Re: GCC 3.4.4 RC1

[R Hill]

Giovanni Bajo wrote:
Etienne Lorrain <[EMAIL PROTECTED]> wrote:
 Some of those problem may also exist in GCC-4.0 because this
version (and the 4.1 I tested) gives me an increase of 60% of the
code size compared to 3.4.3.
This is a serious regression which should be submitted in Bugzilla. Would
you please take care of that? It is sufficient to provide a single
preprocessed source which shows the code size increase in compilation. GCC4
still needs some tuning for -Os.
Thanks!
This might be a good time to see if anyone will take a look at 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21314

If it is indeed unreproducable, I'd like to know so I can close it.
Thanks. :)

Re: successful build on i686-pc-cygwin

[Jørgen Havsberg Seland]

Christopher Faylor wrote:

>On Sat, May 07, 2005 at 04:44:44PM +0100, Dave Korn wrote:
>  
>
>>Original Message
>>
>>
>>>From: J?rgen Havsberg Seland
>>>Sent: 06 May 2005 23:30
>>>  
>>>
>>>additional information: Important to mount all binary folders with the
>>>-X option, as otherwise command-lines will be too long, for instance:
>>>
>>>mount -f -X c:/cygwin/bin /bin
>>>
>>>Important: This also goes for the executables built, so having your
>>>objdir inside a mount with cygexec enabled is required.
>>>  
>>>
>>Strange that, I didn't have any similar trouble.  Did you unpack the
>>source into a directory that had a fairly long path name to start with?
>>
>>
>It could also be an environment variable problem.  Too many environment
>variables could overflow the windows enviroment buffer unless you use
>"-X".
>  
>
I have many and long environment variables, so that may well be the
problem.

--
[jorgen] (at) [fabeljet] (dot) [com]

Re: GCC 3.4.4 RC1

[Etienne Lorrain]

> Etienne Lorrain <[EMAIL PROTECTED]> wrote:
>
>>   If I compile that with GCC-3.4, I get:
>>
>> $ size tmp.o
>> textdata bss dec hex filename
>>  243   0   0 243  f3 tmp.o
>>
>>   With GCC-4.0:
>>
>> $ size tmp.o
>> textdata bss dec hex filename
>>  387   0   0 387 183 tmp.o
>>
>>   Can someone confirm the problem first?
>
>
> I can confirm that this function shows a regression simply with -Os, on
> x86-linux:
>
> GCC 3.4.3:
>textdata bss dec hex filename
> 194   0   0 194  c2 test.o
>
> GCC 4.1.0 CVS 20050323
>textdata bss dec hex filename
> 280   0   0 280 118 test.o
>
> So it's a 44% increase. Definitely worth a bugreport in Bugzilla!
> --
> Giovanni Bajo
>

  Report done:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21529

Re: GCC 3.4.4 RC1

[Etienne Lorrain]

> Etienne Lorrain <[EMAIL PROTECTED]> wrote:
>
>>   If I compile that with GCC-3.4, I get:
>>
>> $ size tmp.o
>> textdata bss dec hex filename
>>  243   0   0 243  f3 tmp.o
>>
>>   With GCC-4.0:
>>
>> $ size tmp.o
>> textdata bss dec hex filename
>>  387   0   0 387 183 tmp.o
>>
>>   Can someone confirm the problem first?
>
>
> I can confirm that this function shows a regression simply with -Os, on
> x86-linux:
>
> GCC 3.4.3:
>textdata bss dec hex filename
> 194   0   0 194  c2 test.o
>
> GCC 4.1.0 CVS 20050323
>textdata bss dec hex filename
> 280   0   0 280 118 test.o
>
> So it's a 44% increase. Definitely worth a bugreport in Bugzilla!
> --
> Giovanni Bajo
>

  Report done:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21529

Re: Proposed resolution to aliasing issue.

[Theodore Papadopoulo]

On Wed, 2005-05-11 at 15:30 -0700, Mark Mitchell wrote:
> Wolfgang Bangerth wrote:
> > Mark,
> > it occurred to me that asking the question you pose may use language that 
> > is 
> > more unfamiliar than necessary. How about this question instead -- assume
> > 
> >   struct S { int s; };
> >   struct X {
> > int i;
> > struct S s;
> >   };
> > 
> >   void g(struct S*);
> >   void f() {
> > X x;
> > g(&x.s);
> >   }
> > 
> > Would the compiler be allowed to realize that X::i is never referenced and 
> > therefore a dead variable? I assume the compiler doesn't do that right now, 
> > but it would be straightforward for a scalar replacement algorithm to not 
> > even allocate stack space for X::i, but only X::s, and hand the address of 
> > the only remaining stack object, of type S, to g().
> 
> I agree that this is the same issue, in another guise.  My point of view 
> is that this optimization would not be valid, pending clarification of 
> the issues we've been discussing.  As soon as any component of "x" is 
> addressed, we must assume that all of "x" is addressed -- unless we can 
> prove otherwise, by, say, looking at the body of "g".

Just a slightly dis-connected question (probably very academic):

Given the following:

struct A {
B& b1;
B& b2;
  const B& b3;

  A(B& b): b1(b),b2(b),b3(b) { }
};

Is the compiler allowed to suppress b2 and/or b3 from the layout of the
object. The next question comes when b1,b2 and b3 are in various places
in an inheritance path, would it be allowed to only keep the first
reference in this path (provided of course that it can be proved that
all references are bound to the same object).

RE: Borland software patent restricting GNU compiler development

[Casper Hornstrup]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Bosscher
> Sent: 11. maj 2005 14:20
> To: gcc@gcc.gnu.org
> Cc: Paolo Bonzini; Ingrid Marson
> Subject: Re: Borland software patent restricting GNU compiler development
> 
> On Wednesday 11 May 2005 13:40, Paolo Bonzini wrote:
> > > The Borland patent is a patent for standard exception handling
> > > http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL
> > > &p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=5,628,016.WKU.&OS=PN/5,628,
> > > 016&RS=PN/5,628,016
> >
> > http://snipurl.com/et1w
> 
> And FWIW, patches exist outside the FSF tree to support SEH, see e.g.
> http://reactos.csh-consult.dk/index.php?page=gccseh
> 
> Gr.
> Steven

I'm writing this patch because A) we need it for the open-source Windows(R) 
compatible OS ReactOS (http://www.reactos.com) and B)
it's not illegal for me to write and publish the patch even if the patent is 
not void since I live in the EU. That said, I do
believe the patent is void (not that it matter). The patent application even 
mentions prior art:

"Niezgoda, S., Holt, L. and Wojciech, D., NT's Structured Exception Handling, 
Byte, Nov. 1993, pp. 317-322."

Casper

Re: mainline boostrap comparison failure on i686-pc-linux-gnu with gcc 3.2.3 20030502 (Red Hat Linux 3.2.3-49)

[Joern RENNECKE]

Andrew Pinski wrote:
	
   

Actually it is easy to peak at any of them and you will see that the
tree optimizators (lim to be in fact) has changed something somewhere.
 

The trouble is that I'm running the tests on Red hat Enterprise Linux, 
and even
with the address randomization allegedly turned off, most addresses 
still end
up being random.  So I've looked at differences of dump file sizes 
instead, and the
first was in the greg dumps.  Still, experimentation with 3.4.3 supports 
your
statement that the mainline code is to blame: I also get bootstrap 
comparison
failures with 3.4.3 as the bootstrap compiler, in fact two different sets
using two different mainline snapshots:

Bootstrap comparison failure!
./expmed.o differs
build/genattrtab.o differs
build/gengtype-lex.o differs
make[1]: *** [gnucompare] Error 1
and
Bootstrap comparison failure!
./emit-rtl.o differs
./expmed.o differs
build/genattrtab.o differs
make[1]: *** [gnucompare] Error 1

Re: volatile semantics

[Paul Koning]

> "Geoffrey" == Geoffrey Keating <[EMAIL PROTECTED]> writes:

 Geoffrey> Paul Koning <[EMAIL PROTECTED]> writes:
 >> Still, never mind what the C spec appears to say, optimizing away
 >> the cast cannot possibly what the user intended.

 Geoffrey> The user might have written a routine which takes a
 Geoffrey> 'volatile int *', with the intent that routine would be
 Geoffrey> used on both regular and volatile 'int's.  The compiler
 Geoffrey> might be able to see (after inlining) that this particular
 Geoffrey> instance does not actually refer to a volatile variable,
 Geoffrey> and so be able to optimise the routine better.

Ok, so every once in a while you might run into a case like that, and
you could very slightly speed up that case at the expense of
introducing a hairy bug into all other cases.  Not a good tradeoff at
all.

paul

Re: mainline boostrap comparison failure on i686-pc-linux-gnu with gcc 3.2.3 20030502 (Red Hat Linux 3.2.3-49)

[H. J. Lu]

On Thu, May 12, 2005 at 01:42:26PM +0100, Joern RENNECKE wrote:
> Andrew Pinski wrote:
> 
> >>
> >>   
> >>
> >Actually it is easy to peak at any of them and you will see that the
> >tree optimizators (lim to be in fact) has changed something somewhere.
> > 
> >
> The trouble is that I'm running the tests on Red hat Enterprise Linux, 
> and even
> with the address randomization allegedly turned off, most addresses 
> still end
> up being random.  So I've looked at differences of dump file sizes 
> instead, and the
> first was in the greg dumps.  Still, experimentation with 3.4.3 supports 
> your
> statement that the mainline code is to blame: I also get bootstrap 
> comparison
> failures with 3.4.3 as the bootstrap compiler, in fact two different sets
> using two different mainline snapshots:
> 
> Bootstrap comparison failure!
> ./expmed.o differs
> build/genattrtab.o differs
> build/gengtype-lex.o differs
> make[1]: *** [gnucompare] Error 1
> 
> and
> 
> Bootstrap comparison failure!
> ./emit-rtl.o differs
> ./expmed.o differs
> build/genattrtab.o differs
> make[1]: *** [gnucompare] Error 1

FWIW, I saw the same problem on RHEL 4.


H.J.

Re: ppc-eabisim is broken in mainline

[Joern RENNECKE]

Aldy Hernandez wrote:

* config/rs6000/sysv4.opt (mlittle): Handle.
* config/rs6000/rs6000.c (rs6000_handle_option): Set
target_flags_explicit when appropriate.
 

Thanks, this allowed my build to complete.  It's regression testing now.  

Re: check_ext_dependent_givs

[Canqun Yang]

Hi, Bonzini,

Thank you for your reponse.
I do not want to modify the old loop optimizer defined 
in loop.c.  I am preparing to port some improvements 
done on gcc-3.5 to gcc-4.0, and the GIV optimizations 
is part of my concerns.

On IA-64, the GIV optimization can hardly improve the 
performance. The reason is that 
check_ext_dependent_givs can not giv an exactly answer 
whether the BIVs will be wrap around or not. In most 
cases, it only produce a conservative result that the 
BIVs may overflow and the corresponding GIVs can not 
be reduced. 

I modified the code in check_ext_dependent_givs to let 
the BIVs always successfully pass the check, then test 
the example you have given to me, but the result is 
the same as before.

Would you please give me another example which will 
lead a wrong result if the check_ext_dependnet_givs 
has not been called. FORTRAN program is nice, and my 
platform is a 64bit system.

Best regards,

Canqun Yang
Creative Compiler Research Group.
National University of Defense Technology, China.

packaging a GCC binary distribution so it can be installed at arbitrary locations?

[Gary Funck]

Given a binary distibution of GCC, for example, built to install under
/usr/local, is it possible to configure and build the compiler in such a
way that a binary packaging method such as RPM can allow a user to specify
an alternate installation point (perhaps /opt, or even the user's home
directory) and have it all work?

My impression is that too many hard coded paths are wired into gcc.c when
it is built to make this ability to migrate the binary possible.  There are
workarounds for the user such as setting various environment variables and
using the -B switch, but I'm looking for a method that directly allows 
installation
of the binary to a new place than where it was initially configured.  Anyone 
found
a way to do this?  (Separately, GCC 3.4 is now built using dynamic libraries
for libgcc and libunwind, and these cause some different but unique problems
invoking gcc [assuming the user would prefer not to adjust their library path
or doesn't have access to /etc/ld.so.conf. I think things could be made
simpler by specifying various -rpath settings when the executable is linked,
but these -rpath settings may have to fixed up when installing the binary
to a place other than it was built, unless the entries can be made relative
to the executable.])

Re: packaging a GCC binary distribution so it can be installed at arbitrary locations?

[Ian Lance Taylor]

"Gary Funck" <[EMAIL PROTECTED]> writes:

> Given a binary distibution of GCC, for example, built to install under
> /usr/local, is it possible to configure and build the compiler in such a
> way that a binary packaging method such as RPM can allow a user to specify
> an alternate installation point (perhaps /opt, or even the user's home
> directory) and have it all work?

Yes, with recent versions of gcc you can move the entire tree around
and the gcc driver will still be able to find the various internal
executables and header files.  You need to keep the tree in the same
format, but everything is found relatively.

Telling the dynamic linker about a dynamic libgcc is still a problem,
but that is a problem whereever you put the compiler.

Ian

Is -static a link-only switch?

[Gary Funck]

Does the -static switch play any role during compilation, or is it
a link-only switch?  A quick review of gcc.c, indicates that -static
may play a role on some targets:

/* %{static:} simply prevents an error message if the target machine
   doesn't handle -static.  */

However, the info documentation shows the following:

 *Note Options for Linking: Link Options. 
  OBJECT-FILE-NAME  -lLIBRARY  
  -nostartfiles  -nodefaultlibs  -nostdlib  
  -s  -static  -static-libgcc  -shared  -shared-libgcc  -symbolic 
  -Wl,OPTION  -Xlinker OPTION  
  -u SYMBOL.


I can think of target OS's that might define a different ABI for procedure calls
for programs compiled with -static asserted, than when compiled for a dynamic
linking environment, but can't quite tell if in fact -static has any effect
during compilation.

RE: packaging a GCC binary distribution so it can be installed at arbitrary locations?

[Gary Funck]

> 
> Yes, with recent versions of gcc you can move the entire tree around
> and the gcc driver will still be able to find the various internal
> executables and header files. [...]

Ian, thanks.

Which versions qualify as "recent" above?  GCC 3.4, or 4.0, or both?
Is there any documentation on how the new packaging mechanism works?
If this was discussed on this list, would you happen to know approximately,
when (so I can do a search of the archives)? 

Re: Is -static a link-only switch?

[Daniel Jacobowitz]

On Thu, May 12, 2005 at 08:37:54AM -0700, Gary Funck wrote:
> 
> Does the -static switch play any role during compilation, or is it
> a link-only switch?  A quick review of gcc.c, indicates that -static
> may play a role on some targets:
> 
> /* %{static:} simply prevents an error message if the target machine
>doesn't handle -static.  */

... in its link specs.

> I can think of target OS's that might define a different ABI for procedure 
> calls
> for programs compiled with -static asserted, than when compiled for a dynamic
> linking environment, but can't quite tell if in fact -static has any effect
> during compilation.

I don't know of any; it was a close call on one RTOS I worked on
recently, but it turned out that nothing else was necessary.  This sort
of applies to MIPS but that gets a separate option (-fno-pic
-mno-abicalls).

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: packaging a GCC binary distribution so it can be installed at arbitrary locations?

[Daniel Jacobowitz]

On Thu, May 12, 2005 at 08:41:58AM -0700, Gary Funck wrote:
> 
> > 
> > Yes, with recent versions of gcc you can move the entire tree around
> > and the gcc driver will still be able to find the various internal
> > executables and header files. [...]
> 
> Ian, thanks.
> 
> Which versions qualify as "recent" above?  GCC 3.4, or 4.0, or both?

Since at least 3.3.

> Is there any documentation on how the new packaging mechanism works?

It's not a new packaging mechanism and it doesn't require any
adjustment; the entire thing should Just Work.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

stack alginment code

[xiaolei zhang]

hello:

i know the codes below is for alignment purpose,

--
.type   main, @function
main:
pushl   %ebp
movl%esp, %ebp
subl$8, %esp
andl$-16, %esp
--

but I think just ``andl$-16, %esp'' is enough, why  ``subl$8, %
esp'' first?

thanks

Re: Is -static a link-only switch?

[Andrew Pinski]

On May 12, 2005, at 11:43 AM, Daniel Jacobowitz wrote:
I don't know of any; it was a close call on one RTOS I worked on
recently, but it turned out that nothing else was necessary.  This sort
of applies to MIPS but that gets a separate option (-fno-pic
-mno-abicalls).
-static on Darwin has an effect but basically -fno-pic.
Thanks,
Andrew Pinski

Re: Is -static a link-only switch?

[Ian Lance Taylor]

"Gary Funck" <[EMAIL PROTECTED]> writes:

> Does the -static switch play any role during compilation, or is it
> a link-only switch?

It is a link-only switch.

>  A quick review of gcc.c, indicates that -static
> may play a role on some targets:
> 
> /* %{static:} simply prevents an error message if the target machine
>doesn't handle -static.  */

That comment is above LINK_COMMAND_SPEC, which is how gcc invokes the
linker.  It means that if the target does not provide any handling for
-static in the target specific LINK_SPEC, gcc will simply ignore
-static.  It doesn't affect code-generation, only how the linker is
invoked.

> I can think of target OS's that might define a different ABI for
> procedure calls for programs compiled with -static asserted, than
> when compiled for a dynamic linking environment, but can't quite
> tell if in fact -static has any effect during compilation.

In fact many targets compile code differently depending upon whether
the code is to be put into a shared library or not, but this is
controlled via options like -fpic, not -static.

Ian

RE: Is -static a link-only switch?

[Gary Funck]

Ian Lance Taylor wrote (in part): 
> In fact many targets compile code differently depending upon whether
> the code is to be put into a shared library or not, but this is
> controlled via options like -fpic, not -static.

Is it generally safe on all currently supported targets to assert -fno-pic
when compiling programs that will ultimately be linked with -static asserted?
Will targets that don't support -fpic (and -fon-pic) complain, or just quietly
accept the switch?

Re: -fdump-translation-unit considered harmful

[Dams, Dennis (Dennis)]

 > Zack Weinberg <[EMAIL PROTECTED]> writes:
 > 
 > [...]
 > 
 > | Me ranting about -fdump-translation-unit had nothing to do with your
 > | problem, really, it's just that your message reminded me that I was
 > | going to bring that up.
 > 
 > I think -fdump-translation-unit should remain.  I thereby volunteer to
 > take any question about it.  
 > 
 > -- Gaby

Gaby,

I'm trying to use the -fdump-translation-unit option (gcc (GCC) 4.1.0 20050505 
(experimental)), but it does not seem to do anything. What's the right way to 
use it - should I specify any additional switches/options?
thanks,
--Dennis.

GCC 4.0.1-beta20050507 miscompiles openssl-0.9.7g with -ftree-loop-linear

[Zan Lynx]

I'm not subscribed to the list (please CC replies to me) and this isn't
a real bug report, just a sort of quick check to see if its a known
problem.

When I compiled openssl-0.9.7g using -O3 and -ftree-loop-linear as
CFLAGS, openssl failed its self-tests for the MD2 code.  Interestingly,
it succeeded at the tests for other algorithms.

Oh yeah, this was in Gentoo Linux on an Athlon64 in 64-bit mode.

I haven't been able to isolate the problem code and I'm having trouble
building GCC from CVS, so no real bug report yet.  I'll get there, but
if this is already a known bug, please let me know, thanks. :-)
-- 
Zan Lynx <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: check_ext_dependent_givs

[Paolo Bonzini]

I modified the code in check_ext_dependent_givs to let 
the BIVs always successfully pass the check, then test 
the example you have given to me, but the result is 
the same as before.
It depends on whether the old loop optimizer will actually decide that 
it is worthwhile to use the induction variable.  Maybe it did not for 
unrelated reasons.

Paolo

RE: packaging a GCC binary distribution so it can be installed at arbitrary locations?

[Gary Funck]

Ian Lance Taylor wrote (in part):
> Telling the dynamic linker about a dynamic libgcc is still a problem,
> but that is a problem whereever you put the compiler.

If I'm not interested in build a dynamically linked gcc, or building
libgcc and related libraries as dynamic libraries, can I simply assert
--disable-shared when configuring gcc, and thus ensure that the resulting
compiler binaries can be easily moved around?

Re: GCC 4.0.1-beta20050507 miscompiles openssl-0.9.7g with -ftree-loop-linear

[Daniel Berlin]

On Thu, 2005-05-12 at 10:01 -0600, Zan Lynx wrote:
> I'm not subscribed to the list (please CC replies to me) and this isn't
> a real bug report, just a sort of quick check to see if its a known
> problem.
> 
> When I compiled openssl-0.9.7g using -O3 and -ftree-loop-linear as
> CFLAGS, openssl failed its self-tests for the MD2 code.  Interestingly,
> it succeeded at the tests for other algorithms.
> 

-ftree-loop-linear uses the dependence analyzer which has a number of
issues where it will claim things are legal that are not.

You shouldn't expect -ftree-loop-linear to work on random code that you
don't know anything about :)
At least, not yet.
Hopefully these should be fixed in 4.1

Re: GCC 4.0.1-beta20050507 miscompiles openssl-0.9.7g with -ftree-loop-linear

[Zan Lynx]

On Thu, 2005-05-12 at 12:30 -0400, Daniel Berlin wrote:
> On Thu, 2005-05-12 at 10:01 -0600, Zan Lynx wrote:
> > I'm not subscribed to the list (please CC replies to me) and this isn't
> > a real bug report, just a sort of quick check to see if its a known
> > problem.
> > 
> > When I compiled openssl-0.9.7g using -O3 and -ftree-loop-linear as
> > CFLAGS, openssl failed its self-tests for the MD2 code.  Interestingly,
> > it succeeded at the tests for other algorithms.
> > 
> 
> -ftree-loop-linear uses the dependence analyzer which has a number of
> issues where it will claim things are legal that are not.
> 
> You shouldn't expect -ftree-loop-linear to work on random code that you
> don't know anything about :)
> At least, not yet.
> Hopefully these should be fixed in 4.1

Well, you know, *someone* has to try it on random code. :-)

Thanks for telling me.
-- 
Zan Lynx <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: GCC 4.0.1-beta20050507 miscompiles openssl-0.9.7g with -ftree-loop-linear

[Sebastian Pop]

Daniel Berlin wrote:
> On Thu, 2005-05-12 at 10:01 -0600, Zan Lynx wrote:
> > I'm not subscribed to the list (please CC replies to me) and this isn't
> > a real bug report, just a sort of quick check to see if its a known
> > problem.
> > 
> > When I compiled openssl-0.9.7g using -O3 and -ftree-loop-linear as
> > CFLAGS, openssl failed its self-tests for the MD2 code.  Interestingly,
> > it succeeded at the tests for other algorithms.
> > 
> 
> -ftree-loop-linear uses the dependence analyzer which has a number of
> issues where it will claim things are legal that are not.
> 
> You shouldn't expect -ftree-loop-linear to work on random code that you
> don't know anything about :)
> At least, not yet.
> Hopefully these should be fixed in 4.1
> 
> 

The loops that get interchanged are in the following function:

static void md2_block(MD2_CTX *c, const unsigned char *d)
 {
 register unsigned int t,*sp1,*sp2;
 register int i,j;
 unsigned int state[48];

 sp1=c->state;
 sp2=c->cksm;
 j=sp2[16 -1];
 for (i=0; i<16; i++)
  {
  state[i]=sp1[i];
  state[i+16]=t=d[i];
  state[i+32]=(t^sp1[i]);
  j=sp2[i]^=S[t^j];
  }
 t=0;
 for (i=0; i<18; i++)
  {
  for (j=0; j<48; j+=8)
   {
   t= state[j+ 0]^=S[t];
   t= state[j+ 1]^=S[t];
   t= state[j+ 2]^=S[t];
   t= state[j+ 3]^=S[t];
   t= state[j+ 4]^=S[t];
   t= state[j+ 5]^=S[t];
   t= state[j+ 6]^=S[t];
   t= state[j+ 7]^=S[t];
   }
  t=(t+i)&0xff;
  }
 memcpy(sp1,state,16*sizeof(unsigned int));
 OPENSSL_cleanse(state,48*sizeof(unsigned int));
 }

It is failing on mainline with:

md2_dgst.c: In function 'md2_block':
md2_dgst.c:170: error: Definition in block 13 does not dominate use in block 9
for SSA_NAME: t_23 in statement:
t_143 = PHI ;
PHI argument
t_23
for PHI node
t_143 = PHI ;
md2_dgst.c:170: internal compiler error: verify_ssa failed.

after transformation in loop linear.

Re: GCC 4.0.1-beta20050507 miscompiles openssl-0.9.7g with -ftree-loop-linear

[Daniel Berlin]

On Thu, 2005-05-12 at 18:45 +0200, Sebastian Pop wrote:
> Daniel Berlin wrote:
> > On Thu, 2005-05-12 at 10:01 -0600, Zan Lynx wrote:
> > > I'm not subscribed to the list (please CC replies to me) and this isn't
> > > a real bug report, just a sort of quick check to see if its a known
> > > problem.
> > > 
> > > When I compiled openssl-0.9.7g using -O3 and -ftree-loop-linear as
> > > CFLAGS, openssl failed its self-tests for the MD2 code.  Interestingly,
> > > it succeeded at the tests for other algorithms.
> > > 
> > 
> > -ftree-loop-linear uses the dependence analyzer which has a number of
> > issues where it will claim things are legal that are not.
> > 
> > You shouldn't expect -ftree-loop-linear to work on random code that you
> > don't know anything about :)
> > At least, not yet.
> > Hopefully these should be fixed in 4.1
> > 
> > 
> 
> The loops that get interchanged are in the following function:
> after transformation in loop linear.
> 

Does -fno-tree-ch fix it? (i'm just curious)

Re: Proposed resolution to aliasing issue.

[Mark Mitchell]

Theodore Papadopoulo wrote:
On Wed, 2005-05-11 at 15:30 -0700, Mark Mitchell wrote:
Given the following:
struct A {
B& b1;
B& b2;
  const B& b3;
  A(B& b): b1(b),b2(b),b3(b) { }
};
Is the compiler allowed to suppress b2 and/or b3 from the layout of the
object. The next question comes when b1,b2 and b3 are in various places
in an inheritance path, would it be allowed to only keep the first
reference in this path (provided of course that it can be proved that
all references are bound to the same object).
Tricky!  Because you can't get the address of the reference, or form a 
pointer-to-member, it might be valid to do the optimization you suggest. 
   Then again, there might be something lurking that I'm not thinking of.

In any case, nobody does that optimization, and it would break the ABI.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: GCC 4.0.1-beta20050507 miscompiles openssl-0.9.7g with -ftree-loop-linear

[Sebastian Pop]

Daniel Berlin wrote:
> 
> Does -fno-tree-ch fix it? (i'm just curious)
> 

No. It still ICEs.

Why doesn't operand_equal_p check pointer equality first?

[Diego Novillo]

Wouldn't it make sense for operand_equal_p to start with:

int
operand_equal_p (tree arg0, tree arg1, unsigned int flags)
{
  if (arg0 == arg1 && !TREE_SIDE_EFFECTS (arg0))
return 1;
  ...
}

Am I missing something here?


Thanks.  Diego.

Looking for cheap high-quality software?

[Bartholomew]

Get a head start on a new computer career
http://lcdrtz.7et4ao7i4h7wmq7.mckayaaebj.com

Re: Is -static a link-only switch?

[Ian Lance Taylor]

"Gary Funck" <[EMAIL PROTECTED]> writes:

> Ian Lance Taylor wrote (in part): 
> > In fact many targets compile code differently depending upon whether
> > the code is to be put into a shared library or not, but this is
> > controlled via options like -fpic, not -static.
> 
> Is it generally safe on all currently supported targets to assert -fno-pic
> when compiling programs that will ultimately be linked with -static asserted?
> Will targets that don't support -fpic (and -fon-pic) complain, or just quietly
> accept the switch?

I believe that -fno-pic will always be accepted, even if it does
nothing.

I'm not sure what you are after here, but I'll note that there are
other related options for specific targets, like MIPS -mno-abicalls.
I'll also note that on most, and perhaps all, targets, you are
permitted to link -fpic code into a statically linked executable, with
some loss of efficiency.

Ian

Re: Proposed resolution to aliasing issue.

[Theodore Papadopoulo]

On Thu, 2005-05-12 at 10:01 -0700, Mark Mitchell wrote:
> Theodore Papadopoulo wrote:
> > On Wed, 2005-05-11 at 15:30 -0700, Mark Mitchell wrote:
> > 
> > Given the following:
> > 
> > struct A {
> > B& b1;
> > B& b2;
> >   const B& b3;
> > 
> >   A(B& b): b1(b),b2(b),b3(b) { }
> > };
> > 
> > Is the compiler allowed to suppress b2 and/or b3 from the layout of the
> > object. The next question comes when b1,b2 and b3 are in various places
> > in an inheritance path, would it be allowed to only keep the first
> > reference in this path (provided of course that it can be proved that
> > all references are bound to the same object).
> 
> Tricky!  Because you can't get the address of the reference, or form a 
> pointer-to-member, it might be valid to do the optimization you suggest. 
> Then again, there might be something lurking that I'm not thinking of.

> In any case, nobody does that optimization, and it would break the ABI.

Yeah I understand that. But one day I might want to evaluate the impact
of this (multiple references) in some of my codes (which of course
include many arrays which is where I would like to avoid some memory
explosion). Obviously, it is always possible to avoid it using simple
programming tricks but this somehow is less clean from the programmer
POV.

Anyway thank's a lot for the answer...

Theo.

i386.md:17581: warning: operand 1 missing mode?

[Thomas Koenig]

With the current 4.0 snapshot:

../../gcc-4.0/gcc/config/i386/i386.md:17581: warning: operand 1 missing mode?

Is this cause for concern?  Should I open a PR for this?

Re: GCC 4.0.0 Performance Regressions?

[Jason Bucata]

On Tue, May 10, 2005 at 05:52:40PM -0700, Joe Buck wrote:
> On Tue, May 10, 2005 at 06:08:43PM -0500, Jason Bucata wrote:
> > Would it help to report some others [regressions]?
> > I might have time later this week to
> > work on some of the others, especially now that I have a much better idea of
> > what to look for.
> 
> If you can find a small test with a large regression (say 30% or more), it
> would be great to have a PR for such a thing.  All else being equal,
> smaller test cases are easier to debug, so I'd suggest starting with as
> small a test as possible that causes as large a regression as possible, if
> you have any like that.

OK, two more bugs posted:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21507
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21527

That's it for this batch, unless somebody wants me to chase down the other
problem noted in 21527.

I noticed some 4.0.0 regressions in SciMark noted here:
http://www.coyotegulch.com/reviews/gcc4/index.html
So I've thought I might try to chase down the regressions in Sparse MIPS and
LU MIPS... but that will have to wait a while while I catch up on other
things.

Jason B.

-- 
"My interest is in the future; I am going to spend the rest of my life
there."
-- Charles Kettering

Re: -fdump-translation-unit considered harmful

[Ian Lance Taylor]

"Dams, Dennis \(Dennis\)" <[EMAIL PROTECTED]> writes:

> I'm trying to use the -fdump-translation-unit option (gcc (GCC)
> 4.1.0 20050505 (experimental)), but it does not seem to do
> anything. What's the right way to use it - should I specify any
> additional switches/options?

-fdump-translation-unit doesn't do anything in the C frontend.  The C
frontend almost generates GENERIC anyhow.  -fdump-translation-unit
does do something in the C++ frontend.  Try it when compiling a C++
file.

Ian

Re: packaging a GCC binary distribution so it can be installed at arbitrary locations?

[Ian Lance Taylor]

"Gary Funck" <[EMAIL PROTECTED]> writes:

> Ian Lance Taylor wrote (in part):
> > Telling the dynamic linker about a dynamic libgcc is still a problem,
> > but that is a problem whereever you put the compiler.
> 
> If I'm not interested in build a dynamically linked gcc, or building
> libgcc and related libraries as dynamic libraries, can I simply assert
> --disable-shared when configuring gcc, and thus ensure that the resulting
> compiler binaries can be easily moved around?

Pedantically, the compiler binaries can be moved around in any case.
The only issue with a shared libgcc is whether the dynamic linker can
find it when you run a program linked against it.  It is of course
possible to fix this, whereever the library winds, up by using
/etc/ld.so.conf (if available) or LD_LIBRARY_PATH (or equivalent).

If you use --disable-shared when configuring gcc, then it won't build
a shared libgcc.  But my understanding is that then you won't be able
to throw and catch exceptions between shared libraries.  See the
discussion of the -shared-libgcc option.

Ian

mixing warning flags

[DJ Delorie]

How to convert this code?  There is no single OPT_* that reflects when
the first warning is emitted.

  if (params == 0 && (warn_format_nonliteral || warn_format_security))
warning (0, "format not a string literal and no format arguments");
  else
warning (OPT_Wformat_nonliteral,
 "format not a string literal, argument types not checked");

One option is:

  if (params == 0)
warning (OPT_Wformat_security,
 "format not a string literal and no format arguments");
  warning (OPT_Wformat_nonliteral,
   "format not a string literal, argument types not checked");

but a little re-wording might be useful for when you get both
warnings.  Alternately:

  if (params == 0 && warn_format_security)
warning (OPT_Wformat_security,
 "format not a string literal and no format arguments");
  else
warning (OPT_Wformat_nonliteral,
 "format not a string literal, argument types not checked");

or pedantically:

  if (params == 0 && warn_format_security)
warning (OPT_Wformat_security,
 "format not a string literal and no format arguments");
  els if (params == 0 && warn_format_nonliteral)
warning (OPT_Wformat_nonliteral,
 "format not a string literal and no format arguments");
  else
warning (OPT_Wformat_nonliteral,
 "format not a string literal, argument types not checked");

Re: packaging a GCC binary distribution so it can be installed at arbitrary locations?

[Daniel Kegel]

Daniel Jacobowitz wrote:
On Thu, May 12, 2005 at 08:41:58AM -0700, Gary Funck wrote:
> Yes, with recent versions of gcc you can move the entire tree around
> and the gcc driver will still be able to find the various internal
> executables and header files. [...]
Ian, thanks.
Which versions qualify as "recent" above?  GCC 3.4, or 4.0, or both?
Since at least 3.3.
I think binutils and gdb acquired this talent around Jan 2003
(see http://sources.redhat.com/ml/binutils/2003-01/msg00065.html,
http://sources.redhat.com/ml/gdb-patches/2003-01/msg00380.html)
so you might need newish versions of them, too.
Is there any documentation on how the new packaging mechanism works?
It's not a new packaging mechanism and it doesn't require any
adjustment; the entire thing should Just Work.
If you happen to need to be able to do this with old tools,
you can try http://kegel.com/crosstool/current/fix-embedded-paths.c
Excerpt:
 Program to fix embedded paths in files.
 Useful especially for gcc < 3.0 and binutils < 2.14, which
 do not work if you move them after installation;
 running this program fixes the paths and lets the programs work again.
I use this to be able to build crosstool rpms of old tools
without having write access to the final install location, and it seems to work.
(Actually, I use it for new tools, too, 'cause it doesn't seem to hurt,
and it's nice to have all the embedded paths right just in case.)
- Dan

Re: mixing warning flags

[Joseph S. Myers]

On Thu, 12 May 2005, DJ Delorie wrote:

> if (params == 0 && warn_format_security)
>   warning (OPT_Wformat_security,
>"format not a string literal and no format arguments");
> els if (params == 0 && warn_format_nonliteral)
>   warning (OPT_Wformat_nonliteral,
>"format not a string literal and no format arguments");
> else
>   warning (OPT_Wformat_nonliteral,
>"format not a string literal, argument types not checked");

This appears to reflect the correct logic.

-Wformat-security happens to be a subset of -Wformat-nonliteral at present 
but needn't always be so.  To reflect the logical intent of these options 
while passing a unique OPT_* to each warning call, you'd need to add an 
option -Wformat-security-nonliteral for the warnings in the intersection 
of the two options; make -Wformat-security and -Wformat-nonliteral enable 
it; add a testcase that -Wformat-security-nonliteral does the same as 
-Wformat-security; and add a testcase that -Wformat-nonliteral 
-Wno-format-security-nonliteral gives only the other warnings from 
-Wformat-nonliteral.  The value of so doing is doubtful unless you have 
users who really do want all the -Wformat-nonliteral warnings except those 
in -Wformat-security.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: mixing warning flags

[Daniel Jacobowitz]

On Thu, May 12, 2005 at 03:46:41PM -0400, DJ Delorie wrote:
> 
> How to convert this code?  There is no single OPT_* that reflects when
> the first warning is emitted.
> 
> if (params == 0 && (warn_format_nonliteral || warn_format_security))
>   warning (0, "format not a string literal and no format arguments");
> else
>   warning (OPT_Wformat_nonliteral,
>"format not a string literal, argument types not checked");

How about this?

  if (params == 0 && (warn_format_nonliteral || warn_format_security))
warning (warn_format_security ? OPT_Wformat_security : 
OPT_Wformat_nonliteral,
 "format not a string literal and no format arguments");
  else
warning (OPT_Wformat_nonliteral,
 "format not a string literal, argument types not checked");

The only useful difference being that you don't have to duplicate the
string.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Proposed resolution to aliasing issue.

[Mike Stump]

On May 12, 2005, at 4:32 AM, Theodore Papadopoulo wrote:
Is the compiler allowed to suppress b2 and/or b3 from the layout of  
the
object.
Yes, of course, in some cases.  For example when whole program  
analysis tells it, it can.

The next question comes when b1,b2 and b3 are in various places
in an inheritance path, would it be allowed to only keep the first
reference in this path (provided of course that it can be proved that
all references are bound to the same object).
Yes, of course, same reasoning.
The as-if rule is _very_ flexible.

Re: ld and R_386_GOTOFF relocs

[H. J. Lu]

On Thu, May 12, 2005 at 08:13:27AM +0200, Peter S. Mazinger wrote:
> On Wed, 11 May 2005, H. J. Lu wrote:
> 
> > On Thu, May 12, 2005 at 12:48:46AM +0200, Peter S. Mazinger wrote:
> > > Hello!
> > > 
> > > I have gotten under peculiar circumstances following:
> > > (sysvinit) init.o: relocation R_386_GOTOFF against protected function 
> > > `main' can not be used when making a shared object
> > > 
> > > libc.so does not provide a weak 'main', main() is in crt1.o defined in 
> > > asm 
> > > as '.protected main'.
> > > 
> > > init is built as -pie executable.
> > > 
> > > I think this check is valid if a shared lib is created, but not valid for 
> > > a PIE executable.
> > > 
> > > I think, that a check info->shared should be changed to
> > > info->shared && !info->pie (or !info->executable), to allow pie to be 
> > > linked, but I can't locate the one needed for this.
> > > 
> > > Thanks, Peter
> > 
> > This is a gcc bug
> > 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
> 
> Reading through this, I came to the patch you posted on 2005-02-06 for 
> elf32-i386.c. The comment says: 
> 
> +2005-02-06  H.J. Lu  <[EMAIL PROTECTED]>
> +
> + * elf32-i386.c (elf_i386_relocate_section): Disallow R_386_GOTOFF
> + against protected function when building shared library.
> 
> If you intented to do this only for shared libraries, but not for PIE 
> executables, then info->shared is incorrect, and as I proposed has to be 
> changed.
> 

I checked in the following patch.

FYI, using protected function in executable has no benefit since
noone can override function in executable anyway.


H.J.

2005-05-12  H.J. Lu  <[EMAIL PROTECTED]>

* elf32-i386.c (elf_i386_relocate_section): Allow R_386_GOTOFF
against protected function when building executable.

--- bfd/elf32-i386.c.pie2005-05-12 10:00:49.0 -0700
+++ bfd/elf32-i386.c2005-05-12 13:55:04.0 -0700
@@ -2390,6 +2390,7 @@ elf_i386_relocate_section (bfd *output_b
 for shared library since it may not be local when used
 as function address.  */
  if (info->shared
+ && !info->executable
  && h
  && h->def_regular
  && h->type == STT_FUNC

Re: ppc-eabisim is broken in mainline

[Aldy Hernandez]

On Wed, May 11, 2005 at 07:44:46PM -0400, Aldy Hernandez wrote:
> Joern.
> 
> My combined tree is acting up, so I haven't tested a full build of
> ppc-eabi*, but this fixes the -mlittle problem.
> 
> Let me know how it goes.

This patch fixed Joern's problems (well, the ones so far ;-)).  I
have tested on ppc32-linux by bootstrapping and regression testing.
I also built ppc-eabisim in it's entirety, with multilibs.

OK?

Aldy

Re: mixing warning flags

[DJ Delorie]

> To reflect the logical intent of these options while passing a
> unique OPT_* to each warning call, you'd need to add an option
> -Wformat-security-nonliteral for the warnings in the intersection of
> the two options;

At one point I proposed a system that let you say "this option infers
these other options" which would have been used to synthesize that new
option.  It was too complicated at that point, but it might get
resurrected in the future if we redesign the concept of "warning
classes".

Link to reporter's article regarding Borland patent.

[E. Weddington]

Here's the article in case anyone was interested:

Eric

Re: ld and R_386_GOTOFF relocs

[Peter S. Mazinger]

On Thu, 12 May 2005, H. J. Lu wrote:

> On Thu, May 12, 2005 at 08:13:27AM +0200, Peter S. Mazinger wrote:
> > On Wed, 11 May 2005, H. J. Lu wrote:
> > 
> > > On Thu, May 12, 2005 at 12:48:46AM +0200, Peter S. Mazinger wrote:
> > > > Hello!
> > > > 
> > > > I have gotten under peculiar circumstances following:
> > > > (sysvinit) init.o: relocation R_386_GOTOFF against protected function 
> > > > `main' can not be used when making a shared object
> > > > 
> > > > libc.so does not provide a weak 'main', main() is in crt1.o defined in 
> > > > asm 
> > > > as '.protected main'.
> > > > 
> > > > init is built as -pie executable.
> > > > 
> > > > I think this check is valid if a shared lib is created, but not valid 
> > > > for 
> > > > a PIE executable.
> > > > 
> > > > I think, that a check info->shared should be changed to
> > > > info->shared && !info->pie (or !info->executable), to allow pie to be 
> > > > linked, but I can't locate the one needed for this.
> > > > 
> > > > Thanks, Peter
> > > 
> > > This is a gcc bug
> > > 
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
> > 
> > Reading through this, I came to the patch you posted on 2005-02-06 for 
> > elf32-i386.c. The comment says: 
> > 
> > +2005-02-06  H.J. Lu  <[EMAIL PROTECTED]>
> > +
> > +   * elf32-i386.c (elf_i386_relocate_section): Disallow R_386_GOTOFF
> > +   against protected function when building shared library.
> > 
> > If you intented to do this only for shared libraries, but not for PIE 
> > executables, then info->shared is incorrect, and as I proposed has to be 
> > changed.
> > 
> 
> I checked in the following patch.

Thanks, your patched solved it.

Peter

> 
> FYI, using protected function in executable has no benefit since
> noone can override function in executable anyway.
> 
> 
> H.J.
> 
> 2005-05-12  H.J. Lu  <[EMAIL PROTECTED]>
> 
>   * elf32-i386.c (elf_i386_relocate_section): Allow R_386_GOTOFF
>   against protected function when building executable.
> 
> --- bfd/elf32-i386.c.pie  2005-05-12 10:00:49.0 -0700
> +++ bfd/elf32-i386.c  2005-05-12 13:55:04.0 -0700
> @@ -2390,6 +2390,7 @@ elf_i386_relocate_section (bfd *output_b
>for shared library since it may not be local when used
>as function address.  */
> if (info->shared
> +   && !info->executable
> && h
> && h->def_regular
> && h->type == STT_FUNC
> 
> 

-- 
Peter S. MazingerID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: Why doesn't operand_equal_p check pointer equality first?

[Richard Henderson]

On Thu, May 12, 2005 at 01:14:15PM -0400, Diego Novillo wrote:
> Am I missing something here?

Probably not.


r~

Re: mainline boostrap comparison failure on i686-pc-linux-gnu with gcc 3.2.3 20030502 (Red Hat Linux 3.2.3-49)

[H. J. Lu]

On Thu, May 12, 2005 at 06:11:46AM -0700, H. J. Lu wrote:
> On Thu, May 12, 2005 at 01:42:26PM +0100, Joern RENNECKE wrote:
> > Andrew Pinski wrote:
> > 
> > >>  
> > >>   
> > >>
> > >Actually it is easy to peak at any of them and you will see that the
> > >tree optimizators (lim to be in fact) has changed something somewhere.
> > > 
> > >
> > The trouble is that I'm running the tests on Red hat Enterprise Linux, 
> > and even
> > with the address randomization allegedly turned off, most addresses 
> > still end
> > up being random.  So I've looked at differences of dump file sizes 
> > instead, and the
> > first was in the greg dumps.  Still, experimentation with 3.4.3 supports 
> > your
> > statement that the mainline code is to blame: I also get bootstrap 
> > comparison
> > failures with 3.4.3 as the bootstrap compiler, in fact two different sets
> > using two different mainline snapshots:
> > 
> > Bootstrap comparison failure!
> > ./expmed.o differs
> > build/genattrtab.o differs
> > build/gengtype-lex.o differs
> > make[1]: *** [gnucompare] Error 1
> > 
> > and
> > 
> > Bootstrap comparison failure!
> > ./emit-rtl.o differs
> > ./expmed.o differs
> > build/genattrtab.o differs
> > make[1]: *** [gnucompare] Error 1
> 
> FWIW, I saw the same problem on RHEL 4.
> 

I have verified that this patch

http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00955.html

caused the comparsion failure on RHEL 4/ia32. RHEL 4/ia64 and
RHEL 4/EM64T are OK. The difference is I have

kernel.exec-shield-randomize = 0

in /etc/sysctl.conf on RHEL 4/ia32. I am rerunning it on RHEL 4/ia32
with

kernel.exec-shield-randomize = 1

now.


H.J.

Re: Why doesn't operand_equal_p check pointer equality first?

[Jeffrey A Law]

On Thu, 2005-05-12 at 15:37 -0700, Richard Henderson wrote:
> On Thu, May 12, 2005 at 01:14:15PM -0400, Diego Novillo wrote:
> > Am I missing something here?
> 
> Probably not.
Isn't operand_equal_p used in situations where we're eliminating
instructions -- and isn't the TREE_SIDE_EFFECT bit there to prevent
us from doing things like elimianting calls, volatiles and the like?

jeff

Re: mainline boostrap comparison failure on i686-pc-linux-gnu with gcc 3.2.3 20030502 (Red Hat Linux 3.2.3-49)

[H. J. Lu]

On Thu, May 12, 2005 at 04:36:58PM -0700, H. J. Lu wrote:
> On Thu, May 12, 2005 at 06:11:46AM -0700, H. J. Lu wrote:
> > On Thu, May 12, 2005 at 01:42:26PM +0100, Joern RENNECKE wrote:
> > > Andrew Pinski wrote:
> > > 
> > > >>
> > > >>   
> > > >>
> > > >Actually it is easy to peak at any of them and you will see that the
> > > >tree optimizators (lim to be in fact) has changed something somewhere.
> > > > 
> > > >
> > > The trouble is that I'm running the tests on Red hat Enterprise Linux, 
> > > and even
> > > with the address randomization allegedly turned off, most addresses 
> > > still end
> > > up being random.  So I've looked at differences of dump file sizes 
> > > instead, and the
> > > first was in the greg dumps.  Still, experimentation with 3.4.3 supports 
> > > your
> > > statement that the mainline code is to blame: I also get bootstrap 
> > > comparison
> > > failures with 3.4.3 as the bootstrap compiler, in fact two different sets
> > > using two different mainline snapshots:
> > > 
> > > Bootstrap comparison failure!
> > > ./expmed.o differs
> > > build/genattrtab.o differs
> > > build/gengtype-lex.o differs
> > > make[1]: *** [gnucompare] Error 1
> > > 
> > > and
> > > 
> > > Bootstrap comparison failure!
> > > ./emit-rtl.o differs
> > > ./expmed.o differs
> > > build/genattrtab.o differs
> > > make[1]: *** [gnucompare] Error 1
> > 
> > FWIW, I saw the same problem on RHEL 4.
> > 
> 
> I have verified that this patch
> 
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00955.html
> 
> caused the comparsion failure on RHEL 4/ia32. RHEL 4/ia64 and
> RHEL 4/EM64T are OK. The difference is I have
> 
> kernel.exec-shield-randomize = 0
> 
> in /etc/sysctl.conf on RHEL 4/ia32. I am rerunning it on RHEL 4/ia32
> with
> 
> kernel.exec-shield-randomize = 1
> 
> now.

I got the same comparsion failure.


H.J.

Re: GCC 3.4.4 RC1

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark Mitchell wrote:
| GCC 3.4.4 RC1 is available here:
|
| ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.4-20050510/
|
| As usual, please test -- by using exactly those tarballs, so that we can
| detect packging errors.  Put problems into Bugzilla, and Cc: me.  At
| this point, the only problems that would block the release would be
| serious regressions from previous 3.4.x compilers.
|
Just noting that because of some changes made to darwin8 libraries:
"ld: Undefined symbols:
_fprintf$LDBLStub"
When trying to use gcc-3.4.4 to build libtool on powerpc-apple-darwin8.0.0
Surprisingly, the compiler actually built on darwin8 and even passed many of
it's tests.
Any @apple person want to backport the necessary bits to the 3.4 branch?
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)
iQCVAwUBQoQGWLiDAg3OZTLPAQKG8wP+Pnhhg0A1uU5ZolIbaUhyZ7377VgLHqrq
BrXYTIB0m5obP0cQD2oMS5OrYnYZQSGzy8ngOaihygEmB1ySPl94poSA43+tUV48
Hz2jmy6U75FRngcdJ3W2+5JC3MsUOU8lj0ZcZNFHTm2DCJgiWHzo0rXOoN4JkfZl
wtA1J252Jpo=
=uiKy
-END PGP SIGNATURE-

Re: mainline boostrap comparison failure on i686-pc-linux-gnu with gcc 3.2.3 20030502 (Red Hat Linux 3.2.3-49)

[Diego Novillo]

On Thu, May 12, 2005 at 05:33:05PM -0700, H. J. Lu wrote:

> I got the same comparsion failure.
> 
Have you tried with Zdenek's patch to LSM that I approved earlier today?
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01150.html


Diego.

Re: Why doesn't operand_equal_p check pointer equality first?

[Daniel Berlin]

On Thu, 2005-05-12 at 18:20 -0600, Jeffrey A Law wrote:
> On Thu, 2005-05-12 at 15:37 -0700, Richard Henderson wrote:
> > On Thu, May 12, 2005 at 01:14:15PM -0400, Diego Novillo wrote:
> > > Am I missing something here?
> > 
> > Probably not.
> Isn't operand_equal_p used in situations where we're eliminating
> instructions -- and isn't the TREE_SIDE_EFFECT bit there to prevent
> us from doing things like elimianting calls, volatiles and the like?

Yes, but Diego's asking why it doesn't do the pointer equality  (when !
TREE_SIDE_EFFECTS) check  *first*, he's not talking about removing it.


Diego translator to the stars,
Dan

Stage2 Miscompilaton of Ada?

[Andreas Jaeger]

Yesterday I tried building gcc again for the first time since two
weeks and encountered what looks like an endless loop.

This command:
stage2/xgcc -Bstage2/ -B/opt/gcc/4.1-devel/x86_64-suse-linux-gnu/bin/ -c -g -O2
 -gnatpg -gnata -g -O1 -fno-inline \
 -I- -I. -Iada -I/cvs/gcc/gcc/ada /cvs/gcc/gcc/ada/a-except.adb -o ada/a-except.
o

was running for several hours.


Attaching gdb shows:

Attaching to program: /builds/gcc/misc/gcc/stage2/gnat1, process 32744
Reading symbols from /lib64/tls/libc.so.6...done.
Loaded symbols for /lib64/tls/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00469c53 in csets._elabb () at /cvs/gcc/gcc/ada/csets.adb:627
627Fold_IBM_PC_437 : constant Translate_Table := Translate_Table'(

If I let it run for some time, it still shows:
(gdb) c
Continuing.

Program received signal SIGINT, Interrupt.
x00469c53 in csets._elabb () at /cvs/gcc/gcc/ada/csets.adb:627
627Fold_IBM_PC_437 : constant Translate_Table := Translate_Table'(
(gdb) bt
#0  0x00469c53 in csets._elabb () at /cvs/gcc/gcc/ada/csets.adb:627
#1  0x00403935 in adainit () at b_gnat1.c:327
#2  0x0041b478 in gnat_parse_file (set_yydebug=)
at /cvs/gcc/gcc/ada/misc.c:240
#3  0x00ad9238 in toplev_main (argc=, argv=0x0)
at /cvs/gcc/gcc/toplev.c:1000
#4  0x2abde54a in __libc_start_main () from /lib64/tls/libc.so.6
#5  0x00402dfa in _start () at start.S:113


This is with current GCC mainline and happens on both Linux/x86-64
and Linux/PowerPC for me.

Anybody with the same problem?  

I'll do a binary search now to figure out which patch broke this,
Andreas
-- 
 Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


pgpoaIjs17Sfl.pgp
Description: PGP signature