[Bug middle-end/23769] always inline short functions if inlining would be as small as non-inlined code

[ash at onezero dot org]

--- Comment #7 from ash at onezero dot org  2005-12-10 06:23 ---
(In reply to comment #6)
> (In reply to comment #5)
> > Yes, I'm running the most recent one of those.  The discussion in the 
> > cygwin 
> > lists does not make it appear that it is easy to compile and install gcc.
> That is not true but what ever.
> No feedback in 3 months so closing as invalid.

What is not true but what ever?


-- 


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

[Bug c++/25337] New: ICE with template processing

[halcy0n at gentoo dot org]

Here is a testcase that results in an ICE:

#include 

typedef char present_t;
typedef struct { char a[2]; } absent_t;

template  T& MakeT();

template 
struct test
{
//   template 
//   struct helper{};

  template ().operator[](0))>
  struct helper{};

  template 
  static absent_t is_here(...);

  template 
  static present_t is_here(helper*);

  enum { ret = (sizeof(is_here(0)) == sizeof(present_t)) };
};

struct A { };
struct B { int operator[](int n) { return n; } };

struct X : public A { };
struct Y : public B { };

int main()
{
  std::cout << "A has [] : " << test::ret << std::endl;
  std::cout << "B has [] : " << test::ret << std::endl;

  std::cout << "X:A has [] : " << test::ret << std::endl;
  std::cout << "Y:B has [] : " << test::ret << std::endl;
}

The commented out block is the version of helper that doesn't cause the ICE,
while the second does.  This is broken on 3.4.4, 4.0.2, 4.1.0.  Works with
3.3.6.


-- 
   Summary: ICE with template processing
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: halcy0n at gentoo dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug web/3119] Broken gcc mailing list archives

[me at cgf dot cx]

--- Comment #8 from me at cgf dot cx  2005-12-10 05:45 ---
Subject: Re:  Broken gcc mailing list archives

On Sat, Dec 10, 2005 at 05:30:21AM -, pinskia at gcc dot gnu dot org wrote:
>
>-- 
>
>pinskia at gcc dot gnu dot org changed:
>
>   What|Removed |Added
>
>   Last reconfirmed|2005-09-07 16:53:59 |2005-12-10 05:30:21
>   date||
>
>
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3119
>
>--- You are receiving this mail because: ---
>You are the assignee for the bug, or are watching the assignee.

Given the age of these bugs should we just close them as "wontfix"?  I don't
see anyone stepping up to fix them anytime soon.

cgf


-- 


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

[Bug c/7948] gcc fails to fault gnu extension with -std=c99

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2005-12-10 05:45 ---
_Complex int is another extension which is only warned with -pedantic included
with -std=c99.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2005-09-10 16:28:52 |2005-12-10 05:45:16
   date||


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

[Bug c/3481] function attributes should apply to function pointers too

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2005-12-10 05:42 ---
Format now applies to function types for at least 4.1.0 and above.


-- 


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

[Bug c/2995] __complex__ int typecasts maybe broken

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2005-12-10 05:41 ---
The "wrong-code" issue has been fixed since 4.0.0.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords|wrong-code  |


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

[Bug bootstrap/24062] Parse error in options.h

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2005-12-10 05:33 ---
Not a GCC so closing as works for me.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug web/20336] gaps in list archives

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED


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

[Bug other/23581] Build failure on MINGW for gcc-4.1-20050819

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2005-12-10 05:29 ---
No feedback in 3 months so closing as invalid.  Other people have built on
mingw recently so it has to be something with your configuration.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/23769] always inline short functions if inlining would be as small as non-inlined code

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2005-12-10 05:27 ---
(In reply to comment #5)
> Yes, I'm running the most recent one of those.  The discussion in the cygwin 
> lists does not make it appear that it is easy to compile and install gcc.

That is not true but what ever.

No feedback in 3 months so closing as invalid.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug fortran/25270] gfortran.dg/array-1.f90 (and a lot of others) fails with a type mismatch

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2005-12-10 05:20 ---
assign_5.f90, assign_6.f, logint-1.f, logint-3.f, 7388.f, and a couple of
others were fixed by:
2005-12-09  Roger Sayle  <[EMAIL PROTECTED]>

PR fortran/22527
* f95-lang.c (gfc_truthvalue_conversion): Use a zero of the correct
integer type when building an inequality.

This bug report is not fully fixed yet though.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|gfortran.dg/array-1.f90 |gfortran.dg/array-1.f90 (and
   |fails with a type mismatch  |a lot of others) fails with
   ||a type mismatch


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

[Bug fortran/22527] fortran produces mismatch types in comparision with integer to logic assignment

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2005-12-10 05:17 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug rtl-optimization/24982] [4.1/4.2 Regression] Bootstrap failure with ICE in refers_to_regno_for_reload_p

[kargl at gcc dot gnu dot org]

--- Comment #10 from kargl at gcc dot gnu dot org  2005-12-10 04:58 ---
The patch from comment #6 no longer applies.  It appears that this ChangeLog

2005-12-07  J"orn Rennecke <[EMAIL PROTECTED]>

* reload.h (reg_equiv_invariant): Declare.
* reload.c (refers_to_regno_for_reload_p): Allow R to be a pseudo
register also when reg_equiv_invariant[R] is set.

has included some, but not all of the comment #6 patch.


-- 


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

[Bug middle-end/25335] [4.1/4.2 Regression] reload leaves insns from earlier passes around: fatal for postinc

[hp at gcc dot gnu dot org]

--- Comment #2 from hp at gcc dot gnu dot org  2005-12-10 04:53 ---
I mean for *this* test-case it's exposed by that fix.  The leaving-behind
of reload-insns from earlier rounds for each new reload round is general.


-- 


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

[Bug testsuite/25336] New: Identical tests: gfortran.dg/g77/20030115-1.f gfortran.dg/g77/pr9258.f

[hp at gcc dot gnu dot org]

Perhaps remove one?


-- 
   Summary: Identical tests: gfortran.dg/g77/20030115-1.f
gfortran.dg/g77/pr9258.f
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org


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

[Bug libstdc++/17038] ABI impacting issue in time_put

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.1.0   |---


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

[Bug libstdc++/16896] Use of non-reserved names in stl_list.h

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.1.0   |---


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

[Bug rtl-optimization/951] Documentation of compiler passes and sources very out of date

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.1.0   |---


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

[Bug middle-end/25335] [4.1/4.2 Regression] reload leaves insns from earlier passes around: fatal for postinc

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-10 04:00 ---
So this is a latent bug exposed by that fix which means this should be marked
as a regression.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|reload leaves insns from|[4.1/4.2 Regression] reload
   |earlier passes around: fatal|leaves insns from earlier
   |for postinc |passes around: fatal for
   ||postinc
   Target Milestone|--- |4.1.0


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

[Bug middle-end/25335] New: reload leaves insns from earlier passes around: fatal for postinc

[hp at gcc dot gnu dot org]

See assembly output for gcc.target/cris/rld-legit2.c (here for cris-axis-elf):
_g:
subq 4,$sp
move $srp,[$sp]
subq 40,$sp
movem $r8,[$sp]
move $r10,$srp
move.d $r11,[$sp+36]
move $srp,$r9
addq 2,$r9
move $r9,$srp
subq 2,$r9
move.w [$r9+],$r11
move.w [$r9+],$r12
movs.w $r12,$r12
move.d [$sp+36],$r13
clear.b [$r12+$r13.b]
move $srp,$r10
movem [$sp+],$r8
addq 4,$sp
jump [$sp+]

Note the two post-increments; the second one is used and gets the wrong value.
(A failing executable test-case can trivially be constructed and will be.)
Reload seems to need two rounds, but the emitted reload insns for each pass
is left around. This is exposed but not actually caused by the fix for
PR middle-end/24912.


-- 
   Summary: reload leaves insns from earlier passes around: fatal
for postinc
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC target triplet: cris-*-*


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

[Bug middle-end/25333] FAIL: gcc.dg/attr-weakref-1.c execution test

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-10 03:48 ---
I almost think this is a dup of bug 25276.


-- 


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

[Bug c++/25331] FAIL: tmpdir-g++.dg-struct-layout-1/t028 cp_compat_[xy]_tst.o compile

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2005-12-10 01:51 ---
These FAIL introduced between "Thu Dec  8 09:08:46 UTC 2005 (revision 108221M)"
and "Fri Dec  9 04:17:20 UTC 2005 (revision 108273M)" also for cris-axis-elf
and
cris-axis-linux-gnu, likely together with the other new
tmpdir-g++.dg-struct-layout-tests (but no other FAILs among them, also no fail
for mmix-knuth-mmixware.
Author of test-cases CC:ed: there's a suspicous mix of attributes aligned and
packed that I can't say is valud; may need component change from "c++" to
"testsuite".


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jakub at redhat dot com
  GCC build triplet|hppa2.0w-hp-hpux11.11   |
   GCC host triplet|hppa2.0w-hp-hpux11.11   |
 GCC target triplet|hppa2.0w-hp-hpux11.11   |cris-axis-elf, cris-axis-
   ||linux-gnu and hppa2.0w-hp-
   ||hpux11.11


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

[Bug java/25330] A race condition in write_classfile

[hjl at lucon dot org]

--- Comment #1 from hjl at lucon dot org  2005-12-10 01:48 ---
I got another one:

/export/build/gnu/gcc/build-x86_64-linux/gcc/gcj
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Wno-deprecated
--encoding=UTF-8 --bootclasspath '' --classpath
..:/net/gnu-13/export/gnu/src/gcc/gcc/libjava:/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/w3c_dom:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/sax:.:
-C -d . -MD -MF lists/java-rmi-dgc.deps -MT lists/java-rmi-dgc.stamp -MP
@lists/java-rmi-dgc.list
/net/gnu-13/export/gnu/src/gcc/gcc/libjava/java/net/URL.java: In class
'java.net.VMNetworkInterface':
/net/gnu-13/export/gnu/src/gcc/gcc/libjava/java/net/URL.java: In method
'java.net.VMNetworkInterface.getInterfaces()':
/net/gnu-13/export/gnu/src/gcc/gcc/libjava/java/net/URL.java:1: fatal error:
can't create ./java/rmi/activation/ActivationSystem.class: No such file or
directory
compilation terminated.
make[8]: *** [lists/gnu-src-gcc.stamp] Error 1
make[8]: *** Waiting for unfinished jobs
echo timestamp > lists/java-rmi-dgc.stamp

This time, there wass no "java/rmi/activation" directory under libjava:

[EMAIL PROTECTED] build-x86_64-linux]$ ls x86_64-unknown-linux-gnu/libjava/java/
io  lang  net  nio  text  util


-- 


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

[Bug c/25334] New: The example for flexible array member doesn't work.

[gcc-bugzilla at gcc dot gnu dot org]

Using an example from the GCC documentation doesn't work. I don't know if the
documentation is broken
or the compiler.

Environment:
System: FreeBSD inchoate.localdomain 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sat
Oct 8 10:25:52 CST 2005 root@:/usr/obj/usr/src/sys/INCHOATE i386

host: i386-portbld-freebsd7.0
build: i386-portbld-freebsd7.0
target: i386-portbld-freebsd7.0
configured with: ./..//gcc-4.1-20051202/configure --disable-nls
--with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=41
--libdir=/usr/local/lib/gcc/i386-portbld-freebsd7.0/4.1.0
--with-gxx-include-dir=/usr/local/lib/gcc/i386-portbld-freebsd7.0/4.1.0/include/c++/
--disable-shared --disable-libgcj --prefix=/usr/local i386-portbld-freebsd7.0

How-To-Repeat:
This file is based on the example in section 5.12 of the manual (Arrays of Zero
length)

cat >test.c
#include 

int
main(int argc, char **argv) {
struct foo { int x; int y[]; };

struct foo a = { 1, { 2, 3, 4 } };

printf("sizeof(a) = %d\n", sizeof(a));
}

[EOT]

~> gcc41 test.c -o test
[inchoate 11:55] ~ >gcc41 test.c -o test
test.c: In function 'main':
test.c:7: error: non-static initialization of a flexible array member
test.c:7: error: (near initialization for 'a')

gcc 3.4.4 gives the same result.


--- Comment #1 from darius at dons dot net dot au  2005-12-10 01:37 ---
Fix:
Depends whether the compiler or the documentation is wrong :)


-- 
   Summary: The example for flexible array member doesn't work.
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: darius at dons dot net dot au
 GCC build triplet: i386-portbld-freebsd7.0
  GCC host triplet: i386-portbld-freebsd7.0
GCC target triplet: i386-portbld-freebsd7.0


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

[Bug fortran/22527] fortran produces mismatch types in comparision with integer to logic assignment

[sayle at gcc dot gnu dot org]

--- Comment #2 from sayle at gcc dot gnu dot org  2005-12-10 01:14 ---
Subject: Bug 22527

Author: sayle
Date: Sat Dec 10 01:14:38 2005
New Revision: 108341

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108341
Log:

PR fortran/22527
* f95-lang.c (gfc_truthvalue_conversion): Use a zero of the correct
integer type when building an inequality.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/f95-lang.c


-- 


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

[Bug rtl-optimization/24899] [4.1/4.2 Regression] loop.c miscompiles libgnomecanvas

[steven at gcc dot gnu dot org]

--- Comment #19 from steven at gcc dot gnu dot org  2005-12-10 00:31 ---
This is beyond my RTL fu.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/25319] namelist error

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2005-12-10 00:09 
---
Not a bug.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug middle-end/25333] New: FAIL: gcc.dg/attr-weakref-1.c execution test

[danglin at gcc dot gnu dot org]

Executing on host: /home/dave/gnu/gcc-4.0/objdir/gcc/xgcc
-B/home/dave/gnu/gcc-4
.0/objdir/gcc/ /home/dave/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/attr-weakref-1.c
  -O2 -fno-show-column 
/home/dave/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/attr-wea
kref-1a.c /home/dave/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/attr-weakref-1b.c 
-lm
   -o ./attr-weakref-1.exe(timeout = 300)
PASS: gcc.dg/attr-weakref-1.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/dave/gnu/gcc-4.0/objdir/gcc::/home/dave/gnu/gc
c-4.0/objdir/gcc:
FAIL: gcc.dg/attr-weakref-1.c execution test

This is a regression.  See
http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00168.html


-- 
   Summary: FAIL: gcc.dg/attr-weakref-1.c execution test
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa-unknown-linux-gnu
  GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu


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

[Bug testsuite/20772] x86 tests should run on both i?86 and x86_64

[ghazi at gcc dot gnu dot org]

--- Comment #14 from ghazi at gcc dot gnu dot org  2005-12-10 00:04 ---
Subject: Bug 20772

Author: ghazi
Date: Sat Dec 10 00:04:44 2005
New Revision: 108327

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108327
Log:
PR testsuite/20772
* g++.old-deja/g++.pt/asm1.C, gcc.c-torture/compile/2804-1.c,
gcc.target/i386/asm-3.c, gcc.target/i386/clobbers.c: Use ilp32 in
dg-skip-if target selector.


Modified:
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
branches/gcc-4_1-branch/gcc/testsuite/g++.old-deja/g++.pt/asm1.C
branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/2804-1.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.target/i386/asm-3.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.target/i386/clobbers.c


-- 


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

[Bug testsuite/20772] x86 tests should run on both i?86 and x86_64

[ghazi at gcc dot gnu dot org]

--- Comment #13 from ghazi at gcc dot gnu dot org  2005-12-10 00:01 ---
Subject: Bug 20772

Author: ghazi
Date: Sat Dec 10 00:01:25 2005
New Revision: 108326

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108326
Log:
PR testsuite/20772
* g++.old-deja/g++.pt/asm1.C, gcc.c-torture/compile/2804-1.c,
gcc.target/i386/asm-3.c, gcc.target/i386/clobbers.c: Use ilp32 in
dg-skip-if target selector.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.old-deja/g++.pt/asm1.C
trunk/gcc/testsuite/gcc.c-torture/compile/2804-1.c
trunk/gcc/testsuite/gcc.target/i386/asm-3.c
trunk/gcc/testsuite/gcc.target/i386/clobbers.c


-- 


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

[Bug testsuite/20772] x86 tests should run on both i?86 and x86_64

[ghazi at gcc dot gnu dot org]

--- Comment #12 from ghazi at gcc dot gnu dot org  2005-12-09 23:56 ---
Subject: Bug 20772

Author: ghazi
Date: Fri Dec  9 23:56:34 2005
New Revision: 108325

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108325
Log:
PR testsuite/20772
* g++.dg/eh/simd-1.C, g++.dg/eh/simd-2.C, g++.dg/opt/inline9.C,
gcc.dg/20020418-1.c, gcc.dg/20031102-1.c, gcc.dg/ia64-sync-1.c,
gcc.dg/ia64-sync-2.c, gcc.dg/ia64-sync-3.c, gcc.dg/ia64-sync-4.c,
gcc.dg/ifcvt-fabs-1.c, gcc.dg/loop-3.c, gcc.dg/nested-calls-1.c,
gcc.dg/pr20017.c, gcc.dg/smod-1.c, gcc.dg/sync-2.c,
gcc.dg/tls/opt-3.c, gcc.dg/torture/badshift.c: Add x86_64 cases
and/or merge with i?86 cases.

* gcc.dg/tls/opt-3.c: Require effective target fpic.


Modified:
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/eh/simd-1.C
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/eh/simd-2.C
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/inline9.C
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/20020418-1.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/20031102-1.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/ia64-sync-1.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/ia64-sync-2.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/ia64-sync-3.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/ia64-sync-4.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/ifcvt-fabs-1.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/loop-3.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/nested-calls-1.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr20017.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/smod-1.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/sync-2.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tls/opt-3.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/badshift.c


-- 


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

[Bug testsuite/20772] x86 tests should run on both i?86 and x86_64

[ghazi at gcc dot gnu dot org]

--- Comment #11 from ghazi at gcc dot gnu dot org  2005-12-09 23:46 ---
Subject: Bug 20772

Author: ghazi
Date: Fri Dec  9 23:46:42 2005
New Revision: 108324

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108324
Log:
PR testsuite/20772
* g++.dg/eh/simd-1.C, g++.dg/eh/simd-2.C, g++.dg/opt/inline9.C,
gcc.dg/20020418-1.c, gcc.dg/20031102-1.c, gcc.dg/ia64-sync-1.c,
gcc.dg/ia64-sync-2.c, gcc.dg/ia64-sync-3.c, gcc.dg/ia64-sync-4.c,
gcc.dg/ifcvt-fabs-1.c, gcc.dg/loop-3.c, gcc.dg/nested-calls-1.c,
gcc.dg/pr20017.c, gcc.dg/smod-1.c, gcc.dg/sync-2.c,
gcc.dg/tls/opt-3.c, gcc.dg/torture/badshift.c: Add x86_64 cases
and/or merge with i?86 cases.

* gcc.dg/tls/opt-3.c: Require effective target fpic.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/eh/simd-1.C
trunk/gcc/testsuite/g++.dg/eh/simd-2.C
trunk/gcc/testsuite/g++.dg/opt/inline9.C
trunk/gcc/testsuite/gcc.dg/20020418-1.c
trunk/gcc/testsuite/gcc.dg/20031102-1.c
trunk/gcc/testsuite/gcc.dg/ia64-sync-1.c
trunk/gcc/testsuite/gcc.dg/ia64-sync-2.c
trunk/gcc/testsuite/gcc.dg/ia64-sync-3.c
trunk/gcc/testsuite/gcc.dg/ia64-sync-4.c
trunk/gcc/testsuite/gcc.dg/ifcvt-fabs-1.c
trunk/gcc/testsuite/gcc.dg/loop-3.c
trunk/gcc/testsuite/gcc.dg/nested-calls-1.c
trunk/gcc/testsuite/gcc.dg/pr20017.c
trunk/gcc/testsuite/gcc.dg/smod-1.c
trunk/gcc/testsuite/gcc.dg/sync-2.c
trunk/gcc/testsuite/gcc.dg/tls/opt-3.c
trunk/gcc/testsuite/gcc.dg/torture/badshift.c


-- 


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

[Bug testsuite/20772] x86 tests should run on both i?86 and x86_64

[ghazi at gcc dot gnu dot org]

--- Comment #10 from ghazi at gcc dot gnu dot org  2005-12-09 23:38 ---
Subject: Bug 20772

Author: ghazi
Date: Fri Dec  9 23:38:19 2005
New Revision: 108323

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108323
Log:
PR testsuite/20772
* g++.dg/opt/life1.C, g++.old-deja/g++.abi/aggregates.C,
g++.old-deja/g++.abi/align.C, g++.old-deja/g++.abi/bitfields.C,
g++.old-deja/g++.law/weak.C, g++.old-deja/g++.pt/asm2.C,
gcc.dg/2724-1.c, gcc.dg/pragma-align.c: Also test on
x86_64-*-linux*.


Modified:
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/life1.C
branches/gcc-4_1-branch/gcc/testsuite/g++.old-deja/g++.abi/aggregates.C
branches/gcc-4_1-branch/gcc/testsuite/g++.old-deja/g++.abi/align.C
branches/gcc-4_1-branch/gcc/testsuite/g++.old-deja/g++.abi/bitfields.C
branches/gcc-4_1-branch/gcc/testsuite/g++.old-deja/g++.law/weak.C
branches/gcc-4_1-branch/gcc/testsuite/g++.old-deja/g++.pt/asm2.C
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/2724-1.c
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pragma-align.c


-- 


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

[Bug testsuite/20772] x86 tests should run on both i?86 and x86_64

[ghazi at gcc dot gnu dot org]

--- Comment #9 from ghazi at gcc dot gnu dot org  2005-12-09 23:34 ---
Subject: Bug 20772

Author: ghazi
Date: Fri Dec  9 23:34:09 2005
New Revision: 108322

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108322
Log:
PR testsuite/20772
* g++.dg/opt/life1.C, g++.old-deja/g++.abi/aggregates.C,
g++.old-deja/g++.abi/align.C, g++.old-deja/g++.abi/bitfields.C,
g++.old-deja/g++.law/weak.C, g++.old-deja/g++.pt/asm2.C,
gcc.dg/2724-1.c, gcc.dg/pragma-align.c: Also test on
x86_64-*-linux*.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/opt/life1.C
trunk/gcc/testsuite/g++.old-deja/g++.abi/aggregates.C
trunk/gcc/testsuite/g++.old-deja/g++.abi/align.C
trunk/gcc/testsuite/g++.old-deja/g++.abi/bitfields.C
trunk/gcc/testsuite/g++.old-deja/g++.law/weak.C
trunk/gcc/testsuite/g++.old-deja/g++.pt/asm2.C
trunk/gcc/testsuite/gcc.dg/2724-1.c
trunk/gcc/testsuite/gcc.dg/pragma-align.c


-- 


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

[Bug libfortran/24224] Generalized internal array IO not implemented.

[jvdelisle at verizon dot net]

--- Comment #5 from jvdelisle at verizon dot net  2005-12-09 23:05 ---
Subject: Re:  Generalized internal array IO not
 implemented.

fxcoudert at gcc dot gnu dot org wrote:
> --- Comment #4 from fxcoudert at gcc dot gnu dot org  2005-12-09 09:05 
> ---
> Jerry, isn't that one completely fixed?
> 
> 
For the most part this is fixed.  We do not handle the case of negative
strides, 
but we do handle strides of more than 1.  So I was leaving it open as a
reminder 
to get back to that after we run out of more serious bugs in the I/O library. 
We have not had any user issues on this.


-- 


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

Re: [Bug libfortran/24224] Generalized internal array IO not implemented.

[Jerry DeLisle]

fxcoudert at gcc dot gnu dot org wrote:

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2005-12-09 09:05 
---
Jerry, isn't that one completely fixed?


For the most part this is fixed.  We do not handle the case of negative strides, 
but we do handle strides of more than 1.  So I was leaving it open as a reminder 
to get back to that after we run out of more serious bugs in the I/O library. 
We have not had any user issues on this.

[Bug c/25332] 64 bit multiplication incorrectly folded.

[jyates at netezza dot com]

--- Comment #2 from jyates at netezza dot com  2005-12-09 22:42 ---
Subject: RE:  64 bit multiplication incorrectly folded.

Is it possible to determine what commit between 3.3.3 and 3.4.0
actually fixed the bug?  I have a very strong motivation to see
if I can propagate the fix back to the 2.96 code base.

/john

-Original Message-
From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED]
Sent: Friday, December 09, 2005 4:38 PM
To: John Yates
Subject: [Bug c/25332] 64 bit multiplication incorrectly folded.




--- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-09 21:37
---
Fixed in 3.4.0 and above, since 3.3.x and below are no longer being maintained
closing as fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||wrong-code
  Known to fail||3.3.3 3.2.3 3.0.4
  Known to work||3.4.0 4.0.0 4.1.0 2.95.3
 Resolution||FIXED
   Target Milestone|--- |3.4.0


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

--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.


-- 


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

[Bug ada/25245] Discriminant is left uninitialized.

[listor1 dot rombobeorn at comhem dot se]

--- Comment #7 from listor1 dot rombobeorn at comhem dot se  2005-12-09 
22:35 ---
Subject: Re:  Discriminant is left uninitialized.

> But the constraint_error for "OS of A1b" looks correct, and if commented
> the one on "OS of A2b", it is a language mandated discriminant check
> failing. But may be I'm missing something, could you explain why you think
> an exception shouldn't be raised?

The discriminant check fails because OS doesn't contain any of the valid 
values 0, 1 or 2 (for NT, OS2 and Linux). If there is random data in the 
memory I expect a 3/256 chance that it will get a valid value.

The OS field shouldn't be random. It's fixed to Linux in the definition of 
Character_Encoding_A:

   This_OS : constant Known_OS := Linux;
   type Character_Encoding_A (Known : Boolean := False) is
 new Unified_Encoding_Record (Known => Known, OS => This_OS);

All objects of this type should therefore have OS=Linux, so the discriminant 
would be valid and would pass the check.


-- 


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

[Bug fortran/20839] do-loop with do-construct-name needs needs end do

[uttamp at us dot ibm dot com]

--- Comment #4 from uttamp at us dot ibm dot com  2005-12-09 21:40 ---
I did build and completed the regression test. The patch in comment #3 fixes
this problem (when compiled with -pedantic option) but gfortran still fails to
report this as an error with -std=f95 without -pedantic.

I've created a new patch where I took the Steven's patch and added GFC_STD_F95
along with pedantic check.

About the error message, how about,
"Construct name on END DO at %L does not match the Named DO construct", sounds?

Below, I'm listing the patch for completeness. Can somebody look at it pease?

Thansks,
Uttam

--- gcc_org/gcc/gcc/fortran/parse.c 2005-11-30 09:56:16.0 -0800
+++ gcc/gcc/fortran/parse.c 2005-12-09 13:33:32.0 -0800
@@ -23,6 +23,7 @@ Software Foundation, 51 Franklin Street,

 #include "config.h"
 #include "system.h"
+#include "flags.h"
 #include 
 #include "gfortran.h"
 #include "match.h"
@@ -2057,6 +2058,10 @@ loop:
   break;

 case ST_IMPLIED_ENDDO:
+  if ((pedantic || GFC_STD_F95) && gfc_current_block () != NULL)
+   gfc_error_now
+  ("Construct name on END DO at %L does not match the Named DO
construct",
+   &gfc_current_block()->declared_at);
   break;

 default:


-- 


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

[Bug c/25332] 64 bit multiplication incorrectly folded.

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-09 21:37 ---
Fixed in 3.4.0 and above, since 3.3.x and below are no longer being maintained
closing as fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||wrong-code
  Known to fail||3.3.3 3.2.3 3.0.4
  Known to work||3.4.0 4.0.0 4.1.0 2.95.3
 Resolution||FIXED
   Target Milestone|--- |3.4.0


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

[Bug c/25332] New: 64 bit multiplication incorrectly folded.

[jyates at netezza dot com]

/*
 * Compile -O0 (no optimization)
 */

#include 

typedef int int32;
typedef long long int64;


int main ()
{
int32 i = 1;/* hence (2*i)-1 below is 1... */
#define K 0x80003LL /* 64 bit constant; low 32 are 3; high 32 are 8
*/

printf("%016llx (gcc 2.96 bad:  0003)\n", K * ( (2*i) -
   1  ));
printf("%016llx (gcc 2.96 bad:  0003)\n", K * ( (2*i) -
   1LL));
printf("%016llx (gcc 2.96 bad:  0003)\n", K * ( (2*i) -
(int64)1  ));

printf("%016llx (gcc 2.96 bad:  fff80003)\n", K * (  (int64)(2*i) -
   1  ));
printf("%016llx (gcc 2.96 bad:  fff80003)\n", K * (  (int64)(2*i) -
   1LL));
printf("%016llx (gcc 2.96 bad:  fff80003)\n", K * (  (int64)(2*i) -
(int64)1  ));

printf("%016llx (gcc 2.96 good: 00080003)\n", K * (2*(int64)(  i) -
   1  ));
}


-- 
   Summary: 64 bit multiplication incorrectly folded.
   Product: gcc
   Version: 2.96
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jyates at netezza dot com


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

[Bug debug/25023] [4.1/4.2 Regression] ICE in def_cfa_1, at dwarf2out.c:792

[jakub at gcc dot gnu dot org]

--- Comment #14 from jakub at gcc dot gnu dot org  2005-12-09 20:13 ---
Created an attachment (id=10446)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10446&action=view)
gcc41-pr25023.patch

A new version of the patch.  While this bootstraps (at least on i386 I tried),
I'm getting some regressions though, particularly:
FAIL: gcc.dg/compat/scalar-by-value-4 c_compat_x_tst.o compile
FAIL: gcc.dg/compat/scalar-by-value-4 c_compat_y_tst.o compile
FAIL: gcc.dg/compat/scalar-return-4 c_compat_x_tst.o compile
FAIL: gcc.dg/compat/scalar-return-4 c_compat_y_tst.o compile
FAIL: gcc.dg/compat/struct-by-value-11 c_compat_x_tst.o compile
FAIL: gcc.dg/compat/struct-by-value-11 c_compat_y_tst.o compile

All seem to be ICEs in emit_move_resolve_push (CQI, [
(mem/i:CQI (pre_modify:SI (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -4 [0xfffc]))) [0 S2 A8])
]), where that function only handles PRE_{INC,DEC} and POST_{INC,DEC}, but
not PRE_MODIFY.  Will see if just handling {PRE,POST}_MODIFY is the right thing
there or if something different is wrong.


-- 


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

[Bug ada/25245] Discriminant is left uninitialized.

[laurent at guerby dot net]

--- Comment #6 from laurent at guerby dot net  2005-12-09 19:51 ---
I see the same thing as you on trunk x86-linux with gcc version 4.2.0 20051202
(experimental).

I agree the "not equal" part is a bug:
  With predefined "=" - A1b and A2b: not equal
should print "equal".

But the constraint_error for "OS of A1b" looks correct, and if commented the
one on "OS of A2b", it is a language mandated discriminant check failing. But
may be I'm missing something, could you explain why you think an exception
shouldn't be raised?

Today Ada front-end commits may have fixed the bug, I'm retesting.


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-12-09 19:51:33
   date||


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

[Bug libfortran/25116] [4.0] namelist read from non-opened file

[fxcoudert at gcc dot gnu dot org]

--- Comment #13 from fxcoudert at gcc dot gnu dot org  2005-12-09 18:52 
---
Committed to 4.1


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail||4.0.3
  Known to work||4.2.0 4.1.0
 Resolution||FIXED
Summary|[4.0/4.1] namelist read from|[4.0] namelist read from
   |non-opened file |non-opened file


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

[Bug libfortran/25116] [4.0/4.1] namelist read from non-opened file

[fxcoudert at gcc dot gnu dot org]

--- Comment #12 from fxcoudert at gcc dot gnu dot org  2005-12-09 18:50 
---
Subject: Bug 25116

Author: fxcoudert
Date: Fri Dec  9 18:50:48 2005
New Revision: 108314

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108314
Log:
PR libfortran/25116
* io/transfer.c (data_transfer_init): Don't set the default for
namelist I/O on preconnected files to UNFORMATTED.

Modified:
branches/gcc-4_1-branch/libgfortran/ChangeLog
branches/gcc-4_1-branch/libgfortran/io/transfer.c


-- 


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

[Bug rtl-optimization/24823] [4.1/4.2 Regression] ICE in insert_save, at caller-save.c:719

[rguenth at gcc dot gnu dot org]

--- Comment #20 from rguenth at gcc dot gnu dot org  2005-12-09 18:45 
---
I'll ping gcc-patches.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||patch


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

[Bug c++/25331] New: FAIL: tmpdir-g++.dg-struct-layout-1/t028 cp_compat_[xy]_tst.o compile

[danglin at gcc dot gnu dot org]

Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/../g++
-B/mnt/gnu/gcc-3
.3/objdir/gcc/testsuite/../  -nostdinc++
-I/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-h
pux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/mnt/gnu/gcc-3.3/objdir/hp
pa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/mnt/gnu/gcc-3.3/gcc/libstdc++-v3/lib
supc++ -I/mnt/gnu/gcc-3.3/gcc/libstdc++-v3/include/backward
-I/mnt/gnu/gcc-3.3/g
cc/libstdc++-v3/testsuite -fmessage-length=0 -w
-I/mnt/gnu/gcc-3.3/gcc/gcc/tests
uite/g++.dg/compat -fno-common   -c  -o cp_compat_x_tst.o
/mnt/gnu/gcc-3.3/objdi
r/gcc/testsuite/g++.dg-struct-layout-1/t028_x.C(timeout = 300)
/mnt/gnu/gcc-3.3/objdir/gcc/testsuite/g++.dg-struct-layout-1/t028_test.h:197:
er
ror: alignment of array elements is greater than element size
compiler exited with status 1
output is:
/mnt/gnu/gcc-3.3/objdir/gcc/testsuite/g++.dg-struct-layout-1/t028_test.h:197:
er
ror: alignment of array elements is greater than element size

FAIL: tmpdir-g++.dg-struct-layout-1/t028 cp_compat_x_tst.o compile

Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/../g++
-B/mnt/gnu/gcc-3
.3/objdir/gcc/testsuite/../  -nostdinc++
-I/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-h
pux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/mnt/gnu/gcc-3.3/objdir/hp
pa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/mnt/gnu/gcc-3.3/gcc/libstdc++-v3/lib
supc++ -I/mnt/gnu/gcc-3.3/gcc/libstdc++-v3/include/backward
-I/mnt/gnu/gcc-3.3/g
cc/libstdc++-v3/testsuite -fmessage-length=0 -w
-I/mnt/gnu/gcc-3.3/gcc/gcc/tests
uite/g++.dg/compat -fno-common   -c  -o cp_compat_y_tst.o
/mnt/gnu/gcc-3.3/objdi
r/gcc/testsuite/g++.dg-struct-layout-1/t028_y.C(timeout = 300)
/mnt/gnu/gcc-3.3/objdir/gcc/testsuite/g++.dg-struct-layout-1/t028_test.h:197:
er
ror: alignment of array elements is greater than element size
compiler exited with status 1
output is:
/mnt/gnu/gcc-3.3/objdir/gcc/testsuite/g++.dg-struct-layout-1/t028_test.h:197:
er
ror: alignment of array elements is greater than element size

FAIL: tmpdir-g++.dg-struct-layout-1/t028 cp_compat_y_tst.o compile


-- 
   Summary: FAIL: tmpdir-g++.dg-struct-layout-1/t028
cp_compat_[xy]_tst.o compile
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa2.0w-hp-hpux11.11
  GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11


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

[Bug target/25317] [4.1 Regression] hppa64 EH failures

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca  2005-12-09 
18:31 ---
Subject: Re:  [4.1 Regression] hppa64 EH failures

> --- Comment #2 from joseph at codesourcery dot com  2005-12-09 16:58 
> ---
> Subject: Re:  [4.1 Regression] hppa64 EH failures
> 
> On Fri, 9 Dec 2005, danglin at gcc dot gnu dot org wrote:
> 
> > Is this with the current CVS version of GAS?  A critical bug affecting
> > data relocations was recently fixed.
> 
> This is with the current binutils release (2.16.1); when I started 4.1 
> branch testing I made that use release binutils rather than mainline 
> binutils which is being used with mainline GCC testing, though the 
> mainline tester had only recently started using mainline binutils for 
> HP-UX before 4.1 branched and no problems had been observed before then 
> with 2.16.1.  When there's a new binutils release I expect to switch the 
> 4.1 branch testing to that.

Ok.  Can't do much about the bug in 2.16.1.

2.16.1 incorrectly handles the fixup associated with the difference
of two symbols.  The two 32-bit portions of a 64-bit difference are
swapped in 2.16.1.  This affects dwarf debugging output and EH
exception support.

I recently made dwarf2 EH support the default on both the 32 and 64-bit
hpux ports to use EH exception support.  I would have liked more time
between the gas fix and enabling this feature, but Richard was pushing.

I believe that you can avoid these errors by using the sjlj exception
support.  In a sense, these errors aren't regressions as the dwarf2
eh support is new.  With cvs binutils, I don't see any regressions
relative to the previous sjlj support on this target.

Dave


-- 


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

[Bug libstdc++/25288] std::list insert members should have no effects if an exception is thrown

[paolo at gcc dot gnu dot org]

--- Comment #4 from paolo at gcc dot gnu dot org  2005-12-09 18:25 ---
Subject: Bug 25288

Author: paolo
Date: Fri Dec  9 18:24:53 2005
New Revision: 108313

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108313
Log:
2005-12-09  Paolo Carlini  <[EMAIL PROTECTED]>
Howard Hinnant  <[EMAIL PROTECTED]>

PR libstdc++/25288
* include/bits/stl_list.h (list<>::_M_insert_dispatch, _M_fill_insert):
Remove.
(_M_initialize_dispatch, _M_fill_initialize): Add.
(list(size_type, const value_type&, const allocator_type&),
list(const list&), list(_InputIterator, _InputIterator,
const allocator_type&): Use the latter.
(insert(iterator, size_type, const value_type&), insert(iterator,
_InputIterator, _InputIterator)): Use construction & splice.
* testsuite/23_containers/list/modifiers/insert/25288.cc: New.
* testsuite/testsuite_allocator.h (class throw_allocator): Add.

* include/bits/stl_list.h (list<>::insert, erase): Fix wrong comments.

Added:
trunk/libstdc++-v3/testsuite/23_containers/list/modifiers/insert/
trunk/libstdc++-v3/testsuite/23_containers/list/modifiers/insert/25288.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_list.h
trunk/libstdc++-v3/testsuite/testsuite_allocator.h


-- 


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

[Bug rtl-optimization/24823] [4.1/4.2 Regression] ICE in insert_save, at caller-save.c:719

[kargl at gcc dot gnu dot org]

--- Comment #19 from kargl at gcc dot gnu dot org  2005-12-09 18:16 ---
I've tested this patch on amd64-*-freebsd.  It cures my
gfortran failures.  Who do we need to ping to get this
approved?


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu dot org


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

[Bug fortran/25292] ASSOCIATED( func() ) rejected ?

[eedelman at gcc dot gnu dot org]

--- Comment #5 from eedelman at gcc dot gnu dot org  2005-12-09 18:08 
---
Fixed on 4.0, 4.1 and mainline.


-- 

eedelman at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/25300] [4.1/4.2 regression] ICE with g++.dg/template/inherit.C

[reichelt at gcc dot gnu dot org]

--- Comment #2 from reichelt at gcc dot gnu dot org  2005-12-09 17:48 
---
Mark, the ICE appeared with your patch for PR20293:
http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg00580.html


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mmitchel at gcc dot gnu dot
   ||org


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

[Bug middle-end/25328] [4.0/4.1 regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1453

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2005-12-09 17:16 ---
Reduced testcase:
int main(int argc, char **argv)
{
int status = 0;
char msg[100] = "";
if(__builtin_strcmp(msg, ""))
status = 200;
}

There a couple of issue here, first DCE is not removing some code even though
it is dead code but that is not the real issue.  The real issue is that DOM is
ICEing, it is not folding *&a to a or a[0] since a is an array.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to work|4.0.1   |4.0.1 4.2.0
   Last reconfirmed|-00-00 00:00:00 |2005-12-09 17:16:30
   date||
   Target Milestone|--- |4.0.3


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

[Bug java/25330] New: A race condition in write_classfile

[hjl at lucon dot org]

On a SMP machine, with "make -j4", I got

/export/build/gnu/gcc/build-x86_64-linux/gcc/gcj
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava/
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Wno-deprecated
--encoding=UTF-8 --bootclasspath '' --classpath
..:/net/gnu-13/export/gnu/src/gcc/gcc/libjava:/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/w3c_dom:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/sax:.:
-C -d . -MD -MF lists/gnu-regexp.deps -MT lists/gnu-regexp.stamp -MP
@lists/gnu-regexp.list
echo timestamp > lists/gnu-javax-swing.stamp
echo timestamp > lists/gnu-regexp.stamp
/export/build/gnu/gcc/build-x86_64-linux/gcc/gcj
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava/
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Wno-deprecated
--encoding=UTF-8 --bootclasspath '' --classpath
..:/net/gnu-13/export/gnu/src/gcc/gcc/libjava:/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/w3c_dom:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/sax:.:
-C -d . -MD -MF lists/gnu-src-gcc.deps -MT lists/gnu-src-gcc.stamp -MP
@lists/gnu-src-gcc.list
/export/build/gnu/gcc/build-x86_64-linux/gcc/gcj
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava/
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Wno-deprecated
--encoding=UTF-8 --bootclasspath '' --classpath
..:/net/gnu-13/export/gnu/src/gcc/gcc/libjava:/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/w3c_dom:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/sax:.:
-C -d . -MD -MF lists/gnu-xml-aelfred2.deps -MT lists/gnu-xml-aelfred2.stamp
-MP @lists/gnu-xml-aelfred2.list
echo timestamp > lists/gnu-xml-aelfred2.stamp
/export/build/gnu/gcc/build-x86_64-linux/gcc/gcj
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava/
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Wno-deprecated
--encoding=UTF-8 --bootclasspath '' --classpath
..:/net/gnu-13/export/gnu/src/gcc/gcc/libjava:/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/w3c_dom:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/sax:.:
-C -d . -MD -MF lists/gnu-xml-dom.deps -MT lists/gnu-xml-dom.stamp -MP
@lists/gnu-xml-dom.list
echo timestamp > lists/gnu-xml-dom.stamp
/export/build/gnu/gcc/build-x86_64-linux/gcc/gcj
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava/
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Wno-deprecated
--encoding=UTF-8 --bootclasspath '' --classpath
..:/net/gnu-13/export/gnu/src/gcc/gcc/libjava:/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/w3c_dom:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/sax:.:
-C -d . -MD -MF lists/gnu-xml-libxmlj.deps -MT lists/gnu-xml-libxmlj.stamp -MP
@lists/gnu-xml-libxmlj.list
echo timestamp > lists/gnu-xml-libxmlj.stamp
/export/build/gnu/gcc/build-x86_64-linux/gcc/gcj
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava/
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Wno-deprecated
--encoding=UTF-8 --bootclasspath '' --classpath
..:/net/gnu-13/export/gnu/src/gcc/gcc/libjava:/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/w3c_dom:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/sax:.:
-C -d . -MD -MF lists/gnu-xml-pipeline.deps -MT lists/gnu-xml-pipeline.stamp
-MP @lists/gnu-xml-pipeline.list
echo timestamp > lists/gnu-xml-pipeline.stamp
/export/build/gnu/gcc/build-x86_64-linux/gcc/gcj
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava/
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Wno-deprecated
--encoding=UTF-8 --bootclasspath '' --classpath
..:/net/gnu-13/export/gnu/src/gcc/gcc/libjava:/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libjava:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/w3c_dom:/net/gnu-13/export/gnu/src/gcc/gcc/libjava/classpath/external/sax:.:
-C -d . -MD -MF lists/gnu-xml-stream.deps -MT lists/gnu-xml-stream.stamp -MP
@lists/gnu-xml-stream.list
echo timestamp > lists/gnu-xml-stream.stamp
/export/build/gnu/gcc/build-x86_64-linux/gcc/

[Bug tree-optimization/25329] Miscompilation in tcl, -INT_MIN test misoptimized

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-09 17:12 ---
-INT_MIN overflows so this is undefined so GCC is correct in assuming anything.

So the bug is in TCL.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/25329] New: Miscompilation in tcl, -INT_MIN test misoptimized

[matz at suse dot de]

This testcase:

int bla (long l)
{
  long lR;
  if (l < 0) {
lR = - l;
if (lR < 0) {// 2
  return 1;
}
  }
  return 0;
}

extern void abort ();
int main()
{
  if (!bla (-2147483648))
abort ();
  return 0;
}
--

when compiled with -O2 will abort.  because the inner test 2 will
be optimized away.  The variable lR is negative at that point, but
the test won't trigger as it was removed.  This same code is used in
tcl 8.4.12 to detect if the passed number is the most negative one (like in
the above example), and special case that one.  So this code relies on
the fact that -INT_MIN is INT_MIN again, and hence both <0 test will
trigger.

Now, with -fwrapv this testcase is not miscompiled, but I'm not sure
if this behaviour of GCC is really justified by the standard and our
intention.  Certainly the -INT_MIN stored into an int is implementation
defined, and older GCCs (and in fact also the current one) stores INT_MIN
into the target.  Just deleting the test seems wrong.


-- 
   Summary: Miscompilation in tcl, -INT_MIN test misoptimized
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at suse dot de
  GCC host triplet: i386-linux


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

[Bug middle-end/25328] [4.0/4.1 regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1453

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-09 17:00 ---
Hmm, the main diff is:
-msg.24 = &msg;
-D.3575 = *msg.24;
-iftmp.23 = (int) D.3575;
+msg.24 = (const unsigned char * {ref-all}) &msg;
+D.3522 = *msg.24;
+iftmp.23 = (int) D.3522;


Someone is not folding something correctly:
D.3575_10 = *&msgD.3533


Reducing (this is not fully an objc issue, I don't know why it is only
reproducible with the objc front-end though).


-- 


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

[Bug target/25317] [4.1 Regression] hppa64 EH failures

[joseph at codesourcery dot com]

--- Comment #2 from joseph at codesourcery dot com  2005-12-09 16:58 ---
Subject: Re:  [4.1 Regression] hppa64 EH failures

On Fri, 9 Dec 2005, danglin at gcc dot gnu dot org wrote:

> Is this with the current CVS version of GAS?  A critical bug affecting
> data relocations was recently fixed.

This is with the current binutils release (2.16.1); when I started 4.1 
branch testing I made that use release binutils rather than mainline 
binutils which is being used with mainline GCC testing, though the 
mainline tester had only recently started using mainline binutils for 
HP-UX before 4.1 branched and no problems had been observed before then 
with 2.16.1.  When there's a new binutils release I expect to switch the 
4.1 branch testing to that.


-- 


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

[Bug target/25317] [4.1 Regression] hppa64 EH failures

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2005-12-09 16:43 ---
Is this with the current CVS version of GAS?  A critical bug affecting
data relocations was recently fixed.


-- 

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=25317

[Bug objc/25328] New: [4.0/4.1 regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1453

[debian-gcc at lists dot debian dot org]

[forwarded from http://bugs.debian.org/342662]

seen with 4.0 20051201, 4.1 20051205, works with 4.0.2 20050808

$ cat test.m
#include 
#include 
#include 
#include 

int main(int argc, char **argv)
{
int status = 0;
char msg[100] = "";

if(!status && !strcmp(msg, "")) {
status = 200;
snprintf(msg, 100, "OK");
}
exit(0);
}
[EMAIL PROTECTED]:~/devel/inova/v3-cgid$ gcc -c -O1 test.m
test.m: In function 'main':
test.m:7: internal compiler error: in get_indirect_ref_operands, at
tree-ssa-operands.c:1453
Please submit a full bug report,
with preprocessed source if appropriate.


-- 
   Summary: [4.0/4.1 regression] ICE in get_indirect_ref_operands,
at tree-ssa-operands.c:1453
   Product: gcc
   Version: 4.0.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org


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

[Bug c++/23333] accepts invalid pure specifier

[reichelt at gcc dot gnu dot org]

--- Comment #2 from reichelt at gcc dot gnu dot org  2005-12-09 15:56 
---
Patch posted.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |reichelt at gcc dot gnu dot
   |dot org |org
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2005-
   ||12/msg00672.html
 Status|NEW |ASSIGNED
   Keywords||patch


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

[Bug testsuite/25327] New: g++.dg/compat/struct-layout-1.exp broken for installed compiler testing

[jsm28 at gcc dot gnu dot org]

The newly added g++.dg/compat/struct-layout-1.exp is broken for installed
compiler testing.  You get:
ERROR: tcl error sourcing
/scratch/gcc/nightly-2005-12-09-mainline/src/gcc-mainline/gcc/testsuite/g++.dg/compat/struct-layout-1.exp.
ERROR: can't read "rootme": no such variable

The corresponding gcc.dg tests were fixed for installed testing by:

2005-05-16  Mark Mitchell  <[EMAIL PROTECTED]>

* gcc.dg/compat/generate-random.c (config.h): Do not include.
(limits.h): Include unconditionally.
(stdlib.h): Likewise.
* gcc.dg/compat/generate-random_r.c (config.h): Do not include.
(limits.h): Include unconditionally.
(stdlib.h): Likewise.
* gcc.dg/compat/struct-layout-1.exp: Do not link with libiberty.
* gcc.dg/compat/struct-layout-1_generate.c (config.h): Do not include.
(limits.h): Include unconditionally.
(stdlib.h): Likewise.
(hashtab.h): Do not include.
(getopt.h): Likewise.
(stddef.h): Include.
(hashval_t): Define.
(struct entry): Add "next" field.
(HASH_SIZE): New macro.
(hash_table): New variable.
(switchfiles): Do not use xmalloc.
(mix): New macro.
(iterative_hash): New function.
(hasht): Remove.
(e_exists): New function.
(e_insert): Likewise.
(output): Use, instead of libiberty hashtable functions.
(main): Do not use getopt.  Do not call htab_create.


-- 
   Summary: g++.dg/compat/struct-layout-1.exp broken for installed
compiler testing
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org


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

[Bug rtl-optimization/24899] [4.1/4.2 Regression] loop.c miscompiles libgnomecanvas

[steven at gcc dot gnu dot org]

--- Comment #18 from steven at gcc dot gnu dot org  2005-12-09 15:37 ---
>From the diff between the old-loop and gcse1 dumps, this looks like a loop.c
strength reduction bug.  Indeed, -fno-strength-reduce makes the miscompilation
go away for me.


-- 


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

[Bug libfortran/21820] Really, really, horrible IO performance

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #18 from sgk at troutmask dot apl dot washington dot edu  
2005-12-09 15:09 ---
Subject: Re:  Really, really, horrible IO performance

On Fri, Dec 09, 2005 at 09:24:29AM -, fxcoudert at gcc dot gnu dot org
wrote:
> On this one, we now (due to Janne's array I/O transfer) perform better
> than Intel and Portland compilers (on i686-linux, ext3 filesystem). I
> think this can be closed as dup of 16339. For formatted I/O performance,
> we have PR 20278.

IIRC, Janne's patch did not deal with IO that involves implied-do
loops.  I'll check this later today.


-- 


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

[Bug libfortran/25132] [4.1/4.2 Regression] collect2: ld terminated with signal 10 [Bus error], core dumped

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2005-12-09 14:37 ---
This was fixed on both 4.1 and 4.2 by the fix for PR 24991. 


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/24899] [4.1/4.2 Regression] loop.c miscompiles libgnomecanvas

[steven at gcc dot gnu dot org]

--- Comment #17 from steven at gcc dot gnu dot org  2005-12-09 14:26 ---
Created an attachment (id=10445)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10445&action=view)
Smaller test case


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #10256|0   |1
is obsolete||


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

[Bug fortran/25324] Wrong DW_TAG_compile_unit generated when compiling preprocessed fortran code

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-09 14:17 ---
.ascii "/tmp/ccN3iGJ2.f\0"  # DW_AT_name
.ascii "/tmp/ccyIGO76.f\0"  # DW_AT_name


Confirmed.  This is a front-end issue.  I thought I had saw a dup of this bug
but I cannot find it.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|debug   |fortran
 Ever Confirmed|0   |1
   Keywords||wrong-debug
   Last reconfirmed|-00-00 00:00:00 |2005-12-09 14:17:28
   date||


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

[Bug libfortran/24991] [4.1/4.2 Regression] gfortran build fails with - error:gthr-default.h: No such file or directory

[jakub at gcc dot gnu dot org]

--- Comment #41 from jakub at gcc dot gnu dot org  2005-12-09 13:50 ---
Subject: Bug 24991

Author: jakub
Date: Fri Dec  9 13:50:11 2005
New Revision: 108280

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108280
Log:
PR libfortran/24991
* acinclude.m4: Include acx.m4 and no-executables.m4.
* configure.ac: Add GCC_TOPLEVEL_SUBDIRS.
* configure: Rebuilt.
* Makefile.am (AM_CPPFLAGS): Use $(host_subdir) in build dir
path.
* Makefile.in: Rebuilt.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/Makefile.am
trunk/libgfortran/Makefile.in
trunk/libgfortran/acinclude.m4
trunk/libgfortran/configure
trunk/libgfortran/configure.ac


-- 


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

[Bug rtl-optimization/25285] pessimization of goto * ("computed goto")

[anton at mips dot complang dot tuwien dot ac dot at]

--- Comment #8 from anton at mips dot complang dot tuwien dot ac dot at  
2005-12-09 13:46 ---
Subject: Re:  pessimization of goto * ("computed goto")

rguenth at gcc dot gnu dot org wrote:
> 
> 
> 
> --- Comment #7 from rguenth at gcc dot gnu dot org  2005-12-09 11:51 
> ---
> > 2) If you do reorder the blocks, you should not merge indirect
> > branches on CPUs with BTBs, for better branch prediction.
> 
> I would rather say that you should not merge frequently executed
> indirect branches.

Yes, that's a refinement.

> There is certainly an upper bound of indirect
> branches after that merging is profitable again,

Yes, once the indirect branch gets evicted from the BTB between two
executions, you might just as well merge it with another indirect
branch of the same kind.  While not all rarely executed indirect
branches will have this property (the few executions might occur in a
burst), many of them will, and for the rest the number of executions
and thus the penalty of doing it wrong will be low.

OTOH, the potential speed benefit of this refinement is also low; so
the main benefit is probably in code size.

- anton


-- 


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

[Bug c++/21494] condensed nested namespaces

[machata at post dot cz]

--- Comment #4 from machata at post dot cz  2005-12-09 12:54 ---
Created an attachment (id=10444)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10444&action=view)
Implementation of condensed nested namespaces definition, includes testcase.

I sent an email with some comments to gcc-patches:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00666.html


-- 


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

[Bug debug/25023] [4.1/4.2 Regression] ICE in def_cfa_1, at dwarf2out.c:792

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2005-12-09 12:50 
---
The patch breaks bootstrap on i686 linux:

/usr/src/packages/BUILD/gcc-4.1.0-20051209/obj-i586-suse-linux/./gcc/xgcc
-B/usr/src/packages/BUILD/gcc-4.1.0-20051209/obj-i586-suse-linux/./gcc/
-B/usr/i586-suse-linux/bin/ -B/usr/i586-suse-linux/lib/ -isystem
/usr/i586-suse-linux/include -isystem /usr/i586-suse-linux/sys-include
-DHAVE_CONFIG_H -I. -I../../../libmudflap -I. -Wall -ffunction-sections
-fdata-sections -O2 -O2 -march=i586 -mtune=i686 -fmessage-length=0 -Wall
-D_FORTIFY_SOURCE=2 -g -U_FORTIFY_SOURCE -MT mf-runtime.lo -MD -MP -MF
.deps/mf-runtime.Tpo -c ../../../libmudflap/mf-runtime.c  -fPIC -DPIC -o
.libs/mf-runtime.o
../../../libmudflap/mf-runtime.c: In function '__mfu_check':
../../../libmudflap/mf-runtime.c:1032: error: unrecognizable insn:
(insn 1384 1383 1385 31 ../../../libmudflap/mf-runtime.c:1457 (set (mem:HI
(pre_dec:SI (reg/f:SI 7 sp)) [0 S2 A8])
(reg:HI 0 ax [orig:182 __mf_lc_shift ] [182])) -1 (nil)
(nil))
../../../libmudflap/mf-runtime.c:1032: internal compiler error: in
extract_insn, at recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
See http://www.suse.de/feedback> for instructions.


-- 


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

[Bug libfortran/25132] [4.1/4.2 Regression] collect2: ld terminated with signal 10 [Bus error], core dumped

[fxcoudert at gcc dot gnu dot org]

--- Comment #1 from fxcoudert at gcc dot gnu dot org  2005-12-09 12:10 
---
Is it still happening now that the relevant part of PR 24991 has been fixed?


-- 


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

[Bug rtl-optimization/25285] pessimization of goto * ("computed goto")

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2005-12-09 11:51 ---
> 2) If you do reorder the blocks, you should not merge indirect
> branches on CPUs with BTBs, for better branch prediction.

I would rather say that you should not merge frequently executed
indirect branches.  There is certainly an upper bound of indirect
branches after that merging is profitable again, and only disabling
merging of frequently executed (from profile feedback) indirect
branches and retaining merging of the seldom executed ones will
probably be the best idea.


-- 


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

gcc-bugs@gcc.gnu.org

[schwab at suse dot de]

--- Comment #1 from schwab at suse dot de  2005-12-09 11:38 ---
See .


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/25325] GCC complains about private copy constructor, which must not be used at that point

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2005-12-09 11:37 ---
This is not a bug: see 8.5.3/5. Roughly, when you have an rvalue (like
NonCopyable()) it's implementation defined whether the constructor is called,
and, in any case, "The constructor that would be used to make the copy shall be
callable whether or not the copy is actually done". 


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

gcc-bugs@gcc.gnu.org

[pablo at ipi dot fi]

Consider following program. I think it shouldn't print anything, but when
compiled with gcc-4.0.? it prints "arr==&arr".

The idea came from comp.lang.c faq question 6.12
(http://www.eskimo.com/~scs/C-faq/q6.12.html)

#include 

int main(int argc,char** argv) {

  int arr[1];
  int (*bar)[1]=&arr;

  if ((void*)arr==(void*)&arr) {
printf("arr==&arr\n");
  }

  if (bar!=&arr) {
printf("&arr!=&arr\n");
  }

  return 0;
}

$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-shared
--with-system-zlib --libexecdir=/usr/lib --enable-nls
--without-included-gettext --enable-threads=posix --program-suffix=-4.0
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)


-- 
   Summary: if arr is an array, arr == &arr
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pablo at ipi dot fi


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

[Bug rtl-optimization/25310] [4.1 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393

[uweigand at gcc dot gnu dot org]

--- Comment #3 from uweigand at gcc dot gnu dot org  2005-12-09 11:30 
---
Looks like a reload problem, I'll be posting a patch ...


-- 

uweigand at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |uweigand at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
  Component|target  |rtl-optimization
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-12-09 11:30:15
   date||


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

[Bug target/25311] [4.1 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393

[uweigand at gcc dot gnu dot org]

--- Comment #5 from uweigand at gcc dot gnu dot org  2005-12-09 11:29 
---
Fixed.


-- 

uweigand at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/25311] [4.1 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393

[uweigand at gcc dot gnu dot org]

-- 

uweigand at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |uweigand at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-12-09 11:28:38
   date||


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

[Bug target/25311] [4.1 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393

[uweigand at gcc dot gnu dot org]

--- Comment #4 from uweigand at gcc dot gnu dot org  2005-12-09 11:26 
---
Subject: Bug 25311

Author: uweigand
Date: Fri Dec  9 11:26:47 2005
New Revision: 108279

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108279
Log:
PR target/25311
* config/s390/s390.c (struct s390_address): New field literal_pool.
(s390_decompose_address): Compute literal_pool field.  Do not 
assume register %r13 is always (and solely) used as pool base.
(s390_extra_constraint_str): Use literal_pool field.

PR target/25311
* gcc.c-torture/compile/pr25311.c: New test.

Added:
branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/pr25311.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/s390/s390.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/25311] [4.1 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393

[uweigand at gcc dot gnu dot org]

--- Comment #3 from uweigand at gcc dot gnu dot org  2005-12-09 11:20 
---
Subject: Bug 25311

Author: uweigand
Date: Fri Dec  9 11:20:40 2005
New Revision: 108278

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108278
Log:
PR target/25311
* config/s390/s390.c (struct s390_address): New field literal_pool.
(s390_decompose_address): Compute literal_pool field.  Do not 
assume register %r13 is always (and solely) used as pool base.
(s390_extra_constraint_str): Use literal_pool field.

PR target/25311
* gcc.c-torture/compile/pr25311.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr25311.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/25315] [4.2 regression] testsuite failure:27_io/basic_ostream/inserters_character/char/9555-oc.cc wchar_t/9555-oc.cc exec

[pcarlini at suse dot de]

--- Comment #4 from pcarlini at suse dot de  2005-12-09 10:33 ---
(In reply to comment #3)
> Comment #2 is generally wrong: a change in GCC codegen can certainly expose a
> coding bug in libstdc++ despite "nothing changed" there.

Yes, in principle you are right.
 As the bug is exposed
> by libstdc++, it is correct to set component to "libstdc++" pending further
> analysis.  I guess you disagree,

Yes, I disagree ;) The reason is a very pragmatic one: usually, in such cases
people stop paying attention to the issue and just wait for the libstdc++ to do
something, without any hurry. I don't like that. Of course, I don't like that
especially when I have strong reasons to believe that the bug is *not* a
libstdc++ bug, like in this case. Probably we should have a way to leave the
component totally unspecified pending further analysis.

Anyway, on ia64-linux I'm even getting a Segmentation fault, very hard to the
debug on the library side, because goes away if I rebuild the library itself
passing anything lower than -O2, -O1 suffices... Frankly, seems a
miscompilation to me.


-- 


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

[Bug rtl-optimization/24899] [4.1/4.2 Regression] loop.c miscompiles libgnomecanvas

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2005-12-09 10:10 
---
Steven, any updates on this?


-- 


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

[Bug target/24969] tmpdir-gcc.dg-struct-layout-1/t026 fails execution

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2005-12-09 10:09 
---
Honza, how went the patch testing?


-- 


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

[Bug c++/25325] New: GCC complains about private copy constructor, which must not be used at that point

[Serguei dot Kolos at cern dot ch]

The following code gives compilation error:

class NonCopyable
{
NonCopyable( const NonCopyable & );
NonCopyable & operator=( const NonCopyable & );
public:
NonCopyable() { ; }
};

void test( const NonCopyable & )
{ ; }

int main()
{
test( NonCopyable() );
}


pcatd12:tmp> g++ -v test.cxx 
Reading specs from
/afs/cern.ch/sw/lcg/contrib/gcc/3.4.4/slc3_ia32_gcc344/lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with: ../gcc-3.4.4/configure
--prefix=/afs/cern.ch/sw/lcg/contrib/gcc/3.4.4/slc3_ia32_gcc344 --enable-shared
Thread model: posix
gcc version 3.4.4

/afs/cern.ch/sw/lcg/contrib/gcc/3.4.4/slc3_ia32_gcc344/libexec/gcc/i686-pc-linux-gnu/3.4.4/cc1plus
-quiet -v -D_GNU_SOURCE test.cxx -quiet -dumpbase test.cxx -mtune=pentiumpro
-auxbase test -version -o /tmp/kolos/cc9ywMuC.s
ignoring nonexistent directory
"/afs/cern.ch/sw/lcg/contrib/gcc/3.4.4/slc3_ia32_gcc344/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/afs/cern.ch/sw/lcg/contrib/gcc/3.4.4/slc3_ia32_gcc344/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4

/afs/cern.ch/sw/lcg/contrib/gcc/3.4.4/slc3_ia32_gcc344/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/i686-pc-linux-gnu

/afs/cern.ch/sw/lcg/contrib/gcc/3.4.4/slc3_ia32_gcc344/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/backward
 /usr/local/include
 /afs/cern.ch/sw/lcg/contrib/gcc/3.4.4/slc3_ia32_gcc344/include

/afs/cern.ch/sw/lcg/contrib/gcc/3.4.4/slc3_ia32_gcc344/lib/gcc/i686-pc-linux-gnu/3.4.4/include
 /usr/include
End of search list.
GNU C++ version 3.4.4 (i686-pc-linux-gnu)
compiled by GNU C version 3.2.3 20030502 (Red Hat Linux 3.2.3-52).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128090
test.cxx: In function `int main()':
test.cxx:3: error: `NonCopyable::NonCopyable(const NonCopyable&)' is private
test.cxx:15: error: within this context


-- 
   Summary: GCC complains about private copy constructor, which must
not be used at that point
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Serguei dot Kolos at cern dot ch
  GCC host triplet: Linux 2.4.21-37.EL.cernsmp


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

[Bug libfortran/20278] Performance of formatted output

[fxcoudert at gcc dot gnu dot org]

--- Comment #6 from fxcoudert at gcc dot gnu dot org  2005-12-09 09:28 
---
Changed the title of the PR to the more general "Performance of formatted
output". My experience is that using sprintf to output float values is where
performance could be gained (computation of the logarithm of the written value
is done twice, for example). *But* that would require a home-made
floating-point I/O system, which is far from trivial to implement.

Oh, I'm also switching priority of this to enhancement, since we don't perform
too bad (20% slower than Intel, 100% slower than g77) and formatted I/O isn't
usually done on very big arrays.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
 GCC target triplet|ia64-unknown-linux-gnu  |
   Last reconfirmed|2005-09-24 05:35:49 |2005-12-09 09:28:43
   date||
Summary|Performance regression in   |Performance of formatted
   |formatted output vs. g77|output


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

[Bug libfortran/16339] Unformatted i/o on large arrays inefficient

[fxcoudert at gcc dot gnu dot org]

--- Comment #8 from fxcoudert at gcc dot gnu dot org  2005-12-09 09:24 
---
*** Bug 21820 has been marked as a duplicate of this bug. ***


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu dot org


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

[Bug libfortran/21820] Really, really, horrible IO performance

[fxcoudert at gcc dot gnu dot org]

--- Comment #17 from fxcoudert at gcc dot gnu dot org  2005-12-09 09:24 
---
On this one, we now (due to Janne's array I/O transfer) perform better than
Intel and Portland compilers (on i686-linux, ext3 filesystem). I think this can
be closed as dup of 16339. For formatted I/O performance, we have PR 20278.

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


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug libfortran/24991] [4.1/4.2 Regression] gfortran build fails with - error:gthr-default.h: No such file or directory

[jakub at gcc dot gnu dot org]

--- Comment #40 from jakub at gcc dot gnu dot org  2005-12-09 09:12 ---
No, in tree builds are still broken everywhere, as
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01687.html
hasn't been approved yet.
All the other problems are fixed already.
I'm using that patch in my tree on many arches for quite some time, although
I'm never doing in tree builds myself.


-- 


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

[Bug libfortran/24224] Generalized internal array IO not implemented.

[fxcoudert at gcc dot gnu dot org]

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2005-12-09 09:05 
---
Jerry, isn't that one completely fixed?


-- 


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

[Bug libfortran/24991] [4.1/4.2 Regression] gfortran build fails with - error:gthr-default.h: No such file or directory

[fxcoudert at gcc dot gnu dot org]

--- Comment #39 from fxcoudert at gcc dot gnu dot org  2005-12-09 09:03 
---
Jakub, Alexandre, what's the status on this PR? If I read it correctly, it's
fixed on darwin but still not fixed on hpux, is that right?


-- 


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

[Bug libfortran/24579] error on list directed read

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2005-12-09 08:59 
---
This bug as been waiting for submitters's feedback for more than a month,
closing it. If you want to report a bug, please attach a source code exhibiting
the problem.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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