[Bug tree-optimization/36765] [4.3 Regression] Revision 137573 miscompiles 464.h264ref in SPEC CPU 2006

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2009-01-19 09:33 
---
Subject: Bug 36765

Author: rguenth
Date: Mon Jan 19 09:33:06 2009
New Revision: 143494

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143494
Log:
2009-01-19  Richard Guenther  

Backport from mainline
2008-07-11  Richard Guenther  

PR tree-optimization/36765
* tree-ssa-alias.c (compute_flow_insensitive_aliasing): Add
aliases from HEAP vars to SMTs.

* gcc.c-torture/execute/pr36765.c: New testcase.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr36765.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-ssa-alias.c


-- 


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

[Bug tree-optimization/36765] [4.3 Regression] Revision 137573 miscompiles 464.h264ref in SPEC CPU 2006

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2009-01-19 09:35 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/38857] [4.4 Regression] ICE in selective scheduler

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-01-19 09:49 ---
P1 as this happens on a secondary target with -O3.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.3.3
   Priority|P3  |P1


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

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[bonzini at gnu dot org]

--- Comment #36 from bonzini at gnu dot org  2009-01-19 10:33 ---
Would you please attach the assembler diff:
1) between -m32 -O1 and -m32 -O1 -fforward-propagate
2) between the latter and -m32 -O1 -fforward-propagate -fschedule-insns2?

Thanks.


-- 


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

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[bonzini at gnu dot org]

--- Comment #37 from bonzini at gnu dot org  2009-01-19 10:36 ---
This is the fishy part: notice that the %esi in the failing test case is
completely bogus.

-   leal-680(%ebp), %esi
-   movb$32, (%esi)
-   movb$32, -679(%ebp)
-   movw$8224, -678(%ebp)
+   leal-176(%ebp), %ebx
+   leal-257(%ebp), %esi
+   movb$32, -176(%ebp)
+   movb$32, -175(%ebp)
+   movw$8224, -174(%ebp)


-- 


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

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[rguenth at gcc dot gnu dot org]

--- Comment #38 from rguenth at gcc dot gnu dot org  2009-01-19 10:50 
---
Created an attachment (id=17139)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17139&action=view)
assembler diff between -O -m32 -fforward-propagate and -O -m32
-fforward-propagate -fschedule-insns2


-- 


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

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

--- Comment #33 from r dot emrich at de dot tecosim dot com  2009-01-19 
10:51 ---
(In reply to comment #32)
> 
> Dave, thank you for the explanation.
> Next week I will try to build some functional C++ application.
> Then we will see if there are remaining issues.
> 
> Rainer
> 

There are some strange symptoms.

I tried to build a simple "Hello, World!" application in 4 variants.
1. C source using gcc
2. C source using gcc, static linking
3. C++ source using g++
4. C++ source using g++, static linking

I will create attachments containing the compile logs.

1. Compilation ok, excecution on the target system ok, but ldd on the target
system gives:
ldd: "hello" is not a shared executable.

2. Compilation ok,  execution on the target system gives:
./hello: cannot execute binary file

3. Linking fails!

4. Compilation ok, execution on the target system gives:
./hello: cannot execute binary file

Any idea?


-- 


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

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

--- Comment #34 from r dot emrich at de dot tecosim dot com  2009-01-19 
10:52 ---
Created an attachment (id=17140)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17140&action=view)
C compile log


-- 


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

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

--- Comment #35 from r dot emrich at de dot tecosim dot com  2009-01-19 
10:53 ---
Created an attachment (id=17141)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17141&action=view)
C compile static log


-- 


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

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

--- Comment #37 from r dot emrich at de dot tecosim dot com  2009-01-19 
10:54 ---
Created an attachment (id=17143)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17143&action=view)
C++ compile static log


-- 


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

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[bonzini at gnu dot org]

--- Comment #39 from bonzini at gnu dot org  2009-01-19 11:04 ---
Looks like a scheduling bug:

-O1 -fforward-propagate has
leal-676(%ebp), %edi
movl$19, %ecx
movl$538976288, %eax
rep stosl
movw$31096, -603(%ebp)
movb$122, -601(%ebp)

-O1 -fforward-propagate -fschedule-insns has
leal-676(%ebp), %edi
movl$19, %ecx
movw$31096, -603(%ebp)
movl$538976288, %eax
rep stosl
movb$122, -601(%ebp)

and 676+19*4 = 600 so -603(%ebp) is 0x2020 in the bad code, 0x7978 in the good
code.


-- 


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

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[rguenth at gcc dot gnu dot org]

--- Comment #35 from rguenth at gcc dot gnu dot org  2009-01-19 10:29 
---
I can reproduce the issue with the testcase in comment #27 on x86_64-linux
with -m32 -O2 vs. -m32 -O.

It can be reduced to the effect of -fschedule-insns2 and -fforward-propagate
(disabling either on -O2 -fno-strict-aliasing is enough to fix the failure,
enabling both is enough to trigger the failure with -O).

I didn't track down which asm difference makes it fail, but there are some
changes across calls which look dubious.  CCing Paolo and Steven ...


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||stevenb dot gcc at gmail dot
   ||com, bonzini at gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2009-01-19 10:29:50
   date||


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

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[r dot emrich at de dot tecosim dot com]

--- Comment #36 from r dot emrich at de dot tecosim dot com  2009-01-19 
10:53 ---
Created an attachment (id=17142)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17142&action=view)
C++ compile log


-- 


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

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[rguenth at gcc dot gnu dot org]

--- Comment #40 from rguenth at gcc dot gnu dot org  2009-01-19 12:20 
---
Which means this might be a target bug as well, more specifically a bug in the
*rep_stossi pattern.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||uros at gcc dot gnu dot org,
   ||hubicka at gcc dot gnu dot
   ||org


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

[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[rguenth at gcc dot gnu dot org]

--- Comment #41 from rguenth at gcc dot gnu dot org  2009-01-19 12:37 
---
In

(insn 37 86 40 4 t.f:9 (parallel [
(set (reg:SI 2 cx [74])
(const_int 0 [0x0]))
(set (reg/f:SI 5 di [72])
(plus:SI (ashift:SI (reg:SI 2 cx [74])
(const_int 2 [0x2]))
(reg/f:SI 5 di [72])))
(set (mem/s/j:BLK (reg/f:SI 5 di [72]) [0 line+80 A32])
(const_int 0 [0x0]))
(use (reg:SI 0 ax [73]))
(use (reg:SI 2 cx [74]))
]) 856 {*rep_stossi} (expr_list:REG_DEAD (reg:SI 0 ax [73])
(expr_list:REG_UNUSED (reg/f:SI 5 di [72])
(expr_list:REG_UNUSED (reg:SI 2 cx [74])
(nil)

the MEM_EXPR of

(set (mem/s/j:BLK (reg/f:SI 5 di [72]) [0 line+80 A32])
(const_int 0 [0x0]))

is bogus, it should be line, not line+80.  Does forwprop adjust MEM_EXPRs
properly?


-- 


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

[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[rguenth at gcc dot gnu dot org]

--- Comment #42 from rguenth at gcc dot gnu dot org  2009-01-19 12:40 
---
Rather it is broken from expansion:

;; __builtin_memset (&line[2]{lb: 1 sz: 1}, 32, 79);

(insn 28 27 29 t.f:9 (parallel [
(set (reg:SI 70)
(plus:SI (reg/f:SI 54 virtual-stack-vars)
(const_int -656 [0xfd70])))
(clobber (reg:CC 17 flags))
]) -1 (nil))

(insn 29 28 30 t.f:9 (parallel [
(set (reg:SI 71)
(plus:SI (reg:SI 70)
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) -1 (nil))

(insn 30 29 31 t.f:9 (set (reg:SI 72)
(reg:SI 71)) -1 (nil))

(insn 31 30 32 t.f:9 (set (reg:SI 73)
(const_int 538976288 [0x20202020])) -1 (nil))

(insn 32 31 33 t.f:9 (set (mem/s/j:QI (reg:SI 72) [0 line+1 S1 A8])
(subreg:QI (reg:SI 73) 0)) -1 (nil))

(insn 33 32 34 t.f:9 (parallel [
(set (reg:SI 72)
(plus:SI (reg:SI 72)
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) -1 (nil))

(insn 34 33 35 t.f:9 (set (mem/s/j:HI (reg:SI 72) [0 line+2 S2 A16])
(subreg:HI (reg:SI 73) 0)) -1 (nil))

(insn 35 34 36 t.f:9 (parallel [
(set (reg:SI 72)
(plus:SI (reg:SI 72)
(const_int 2 [0x2])))
(clobber (reg:CC 17 flags))
]) -1 (nil))

(insn 36 35 37 t.f:9 (set (reg:SI 74)
(const_int 19 [0x13])) -1 (nil))

(insn 37 36 0 t.f:9 (parallel [
(set (reg:SI 74)
(const_int 0 [0x0]))
(set (reg:SI 72)
(plus:SI (ashift:SI (reg:SI 74)
(const_int 2 [0x2]))
(reg:SI 72)))
(set (mem/s/j:BLK (reg:SI 72) [0 line+80 A32])
(const_int 0 [0x0]))
(use (reg:SI 73))
(use (reg:SI 74))
]) -1 (nil))


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|middle-end  |target
 GCC target triplet||i?86-*-*


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

[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #38 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-19 
13:38 ---
Subject: Re:  fails to build cross gcc for target hppa64-hp-hpux11.00 in
libstdc++/libmath

> There are some strange symptoms.
> 
> I tried to build a simple "Hello, World!" application in 4 variants.
> 1. C source using gcc
> 2. C source using gcc, static linking
> 3. C++ source using g++
> 4. C++ source using g++, static linking
> 
> I will create attachments containing the compile logs.
> 
> 1. Compilation ok, excecution on the target system ok, but ldd on the target
> system gives:
> ldd: "hello" is not a shared executable.
> 
> 2. Compilation ok,  execution on the target system gives:
> ./hello: cannot execute binary file
> 
> 3. Linking fails!
> 
> 4. Compilation ok, execution on the target system gives:
> ./hello: cannot execute binary file
> 
> Any idea?

Use file, chatr, ldd and readelf commands to check file type and ELF
information.  Compare with native application.

GNU ld doesn't create "static" executables (known problem).  It
can only create dynamic executables.  Typically, problems in launching
dynamic executables are debugged by running the dynamic linker under
gdb.  This is hard here because the dynamic linker is proprietary.

3 is probably a binutils bug.  I haven't tried a native build
using GNU ld for some time.  It used to be good enough to do what
you want.

Dave


-- 


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

[Bug libstdc++/38897] Parallel mode example code does not compile

[j dot s dot sebastian at gmail dot com]

--- Comment #1 from j dot s dot sebastian at gmail dot com  2009-01-19 
13:50 ---
After some trial and error, I found it does compile (on same system) if I
modify the code as follows, to use the 3-argument version of sort:

#include 
#include 

int main()
{
  std::vector v(100);

  // Explicitly force a call to parallel sort.
  //__gnu_parallel::sort(v.begin(), v.end());
  __gnu_parallel::sort(v.begin(), v.end(),std::less());
  return 0;
}

Still I think it is a bug (not just documentation bug), as both versions should
work.

By the way this parallel STL stuff is just awesome ;-)


-- 


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

[Bug libstdc++/38897] Parallel mode example code does not compile

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-01-19 14:05 
---
Thanks for the additional info. Let's add Johannes in CC, I'm confident we can
fix this pretty soon.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||paolo at gcc dot gnu dot
   ||org, singler at ira dot uka
   ||dot de
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-19 14:05:04
   date||


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

[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[bonzini at gnu dot org]

--- Comment #43 from bonzini at gnu dot org  2009-01-19 14:06 ---
The bug is actually in target independent code.  The code to change_address_1
in adjust_address_1 does nothing if the addr is simple, and this causes the
creation of shared or wrong RTL.


-- 


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

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-01-19 14:07 ---
Can you attach preprocessed source of idecode.c at least?  Can you track down
where in idecode.c the bug is and wrap a main () around that piece, making it
an executable testcase?

Does 4.3.[23] work?  Pleas adjust the Known-to-work fields.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
Summary|psim miscompiled #2 |[4.4 Regression] psim
   |[regression]|miscompiled #2
   Target Milestone|--- |4.4.0


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

[Bug driver/38911] New: RFE - Need verbose gcc to show cloog , ppl and pwl + more (and trivial fix)

[rob1weld at aol dot com]

This RFE is for two related issues. I'll call it an RFE rather
than attempt to argue it is a Bug (by omission or inconsistent 
behavior).


1: Typing "gcc -v" will print the 'specs info', 'HBT', 'how gcc was
"./configured"', 'the thread model' and 'version / revision'. When
you actually compile a program using the "-v" option gcc will print
out some additional info that may be useful to include with the 
more trivial "gcc -v" command.


2: When you actually compile a program using the "-v" option gcc
prints out info about gmp and mpfr but none about cloog , ppl and 
pwl.

In the past 'libgmp.so' and 'libmpfr.so' were optional in _some_
configurations, and were tested for during configuration to enable
or disable features. It is my understanding that these libraries
are now mandatory and omission of them will cause configuration
failure.

At present 'libppl.so', 'libpwl.so', and 'libcloog.so' are optional
and are tested for during configuration to enable or disable features.

Are the 'libppl.so', 'libpwl.so', and 'libcloog.so' libraries worthy
of enough "status" to print their versions alongside gmp and mpfr ?

It is also a minor issue that there is some leading whitespace.



Here is an example of "gcc -v" as it currently is (depending upon your
configuration and platform):

# gcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-decimal-float --with-long-double-128 --enable-nls
--with-included-gettext --enable-gather-detailed-mem-stats --with-stabs
--enable-debug --enable-largefile --enable-symvers --without-system-zlib
--enable-gtk-cairo --enable-gconf-peer --enable-xmlj --enable-gtk-peer
--enable-qt-peer --enable-plugin --enable-tool-wrappers --enable-local-sockets
--enable-gjdoc --enable-java-awt=gtk,xlib,qt,x --enable-gc-debug
--enable-libgcj-debug --enable-objc-gc --enable-libstdcxx-debug
--disable-stage1-checking --enable-checking=release --without-system-libunwind
--with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld
--with-ld=/usr/local/bin/ld
Thread model: posix
gcc version 4.4.0 20090117 (experimental) [trunk revision 143454] (GCC) 


Here is an example of adding "-v" when compiling a program (current):

# gcc -v program.c
...
End of search list.
GNU C (GCC) version 4.4.0 20090117 (experimental) [trunk revision 143454]
(i386-pc-solaris2.11)
compiled by GNU C version 4.4.0 20090116 (experimental) [trunk revision
143443], GMP version 4.2.1, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
...



Here the revised version of "gcc -v":

# gcc -v
Using built-in specs.
Configured with: ../gcc_trunk/configure
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-decimal-float --with-long-double-128 --enable-nls
--with-included-gettext --enable-gather-detailed-mem-stats --with-stabs
--enable-debug --enable-largefile --enable-symvers --without-system-zlib
--enable-gtk-cairo --enable-gconf-peer --enable-xmlj --enable-gtk-peer
--enable-qt-peer --enable-plugin --enable-tool-wrappers --enable-local-sockets
--enable-gjdoc --enable-java-awt=gtk,xlib,qt,x --enable-gc-debug
--enable-libgcj-debug --enable-objc-gc --enable-libstdcxx-debug
--disable-stage1-checking --enable-checking=release --without-system-libunwind
--with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld
--with-ld=/usr/local/bin/ld
Thread model: posix
GNU GCC version 4.4.0 20090117 (experimental) [trunk revision 143454]
(i386-pc-solaris2.11)
compiled by GNU C version 4.4.0 20090116 (experimental) [trunk revision
143443], GMP version 4.2.1, MPFR version 2.3.2, PPL 1.0, CLOOG 1.0.
Compiler executable checksum: 887b9f3a0e2bcd7effe1a0a359de0f07


Here the revised version of adding a "-v" when compiling a program
(remove the extra white space before "compiled"):

# gcc -v program.c
...
End of search list.
GNU C (GCC) version 4.4.0 20090117 (experimental) [trunk revision 143454]
(i386-pc-solaris2.11)
compiled by GNU C version 4.4.0 20090116 (experimental) [trunk revision 43443],
GMP version 4.2.1, MPFR version 2.3.2, PPL 1.0, CLOOG 1.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 887b9f3a0e2bcd7effe1a0a359de0f07
...

Thanks,
Rob


-- 
   Summary: RFE - Need verbose gcc to show cloog , ppl and pwl +
more (and trivial fix)
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com


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

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

[joel at gcc dot gnu dot org]

--- Comment #7 from joel at gcc dot gnu dot org  2009-01-19 14:38 ---
Works with 4.3.2 as shipped with Fedora 10 (RPM gcc-4.3.2-7.x86_64)


-- 

joel at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.3.2


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

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

[joel at gcc dot gnu dot org]

--- Comment #8 from joel at gcc dot gnu dot org  2009-01-19 14:45 ---
$ gcc --version
gcc (GCC) 4.4.0 20090116 (experimental) [trunk revision 143442]

broken still.  Test script 
=
rm -rf b-gdb && mkdir b-gdb && cd b-gdb && \
/home/joel/gcc-pr38587/gdb-6.8/configure --target=powerpc-rtems4.10 \
  --disable-werror --enable-sim --enable-sim-hardware --enable-timebase \
--enable-sim-trace 2>&1 && \
make -j6  2>&1 && \
../psim-4.10 /home/joel/powerpc-psim-ticker.ralf

=


-- 


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

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

[joel at gcc dot gnu dot org]

--- Comment #9 from joel at gcc dot gnu dot org  2009-01-19 14:51 ---
Created an attachment (id=17144)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17144&action=view)
PSIM test executable that produces assertion

PowerPC PSIM executable used by previous test script.


-- 


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

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

[joel at gcc dot gnu dot org]

--- Comment #10 from joel at gcc dot gnu dot org  2009-01-19 14:54 ---
Created an attachment (id=17145)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17145&action=view)
preprocessed idecode.c

Preprocessed version of idecode.i using this gcc version on Fedora 10:

4.4.0 20090116 (experimental) [trunk revision 143442]

gcc -E -g -O2 -DDEFAULT_INLINE=PSIM_INLINE_LOCALS
-DWITH_HOST_BYTE_ORDER=LITTLE_ENDIAN -DWITH_SMP=5-DWITH_TRACE=1 
-DHAVE_TERMIOS_STRUCTURE -DHAVE_TERMIOS_CLINE -DHAVE_DEVZERO -I.
-I/home/joel/gcc-pr38587/gdb-6.8/sim/ppc
-I/home/joel/gcc-pr38587/gdb-6.8/sim/ppc/../../include -I../../bfd
-I/home/joel/gcc-pr38587/gdb-6.8/sim/ppc/../../bfd -I../../gdb
-I/home/joel/gcc-pr38587/gdb-6.8/sim/ppc/../../gdb 
-I/home/joel/gcc-pr38587/gdb-6.8/sim/ppc/../../gdb/config  -DHAVE_COMMON_FPU
-I../common -I/home/joel/gcc-pr38587/gdb-6.8/sim/ppc/../common idecode.c
>idecode.i


-- 


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

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

[joel at gcc dot gnu dot org]

--- Comment #11 from joel at gcc dot gnu dot org  2009-01-19 15:00 ---
(In reply to comment #6)
> Can you attach preprocessed source of idecode.c at least?  Can you track down
> where in idecode.c the bug is and wrap a main () around that piece, making it
> an executable testcase?

psim is automatically generated code.  I have no idea how to narrow it down
to an executable test case.  I included my gdb configuration, psim
test program, and preprocessed source.  I will upload the script I
am using to run it since you have to have a device tree.

Hmmm... this is the code where the assert happens:

  /* now establish the restart target */
  psim_set_halt_and_restart(system, &halt, &restart);
  if (setjmp(restart)) {
current_cpu = psim_last_cpu(system);
ASSERT(current_cpu >= 0 && current_cpu < nr_cpus);
  }

Is it possible that setjmp/longjmp is not preserving a register that
gcc x86_64 is now using?

> Does 4.3.[23] work?  Pleas adjust the Known-to-work fields.

Confirmed 4.3.2.


-- 


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

[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[bonzini at gnu dot org]

--- Comment #44 from bonzini at gnu dot org  2009-01-19 15:03 ---
Created an attachment (id=17146)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17146&action=view)
patch under test

testing this patch.


-- 


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

[Bug fortran/38913] New: Fortran does not set TYPE_CANONICAL properly

[rguenth at gcc dot gnu dot org]

TYPE_CANONICAL should specify a canonical type node (equivalent for type
comparison for example during TBAA) for each type declaration.  Failing to do
so causes TBAA pessimizations.

The frontend also does not properly identify equivalent types, which is
a correctness issue.  Consider (reduced from polyhedron protein)

subroutine check (string1, string2)
character (len=1) :: string1, string2
if (string1(1:1) /= string2(1:1)) call abort
end subroutine check
program foo
  character (len=1) :: str, str2
  str(1:1) = ' '
  str2(1:1) = convert_lower_case(str(1:1))
  call check(str, str2)

  contains
  function convert_lower_case (input_string) result (output_string)
  character (len=1) :: input_string, output_string
  output_string = input_string
  end function convert_lower_case

end program

the character array type used in the inline function convert_lower_case is
not connected to the character array type used in the main function.  This
causes the alias-oracle on the alias-improvements branch to consider
str.293[0] and (*str.327_132)[1]{lb: 1 sz: 1} to be non-aliasing even
if str.327_132 is initialized from str.293 via
str.327_132 = (character(kind=1)[1:1] *) &str.293; because the type used
in that conversion is from the inline function and is not equal to that
of std.293.

I believe that boils down to a similar issue as the one-decl for each
function thing.  Either GFortran has to use -fno-strict-aliasing or
needs to properly use canonical types.


-- 
   Summary: Fortran does not set TYPE_CANONICAL properly
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: blocker
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug middle-end/36227] [4.3 Regression] POINTER_PLUS folding introduces undefined overflow

[danglin at gcc dot gnu dot org]

--- Comment #14 from danglin at gcc dot gnu dot org  2009-01-19 16:14 
---
New test fails on hpux:

Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr36227.c  -w  -O0   -lm  
-o
 /test/gnu/gcc/objdir/gcc/testsuite/gcc/pr36227.x0(timeout = 300)
/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr36227.c:1:20: error:
std
int.h: No such file or directory


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu dot
   ||org


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

[Bug middle-end/36227] [4.3 Regression] POINTER_PLUS folding introduces undefined overflow

[rguenther at suse dot de]

--- Comment #15 from rguenther at suse dot de  2009-01-19 16:22 ---
Subject: Re:  [4.3 Regression] POINTER_PLUS folding
 introduces undefined overflow

On Mon, 19 Jan 2009, danglin at gcc dot gnu dot org wrote:

> --- Comment #14 from danglin at gcc dot gnu dot org  2009-01-19 16:14 
> ---
> New test fails on hpux:
> 
> Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
> /te
> st/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr36227.c  -w  -O0   -lm  
> -o
>  /test/gnu/gcc/objdir/gcc/testsuite/gcc/pr36227.x0(timeout = 300)
> /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr36227.c:1:20: error:
> std
> int.h: No such file or directory

Ah, needs

{ target { stdint_types } }

Richard.


-- 


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

[Bug fortran/38913] Fortran does not set TYPE_CANONICAL properly

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-01-19 16:23 ---
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00937.html


-- 


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

[Bug testsuite/38739] gcc 4.4.0 20090104 - contrib/test_summary - On Solaris /bin/sh uses ksh, gawk fails

[rob1weld at aol dot com]

--- Comment #3 from rob1weld at aol dot com  2009-01-19 16:26 ---
(In reply to comment #1)
> Probably the Solaris /bin/sh misparses ${BOOT_CFLAGS+'print
> "BOOT_CFLAGS='"${BOOT_CFLAGS}"'";'}.  The autoconf manual describes a similar
> bug in connection with ${foo='}'}.

There may well be some dubious stuff in there. 


I added "--posix --lint --lint-old" into the AWK command and got this
(partial):

gawk: cmd. line:12: warning: `sub' is not supported in old awk
gawk: cmd. line:13: warning: `sub' is not supported in old awk
gawk: cmd. line:15: warning: `sub' is not supported in old awk
gawk: cmd. line:17: warning: `system' is not supported in old awk
gawk: cmd. line:20: warning: `sub' is not supported in old awk
gawk: cmd. line:21: warning: `sub' is not supported in old awk
gawk: cmd. line:22: warning: `sub' is not supported in old awk
gawk: cmd. line:23: warning: `sub' is not supported in old awk
gawk: cmd. line:24: warning: `sub' is not supported in old awk
gawk: cmd. line:25: warning: `sub' is not supported in old awk
gawk: cmd. line:35: warning: `gsub' is not supported in old awk
gawk: cmd. line:35: warning: `gsub' is not supported in old awk
gawk: cmd. line:35: (FILENAME=- FNR=6) warning: reference to uninitialized
field `$2'
gawk: cmd. line:37: (FILENAME=- FNR=6) warning: reference to uninitialized
field `$2'
gawk: cmd. line:43: (FILENAME=- FNR=6) warning: reference to uninitialized
variable `blanks'

(Many thousands of lines repeating same error with different FNR #)

gawk: cmd. line:35: (FILENAME=- FNR=70066) warning: reference to uninitialized
field `$2'
gawk: cmd. line:37: (FILENAME=- FNR=70066) warning: reference to uninitialized
field `$2'
gawk: cmd. line:35: (FILENAME=- FNR=70068) warning: reference to uninitialized
field `$2'
gawk: cmd. line:37: (FILENAME=- FNR=70068) warning: reference to uninitialized
field `$2'
gawk: cmd. line:46: (FILENAME=- FNR=70072) warning: reference to uninitialized
variable `prefix'
gawk: cmd. line:52: (FILENAME=- FNR=70072) warning: reference to uninitialized
variable `boot_cflags'
gawk: cmd. line:53: (FILENAME=- FNR=70072) warning: reference to uninitialized
variable `prefix'

Rob


-- 


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

[Bug target/38730] gcc 4.4.0 20090104 - "make -i check" - over 60 FAILs in "C" compiler

[rob1weld at aol dot com]

--- Comment #4 from rob1weld at aol dot com  2009-01-19 16:39 ---
Ada has it's errors fixed but now it presents output that is not "captured
and warned" in the Testsuite reports. The extra messages are not reported.


Here is part of: http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01790.html

--

...
LAST_UPDATED: Sat Jan 17 01:02:29 UTC 2009 (revision 143454)

=== acats tests ===

   === acats Summary ===
# of expected passes2315
# of unexpected failures0
Native configuration is i386-pc-solaris2.11


=== g++ tests ===
...
=== gnat tests ===


Running target unix

=== gnat Summary ===

# of expected passes604
# of expected failures  6
   === obj-c++ tests ===
...
--


Here is what the actual screen output looks like:

...
=== acats tests ===
Running chapter a ...
comm: file 2 is not in sorted order
(repeated "comm" messages for each test)
...


Thanks,
Rob


-- 


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

[Bug fortran/38914] New: ICE with array inquiry functions above contains in parameter expression

[dick dot hendrickson at gmail dot com]

The following program causes an ICE.  If the contains and subroutine statements
are uncommented, then the program compiles.

Dick Hendrickson

  MODULE U_above_TESTS

! fails on Windows XP
! gcc version 4.4.0 20081219 (experimental) [trunk revision 142842] (GCC)

!  contains
!  subroutine U_below

  INTEGER, PARAMETER, DIMENSION(0:20,4) :: IP_ARRAY2_4_S = 0

  INTEGER, PARAMETER, DIMENSION(12) ::  IP_ARRAY1_32_S =
 $(/  LBOUND(IP_ARRAY2_4_S), LBOUND(IP_ARRAY2_4_S(5:10,2:3)),
 $UBOUND(IP_ARRAY2_4_S), UBOUND(IP_ARRAY2_4_S(5:10,2:3)),
 $SIZE(IP_ARRAY2_4_S), SIZE(IP_ARRAY2_4_S(5:10,2:3)),
 $SHAPE(IP_ARRAY2_4_S(5:10,2:3))  /)

!  end subroutine u_below

  END MODULE U_above_TESTS


C:\gfortran>gfortran u_above.f
f951.exe: internal compiler error: in gfc_conv_array_initializer, at
fortran/tra
ns-array.c:4009
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE with array inquiry functions above contains in
parameter expression
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dick dot hendrickson at gmail dot com


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

[Bug libgcj/38685] classmap.db is zero bytes long in 64 bit directory

[rob1weld at aol dot com]

--- Comment #6 from rob1weld at aol dot com  2009-01-19 17:09 ---
The Trunk (143454) is now:

# gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-decimal-float --with-long-double-128 --enable-nls
--with-included-gettext --enable-gather-detailed-mem-stats --with-stabs
--enable-debug --enable-largefile --enable-symvers --without-system-zlib
--enable-gtk-cairo --enable-gconf-peer --enable-xmlj --enable-gtk-peer
--enable-qt-peer --enable-plugin --enable-tool-wrappers --enable-local-sockets
--enable-gjdoc --enable-java-awt=gtk,xlib,qt,x --enable-gc-debug
--enable-libgcj-debug --enable-objc-gc --enable-libstdcxx-debug
--disable-stage1-checking --enable-checking=release --without-system-libunwind
--with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld
--with-ld=/usr/local/bin/ld
Thread model: posix
gcc version 4.4.0 20090117 (experimental) [trunk revision 143454] (GCC) 


# ls -l /usr/local/lib/amd64/gcj-4.4.0-10/ /usr/local/lib/gcj-4.4.0-10/
/usr/local/lib/amd64/gcj-4.4.0-10/:
total 2053
-rw-r--r-- 1 root root   0 Jan 11 18:03 classmap.db
-rwxr-xr-x 1 root root1200 Jan 11 18:03 libgconfpeer.la
-rwxr-xr-x 1 root root   68014 Jan 11 18:03 libgconfpeer.so
-rwxr-xr-x 1 root root1296 Jan 11 18:03 libgtkpeer.la
-rwxr-xr-x 1 root root 1325924 Jan 11 18:03 libgtkpeer.so
-rwxr-xr-x 1 root root1326 Jan 11 18:03 libjawt.la
-rwxr-xr-x 1 root root   33054 Jan 11 18:03 libjawt.so
-rwxr-xr-x 1 root root1107 Jan 11 18:03 libjvm.la
-rwxr-xr-x 1 root root   15398 Jan 11 18:03 libjvm.so
-rwxr-xr-x 1 root root 977 Jan 11 18:03 libxmlj.la
lrwxrwxrwx 1 root root  16 Jan 11 18:03 libxmlj.so -> libxmlj.so.0.0.0
lrwxrwxrwx 1 root root  16 Jan 11 18:03 libxmlj.so.0 -> libxmlj.so.0.0.0
-rwxr-xr-x 1 root root  429910 Jan 11 18:03 libxmlj.so.0.0.0

/usr/local/lib/gcj-4.4.0-10/:
total 3276
-rw-r--r-- 1 root root 1441792 Jan 11 18:02 classmap.db
-rwxr-xr-x 1 root root1194 Jan 11 18:01 libgconfpeer.la
-rwxr-xr-x 1 root root   59934 Jan 11 18:01 libgconfpeer.so
-rwxr-xr-x 1 root root1290 Jan 11 18:01 libgtkpeer.la
-rwxr-xr-x 1 root root 1208507 Jan 11 18:01 libgtkpeer.so
-rwxr-xr-x 1 root root 972 Jan 11 18:01 libjavamath.la
-rwxr-xr-x 1 root root   82307 Jan 11 18:01 libjavamath.so
-rwxr-xr-x 1 root root1314 Jan 11 18:02 libjawt.la
-rwxr-xr-x 1 root root   29296 Jan 11 18:02 libjawt.so
-rwxr-xr-x 1 root root1083 Jan 11 18:02 libjvm.la
-rwxr-xr-x 1 root root   13266 Jan 11 18:02 libjvm.so
-rwxr-xr-x 1 root root 971 Jan 11 18:01 libxmlj.la
lrwxrwxrwx 1 root root  16 Jan 11 18:01 libxmlj.so -> libxmlj.so.0.0.0
lrwxrwxrwx 1 root root  16 Jan 11 18:01 libxmlj.so.0 -> libxmlj.so.0.0.0
-rwxr-xr-x 1 root root  377422 Jan 11 18:01 libxmlj.so.0.0.0

Rob


-- 


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

[Bug libstdc++/38897] Parallel mode example code does not compile

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-01-19 17:17 
---
Hummm, actually, I can't reproduce with current mainline... Can you also try a
snapshot / SVN checkout of current mainline?


-- 


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

[Bug c/38869] [4.4 Regression] valgrind find problem with -O -mtune=generic

[vmakarov at gcc dot gnu dot org]

--- Comment #9 from vmakarov at gcc dot gnu dot org  2009-01-19 17:17 
---
Subject: Bug 38869

Author: vmakarov
Date: Mon Jan 19 17:17:14 2009
New Revision: 143498

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143498
Log:
2009-01-19  Vladimir Makarov  

PR c/38869
* rtl.h (reinit_regs): New prototype.
* regclass.c: Include ira.h.
(reinit_regs): New.
* Makefile.in (regclass.o): Add ira.h.
* config/i386/i386.c (ix86_maybe_switch_abi): Use reinit_regs.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/config/i386/i386.c
trunk/gcc/regclass.c
trunk/gcc/rtl.h


-- 


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

[Bug libstdc++/38897] Parallel mode example code does not compile

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |WAITING


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

[Bug libstdc++/38897] Parallel mode example code does not compile

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2009-01-19 17:36 
---
By the way, I don't see any serious divergence between the 4_3 and the mainline
libraries in this area, therefore likely the issue is ultimately due to a C++
front-end issue... Since 4.3.3 is being released right now, and, I understand,
there are dim hopes of a 4.3.4 any time soon, unless we figure out something
really trivial for 4_3-branch, we are not going to do anything...


-- 


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

[Bug libgcj/24403] --enable-java-awt=qt fails to build

[rob1weld at aol dot com]

--- Comment #18 from rob1weld at aol dot com  2009-01-19 17:43 ---
With my fix I can configure with "--enable-java-awt=gtk,xlib,qt,x", see:

Results for 4.4.0 20090117 (experimental) [trunk revision 143454] (GCC)
testsuite on i386-pc-solaris2.11
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01790.html

Rob


-- 


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

[Bug libgcj/32781] Build breaks - libstdc++-v3/include/bits/stl_algobase.h: In function '_OI std::__copy_aux(_II, _II, _OI)': error: expected primary-expression before ')' token

[rob1weld at aol dot com]

--- Comment #8 from rob1weld at aol dot com  2009-01-19 17:46 ---
(In reply to comment #7)
> After my "moc-qt4" fix to the Makefile I have test results to prove it built:
> 
> Results for 4.3.0 20070716 (experimental) testsuite on i686-pc-linux-gnu
> http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00721.html


My fix still works on new gcc, see here for "--enable-java-awt=gtk,xlib,qt,x" :

Results for 4.4.0 20090117 (experimental) [trunk revision 143454] (GCC)
testsuite on i386-pc-solaris2.11
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01790.html

Rob


-- 


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

[Bug fortran/38915] New: wrong results for structure assignment of character components when left and right sides overlap

[dick dot hendrickson at gmail dot com]

The following program gives the wrong results for the character assignments to
a structure component.  The problem appears to occur when there is an overlap
between the left and right hand sides of the assignment.  It is "as if" the
character length of the right hand side is treated as 1, rather than 9, and
then the left is blank padded to 9.  While experimenting with this, I tried
some simple things like L(1:2)%c = R(2:3)%c and they all worked.

Dick Hendrickson

   program cg0033_41

! fails on Windows XP
! gcc version 4.4.0 20081219 (experimental) [trunk revision 142842] (GCC)

   type t
 sequence
 integer i
 character(len=9) c
   end type t

   type (t)  L(3),R(3), LL(4), RR(4)
   EQUIVALENCE (L,LL)

   integer nfv1(3), nfv2(3)

   R(1)%c = '123456789'
   R(2)%c = 'abcdefghi'
   R(3)%c = '!...@#$%^&*('

   L%c = R%c
   print *, 'simple assignment'
   print *,  R%c
   print *,  L%c

   LL(1:3)%c = R%c
   LL(4)%c = 'QWERTYUIO'
   RR%c = LL%c

   L%c = LL(2:4)%c

   print *
   print *, 'overlapping assignment'
   print *,  RR(2:4)%c
   print *,  L%c

   nfv1 = (/1,2,3/)
   nfv2 = nfv1
   L%c = R%c
   L(nfv1)%c = L(nfv2)%c
   print *
   print *, ' vvs assignment'
   print *,  R%c
   print *,  L%c

   end


C:\gfortran>gfortran try_cg0033_41.f

C:\gfortran>a
 simple assignment
 123456789abcdefg...@#$%^&*(
 123456789abcdefg...@#$%^&*(

 overlapping assignment
 abcdefg...@#$%^&*(QWERTYUIO
 a!Q

  vvs assignment
 123456789abcdefg...@#$%^&*(
 1a!


-- 
   Summary: wrong results for structure assignment of character
components when left and right sides overlap
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dick dot hendrickson at gmail dot com


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

[Bug fortran/38914] ICE with array inquiry functions above contains in parameter expression

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2009-01-19 17:56 ---
Reduced testcase.  This appears to be an array section problem
with lbound().

  MODULE U_above_TESTS
  INTEGER, PARAMETER, DIMENSION(0:20,4) :: IP_ARRAY2_4_S = 0
  INTEGER, PARAMETER, DIMENSION(2) ::  IP_ARRAY1_32_S =
 $(/  LBOUND(IP_ARRAY2_4_S(5:10,2:3))/)
  END MODULE U_above_TESTS


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.2.5 4.3.3 4.4.0
   Priority|P3  |P4
   Last reconfirmed|-00-00 00:00:00 |2009-01-19 17:56:51
   date||


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

[Bug other/32754] The opt?-gen.awk file generators produce incorrect credits

[rob1weld at aol dot com]

--- Comment #4 from rob1weld at aol dot com  2009-01-19 18:01 ---
(In reply to comment #3)
> Fixed in GCC 4.2.4 and GCC 4.3. I don't think it is worth to fix this in
> earlier versions.

Thank you for fixing this.

BTW: Between 4.2.1 and 4.2.2 the gcc compiler changed from "supporting old
and broken C++ code" to "refusing old and broken C++ code". 

The result of this change in the compiler was that much of the C++ code on
the Internet (even from programming teams at well known Universities) would
no longer compile "as-is" and one was required to fix the source that once
built without error. 

In later versions of gcc it got to the point were one could not compile
the Linux Kernel since it was gcc (correct) opinion that the code was
written too poorly and gcc's arrogance that it was to be unworthy of 
compiling.

You may want to go back to 4.2.1 since it is a different compiler than
gcc version 4.2.4 due to the "big break" in the C++ compiler.

I keep 3.4.3 (supplied with my OS), 4.2.1, and the Trunk on my system
and that way I can compile just about anything without having to do
extensive fixups to the C++ code.

There was a couple of weeks when 4.2.1 had _most_ of it's "make check"
tests pass for all Languages with nearly no FAILs, if you really feel
ambitious you might want to check the Testsuite Reports for a particular
day that had a revision with the best score.


Thanks again for fixing this, it was an annoyance while debugging that
portion of the code.

Rob


-- 


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

[Bug bootstrap/32690] 4.2.1 Bootstrap fails - gcc-4_2-branch/boehm-gc/ltconfig: No such file or directory

[rob1weld at aol dot com]

--- Comment #2 from rob1weld at aol dot com  2009-01-19 18:06 ---
(In reply to comment #1)
> A few hours later and it failed for want of ltcf-c.sh and ltcf-cxx.sh. I ran
> gcc_update again and that fixed the configure / makefile problem of not 
> copying
> those files over.

I no longer get that problem with "gcc version 4.4.0 20090117 (experimental)
[trunk revision 143454]".


> There is still the annoyance of the build re-starting too far back and using
> "rm -f stage_current" / "rm -rf stagefeedback-*" - even if you only type just
> "make" (instead of "make profiledbootstrap").
> It would be better if the build made it as far as the libraries then it would
> not try to remake the 'use feedback' stages and simply continue the libraries
> where it left off.

That problem still occurs with "gcc version 4.4.0 20090117 (experimental)
[trunk revision 143454]".

Rob


-- 


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

[Bug fortran/38852] UBOUND fails for negative stride triplets

[mikael at gcc dot gnu dot org]

--- Comment #3 from mikael at gcc dot gnu dot org  2009-01-19 18:48 ---
DLA => DDA(2:3, 1:3:2, 5:4:-1, NF2, NF5:NF2:MF2)

The descriptor built for DLA has negative strides for dimension >= 3. 
This makes ubound fail. 


-- 


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

[Bug fortran/38915] wrong results for structure assignment of character components when left and right sides overlap

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-01-19 18:49 ---
Confirm. ICE with 4.1.x and 4.2.x and wrong code with 4.3.x and 4.4.

Thanks for the report.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||32834
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2009-01-19 18:49:04
   date||


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

[Bug rtl-optimization/35729] const volatile variable access incorrectly hoisted out of loop

[ubizjak at gmail dot com]

--- Comment #13 from ubizjak at gmail dot com  2009-01-19 18:53 ---
(In reply to comment #10)
> Fails on s390 and s390x as well.

And alpha.


-- 


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

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

[hjl dot tools at gmail dot com]

--- Comment #12 from hjl dot tools at gmail dot com  2009-01-19 19:01 
---
How can I reproduce it on Linux/x86-64, assuming I know nothing
about rtems and sim?


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com


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

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

[joel at gcc dot gnu dot org]

--- Comment #13 from joel at gcc dot gnu dot org  2009-01-19 19:09 ---
Created an attachment (id=17147)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17147&action=view)
script to run psim

script to run psim to reproduce bug.  Specifying the device tree is painful.


-- 


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

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

[joel at gcc dot gnu dot org]

--- Comment #14 from joel at gcc dot gnu dot org  2009-01-19 19:15 ---
(In reply to comment #12)
> How can I reproduce it on Linux/x86-64, assuming I know nothing
> about rtems and sim?
> 

You don't have to know much of anything.  It should be reproducible with 
powerpc-elf but this is the known way to the goal.  I configure gdb 
6.8 this way using a GCC SVN native compiler.

rm -rf b-gdb && mkdir b-gdb && cd b-gdb && \
../gdb-6.8/configure --target=powerpc-rtems4.10 \
  --disable-werror --enable-sim --enable-sim-hardware --enable-timebase \
--enable-sim-trace 2>&1 && \
make

That should give you an executable named "run" in the sim/ppc subdirectory
of the build tree.  There are two attachments to this PR:
 + powerpc-ticker-ticker.ralf.bz2
 + psim-4.10

uncompress the ticker executable anywhere.

The psim-4.10 scripts creates a psim device tree and runs the executable
that is $1.  Edit to fix the definition of "RUN" to get the "run" executable
in the build tree.

I place the psim-4.10 program in my "gcc-pr38587" and it picks up the
run executable from the build.  It assumes you are in the build tree
when run.  

../psim-4.10 /home/joel/powerpc-psim-ticker.ralf

It is a hack to make this easier to check since it has been 
broken for over a month and I have checked it every few days.

It will print a few lines from tasks TA1, TA2, and TA3 and when it gets to
the end, you get an assertion.

Looking at the code in idecode.c, I suspect a setjmp/longjmp interacting
with the register usage.  But who knows.  

If you have trouble, I will try to answer quickly.  Thanks.


-- 


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

[Bug target/38902] [4.3 Regression] __builtin_strcpy doesn't work with -fstack-protector

[hjl dot tools at gmail dot com]

--- Comment #10 from hjl dot tools at gmail dot com  2009-01-19 19:30 
---
The problem is x86 doesn't set the memory size correct for rep_stos.
Gcc 4.3.3 gave:

(gdb) call debug_rtx (destmem)
(mem/s/c:BLK (reg:DI 59) [3 buffer+8 S1 A64])
(gdb) 

Jakub's patch corrected it to

(gdb) call debug_rtx (destmem)
(mem/s/c:BLK (reg:DI 59) [0 buffer+8 S1016 A64])
(gdb) 

Since scheduler thinks the size of memory is 1, it changed

(insn:HI 13 12 15 2 x.c:5 (parallel [
(set (reg:DI 2 cx [62])
(const_int 0 [0x0]))
(set (reg:DI 5 di [59])
(plus:DI (ashift:DI (reg:DI 2 cx [62])
(const_int 3 [0x3]))
(reg:DI 5 di [59])))
(set (mem/s/c:BLK (reg:DI 5 di [59]) [3 buffer+8 S1 A64])
(const_int 0 [0x0]))
(use (reg:DI 0 ax [60]))
(use (reg:DI 2 cx [62]))
]) 801 {*rep_stosdi_rex64} (expr_list:REG_DEAD (reg:DI 0 ax [60])
(expr_list:REG_UNUSED (reg:DI 5 di [59])
(expr_list:REG_UNUSED (reg:DI 2 cx [62])
(nil)
...
(insn:HI 22 65 24 2 x.c:6 (set (mem/s/c:HI (plus:DI (reg/f:DI 7 sp)
(const_int 24 [0x18])) [0 buffer+24 S2 A64])
(const_int 111 [0x6f])) 53 {*movhi_1} (nil)

into

(insn:HI 22 65 24 2 x.c:6 (set (mem/s/c:HI (plus:DI (reg/f:DI 7 sp)
(const_int 24 [0x18])) [0 buffer+24 S2 A64])
(const_int 111 [0x6f])) 53 {*movhi_1} (nil)
...
(insn:TI 13 22 68 2 x.c:5 (parallel [
(set (reg:DI 2 cx [62])
(const_int 0 [0x0]))
(set (reg:DI 5 di [59])
(plus:DI (ashift:DI (reg:DI 2 cx [62])
(const_int 3 [0x3]))
(reg:DI 5 di [59])))
(set (mem/s/c:BLK (reg:DI 5 di [59]) [3 buffer+8 S1 A64])
(const_int 0 [0x0]))
(use (reg:DI 0 ax [60]))
(use (reg:DI 2 cx [62]))
]) 801 {*rep_stosdi_rex64} (expr_list:REG_DEAD (reg:DI 0 ax [60])
(expr_list:REG_UNUSED (reg:DI 5 di [59])
(expr_list:REG_UNUSED (reg:DI 2 cx [62])
(nil)


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Severity|normal  |critical


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

[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[dominiq at lps dot ens dot fr]

--- Comment #45 from dominiq at lps dot ens dot fr  2009-01-19 19:31 ---
The patch in comment #44 fixes the problem (as far as I can test it) on
i686-apple-darwin9 without regression for gcc, g++, gfortran, objc, and
obj-c++, full test this night.

Thanks for the patch.


-- 


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

[Bug c++/23287] [4.2/4.3/4.4 regression] Explicitly invoking destructor of template class in a template and is dependent

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|nathan at gcc dot gnu dot   |jason at gcc dot gnu dot org
   |org |
 Status|REOPENED|ASSIGNED
   Last reconfirmed|2006-08-28 17:56:33 |2009-01-19 19:44:51
   date||


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

[Bug fortran/38914] ICE with array inquiry functions above contains in parameter expression

[mikael at gcc dot gnu dot org]

--- Comment #2 from mikael at gcc dot gnu dot org  2009-01-19 19:47 ---
the lbound should be simplified in simplify_bound even if the ARRAY argument is
not a full array.


-- 


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

[Bug target/38902] [4.3 Regression] __builtin_strcpy doesn't work with -fstack-protector

[hjl dot tools at gmail dot com]

--- Comment #11 from hjl dot tools at gmail dot com  2009-01-19 20:30 
---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00948.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||01/msg00948.html


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

[Bug fortran/36874] Add shape checks to cshift/eoshift

[dfranke at gcc dot gnu dot org]

-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dfranke at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-07-28 10:48:37 |2009-01-19 20:41:54
   date||


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

[Bug libstdc++/38916] New: auto_ptr_ref conversion incorrectly releases ownership

[janis at gcc dot gnu dot org]

The ISO C++ standard in section 20.4.5.3 defines the effects and postconditions
of auto_ptr conversions.  It says that

  template operator auto_ptr_ref() throw();

returns "an auto_ptr_ref that holds *this".  Unlike the other conversions in
the same section, there is no call to release(), so after the call the original
auto_ptr should still own the memory.

The following testcase is based on one from a testing group within IBM (not a
customer-reported problem).  It shows that creating a reference to an auto_ptr
releases the memory from that auto_ptr when it should not.  I see this behavior
on powerpc*-linux for GCC 3.3 and later.  I haven't tried earlier versions.


// Test the effects and postconditions of auto_ptr conversions, defined
// in the ISO C++ standard in section 20.4.5.3.

#include 
extern "C" void abort (void);

int failures = 0;

#ifdef DBG
#include 
#define FAILURE(m)  \
  { \
std::cout << "line " << __LINE__ << ":  " << m << std::endl;\
failures++; \
  }
#else
#define FAILURE(m) { failures++; }
#endif

struct X { };

int
main ()
{
  X* xptr = new X;

  std::auto_ptr ap1 (xptr);
  if (ap1.get() != xptr)
FAILURE ("ap1 does not own the memory")

  // Construct a reference to ap1; there should be no release.
  std::auto_ptr_ref ref (ap1.operator std::auto_ptr_ref ());
  if (ap1.get() != xptr)
FAILURE ("ap1 no longer owns the memory after constructing a reference")

  // Construct ap2 from the reference.  ap2 should now own the memory
  // and ap1 should no longer hold it.
  std::auto_ptr ap2(ref);
  if (ap2.get() != xptr)
FAILURE ("ap2 does not own the memory after constructing from reference")
  if (ap1.get() != (X*)0)
FAILURE ("ap1 is not zeroed after constructing ap2 from reference")

  if (failures != 0)
abort ();

  return 0;
}


elm3b145% /opt/gcc-nightly/trunk/bin/g++ -DDBG bug.cc
elm3b145% LD_LIBRARY_PATH=/opt/gcc-nightly/trunk/lib ./a.out
line 34:  ap1 no longer owns the memory after constructing a reference
Aborted


-- 
   Summary: auto_ptr_ref conversion incorrectly releases ownership
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org


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

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

[hjl dot tools at gmail dot com]

--- Comment #15 from hjl dot tools at gmail dot com  2009-01-19 21:38 
---
Revision 142516 gave:

[...@gnu-28 pr38587]$ ./psim-4.10 ./powerpc-psim-ticker.ralf
events.c:329: assertion failed - !events->processing

[...@gnu-28 pr38587]$ 

Revision 142517 gave:

[...@gnu-34 pr38587]$ ./psim-4.10 ./powerpc-psim-ticker.ralf


*** CLOCK TICK TEST ***
TA1  - rtems_clock_get - 09:00:00   12/31/1988
TA2  - rtems_clock_get - 09:00:00   12/31/1988
TA3  - rtems_clock_get - 09:00:00   12/31/1988
TA1  - rtems_clock_get - 09:00:05   12/31/1988
TA2  - rtems_clock_get - 09:00:10   12/31/1988
TA1  - rtems_clock_get - 09:00:10   12/31/1988
TA3  - rtems_clock_get - 09:00:15   12/31/1988
TA1  - rtems_clock_get - 09:00:15   12/31/1988
TA2  - rtems_clock_get - 09:00:20   12/31/1988
TA1  - rtems_clock_get - 09:00:20   12/31/1988
TA1  - rtems_clock_get - 09:00:25   12/31/1988
TA3  - rtems_clock_get - 09:00:30   12/31/1988
TA1  - rtems_clock_get - 09:00:30   12/31/1988
TA2  - rtems_clock_get - 09:00:30   12/31/1988
*** END OF CLOCK TICK TEST ***
idecode.c:6591: assertion failed - current_cpu >= 0 && current_cpu < nr_cpus

[...@gnu-34 pr38587]$ 

Is that possible a bug in sim?


-- 


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

[Bug fortran/38917] New: Can't use DATA to initialize pointer to array to NULL()

[dick dot hendrickson at gmail dot com]

The following program gives error messages for using DATA to iniialize pointers
to arrays to NULL()

Dick Hendrickson

  SUBROUTINE PF0005

! fails on Windows XP
! gcc version 4.4.0 20081219 (experimental) [trunk revision 142842] (GCC)

  REAL, SAVE, POINTER :: PTR1
  INTEGER, POINTER   :: PTR2(:,:,:)
  CHARACTER(LEN=1), SAVE, POINTER :: PTR3(:)

  DATA  PTR1 / NULL() /
  DATA  PTR2 / NULL() /
  DATA  PTR3 / NULL() /

  end subroutine pf0005


C:\documents and settings\s and h\my documents\g_experiments\gfortran>gfortran
t
ry_pf0005.f
try_pf0005.f:12.10:

  DATA  PTR3 / NULL() /
  1
Error: Nonconstant array section at (1) in DATA statement
try_pf0005.f:11.10:

  DATA  PTR2 / NULL() /
  1
Error: Nonconstant array section at (1) in DATA statement


-- 
   Summary: Can't use DATA to initialize pointer to array to NULL()
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dick dot hendrickson at gmail dot com


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

[Bug fortran/38918] New: compile time error for DATA of NULL() to pointer structure component

[dick dot hendrickson at gmail dot com]

The following program gives a compile time error for a DATA assignment of
NULL() to a structure component.  Probably related to 38917

Dick Hendrickson

  SUBROUTINE PF0009

! fails on Windows XP
! gcc version 4.4.0 20081219 (experimental) [trunk revision 142842] (GCC)

  TYPE  :: HAS_POINTER
INTEGER, POINTER:: PTR_S
  END TYPE HAS_POINTER
  TYPE (HAS_POINTER)  ::  PTR_ARRAY(5)

  DATA PTR_ARRAY(1)%PTR_S  /NULL()/

  end subroutine pf0009


C:\gfortran>gfortran try_pf0009.f
try_pf0009.f:11.38:

  DATA PTR_ARRAY(1)%PTR_S  /NULL()/
  1
Error: NULL appears on right-hand side in assignment at (1)


-- 
   Summary: compile time error for DATA of NULL() to pointer
structure component
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dick dot hendrickson at gmail dot com


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

[Bug fortran/38863] WHERE with multiple elemental defined assignments gives wrong answer

[mikael at gcc dot gnu dot org]

--- Comment #3 from mikael at gcc dot gnu dot org  2009-01-19 22:18 ---
> > I suspect the following  is invalid as the arguments to the defined 
> > assignment
> > alias.
> >
> 
> Why do you think it is invalid?  
Because the arguments to the i_to_t (or l_to_t) alias. They point to the same
data. 
I may be wrong however (actually it wouldn't be the first time when arguing
about standard conformance). I'm sure it is wrong with basic subroutines, but
mixing that with where, elemental and defined assignment doesn't make it clear. 

> For what it's worth, the test case compiles
> successfully with a different compiler.  The larger program compiles with
> several other compilers.
And it compiles with gfortran too ;). 


-- 


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

[Bug fortran/38859] [4.3/4.4 Regression] ubound and lbound treat structure component references as whole arrays

[mikael at gcc dot gnu dot org]

--- Comment #6 from mikael at gcc dot gnu dot org  2009-01-19 22:19 ---
Subject: Bug 38859

Author: mikael
Date: Mon Jan 19 22:19:34 2009
New Revision: 143501

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143501
Log:
2009-01-19  Mikael Morin  

PR fortran/38859
* simplify.c (simplify_bound): Don't use array specification
if variable or component has subsequent references.

2009-01-19  Mikael Morin  

PR fortran/38859
* gfortran.dg/bound_5.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/bound_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

[joel at gcc dot gnu dot org]

--- Comment #16 from joel at gcc dot gnu dot org  2009-01-19 22:20 ---
(In reply to comment #15)
> Revision 142516 gave:
> 
> [...@gnu-28 pr38587]$ ./psim-4.10 ./powerpc-psim-ticker.ralf
> events.c:329: assertion failed - !events->processing

That sounds like the previous psim miscompiled bug.

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

I closed it when the problem went away with no explanation.

I first saw the bug around this revision.

gcc (GCC) 4.4.0 20081205 (experimental) [trunk revision 142492]

So you have to go back further than that to miss psim regression #1

> 
> [...@gnu-28 pr38587]$ 
> 
> Revision 142517 gave:
> 
> [...@gnu-34 pr38587]$ ./psim-4.10 ./powerpc-psim-ticker.ralf
> 
> 
> *** CLOCK TICK TEST ***
> TA1  - rtems_clock_get - 09:00:00   12/31/1988
> TA2  - rtems_clock_get - 09:00:00   12/31/1988
> TA3  - rtems_clock_get - 09:00:00   12/31/1988
> TA1  - rtems_clock_get - 09:00:05   12/31/1988
> TA2  - rtems_clock_get - 09:00:10   12/31/1988
> TA1  - rtems_clock_get - 09:00:10   12/31/1988
> TA3  - rtems_clock_get - 09:00:15   12/31/1988
> TA1  - rtems_clock_get - 09:00:15   12/31/1988
> TA2  - rtems_clock_get - 09:00:20   12/31/1988
> TA1  - rtems_clock_get - 09:00:20   12/31/1988
> TA1  - rtems_clock_get - 09:00:25   12/31/1988
> TA3  - rtems_clock_get - 09:00:30   12/31/1988
> TA1  - rtems_clock_get - 09:00:30   12/31/1988
> TA2  - rtems_clock_get - 09:00:30   12/31/1988
> *** END OF CLOCK TICK TEST ***
> idecode.c:6591: assertion failed - current_cpu >= 0 && current_cpu < nr_cpus
> 
> [...@gnu-34 pr38587]$ 
> 
> Is that possible a bug in sim?
> 

psim is very old code written by Andrew Cagney over a decade ago.  It has
compiled and worked with all gcc versions since that time.  My test script
on CFARM builds a native GCC from SVN and uses that to build the crosses.


-- 


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

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[mckelvey at maskull dot com]

--- Comment #10 from mckelvey at maskull dot com  2009-01-19 22:29 ---
(In reply to comment #7)
> Created an attachment (id=17132)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17132&action=view) [edit]
> Move _ctors* and _chkstk* to import lib
> 
> Danny, this is the approach that I think I'd like to take for Cygwin; what do
> you think about doing it this way?  I'm currently testing a full bootstrap
> using this patch.
> 

This patch works for Cygwin.


-- 


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

[Bug fortran/38863] WHERE with multiple elemental defined assignments gives wrong answer

[dick dot hendrickson at gmail dot com]

--- Comment #4 from dick dot hendrickson at gmail dot com  2009-01-19 22:31 
---
Subject: Re:  WHERE with multiple elemental defined assignments gives wrong
answer

On Mon, Jan 19, 2009 at 4:18 PM, mikael at gcc dot gnu dot org
 wrote:
>
>
> --- Comment #3 from mikael at gcc dot gnu dot org  2009-01-19 22:18 
> ---
>> > I suspect the following  is invalid as the arguments to the defined 
>> > assignment
>> > alias.
>> >
>>
>> Why do you think it is invalid?
> Because the arguments to the i_to_t (or l_to_t) alias. They point to the same
> data.
> I may be wrong however (actually it wouldn't be the first time when arguing
> about standard conformance). I'm sure it is wrong with basic subroutines, but
> mixing that with where, elemental and defined assignment doesn't make it 
> clear.

Defined assignment is sort of a special case.  A statement like

  A = B

is equivalent to
CALL DEFINED_ROUTINE ( A, (B) )

The "extra" parenthesis allow something like

  A = A

to work like

CALL DEFINED_ROUTINE ( A, (A)  )

and it is legal for the first argument to be intent(out) since the first
and second arguments are different.   See 12.3.2.1.2 in F95

Dick Hendrickson


>
>> For what it's worth, the test case compiles
>> successfully with a different compiler.  The larger program compiles with
>> several other compilers.
> And it compiles with gfortran too ;).
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38863
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>


-- 


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

[Bug fortran/38907] [4.3/4.4 Regression ] ICE when contained function has same name as module function and used in expression

[mikael at gcc dot gnu dot org]

--- Comment #4 from mikael at gcc dot gnu dot org  2009-01-19 22:33 ---
This removes the ICE:

Index: primary.c
===
--- primary.c   (révision 143501)
+++ primary.c   (copie de travail)
@@ -2370,6 +2370,8 @@
   bool implicit_char;
   gfc_ref *ref;

+  where = gfc_current_locus;
+
   m = gfc_match_name (name);
   if (m != MATCH_YES)
 return m;
@@ -2385,7 +2387,6 @@

   sym = symtree->n.sym;
   e = NULL;
-  where = gfc_current_locus;

   /* If this is an implicit do loop index and implicitly typed,
  it should not be host associated.  */


-- 


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

[Bug libstdc++/38916] auto_ptr_ref conversion incorrectly releases ownership

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-01-19 22:35 
---
Note that auto_ptr is deprecated for the next Standard, replaced by unique_ptr
(which we deliver in C++0x mode). In fact the specifications of auto_ptr are
known to be irreparably broken.  That means we must be *extremely* careful
here, if we touch the code we can destabilize an already brittle behavior.

Do we have evidence that other widespread implementations actually behave
differently than libstdc++-v3 here?


-- 


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

[Bug fortran/38907] [4.3/4.4 Regression ] ICE when contained function has same name as module function and used in expression

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2009-01-19 22:39 ---
> This removes the ICE: ...

Do you understand why?


-- 


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

[Bug libstdc++/38916] auto_ptr_ref conversion incorrectly releases ownership

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2009-01-19 22:45 ---
I assume that the person who sent me the test did so because it passes with
some other implementation, but that doesn't mean it's widespread.  It's fine
with me if you say it won't be fixed.


-- 


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

[Bug middle-end/38857] [4.4 Regression] ICE in selective scheduler

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2009-01-19 22:49 ---
Yah, seen -> CONFIRMED


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-19 22:49:52
   date||


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

[Bug c++/23287] [4.2/4.3/4.4 regression] Explicitly invoking destructor of template class in a template and is dependent

[jason at gcc dot gnu dot org]

--- Comment #22 from jason at gcc dot gnu dot org  2009-01-19 22:50 ---
Subject: Bug 23287

Author: jason
Date: Mon Jan 19 22:50:43 2009
New Revision: 143502

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143502
Log:
PR c++/23287
* parser.c (cp_parser_unqualified_id): In a template,
accept ~identifier.
* typeck.c (lookup_destructor): Handle IDENTIFIER_NODE.

Added:
trunk/gcc/testsuite/g++.dg/template/dtor5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libfortran/38871] [4.4 Regression] libgfortran.so.3 dropped __iso_c_binding_c_f_procpointer@@GFORTRAN_1.0

[steven at gcc dot gnu dot org]

--- Comment #11 from steven at gcc dot gnu dot org  2009-01-19 22:53 ---
I vote WONTFIX.  No user is ever going to notice this.


-- 


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

[Bug c++/23287] [4.2/4.3 regression] Explicitly invoking destructor of template class in a template and is dependent

[jason at gcc dot gnu dot org]

--- Comment #23 from jason at gcc dot gnu dot org  2009-01-19 23:05 ---
Fixed for 4.4.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work|3.3.4   |3.3.4 4.4.0
Summary|[4.2/4.3/4.4 regression]|[4.2/4.3 regression]
   |Explicitly invoking |Explicitly invoking
   |destructor of template class|destructor of template class
   |in a template and is|in a template and is
   |dependent   |dependent


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

[Bug fortran/38907] [4.3/4.4 Regression ] ICE when contained function has same name as module function and used in expression

[pault at gcc dot gnu dot org]

--- Comment #6 from pault at gcc dot gnu dot org  2009-01-19 23:08 ---
Created an attachment (id=17148)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17148&action=view)
A patch for the PR

This regtests and bootstraps on FC9/x86_i64.  I'll do ChangeLogs and so on
tomorrow.

Thanks for the report, Dick!

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug libstdc++/38916] auto_ptr_ref conversion incorrectly releases ownership

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-01-19 23:12 
---
Please, double check that, if possible. Then we'll see...
By the way, we are essentially following Josuttis' implementation, in his book.


-- 


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

[Bug c/38387] [4.4 Regression] psim miscompiled

[hjl dot tools at gmail dot com]

--- Comment #15 from hjl dot tools at gmail dot com  2009-01-19 23:28 
---
This isn't really fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WORKSFORME  |


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

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

[hjl dot tools at gmail dot com]

--- Comment #17 from hjl dot tools at gmail dot com  2009-01-19 23:29 
---
*** Bug 38387 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c/38387] [4.4 Regression] psim miscompiled

[hjl dot tools at gmail dot com]

--- Comment #16 from hjl dot tools at gmail dot com  2009-01-19 23:29 
---


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


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

[hjl dot tools at gmail dot com]

--- Comment #18 from hjl dot tools at gmail dot com  2009-01-19 23:35 
---
(In reply to comment #11)
> (In reply to comment #6)
> > Can you attach preprocessed source of idecode.c at least?  Can you track 
> > down
> > where in idecode.c the bug is and wrap a main () around that piece, making 
> > it
> > an executable testcase?
> 
> psim is automatically generated code.  I have no idea how to narrow it down
> to an executable test case.  I included my gdb configuration, psim
> test program, and preprocessed source.  I will upload the script I
> am using to run it since you have to have a device tree.
> 
> Hmmm... this is the code where the assert happens:
> 
>   /* now establish the restart target */
>   psim_set_halt_and_restart(system, &halt, &restart);
>   if (setjmp(restart)) {
> current_cpu = psim_last_cpu(system);
> ASSERT(current_cpu >= 0 && current_cpu < nr_cpus);
>   }
> 
> Is it possible that setjmp/longjmp is not preserving a register that
> gcc x86_64 is now using?
> 

This is an IRA bug. -fno-ira fixes it. This may be caused by revision
139996:

http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00315.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||vmakarov at redhat dot com
   Keywords||ra, wrong-code
   Last reconfirmed|-00-00 00:00:00 |2009-01-19 23:35:49
   date||


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

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

[hjl dot tools at gmail dot com]

--- Comment #19 from hjl dot tools at gmail dot com  2009-01-19 23:41 
---
Revert revision revision 139996 doesn't solve the problem.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|2009-01-19 23:35:49 |2009-01-19 23:41:45
   date||


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

[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih

[howarth at nitro dot med dot uc dot edu]

--- Comment #46 from howarth at nitro dot med dot uc dot edu  2009-01-19 
23:44 ---
I can confirm that gcc trunk with the proposed patch can now build xplor-nih at
-O3 (with to resorting to -funroll-loops) and the output code works correctly
now on i686-apple-darwin9. Thanks for fixing this.


-- 


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

[Bug middle-end/38219] gcc.dg/tree-ssa/vrp47.c fails on powerpc

[janis at gcc dot gnu dot org]

--- Comment #4 from janis at gcc dot gnu dot org  2009-01-20 00:22 ---
See the analysis in http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00801.html
which skips the test for MIPS targets.


-- 


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

[Bug libstdc++/38919] New: math_stubs_long_double.cc: error: redefinition of 'long double ...'

[pluto at agmk dot net]

building 4.4 snap with mingw-w64-snapshot-20081115.tar.bz2 ends with:

(...)
libtool: compile: 
/home/users/pluto/rpm/BUILD/gcc-4.4-20090116/BUILDDIR/./gcc/xgcc -shared-libgcc
-B/home/users/pluto/rpm/BUILD/gcc-4.4-20090116/BUILDDIR/./gcc -nostdinc++
-L/home/users/pluto/rpm/BUILD/gcc-4.4-20090116/BUILDDIR/x86_64-mingw32/libstdc++-v3/src
-L/home/users/pluto/rpm/BUILD/gcc-4.4-20090116/BUILDDIR/x86_64-mingw32/libstdc++-v3/src/.libs
-L/home/users/pluto/rpm/BUILD/gcc-4.4-20090116/BUILDDIR/x86_64-mingw32/winsup/mingw
-L/home/users/pluto/rpm/BUILD/gcc-4.4-20090116/BUILDDIR/x86_64-mingw32/winsup/w32api/lib
-isystem /home/users/pluto/rpm/BUILD/gcc-4.4-20090116/winsup/mingw/include
-isystem /home/users/pluto/rpm/BUILD/gcc-4.4-20090116/winsup/w32api/include
-B/usr/x86_64-mingw32/bin/ -B/usr/x86_64-mingw32/lib/ -isystem
/usr/x86_64-mingw32/include -isystem /usr/x86_64-mingw32/sys-include
-I/home/users/pluto/rpm/BUILD/gcc-4.4-20090116/BUILDDIR/x86_64-mingw32/libstdc++-v3/include/x86_64-mingw32
-I/home/users/pluto/rpm/BUILD/gcc-4.4-20090116/BUILDDIR/x86_64-mingw32/libstdc++-v3/include
-I/home/users/pluto/rpm/BUILD/gcc-4.4-20090116/libstdc++-v3/libsupc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2
-fno-strict-aliasing -fwrapv -march=x86-64 -c
../../../../libstdc++-v3/src/math_stubs_long_double.cc  -DDLL_EXPORT -DPIC -o
.libs/math_stubs_long_double.o
../../../../libstdc++-v3/src/math_stubs_long_double.cc: In function 'long
double fabsl(long double)':
../../../../libstdc++-v3/src/math_stubs_long_double.cc:40: error: redefinition
of 'long double fabsl(long double)'
/usr/x86_64-mingw32/include/math.h:181: error: 'long double fabsl(long double)'
previously defined here
../../../../libstdc++-v3/src/math_stubs_long_double.cc: In function 'long
double modfl(long double, long double*)':
../../../../libstdc++-v3/src/math_stubs_long_double.cc:172: error: redefinition
of 'long double modfl(long double, long double*)'
/usr/x86_64-mingw32/include/math.h:187: error: 'long double modfl(long double,
long double*)' previously defined here
make[4]: *** [math_stubs_long_double.lo] Error 1


-- 
   Summary: math_stubs_long_double.cc: error: redefinition of 'long
double ...'
vs. /usr/x86_64-mingw32/include/math.h
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC target triplet: x86_64-mingw32


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

[Bug libstdc++/38919] math_stubs_long_double.cc: error: redefinition of 'long double ...' vs. /usr/x86_64-mingw32/include/math.h

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-01-20 01:09 
---
Benjamin, can you have a look?


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||bkoz at redhat dot com
Summary|math_stubs_long_double.cc:  |math_stubs_long_double.cc:
   |error: redefinition of 'long|error: redefinition of 'long
   |double ...' |double ...' vs. /usr/x86_64-
   |vs. /usr/x86_64-|mingw32/include/math.h
   |mingw32/include/math.h  |


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

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

[hjl dot tools at gmail dot com]

--- Comment #20 from hjl dot tools at gmail dot com  2009-01-20 02:00 
---
The problem may something to do with

setjmp
...
while (1)
{
  foo (); // foo calls longjmp and foo is inlined.
}


-- 


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

[Bug other/38920] New: throwing ex. across dlls doesn't work.

[pluto at agmk dot net]

$ x86_64-mingw32-g++ -v
Reading specs from /usr/lib64/gcc/x86_64-mingw32/4.4.0/specs
Target: x86_64-mingw32
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--includedir=/usr/x86_64-mingw32/include --with-gnu-as --with-gnu-ld
--with-sysroot=/usr/x86_64-mingw32 --enable-shared --enable-threads=win32
--disable-sjlj-exceptions --enable-languages=c,c++ --enable-c99
--enable-long-long --enable-decimal-float=yes --enable-multilib
--enable-cmath --disable-nls --with-gnu-as --with-gnu-ld
--with-mangler-in-ld
--with-gxx-include-dir=/usr/x86_64-mingw32/include/c++/4.4.0
--disable-libstdcxx-pch --enable-__cxa_atexit --disable-libmudflap
--disable-libssp --with-pkgversion=PLD-Linux
--with-bugurl=http://bugs.pld-linux.org
--build=x86_64-pld-linux --host=x86_64-pld-linux --target=x86_64-mingw32
Thread model: win32
gcc version 4.4.0 20090116 (experimental) (PLD-Linux)



a simple testcase that throws an exception from test.dll
into main.exe causes an error:

d:\w64\main.exe
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

afaics the test.dll exports all these typeinfos:

[Ordinal/Name Pointer] Table
[   0] _Z9exceptionv
[   1] _ZN2ExC1ERKSs
[   2] _ZN2ExC2ERKSs
[   3] _ZN2ExD0Ev
[   4] _ZN2ExD1Ev
[   5] _ZTI2Ex
[   6] _ZTISt13runtime_error
[   7] _ZTISt9exception
[   8] _ZTS2Ex
[   9] _ZTSSt13runtime_error
[  10] _ZTSSt9exception
[  11] _ZTV2Ex

but the main.exe import only one symbol from test.dll:

DLL Name: test.dll
vma:  Hint/Ord Member-Name Bound-To
13a70   0  _Z9exceptionv

DLL Name: libgcc_s_1.dll
vma:  Hint/Ord Member-Name Bound-To
135ac   1  _Unwind_DeleteException
135c8   6  _Unwind_GetDataRelBase
135e4   9  _Unwind_GetIPInfo
135f8  10  _Unwind_GetLanguageSpecificData
1361c  11  _Unwind_GetRegionStart
13638  12  _Unwind_GetTextRelBase
13654  13  _Unwind_RaiseException
13670  14  _Unwind_Resume
13684  15  _Unwind_Resume_or_Rethrow
136a0  16  _Unwind_SetGR
136b0  17  _Unwind_SetIP
136c0  35  __deregister_frame_info
136dc  83  __register_frame_info

full example attached.


-- 
   Summary: throwing ex. across dlls doesn't work.
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC target triplet: x86_64-mingw32


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

[Bug other/38920] throwing ex. across dlls doesn't work.

[pluto at agmk dot net]

--- Comment #1 from pluto at agmk dot net  2009-01-20 02:51 ---
Created an attachment (id=17149)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17149&action=view)
testcase


-- 


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

[Bug rtl-optimization/38921] New: [4.3 Regression] NULL access in delay-slot

[hp at gcc dot gnu dot org]

With 4.3 branch at revision 143494 (probably also at least 135713, but that has
local patches I don't care to revert to verify) the attached code puts the
p->next load in the delay-slot of the NULL-check branch, yielding a NULL
access.
I'm guessing a reorg.c bug...

(It doesn't seem to happen at HEAD/4.4 at 143507 which instead has some weird
and suboptimal cross-jumping behavior.)


-- 
   Summary: [4.3 Regression] NULL access in delay-slot
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu, i686-unknown-linux-gnu
GCC target triplet: cris-*-* and crisv32-*-*


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

[Bug rtl-optimization/38921] [4.3 Regression] NULL access in delay-slot

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2009-01-20 03:57 ---
Created an attachment (id=17150)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17150&action=view)
testcase

Compile at -O2.  Run in simulator (note the linker option) or compile with -O2
-S and observe:

move.d _alarmlist,$r9
move.d [$r9],$r9
.L19:
test.d $r9
bne .L19
move.d [$r9],$r9

Or compile Linux and observe oopses all over...


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hp at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug boehm-gc/37017] Using --enable-threads=solaris breaks near end of build in boehm-gc configury

[rob1weld at aol dot com]

--- Comment #4 from rob1weld at aol dot com  2009-01-20 04:05 ---
(In reply to comment #1)
> I really don't think using solaris threads is that well supported anymore.  Is
> there a reason why you are not using just --enable-threads=pthreads?

I have another reason for the compiler to support Solaris threading
on this Platform, it is 'expected' by gdb. This is from code compiled by:
gcc version 4.4.0 20090117 (experimental) [trunk revision 143454].

# gdb simtest
GNU gdb (GDB) 6.8.50.20090115-cvs
(gdb) b 8
Breakpoint 1 at 0x804883f: file simtest.f, line 8.
(gdb) r
Starting program: /usr/share/src/gcc_build/gcc/testsuite/gcc/simtest 
warning: rw_common (): unable to read at addr 0x155708
warning: sol_thread_new_objfile: td_ta_new: Debugger service failed
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.

Breakpoint 1, MAIN__ () at simtest.f:8
8 call sub
(gdb) 


The "warning: sol_thread_new_objfile" line is from: 'gdb-6.8/gdb/sol-thread.c'.

static void
sol_thread_new_objfile (struct objfile *objfile)
{
  td_err_e val;
...
  if (val == TD_NOLIBTHREAD)
return;
  else if (val != TD_OK)
{
  warning (_("sol_thread_new_objfile: td_ta_new: %s"), td_err_string
(val));
  return;
}

  sol_thread_active = 1;
}


Between ./configuring using "--with-gnu-as --with-as=/usr/local/bin/as 
--with-gnu-ld --with-ld=/usr/local/bin/ld" and using the Posix thread 
model on i386-pc-solaris2.11 we end up confusing gdb build with an unusual
Solaris configuration.

Gdb expects the Solaris Platform to be different than what gcc is providing
and for Solaris' compiler (_even_ _if_ it is gcc) to support the model
--enable-threads=solaris . 

This is due to gdb's expectation that the libthread_db and libthread
provided by the Operating System are in use. If we can not build the
compiler with the correct options for this Platform then gdb suffers.

When we get that warning it also means "sol_thread_active != 1" .

While it would be correct for gdb to fix _their_ configury to correctly
_detect_ the features that are available we should also fix _our_ 
configury to correctly _provide_ the features we need.

Rob


-- 


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

[Bug libstdc++/38919] math_stubs_long_double.cc: error: redefinition of 'long double ...' vs. /usr/x86_64-mingw32/include/math.h

[bkoz at redhat dot com]

--- Comment #2 from bkoz at redhat dot com  2009-01-20 04:21 ---

If this is a native build, then GLIBCXX_CHECK_MATH_SUPPORT should have defined

_GLIBCXX_HAVE_FABSL
_GLIBCXX_HAVE_MODFL

in c++config.h. One would have seen something like:

checking for fabsl declaration... yes
checking for fabsl... (cached) yes

checking for modfl declaration... yes
checking for modfl... (cached) yes


when configuring. Please let me know what your see and what macros are defined
in c++config.h.

However, if this is a cross compile, then crossconfig.m4 is wrong:

  *-mingw32*)
AC_DEFINE(HAVE_STRTOF)
AC_DEFINE(HAVE_STRTOLD)
GLIBCXX_CHECK_LINKER_FEATURES
;;

would have to be something like:

  *-mingw32*)
AC_DEFINE(HAVE_STRTOF)
AC_DEFINE(HAVE_STRTOLD)
AC_DEFINE(HAVE_MODFL)
AC_DEFINE(HAVE_FABSL)
GLIBCXX_CHECK_LINKER_FEATURES
;;


-- 


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

[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update

[dave dot korn dot cygwin at gmail dot com]

--- Comment #11 from dave dot korn dot cygwin at gmail dot com  2009-01-20 
04:32 ---
Created an attachment (id=17151)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17151&action=view)
Fill out missing syms from shared libgcc using static libgcc archive.

(In reply to comment #10)
> (In reply to comment #7)
> > Created an attachment (id=17132)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17132&action=view) [edit]
> > Move _ctors* and _chkstk* to import lib

> This patch works for Cygwin.

:-)  Thanks for testing that.  I'm actually going to submit /this/ patch for
inclusion in mainline, once it's finished bootstrapping and testing; Danny is
right that this is just the simplest way to go.

  cheers,
DaveK


-- 

dave dot korn dot cygwin at gmail dot com changed:

   What|Removed |Added

  Attachment #17132|0   |1
is obsolete||


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

[Bug middle-end/38587] [4.4 Regression] psim miscompiled #2

[hjl dot tools at gmail dot com]

--- Comment #21 from hjl dot tools at gmail dot com  2009-01-20 05:00 
---
(In reply to comment #20)
> The problem may something to do with
> 
> setjmp
> ...
> while (1)
> {
>   foo (); // foo calls longjmp and foo is inlined.
> }
> 

The problem is

  if (setjmp (buf))
{
  /* Restore registers from stack.  */
}

  while (1)
{
  bar ();   /* Reuse stack slots used to restore registers after
   longjmp.  */
  foo ();   /* Call longjmp.  */
}

IRA should avoid reusing stack slots used to restore registers after
longjmp.


-- 


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

[Bug libstdc++/32666] FAIL: abi_check hppa

[bkoz at redhat dot com]

--- Comment #17 from bkoz at redhat dot com  2009-01-20 05:51 ---

The float versions were added in r143457

http://gcc.gnu.org/ml/gcc-cvs/2009-01/msg00470.html

hpux 11 looks fine, but I don't see 10.x results.


-- 


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

[Bug fortran/38859] [4.3 Regression] ubound and lbound treat structure component references as whole arrays

[pault at gcc dot gnu dot org]

--- Comment #7 from pault at gcc dot gnu dot org  2009-01-20 05:54 ---
Ticked off 4.4...:-)

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.3/4.4 Regression] ubound |[4.3 Regression] ubound and
   |and lbound treat structure  |lbound treat structure
   |component references as |component references as
   |whole arrays|whole arrays


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

[Bug other/38920] throwing ex. across dlls doesn't work.

[dannysmith at users dot sourceforge dot net]

--- Comment #2 from dannysmith at users dot sourceforge dot net  2009-01-20 
06:07 ---
libstdc++ also needs to be built and linked in as dll.

Search mingw archive lists for other examples and approaches.

Danny


-- 

dannysmith at users dot sourceforge dot net changed:

   What|Removed |Added

 CC||dannysmith at users dot
   ||sourceforge dot net
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-20 06:07:57
   date||


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

[Bug fortran/38917] Can't use DATA to initialize pointer to array to NULL()

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-01-20 07:25 ---
Confirm. Thanks for the report.

R532 data-stmt-constant   is ...
  or null-init

R507 null-init   is function-reference
C506 (R507) The function-reference shall be a reference to the NULL intrinsic
function with no arguments

Probably a duplicate of PR 38918.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||32834
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2009-01-20 07:25:22
   date||


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