From: pavenis AT lanet DOT lv
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com
Date: Wed, 13 Jun 2001 14:15:49 +0300
MIME-Version: 1.0
Content-type: text/enriched; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: GCC-3.0 related problem with src/libc/stubs/stubXXXX.S
Message-ID: <3B277595.25597.40015F@localhost>
References: <200106130926 DOT f5D9QAX03971 AT hal DOT astr DOT lu DOT lv>
In-reply-to: <Pine.SUN.3.91.1010613133805.17089B@is>
X-mailer: Pegasus Mail for Win32 (v3.12c)
Reply-To: djgpp-workers AT delorie DOT com

<color><param>0100,0100,0100</param>On 13 Jun 2001, at 13:41, Eli Zaretskii wrote:


<color><param>7F00,0000,0000</param>> 

> On Wed, 13 Jun 2001, Andris Pavenis wrote:

> 

> > stubXXXX.S files generated by mkstubs triggers gcc-3.0 preprocessor bug

> > (See http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3081&database=gcc):

> > 

> > preprocessor errorously merges first 2 lines (if these are not preprocessor 

> > instructions) when -imacros command line option is being used. It's rather

> > harmless for most real life situations (we have #include ... at start of 

> > program), but it causes syntax errors in this case (stubXXXX.S)

> > 

> > I got a respsonse that it's rather unlikely to be fixed in gcc-3.0 release

> > Fortunatelly it's easy to workaround this bug by simply adding

> > blank line at start of .S file:

> 

> I don't like this solution: I think a library shouldn't have to work 

> around such blatant bugs (are they serious about not fixing it in 3.0 

> release??).


</color>Perhaps too little time left (they expect to put out gcc-3.0 in June 15th AFAIK). 
Perhaps (it's my optionion) it should be named beta.

We can do this for DJGPP (not to put gcc-3.0 for DJGPP in v2gnu, only in 
v2gnu/betas) and wait for 3.0.1. 


I also didn't get any feedback about binaries I uploaded for v2gnu/alphas

<color><param>7F00,0000,0000</param> 

</color>About this bug: it took about 1 hour after I submitted bug report to GNATS to get 
response. Unfortunatelly it's clasified as low priority bug:


Number: 3081  

Category: preprocessor  

Synopsis: Preprocessor merges 2 first lines when -imacros is being used  

Confidential: no  

Severity: non-critical  

Priority: low  

Responsible: neil  

State: analyzed  

Class: sw-bug  

Submitter-Id: net  

Arrival-Date: Thu Jun 07 22:46:00 PDT 2001  


I don't know preprocessor well enough to fix it myself


<color><param>7F00,0000,0000</param>> Does it help to use -traditional when compiling stub*.S files?  If it 

> does, I'd prefer to use tradcpp for the stubs until they fix this in the 

> mainline version.


</color>tradcpp doesn't have this bug


but tradcpp doesn't like options -remap and -imacros. Of course I can 

exclude these options in specs when tradcpp is being used:


*cpp:

%{!traditional|ftraditional|traditional-cpp:-remap} %(cpp_cpu) %{posix:-
D_POSIX_SOURCE}   %{!ansi:%{!std=c*:%{!std=i*:-DMSDOS}}} 
%{!ansi:%{!std=c*:%{!std=i*:-DGO32}}}   %{!traditional|ftraditional|traditional-
cpp:-imacros %sdjgpp.ver}


Andris


<nofill>