[Bug c/34947] [4.2 Regression] Clobbered float registers not popped

[vincent dot riviere at freesbee dot fr]

--- Comment #2 from vincent dot riviere at freesbee dot fr  2008-02-21 
07:34 ---
That patch fixes the problem:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00790.html


-- 


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

[Bug bootstrap/35273] [4.3.0 regression] Bootstrap of mingw32 using non-MSYS shell broken

[Ralf dot Wildenhues at gmx dot de]

--- Comment #2 from Ralf dot Wildenhues at gmx dot de  2008-02-21 07:33 
---
(In reply to comment #0) 
> I did not see an approval of this patch in GCC-patches.  Was it approved
> off-line?

Yes, it was approved by Jakub.

Patch to fix this breakage posted at
.


-- 


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

[Bug bootstrap/35273] [4.3.0 regression] Bootstrap of mingw32 using non-MSYS shell broken

[dannysmith at users dot sourceforge dot net]

--- Comment #1 from dannysmith at users dot sourceforge dot net  2008-02-21 
06:53 ---
Fix typo in summary


-- 

dannysmith at users dot sourceforge dot net changed:

   What|Removed |Added

Summary|[4.3.0  regression] |[4.3.0  regression]
   |Bootstrap of mingw32 using  |Bootstrap of mingw32 using
   |non-MSYS sehll broken   |non-MSYS shell broken


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

[Bug bootstrap/35273] New: [4.3.0 regression] Bootstrap of mingw32 using non-MSYS sehll broken

[dannysmith at users dot sourceforge dot net]

> gcc/ChangeLog:
> 2008-02-17  Ralf Wildenhues  <[EMAIL PROTECTED]>
>
> PR bootstrap/35218
> * Makefile.in (build_file_translate): New.
> (gcc-vers.texi): Use it for translating $(abs_srcdir).
> * config.build (build_file_translate): Set to `CMD //c' on MinGW.
> * configure.ac (build_file_translate): Substitute it.
> * configure: Regenerate.
>

This patch breaks native bootstrap on mingw systems that use
cygwin1.dll-dependent bash and development tools.  As such, that would
be a regression against all versions of gcc since at least 2.95.3

I did not see an approval of this patch in GCC-patches.  Was it approved
off-line?

The  ' CMD  //c' (with 2 slashes preceding the switch  rather than the
one documented for cmd by Micrsosoft) is a MSYS-ism that causes
problems  with non-MSYS shells (including cygwin bash, ZSH, and the shell
provided by MS in its SFU package)

Prior to this patch, GCC bootstrapped just fine (with or without the earlier
abs_srcdir patch that broke MSYS build) on mingw using the cygwin bash shell,
make and configure. Using cygwin shell rather than the MSYS shell means that
DejaGnu testsuite can be run.  The last time I checked this was not
possible with MSYS.

Danny


-- 
   Summary: [4.3.0  regression] Bootstrap of mingw32 using  non-MSYS
sehll broken
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
 GCC build triplet: i686-pc-mingw32


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

[Bug tree-optimization/35272] New: Loop distribution fails to distribute

[irar at il dot ibm dot com]

Loop distribution (from the patch
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00215.html) fails to distribute
the following loop:

for (i = 2; i <= n; ++i)
 {
   a[i] += c[i] * d[i];
   b[i] = a[i] + d[i] + b[i - 1];
 }

dumping "FIXME: Loop 1 not distributed: failed to build the RDG."

(After distribution the first loop will be vectorizable).


-- 
   Summary: Loop distribution fails to distribute
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: irar at il dot ibm dot com


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

[Bug c/19999] -Wfloat-equal does not warn for complex numbers

[rwild at gcc dot gnu dot org]

--- Comment #2 from rwild at gcc dot gnu dot org  2008-02-21 06:29 ---
patch at 


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||Ralf dot Wildenhues at gmx
   ||dot de
   Last reconfirmed|2005-12-18 01:40:38 |2008-02-21 06:29:50
   date||


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

[Bug target/35264] [4.3/4.4 regression] ntfs-3g miscompiled

[cnstar9988 at gmail dot com]

--- Comment #2 from cnstar9988 at gmail dot com  2008-02-21 06:07 ---
ok?


-- 


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

[Bug libfortran/35132] Formatted stream I/O write should truncate

[jvdelisle at gcc dot gnu dot org]

--- Comment #11 from jvdelisle at gcc dot gnu dot org  2008-02-21 02:54 
---
Closing


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libfortran/35132] Formatted stream I/O write should truncate

[jvdelisle at gcc dot gnu dot org]

--- Comment #10 from jvdelisle at gcc dot gnu dot org  2008-02-21 02:46 
---
Fixed on trunk.


-- 


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

[Bug libfortran/34974] null bytes when reverse-tabbing long records (regression vs. g77)

[jvdelisle at gcc dot gnu dot org]

--- Comment #11 from jvdelisle at gcc dot gnu dot org  2008-02-21 02:44 
---
Fixed on trunk, Committed as obvious.  Original test case now gives:

$ od -a test.dat 
000   a  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp
020  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp
*
3641060  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp  sp   b
3641100  nl


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/34954] finalize_transfer (transfer.c:2698): Depends on uninitialized memory

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2008-02-21 02:36 
---
Fixed on trunk, committed as obvious.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libfortran/34974] null bytes when reverse-tabbing long records (regression vs. g77)

[jvdelisle at gcc dot gnu dot org]

--- Comment #10 from jvdelisle at gcc dot gnu dot org  2008-02-21 02:34 
---
Subject: Bug 34974

Author: jvdelisle
Date: Thu Feb 21 02:33:17 2008
New Revision: 132513

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132513
Log:
2008-02-20  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libfortran/34974
* gfortran.dg/fmt_t_7.f: New test.

PR libfortran/35132
* gfortran.dg/streamio_15.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_t_7.f
trunk/gcc/testsuite/gfortran.dg/streamio_15.f90
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libfortran/35132] Formatted stream I/O write should truncate

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2008-02-21 02:34 
---
Subject: Bug 35132

Author: jvdelisle
Date: Thu Feb 21 02:33:17 2008
New Revision: 132513

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132513
Log:
2008-02-20  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libfortran/34974
* gfortran.dg/fmt_t_7.f: New test.

PR libfortran/35132
* gfortran.dg/streamio_15.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_t_7.f
trunk/gcc/testsuite/gfortran.dg/streamio_15.f90
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libfortran/34974] null bytes when reverse-tabbing long records (regression vs. g77)

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2008-02-21 02:27 
---
Subject: Bug 34974

Author: jvdelisle
Date: Thu Feb 21 02:27:07 2008
New Revision: 132512

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132512
Log:
2008-02-20  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libfortran/35132
* io/transfer.c (next_record_w): Truncate after the last record for
STREAM I/O.

PR libfortran/34954
* io/transfer.c (data_transfer_init): Initialize dtp->rec if writing.

PR libfortran/34974
* io/transfer.c (formatted_transfer_scalar): Flush the buffer if skips
is less than zero. (next_record_w): Use sseek to position the file to
the max position reached.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c


-- 


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

[Bug libfortran/35132] Formatted stream I/O write should truncate

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2008-02-21 02:27 
---
Subject: Bug 35132

Author: jvdelisle
Date: Thu Feb 21 02:27:07 2008
New Revision: 132512

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132512
Log:
2008-02-20  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libfortran/35132
* io/transfer.c (next_record_w): Truncate after the last record for
STREAM I/O.

PR libfortran/34954
* io/transfer.c (data_transfer_init): Initialize dtp->rec if writing.

PR libfortran/34974
* io/transfer.c (formatted_transfer_scalar): Flush the buffer if skips
is less than zero. (next_record_w): Use sseek to position the file to
the max position reached.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c


-- 


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

[Bug fortran/34954] finalize_transfer (transfer.c:2698): Depends on uninitialized memory

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2008-02-21 02:27 
---
Subject: Bug 34954

Author: jvdelisle
Date: Thu Feb 21 02:27:07 2008
New Revision: 132512

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132512
Log:
2008-02-20  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libfortran/35132
* io/transfer.c (next_record_w): Truncate after the last record for
STREAM I/O.

PR libfortran/34954
* io/transfer.c (data_transfer_init): Initialize dtp->rec if writing.

PR libfortran/34974
* io/transfer.c (formatted_transfer_scalar): Flush the buffer if skips
is less than zero. (next_record_w): Use sseek to position the file to
the max position reached.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c


-- 


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

[Bug fortran/35036] illegal E format descriptor produces wrong output

[jvdelisle at gcc dot gnu dot org]

--- Comment #17 from jvdelisle at gcc dot gnu dot org  2008-02-21 02:23 
---
Fixed on trunk.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/35036] illegal E format descriptor produces wrong output

[jvdelisle at gcc dot gnu dot org]

--- Comment #16 from jvdelisle at gcc dot gnu dot org  2008-02-21 02:23 
---
Subject: Bug 35036

Author: jvdelisle
Date: Thu Feb 21 02:22:45 2008
New Revision: 132511

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132511
Log:
2008-02-20  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libfortran/35036
* gfortran.dg/fmt_zero_digits.f90: Revise test.

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


-- 


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

[Bug fortran/35036] illegal E format descriptor produces wrong output

[jvdelisle at gcc dot gnu dot org]

--- Comment #15 from jvdelisle at gcc dot gnu dot org  2008-02-21 02:21 
---
Subject: Bug 35036

Author: jvdelisle
Date: Thu Feb 21 02:20:27 2008
New Revision: 132510

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132510
Log:
2008-02-20  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libfortran/35036
* write_float.def (output_float):  Add error checks for zero digits
after decimal point in E and D format specifiers.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/write_float.def


-- 


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

[Bug c++/35262] [4.4 Regression]: FAIL: abi_check

[pcarlini at suse dot de]

--- Comment #7 from pcarlini at suse dot de  2008-02-21 00:08 ---
Created an attachment (id=15189)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15189&action=view)
Pre-processed instantiation


-- 


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

[Bug c++/35262] [4.4 Regression]: FAIL: abi_check

[pcarlini at suse dot de]

--- Comment #6 from pcarlini at suse dot de  2008-02-21 00:07 ---
(In reply to comment #5)
> Subject: Re:  [4.4 Regression]: FAIL: abi_check
> 
> OK,
> if it really is just inlining decision difference then we are fine.
> I guess we can either update symbol list or mark always_inline

Yes, from a robustness of the set of exported symbols point of view eventually
we should anyway specify in the linker script to hide such symbols. However...

> I can look into the reason why it is not getting inlined. It would help
> to have preprocessed testcase as I am travelling now  :)

... many thanks! Because I think 4.3.0 is right here, I think that small
function should be indeed inlined. I'm going to add a trivial preprocessed
file, which just instantiates std::basic_filebuf: at -O2 the object
contains the __check_facet symbol, at variance with 4.3. Many thanks
again for looking into this.


-- 


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

[Bug c++/35262] [4.4 Regression]: FAIL: abi_check

[hubicka at ucw dot cz]

--- Comment #5 from hubicka at ucw dot cz  2008-02-20 23:39 ---
Subject: Re:  [4.4 Regression]: FAIL: abi_check

OK,
if it really is just inlining decision difference then we are fine.
I guess we can either update symbol list or mark always_inline
> because of a changing inlining decision. My concern, however, is whether it's
> ok not to inline such a tiny function (fyi, the function is defined in
> basic_ios.h all the uses are in fstream.tcc). First blush, I don't think it's
> ok...

I can look into the reason why it is not getting inlined. It would help
to have preprocessed testcase as I am travelling now  :)

Honza


-- 


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

[Bug target/35225] [4.2 regression] gcc segfaults when building GTK+ code with -O2 -fPIC for SH4

[kkojima at gcc dot gnu dot org]

--- Comment #4 from kkojima at gcc dot gnu dot org  2008-02-20 23:38 ---
Subject: Bug 35225

Author: kkojima
Date: Wed Feb 20 23:37:58 2008
New Revision: 132503

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132503
Log:
PR target/35225
* config/sh/sh.c (find_barrier): Don't go past 'from' argument.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c


-- 


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

[Bug target/35190] Wrong branch instruction with -freorder-blocks-and-partition on SH

[kkojima at gcc dot gnu dot org]

--- Comment #4 from kkojima at gcc dot gnu dot org  2008-02-20 23:36 ---
Subject: Bug 35190

Author: kkojima
Date: Wed Feb 20 23:35:41 2008
New Revision: 132502

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132502
Log:
PR target/35190
* config/sh/sh.md (jump_compact): Disable for crossing jumps.

* config/sh/sh.c (find_barrier): Don't go past
NOTE_INSN_SWITCH_TEXT_SECTIONS note.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sh/sh.md


-- 


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

[Bug c/35271] Stack not aligned at mod 16 byte boundary in x86_64 code

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-20 23:10 ---
Testcase?  Because we do align it for both x86_64-* and i386-darwin.

Now the SVSV i386 ABI says it should be aligned at 4 (word) bytes boundary.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
 Status|UNCONFIRMED |WAITING


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

[Bug c/35271] New: Stack not aligned at mod 16 byte boundary in x86_64 code

[tege-gcc at swox dot com]

The stack should be aligned at a 8 mod 16 boundary
at function entry, under both Apple's ABI and under
"System V Application Binary Interface AMD64
Architecture Processor Supplement, draft 0.99".

GCC aligns the stack at a 0 mod 8 boundary.

To quote from the above mentioned document:
  The end of the input argument area shall be aligned
  on a 16 byte boundary.  In other words, the value
  (%rsp - 8) is always a multiple of 16 when control
  is transferred to the function entry point.

How come this hasn't been discovered before (at least I
cannot find any bug reports about it)?  It is because the
x86 is very lax about alignment.  But a few instructions
are not that lax, MOVDQA will trigger a SIGSEGV on *nix
systems.  It is a performance issue for other 16-byte
loads and stores.

I have no test case for this, although it is possible to
trigger in a shared library under darwin, since the runtime
loader used MOVDQA.

Note that this bug has been verified to exist also for
x86_64-*-freebsd, and from reading the compiler sources.
it also affects gnu/linux.


-- 
   Summary: Stack not aligned at mod 16 byte boundary in x86_64 code
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tege-gcc at swox dot com
 GCC build triplet: i386-apple-darwin8.11.1
  GCC host triplet: i386-apple-darwin8.11.1
GCC target triplet: i386-apple-darwin8.11.1


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

[Bug middle-end/30262] [4.0/4.1 Regression] ICE with nested fn accessed var in asm "m" constraint

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2008-02-20 22:47 
---
Fixed since 4.2.0, wontfix on older branches.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail||4.1.3
  Known to work||4.2.0
 Resolution||FIXED
   Target Milestone|4.1.3   |4.2.0


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

[Bug debug/27473] [4.0/4.1 Regression] g++.dg/other/unused1.C and gcc.dg/20060410.c fail on powerpc-darwin

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-02-20 22:46 ---
Fixed since 4.2.0, wontfix on earlier branches.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail||4.1.3
  Known to work||4.2.0
 Resolution||FIXED
   Target Milestone|4.1.3   |4.2.0


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

[Bug target/25127] [4.0/4.1 Regression] internal compiler error: in rs6000_emit_prologue, at config/rs6000/rs6000.c:14039

[rguenth at gcc dot gnu dot org]

--- Comment #17 from rguenth at gcc dot gnu dot org  2008-02-20 22:44 
---
Fixed since 4.2.0, wontfix on earlier branches.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail|4.1.1 4.1.2 |4.1.1 4.1.2 4.1.3
 Resolution||FIXED
   Target Milestone|4.1.3   |4.2.0


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

[Bug middle-end/27567] [4.0/4.1 Regression] __builtin_memcpy generates redundant stores/moves.

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2008-02-20 22:37 
---
Fixed since 4.2.0, wontfix on earlier branches.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail|3.4.6 4.0.3 4.1.2   |3.4.6 4.0.3 4.1.2 4.1.3
 Resolution||FIXED
   Target Milestone|4.1.3   |4.2.0


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

[Bug target/21715] [4.0/4.1 regression] code-generation performance regression

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2008-02-20 22:35 
---
Fixed since 4.2.0, wontfix on older branches.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail|4.0.0 4.1.0 3.3.5 3.3.6 |4.0.0 4.1.0 4.1.3 3.3.5
   ||3.3.6
 Resolution||FIXED
   Target Milestone|4.1.3   |4.2.0


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

[Bug tree-optimization/17506] [4.0/4.1 Regression] warning about uninitialized variable points to wrong location

[rguenth at gcc dot gnu dot org]

--- Comment #36 from rguenth at gcc dot gnu dot org  2008-02-20 22:34 
---
Fixed since 4.2.0, wontfix for older branches.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail|4.0.0   |4.0.0 4.1.3
  Known to work|3.4.2   |3.4.2 4.2.0
 Resolution||FIXED
Summary|[4.0/4.1 regression]|[4.0/4.1 Regression]
   |warning about uninitialized |warning about uninitialized
   |variable points to wrong|variable points to wrong
   |location|location
   Target Milestone|4.1.3   |4.2.0


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

[Bug tree-optimization/19661] unnecessary atexit calls emitted for static objects with empty destructors

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2008-02-20 21:52 ---
(In reply to comment #7)
> Why do you think the front-end doesn't know that the destructor is empty? 

Because it is non trivial.  Try it with a more complex case where you have
multiple layer destructors and inlining, you will see that the front-end does
not know if it is empty until way after inlining.

-- Pinski


-- 


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

[Bug c/35263] Erroneous Application Execution Starting With GCC Version 4.1.3

[mlake at mlake dot net]

--- Comment #2 from mlake at mlake dot net  2008-02-20 21:51 ---
Subject: Re:  Erroneous Application Execution Starting With GCC
 Version 4.1.3


> --- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-20 19:08 
> ---
> Do you have a testcase?

Hopefully the info below will be enough to help.  I'm not sure what other 
info I can send.

The first set of data is the output of gcc -v on the machine where the 
execution is good.  The second set of data is the output of gcc -v on the 
machine where the execution is bad.

The third set of data is a display of the contents of the array char 
schedule[244][500]; showing good data.  The fourth set of data is a 
display of the contents of the array char schedule[244][500]; showing bad 
data.  Notice in the occurrence of the array starting with 065 (and all 
the following occurrences) the data is different.

My application is the same on both machines.  The same input data was used 
in both cases.



begin gcc -v, good case---
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,f95,java,ada --disable-checking
--with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-java-awt=gtk
--disable-libjava-multilib --with-slibdir=/lib --with-system-zlib
--enable-shared --enable-__cxa_atexit --without-system-libunwind
--host=i586-suse-linux
Thread model: posix
gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)
end gcc -v, good case---


begin gcc -v, bad case---
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.2.1
--enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.2
--enable-version-specific-runtime-libs --without-system-libunwind
--with-cpu=generic --host=i586-suse-linux
Thread model: posix
gcc version 4.2.1 (SUSE Linux)
end gcc -v, bad case---


begin array data, good case---
001 19010062-19010002 19010058-19010055 19010004-19010063 19010045-19010018
19010023-19010006 19010033-19010053 19010027-19010026 19010035-19010030 
002 19010062-19010002 19010058-19010055 19010004-19010063 19010045-19010018
19010023-19010006 19010033-19010053 19010027-19010026 19010035-19010030 
003 19010062-19010002 19010058-19010055 19010004-19010063 19010045-19010018
19010023-19010006 19010033-19010053 19010027-19010026 19010035-19010030 
004 19010062-19010002 19010058-19010055 19010004-19010063 19010045-19010018
19010023-19010006 19010033-19010053 19010027-19010026 19010035-19010030 
005 19010055-19010002 19010058-19010062 19010018-19010063 19010045-19010004
19010053-19010006 19010033-19010023 19010030-19010026 19010035-19010027 
006 19010055-19010002 19010058-19010062 19010018-19010063 19010045-19010004
19010053-19010006 19010033-19010023 19010030-19010026 19010035-19010027 
007 19010055-19010002 19010058-19010062 19010018-19010063 19010045-19010004
19010053-19010006 19010033-19010023 19010030-19010026 19010035-19010027 
008 19010055-19010002 19010058-19010062 19010018-19010063 19010045-19010004
19010053-19010006 19010033-19010023 19010030-19010026 19010035-19010027 
009 19010058-19010002 19010055-19010062 19010045-19010063 19010018-19010004
19010033-19010006 19010053-19010023 19010035-19010026 19010030-19010027 
010 19010058-19010002 19010055-19010062 19010045-19010063 19010018-19010004
19010033-19010006 19010053-19010023 19010035-19010026 19010030-19010027 
011 19010058-19010002 19010055-19010062 19010045-19010063 19010018-19010004
19010033-19010006 19010053-19010023 19010035-19010026 19010030-19010027 
012 19010058-19010002 19010055-19010062 19010045-19010063 19010018-19010004
19010033-19010006 19010053-19010023 19010035-19010026 19010030-19010027 
013 19010063-19010002 19010004-19010062 19010018-19010055 19010045-19010058
19010026-19010006 19010027-19010023 19010030-19010053 19010035-19010033 
014 19010063-19010002 19010004-19010062 19010018-19010055 19010045-19010058
19010026-19010006 19010027-19010023 19010030-19010053 19010035-19010033 
015 19010063-19010002 19010004-19010062 19010018-19010055 19010045-19010058
19010026-19010006 19010027-19010023 19010030-19010053 19010035-19010033 
016 19010063-19010002 19010004-19010062 19010018-19010055 19010045-19010058
19010026-19010006 19010027-19010023 19010030-19010053 19010

[Bug target/32110] vector "extract" and then vector "splat" is not optimized

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-20 21:34 ---
Mine, the PS3 toolchain has patches which fixes this issue.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-20 21:34:23
   date||


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

[Bug libstdc++/35256] Bad link on http://gcc.gnu.org/onlinedocs/libstdc++/parallel_mode.html

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-02-20 21:14 ---
Confirmed.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
  Component|web |libstdc++
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-20 21:14:52
   date||


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

[Bug bootstrap/32009] [4.3/4.4 Regression] building gcc4-4.3/4.4.0-20070518 failed on OSX 10.3.9

[andreast at gcc dot gnu dot org]

--- Comment #29 from andreast at gcc dot gnu dot org  2008-02-20 21:14 
---
Paolo, thank you.
It took me some time but now I completed a bootstrap on ppc-darwin (10.5.2).
I started to try your first patch yesterday and I failed due to some predict.c
failure. This morning I restarted and interrupted after I saw your second
patch.
Tried this one as well and I failed. I must have missed an autoconf step and as
it seemed, also a Makefile generation step.

After your commit I felt very bad. But then, before complaining, I synced and
restarted the build again. Whee, success!

As already said, thank you!
Andreas


-- 


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

[Bug c++/35262] [4.4 Regression]: FAIL: abi_check

[pcarlini at suse dot de]

--- Comment #4 from pcarlini at suse dot de  2008-02-20 21:13 ---
I'm not sure there is a substantive bug here, in that the problem can be easily
fixed by simply tweaking gnu.ver to explicitely hide
ZSt13__check_facetISt7codecvtIcc11__mbstate_tEERKT_PS4_ and the wchar_t
counterpart: certainly would not be the first time exports must be tweaked
because of a changing inlining decision. My concern, however, is whether it's
ok not to inline such a tiny function (fyi, the function is defined in
basic_ios.h all the uses are in fstream.tcc). First blush, I don't think it's
ok...


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||pcarlini at suse dot de


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

[Bug java/35257] jar: internal error: java.lang.NullPointerException bootstrapping libjava

[tromey at gcc dot gnu dot org]

--- Comment #2 from tromey at gcc dot gnu dot org  2008-02-20 21:10 ---
Based on the command line it looks like your system gjar is crashing.
Is that the case?


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org


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

[Bug c++/35262] [4.4 Regression]: FAIL: abi_check

[hubicka at ucw dot cz]

--- Comment #3 from hubicka at ucw dot cz  2008-02-20 21:05 ---
Subject: Re:  [4.4 Regression]: FAIL: abi_check

> (In reply to comment #1)
> > Jan, is this related to your patch?
> 
> And if it is, then there is another bug somewhere else anyways as it could 
> only
> change inlining decisions.

It might be the negative inlining cost assert.  I will look into that.

Honza


-- 


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

[Bug tree-optimization/35269] missed optimization of std::vector access.

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-20 20:45 ---
Sorry, but the vector v is potentially clobbered by the call to f, so the load
of the array pointer you index into with i is not loop invariant.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/35251] internal compiler error: verify_stmts failed

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2008-02-20 20:40 
---
Works OK on 4.3.0


-- 


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

[Bug target/30243] [4.1/4.2/4.3/4.4 Regression][avr] signbit() causes an internal compiler error

[eric dot weddington at atmel dot com]

--- Comment #7 from eric dot weddington at atmel dot com  2008-02-20 20:34 
---
Created an attachment (id=15187)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15187&action=view)
New patch

New patch using GET_MODE_SIZE as recommended.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

  Attachment #14316|0   |1
is obsolete||


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

[Bug tree-optimization/35269] New: missed optimization of std::vector access.

[pluto at agmk dot net]

please consider following testcase:

#include 
void f( int );
typedef std::vector< int > V;
void g( V const& v, V::size_type n )
{
for ( V::size_type i = 0; i < n; i++ )
f( v[ i ] );
}
void h( V const& v, V::size_type n )
{
for ( V::const_iterator i = v.begin(), e = i + n; i != e; ++i )
f( *i );
}

g() and h() traverse vector in the same way and imho should
produces the same assembly code but compiler producess
unoptimal code for g().

_Z1gRKSt6vectorIiSaIiEEm:
pushq   %r12
testq   %rsi, %rsi
movq%rdi, %r12
pushq   %rbp
movq%rsi, %rbp
pushq   %rbx
je  .L12
xorl%ebx, %ebx

.L11:   movq(%r12), %rax <=== h() is smarter in this point.
movl(%rax,%rbx,4), %edi  <===

addq$1, %rbx
call_Z1fi
cmpq%rbp, %rbx
jne .L11

popq%rbx
popq%rbp
popq%r12
ret

_Z1hRKSt6vectorIiSaIiEEm:
pushq   %rbp
pushq   %rbx
subq$8, %rsp
movq(%rdi), %rbx
leaq(%rbx,%rsi,4), %rbp
cmpq%rbp, %rbx
je  .L4

.L5:movl(%rbx), %edi
addq$4, %rbx
call_Z1fi
cmpq%rbx, %rbp
jne .L5

addq$8, %rsp
popq%rbx
popq%rbp
ret


-- 
   Summary: missed optimization of std::vector access.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC target triplet: x86_64-gnu-linux


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

[Bug libgcj/35266] gcj: Internal error: Killed (program jc1) when building java

[juli-info at baumler dot com]

--- Comment #2 from juli-info at baumler dot com  2008-02-20 20:21 ---
(In reply to comment #1)
> How much memory do you have?

% free -mt
 total   used   free sharedbuffers cached
Mem:  3536   3334202  0 40   1814
-/+ buffers/cache:   1478   2057
Swap: 6165   1273   4891
Total:9702   4608   5094

> How are you invoking make?

just as make.

> How did you configure GCC ?

from the objectdir:

../gcc-4.23/configure --prefix=/home/lhaley/lib \
 --enable-languages=java,c,c++

I'm building/installing a personal copy of gcj for a user on some cheap
hosting solution that doesn't supply it or a current gcc.


-- 


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

[Bug c++/35268] New: ICE on virtual function in template with pointer-to-member-function template parameter

[circuitben at gmail dot com]

A template parameter is provided by a function call parameter (which should be
rejected as it is non-constant).
The ICE does not occur (and an appropriate error is issued) if the code is
rewritten so that func is an int or a pointer to a non-member function.


class Object
{
public:
void something()
{
}
};

template
class Action
{
public:
// Removing "virtual" prevents the error.
virtual void run()
{
// Removing the next line prevents the error.
(object->*func)();
}

Object *object;
};

template
void *make_action(F func)
{
// Replacing func with &Object::something prevents the error.
return new Action();
}

void bug()
{
make_action(&Object::something);

// Not using the templated function prevents the error:
//new Action();
}


-- 
   Summary: ICE on virtual function in template with pointer-to-
member-function template parameter
   Product: gcc
   Version: 4.1.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: circuitben at gmail dot com
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug fortran/35267] New: VOLATILE constrain: Misleading error message "Incompatible ranks"

[burnus at gcc dot gnu dot org]

Spit off from PR 35033. The following is wrong but for different reasons. The
error message is thus very difficult to deceiver:

  p = q
  1
Error: Incompatible ranks 2 and 1 in assignment at (1)

gfortran regards it as intrinsic assignment which fails due to the different
ranks. However, it is actually a non-intrinsic assignment and it only fails
because the argument to the ASSIGNMENT(=) subroutine is a pointer and the dummy
is VOLATILE.

The problem is that the checking is done via "try whether interface matches"
and if it fails it is ignored and the next generic interface is tried. One
should actually check whether it matches - and if it does, additional
constrains need to be checked - such as this VOLATILE problem.

Detailed description of the test case, see PR 35033. compare_actual_formal
should be modified such that there is first a loop of arguments which checks
whether the all arguments match to the interface. Then another loop which runs
again over all arguments and checks whether additional constrains are violated.
For the first one, one simply returns when matching GERNERIC procedures
(assignments, operators) while in the second loop one prints out an error
message unconditionally.


The test case itself is:

  INTERFACE ASSIGNMENT(=)
 SUBROUTINE s(a,b)
 REAL,INTENT(OUT),VOLATILE :: a(1,*)
 REAL,INTENT(IN) :: b(:)
 END SUBROUTINE
  END Interface
  REAL,POINTER :: p(:,:),q(:)
  CALL s(p,q)! Violation of constraint C1233 [271:9-11],
 !  associating P with A
  p = q  ! No constraint violation because 
 !  syntax is not being used
  end


-- 
   Summary: VOLATILE constrain: Misleading error message
"Incompatible ranks"
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug ada/15479] Ada manual problems

[rwild at gcc dot gnu dot org]

--- Comment #5 from rwild at gcc dot gnu dot org  2008-02-20 19:51 ---
Subject: Bug 15479

Author: rwild
Date: Wed Feb 20 19:50:39 2008
New Revision: 132494

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132494
Log:
gcc/ada/:
PR documentation/15479
* gnat_ugn.texi: In non-code, avoid space before colon.
(Regular Expressions in gnatfind and gnatxref): Fix indentation.
(Examples of gnatxref Usage): Use @command{vi} instead of
@file{vi}.
(Character Set Control): Do not use @code for UTF-8.
(Validity Checking): Fix typo "NaNs" instead of "NaN's".  Do not
use @code for IEEE.
* gnat_rm.texi (Aggregates with static bounds): Fix typo in code
sample.
* gnat_rm.texi, gnat_ugn.texi: Fix typos.  Bump copyright years.

Modified:
branches/gcc-4_1-branch/gcc/ada/ChangeLog
branches/gcc-4_1-branch/gcc/ada/gnat_rm.texi
branches/gcc-4_1-branch/gcc/ada/gnat_ugn.texi


-- 


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

[Bug ada/15479] Ada manual problems

[rwild at gcc dot gnu dot org]

--- Comment #4 from rwild at gcc dot gnu dot org  2008-02-20 19:49 ---
Subject: Bug 15479

Author: rwild
Date: Wed Feb 20 19:48:55 2008
New Revision: 132493

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132493
Log:
gcc/ada/:
PR documentation/15479
* gnat_ugn.texi: In non-code, avoid space before colon.
(Regular Expressions in gnatfind and gnatxref): Fix indentation.
(Examples of gnatxref Usage): Use @command{vi} instead of
@file{vi}.
(Character Set Control): Do not use @code for UTF-8.
(Validity Checking): Fix typo "NaNs" instead of "NaN's".  Do not
use @code for IEEE.
* gnat_rm.texi (Aggregates with static bounds): Fix typo in code
sample.
* gnat_rm.texi, gnat_ugn.texi: Fix typos.  Bump copyright years.

Modified:
branches/gcc-4_2-branch/gcc/ada/ChangeLog
branches/gcc-4_2-branch/gcc/ada/gnat_rm.texi
branches/gcc-4_2-branch/gcc/ada/gnat_ugn.texi


-- 


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

[Bug bootstrap/25672] [4.1/4.2/4.3/4.4 regression] cross build's libgcc picks up CFLAGS

[bonzini at gnu dot org]

--- Comment #20 from bonzini at gnu dot org  2008-02-20 19:32 ---
Subject: Re:  [4.1/4.2/4.3/4.4 regression] cross build's
 libgcc picks up CFLAGS

ubizjak at gmail dot com wrote:
> --- Comment #19 from ubizjak at gmail dot com  2008-02-20 18:44 ---
> Patch at http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00204.html needs build
> maintainer attention. And a ChangeLog!

should be fixed by today's patch for PR/32009.

Paolo


-- 


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

[Bug libgcj/24170] libjava natFilePosix.cc seems to have a security problem

[tromey at gcc dot gnu dot org]

--- Comment #11 from tromey at gcc dot gnu dot org  2008-02-20 19:10 ---
Fix checked in.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug libgcj/24170] libjava natFilePosix.cc seems to have a security problem

[tromey at gcc dot gnu dot org]

--- Comment #10 from tromey at gcc dot gnu dot org  2008-02-20 19:09 ---
Subject: Bug 24170

Author: tromey
Date: Wed Feb 20 19:09:09 2008
New Revision: 132491

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132491
Log:
PR libgcj/24170:
* java/io/natFilePosix.cc (File::performList): Don't use
readdir_r.
* configure, include/config.h.in: Rebuilt.
* configure.ac: Don't check for readdir_r.

Modified:
trunk/libjava/ChangeLog
trunk/libjava/configure
trunk/libjava/configure.ac
trunk/libjava/include/config.h.in
trunk/libjava/java/io/natFilePosix.cc


-- 


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

[Bug c/35263] Erroneous Application Execution Starting With GCC Version 4.1.3

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-20 19:08 ---
Do you have a testcase?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug libgcj/35266] gcj: Internal error: Killed (program jc1) when building java

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-20 18:52 ---
How much memory do you have?

How are you invoking make?

How did you configure GCC ?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
 Status|UNCONFIRMED |WAITING


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

[Bug bootstrap/25672] [4.1/4.2/4.3/4.4 regression] cross build's libgcc picks up CFLAGS

[ubizjak at gmail dot com]

--- Comment #19 from ubizjak at gmail dot com  2008-02-20 18:44 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00204.html needs build
maintainer attention. And a ChangeLog!


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2006-
   ||05/msg00204.html
   Keywords||patch


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

[Bug libgcj/35266] New: gcj: Internal error: Killed (program jc1) when building java

[juli-info at baumler dot com]

When running make from the top level directory, it fails with the following
information/error message.

/home/lhaley/source/objdir/gcc/gcj
-B/home/lhaley/source/objdir/i686-pc-linux-gnu/libjava/
-B/home/lhaley/source/objdir/gcc/ -Wno-deprecated --encoding=UTF-8
--bootclasspath '' --classpath
..:/home/lhaley/source/gcc-4.2.3/libjava:/home/lhaley/source/objdir/i686-pc-linux-gnu/libjava:../../../../../gcc-4.2.3/libjava/classpath:../../../../../gcc-4.2.3/libjava/classpath/external/w3c_dom:../../../../../gcc-4.2.3/libjava/classpath/external/sax:../../../../../gcc-4.2.3/libjava/classpath/external/relaxngDatatype:.::
-C -d . -MD -MF lists/gnu-CORBA-CDR.deps -MT lists/gnu-CORBA-CDR.stamp -MP
@lists/gnu-CORBA-CDR.list
gcj: Internal error: Killed (program jc1)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
make[5]: *** [lists/gnu-CORBA-CDR.stamp] Error 1

Runing make from the directory
objectdir/i686-pc-linux-gnu/libjava/classpath/lib directly allows that
statement to complete, but then it fails later at:
/home/lhaley/source/objdir/gcc/gcj
-B/home/lhaley/source/objdir/i686-pc-linux-gnu/libjava/
-B/home/lhaley/source/objdir/gcc/ -Wno-deprecated --encoding=UTF-8
--bootclasspath '' --classpath
..:/home/lhaley/source/gcc-4.2.3/libjava:/home/lhaley/source/objdir/i686-pc-linux-gnu/libjava:../../../../../gcc-4.2.3/libjava/classpath:../../../../../gcc-4.2.3/libjava/classpath/external/w3c_dom:../../../../../gcc-4.2.3/libjava/classpath/external/sax:../../../../../gcc-4.2.3/libjava/classpath/external/relaxngDatatype:.::
-C -d . -MD -MF lists/gnu-javax-crypto.deps -MT lists/gnu-javax-crypto.stamp
-MP @lists/gnu-javax-crypto.list
gcj: Internal error: Killed (program jc1)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [lists/gnu-javax-crypto.stamp] Error 1

going back to the objectdir allows programs to compile through

/home/lhaley/source/objdir/gcc/gcj
-B/home/lhaley/source/objdir/i686-pc-linux-gnu/libjava/
-B/home/lhaley/source/objdir/gcc/ -Wno-deprecated --encoding=UTF-8
--bootclasspath '' --classpath
..:/home/lhaley/source/gcc-4.2.3/libjava:/home/lhaley/source/objdir/i686-pc-linux-gnu/libjava:../../../../../gcc-4.2.3/libjava/classpath:../../../../../gcc-4.2.3/libjava/classpath/external/w3c_dom:../../../../../gcc-4.2.3/libjava/classpath/external/sax:../../../../../gcc-4.2.3/libjava/classpath/external/relaxngDatatype:.::
-C -d . -MD -MF lists/java-beans.deps -MT lists/java-beans.stamp -MP
@lists/java-beans.list
gcj: Internal error: Killed (program jc1)

This again will compile if you move directly to that directory, but then fails
again later with the same error.

It may be possible to get a working libjava by dint of switching directories
and restarting, but I'm working for a client who doesn't want to put the time
in (I've already done a lot on my own time trying to find / document this bug).


-- 
   Summary: gcj: Internal error: Killed (program jc1) when building
java
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: juli-info at baumler dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug target/27880] [4.2/4.3/4.4 regression] undefined reference to `_Unwind_GetIPInfo'

[ubizjak at gmail dot com]

--- Comment #22 from ubizjak at gmail dot com  2008-02-20 18:39 ---
Critical P2 bug and the patch gets unreviewed for so long?!

Is this bug still relevant for ia64-*-linux?


-- 


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

[Bug libgcj/24170] libjava natFilePosix.cc seems to have a security problem

[tromey at gcc dot gnu dot org]

--- Comment #9 from tromey at gcc dot gnu dot org  2008-02-20 18:38 ---
I'll handle it.


-- 

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|2005-10-03 14:28:34 |2008-02-20 18:38:40
   date||


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

[Bug fortran/34997] Mention -fdollar-ok option in error message for symbol names containing $

[burnus at gcc dot gnu dot org]

--- Comment #6 from burnus at gcc dot gnu dot org  2008-02-20 18:28 ---
FIXED on the trunk (4.4.0)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libgcj/24170] libjava natFilePosix.cc seems to have a security problem

[jason at gcc dot gnu dot org]

--- Comment #8 from jason at gcc dot gnu dot org  2008-02-20 18:27 ---
is anyone on the gcj team looking at this?


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|natFilePosix.cc seems to|libjava natFilePosix.cc
   |have a security problem |seems to have a security
   ||problem


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

[Bug target/18994] AIX: storage class in debugging strings

[jason at gcc dot gnu dot org]

--- Comment #1 from jason at gcc dot gnu dot org  2008-02-20 18:23 ---
downgrading to P3


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P1  |P3


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

[Bug fortran/34997] Mention -fdollar-ok option in error message for symbol names containing $

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2008-02-20 18:22 ---
Subject: Bug 34997

Author: burnus
Date: Wed Feb 20 18:21:14 2008
New Revision: 132488

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132488
Log:
2008-02-20  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/34997
* match.c (gfc_match_name): Improve error message for '$'.

2008-02-20  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/34997
* gfortran.dg/dollar_sym_1.f90: New.
* gfortran.dg/dollar_sym_2.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/dollar_sym_1.f90
trunk/gcc/testsuite/gfortran.dg/dollar_sym_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/35262] [4.4 Regression]: FAIL: abi_check

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-02-20 17:50 ---
(In reply to comment #1)
> Jan, is this related to your patch?

And if it is, then there is another bug somewhere else anyways as it could only
change inlining decisions.

-- Pinski


-- 


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

[Bug middle-end/35265] [4.2/4.3/4.4 Regression] __builtin_popcount expansion bug

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2008-02-20 17:33 ---
Subject: Bug 35265

Author: rguenth
Date: Wed Feb 20 17:33:07 2008
New Revision: 132487

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132487
Log:
2008-02-20  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/35265
* builtins.c (validate_arg): If we want an INTEGER_TYPE,
be happy with INTEGRAL_TYPE_P.

* gcc.dg/builtins-66.c: New testcase.

Added:
branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/builtins-66.c
Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/builtins.c
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/35265] [4.2/4.3/4.4 Regression] __builtin_popcount expansion bug

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-02-20 17:33 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/35265] [4.2/4.3/4.4 Regression] __builtin_popcount expansion bug

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-02-20 17:28 ---
Subject: Bug 35265

Author: rguenth
Date: Wed Feb 20 17:27:21 2008
New Revision: 132486

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132486
Log:
2008-02-20  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/35265
* builtins.c (validate_arg): If we want an INTEGER_TYPE,
be happy with INTEGRAL_TYPE_P.

* gcc.dg/builtins-66.c: New testcase.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/builtins-66.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/builtins.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/35265] [4.2/4.3/4.4 Regression] __builtin_popcount expansion bug

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-02-20 17:26 ---
Subject: Bug 35265

Author: rguenth
Date: Wed Feb 20 17:25:52 2008
New Revision: 132485

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132485
Log:
2008-02-20  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/35265
* builtins.c (validate_arg): If we want an INTEGER_TYPE,
be happy with INTEGRAL_TYPE_P.

* gcc.dg/builtins-66.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/builtins-66.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/35265] [4.2/4.3/4.4 Regression] __builtin_popcount expansion bug

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-02-20 16:45 ---
I have an obvious patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.2.3
  Known to work||4.1.2
   Priority|P3  |P1


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

[Bug middle-end/35265] [4.2/4.3/4.4 Regression] __builtin_popcount expansion bug

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-02-20 16:34 ---
5111  if (!validate_arglist (exp, INTEGER_TYPE, VOID_TYPE))
5112return NULL_RTX;

but we get an enumeral type.  Hm.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-02-20 16:29:06 |2008-02-20 16:34:00
   date||


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

[Bug middle-end/35265] [4.2/4.3/4.4 Regression] __builtin_popcount expansion bug

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-02-20 16:30 ---
The same is probably true for CTZ, PARITY, etc. (all go through unop
expansion).


-- 


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

[Bug target/35264] [4.3/4.4 regression] ntfs-3g miscompiled

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-02-20 16:29 ---
Oops, sorry.


-- 


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

[Bug middle-end/35265] [4.2/4.3/4.4 Regression] __builtin_popcount expansion bug

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-20 16:29 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-02-20 16:29:06
   date||
   Target Milestone|--- |4.2.4


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

[Bug middle-end/35265] New: [4.2/4.3/4.4 Regression] __builtin_popcount expansion bug

[jakub at gcc dot gnu dot org]

enum { E0 = 0, E1 = 1, E2 = 2 } e;

int
foo (void)
{
  return __builtin_popcount ((int) e);
}

int
bar (int x)
{
  return __builtin_popcount (x);
}

In foo this is expanded into a call to __builtin_popcount, rather than
__popcountsi2 (or popcount instruction), at least on i?86/x86_64/ppc/ppc64.
In 4.1 this used to work correctly.


-- 
   Summary: [4.2/4.3/4.4 Regression] __builtin_popcount expansion
bug
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug target/35264] [4.3/4.4 regression] ntfs-3g miscompiled

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Priority|P3  |P1
   Last reconfirmed|-00-00 00:00:00 |2008-02-20 16:25:18
   date||
Summary|[4.3 regression] ntfs-3g|[4.3/4.4 regression] ntfs-3g
   |miscompiled |miscompiled
   Target Milestone|--- |4.3.0


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

[Bug target/35264] New: [4.3 regression] ntfs-3g miscompiled

[matz at gcc dot gnu dot org]

This testcase, compiled with -O1 aborts:

% cat t.c
extern void abort(void);
long long __attribute__((noinline)) get(void)
{
  return -2;
}
long long __attribute__((noinline)) get(void);
int __attribute__((noinline)) check(void)
{
 long long lcn;

 lcn = get();
 if (lcn >= 0 || lcn == -1)
  return 0;

 return -1;
}
int main()
{
  if (check() == 0)
abort();
  return 0;
}

Reason is ix86_expand_branch, the committ for PR target/29978 misses breaks
in the switch statement, hence falls through into the wrong branch.

Obvious patch:
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 132470)
+++ config/i386/i386.c  (working copy)
@@ -12148,6 +12152,7 @@ ix86_expand_branch (enum rtx_code code,
  ix86_expand_branch (code, label);
  return;
}
+ break;
case LE: case LEU: case GT: case GTU:
  if (lo[1] == constm1_rtx)
{
@@ -12156,6 +12161,7 @@ ix86_expand_branch (enum rtx_code code,
  ix86_expand_branch (code, label);
  return;
}
+ break;
default:
  break;
}

Richi already preapproved this patch for 4.3, I'm opening this PR anyway, to
have a reference for the testcase.


-- 
   Summary: [4.3 regression] ntfs-3g miscompiled
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC target triplet: i386


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

[Bug c/35263] New: Erroneous Application Execution Starting With GCC Version 4.1.3

[mlake at mlake dot net]

I'm running various versions of Linux on various i386 hardware.

I have a C application which I've compiled using gcc versions 3.4.1,
4.0.2, 4.1.2, 4.1.3, and 4.2.1.  (I'm told 4.1.3 is not a released
version but I do indeed have a version of gcc running on an openSUSE
10.3 system where gcc -v returns "gcc version 4.1.3 20070724 (prerelease)
(SUSE Linux)".)

On all the versions of gcc listed above my application compiles cleanly
using options -I../include -Wall -g -pedantic.  However, starting with
gcc version 4.1.3 my application executes incorrectly.  I've tried adding
the options -fno-strict-aliasing and -fno-strict-overflow but the same
erroneous results occur.

It's proving difficult for me to pinpoint the cause of the erroneous
results.  I have a character array ... char schedule[244][500]; ... in
which beginning at the 64th occurrence (starting with occurrence 0)
the data is incorrect using gcc versions 4.1.3 and 4.2.1.  The data is
correct using all the other versions of gcc listed above.

Is it possible that there is a bug in this regard in the 4.2.x series
of gcc?

Marshall Lake
[EMAIL PROTECTED]


-- 
   Summary: Erroneous Application Execution Starting With GCC
Version 4.1.3
   Product: gcc
   Version: 4.1.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mlake at mlake dot net


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

[Bug c++/35262] [4.4 Regression]: FAIL: abi_check

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-02-20 15:50 ---
Revision 132439 is bad:

http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg01322.html

Revision 132433 is OK:

http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg01318.html

The only change in 4.4 between those 2 revisions is revision 132439:

http://gcc.gnu.org/ml/gcc-cvs/2008-02/msg00454.html

Jan, is this related to your patch?


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
 GCC target triplet|x86_64-unknown-linux-gnu|


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

[Bug bootstrap/32009] [4.3/4.4 Regression] building gcc4-4.3/4.4.0-20070518 failed on OSX 10.3.9

[mrs at apple dot com]

--- Comment #28 from mrs at apple dot com  2008-02-20 15:44 ---
Thanks.


-- 


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

[Bug c++/35262] New: [4.4 Regression]: FAIL: abi_check

[hjl dot tools at gmail dot com]

With gcc 4.4 revision 132478 on Linux/Intel64, I got

FAIL: abi_check

in libstdc++. Revision 132408 is OK.


-- 
   Summary: [4.4 Regression]: FAIL: abi_check
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/35261] GCC4.3 internal compiler error: verify_flow_info failed

[rajiv dot adhikary at amd dot com]

--- Comment #1 from rajiv dot adhikary at amd dot com  2008-02-20 15:39 
---
Created an attachment (id=15186)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15186&action=view)
Source File with the problem


-- 


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

[Bug c++/35261] New: GCC4.3 internal compiler error: verify_flow_info failed

[rajiv dot adhikary at amd dot com]

Compiling using GCC4.3 with

g++ -msse4.1 -O2 -c  repro.cpp

causes internal compiler error:

repro.cpp: In function 'int main()':
repro.cpp:122: error: BB 10 can not throw but has EH edges
repro.cpp:122: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.



In this file the error goes away if you change

const static repro_u32 LOOP_COUNT = 100 * 1000;

to

const static repro_s32 LOOP_COUNT = 100 * 1000;

 Alternately if I remove the creation of Timer object (comment out Timer t(
pass, expCycles ); ) the problem goes away.


-- 
   Summary: GCC4.3 internal compiler error: verify_flow_info failed
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rajiv dot adhikary at amd dot com


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

[Bug fortran/34685] [patch] Honour parentheses in expressions

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-02-20 15:00 ---
How so?


-- 


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

[Bug c++/35140] wrong result due to -O2 optimization in combination with std::list

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-02-20 14:47 ---
We should probably admit that we will not fix this bug for GCC 4.1 (there will
be no further release off that branch).  A workaround is to use
-fno-strict-aliasing.

Please consider moving to GCC 4.2.x or 4.3.x once it is released.


-- 


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

[Bug c++/35140] wrong result due to -O2 optimization in combination with std::list

[basti at fkp dot tu-darmstadt dot de]

--- Comment #6 from basti at fkp dot tu-darmstadt dot de  2008-02-20 14:42 
---
The bug is not encountered when using the list<> container 
from the stlport-library instead of the one coming with the 
compiler. I tried the versions 4.6, 5.0, and 5.1 
(debian-etch packages libstlport4.6-dev,libstlport5.0-dev,
libstlport5.1-dev) and everything worked fine.

Hope that helps, sebastian

ps: is there any chance this bug is sorted out any time soon, 
or should i switch to a different compiler-version alltogether?


-- 


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

[Bug bootstrap/32161] stage1 libgcc is being built unoptimized

[bonzini at gcc dot gnu dot org]

--- Comment #6 from bonzini at gnu dot org  2008-02-20 14:11 ---
Subject: Bug 32161

Author: bonzini
Date: Wed Feb 20 14:10:40 2008
New Revision: 132479

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132479
Log:
2008-02-20  Paolo Bonzini  <[EMAIL PROTECTED]>

PR bootstrap/32009
PR bootstrap/32161

* configure.ac (CFLAGS_FOR_TARGET, CXXFLAGS_FOR_TARGET): Compute here.
* configure: Regenerate.

* Makefile.def: Define stage_libcflags for all bootstrap stages.
* Makefile.tpl (STAGE1_LIBCFLAGS, STAGE2_LIBCFLAGS, STAGE3_LIBCFLAGS,
STAGE4_LIBCFLAGS): New.
(CFLAGS_FOR_TARGET, CXXFLAGS_FOR_TARGET): Subst from autoconf, without
$(SYSROOT_CFLAGS_FOR_TARGET) and $(DEBUG_PREFIX_CFLAGS_FOR_TARGET).
(BASE_TARGET_EXPORTS): Append them here to C{,XX}FLAGS.
(EXTRA_TARGET_FLAGS): Append them here to {LIB,}C{,XX}FLAGS.
(configure-stage[+id+]-[+prefix+][+module+]): Pass stage_libcflags
for target modules.  Don't export LIBCFLAGS.
(all-stage[+id+]-[+prefix+][+module+]): Pass stage_libcflags; pass
$(BASE_FLAGS_TO_PASS) where [+args+] was passed, and [+args+] after
the overridden CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET.
(invocations of `all'): Replace $(TARGET_FLAGS_TO_PASS) with
$(EXTRA_TARGET_FLAGS), $(FLAGS_TO_PASS) with $(EXTRA_HOST_FLAGS).
* Makefile.in: Regenerate.

2008-02-20  Paolo Bonzini  <[EMAIL PROTECTED]>

PR bootstrap/32009

* mh-ppc-darwin (BOOT_CFLAGS): Reenable.

2008-02-20  Paolo Bonzini  <[EMAIL PROTECTED]>

* doc/install.texi: Correct references to CFLAGS, replacing them
with BOOT_CFLAGS.  Document flags used during bootstrap for
target libraries.


Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in
trunk/Makefile.tpl
trunk/config/ChangeLog
trunk/config/mh-ppc-darwin
trunk/configure
trunk/configure.ac
trunk/gcc/ChangeLog
trunk/gcc/doc/install.texi


-- 


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

[Bug bootstrap/32009] [4.3/4.4 Regression] building gcc4-4.3/4.4.0-20070518 failed on OSX 10.3.9

[bonzini at gcc dot gnu dot org]

--- Comment #27 from bonzini at gnu dot org  2008-02-20 14:11 ---
Subject: Bug 32009

Author: bonzini
Date: Wed Feb 20 14:10:40 2008
New Revision: 132479

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132479
Log:
2008-02-20  Paolo Bonzini  <[EMAIL PROTECTED]>

PR bootstrap/32009
PR bootstrap/32161

* configure.ac (CFLAGS_FOR_TARGET, CXXFLAGS_FOR_TARGET): Compute here.
* configure: Regenerate.

* Makefile.def: Define stage_libcflags for all bootstrap stages.
* Makefile.tpl (STAGE1_LIBCFLAGS, STAGE2_LIBCFLAGS, STAGE3_LIBCFLAGS,
STAGE4_LIBCFLAGS): New.
(CFLAGS_FOR_TARGET, CXXFLAGS_FOR_TARGET): Subst from autoconf, without
$(SYSROOT_CFLAGS_FOR_TARGET) and $(DEBUG_PREFIX_CFLAGS_FOR_TARGET).
(BASE_TARGET_EXPORTS): Append them here to C{,XX}FLAGS.
(EXTRA_TARGET_FLAGS): Append them here to {LIB,}C{,XX}FLAGS.
(configure-stage[+id+]-[+prefix+][+module+]): Pass stage_libcflags
for target modules.  Don't export LIBCFLAGS.
(all-stage[+id+]-[+prefix+][+module+]): Pass stage_libcflags; pass
$(BASE_FLAGS_TO_PASS) where [+args+] was passed, and [+args+] after
the overridden CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET.
(invocations of `all'): Replace $(TARGET_FLAGS_TO_PASS) with
$(EXTRA_TARGET_FLAGS), $(FLAGS_TO_PASS) with $(EXTRA_HOST_FLAGS).
* Makefile.in: Regenerate.

2008-02-20  Paolo Bonzini  <[EMAIL PROTECTED]>

PR bootstrap/32009

* mh-ppc-darwin (BOOT_CFLAGS): Reenable.

2008-02-20  Paolo Bonzini  <[EMAIL PROTECTED]>

* doc/install.texi: Correct references to CFLAGS, replacing them
with BOOT_CFLAGS.  Document flags used during bootstrap for
target libraries.


Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in
trunk/Makefile.tpl
trunk/config/ChangeLog
trunk/config/mh-ppc-darwin
trunk/configure
trunk/configure.ac
trunk/gcc/ChangeLog
trunk/gcc/doc/install.texi


-- 


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

[Bug target/35258] two memcpy calls merged incorrectly with -O1

[krebbel at gcc dot gnu dot org]

--- Comment #5 from krebbel at gcc dot gnu dot org  2008-02-20 12:59 ---
The assembler code is broken. In case of an overlap mvc copies one byte at a
time and continuing with the next after the first has been written. That's how
we use mvc for memsets.

The mvcs are merged by the dead store elimination pass. I'll try to understand
were it slips through the tests in dse and/or cse.


-- 


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

[Bug rtl-optimization/35232] [4.3/4.4 regression] ICE in fp-int-convert-double.c at -O2

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P1  |P2


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

[Bug rtl-optimization/35232] [4.3/4.4 regression] ICE in fp-int-convert-double.c at -O2

[rsandifo at gcc dot gnu dot org]

--- Comment #3 from rsandifo at gcc dot gnu dot org  2008-02-20 12:17 
---
Subject: Bug 35232

Author: rsandifo
Date: Wed Feb 20 12:16:51 2008
New Revision: 132473

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132473
Log:
gcc/testsuite/
PR rtl-optimization/35232
* gcc.dg/torture/fp-int-convert-float.c: Skip for MIPS16 targets.
* gcc.dg/torture/fp-int-convert-double.c: Likewise.
* gcc.dg/torture/fp-int-convert-long-double.c: Likewise.

Modified:
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
   
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/fp-int-convert-double.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/fp-int-convert-float.c
   
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/fp-int-convert-long-double.c


-- 


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

[Bug middle-end/35249] gcc miscompiles emacs' src/intervals.c when using optimisation on solaris 8

[ebotcazou at gcc dot gnu dot org]

--- Comment #8 from ebotcazou at gcc dot gnu dot org  2008-02-20 11:35 
---
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|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-20 11:35:25
   date||


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

[Bug fortran/35259] PAREN_EXPR: Option to allow for reassociation

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-02-20 10:12 ---
So - should Fortran disable flag_trapping_math and flag_signed_zeros by default
as well?  


-- 


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

[Bug fortran/35259] PAREN_EXPR: Option to allow for reassociation

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-20 10:09 ---
Note that -fassociative-math is only enabled if -fno-signed-zeros and
-fno-trapping-math is specified.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-20 10:09:47
   date||


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

[Bug target/35258] two memcpy calls merged incorrectly with -O1

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-02-20 09:52 ---
Actually the asm looks correct.  mvc is a memmove operation, moving 4 bytes
from string1+1 to string1+2.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu dot
   ||org


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

[Bug target/26674] missed optimization / 128-bit arithmetic.

[pluto at agmk dot net]

--- Comment #4 from pluto at agmk dot net  2008-02-20 09:48 ---
4.2.3 produces:

sqr_1:  xorl%edx, %edx  # 45*movdi_xor_rex64[length = 2]
movq%rdi, %rax  # 11*movdi_1_rex64/2[length = 6]
movq%rdx, %rcx  # 40*movdi_1_rex64/2[length = 6]
imulq   %rdi, %rcx  # 15*muldi3_1_rex64/3   [length = 4]
mulq%rdi# 18*umulditi3_insn [length = 3]
addq%rcx, %rcx  # 17*ashldi3_1_rex64/1  [length = 4]
addq%rdx, %rcx  # 19*adddi_1_rex64/1[length = 3]
movq%rcx, %rdx  # 20*movdi_1_rex64/2[length = 6]
ret # 43return_internal [length = 1]

4.3-svn:

sqr_1:  movq%rdi, %rax  # 35*movdi_1_rex64/2[length = 6]
mulq%rdi# 13*umulditi3_insn [length = 3]
ret # 41return_internal [length = 1]


-- 

pluto at agmk dot net changed:

   What|Removed |Added

  Known to fail|4.1.2 4.2.0 |4.1.2 4.2.3
  Known to work||4.3.0


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

[Bug target/35258] two memcpy calls merged incorrectly with -O1

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-02-20 09:43 ---
This would be an executable testcase:

extern void *memcpy (void *, const void *,  __SIZE_TYPE__);
extern int memcmp(const void *s1, const void *s2, __SIZE_TYPE__ n);
extern void abort(void);

char string1[9] = "1234";
char string2[9] = "1234";

void
bar (void)
{
  unsigned int temp;
  char *p = &string1[2];

  memcpy (&temp, &string1[1], 4);
  memcpy (p, &temp, 4);
  string1[1] = '.';
}

int main()
{
  bar();
  if (memcmp (string1, "1.234", 5) != 0)
abort ();
  return 0;
}

which I can confirm aborts on s390 but not x86_64.  bar looks like

bar:
.LFB2:
st  %r15,60(%r15)
.LCFI0:
larl%r5,.L3
ahi %r15,-104
.LCFI1:
larl%r1,string1+2
l   %r2,.L4-.L3(%r5)
mvc 0(4,%r1),0(%r2)
larl%r1,string1
mvi 1(%r1),46
l   %r15,164(%r15)
br  %r14


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-02-20 09:43:54
   date||


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

[Bug c++/35255] gcc does not do partial ordering on overloaded address resolution

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-20 09:29:16
   date||


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

[Bug fortran/35259] New: PAREN_EXPR: Option to allow for reassociation

[burnus at gcc dot gnu dot org]

Follow up to http://gcc.gnu.org/ml/fortran/2008-02/msg00157.html

Contrary to C, Fortran allows a lot of reassociations (-fassociative-math is
enabled by default in Fortran. THE GCC MANPAGE NEEDS TO BE UPDATED!).

Contrary to C with -fassociative-math, parentheses are still honoured, i.e. "(x
+ 2**52) - 2**52)" remains such while "x + 2**52 - 2**52" can be optimized to
"x".

In C the "= x" happens for both versions using -ffast-math. However, in Fortran
it never is done. We should add an option to do so optionally. One could argue
that option should be enabled by default for -ffast-math.


-- 
   Summary: PAREN_EXPR: Option to allow for reassociation
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug tree-optimization/35254] Should gcc fold DFP expression?

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-20 09:24 ---
It definitely should fold constants, but I have no idea whether this is
implemented.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2008-02-20 09:24:37
   date||


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