[Bug ada/28591] [4.2 regression] ICE in splice_child_die, at dwarf2out.c:5513

[ebotcazou at gcc dot gnu dot org]

--- Comment #1 from ebotcazou at gcc dot gnu dot org  2006-08-06 07:02 
---
Known problem.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-08-06 07:02:35
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28591

[Bug rtl-optimization/28618] The scheduler extends the lifetime of CLASS_LIKELY_SPILLED registers

[amylaar at gcc dot gnu dot org]

--- Comment #6 from amylaar at gcc dot gnu dot org  2006-08-06 07:22 ---
(In reply to comment #1)
> The scheduler should not know anything about if a register is likely to spill
> or not, that is the job of the RA.

CLASS_LIKELY_SPIULLED is special because there is simply no way for reload to
fix this up when a single-register class is overcommitted, unless you want
to add code to reload to be able to undo any code transformation that the
optimizers are capable of, which would also include the analysis to see what is
possible - that would be more expensive then running all the optimizers. 
Therefore, there is a convention that the lifetime of CLASS_LIKELY_SPILLED
registers must not be extended - just like you may not move a cc0_setter from a
cc0_user, or a function call from the return value copy.
Note that there is some half-hearted code in sched-rgn.c whcih preserves
cc0_setter / cc0_user pairs, call/return value copies, and CLASS_LIKELY_SPILLED
registers, but only if they appear at the end of the basic block.
For cc0 there is already the more thorough code in sched-deps.c, but it was
missing for CLASS_LIKELY_SPILLED.

A historical note: the code to preserve CLASS_LIKELY_SPILLED registers
originally applied to all hard registers, but only on targets that defined the
SMALL_REGISTER_CLASSES target macro.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28618

[Bug rtl-optimization/28618] The scheduler extends the lifetime of CLASS_LIKELY_SPILLED registers

[amylaar at gcc dot gnu dot org]

--- Comment #7 from amylaar at gcc dot gnu dot org  2006-08-06 07:24 ---
(In reply to comment #5)
> Also one comment about your patch for soft-fp:
> +  /* Wrap the sequence in REG_LIBCALL / REG_RETVAL notes so that loop
> + invariant code motion can move it.  */
> 
> The tree level loop invariant motion should have moved it already.  Why use
> LIBCALL here when we are already trying to remove it?

That bit is from 2004.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28618

[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch

[skunk at iskunk dot org]

--- Comment #8 from skunk at iskunk dot org  2006-08-06 07:26 ---
(In reply to comment #7)
> You cannot expect that to work.  You're trying to bootstrap a 32-bit compiler
> (sparc-sun-solaris2.8) with a 64-bit compiler (cc -xarch=v9).  Unsupported.

No, I'm trying to build a 64-bit GCC using cc in 64-bit mode (as per CFLAGS) on
a 64-bit system. Nothing fancy here.

You don't pass compiler flags in CC. That's what CFLAGS is for. Let me refocus
the issue: It is a bug for genmodes et al. in GCC's stage 1 to have been built
without CFLAGS. Is there any reason for this not to be the case?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515

[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch

[ebotcazou at gcc dot gnu dot org]

--- Comment #9 from ebotcazou at gcc dot gnu dot org  2006-08-06 07:34 
---
> No, I'm trying to build a 64-bit GCC using cc in 64-bit mode (as per CFLAGS) 
> on
> a 64-bit system. Nothing fancy here.

Sure, but you're not using the correct procedure.  Use the first I posted.

> You don't pass compiler flags in CC. That's what CFLAGS is for.

You do for GCC.  Tweaking CFLAGS for a bootstrap is a recipe for disaster.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515

[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch

[schwab at suse dot de]

--- Comment #10 from schwab at suse dot de  2006-08-06 08:01 ---
(In reply to comment #8)
> You don't pass compiler flags in CC. That's what CFLAGS is for.

Passing -xarch=v9 to the compiler makes it a different compiler in essence, one
that creates object files that are incompatible with the output of the default
compiler.  It also changes the operation of the linker.  That makes the flag
quite different from other compiler flags.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515

[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch

[skunk at iskunk dot org]

--- Comment #11 from skunk at iskunk dot org  2006-08-06 08:09 ---
(In reply to comment #9)
> You do for GCC.  Tweaking CFLAGS for a bootstrap is a recipe for disaster.

How is it any worse than having those flags in CC? CC and CFLAGS are always
supposed to be used together anyway---the only difference with what you're
describing is that this follows the standard variable convention. (And surely
you're not implying that CFLAGS is supposed to be passed to xgcc or some other
stage, instead of BOOT_CFLAGS or similar?)

To say nothing of the issue of consistency: If CFLAGS is so bad, why is
libiberty built using it?

I understand that things are necessarily complicated in GCC's build system,
that you can have up to three (four?) different compilers and associated
options, etc. etc. No problem with that. What I don't understand is why, in the
simplest ("degenerate") case of bootstrapping a compiler on the target system,
I can't just blithely set CC+CFLAGS and have it work in the expected way.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515

[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch

[skunk at iskunk dot org]

--- Comment #12 from skunk at iskunk dot org  2006-08-06 08:32 ---
(In reply to comment #10)
> Passing -xarch=v9 to the compiler makes it a different compiler in essence, 
> one
> that creates object files that are incompatible with the output of the default
> compiler.  It also changes the operation of the linker.  That makes the flag
> quite different from other compiler flags.

That's a fairly slippery slope. Does -KPIC/-fPIC/etc. make cc a different
compiler? -g/-O? -g/-pg? (Yes, the linker might be able to handle those
combinations, but you may end up with a Frankenbinary that fails unpredictably
at run-time.) Where do you draw the line?

That's beside the point, even. "$CC $CFLAGS" may produce something incompatible
with "$CC" alone---and yes, it is as if the two are completely different
compilers---but ***why*** are you using CC alone, without CFLAGS, in the first
place? Can someone please explain this to me?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515

[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch

[ebotcazou at gcc dot gnu dot org]

--- Comment #13 from ebotcazou at gcc dot gnu dot org  2006-08-06 08:46 
---
> How is it any worse than having those flags in CC? CC and CFLAGS are always
> supposed to be used together anyway---the only difference with what you're
> describing is that this follows the standard variable convention. (And surely
> you're not implying that CFLAGS is supposed to be passed to xgcc or some other
> stage, instead of BOOT_CFLAGS or similar?)

It's worse because tweaking CFLAGS makes you think you can do whatever you
want with it.  You cannot, as explained by Andreas.

> I understand that things are necessarily complicated in GCC's build system,
> that you can have up to three (four?) different compilers and associated
> options, etc. etc. No problem with that. What I don't understand is why, in
> the simplest ("degenerate") case of bootstrapping a compiler on the target
> system, I can't just blithely set CC+CFLAGS and have it work in the expected
> way.

You're precisely *not* bootstrapping a compiler on the target system, you're
building a 32-bit compiler (sparc-sun-solaris2.8) by starting with a 64-bit
one.  This is a cross-compilation.  You cannot use a bootstrap in that case.

I guess it's not what you intended, that's why tweaking CFLAGS is dangerous.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515

[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch

[ebotcazou at gcc dot gnu dot org]

--- Comment #14 from ebotcazou at gcc dot gnu dot org  2006-08-06 08:48 
---
> That's a fairly slippery slope. Does -KPIC/-fPIC/etc. make cc a different
> compiler? -g/-O? -g/-pg? (Yes, the linker might be able to handle those
> combinations, but you may end up with a Frankenbinary that fails unpredictably
> at run-time.) Where do you draw the line?

At the ABI level.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515

[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch

[skunk at iskunk dot org]

--- Comment #15 from skunk at iskunk dot org  2006-08-06 09:44 ---
(In reply to comment #13)
> It's worse because tweaking CFLAGS makes you think you can do whatever you
> want with it.  You cannot, as explained by Andreas.

Per Andreas, the "cannot" part stems directly from using CC alone (a.k.a. "the
default compiler"), which is the bug at issue.

If tweaking CFLAGS makes me think bad thoughts, then the caveats should be
noted in the build docs, instead of the variable behavior being purposely
broken. (**None** of what you're saying is currently in the docs, so far as I
can see.) If users ignoring docs is a problem, then do as the MPlayer folks do
and have the configure script print a big fat warning if it detects anything
unwholesome.

> You're precisely *not* bootstrapping a compiler on the target system, you're
> building a 32-bit compiler (sparc-sun-solaris2.8) by starting with a 64-bit
> one.  This is a cross-compilation.  You cannot use a bootstrap in that case.
> 
> I guess it's not what you intended, that's why tweaking CFLAGS is dangerous.

So you're saying that CC and the target triplet have to agree, ABI-wise?
Because that would be an issue, in my case---but it's still orthogonal to the
problem of using CC sans CFLAGS. (Here, the resolution would be that I have to
specify the sparc64 triplet explictly, presumably because config.guess returns
the 32-bit triplet irrespective of the system being 64-bit.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515

[Bug c++/28620] New: [4.1 regression] static const member in template class leads to multiple definitions at linktime

[tausq at debian dot org]

with the attached testcase, during linking you get:
test2.o:(.data+0x0): multiple definition of `_ZN3BadIT_E2_yE'
test1.o:(.data+0x0): first defined here

this comes from a template class:
template 
class Bad {
static const int _y;
};

template  const int Bad::_y = 1023;

although this seems like a generic c++ problem, it was only observed on
hppa-linux and not on other platforms.

this test was simplified from a failure reported in building the quantlib
package against g++-4.1. With earlier g++ versions the package builds fine.


-- 
   Summary: [4.1 regression] static const member in template class
leads to multiple definitions at linktime
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tausq at debian dot org
 GCC build triplet: hppa-unknown-linux
  GCC host triplet: hppa-unknown-linux
GCC target triplet: hppa-unknown-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28620

[Bug c++/28620] [4.1 regression] static const member in template class leads to multiple definitions at linktime

[tausq at debian dot org]

--- Comment #1 from tausq at debian dot org  2006-08-06 10:07 ---
Created an attachment (id=12026)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12026&action=view)
testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28620

[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch

[ebotcazou at gcc dot gnu dot org]

--- Comment #16 from ebotcazou at gcc dot gnu dot org  2006-08-06 10:59 
---
> (**None** of what you're saying is currently in the docs, so far as I can
> see.)

Take a look at http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2

> If users ignoring docs is a problem, then do as the MPlayer folks do and
> have the configure script print a big fat warning if it detects anything
> unwholesome.

This would be a lot of work for GCC!

> So you're saying that CC and the target triplet have to agree, ABI-wise?

If you want to do a bootstrap, yes.  Otherwise this is a cross-compilation and
a bootstrap will miserably fail like in your case.

> Because that would be an issue, in my case---but it's still orthogonal to the
> problem of using CC sans CFLAGS. (Here, the resolution would be that I have to
> specify the sparc64 triplet explictly, presumably because config.guess returns
> the 32-bit triplet irrespective of the system being 64-bit.)

CC+CFLAGS and the --host parameter of configure must always be in keeping.
For a native compilation (hence a bootstrap), --target must additionally be.
So the safe procedure is to modify CC and not CFLAGS.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515

[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch

[ebotcazou at gcc dot gnu dot org]

--- Comment #17 from ebotcazou at gcc dot gnu dot org  2006-08-06 11:02 
---
> CC+CFLAGS and the --host parameter of configure must always be in keeping.

--build actually.

> For a native compilation (hence a bootstrap), --target must additionally be.

As well as --host.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515

[Bug debug/26827] "GNAT BUG DETECTED" on compile GPS 1.3.1/gtkada

[bonzini at gcc dot gnu dot org]

--- Comment #4 from bonzini at gnu dot org  2006-08-06 12:06 ---
Subject: Bug 26827

Author: bonzini
Date: Sun Aug  6 12:06:31 2006
New Revision: 115969

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115969
Log:
2006-08-06  Paolo Bonzini  <[EMAIL PROTECTED]>

PR target/26827
* config/i386/i386.md: Add peephole2 to avoid "fld %st"
instructions.

2006-08-06  Paolo Bonzini  <[EMAIL PROTECTED]>

PR target/26827
* gcc.target/i386/pr27827.c: New testcase.



Added:
trunk/gcc/testsuite/gcc.target/i386/pr27827.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26827

[Bug c++/28620] [4.1 regression] static const member in template class leads to multiple definitions at linktime

[tbm at gcc dot gnu dot org]

--- Comment #2 from tbm at gcc dot gnu dot org  2006-08-06 13:41 ---
This has been fixed already, both in GCC's SVN and in Debian's gcc-4.1 package.

The reason you see it on HPPA is that recent version of gcc-4.1 in Debian don't
build.  This bug was fixed in -9 but hppa still has -8.  Can you investigate
why recent gcc-4.1 in Debian doesn't compile on HPPA?

gcc-4.1 (4.1.1-9) unstable; urgency=low

  * Update to SVN 20060715.
- Fix PR c++/28016, do not emit uninstantiated static data members.
  Closes: #373895, #376871.


*** This bug has been marked as a duplicate of 28016 ***


-- 

tbm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28620

[Bug c++/28016] [4.1 Regression] emitting template constant

[tbm at gcc dot gnu dot org]

--- Comment #16 from tbm at gcc dot gnu dot org  2006-08-06 13:41 ---
*** Bug 28620 has been marked as a duplicate of this bug. ***


-- 

tbm at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tausq at debian dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28016

[Bug debug/26827] "GNAT BUG DETECTED" on compile GPS 1.3.1/gtkada

[tbm at gcc dot gnu dot org]

--- Comment #5 from tbm at gcc dot gnu dot org  2006-08-06 14:23 ---
(In reply to comment #4)
> Subject: Bug 26827
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115969
> Log:
> 2006-08-06  Paolo Bonzini  <[EMAIL PROTECTED]>
> 
> PR target/26827
> * config/i386/i386.md: Add peephole2 to avoid "fld %st"
> instructions.

This should have been 27827.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26827

[Bug libstdc++/16611] Terrible code generated for vector

[paolo at gcc dot gnu dot org]

--- Comment #11 from paolo at gcc dot gnu dot org  2006-08-06 14:45 ---
Subject: Bug 16611

Author: paolo
Date: Sun Aug  6 14:45:04 2006
New Revision: 115972

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115972
Log:
2006-08-06  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/16611
* include/bits/stl_bvector.h (vector::operator[],
vector::operator[] const): Do not use iterator::operator+,
hand code.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_bvector.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16611

[Bug libstdc++/16611] Terrible code generated for vector

[pcarlini at suse dot de]

--- Comment #12 from pcarlini at suse dot de  2006-08-06 14:47 ---
Now I get:

 <_Z1fRKSt6vectorIbSaIbEEj>:
   0:   55  push   %ebp
   1:   89 e5   mov%esp,%ebp
   3:   8b 45 08mov0x8(%ebp),%eax
   6:   8b 4d 0cmov0xc(%ebp),%ecx
   9:   53  push   %ebx
   a:   8b 10   mov(%eax),%edx
   c:   b8 01 00 00 00  mov$0x1,%eax
  11:   89 cb   mov%ecx,%ebx
  13:   83 e1 1fand$0x1f,%ecx
  16:   c1 eb 05shr$0x5,%ebx
  19:   d3 e0   shl%cl,%eax
  1b:   85 04 9atest   %eax,(%edx,%ebx,4)
  1e:   5b  pop%ebx
  1f:   5d  pop%ebp
  20:   0f 95 c0setne  %al
  23:   0f b6 c0movzbl %al,%eax
  26:   c3  ret

I guess we can close the library issue.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16611

[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3

[whaley at cs dot utsa dot edu]

--- Comment #36 from whaley at cs dot utsa dot edu  2006-08-06 15:03 ---
Paola,

Thanks for working on this.  We are making progres, but I have some mixed
results.  I timed the assemblies you provided directly.  I added a target
"asgexe" that builds the same benchmark, assuming assembly source instead of C
to make this more reproducable.  I ran on the Athlon-64X2, where your new
assembly ran *faster* than gcc 3 for double precision.  However, you still lost
for single precision.  I believe the reason is that you still have more
fmuls/fmull (fmul from memory) than does gcc 3:

>animal>fgrep -i fmuls smm_4.s | wc
>240 4804051
>animal>fgrep -i fmuls smm_asg.s | wc
> 60 1201020
>animal>fgrep -i fmuls smm_3.s  | wc
>  0   0   0
>animal>fgrep -i fmull dmm_4.s | wc
>100 2001739
>animal>fgrep -i fmull dmm_asg.s | wc
> 20  40 360
>animal>fgrep -i fmuls dmm_3.s | wc
>  0   0   0


I haven't really scoped out the dmm diff, but in single prec anyway, these
dreaded fmuls are in the inner loop, and this is probably why you are still
losing.  I'm guessing your peephole is missing some cases, and for some reason
is missing more under single.  Any ideas?

As for your assembly actually beating gcc 3 for double, my guess is that it is
some other optimization that gcc 4 has, and you will beat by even more once the
final fmull are removed . . .

On the P4e, your double precision code is faster than stock gcc 4, but still
slower than gcc3.  again, I suspect the remaining fmull.  Then comes the thing
I cannot explain at all.  Your single precision results are horrible.  gcc 3
gets 1991MFLOPS, gcc 4 gets 1664, and the assembly you sent gets 34!  No chance
the mixed fld/fmuls is causing stack overflow, I guess?  I think this might
account for such a catastrophic drop  . . .  That's about the only WAG I've got
for this behavior.

Anyway, I think the first order of business may be to get your peephole to
grabbing all the cases, and see if that makes you win everywhere on Athlon, and
if it makes single precision P4e better, and we can go from there . . .

If you do that, attach the assemblies  again, and I'll redo timings.  Also, if
you could attach (not put in comment) the patch, it'd be nice to get the
compiler, so I could test x86-64 code on Athlon, etc.

Thanks,
Clint


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827

[Bug c/28621] New: SEGSEGV at set_fast_math () at ../../gcc/config/i386/crtfastmath.c:97 when using the -Os flag

[magsilva at gmail dot com]

After build a new version of procps using the "-Os" flag for gcc, all its
(procps) software (ps, top, etc) were failing due to a segmentation fault. I
couldn't find a report about that at Bugzilla, but I did find one at
"http://www.netdomination.org/~stkn/index.php?/archives/24-Anatomy-of-a-segfaulthtml";.
Although the author of that report was using ulibc (and I glibc), it applied
perfectly to my case. After I removed the "-ffast-math" from the procps compile
command, everything worked fine again.


-- 
   Summary: SEGSEGV at set_fast_math () at
../../gcc/config/i386/crtfastmath.c:97 when using the -
Os flag
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: magsilva at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28621

[Bug target/28621] [4.1/4.2 Regression] SEGSEGV at set_fast_math () at ../../gcc/config/i386/crtfastmath.c:97 when using the -Os flag

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |target
Summary|SEGSEGV at set_fast_math () |[4.1/4.2 Regression] SEGSEGV
   |at  |at set_fast_math () at
   |../../gcc/config/i386/crtfas|../../gcc/config/i386/crtfas
   |tmath.c:97 when using the - |tmath.c:97 when using the -
   |Os flag |Os flag
   Target Milestone|--- |4.1.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28621

[Bug target/28621] [4.1/4.2 Regression] SEGSEGV at set_fast_math () at ../../gcc/config/i386/crtfastmath.c:97 when using the -Os flag

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-08-06 17:19 ---
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01179.html


Caused by the patch at:
http://gcc.gnu.org/ml/gcc/2005-08/msg00281.html


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hjl at gcc dot gnu dot org
   Severity|normal  |blocker
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-08-06 17:19:06
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28621

[Bug target/28622] New: [4.1 regression] ICE in extract_insn, at recog.c:2084 (unecognizable insn)

[tbm at cyrius dot com]

We get the following ICE on m68k with gcc 4.1.  I checked today's SVN and 4.1
fails while 4.2 works.

(sid)34:[EMAIL PROTECTED]: ~] /usr/local/bin/m68k-linux-gnu-gcc-4.1.2 -c -O
kdelibs-slaveinterface.cpp
kdelibs-slaveinterface.cpp: In function ‘QDataStream&
operator<<(QDataStream&, const KIO::UDSEntry&)’:
kdelibs-slaveinterface.cpp:62: error: unrecognizable insn:
(insn 23 21 25 1 (set (mem/s/j/c:DI (plus:SI (reg/f:SI 26 virtual-stack-vars)
(const_int -8 [0xfff8])) [0 a.m_long+0 S8 A16])
(ashiftrt:DI (mem/s/j:DI (plus:SI (reg:SI 31 [ D.1850 ])
(const_int 2 [0x2])) [0 .m_long+0 S8 A16])
(const_int 32 [0x20]))) -1 (nil)
(nil))
kdelibs-slaveinterface.cpp:62: internal compiler error: in extract_insn, at
recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
(sid)35:[EMAIL PROTECTED]: ~] /usr/local/bin/m68k-linux-gnu-gcc-4.1.2 -c
kdelibs-slaveinterface.cpp
(sid)36:[EMAIL PROTECTED]: ~] /usr/local/bin/m68k-linux-gnu-gcc-4.2.0 -c -O2
kdelibs-slaveinterface.cpp
(sid)37:[EMAIL PROTECTED]: ~]


-- 
   Summary: [4.1 regression] ICE in extract_insn, at recog.c:2084
(unecognizable insn)
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
  GCC host triplet: m68k-linux-gnu
GCC target triplet: m68k-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28622

[Bug target/28622] [4.1 regression] ICE in extract_insn, at recog.c:2084 (unecognizable insn)

[tbm at cyrius dot com]

--- Comment #1 from tbm at cyrius dot com  2006-08-06 17:50 ---
Created an attachment (id=12027)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12027&action=view)
test case

Testcase from application "kdelibs".


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28622

[Bug target/28623] New: [4.1/4.2 regression] ICE in extract_insn, at recog.c:2077 (nrecognizable insn) [alpha]

[tbm at cyrius dot com]

We get the following ICE on alpha with 4.1 and 4.2.  gcc 4.0 works.

[EMAIL PROTECTED]:~$ gcc-4.1 -c -O kdegraphics-gstring.cpp
kdegraphics-gstring.cpp: In member function 'GP
GStringRep::vformat(va_list) const':
kdegraphics-gstring.cpp:57: error: unrecognizable insn:
(insn 15 10 16 0 (set (reg:DI 73)
(plus:DI (reg/v/f:DI 69 [ buffer ])
(const_int 32768 [0x8000]))) -1 (nil)
(nil))
kdegraphics-gstring.cpp:57: internal compiler error: in extract_insn, at
recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
Preprocessed source stored into /tmp/ccG6Sh3U.out file, please attach this to
your bugreport.
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/g++ -c -O kdegraphics-gstring.cpp
kdegraphics-gstring.cpp: In member function 'GP
GStringRep::vformat(va_list) const':
kdegraphics-gstring.cpp:57: error: unrecognizable insn:
(insn 14 10 15 2 (set (reg:DI 73)
(plus:DI (reg/v/f:DI 69 [ buffer ])
(const_int 32768 [0x8000]))) -1 (nil)
(nil))
kdegraphics-gstring.cpp:57: internal compiler error: in extract_insn, at
recog.c:2077
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
[EMAIL PROTECTED]:~$ gcc-4.0 -c -O kdegraphics-gstring.cpp
[EMAIL PROTECTED]:~$


-- 
   Summary: [4.1/4.2 regression] ICE in extract_insn, at
recog.c:2077 (nrecognizable insn) [alpha]
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
  GCC host triplet: alpha-linux-gnu
GCC target triplet: alpha-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28623

[Bug bootstrap/28615] cross-compile uses host cpp to determine features

[freyther at inf dot fu-berlin dot de]

--- Comment #2 from freyther at inf dot fu-berlin dot de  2006-08-06 17:54 
---
Created an attachment (id=12028)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12028&action=view)
Same as 12022 but for gcc4.1.1


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28615

[Bug target/28623] [4.1/4.2 regression] ICE in extract_insn, at recog.c:2077 (nrecognizable insn) [alpha]

[tbm at cyrius dot com]

--- Comment #1 from tbm at cyrius dot com  2006-08-06 17:55 ---
Created an attachment (id=12029)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12029&action=view)
test case

Testcase from application "kdegraphics".


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28623

[Bug target/28621] [4.1/4.2 Regression] SEGSEGV at set_fast_math () at ../../gcc/config/i386/crtfastmath.c:97 when using the -Os flag

[hjl at lucon dot org]

--- Comment #2 from hjl at lucon dot org  2006-08-06 18:29 ---
The main problem is bug 27537. That is -Os aligns stack at 4 bytes and the
other
part of i386 backend assumes stack aliged at 16byte. We can word around this by

1. Don't include crtfastmath.o for -m32.
2. Make crtfastmath.o dummy for -m32.
3. Use a static variable to align at 16byte.
4. Compile crtfastmath.o with -mstackrealign. Need to backport -mstackrealign
to
4.1?
5. Fix i386 backend only to assume 4byte stack alignment.

The easiest one is #2 or #3. The idel one is #5.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28621

[Bug fortran/28425] Derived type initialization via a derived type is broken

[patchapp at dberlin dot org]

--- Comment #3 from patchapp at dberlin dot org  2006-08-06 18:35 ---
Subject: Bug number PR28425

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00152.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28425

[Bug tree-optimization/28624] New: [4.2 regression] latent segfault in remove_phi_node

[tbm at cyrius dot com]

I got a segfault with a recent version of gcc 4.2 on x86_64.  It has gone away
recently but after investigating when it was introduced and fixed I got the
impression that this is a latent problem.

With the attached testcase, I can reproduce this segfault starting with r115200
until r115711.  As far as I can tell, neither of those changes are related so I
think the problem is latent.

(sid)585:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O2 fityk-ast.ii
/usr/include/boost/spirit/core/impl/parser.ipp: In function
'boost::spirit::parse_info boost::spirit::parse(const CharT*,
const boost::spirit::parser&) [with CharT = char, DerivedT =
boost::spirit::sequence,
boost::spirit::contiguous,
boost::spirit::action, boost::spirit::ref_value_actor > > > >]':
/usr/include/boost/spirit/core/impl/parser.ipp:40: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
zsh: exit 1 /usr/lib/gcc-snapshot/bin/g++ -c -O2 fityk-ast.ii
(sid)586:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O1 fityk-ast.ii
(sid)587:[EMAIL PROTECTED]: ~]


-- 
   Summary: [4.2 regression] latent segfault in remove_phi_node
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28624

[Bug libgcj/28625] New: FAIL: PR7482 -O3 output - source compiled test

[danglin at gcc dot gnu dot org]

set_ld_library_path_env_vars:
ld_library_path=.:/mnt/gnu/gcc/objdir/hppa2.0w-hp-
hpux11.11/./libjava/.libs
Executing on host:
/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/.
./libtool --silent --tag=GCJ --mode=link /mnt/gnu/gcc/objdir/gcc/gcj
-B/mnt/gnu/
gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/ -B/mnt/gnu/gcc/objdir/gcc/
--encoding=
UTF-8 -B/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/../
/mnt/gnu
/gcc/gcc/libjava/testsuite/libjava.lang/PR7482.java   -no-install --main=PR7482
-O3 -g  -L/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs -lm   -o
/mn
t/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/PR7482.exe(timeout
= 300)
PASS: PR7482 -O3 compilation from source
set_ld_library_path_env_vars:
ld_library_path=.:/mnt/gnu/gcc/objdir/hppa2.0w-hp-
hpux11.11/./libjava/.libs
Setting LD_LIBRARY_PATH to
.:/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava
/.libs:.:/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs:.:/mnt/gnu/gc
c/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs
/usr/lib/dld.sl: Filename passed is Null.
/usr/lib/dld.sl: No such file or directory
PASS: PR7482 -O3 execution - source compiled test
FAIL: PR7482 -O3 output - source compiled test

This might be a testsuite issue as I can't duplicate the problem running
the test manually.  I'm also seeing dynamic loader wierdness running on a
SMP hppa-unknown-linux-gnu target:

set_ld_library_path_env_vars:
ld_library_path=.:/home/dave/gcc-4.2/objdir/hppa-l
inux/./libjava/.libs:/home/dave/gcc-4.2/objdir/gcc
Executing on host:
/home/dave/gcc-4.2/objdir/hppa-linux/libjava/testsuite/../lib
tool --silent --tag=GCJ --mode=link /home/dave/gcc-4.2/objdir/gcc/gcj
-B/home/da
ve/gcc-4.2/objdir/hppa-linux/libjava/ -B/home/dave/gcc-4.2/objdir/gcc/
--encodin
g=UTF-8 -B/home/dave/gcc-4.2/objdir/hppa-linux/libjava/testsuite/../
/home/dave/
gcc-4.2/gcc/libjava/testsuite/libjava.lang/PR3096.java   -no-install
--main=PR30
96 -g  -L/home/dave/gcc-4.2/objdir/hppa-linux/./libjava/.libs -lm   -o
/home/dav
e/gcc-4.2/objdir/hppa-linux/libjava/testsuite/PR3096.exe(timeout = 300)
/bin/sh: symbol lookup error: /bin/sh: undefined symbol: execve, version
libtool: ignoring unknown tag
output is:
/bin/sh: symbol lookup error: /bin/sh: undefined symbol: execve, version
libtool: ignoring unknown tag

FAIL: PR3096 compilation from source
UNTESTED: PR3096 execution from source compiled test
UNTESTED: PR3096 output from source compiled test

The tests that fail due to the execve lookup problem vary from run to run.


-- 
   Summary: FAIL: PR7482 -O3 output - source compiled test
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa2.0w-hp-hpux11.11
  GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28625

[Bug tree-optimization/28624] [4.2 regression] latent segfault in remove_phi_node

[tbm at cyrius dot com]

--- Comment #1 from tbm at cyrius dot com  2006-08-06 18:38 ---
Created an attachment (id=12030)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12030&action=view)
test case

Preprocessed source from application "fityk".


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28624

[Bug tree-optimization/28624] [4.2 regression] latent segfault in remove_phi_node

[tbm at cyrius dot com]

--- Comment #2 from tbm at cyrius dot com  2006-08-06 18:39 ---
Program received signal SIGSEGV, Segmentation fault.
remove_phi_node (phi=0x2ace1982f900, prev=0x0) at gcc/tree-phinodes.c:458
458loc = &PHI_CHAIN (*loc))
(gdb) where
#0  remove_phi_node (phi=0x2ace1982f900, prev=0x0)
at gcc/tree-phinodes.c:458
#1  0x0059fd57 in remove_stmt_or_phi (t=0x0)
at gcc/tree-ssa-dom.c:2086
#2  0x005a5af8 in eliminate_degenerate_phis ()
at gcc/tree-ssa-dom.c:2486
#3  0x0089568c in execute_one_pass (pass=0xd370b0)
at gcc/passes.c:864
#4  0x008957fc in execute_pass_list (pass=0xd370b0)
at gcc/passes.c:911
#5  0x0089580e in execute_pass_list (pass=0xc77d60)
at gcc/passes.c:912
#6  0x0055ebda in tree_rest_of_compilation (fndecl=0x2ace195b6540)
at gcc/tree-optimize.c:418
#7  0x004d3a18 in expand_body (fn=0x2ace195b6540)
at gcc/cp/semantics.c:3069
#8  0x008e5a86 in cgraph_expand_function (node=0x2ace199900b0)
at gcc/cgraphunit.c:1186
#9  0x008e8274 in cgraph_optimize () at gcc/cgraphunit.c:1251
#10 0x0048013a in cp_finish_file () at gcc/cp/decl2.c:3344
#11 0x0053307a in c_common_parse_file (set_yydebug=)
at gcc/c-opts.c:1165
#12 0x00866b43 in toplev_main (argc=, argv=)
at gcc/toplev.c:999
#13 0x2ace156224ca in __libc_start_main () from /lib/libc.so.6
#14 0x0040273a in _start () at ../sysdeps/x86_64/elf/start.S:113
(gdb)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28624

[Bug libgcj/28626] New: FAIL: Thread_Join execution - gij test

[danglin at gcc dot gnu dot org]

byte compile: /mnt/gnu/gcc/objdir/gcc/gcj
-B/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux
11.11/libjava/ -B/mnt/gnu/gcc/objdir/gcc/ --encoding=UTF-8 -C
-I/mnt/gnu/gcc/obj
dir/hppa2.0w-hp-hpux11.11/libjava/testsuite/../libgcj-4.2.0.jar -g
/mnt/gnu/gcc/
gcc/libjava/testsuite/libjava.lang/Thread_Join.java -d
/mnt/gnu/gcc/objdir/hppa2
.0w-hp-hpux11.11/libjava/testsuite 2>@ stdout
PASS: Thread_Join byte compilation
Thread_Join
Sleeper Joiner Thread_Join
set_ld_library_path_env_vars:
ld_library_path=.:/mnt/gnu/gcc/objdir/hppa2.0w-hp-
hpux11.11/./libjava/.libs
Setting LD_LIBRARY_PATH to
.:/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava
/.libs:.:/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs:.:/mnt/gnu/gc
c/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs
sleeping
done
ok
ok
ok
ok
ok
Exception in thread "Thread-3" ok
ok
ok
ok
java.lang.NullPointerException
   at java.lang.ClassLoader.loadClass(libgcj.sl.7)
   at java.lang.ClassLoader.loadClass(libgcj.sl.7)
   at Joiner.run(Thread_Join.java:45)
   at java.lang.Thread.run(libgcj.sl.7)
FAIL: Thread_Join execution - gij test
UNTESTED: Thread_Join output - gij test

I'm unable to duplicate running the test manually:

# ../gij Thread_Join
sleeping
done
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok


-- 
   Summary: FAIL: Thread_Join execution - gij test
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa2.0w-hp-hpux11.11
  GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28626

[Bug rtl-optimization/27616] [4.1/4.2 Regression] Internal error with -O1 (CSE)

[ebotcazou at gcc dot gnu dot org]

--- Comment #10 from ebotcazou at gcc dot gnu dot org  2006-08-06 20:15 
---
Investigating.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-05-15 15:53:09 |2006-08-06 20:15:17
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27616

[Bug target/28627] New: [cygwin/mingw32] Missing dllimport diagnostic

[dannysmith at users dot sourceforge dot net]

This change caused a new testsuite regression on windows32 targets 

2006-08-01  Volker Reichelt  <[EMAIL PROTECTED]>

PR c++/28250
PR c++/28257
PR c++/28259
PR c++/28267
* toplev.c (compile_file): Return early on errorcount or sorrycount.
* cgraphunit.c (cgraph_finalize_compilation_unit): Likewise.
(cgraph_optimize): Likewise.

Here:
FAIL: g++.dg/ext/dllimport7.C C++ specific error (test for errors, line 24)

(see eg: 

The testcase expects error messages for each of two static data members
that are declared in a dllimport'd class and later defined out of class.


const int Bar::three = 3;   //  { dg-warning "redeclared without dllimport"
}
//  { dg-error "definition of static data" "C++ specific error" { target
i?86-*-cygwin* i?86-*-mingw* } 21 }

const Baz Bar::null_baz;// { dg-warning "redeclared without dllimport"
}
// { dg-error "definition of static data" "C++ specific error" { target
i?86-*-cygwin* i?86-*-mingw* } 24 } 


only the first "C++-specific error" is emitted, Once errorcount > 0, no
more errors are reported.

Commenting out the early return on errorcount in cgraph_optimize()
restores the expected error message at line 24

The error messages are emitted by winnt-cxx.c:i386_pe_type_dllimport_p(),
a helper routine for targetm.encode_section_info.

Changing the errors to warnings, I get all the messages. The reason they
are errors, rather than warnings is because (1) native MS compiler calls
the definition of a static data member of a dllimport'd class an error and
(2) they usually indicate a silly dll[/im/ex/]port typo in the class
definition or a serious misunderstanding of dllimport semantics.

Danny


-- 
   Summary: [cygwin/mingw32] Missing dllimport  diagnostic
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: dannysmith at users dot sourceforge dot net
ReportedBy: dannysmith at users dot sourceforge dot net
 GCC build triplet: i386-pc-mingw32
  GCC host triplet: i386-pc-mingw32
GCC target triplet: i386-pc-mingw32


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28627

[Bug libgcj/28579] [ecj] classpath build must use gcj

[tromey at gcc dot gnu dot org]

-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-08-06 21:14:27
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28579

[Bug libgcj/28491] NetworkInterface.getNetworkInterfaces() doesn't report ipv6 interfaces.

[tromey at gcc dot gnu dot org]

-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-08-06 21:35:24
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28491

[Bug libgcj/28576] PlainDatagramSocketImpl::connect: not implemented yet

[tromey at gcc dot gnu dot org]

--- Comment #1 from tromey at gcc dot gnu dot org  2006-08-06 21:35 ---
I'm testing a patch.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tromey at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-08-06 21:35:42
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28576

[Bug libgcj/28576] PlainDatagramSocketImpl::connect: not implemented yet

[tromey at gcc dot gnu dot org]

--- Comment #2 from tromey at gcc dot gnu dot org  2006-08-06 21:52 ---
Subject: Bug 28576

Author: tromey
Date: Sun Aug  6 21:52:04 2006
New Revision: 115976

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115976
Log:
PR libgcj/28576:
* gnu/java/net/natPlainDatagramSocketImplPosix.cc (connect):
Implemented.
(disconnect): Likewise.
(send): Handle already-connected case.

Modified:
trunk/libjava/ChangeLog
trunk/libjava/gnu/java/net/natPlainDatagramSocketImplPosix.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28576

[Bug libgcj/28576] PlainDatagramSocketImpl::connect: not implemented yet

[tromey at gcc dot gnu dot org]

--- Comment #3 from tromey at gcc dot gnu dot org  2006-08-06 21:52 ---
Fix checked in.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28576

[Bug c++/28573] [4.0/4.1/4.2 Regression] incorrectly allowing non-constant expression to offsetof()

[bangerth at dealii dot org]

--- Comment #1 from bangerth at dealii dot org  2006-08-06 22:12 ---
For some reason, this also passes icc. Interestingly, it isn't even the
case that offsetof manages to look through operator[] -- removing the
body of operator[] doesn't affect the result.

W.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-08-06 22:12:50
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28573

[Bug c++/27787] Qualified lookup fails to find inherited class template

[bangerth at dealii dot org]

--- Comment #5 from bangerth at dealii dot org  2006-08-06 22:16 ---
Confirmed. I'm sure this is a duplicate of some other PR, but I don't
know which one right now...

W.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||rejects-valid
  Known to fail||3.4.3 4.1.0
  Known to work||2.95.3 3.2.3
   Last reconfirmed|-00-00 00:00:00 |2006-08-06 22:16:30
   date||
   Target Milestone|--- |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27787

[Bug c++/27775] incorrect "ambiguous" error message with multiple inheritance and nested class.

[bangerth at dealii dot org]

--- Comment #1 from bangerth at dealii dot org  2006-08-06 22:19 ---
Confirmed. To make things worse, the diagnostic is really longish
right now as well:

g/x> c++ -c x.cc
x.cc:10: error: reference to 'B' is ambiguous
x.cc:4: error: candidates are: struct A::B
x.cc:4: error: struct A::B
x.cc:10: error: reference to 'B' is ambiguous
x.cc:4: error: candidates are: struct A::B
x.cc:4: error: struct A::B
x.cc:10: error: 'B' has not been declared
x.cc:11: error: reference to 'B' is ambiguous
x.cc:4: error: candidates are: struct A::B
x.cc:4: error: struct A::B
x.cc:11: error: reference to 'B' is ambiguous
x.cc:4: error: candidates are: struct A::B
x.cc:4: error: struct A::B
x.cc:11: error: 'B' has not been declared

The 'is ambiguous' message is apparently printed twice, and the 'has not 
been declared' message is, and has long been, bogus...

W.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-08-06 22:19:48
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27775

[Bug libgcj/28491] NetworkInterface.getNetworkInterfaces() doesn't report ipv6 interfaces.

[tromey at gcc dot gnu dot org]

--- Comment #1 from tromey at gcc dot gnu dot org  2006-08-06 22:23 ---
Testing a patch.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tromey at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-08-06 21:35:24 |2006-08-06 22:23:08
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28491

[Bug libgcj/28491] NetworkInterface.getNetworkInterfaces() doesn't report ipv6 interfaces.

[tromey at gcc dot gnu dot org]

--- Comment #2 from tromey at gcc dot gnu dot org  2006-08-06 22:43 ---
Subject: Bug 28491

Author: tromey
Date: Sun Aug  6 22:43:05 2006
New Revision: 115977

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115977
Log:
PR libgcj/28491:
* configure, include/config.h.in: Rebuilt.
* configure.ac: Look for ifaddrs.h, getifaddrs.
* java/net/natVMNetworkInterfacePosix.cc (getInterfaces): Use
getifaddrs if available.

Modified:
trunk/libjava/ChangeLog
trunk/libjava/configure
trunk/libjava/configure.ac
trunk/libjava/include/config.h.in
trunk/libjava/java/net/natVMNetworkInterfacePosix.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28491

[Bug java/28423] multianewarray not always evaluated when compiling from bytecode

[tromey at gcc dot gnu dot org]

--- Comment #2 from tromey at gcc dot gnu dot org  2006-08-06 22:43 ---
Shouldn't we just pull in the fix from the gcj-eclipse branch?


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-08-06 22:43:47
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28423

[Bug libgcj/28491] NetworkInterface.getNetworkInterfaces() doesn't report ipv6 interfaces.

[tromey at gcc dot gnu dot org]

--- Comment #3 from tromey at gcc dot gnu dot org  2006-08-06 22:44 ---
Fix checked in on trunk.
This could be backported by someone if need be.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28491

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[howarth at nitro dot med dot uc dot edu]

--- Comment #14 from howarth at nitro dot med dot uc dot edu  2006-08-06 
22:47 ---
The current patch doesn't seem to work any more. I get a compile error on the
current gcc trunk svn
pull...

../../gcc-4.2-20060806/gcc/fortran/parse.c: In function 'parse_derived':
../../gcc-4.2-20060806/gcc/fortran/parse.c:1601: error: 'c' undeclared (first
use in this function)
../../gcc-4.2-20060806/gcc/fortran/parse.c:1601: error: (Each undeclared
identifier is reported only once
../../gcc-4.2-20060806/gcc/fortran/parse.c:1601: error: for each function it
appears in.)

Looking at parse.c, it appears that gfc_component has been removed from the
parse_derived call breaking
the section of the patch that looks for allocatable components.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541

[Bug awt/16729] Component.print() and Component.printAll() does not affect graphics parameter

[mark at gcc dot gnu dot org]

--- Comment #3 from mark at gcc dot gnu dot org  2006-08-06 23:24 ---
This seems to be partially fixed by:

2006-08-03  Sven de Marothy  <[EMAIL PROTECTED]>

* gnu/java/awt/peer/gtk/ComponentGraphics.java
(grab, nativeGrab): New methods.
* include/gnu_java_awt_peer_gtk_ComponentGraphics.h
* native/jni/gtk-peer/gnu_java_awt_peer_gtk_ComponentGraphics.c
(nativeGrab): New method.
* gnu/java/awt/peer/gtk/GtkComponentPeer.java
(print): Implement.
* java/awt/Component.java
(printAll): Should call peer print method.

The part that not always seems to work is when the Component is not
(completely) visible.


-- 

mark at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||sven at physto dot se


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16729

[Bug testsuite/27033] g++.dg/eh/spbp.C (test for excess errors) fails

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2006-08-06 23:42 ---
Subject: Bug 27033

Author: danglin
Date: Sun Aug  6 23:41:57 2006
New Revision: 115978

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115978
Log:
PR testsuite/27033
* g++.dg/eh/spbp.C: Skip on hppa*-*-hpux* if not hppa*64*-*-*.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/eh/spbp.C


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27033

[Bug testsuite/27033] g++.dg/eh/spbp.C (test for excess errors) fails

[danglin at gcc dot gnu dot org]

--- Comment #3 from danglin at gcc dot gnu dot org  2006-08-06 23:44 ---
Skipped on trunk.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27033

[Bug testsuite/27611] FAIL: g++.dg/other/unused1.C scan-assembler string\t"class2" and string\t"printer"

[danglin at gcc dot gnu dot org]

--- Comment #7 from danglin at gcc dot gnu dot org  2006-08-06 23:56 ---
Subject: Bug 27611

Author: danglin
Date: Sun Aug  6 23:56:24 2006
New Revision: 115979

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115979
Log:
PR testsuite/27611
* g++.dg/other/unused1.C: Skip on hppa*-*-hpux* if not hppa*64*-*-*.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/other/unused1.C


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27611

[Bug testsuite/27611] FAIL: g++.dg/other/unused1.C scan-assembler string\t"class2" and string\t"printer"

[danglin at gcc dot gnu dot org]

--- Comment #8 from danglin at gcc dot gnu dot org  2006-08-06 23:58 ---
Skipped on 32-bit PA hpux.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27611

[Bug libfortran/28603] FAIL: gfortran.dg/direct_io_6.f90 -O0 execution test

[danglin at gcc dot gnu dot org]

--- Comment #3 from danglin at gcc dot gnu dot org  2006-08-07 00:04 ---
Subject: Bug 28603

Author: danglin
Date: Mon Aug  7 00:04:06 2006
New Revision: 115980

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115980
Log:
PR libfortran/28603
* gfortran.dg/direct_io_6.f90: Skip on hppa*-*-hpux*.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/direct_io_6.f90


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28603

[Bug libfortran/28603] FAIL: gfortran.dg/direct_io_6.f90 -O0 execution test

[danglin at gcc dot gnu dot org]

--- Comment #4 from danglin at gcc dot gnu dot org  2006-08-07 00:05 ---
Skipped.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28603

[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch

[skunk at iskunk dot org]

--- Comment #18 from skunk at iskunk dot org  2006-08-07 04:32 ---
(In reply to comment #16)
> > (**None** of what you're saying is currently in the docs, so far as I can
> > see.)
> 
> Take a look at http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2

Okay, so the sparc64 and CC="cc -xarch=v9" bits are there. What about the
non-system-specific caveats w.r.t. CFLAGS and ABI compatibility?

> > If users ignoring docs is a problem, then do as the MPlayer folks do and
> > have the configure script print a big fat warning if it detects anything
> > unwholesome.
> 
> This would be a lot of work for GCC!

"Detects anything unwholesome" can be as simple as checking whether CFLAGS is
set at all (which is all MPlayer's build does). Over time, it could be expanded
into a case statement keying off a triplet, so you could have e.g. a
present/absent check for -xarch=v9 in CFLAGS for sparc*-sun-solaris*.

> > So you're saying that CC and the target triplet have to agree, ABI-wise?
> 
> If you want to do a bootstrap, yes.  Otherwise this is a cross-compilation and
> a bootstrap will miserably fail like in your case.

The reason why it failed in my case is because it linked code built with "$CC"
(genmodes) against code built with "$CC $CFLAGS" (libiberty). It was a flat-out
violation of flag-variable convention to build stage 1 genmodes without CFLAGS.

Now, if the failure was in linking code built with xgcc against the original
[cc-built] libiberty, then that's a more meaningful issue---because CFLAGS
doesn't apply there. It is the target (right?) triplet that controls what kind
of code xgcc generates, and this must be compatible with the output of "$CC
$CFLAGS". (I obtained this result by attempting to build with CC="cc
-xarch=v9", but without the sparc64 triplet.)

> CC+CFLAGS and the --host parameter of configure must always be in keeping.
> For a native compilation (hence a bootstrap), --target must additionally be.
> So the safe procedure is to modify CC and not CFLAGS.

Wait a second---you said that CFLAGS was being ignored because you didn't trust
the user to tweak it appropriately. So the "safe procedure" is what it is
because of that, not because of any technical requirement of the bootstrap
process.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515

[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch

[ebotcazou at gcc dot gnu dot org]

--- Comment #19 from ebotcazou at gcc dot gnu dot org  2006-08-07 05:32 
---
> Now, if the failure was in linking code built with xgcc against the original
> [cc-built] libiberty, then that's a more meaningful issue---because CFLAGS
> doesn't apply there.

Right, this would have failed here too.

> Wait a second---you said that CFLAGS was being ignored because you didn't
> trust the user to tweak it appropriately. So the "safe procedure" is what it
> is because of that, not because of any technical requirement of the bootstrap
> process.

Everything is always doable if resources permit.  Tweaking CFLAGS is simply
not generically supported and I don't think we have plan to that effect.

Simply use the documented procedure.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515

[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch

[skunk at iskunk dot org]

--- Comment #20 from skunk at iskunk dot org  2006-08-07 05:51 ---
(In reply to comment #19)
> Everything is always doable if resources permit.  Tweaking CFLAGS is simply
> not generically supported and I don't think we have plan to that effect.

Okay. No generic flag-tweaking support is perfectly fine. Can we either...

(1) Straighten things out so that if you do have to pass a flag(s) to the
compiler, it is passed in through CFLAGS---thus respecting standard
flag-variable convention, or

(2) Ignore CFLAGS altogether, so that libiberty isn't built with it, and CC
becomes the only place where flags can be put in? (The thinking being, if the
behavior's going to be broken, at least make it _consistently_ broken)

> Simply use the documented procedure.

This isn't just about sparc64, you know. The whole reason why this came up in
the first place is because I'm building GCC in a custom autobuild framework,
across a number of architectures. For every other autotoolized package, I set
CC, CXX, {CC,CXX,CPP}FLAGS, and everything works. It's really annoying to have
GCC, a pretty important package, so thoroughly flout the convention that all
the other GNU toolsets adhere to.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515

[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch

[ebotcazou at gcc dot gnu dot org]

--- Comment #21 from ebotcazou at gcc dot gnu dot org  2006-08-07 06:11 
---
> Okay. No generic flag-tweaking support is perfectly fine. Can we either...
> 
> (1) Straighten things out so that if you do have to pass a flag(s) to the
> compiler, it is passed in through CFLAGS---thus respecting standard
> flag-variable convention, or
> 
> (2) Ignore CFLAGS altogether, so that libiberty isn't built with it, and CC
> becomes the only place where flags can be put in? (The thinking being, if the
> behavior's going to be broken, at least make it _consistently_ broken)

I'm not the maintainer of the build machinery so I cannot really answer.

I'd only add that the upcoming GCC 4.2 release will feature a new bootstrap
procedure (aka toplevel bootstrap) that could solve the issue.  You might want
to give a try to one of the recent 4.2 snapshots and open a new PR against it
if you deem it necessary.

> This isn't just about sparc64, you know. The whole reason why this came up in
> the first place is because I'm building GCC in a custom autobuild framework,
> across a number of architectures. For every other autotoolized package, I set
> CC, CXX, {CC,CXX,CPP}FLAGS, and everything works. It's really annoying to have
> GCC, a pretty important package, so thoroughly flout the convention that all
> the other GNU toolsets adhere to.

On the one hand, and without any inflated ego :-), you cannot consider that
bootstrapping a compiler is like building any other piece of software.  On
the other hand, the aforementioned toplevel bootstrap is aimed at eliminating
the peculiarities you noticed; for example, a bare "make" will automatically
perform a complete 3-stage bootstrap for a native compiler in the sense that
the end result should not depend on the bootstrap compiler anymore at all.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515

[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3

[bonzini at gnu dot org]

--- Comment #37 from bonzini at gnu dot org  2006-08-07 06:19 ---
I don't see how the last fmul[sl] can be removed without increasing code size. 
The only way to fix it would be to change the machine description to say that
"this processor does not like FP operations with a memory operand".  With a
peephole, this is as good as we can get it.  The last fmul is not coupled with
a "fld %st" because it consumes the stack entry.  See in comment #30, where
there is still a "fmull b".

Can you please try re-running the tests?  It takes skill^W^W seems quite weird
to have a 100x slow-down, also because my tests were run on a similar Prescott
(P4e).

It also would be interesting to re-run your code generator on a compiler built
from svn trunk.  If it can provide higher performance, you'd be satisfied I
guess even if it comes from a different kernel.  Also, I strongly believe that
you should implement vectorization, or at least find out *why* GCC does not
vectorize your code.  It may be simply that it does not have any guarantee on
the alignment.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827

[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch

[ebotcazou at gcc dot gnu dot org]

--- Comment #22 from ebotcazou at gcc dot gnu dot org  2006-08-07 06:23 
---
> This isn't just about sparc64, you know. The whole reason why this came up in
> the first place is because I'm building GCC in a custom autobuild framework,
> across a number of architectures. For every other autotoolized package, I set
> CC, CXX, {CC,CXX,CPP}FLAGS, and everything works. It's really annoying to have
> GCC, a pretty important package, so thoroughly flout the convention that all
> the other GNU toolsets adhere to.

I'd also challenge this assertion: I don't think you can generically tweak
CFLAGS, in particular change the ABI, once a package has been configured.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515

[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch

[skunk at iskunk dot org]

--- Comment #23 from skunk at iskunk dot org  2006-08-07 06:43 ---
(In reply to comment #21)
> I'd only add that the upcoming GCC 4.2 release will feature a new bootstrap
> procedure (aka toplevel bootstrap) that could solve the issue.

Very interesting. I'll have a look at it. If this refactors the rat's nest of
Make variable overrides in the top-level makefile, then it could be a very good
thing indeed.

> On the one hand, and without any inflated ego :-), you cannot consider that
> bootstrapping a compiler is like building any other piece of software.

Very true, but in the simplest, degenerate case (bootstrapping with host ==
build == target), you could reasonably expect stage 1 (and anything before it)
to be built with CC+CFLAGS. Principle of least surprise, and all that.

(This is saying nothing about matching the triplets to CFLAGS, which does
remain an issue. Yes, you can't be *completely* naive in building GCC.)

>  On
> the other hand, the aforementioned toplevel bootstrap is aimed at eliminating
> the peculiarities you noticed; for example, a bare "make" will automatically
> perform a complete 3-stage bootstrap for a native compiler in the sense that
> the end result should not depend on the bootstrap compiler anymore at all.

I think you meant to say, "not depend on the native compiler" :-)  But this is
good---doing a bootstrap unconditionally is reasonable nowadays, and it should
simplify the build system a bit (one less case to handle).

(In reply to comment #22)
> I'd also challenge this assertion: I don't think you can generically tweak
> CFLAGS, in particular change the ABI, once a package has been configured.

Right, but... of course, whenever I say that I set such-and-such flags, I mean
before configure time. After that point, it usually doesn't matter what you
have set in the environment, because the standard variables are explicitly
assigned in the makefiles.

(You didn't think I was asking for the build system to track variables in the
environment _after_ configure time... did you?)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515

[Bug target/28074] -mstackrealign generates very inefficient code

[bonzini at gnu dot org]

--- Comment #1 from bonzini at gnu dot org  2006-08-07 06:55 ---
but it makes code undebuggable, doesn't it (because the GCC code keeps the
return address in place)


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28074