[Bug rtl-optimization/34999] Fallthru crossing edges in partition_hot_cold_basic_blocks are not been fixed when the section ends with call insn

[jakub at gcc dot gnu dot org]

--- Comment #15 from jakub at gcc dot gnu dot org  2008-02-29 08:56 ---
.LSFDE3:
.long   .LEFDE3-.LASFDE3# FDE Length
.LASFDE3:
.long   .LASFDE3-.Lframe1   # FDE CIE offset
.long   .LHOTB2 # FDE initial location
.long   .LHOTE2-.LHOTB2 # FDE address range
.long   .LCOLDB2# FDE initial location
.long   .LCOLDE2-.LCOLDB2   # FDE address range
.uleb128 0x0# Augmentation size
.byte   0x4 # DW_CFA_advance_loc4
.long   .LCFI2-.LFB3
.byte   0xe # DW_CFA_def_cfa_offset
.uleb128 0x10
.byte   0x86# DW_CFA_offset, column 0x6
.uleb128 0x2
.byte   0x4 # DW_CFA_advance_loc4
.long   .LCFI3-.LCFI2
.byte   0xd # DW_CFA_def_cfa_register
.uleb128 0x6
.align 8
.LEFDE3:

is not a valid .eh_frame FDE, the
2005-03-31  Caroline Tice  <[EMAIL PROTECTED]>

(output_call_frame_info): Add test to see if function switches text
sections in the middle; if so, use appropriate extra hot and cold
section labels to compute size deltas for the hot and cold sections.

change was totally broken.  There is no such thing as a two ranges FDE in
Dwarf2/3.  FDE starts with FDE length, CIE offset, FDE initial location, FDE
address range, depending on CIE optionally with augmentation size and
augmentation and then CFA instructions.  So, to describe .text/.text.unlikely
split function, you need two FDEs, one describing the .text section, the other
describing .text.unlikely section.  When the code jumps in between the
sections, you need to insert CFA instructions that reflect what really changed.
The easiest would be to use .cfi_* assembler directives that recentish gas
supports and emitting them inline in the code, rather than creating separate
.eh_frame.  But I believe we need some more help from gas - particularly more
powerful .cfi_escape and some easy way to just save current state resp. restore
it.  That way you could save the state at the jump location and restore it at
the jump target and let gas compute what CFA instructions are needed.


-- 


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

[Bug c++/35401] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib

[rwild at gcc dot gnu dot org]

--- Comment #2 from rwild at gcc dot gnu dot org  2008-02-29 12:34 ---
Probably the easiest way to fix this is to fool libtool with a hand-written
libgcc_s.la.

I think PR #5291 is related.


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||Ralf dot Wildenhues at gmx
   ||dot de


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

[Bug c++/35405] [4.2/4.3/4.4 Regression] Internal compiler error

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-29 12:48 ---
t.C(13): error #501: argument of type "int" is incompatible with template
parameter of type "C *"
  template  class C, typename X, C* = 0>
 ^

2.95.4 rejects this with

t.C: In instantiation of `check':
t.C:39:   instantiated from here
t.C:39: `C' is not a template
t.C:15: `C' is not a template
t.C:23: no method `check::test'


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-invalid-code
  Known to fail||3.3.6
  Known to work||2.95.4
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2008-02-29 12:48:25
   date||
Summary|Internal compiler error |[4.2/4.3/4.4 Regression]
   ||Internal compiler error
   Target Milestone|--- |4.2.4
Version|unknown |4.3.0


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

[Bug tree-optimization/35402] Store CCP will not inline static const variable which is default initialized

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-02-29 12:43 ---
Please change tree-ssa-sccvn.c:try_to_simplify accordingly (eventually that
should use a common helper function to extract a constant initializer for
the tcc_reference case, too).  Thanks!


-- 


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

[Bug target/34571] [4.3/4.4 Regression] Segfault in alpha_expand_mov at -O3

[tbm at cyrius dot com]

--- Comment #10 from tbm at cyrius dot com  2008-02-29 12:23 ---
RTH, can you take the lead on submitting/applying this patch to fix
an Alpha bug?


-- 


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

[Bug rtl-optimization/33009] -frtl-abstract-sequences causes an infinite loop

[loki at gcc dot gnu dot org]

--- Comment #5 from loki at gcc dot gnu dot org  2008-02-29 13:06 ---
Created an attachment (id=15245)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15245&action=view)
infinite loop patch v1

This proposed patch fixes the reported bug on i386.

I am going to test it for some other targets, and create some testcases.
After that I will send it to the gcc-patches list.


-- 


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

[Bug middle-end/35400] [4.4 Regression] -Wtype-limits -O2 causes ICE tree check: expected ssa_name, have addr_expr in get_value_range, at tree-vrp.c:469

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-02-29 12:50 ---
Likely caused by diegos change.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dnovillo at gcc dot gnu dot
   ||org


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

[Bug c++/31775] static object mangling conflicts with extern object

[mueller at gcc dot gnu dot org]

--- Comment #7 from mueller at gcc dot gnu dot org  2008-02-29 13:57 ---
how about 

extern "C" void abort();
extern "C" { static int i; }
int *p = &i;
int main()
{ 
  int i;
  { 
extern int i;
i = 1;
*p = 2;
if (i == 2)
  abort ();
  }
  return 0;
}

in this case, the "i" name should not be mangled, right?


-- 

mueller at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mueller at gcc dot gnu dot
   ||org


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

[Bug c++/35401] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib

[howarth at nitro dot med dot uc dot edu]

--- Comment #3 from howarth at nitro dot med dot uc dot edu  2008-02-29 
14:00 ---
I doubt that since gcc 4.2.0 doesn't have the problem and all of gcc 4.3.0's
shared libraries are linked incorrectly against the system libgcc on darwin.

(In reply to comment #2)
> Probably the easiest way to fix this is to fool libtool with a hand-written
> libgcc_s.la.
> 
> I think PR #5291 is related.
> 


-- 


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

[Bug c++/35401] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib

[howarth at nitro dot med dot uc dot edu]

--- Comment #4 from howarth at nitro dot med dot uc dot edu  2008-02-29 
14:03 ---
I think this is likely due to Jakub's fix for PR 30572 instead.


-- 


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[howarth at nitro dot med dot uc dot edu]

--- Comment #24 from howarth at nitro dot med dot uc dot edu  2008-02-29 
14:06 ---
Jakub,
I think your fix to this PR could be the cause of
PR 35401. All of gcc 4.3.0's shared libraries are being
linked against the system libgcc in /usr/lib on darwin
rather than the libgcc built and installed by gcc 4.3.0
(in say /sw/lib/gcc4.3/lib for instance).
Jack


-- 


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

[Bug c++/35401] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-02-29 14:58 ---
No idea why do you think it I had anything to do with that PR.


-- 


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

[Bug c++/35401] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib

[agn at noc dot soton dot ac dot uk]

-- 

agn at noc dot soton dot ac dot uk changed:

   What|Removed |Added

   Severity|normal  |blocker


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

[Bug c++/35401] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib

[howarth at nitro dot med dot uc dot edu]

--- Comment #6 from howarth at nitro dot med dot uc dot edu  2008-02-29 
15:50 ---
My mistake. I looked at your marking of PR 30572 as fixed rather than the patch
committed.


-- 


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

[Bug ada/35050] [4.x regression] renames entities not in symbol table

[tero dot koskinen at iki dot fi]

--- Comment #2 from tero dot koskinen at iki dot fi  2008-02-29 15:52 
---
Created an attachment (id=15246)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15246&action=view)
Fix .ali file parsing in xref_lib.adb.

The patch attached in case the url doesn't work.


-- 


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

[Bug c++/35401] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2008-02-29 16:05 ---
CCing a build system maintainer.

Did this ever work?  That is, is this a regression?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org, bonzini at gnu dot org


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

[Bug c++/35401] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib

[howarth at nitro dot med dot uc dot edu]

--- Comment #9 from howarth at nitro dot med dot uc dot edu  2008-02-29 
16:12 ---
I'm positive I tested the committed patch...

Author: bonzini
Date: Wed Dec 19 14:28:32 2007
New Revision: 131062

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131062
Log:
2007-12-19  Etsushi Kato  <[EMAIL PROTECTED]>
Paolo Bonzini  <[EMAIL PROTECTED]>

PR target/30572
* Makefile.in: Use @shlib_slibdir@ substitution to get correct install
name
on darwin.
* config/t-slibgcc-darwin: Use @shlib_slibdir@ for -install_name.


Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/Makefile.in
trunk/libgcc/config/t-slibgcc-darwin

and it was working. The proposed alternative didn't. I am testing regressing
r131198 from my build tree to see if that solves the problem.

(In reply to comment #8)
> CCing a build system maintainer.
> 
> Did this ever work?  That is, is this a regression?
> 


-- 


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

[Bug ada/35050] [4.x regression] renames entities not in symbol table

[tero dot koskinen at iki dot fi]

--- Comment #1 from tero dot koskinen at iki dot fi  2008-02-29 15:50 
---
I think the problem is in Xref_lib package (xref_lib.adb). It doesn't parse the
current .ali file format properly.

The patch (against gcc-trunk r131693) at
http://iki.fi/tero.koskinen/gcc/gcc-ada-xref_lib_adb.diff fixes parsing for me.

Some details:
The code expects .ali file format for renamings to be:
4V12*My_plus{integer}=4:58 2|11r20

But if I understood the code correctly, the format is:
4V12*My_plus=4:58{integer} 2|11r20

The patch moves =NUMBER:NUMBER handling before {integer}&co. handling.

gnatxref output after the patch:
Add  function
  Decl:  pb_renaming.ads5:12
  Ref:   pb_renaming.adb   11:8
My_plus  function
  Decl:  pb_renaming.ads4:12
  Ref:   pb_renaming.adb   11:20

I haven't tested very complex cases, but for random gtkada code the patch
seemed to work.


-- 


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

[Bug c++/35401] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib

[howarth at nitro dot med dot uc dot edu]

--- Comment #7 from howarth at nitro dot med dot uc dot edu  2008-02-29 
16:03 ---
Could this problem be caused by...

Author: rsandifo
Date: Thu Dec 27 11:26:06 2007
New Revision: 131198

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131198
Log:
libgcc/
* Makefile.in (all): Use install-leaf rather than install.
(install): Split most of the rule into...
(install-leaf): ...this new one.

Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/Makefile.in


-- 


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

[Bug ada/35050] [4.x regression] renames entities not in symbol table

[sam at gcc dot gnu dot org]

--- Comment #3 from sam at gcc dot gnu dot org  2008-02-29 16:10 ---
Tero,

your patch is similar to the one I proposed a few days ago :)

http://thread.gmane.org/gmane.comp.gcc.patches/157295


-- 


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

[Bug tree-optimization/35406] New: gfortran.dg/ldist-1.f90 and gcc.dg/tree-ssa/ldist-4.c don't work

[hjl dot tools at gmail dot com]

On Linux/x86-64, I got

FAIL: gfortran.dg/ldist-1.f90  -O  scan-tree-dump-times ldist "distributed:
split to 4 loops" 1
FAIL: gcc.dg/tree-ssa/ldist-4.c scan-tree-dump-times ldist "distributed: split
to 2 loops" 0


-- 
   Summary: gfortran.dg/ldist-1.f90 and gcc.dg/tree-ssa/ldist-4.c
don't work
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
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=35406

[Bug bootstrap/35407] tries to link 32 instead of 64 bit version of libasound.so in midi-alsa

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-29 17:12 ---
--prefix=/usr --libdir=/usr/lib64 \
--libexecdir=/usr/lib64

Why are you trying to build a system compiler?


-- 


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

[Bug c++/35401] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib

[howarth at nitro dot med dot uc dot edu]

--- Comment #10 from howarth at nitro dot med dot uc dot edu  2008-02-29 
16:52 ---
Regressing r131198 eliminates the problem here...

otool -L libgfortran.3.dylib
libgfortran.3.dylib:
/sw/lib/gcc4.3/lib/libgfortran.3.dylib (compatibility version 4.0.0,
current version 4.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 111.0.0)
/sw/lib/gcc4.3/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)

...at least for a manual rebuilding of the gcc and other library build
directories. I'll do a complete build of gcc trunk with r131198 regressed next.


-- 


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

[Bug bootstrap/35407] New: tries to link 32 instead of 64 bit version of libasound.so in midi-alsa

[axelbergerhoff at compuserve dot com]

libgjsmalsa.la (32 bit) is built, 64 bit version fails
same with gcc-4.2.2 and 4.2.3

Tools used:
binutils  2.18.0
gmp   4.2.2
bison 2.3
m41.4.10
flex  2.5.33
expect5.43.0
dejagnu   1.4.4
makeinfo  4.11
libtool   1.5.24
gcc   4.2.2 w/o java
gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.2.2/configure --prefix=/usr --libdir=/usr/lib64
--libexecdir=/usr/lib64 --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-c99 --enable-long-long --enable-clocale=gnu
--enable-languages=c,c++ --disable-libstdcxx-pch
Thread model: posix
gcc version 4.2.2


Building gcc-4.2.3:

sed -i 's/install_to_$(INSTALL_DEST) //' libiberty/Makefile.in
  (to keep libiberty from binutils)

mkdir -v ../gcc-build-4.2.3 &&
  cd ../gcc-build-4.2.3

export PKG_CONFIG_PATH="${PKG_CONFIG_PATH64}" &&
../gcc-4.2.3/configure --prefix=/usr --libdir=/usr/lib64 \
--libexecdir=/usr/lib64 --enable-shared --enable-threads=posix \
--enable-__cxa_atexit --enable-c99 --enable-long-long \
--enable-clocale=gnu --disable-libstdcxx-pch --enable-multilib \
--enable-languages=c,c++,java

echo $PKG_CONFIG_PATH
/usr/lib64/pkgconfig:/opt/qt/lib64/pkgconfig:/opt/kde/lib64/pkgconfig:/usr/X11R7/lib64/pkgconfig

make bootstrap
..
Making all in midi-alsa
make[6]: Entering directory
`/usr/src/gcc-build-4.2.3/x86_64-unknown-linux-gnu/libjava/classpath/native/jni/midi-alsa'
if /bin/sh ../../../libtool --mode=compile /usr/src/gcc-build-4.2.3/./gcc/xgcc
-B/usr/src/gcc-build-4.2.3/./gcc/ -B/usr/x86_64-unknown-linux-gnu/bin/
-B/usr/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/x86_64-unknown-linux-gnu/include -isystem
/usr/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../../../../../../../gcc-4.2.3/libjava/classpath/native/jni/midi-alsa
-I../../../include  -I../../../../../../../gcc-4.2.3/libjava/classpath/include
-I../../../../../../../gcc-4.2.3/libjava/classpath/native/jni/classpath
-I../../../../../../../gcc-4.2.3/libjava/classpath/native/target/Linux
-I../../../../../../../gcc-4.2.3/libjava/classpath/native/target/generic
`pkg-config  --cflags-only-I alsa`  -pedantic -W -Wall -Wmissing-declarations
-Wwrite-strings -Wmissing-prototypes -Wno-long-long -Wstrict-prototypes 
`pkg-config --cflags-only-other alsa` -O2 -g -O2  -MT
gnu_javax_sound_midi_alsa_AlsaMidiSequencerDevice.lo -MD -MP -MF
".deps/gnu_javax_sound_midi_alsa_AlsaMidiSequencerDevice.Tpo" -c -o
gnu_javax_sound_midi_alsa_AlsaMidiSequencerDevice.lo
../../../../../../../gcc-4.2.3/libjava/classpath/native/jni/midi-alsa/gnu_javax_sound_midi_alsa_AlsaMidiSequencerDevice.c;
\
then mv -f
".deps/gnu_javax_sound_midi_alsa_AlsaMidiSequencerDevice.Tpo"
".deps/gnu_javax_sound_midi_alsa_AlsaMidiSequencerDevice.Plo"; else rm -f
".deps/gnu_javax_sound_midi_alsa_AlsaMidiSequencerDevice.Tpo"; exit 1; fi
mkdir .libs
/usr/src/gcc-build-4.2.3/./gcc/xgcc -B/usr/src/gcc-build-4.2.3/./gcc/
-B/usr/x86_64-unknown-linux-gnu/bin/ -B/usr/x86_64-unknown-linux-gnu/lib/
-isystem /usr/x86_64-unknown-linux-gnu/include -isystem
/usr/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../../../../../../../gcc-4.2.3/libjava/classpath/native/jni/midi-alsa
-I../../../include -I../../../../../../../gcc-4.2.3/libjava/classpath/include
-I../../../../../../../gcc-4.2.3/libjava/classpath/native/jni/classpath
-I../../../../../../../gcc-4.2.3/libjava/classpath/native/target/Linux
-I../../../../../../../gcc-4.2.3/libjava/classpath/native/target/generic
-I/usr/include/alsa -pedantic -W -Wall -Wmissing-declarations -Wwrite-strings
-Wmissing-prototypes -Wno-long-long -Wstrict-prototypes -O2 -g -O2 -MT
gnu_javax_sound_midi_alsa_AlsaMidiSequencerDevice.lo -MD -MP -MF
.deps/gnu_javax_sound_midi_alsa_AlsaMidiSequencerDevice.Tpo -c
../../../../../../../gcc-4.2.3/libjava/classpath/native/jni/midi-alsa/gnu_javax_sound_midi_alsa_AlsaMidiSequencerDevice.c
 -fPIC -DPIC -o .libs/gnu_javax_sound_midi_alsa_AlsaMidiSequencerDevice.o
if /bin/sh ../../../libtool --mode=compile /usr/src/gcc-build-4.2.3/./gcc/xgcc
-B/usr/src/gcc-build-4.2.3/./gcc/ -B/usr/x86_64-unknown-linux-gnu/bin/
-B/usr/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/x86_64-unknown-linux-gnu/include -isystem
/usr/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../../../../../../../gcc-4.2.3/libjava/classpath/native/jni/midi-alsa
-I../../../include  -I../../../../../../../gcc-4.2.3/libjava/classpath/include
-I../../../../../../../gcc-4.2.3/libjava/classpath/native/jni/classpath
-I../../../../../../../gcc-4.2.3/libjava/classpath/native/target/Linux
-I../../../../../../../gcc-4.2.3/libjava/classpath/native/target/generic
`pkg-config  --cflags-only-I alsa`  -pedantic -W -Wall -Wmissing-declarations
-Wwrite-strings -Wmissing-prototypes -Wno-long-long -Wstrict-prototypes 
`pkg-config --cflags-only-other alsa` -O2 -g -O2  -MT
gnu_javax_sound_midi_alsa_AlsaPortDevice.lo -MD -MP -MF
".deps/gnu_javax_sound_midi_alsa_AlsaPortDevice.Tpo" -c -o
gnu_javax_sound_midi_alsa_AlsaPortDevice.lo
..

[Bug target/35408] New: Bad XFmode size and alignment for x86

[hjl dot tools at gmail dot com]

i386-modes.def has

---
/* In ILP32 mode, XFmode has size 12 and alignment 4.
  In LP64 mode, XFmode has size and alignment 16.  */
ADJUST_FLOAT_FORMAT (XF, (TARGET_128BIT_LONG_DOUBLE
 ? &ieee_extended_intel_128_format
 : TARGET_96_ROUND_53_LONG_DOUBLE
 ? &ieee_extended_intel_96_round_53_format
 : &ieee_extended_intel_96_format));
ADJUST_BYTESIZE  (XF, TARGET_128BIT_LONG_DOUBLE ? 16 : 12);
ADJUST_ALIGNMENT (XF, TARGET_128BIT_LONG_DOUBLE ? 16 : 4);
---

The comment don't match the code.  XFmode is independent of ILP32
and LP64.  However, in i386.h, there is

/* Decide whether a variable of mode MODE should be 128 bit aligned.  */
#define ALIGN_MODE_128(MODE) \
 ((MODE) == XFmode || SSE_REG_MODE_P (MODE))

What is the real alignment of XFmode in ILP32 mode?

According to i386 and x86-64 psABIs,  in LP32 mode, XFmode has
size 12 and alignment 4 and in LP64 mode, XFmode has size and
alignment 16. It doesn't make senses to have XFmode of size 12
and alignment 16 in ILP32 mode since it doesn't work with array
of XFmode.


-- 
   Summary: Bad XFmode size and alignment for x86
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug fortran/35299] scope of variables in statement function do not acquire rank from host

[fxcoudert at gcc dot gnu dot org]

--- Comment #2 from fxcoudert at gcc dot gnu dot org  2008-02-29 17:53 
---
I disagree. In Fortran 2003 12.5.4, C1263/R1238 says "The function-name and
each dummy-arg-name shall be specified, explicitly or implicitly, to be
scalar.". Intel accepts it, but IBM, g95 and (most importantly) Lahey think
it's invalid.


However, the error message should point to the statement function. The patch
below gives, in my opinion, a better error message:

  HSTAR(E,B)=B**.4*((1.25*FUN(-E/40)+.18)) ! Doesn't work.  
  1
Error: Argument 'e' of statement function 'hstar' at (1) must be scalar


Index: resolve.c
===
--- resolve.c   (revision 132578)
+++ resolve.c   (working copy)
@@ -240,8 +240,9 @@
{
  if (sym->as != NULL)
{
- gfc_error ("Argument '%s' of statement function at %L must "
-"be scalar", sym->name, &sym->declared_at);
+ gfc_error ("Argument '%s' of statement function '%s' at %L "
+"must be scalar", sym->name, proc->name,
+&proc->declared_at);
  continue;
}



-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Keywords|rejects-valid   |diagnostic, patch
   Last reconfirmed|2008-02-23 20:22:34 |2008-02-29 17:53:40
   date||


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

[Bug fortran/34956] -fbounds-check: bounds_check_9.f90: Use of uninitialized memory

[fxcoudert at gcc dot gnu dot org]

--- Comment #2 from fxcoudert at gcc dot gnu dot org  2008-02-29 18:27 
---
The following patch fixes it, but I don't know yet if it regtests...

Index: trans-array.c
===
--- trans-array.c   (revision 132578)
+++ trans-array.c   (working copy)
@@ -2912,9 +2912,13 @@

   for (ss = loop->ss; ss != gfc_ss_terminator; ss = ss->loop_chain)
{
+ stmtblock_t inner;
+
  if (ss->type != GFC_SS_SECTION)
continue;

+ gfc_start_block (&inner);
+
  /* TODO: range checking for mapped dimensions.  */
  info = &ss->data.info;

@@ -2941,7 +2945,7 @@
  asprintf (&msg, "Zero stride is not allowed, for dimension %d "
"of array '%s'", info->dim[n]+1,
ss->expr->symtree->name);
- gfc_trans_runtime_check (tmp, &block, &ss->expr->where, msg);
+ gfc_trans_runtime_check (tmp, &inner, &ss->expr->where, msg);
  gfc_free (msg);

  desc = ss->data.info.descriptor;
@@ -2983,7 +2987,7 @@
  asprintf (&msg, "%s, lower bound of dimension %d of array '%s'"
" exceeded (%%ld < %%ld)", gfc_msg_fault,
info->dim[n]+1, ss->expr->symtree->name);
- gfc_trans_runtime_check (tmp, &block, &ss->expr->where, msg,
+ gfc_trans_runtime_check (tmp, &inner, &ss->expr->where, msg,
   fold_convert (long_integer_type_node,
 info->start[n]),
   fold_convert (long_integer_type_node,
@@ -2999,7 +3003,7 @@
  asprintf (&msg, "%s, upper bound of dimension %d of array "
"'%s' exceeded (%%ld > %%ld)", gfc_msg_fault,
info->dim[n]+1, ss->expr->symtree->name);
- gfc_trans_runtime_check (tmp, &block, &ss->expr->where, msg,
+ gfc_trans_runtime_check (tmp, &inner, &ss->expr->where, msg,
fold_convert (long_integer_type_node, info->start[n]),
fold_convert (long_integer_type_node, ubound));
  gfc_free (msg);
@@ -3021,7 +3025,7 @@
  asprintf (&msg, "%s, lower bound of dimension %d of array '%s'"
" exceeded (%%ld < %%ld)", gfc_msg_fault,
info->dim[n]+1, ss->expr->symtree->name);
- gfc_trans_runtime_check (tmp, &block, &ss->expr->where, msg,
+ gfc_trans_runtime_check (tmp, &inner, &ss->expr->where, msg,
   fold_convert (long_integer_type_node,
 tmp2),
   fold_convert (long_integer_type_node,
@@ -3036,7 +3040,7 @@
  asprintf (&msg, "%s, upper bound of dimension %d of array "
"'%s' exceeded (%%ld > %%ld)", gfc_msg_fault,
info->dim[n]+1, ss->expr->symtree->name);
- gfc_trans_runtime_check (tmp, &block, &ss->expr->where, msg,
+ gfc_trans_runtime_check (tmp, &inner, &ss->expr->where, msg,
fold_convert (long_integer_type_node, tmp2),
fold_convert (long_integer_type_node, ubound));
  gfc_free (msg);
@@ -3054,30 +3058,30 @@
  tree tmp3;

  tmp3 = fold_build2 (NE_EXPR, boolean_type_node, tmp,
size[n]);
-
- /* For optional arguments, only check bounds if the
-argument is present.  */
- if (ss->expr->symtree->n.sym->attr.optional
- || ss->expr->symtree->n.sym->attr.not_always_present)
-   {
- tree cond;
-
- cond = gfc_conv_expr_present (ss->expr->symtree->n.sym);
- tmp3 = fold_build2 (TRUTH_AND_EXPR, boolean_type_node,
- cond, tmp3);
-   }
-
  asprintf (&msg, "%s, size mismatch for dimension %d "
"of array '%s' (%%ld/%%ld)", gfc_msg_bounds,
info->dim[n]+1, ss->expr->symtree->name);
- gfc_trans_runtime_check (tmp3, &block, &ss->expr->where, msg,
+ gfc_trans_runtime_check (tmp3, &inner, &ss->expr->where, msg,
fold_convert (long_integer_type_node, tmp),
fold_convert (long_integer_type_node, size[n]));
  gfc_free (msg);
}
  else
-   size[n] = gfc_evaluate_now (tmp, &block);
+   size[n] = gfc_evaluate_now (tmp, &inner);
}
+
+ tmp = gfc_finish_block (&inner);
+
+ /* For optional arguments, only check bounds if the argument is
+

[Bug rtl-optimization/35404] ra-conflict does not handle subregs optimally

[ian at airs dot com]

--- Comment #2 from ian at airs dot com  2008-02-29 18:43 ---
Whoops, you have to use to -fno-split-wide-types, not -fno-wide-types.  Sorry.


-- 


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

[Bug fortran/34955] transfer_assumed_size_1.f90: Valgrind error: invalid read of size 3

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2008-02-29 19:50 
---
(In reply to comment #2)
> Tobias, what target and options are you compiling with? I can't reproduce this
> on x86_64-linux...

Nor on i686-linux.


-- 


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

[Bug c++/35401] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib

[howarth at nitro dot med dot uc dot edu]

--- Comment #13 from howarth at nitro dot med dot uc dot edu  2008-02-29 
20:17 ---
Created an attachment (id=15248)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15248&action=view)
link commands on powerpc-apple-darwin9 for libgfortran without r131198


-- 


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

[Bug bootstrap/35407] tries to link 32 instead of 64 bit version of libasound.so in midi-alsa

[axelbergerhoff at compuserve dot com]

--- Comment #2 from axelbergerhoff at compuserve dot com  2008-02-29 20:29 
---
(In reply to comment #1)
> --prefix=/usr --libdir=/usr/lib64 \
> --libexecdir=/usr/lib64
> 
> Why are you trying to build a system compiler?
> 

I'm building a system.
But these options should not cause linking the wrong library.


-- 


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

[Bug fortran/35299] scope of variables in statement function do not acquire rank from host

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #3 from sgk at troutmask dot apl dot washington dot edu  
2008-02-29 20:15 ---
Subject: Re:  scope of variables in statement function do not acquire rank from
host

On Fri, Feb 29, 2008 at 05:53:40PM -, fxcoudert at gcc dot gnu dot org
wrote:
> I disagree. In Fortran 2003 12.5.4, C1263/R1238 says "The function-name and
> each dummy-arg-name shall be specified, explicitly or implicitly, to be
> scalar.". Intel accepts it, but IBM, g95 and (most importantly) Lahey think
> it's invalid.
> 
> 
> However, the error message should point to the statement function. The patch
> below gives, in my opinion, a better error message:
> 
>   HSTAR(E,B)=B**.4*((1.25*FUN(-E/40)+.18)) ! Doesn't work.  
>   1
> Error: Argument 'e' of statement function 'hstar' at (1) must be scalar
> 

I disagree with your disagreement. :-)  Gordon Sande and Richard Maine
also disagrees with you (see c.l.f threads "I've never seen this
before in 30 years - what is this?" and "What is this").

>From Fortran 95, Sec. 12.5.4, lines 38 and 39:

  The dummy arguments have a scope of the statement function.  Each
  dummy argument has the same type and type parameters as the 
  entity of the same name in the scoping unit containing the statement
  function.

Note, this passage does not include rank.


-- 


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

[Bug c++/35401] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib

[howarth at nitro dot med dot uc dot edu]

--- Comment #14 from howarth at nitro dot med dot uc dot edu  2008-02-29 
20:29 ---
I would also add that despite having different linkages...

otool -L
/sw/src/fink.build/gcc43-4.3.0-20080226/darwin_objdir/powerpc-apple-darwin9/ppc64/libgfortran/.libs/libgfortran.3.dylib
/sw/src/fink.build/gcc43-4.3.0-20080226/darwin_objdir/powerpc-apple-darwin9/ppc64/libgfortran/.libs/libgfortran.3.dylib:
/sw/lib/gcc4.3/lib/ppc64/libgfortran.3.dylib (compatibility version
4.0.0, current version 4.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 111.0.0)
/usr/lib/libgcc_s_ppc64.1.dylib (compatibility version 1.0.0, current
version 1.0.0)

vs

 otool -L
/sw/src/fink.build/gcc43-4.3.0-20080228/darwin_objdir/powerpc-apple-darwin9/ppc64/libgfortran/.libs/libgfortran.3.dylib
/sw/src/fink.build/gcc43-4.3.0-20080228/darwin_objdir/powerpc-apple-darwin9/ppc64/libgfortran/.libs/libgfortran.3.dylib:
/sw/lib/gcc4.3/lib/ppc64/libgfortran.3.dylib (compatibility version
4.0.0, current version 4.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 111.0.0)
/sw/lib/gcc4.3/lib/libgcc_s_ppc64.1.dylib (compatibility version 1.0.0,
current version 1.0.0)

both the build with and without r131198 generate identical libgfortran.la files
and there are no obvious differences in the Makefiles generated (attached).


-- 


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

[Bug c++/35401] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib

[howarth at nitro dot med dot uc dot edu]

--- Comment #15 from howarth at nitro dot med dot uc dot edu  2008-02-29 
20:31 ---
Created an attachment (id=15249)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15249&action=view)
differences between Makefile's generated in libgfortran with and without
r131198


-- 


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

[Bug c++/35401] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib

[howarth at nitro dot med dot uc dot edu]

--- Comment #12 from howarth at nitro dot med dot uc dot edu  2008-02-29 
20:17 ---
Created an attachment (id=15247)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15247&action=view)
link commands on powerpc-apple-darwin9 for libgfortran with r131198


-- 


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

[Bug c++/35401] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib

[howarth at nitro dot med dot uc dot edu]

--- Comment #11 from howarth at nitro dot med dot uc dot edu  2008-02-29 
20:15 ---
In case anyone sees something I am missing, I have attached the link commands
for libgfortran.dylib from a gcc 4.3.0 build on powerpc-apple-darwin9 with
(libgfortran_badlink.txt) and without (libgfortran_godlink) r131198 applied
to current gcc 4.3.0 branch.


-- 


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

[Bug fortran/35299] scope of variables in statement function do not acquire rank from host

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #5 from sgk at troutmask dot apl dot washington dot edu  
2008-02-29 20:41 ---
Subject: Re:  scope of variables in statement function do not acquire rank from
host

On Fri, Feb 29, 2008 at 08:23:16PM -, fxcoudert at gcc dot gnu dot org
wrote:
> (In reply to comment #3)
> >   The dummy arguments have a scope of the statement function.  Each
> >   dummy argument has the same type and type parameters as the 
> >   entity of the same name in the scoping unit containing the statement
> >   function.
> > 
> > Note, this passage does not include rank.
> 
> No, but it does not say that they are scalar either. It does not say "Each
> dummy argument is a scalar of the same type and type parameters...".
> 
> If we follow this interpretation, then what does "The function-name
> and each dummy-arg-name shall be specified, explicitly or implicitly,
> to be scalar"  mean? In your (and Richard Maine's and ...) reading,
> the dummy arguments are by definition scalar, and so how can they be
> "specified, explicitly or implicitly,
> to be scalar". Or, to say it the other way around, let's say that I want to
> break this particular constraint, how do I explicitly specify one of my dummy
> arguments not to be a scalar?
> 
> I'm thoroughly confused.
> 

Don't worry, I share your confusion (when I read the standard). :)

I think the passage you quote applies to the following code:

  program z
real :: y = 2.
real :: x(5) = 1.
f(x(2:4)) = 2 * sum(x)   ! dummy arg is an array.
g(y) = y * x ! function g is an array because of x.
  end program z

I just found the definition of type parameters in 2.4.1.1.
"The type parameters are KIND and LEN."  All other attributes
are irrelevant.

PS: I see you just found the c.l.f threads.


-- 


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

[Bug java/35410] New: clone() for array types has incorrect return type

[gcc dot ank2 at spamgourmet dot com]

The clone() method for array types incorrectly returns Object. But the
JLS3, 10.7 Array Members states: "The members of an array type are all
of the following: [...] The return type of the clone method of an array
type T[] is T[]."

The following Java class triggers the problem:

public class Test {
int[] x = new int[1];
int[] y = x.clone();
}

# gcj Test.java
Test.java:3: error: Type mismatch: cannot convert from Object to int[]
int[] y = x.clone();
  ^
1 problem (1 error)

# gcj --version
gcj (Debian 4.3-20080202-1) 4.3.0 20080202 (experimental) [trunk revision
132072]
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


-- 
   Summary: clone() for array types has incorrect return type
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc dot ank2 at spamgourmet dot com


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

[Bug java/35410] clone() for array types has incorrect return type

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-29 21:04 ---
The java source compiler has been removed so this is mostly a ecj bug. 


-- 


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

[Bug middle-end/19984] nan should be C99 built-in

[uros at gcc dot gnu dot org]

--- Comment #4 from uros at gcc dot gnu dot org  2008-02-29 20:56 ---
Subject: Bug 19984

Author: uros
Date: Fri Feb 29 20:55:19 2008
New Revision: 132777

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132777
Log:
PR middle-end/19984
* builtins.def (BUILT_IN_NAN): Define as c99 builtin
using DEF_C99_BUILTIN.
(BUILT_IN_NANF): Ditto.
(BUILT_IN_NANL): Ditto.

testsuite/ChangeLog:

PR middle-end/19984
* gcc.dg/pr19984.c: New test.
* gcc.dg/dfp/compare-special.h: Use _nan instead of nan as the
name of the variable.

PR target/25477
* config/darwin-ppc-ldouble-patch.def (BUILT_IN_NANL): Add.


Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr19984.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/builtins.def
branches/gcc-4_3-branch/gcc/config/darwin-ppc-ldouble-patch.def
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/dfp/compare-special.h


-- 


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

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

[uros at gcc dot gnu dot org]

--- Comment #68 from uros at gcc dot gnu dot org  2008-02-29 20:56 ---
Subject: Bug 25477

Author: uros
Date: Fri Feb 29 20:55:19 2008
New Revision: 132777

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132777
Log:
PR middle-end/19984
* builtins.def (BUILT_IN_NAN): Define as c99 builtin
using DEF_C99_BUILTIN.
(BUILT_IN_NANF): Ditto.
(BUILT_IN_NANL): Ditto.

testsuite/ChangeLog:

PR middle-end/19984
* gcc.dg/pr19984.c: New test.
* gcc.dg/dfp/compare-special.h: Use _nan instead of nan as the
name of the variable.

PR target/25477
* config/darwin-ppc-ldouble-patch.def (BUILT_IN_NANL): Add.


Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr19984.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/builtins.def
branches/gcc-4_3-branch/gcc/config/darwin-ppc-ldouble-patch.def
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/dfp/compare-special.h


-- 


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

[Bug fortran/35299] scope of variables in statement function do not acquire rank from host

[fxcoudert at gcc dot gnu dot org]

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2008-02-29 20:23 
---
(In reply to comment #3)
>   The dummy arguments have a scope of the statement function.  Each
>   dummy argument has the same type and type parameters as the 
>   entity of the same name in the scoping unit containing the statement
>   function.
> 
> Note, this passage does not include rank.

No, but it does not say that they are scalar either. It does not say "Each
dummy argument is a scalar of the same type and type parameters...".

If we follow this interpretation, then what does "The function-name and each
dummy-arg-name shall be specified, explicitly or implicitly, to be scalar"
mean? In your (and Richard Maine's and ...) reading, the dummy arguments are by
definition scalar, and so how can they be "specified, explicitly or implicitly,
to be scalar". Or, to say it the other way around, let's say that I want to
break this particular constraint, how do I explicitly specify one of my dummy
arguments not to be a scalar?

I'm thoroughly confused.


-- 


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

[Bug c++/35315] [4.4 regression] ICE with attribute transparent_union

[dgregor at gcc dot gnu dot org]

--- Comment #3 from dgregor at gcc dot gnu dot org  2008-02-29 21:42 ---
Subject: Bug 35315

Author: dgregor
Date: Fri Feb 29 21:41:38 2008
New Revision: 132779

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132779
Log:
2008-02-29  Douglas Gregor  <[EMAIL PROTECTED]>

PR c++/35315
* tree-inline.c (build_duplicate_type): When we make a
duplicate type, make it unique in the canonical types system.

2008-02-29  Douglas Gregor  <[EMAIL PROTECTED]>

PR c++/35315
* g++.dg/ext/attrib32.C: Add another test case.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/attrib32.C
trunk/gcc/tree-inline.c


-- 


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

[Bug middle-end/35411] New: internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1075

[ismail at namtrac dot org]

While regtesting on MacOSX Leopard I hit this :

/Users/cartman/Sources/gcc/gcc/testsuite/gcc.c-torture/execute/991118-1.c: In
function 'main':
/Users/cartman/Sources/gcc/gcc/testsuite/gcc.c-torture/execute/991118-1.c:59:
internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1075
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
compiler exited with status 1

Using built-in specs.
Target: i686-apple-darwin9
Configured with: ../configure --prefix=/Users/cartman/Sources/gcc/obj
--enable-languages=c,c++ --with-gxx-include-dir=/usr/include/c++/4.0.0
--build=i686-apple-darwin9 --with-arch=nocona --with-tune=generic --disable-nls
--disable-mudflap --disable-libmudflap --disable-libssp
Thread model: posix
gcc version 4.4.0 20080229 (experimental) [trunk revision 132769] (GCC)


-- 
   Summary: internal compiler error: in set_ssa_val_to, at tree-ssa-
sccvn.c:1075
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ismail at namtrac dot org
 GCC build triplet: i686-apple-darwin9


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

[Bug c/34587] gcc.dg/initpri1.c fails on powerpc-apple-darwin

[ismail at namtrac dot org]

--- Comment #3 from ismail at namtrac dot org  2008-02-29 21:28 ---
This also fails on i686-apple-darwin9 so its not powerpc specific.


-- 

ismail at namtrac dot org changed:

   What|Removed |Added

 CC||ismail at namtrac dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-29 21:28:54
   date||


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

[Bug java/35410] clone() for array types has incorrect return type

[tromey at gcc dot gnu dot org]

--- Comment #2 from tromey at gcc dot gnu dot org  2008-02-29 21:56 ---
Confirmed.
We probably need to make and upload a new canonical ecj jar.


-- 

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 |2008-02-29 21:56:24
   date||


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

[Bug c++/35401] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib

[agn at noc dot soton dot ac dot uk]

--- Comment #16 from agn at noc dot soton dot ac dot uk  2008-02-29 22:30 
---
Many thanks to Jack Howarth for putting in this work to sort out the bug.

Given the comments on the gcc list, I'll reduce the severity of the bug from
blocker to critical.

What originally brought this bug to my notice was that a python extension
linked to gcc43/libstdc++.6.dylib and gcc43/libgcc_s.1.dylib gave a
segmentation fault when called.
I suspected that the use of conflicting c libraries gcc43/libgcc_s.1.dylib and
(implicitly, through gcc43/libstdc++.6.dylib) /usr/lib/libgcc_s.1.dylib might
be causing the segmentation fault.

On the other hand... a similar extension linked to gcc43/libgfortran.3.dylib
and gcc43/libgcc_s.1.dylib was ok, even though gcc43/libgfortran.3.dylib is
itself linked to /usr/lib/libgcc_s.1.dylib

Perhaps the mislinking has more effect on the libstdc++ than on libgfortran?

Apologies if (as is likely) my contribution here is based on ignorance.

George Nurser.


-- 

agn at noc dot soton dot ac dot uk changed:

   What|Removed |Added

   Severity|blocker |critical


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

[Bug fortran/35059] Seg fault when max constructor limit reached

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2008-02-29 22:51 
---
Subject: Bug 35059

Author: jvdelisle
Date: Fri Feb 29 22:50:25 2008
New Revision: 132782

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

PR fortran/35059
* expr.c (find_array_element): Modify traversing the constructor to
avoid trying to access NULL memory pointed to by next for the
last element. (find_array_section): Exit while loop if cons->next is
NULL.
* trans-expr.c (gfc_conv_scalar_char_value): Initialize gfc_typespec.
(gfc_conv_function_call): Same.
* decl.c (gfc_match_implicit): Same.
* trans-intrinsic.c (gfc_conv_intrinsic_sr_kind): Same.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-intrinsic.c


-- 


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

[Bug c++/35401] [4.3/4.4 Regression] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib

[rguenth at gcc dot gnu dot org]

--- Comment #17 from rguenth at gcc dot gnu dot org  2008-02-29 22:52 
---
A regression according to comments.  P2.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||build
   Priority|P3  |P2
Summary|libstdc++ linked to system  |[4.3/4.4 Regression]
   |/usr/lib/libgcc_s.1.dylib   |libstdc++ linked to system
   |not new  gcc4.3 |/usr/lib/libgcc_s.1.dylib
   |libgcc_s.1.dylib|not new  gcc4.3
   ||libgcc_s.1.dylib
   Target Milestone|--- |4.3.0


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

[Bug fortran/35299] scope of variables in statement function do not acquire rank from host

[fxcoudert at gcc dot gnu dot org]

--- Comment #6 from fxcoudert at gcc dot gnu dot org  2008-02-29 22:55 
---
I've thought about it more, and it's probably going to be tricky to solve:
after we have matched the formal arglist, we need to fill the namespace with
replacement symbols for all the dummy args (stripping them from their
attributes other than type and kind), then match the body of the statement
function, then remove these symbols and go on with our life. I don't know the
resolution code well enough to do that :(


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW
   Keywords|patch   |


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

[Bug middle-end/35411] internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1075

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-29 23:00 ---
While I cannot reproduce this on x86_64 I know what can cause it ;)

So, mine.


-- 

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|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-29 23:00:51
   date||


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

[Bug fortran/35299] scope of variables in statement function do not acquire rank from host

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #7 from sgk at troutmask dot apl dot washington dot edu  
2008-02-29 23:05 ---
Subject: Re:  scope of variables in statement function do not acquire rank from
host

On Fri, Feb 29, 2008 at 10:55:31PM -, fxcoudert at gcc dot gnu dot org
wrote:
>--- Comment #6 from fxcoudert at gcc dot gnu dot org  2008-02-29 22:55 ---
> I've thought about it more, and it's probably going to be tricky to solve:
> after we have matched the formal arglist, we need to fill the namespace with
> replacement symbols for all the dummy args (stripping them from their
> attributes other than type and kind), then match the body of the statement
> function, then remove these symbols and go on with our life. I don't know the
> resolution code well enough to do that :(

This bug pre-dates gfortran (at least it is also in g95).  gfortran
has compiled a ton of F77 code, and this is the first instance that
I've seen.  I think this bug is way down the priority list.


-- 


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

[Bug middle-end/35411] internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1075

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-02-29 23:08 ---
  tmp4.field = () SR.447_374;

which SRA creates is invalid GIMPLE.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code


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

[Bug middle-end/35412] New: Correctness with -ftrapv depends on libcall notes

[steven at gcc dot gnu dot org]

See http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01011.html

``When -ftrapv is in effect, libcalls are "necessary" so that the results of an
operation can be propagated without making the call to the libgcc functions
dead. The attached patch causes a failure in pr30286.c.''

This has to be investigated before libcall notes can be removed from the
compiler.


-- 
   Summary: Correctness with -ftrapv depends on libcall notes
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org


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

[Bug middle-end/35413] New: [meta-bug] Remaining issues blocking the removal of libcall notes from the compiler

[steven at gcc dot gnu dot org]

This is a placeholder bug to collect references to all issues that cause GCC to
still require libcall notes.


-- 
   Summary: [meta-bug] Remaining issues blocking the removal of
libcall notes from the compiler
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: meta-bug
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org


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

[Bug middle-end/35413] [meta-bug] Remaining issues blocking the removal of libcall notes from the compiler

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||35404, 35412
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-29 23:26:27
   date||


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

[Bug middle-end/35412] Correctness with -ftrapv depends on libcall notes

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-29 23:33 ---
-ftrapv is seriously broken and nobody wants to fix it;  so the most appealing
solution is to remove support for -ftrapv.  See PR19020, especially the
libcall part is broken as well.


-- 

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-29 23:33:53
   date||


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

[Bug middle-end/35412] Correctness with -ftrapv depends on libcall notes

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2008-02-29 23:36 ---
PR19020 shows that -ftrapv vs. libcalls is broken even without Paolo's patch.


-- 


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

[Bug fortran/35299] scope of variables in statement function do not acquire rank from host

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #8 from sgk at troutmask dot apl dot washington dot edu  
2008-02-29 23:52 ---
Subject: Re:  scope of variables in statement function do not acquire rank from
host

> 
> Don't worry, I share your confusion (when I read the standard). :)
> 
> I think the passage you quote applies to the following code:
> 
>   program z
> real :: y = 2.
> real :: x(5) = 1.
> f(x(2:4)) = 2 * sum(x)   ! dummy arg is an array.
> g(y) = y * x ! function g is an array because of x.
>   end program z
> 

Well, Richard Maine shot these down from other considerations.
The x(2:4) isn't a dummy-arg-name, so that one's out.  In
'g(y) = y * x', the RHS is not a scal-expr, so that one's 
out.

BTW, I don't use statement function, and I've come to dislike
them even more after thinking about this issue.


-- 


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

[Bug middle-end/35411] internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1075

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-03-01 00:28 ---
Subject: Bug 35411

Author: rguenth
Date: Sat Mar  1 00:27:26 2008
New Revision: 132791

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

PR tree-optimization/35411
* tree-sra.c (sra_build_assignment): Split conversion to
final type to a separate statement if we are not assigning
to a register.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-sra.c


-- 


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

[Bug middle-end/35411] [4.4 Regression] internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1075

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-03-01 00:28 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
Summary|internal compiler error: in |[4.4 Regression] internal
   |set_ssa_val_to, at tree-ssa-|compiler error: in
   |sccvn.c:1075|set_ssa_val_to, at tree-ssa-
   ||sccvn.c:1075
   Target Milestone|--- |4.4.0


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

[Bug c/35414] New: gfortran fails to build

[jvdelisle at gcc dot gnu dot org]

This is with:

Last Changed Rev: 132782
Last Changed Date: 2008-02-29 22:50:25 + (Fri, 29 Feb 2008)

../../../gcc44/libgfortran/generated/maxloc1_4_r16.c: In function
'mmaxloc1_4_r16':
../../../gcc44/libgfortran/generated/maxloc1_4_r16.c:220: internal compiler
error: in memory_address, at explow.c:492
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: gfortran fails to build
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jvdelisle at gcc dot gnu dot org
  GCC host triplet: powerpc64-unknown-linux-gnu


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

[Bug c/35414] gfortran fails to build

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-03-01 01:55 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-03-01 01:55 ---
*** Bug 35414 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu dot
   ||org


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

[Bug c++/31775] static object mangling conflicts with extern object

[geoffk at geoffk dot org]

--- Comment #8 from geoffk at geoffk dot org  2008-03-01 04:05 ---
Subject: Re:  static object mangling conflicts with extern object


On 29/02/2008, at 5:57 AM, mueller at gcc dot gnu dot org wrote:

> extern "C" void abort();
> extern "C" { static int i; }
> int *p = &i;
> int main()
> {
>  int i;
>  {
>extern int i;
>i = 1;
>*p = 2;
>if (i == 2)
>  abort ();
>  }
>  return 0;
> }
>
> in this case, the "i" name should not be mangled, right?

It should be mangled, because there are still three different things  
named 'i' declared in this program, and so the two that have assembler  
names have to have different names, and I don't think we want to start  
mangling non-static variable names.


-- 


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

Re: [Bug c++/31775] static object mangling conflicts with extern object

[Andrew Pinski]

Sent from my iPhone

On Feb 29, 2008, at 20:05, "geoffk at geoffk dot org" <[EMAIL PROTECTED] 
> wrote:





--- Comment #8 from geoffk at geoffk dot org  2008-03-01 04:05  





It should be mangled, because there are still three different things
named 'i' declared in this program, and so the two that have assembler
names have to have different names, and I don't think we want to start
mangling non-static variable names.


Also mangling non-static variables will cause an ABI change.

Thanks,
Andrew Pinski

[Bug c++/31775] static object mangling conflicts with extern object

[pinskia at gmail dot com]

--- Comment #9 from pinskia at gmail dot com  2008-03-01 04:19 ---
Subject: Re:  static object mangling conflicts with extern object

Sent from my iPhone

On Feb 29, 2008, at 20:05, "geoffk at geoffk dot org" <[EMAIL PROTECTED] 
 > wrote:

>
>
> --- Comment #8 from geoffk at geoffk dot org  2008-03-01 04:05  
> 
>>
>
> It should be mangled, because there are still three different things
> named 'i' declared in this program, and so the two that have assembler
> names have to have different names, and I don't think we want to start
> mangling non-static variable names.

Also mangling non-static variables will cause an ABI change.

Thanks,
Andrew Pinski


-- 


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

[Bug c++/35315] [4.4 regression] ICE with attribute transparent_union

[dgregor at gcc dot gnu dot org]

--- Comment #4 from dgregor at gcc dot gnu dot org  2008-03-01 05:38 ---
Subject: Bug 35315

Author: dgregor
Date: Sat Mar  1 05:37:41 2008
New Revision: 132798

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132798
Log:
2008-02-29  Douglas Gregor  <[EMAIL PROTECTED]>

PR c++/35315
* tree-inline.c (build_duplicate_type): When we make a
duplicate type, make it unique in the canonical types system.

2008-02-29  Douglas Gregor  <[EMAIL PROTECTED]>

PR c++/35315
* g++.dg/ext/attrib32.C: New.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/ext/attrib32.C
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-inline.c


-- 


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

[Bug c++/35415] New: [4.4 Regression] 20_util/shared_ptr/assign/shared_ptr_neg.cc

[hjl dot tools at gmail dot com]

With revision 132792, I got

FAIL: 20_util/shared_ptr/assign/shared_ptr_neg.cc (test for excess errors)

on Linux/Intel64. Revision 132763 is OK.


-- 
   Summary: [4.4 Regression]
20_util/shared_ptr/assign/shared_ptr_neg.cc
   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


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

[Bug c++/35416] New: [4.4 Regression] tr1/2_general_utilities/shared_ptr/assign/shared_ptr_neg.cc

[hjl dot tools at gmail dot com]

With revision 132792, I got

FAIL: tr1/2_general_utilities/shared_ptr/assign/shared_ptr_neg.cc (test for
excess errors)

on Linux/Intel64. Revision 132763 is OK.


-- 
   Summary: [4.4 Regression]
tr1/2_general_utilities/shared_ptr/assign/shared_ptr_neg
.cc
   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


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