[Bug ada/20530] New: gnatlink does not respect -mno-cygwin

[rolf dot ebert dot gcc at gmx dot de]

despite passing -mno-cygwin as a gnatmake option and additionally as a gnatlink 
option, gnatlink adds the cygwin path to adalib to the link command. The 
libgnat 
 is found first in the cygwin path and not in the mingw path.  The link 
consequently fails.

The problem is present on both gcc-3.3.3 and gcc-3.4.1

$ gnatmake -mno-cygwin hello -largs -v -v -mno-cygwin
gcc -c -mno-cygwin hello.adb
gnatbind -x hello.ali
gnatlink -v -v -mno-cygwin hello.ali

GNATLINK 3.3.3 (cygwin special) Copyright 1996-2002 Free Software Foundation, In
c.
gcc -c -gnatA -gnatWb -gnatiw -mno-cygwin -v -gnatws b~hello.adb
Reading specs from /usr/lib/gcc-lib/i686-pc-mingw32/3.3.3/specs
Configured with: /gcc/gcc-3.3.3-3/configure --verbose --prefix=/usr --exec-prefi
x=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/s
hare/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,java,objc,
pascal --enable-nls --without-included-gettext --enable-libgcj --with-system-zli
b --enable-interpreter --enable-threads=posix --enable-java-gc=boehm --enable-sj
lj-exceptions --disable-version-specific-runtime-libs --disable-win32-registry
Thread model: posix
gcc version 3.3.3 (cygwin special)
 /usr/lib/gcc-lib/i686-pc-mingw32/3.3.3/gnat1.exe -quiet -dumpbase b~hello.adb -
gnatA -gnatWb -gnatiw -gnatws -mno-cygwin b~hello.adb -o /c/DOKUME~1/EBERT/LOKAL
E~1/Temp/ccsNrn8f.s
 /usr/lib/gcc-lib/i686-pc-mingw32/3.3.3/../../../../i686-pc-mingw32/bin/as.exe -
-traditional-format -o b~hello.o /c/DOKUME~1/EBERT/LOKALE~1/Temp/ccsNrn8f.s
/usr/bin/gcc.exe b~hello.o ./hello.o -v -mno-cygwin -o hello.exe -L./ -L/usr/lib
/gcc-lib/i686-pc-cygwin/3.3.3/adalib/ /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/adal
ib/libgnat.a
Reading specs from /usr/lib/gcc-lib/i686-pc-mingw32/3.3.3/specs
Configured with: /gcc/gcc-3.3.3-3/configure --verbose --prefix=/usr --exec-prefi
x=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/s
hare/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,java,objc,
pascal --enable-nls --without-included-gettext --enable-libgcj --with-system-zli
b --enable-interpreter --enable-threads=posix --enable-java-gc=boehm --enable-sj
lj-exceptions --disable-version-specific-runtime-libs --disable-win32-registry
Thread model: posix
gcc version 3.3.3 (cygwin special)
 /usr/lib/gcc-lib/i686-pc-mingw32/3.3.3/collect2.exe -Bdynamic -o hello.exe /usr
/lib/gcc-lib/i686-pc-mingw32/3.3.3/../../../../i686-pc-mingw32/lib/crt2.o /usr/l
ib/gcc-lib/i686-pc-mingw32/3.3.3/crtbegin.o -L./ -L/usr/lib/gcc-lib/i686-pc-cygw
in/3.3.3/adalib/ -L/usr/lib/gcc-lib/i686-pc-mingw32/3.3.3 -L/usr/lib/gcc-lib/i68
6-pc-mingw32/3.3.3/../../../../i686-pc-mingw32/lib -L/usr/lib/gcc-lib/i686-pc-mi
ngw32/3.3.3/../../.. b~hello.o ./hello.o /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/a
dalib/libgnat.a -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -lmingw32 -luser32
 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt /
usr/lib/gcc-lib/i686-pc-mingw32/3.3.3/crtend.o
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/adalib/libgnat.a(cio.o)(.text+0x7): undefi
ned reference to `___getreent'
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/adalib/libgnat.a(cio.o)(.text+0x67): undef
ined reference to `___getreent'
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/adalib/libgnat.a(cio.o)(.text+0x97): undef
ined reference to `___getreent'
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/adalib/libgnat.a(cio.o)(.text+0xc7): undef
ined reference to `___getreent'
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/adalib/libgnat.a(cstreams.o)(.text+0x97):
undefined reference to `___getreent'
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/adalib/libgnat.a(cstreams.o)(.text+0xb7):
more undefined references to `___getreent' follow
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/adalib/libgnat.a(sysdep.o)(.text+0xd4): un
defined reference to `_tcgetattr'
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/adalib/libgnat.a(sysdep.o)(.text+0xfe): un
defined reference to `_tcsetattr'
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/adalib/libgnat.a(sysdep.o)(.text+0x156): u
ndefined reference to `_tcsetattr'
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/adalib/libgnat.a(sysdep.o)(.text+0x25): un
defined reference to `_ttyname'
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/adalib/libgnat.a(sysdep.o)(.text+0x1e5): u
ndefined reference to `_localtime_r'
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/adalib/libgnat.a(adaint.o)(.text+0x7e7): u
ndefined reference to `_fork'
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/adalib/libgnat.a(adaint.o)(.text+0x81b): u
ndefined reference to `_waitpid'
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/adalib/libgnat.a(adaint.o)(.text+0x860): u
ndefined reference to `_fork'
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/adalib/libgnat.a(adaint.o)(.text+0x8c2): u
ndefined reference to `_waitpid'
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/adalib/libgnat.a(adaint.o)(.text+0x901): u
ndefined reference to `_waitpid'
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/adalib/libgnat.a(adaint.o)(.text+0xa5): un
defined reference to `_readlink'
/usr/lib/gcc-lib/i686-pc-

[Bug tree-optimization/13952] [tree-ssa] SRA does not work for structs containing arrays

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Last reconfirmed|2004-09-28 03:34:06 |2005-03-18 10:10:08
   date||


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

[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer

[aoliva at redhat dot com]

--- Additional Comments From aoliva at gcc dot gnu dot org  2005-03-18 
10:14 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable 
types

On Mar 18, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:

> On Mar 17, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote:
>>> +cp_gimplify_compound_literal_expr (tree *expr_p, tree *pre_p, tree *post_p)

>>> +  return gimplify_expr (expr_p, pre_p, post_p, is_gimple_val, 
>>> fb_rvalue);

>> You don't need to recurse here.  Just return GS_OK.

> Neat!

FWIW, removing the recursion enabled me to remove the post_p argument
as well, but I only realized that after posting the patch.  I'm not
reposting it right now for this trivial reason, but consider the
patch with this additional change.



-- 


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

[Bug other/20531] New: gcc should warn about undefined behaviour

[pluto at pld-linux dot org]

volatile struct {
int x, y;
} s;

int foo()
{
return (s.x > s.y);   // undefined behavior:
  // the order of volatile accesses
  // is undefined in this statment
}

-- 
   Summary: gcc should warn about undefined behaviour
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at pld-linux dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pld-linux
  GCC host triplet: i686-pld-linux
GCC target triplet: i686-pld-linux


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

[Bug ada/19519] GNAT Bug Box when reading a program with UTF-8 encoded enumeration literals

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-18 
11:51 ---
Subject: Bug 19519

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-18 11:50:32

Modified files:
gcc/ada: namet.adb 

Log message:
2005-03-17  Robert Dewar  <[EMAIL PROTECTED]>

PR ada/19519

* namet.adb (Copy_One_Character): Set proper wide character encoding
for upper half character if we have upper half encoding.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/namet.adb.diff?cvsroot=gcc&r1=1.10&r2=1.11



-- 


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

[Bug c++/20463] [4.0/4.1 regression] ICE on using undefined type

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-03-18 12:04 
---
Looking into it.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug middle-end/20524] [4.0/4.1 regression] cris-axis-elf testsuite failures: gcc.c-torture/compile/20011119-1.c and -2

[joseph at codesourcery dot com]

--- Additional Comments From joseph at codesourcery dot com  2005-03-18 
12:27 ---
Subject: Re:  [4.0/4.1 regression] cris-axis-elf
 testsuite failures: gcc.c-torture/compile/2009-1.c and -2

2009-2.c seems to be failing on all HP-UX targets and 
i686-pc-linux-gnu, mainline and 4.0 branch.

hppa2.0w-hpux fails to bootstrap on mainline as noted in 
.  On 4.0 branch 
it has new FAILs on 2009-1.c, 2009-2.c and 981001-2.c, "error: 
alias definitions not supported in this configuration".  If this is 
correct and the compiler was previously buggy not to reject the code then 
the tests need to be skipped on targets not supporting alias definitions.



-- 


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

[Bug ada/19519] GNAT Bug Box when reading a program with UTF-8 encoded enumeration literals

[charlet at gcc dot gnu dot org]

--- Additional Comments From charlet at gcc dot gnu dot org  2005-03-18 
12:39 ---
Fixed.

Arno

-- 
   What|Removed |Added

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


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

[Bug c/20531] gcc should warn about undefined behaviour

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-18 
13:44 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|other   |c
 Ever Confirmed||1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2005-03-18 13:44:52
   date||


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

[Bug c/20532] New: Bad code for DImode left shifts by 31 and then 1

[macro at linux-mips dot org]

gcc (GCC) 4.0.0 20050316 (prerelease) (from the gcc-4_0-branch branch) emits
bad code for DImode left shifts by 31 and then 1 (foo << 31 <<1).  Instead of
doing the shifts, both the lowpart (correctly) and the highpart (incorrectly)
word get zeroed.  If the shifts are replaced by ones by 30 and then 2 or by one
by 32, then the resulting code is correct.

 GCC has been built with the following configure and make options:

$ CC=i386-linux-gcc \
CXX=i386-linux-g++ \
F77=i386-linux-gfortran \
CFLAGS="-pipe -O2 -fomit-frame-pointer -mtune=i486" \
CXXFLAGS="-pipe -O2 -fomit-frame-pointer -mtune=i486" \
FCFLAGS="-pipe -O2 -fomit-frame-pointer -mtune=i486" \
CC_FOR_BUILD=i386-linux-gcc \
CFLAGS_FOR_BUILD="-pipe -O2 -fomit-frame-pointer -mtune=i486" \
CFLAGS_FOR_TARGET="-pipe -O2 -fomit-frame-pointer -mtune=i486" \
CXXFLAGS_FOR_TARGET="-pipe -O2 -fomit-frame-pointer -mtune=i486" \
FCFLAGS_FOR_TARGET="-pipe -O2 -fomit-frame-pointer -mtune=i486" \
INSTALL_PROGRAM='${INSTALL} -s' \
../configure --prefix=/usr --mandir='${datadir}/man' \
--with-local-prefix='${prefix}/local' \
--enable-shared \
--with-slibdir=/lib \
--enable-static \
--with-system-zlib \
--enable-threads \
--cache-file=config.cache \
--build=i386-linux --host=i386-linux --target=i386-linux
$ make 'BOOT_CFLAGS=-pipe -O2 -fomit-frame-pointer -mtune=i486' \
'STAGE1_CFLAGS=-pipe -O2 -fomit-frame-pointer -mtune=i486' \
'GCJFLAGS=-pipe -O2 -fomit-frame-pointer -mtune=i486' \
CXX_FOR_BUILD=i386-linux-g++ \
'CXXFLAGS_FOR_BUILD=-pipe -O2 -fomit-frame-pointer -mtune=i486' bootstrap

 Here is a simple test case that fails for me (the source C file only as you
seem not to want to receive *.s files):

unsigned long long int badshift(unsigned long long int v)
{
return v << 31 << 1;
}

 The problem was originally discovered with a 4.0.0 snapshot from the trunk
dated 20050225, therefore it likely applies to 4.1.0, too.

-- 
   Summary: Bad code for DImode left shifts by 31 and then 1
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P1
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: macro at linux-mips dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-pc-linux-gnu
  GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu


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

[Bug c++/20463] [4.0/4.1 regression] ICE on using undefined type

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-18 
13:48 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug c/20532] Bad code for DImode left shifts by 31 and then 1

[macro at linux-mips dot org]

--- Additional Comments From macro at linux-mips dot org  2005-03-18 13:50 
---
You need to pass at least -O1 when building this program to trigger the bug.

-- 


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

[Bug rtl-optimization/20532] [4.0/4.1 Regression] Bad code for DImode left shifts by 31 and then 1

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-18 
13:55 ---
Confirmed with the following options on i686-pc-linux-gnu:
-O1  -march=i386

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c   |rtl-optimization
 Ever Confirmed||1
   Keywords||wrong-code
  Known to fail||4.0.0
  Known to work||3.4.0
   Last reconfirmed|-00-00 00:00:00 |2005-03-18 13:55:22
   date||
Summary|Bad code for DImode left|[4.0/4.1 Regression] Bad
   |shifts by 31 and then 1 |code for DImode left shifts
   ||by 31 and then 1
   Target Milestone|--- |4.0.0


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

[Bug java/20522] ICE in update_aliases, at java/decl.c:163

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-18 
13:57 ---
Subject: Bug 20522

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-03-18 13:57:15

Modified files:
gcc/java   : decl.c ChangeLog 

Log message:
2005-03-18  Andrew Haley  <[EMAIL PROTECTED]>

PR java/20522
* decl.c (update_aliases): Don't update variables that are about
to die.
(maybe_poplevels): Add comment.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.209&r2=1.209.4.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1556.2.6&r2=1.1556.2.7



-- 


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

[Bug java/20522] ICE in update_aliases, at java/decl.c:163

[aph at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug java/20522] ICE in update_aliases, at java/decl.c:163

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-18 
13:59 ---
Subject: Bug 20522

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-18 13:59:11

Modified files:
gcc/java   : decl.c ChangeLog 

Log message:
2005-03-18  Andrew Haley  <[EMAIL PROTECTED]>

PR java/20522
* decl.c (update_aliases): Don't update variables that are about
to die.
(maybe_poplevels): Add comment.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/decl.c.diff?cvsroot=gcc&r1=1.212&r2=1.213
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1575&r2=1.1576



-- 
   What|Removed |Added

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


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

[Bug rtl-optimization/20532] [4.0/4.1 Regression] Bad code for DImode left shifts by 31 and then 1

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-18 
14:03 ---
This was introduced between 20040630 and 20040702.

-- 


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

[Bug middle-end/20225] [4.0/4.1 regression] ICE during GC

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-18 
14:57 ---
Subject: Bug 20225

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-18 14:57:15

Modified files:
gcc: ChangeLog cgraph.c varasm.c 

Log message:
PR middle-end/20225
* cgraph.c (cgraph_mark_reachable_node): Assert that it is not called
too late.
* varasm.c (find_decl_and_mark_needed): Mark needed only when not
called too late.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7898&r2=2.7899
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cgraph.c.diff?cvsroot=gcc&r1=1.66&r2=1.67
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&r1=1.482&r2=1.483



-- 


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

[Bug c++/9782] constructor not called on higher-dimensional arrays of template types

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2005-03-18 
15:08 ---
Now the code is rejected by GCC in 4.0 branch and mainline.

-- 
   What|Removed |Added

   Keywords||rejects-valid


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

[Bug tree-optimization/19108] [4.0/4.1 regression] ICE initializing arrays

[sayler at thewalrus dot org]

--- Additional Comments From sayler at thewalrus dot org  2005-03-18 15:49 
---
working to replicate this in current CVS.

-- 
   What|Removed |Added

 CC||sayler at thewalrus dot org


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

[Bug c/20533] New: documentation: attribute 'used', applied to a variable

[gary at intrepid dot com]

See related discussion in Bug #20319, and at
http://gcc.gnu.org/ml/gcc/2005-03/msg00450.html

The "used" attribute is described only under "function attributes"
and not under "variable attributes" in the documentation:

used
This attribute, attached to a function, means that code must be emitted for 
the function even if it appears that the function is not referenced. This is 
useful, for example, when the function is referenced only in inline assembly. 

(see: http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Function-
Attributes.html#Function-Attributes)

It would be helpful if the documentation were updated to describe the
behavior of the `used' attribute when apllied to variables.

-- 
   Summary: documentation: attribute 'used', applied to a variable
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gary at intrepid dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libstdc++/20534] New: Erroneous #include of

[sacolcor at provide dot net]

gcc/libstdc++-v3/include/debug/debug.h:272 reads:

#include  // TBD: temporary

Is this "temporary" include still needed?  It causes most uses of STL to pull in
the assert header, which means that programs can (and have) failed to compile on
versions of the compiler without this bug.

-- 
   Summary: Erroneous #include of 
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sacolcor at provide dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/20319] -fkeep-static-consts with -O asserted doesn't keep consts

[gary at intrepid dot com]

--- Additional Comments From gary at intrepid dot com  2005-03-18 16:16 
---
from http://gcc.gnu.org/ml/gcc/2005-03/msg00491.html

I think that the switch name
-fkeep-static-consts might be more consistenly named if it
was given the opposite sense and named something like
-fdelete-unused-static-consts.  The idea here is that by
asserting the switch a particular optimization is _enabled_.
Thus the optimizations performed at each level can be consistently
enumerated by asserting a particular set of switches which enable
specific optimizations.  This would change the present user interface,
however, I doubt that anyone is making extensive use of the current
interface because at present only -fno-keep-static-consts, asserted
at -O0 (no optimization), actually changes the default behavior of
the compiler.

-- 


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

[Bug c++/19772] [3.4/4.0/4.1 Regression] crash on invalid template friend decl

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2005-03-18 
16:39 ---
Got it.  Mainline ICE on corrected code.  4.0 ICE on both original and corrected
one.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |lerdsuwa at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Keywords||ice-on-valid-code
   Last reconfirmed|2005-02-03 03:36:13 |2005-03-18 16:39:32
   date||
Summary|crash on invalid template   |[3.4/4.0/4.1 Regression]
   |friend decl |crash on invalid template
   ||friend decl


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

[Bug c/20533] documentation: attribute 'used', applied to a variable

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||documentation


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

[Bug libstdc++/20534] Erroneous #include of

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-18 
16:54 ---
Hmm, I know that the only header which is allowed to included twice is 
cassert/assert.h and change the 
behavior.  Also I know standard headers are allowed to bring in other standard 
headers.


So I don't know if this is a bug in libstdc++ or your code.

Could you give an example of where this fails?

-- 


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

[Bug c++/20381] [4.0/4.1 Regression] ICE in build_ptrmemfunc, at cp/typeck.c:5702

[micis at gmx dot de]

--- Additional Comments From micis at gmx dot de  2005-03-18 17:04 ---
Please ignore the coment above.
I do get this error with gcc4.0.0 abd gcc4.1.0

Michael Cieslinski

-- 


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

[Bug c++/20463] [4.0/4.1 regression] ICE on using undefined type

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-18 
17:16 ---
Subject: Bug 20463

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-18 17:16:24

Modified files:
gcc/cp : ChangeLog parser.c 

Log message:
2005-03-18  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/20463
* parser.c (cp_parser_diagnose_invalid_type_name):
Check TYPE_BINFO (current_class_type) before attempting
to emit inform messages.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4665&r2=1.4666
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.321&r2=1.322



-- 


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

[Bug c++/20463] [4.0/4.1 regression] ICE on using undefined type

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-18 
17:19 ---
Subject: Bug 20463

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-18 17:19:42

Modified files:
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/template: crash35.C 

Log message:
2005-03-18  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/20463
* g++.dg/template/crash35.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5180&r2=1.5181
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/crash35.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug c/20535] New: add warning or error if storage size mismatch

[olh at suse dot de]

We see more and more code like this, in this case e2fsprogs blkid:

char c;
c=getopt(...)

getopt returns an int, and so does getc.
But gcc stores the thing in something that cant hold the return type.

It should warn with an obvious message, or even error out.

-- 
   Summary: add warning or error if storage size mismatch
   Product: gcc
   Version: 3.3.3
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olh at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-linux
  GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linux


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

[Bug c/20535] add warning or error if storage size mismatch

[olh at suse dot de]

--- Additional Comments From olh at suse dot de  2005-03-18 17:32 ---
just checked, gcc4 accepts it (blkid.c) as well.


-- 
   What|Removed |Added

Version|3.3.3   |4.1.0


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

[Bug middle-end/20225] [4.0/4.1 regression] ICE during GC

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-18 
18:15 ---
Subject: Bug 20225

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-03-18 18:15:09

Modified files:
gcc: ChangeLog cgraph.c varasm.c 

Log message:
PR middle-end/20225
* cgraph.c (cgraph_mark_reachable_node): Assert that it is not called
too late.
* varasm.c (find_decl_and_mark_needed): Mark needed only when not
called too late.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.61&r2=2.7592.2.62
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cgraph.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.64.8.1&r2=1.64.8.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.477.6.2&r2=1.477.6.3



-- 


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

[Bug ada/19382] ACATS cxb5002 simple To_Fortran test fails at runtime on s390-linux

[laurent at guerby dot net]

--- Additional Comments From laurent at guerby dot net  2005-03-18 18:46 
---
Still fails on 4.0.0 20050317 (prerelease) testsuite on s390-ibm-linux-gnu
according to:
http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01185.html

-- 


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

[Bug c++/20536] New: G++ segfault on tiny snipped of invalid code

[wwieser at gmx dot de]

Trying to compile the following invalid code with  
gcc (GCC) 4.1.0 20050312 (experimental) 
results in an ICE: segfault.  
 
Version 3.4.1 is not affectected.  
 
 
// Found by Wolfgang Wieser 03/2005.  
// Crash gcc (GCC) 4.1.0 20050312 (experimental).  
 
struct yyguts_t 
{ 
class TestScanner* yyextra_r; 
}; 

TestScanner::TestScanner() 
{ 
} 
--- 
 
segfault.cc:9: error: invalid use of undefined type 'struct TestScanner' 
segfault.cc:6: error: forward declaration of 'struct TestScanner' 
segfault.cc: In constructor 'TestScanner::TestScanner()': 
segfault.cc:9: internal compiler error: Segmentation fault 
Please submit a full bug report, 
with preprocessed source if appropriate. 
See http://gcc.gnu.org/bugs.html> for instructions.

-- 
   Summary: G++ segfault on tiny snipped of invalid code
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wwieser at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-linux-gnu
  GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu


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

[Bug c++/20536] G++ segfault on tiny snipped of invalid code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-18 
19:13 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/20461] [4.0/4.1 Regression] ICE at "class 'C' does not have any field named 'f'" error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-18 
19:13 ---
*** Bug 20536 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||wwieser at gmx dot de


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

[Bug c++/20537] New: GCC install libstdc++ headers in wrong dir

[wanderer at rsu dot ru]

Current GCC mainline (4.1.0 20050318) install libstdc++ headers at FreeBSD 5.3 
in
/include/c++/const/ dir instead /include/c++/4.1.0/
I think problem related to last GCC version generation changes.

I build and install without this problem GCC 4.1.0 20050313 

Vladimir

-- 
   Summary: GCC install libstdc++ headers in wrong dir
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wanderer at rsu dot ru
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-unknown-freebsd5.3
  GCC host triplet: i386-unknown-freebsd5.3
GCC target triplet: i386-unknown-freebsd5.3


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

[Bug fortran/20538] New: compiling -finline-functions -O2 and we crash at runtime

[pinskia at gcc dot gnu dot org]

From:


program nbody

  implicit none
  integer result, num, i, k
  character(len=8) argv
  real*8, parameter :: tstep = 0.01d0
  real*8, parameter ::  PI = 3.141592653589793d0
  real*8, parameter ::  SOLAR_MASS = 4 * PI * PI
  real*8, parameter ::  DAYS_PER_YEAR = 365.24d0
  real*8 :: e
  type body
 real*8 x, y, z, vx, vy, vz, mass
  end type body
  type(body), parameter :: jupiter = body( &
   4.84143144246472090d0,-1.16032004402742839d0, &
   -1.03622044471123109d-01, 1.66007664274403694d-03 * DAYS_PER_YEAR, &
   7.69901118419740425d-03 * DAYS_PER_YEAR, -6.90460016972063023d-05 * 
DAYS_PER_YEAR, 
&
   9.54791938424326609d-04 * SOLAR_MASS)

  type(body), parameter :: saturn = body( &
   8.34336671824457987d+00, &
   4.12479856412430479d+00, &
   -4.03523417114321381d-01, &
   -2.76742510726862411d-03 * DAYS_PER_YEAR, &
   4.99852801234917238d-03 * DAYS_PER_YEAR, &
   2.30417297573763929d-05 * DAYS_PER_YEAR, &
   2.85885980666130812d-04 * SOLAR_MASS)

  type(body), parameter :: uranus = body( &
   1.28943695621391310d+01, &
   -1.5514016986312d+01, &
   -2.23307578892655734d-01, &
   2.96460137564761618d-03 * DAYS_PER_YEAR, &
   2.37847173959480950d-03 * DAYS_PER_YEAR, &
   -2.96589568540237556d-05 * DAYS_PER_YEAR, &
   4.36624404335156298d-05 * SOLAR_MASS )

  type(body), parameter :: neptune = body( &
   1.53796971148509165d+01, &
   -2.59193146099879641d+01, &
   1.79258772950371181d-01, &
   2.68067772490389322d-03 * DAYS_PER_YEAR, &
   1.62824170038242295d-03 * DAYS_PER_YEAR, &
   -9.51592254519715870d-05 * DAYS_PER_YEAR, &
   5.15138902046611451d-05 * SOLAR_MASS)

  type(body), parameter :: sun = body(0.0d0, 0.0d0, 0.0d0, 0.0d0, 0.0d0, 0.0d0, 
SOLAR_MASS)

  type(body), dimension(5) :: bodies
  bodies = (/ sun, jupiter, saturn, uranus, neptune /)

  call getarg(1,argv)
  read(argv,*) num

  call offsetMomentum(1,bodies)
  e = energy(bodies)
  write(*,'(f12.9)') e
  do i=1,num
 call advance(tstep, bodies)
  end do
  e = energy(bodies)
  write(*,'(f12.9)') e

contains

  subroutine offsetMomentum(k, bodies)
integer, intent(in) :: k
type(body), dimension(:), intent(inout) :: bodies
real*8 :: px, py, pz
px = 0.0d0
py = 0.0d0
pz = 0.0d0
do i=1,size(bodies)
   px = px + bodies(i)%vx * bodies(i)%mass;
   py = py + bodies(i)%vy * bodies(i)%mass;
   pz = pz + bodies(i)%vz * bodies(i)%mass;
end do
bodies(k)%vx = -px/SOLAR_MASS
bodies(k)%vy = -py/SOLAR_MASS
bodies(k)%vz = -pz/SOLAR_MASS
  end subroutine offsetMomentum


  subroutine advance(tstep, bodies)
  real*8, intent(in) :: tstep
  type(body), dimension(:), intent(inout) :: bodies

  real*8 dx, dy, dz, distance, mag
  integer i, j

  do i=1,size(bodies)
 do j=i+1,size(bodies)
dx = bodies(i)%x - bodies(j)%x
dy = bodies(i)%y - bodies(j)%y
dz = bodies(i)%z - bodies(j)%z

distance = sqrt(dx*dx + dy*dy + dz*dz)
mag = tstep / (distance * distance * distance)

bodies(i)%vx = bodies(i)%vx - dx * bodies(j)%mass * mag
bodies(i)%vy =  bodies(i)%vy - dy * bodies(j)%mass * mag
bodies(i)%vz =  bodies(i)%vz - dz * bodies(j)%mass * mag

bodies(j)%vx = bodies(j)%vx + dx * bodies(i)%mass * mag
bodies(j)%vy = bodies(j)%vy + dy * bodies(i)%mass * mag
bodies(j)%vz = bodies(j)%vz + dz * bodies(i)%mass * mag
 end do
  end do

  do i=1,size(bodies)
 bodies(i)%x = bodies(i)%x + tstep * bodies(i)%vx
 bodies(i)%y = bodies(i)%y + tstep * bodies(i)%vy
 bodies(i)%z = bodies(i)%z + tstep * bodies(i)%vz
  end do

  end subroutine advance

  real*8 function energy(bodies)
type(body), dimension(:), intent(in) :: bodies
real*8 dx, dy, dz, distance
integer i, j

energy = 0.0d0
do i=1,size(bodies)
   energy = energy + 0.5d0 * bodies(i)%mass *  &
( bodies(i)%vx * bodies(i)%vx + &
bodies(i)%vy * bodies(i)%vy + &
bodies(i)%vz * bodies(i)%vz)

   do j=i+1,size(bodies)
  dx = bodies(i)%x - bodies(j)%x
  dy = bodies(i)%y - bodies(j)%y
  dz = bodies(i)%z - bodies(j)%z
  distance = sqrt(dx*dx + dy*dy + dz*dz)
  energy = energy - (bodies(i)%mass * bodies(j)%mass) / distance;
   end do

end do
  end function energy

end program nbody



I don't know where the problem is which is why I am just filing it.

run with 60 as the agrument to the problem.  If someone will reduce this 
for me, it would be nice.

-- 
   Summary: compiling -finline-functions -O2 and we crash at runtime
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: una

[Bug bootstrap/20537] [4.1 Regression] GCC install libstdc++ headers in wrong dir

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-18 
19:30 ---
We know about this.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|c++ |bootstrap
 Ever Confirmed||1
   Keywords||build
   Last reconfirmed|-00-00 00:00:00 |2005-03-18 19:30:22
   date||
Summary|GCC install libstdc++   |[4.1 Regression] GCC install
   |headers in wrong dir|libstdc++ headers in wrong
   ||dir
   Target Milestone|--- |4.1.0


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

[Bug bootstrap/20537] [4.1 Regression] GCC install libstdc++ headers in wrong dir

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-18 
19:30 ---
See:  and follow ups.

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug rtl-optimization/20539] New: ICE in simplify_subreg, at simplify-rtx.c:3674

[John at xza5 dot com]

It's quite a small testcase.  I hacked it down to about 3700 lines...
More seriously, I haven't tried hacking about the (member) function
that's causing the problem - I've just removed a load of irrelevant
stuff from the file.

This is the failure I found:

[ALL]$ /usr/local/gcc/gcc-4.0-20050312/bin/g++  -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../sources/gcc-4.0-20050312/configure
--enable-languages=c,c++ --enable-__cxa_atexit --disable-checking --disable-nls
--prefix=/usr/local/gcc/gcc-4.0-20050312
Thread model: posix
gcc version 4.0.0 20050312 (prerelease)
[ALL]$ /usr/local/gcc/gcc-4.0-20050312/bin/g++  -S testcase1.ii
testcase1.ii: In member function 'void S::wave_1000130()':
testcase1.ii:3691: internal compiler error: Floating point exception
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


Try with a compiler built with checking enabled:

[ALL]$ /usr/local/gcc/gcc-4.0-20050312-ggdb3/bin/g++  -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../sources/gcc-4.0-20050312/configure
--enable-languages=c,c++ --enable-__cxa_atexit --disable-checking --disable-nls
--prefix=/usr/local/gcc/gcc-4.0-20050312 : (reconfigured)
../../sources/gcc-4.0-20050312/configure --enable-languages=c,c++
--enable-__cxa_atexit --disable-nls 
--prefix=/usr/local/gcc/gcc-4.0-20050312-ggdb3
Thread model: posix
gcc version 4.0.0 20050312 (prerelease)
[ALL]$ /usr/local/gcc/gcc-4.0-20050312-ggdb3/bin/g++  -S testcase1.ii
testcase1.ii: In member function 'void S::wave_1000130()':
testcase1.ii:3380: internal compiler error: in simplify_subreg, at
simplify-rtx.c:3674
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
[ALL]$

-- 
   Summary: ICE in simplify_subreg, at simplify-rtx.c:3674
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: John at xza5 dot com
CC: gcc-bugs at gcc dot gnu dot org,giovannibajo at libero
dot it
 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=20539

[Bug rtl-optimization/20539] ICE in simplify_subreg, at simplify-rtx.c:3674

[John at xza5 dot com]

--- Additional Comments From John at xza5 dot com  2005-03-18 20:09 ---
Created an attachment (id=8417)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8417&action=view)
bzip'ed, preprocessed, trimmed testcase


-- 


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

[Bug rtl-optimization/20539] ICE in simplify_subreg, at simplify-rtx.c:3674

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug target/20540] New: "-march=i386" doesn't mean "limit instruction set to what 80386 understands"

[zeev dot tarantov at gmail dot com]

gcc version 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110, ssp-3.4.3.20050110-0,
pie-8.7.7)

Basically, I get P6 instructions in the assembly output when compiling with
"-march=i386", but when I tried "-march=i486" id did the right thing (no P6
instructions).
I hope it is just a simple problem of misunderstanding "i386" to mean something
other than what the documentation (read: man page) says, rather than an actual
bug with the definition of what instructions 386 can and can't issue.
I don't think it's Gentoo's fault so I complain here.

-- 
   Summary: "-march=i386" doesn't mean "limit instruction set to
what 80386 understands"
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zeev dot tarantov at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug target/20540] "-march=i386" doesn't mean "limit instruction set to what 80386 understands"

[zeev dot tarantov at gmail dot com]

--- Additional Comments From zeev dot tarantov at gmail dot com  2005-03-18 
20:26 ---
Created an attachment (id=8418)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8418&action=view)
testcase source


-- 


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

[Bug target/20540] "-march=i386" doesn't mean "limit instruction set to what 80386 understands"

[zeev dot tarantov at gmail dot com]

--- Additional Comments From zeev dot tarantov at gmail dot com  2005-03-18 
20:27 ---
Created an attachment (id=8419)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8419&action=view)
testcase expected output

this is what I get from "gcc -march=i486 -O3 -S -g opcode.c -o opcode.i486.s"

-- 


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

[Bug target/20540] "-march=i386" doesn't mean "limit instruction set to what 80386 understands"

[zeev dot tarantov at gmail dot com]

--- Additional Comments From zeev dot tarantov at gmail dot com  2005-03-18 
20:36 ---
Created an attachment (id=8420)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8420&action=view)
testcase unexpected output

this is what I get from "gcc -march=i386 -O3 -S -g opcode.c -o opcode.i386.s".
Notice the "movzbl" on line 28. I don't have a 80386 to test it, but I doubt it
supports this.

-- 


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

[Bug fortran/20541] New: INTEGER type declaration: ALLOCATABLE, compilation error

[madbosun at gmail dot com]

This line is a allocatable integer type declaration in a standard module

"
gfortran -ffree-form -O3 -c dvr.f90
 In file dvr.f90:8

INTEGER(kind=4), ALLOCATABLE :: glmark(:)
   1
Error: Attribute at (1) is not allowed in a TYPE definition
make: *** [dvr.mod] Error 1
"

And so the compiler exits on the error

The partial source for the module.

MODULE DVR
  implicit none
!  PRIVATE
  PUBLIC :: buildgrid, writegrid, creategrid1, creategrid2, ecscreategrid1,
ecscreategrid2

  TYPE dvrgrid
INTEGER(kind=4) :: gln, nfe, cess, nnodes, nreal, ncomplex, gnn, fim, lim
INTEGER(kind=4), ALLOCATABLE :: glmark(:)
REAL(kind=8) :: phi
REAL(kind=8), pointer :: fenodes(:), gnodes(:), rnodes(:), wr(:)
COMPLEX(kind=8), pointer :: znodes(:), wz(:)
  END TYPE dvrgrid

!  INTERFACE buildgrid
!MODULE PROCEDURE creategrid1, creategrid2, ecscreategrid1, ecscreategrid2
  END INTERFACE

  INTERFACE D1node
MODULE PROCEDURE D1glnode, D1gennode
  END INTERFACE

CONTAINS



END MODULE DVR

-- 
   Summary: INTEGER type declaration: ALLOCATABLE, compilation error
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: madbosun at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: Intel Opteron


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

[Bug rtl-optimization/20539] ICE in simplify_subreg, at simplify-rtx.c:3674

[John at xza5 dot com]

--- Additional Comments From John at xza5 dot com  2005-03-18 20:46 ---
I should have added:
- This is a regression from gcc-3.4.3
- The compiler I was testing was the snapshot: gcc-4.0-20050312
- The last snapshot I tried, gcc-4.0-20050220 exhibited the same behaviour

-- 


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

[Bug target/20540] "-march=i386" doesn't mean "limit instruction set to what 80386 understands"

[zeev dot tarantov at gmail dot com]

--- Additional Comments From zeev dot tarantov at gmail dot com  2005-03-18 
20:47 ---
I forgot to say gcc was compiled with "-march=pentium3 -O3".
I tried it now on gcc 3.3.5 and got the same deal.

-- 
   What|Removed |Added

   GCC host triplet||i686-pc-linux-gnu


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

[Bug middle-end/20539] [4.0 Regression] ICE in simplify_subreg, at simplify-rtx.c:3674

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|rtl-optimization|middle-end
   Keywords||ice-on-valid-code
Summary|ICE in simplify_subreg, at  |[4.0 Regression] ICE in
   |simplify-rtx.c:3674 |simplify_subreg, at
   ||simplify-rtx.c:3674
   Target Milestone|--- |4.0.0


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

[Bug middle-end/20539] [4.0/4.1 Regression] ICE in simplify_subreg, at simplify-rtx.c:3674

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|[4.0 Regression] ICE in |[4.0/4.1 Regression] ICE in
   |simplify_subreg, at |simplify_subreg, at
   |simplify-rtx.c:3674 |simplify-rtx.c:3674


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

[Bug libstdc++/20534] Erroneous #include of

[sacolcor at provide dot net]

--- Additional Comments From sacolcor at provide dot net  2005-03-18 20:57 
---
I'm working on it, but it may take me a where to track it down to a minimal 
case.

You're correct in that this is legal behavior for a conforming compiler; the
actual "core" problem is that because gcc (and most other compilers) #includes
some standard headers in others, it's possible to write code that is invalid
(because it does not #include all of the necessary headers) but have it still
compile without a diagnostic.  Thus, it breaks when moved to a compiler with a
different internal library header configuration.

In this case, the change was the debug header rework performed between v3.3.2
and v3.4.0.

It was the obvious "temporary" label on that line that led me to believe that it
was erroneous; if it needs to stay there, it probably shouldn't be tagged that
way (or should indicate what its intended lifetime is).

-- 


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

[Bug middle-end/20539] [4.0/4.1 Regression] ICE in simplify_subreg, at simplify-rtx.c:3674

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-18 
21:08 ---
Reduced testcase:
char l7_en;
long long l6_data_Z_0th;
int t;
void f()
{
  if (((char )(l6_data_Z_0th>>1 & 1U)) & ((l6_data_Z_0th & 1U)
 | !(((char )(l6_data_Z_0th>>35 & 15U))==14U)))
t = 0ULL;
}

: Search converges between 2004-05-11-trunk (#454) and 2004-05-14-trunk (#455).

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-18 21:08:02
   date||


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

[Bug middle-end/20539] [4.0/4.1 Regression] ICE in simplify_subreg, at simplify-rtx.c:3674

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-18 
21:09 ---
(In reply to comment #3)
> : Search converges between 2004-05-11-trunk (#454) and 2004-05-14-trunk 
> (#455).
Hmm, this would mean it was introduced by the tree-ssa merge.
It works with the tree-ssa branch on 2004-01-26 though.

-- 


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

[Bug tree-optimization/20542] New: [4.1 Regression] Bootstrap failure at -Os

[rearnsha at gcc dot gnu dot org]

Bootstrapping with BOOT_CFLAGS="-Os -g" fails when the stage2 cc1 is used to
build  crtstuff.o.  The segmentation fault occurs in find_uses_to_rename_use but
the error really seems to be in its caller find_uses_to_rename_bb
(tree-ssa-loop-manip.c).  Looking at the tree dumps we have in t49.loopinit

:;
  stmt_35 = bsi_stmt (bsi);
  get_stmt_operands (stmt_35);
  var_38 = op_iter_init_tree (&iter, stmt_35, 13);
  goto  ();

:;
  var_45 = op_iter_next_tree (&iter);

:;
  D.17355_41 = iter.done;
  D.17353_42 = (int) D.17355_41;
  D.17347_44 = (unsigned char) D.17353_42;
  if (D.17347_44 == 0) goto ; else goto ;

but in t50.lim we have:

:;
  stmt_35 = bsi_stmt (bsi);
  get_stmt_operands (stmt_35);
  var_38 = op_iter_init_tree (&iter, stmt_35, 13);
  lsm_tmp.500_356 = iter.done;
  goto  ();

:;
  var_45 = op_iter_next_tree (&iter);

:;
  D.17355_41 = lsm_tmp.500_356;
  D.17353_42 = (int) D.17355_41;
  D.17347_44 = (unsigned char) D.17353_42;
  if (D.17347_44 == 0) goto ; else goto ;

:;
  iter.done = lsm_tmp.500_356;

note that the use of iter.done has been hoisted out of the loop even though the
call of op_iter_next_tree passes the address of iter.

-- 
   Summary: [4.1 Regression] Bootstrap failure at -Os
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i386-unknown-netbsdelf arm-unknown-netbsdelf
GCC target triplet: i386-unknown-netbsdelf arm-unknown-netbsdelf


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

[Bug tree-optimization/20543] New: [4.1 Regression] Bootstrap failure at -Os

[rearnsha at gcc dot gnu dot org]

Bootstrapping with BOOT_CFLAGS="-Os -g" fails when the stage2 cc1 is used to
build  crtstuff.o.  The segmentation fault occurs in find_uses_to_rename_use but
the error really seems to be in its caller find_uses_to_rename_bb
(tree-ssa-loop-manip.c).  Looking at the tree dumps we have in t49.loopinit

:;
  stmt_35 = bsi_stmt (bsi);
  get_stmt_operands (stmt_35);
  var_38 = op_iter_init_tree (&iter, stmt_35, 13);
  goto  ();

:;
  var_45 = op_iter_next_tree (&iter);

:;
  D.17355_41 = iter.done;
  D.17353_42 = (int) D.17355_41;
  D.17347_44 = (unsigned char) D.17353_42;
  if (D.17347_44 == 0) goto ; else goto ;

but in t50.lim we have:

:;
  stmt_35 = bsi_stmt (bsi);
  get_stmt_operands (stmt_35);
  var_38 = op_iter_init_tree (&iter, stmt_35, 13);
  lsm_tmp.500_356 = iter.done;
  goto  ();

:;
  var_45 = op_iter_next_tree (&iter);

:;
  D.17355_41 = lsm_tmp.500_356;
  D.17353_42 = (int) D.17355_41;
  D.17347_44 = (unsigned char) D.17353_42;
  if (D.17347_44 == 0) goto ; else goto ;

:;
  iter.done = lsm_tmp.500_356;

note that the use of iter.done has been hoisted out of the loop even though the
call of op_iter_next_tree passes the address of iter.

-- 
   Summary: [4.1 Regression] Bootstrap failure at -Os
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i386-unknown-netbsdelf arm-unknown-netbsdelf
GCC target triplet: i386-unknown-netbsdelf arm-unknown-netbsdelf


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

[Bug tree-optimization/20543] [4.1 Regression] Bootstrap failure at -Os

[rearnsha at gcc dot gnu dot org]

--- Additional Comments From rearnsha at gcc dot gnu dot org  2005-03-18 
21:24 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/20542] [4.1 Regression] Bootstrap failure at -Os

[rearnsha at gcc dot gnu dot org]

--- Additional Comments From rearnsha at gcc dot gnu dot org  2005-03-18 
21:24 ---
*** Bug 20543 has been marked as a duplicate of this bug. ***

-- 


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

[Bug target/20540] "-march=i386" doesn't mean "limit instruction set to what 80386 understands"

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-18 
21:25 ---
Why do you think movzbl is not an instruction on i386?

-- 


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

[Bug tree-optimization/20542] [4.1 Regression] Bootstrap failure at -Os

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||dberlin at gcc dot gnu dot
   ||org, pinskia at gcc dot gnu
   ||dot org
   Severity|normal  |critical
   Keywords||build
   Target Milestone|--- |4.1.0


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

[Bug tree-optimization/20542] [4.1 Regression] Bootstrap failure at -Os

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-03-18 
21:33 ---
Subject: Re:  New: [4.1 Regression] Bootstrap
failure at -Os

On Fri, 2005-03-18 at 21:21 +, rearnsha at gcc dot gnu dot org
wrote:
> Bootstrapping with BOOT_CFLAGS="-Os -g" fails when the stage2 cc1 is used to
> build  crtstuff.o.  The segmentation fault occurs in find_uses_to_rename_use 
> but
> the error really seems to be in its caller find_uses_to_rename_bb
> (tree-ssa-loop-manip.c).  Looking at the tree dumps we have in t49.loopinit
> 
> :;
>   stmt_35 = bsi_stmt (bsi);
>   get_stmt_operands (stmt_35);
>   var_38 = op_iter_init_tree (&iter, stmt_35, 13);
>   goto  ();
> 
> :;
>   var_45 = op_iter_next_tree (&iter);
> 
> :;
>   D.17355_41 = iter.done;
>   D.17353_42 = (int) D.17355_41;
>   D.17347_44 = (unsigned char) D.17353_42;
>   if (D.17347_44 == 0) goto ; else goto ;
> 
> but in t50.lim we have:
> 
> :;
>   stmt_35 = bsi_stmt (bsi);
>   get_stmt_operands (stmt_35);
>   var_38 = op_iter_init_tree (&iter, stmt_35, 13);
>   lsm_tmp.500_356 = iter.done;
>   goto  ();
> 
> :;
>   var_45 = op_iter_next_tree (&iter);
> 
> :;
>   D.17355_41 = lsm_tmp.500_356;
>   D.17353_42 = (int) D.17355_41;
>   D.17347_44 = (unsigned char) D.17353_42;
>   if (D.17347_44 == 0) goto ; else goto ;
> 
> :;
>   iter.done = lsm_tmp.500_356;
> 
> note that the use of iter.done has been hoisted out of the loop even though 
> the
> call of op_iter_next_tree passes the address of iter.

This is probably because is_call_clobbered_ref is wrong for variables
that have subvars (it checks the base var instead of the SFT's).




-- 


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

[Bug tree-optimization/20544] New: missed tree-fold opportunity (shift of shifted value).

[rearnsha at gcc dot gnu dot org]

This code should really be simplified to a single shift before the end of the
tree optimization passes.  Once we've expanded to RTL this is likely to be too
complex to simplify on a 32-bit machine.

unsigned long long int shifttwice(unsigned long long int v)
{
return v << 31 << 1;
}

-- 
   Summary: missed tree-fold opportunity (shift of shifted value).
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: minor
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug target/20540] "-march=i386" doesn't mean "limit instruction set to what 80386 understands"

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-18 
21:42 ---
(In reply to comment #5)
> Why do you think movzbl is not an instruction on i386?

Just one more nore, movzbl is the same as movzx.  This is where AT&T vs Intel 
asm format is different.

So this is not a bug.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/20544] missed tree-fold opportunity (shift of shifted value).

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-18 
21:44 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/14796] [tree-ssa] combine two shifts into one

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-18 
21:44 ---
*** Bug 20544 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||rearnsha at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/20542] [4.1 Regression] Bootstrap failure at -Os

[dberlin at gcc dot gnu dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-03-18 
21:45 ---
I'm testing a patch now

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dberlin at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-18 21:45:00
   date||


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

[Bug middle-end/20545] New: unnecessary operations in tailcall

[Thomas dot Koenig at online dot de]

$ cat output-block.c
int flush_output(void)
{
return add_block();
}

$ gcc -O3 -S output-block.c
$ cat output-block.s
.file   "output-block.c"
.text
.p2align 4,,15
.globl flush_output
.type   flush_output, @function
flush_output:
pushl   %ebp
movl%esp, %ebp
popl%ebp
jmp add_block
.size   flush_output, .-flush_output
.ident  "GCC: (GNU) 4.1.0 20050315 (experimental)"
.section.note.GNU-stack,"",@progbits

The operations on ebp aren't necessary.

-- 
   Summary: unnecessary operations in tailcall
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/20545] unnecessary operations in tailcall

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-18 
22:06 ---
-fomit-frame-pointer "fixes" the problem, well this option really should be 
enabled by default and that 
is PR 13822 which I am marking this bug as a dup of.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/13822] enable -fomit-frame-pointer or at least -momit-frame-pointer by default on x86/dwarf2 platforms

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-18 
22:06 ---
*** Bug 20545 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||Thomas dot Koenig at online
   ||dot de


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

[Bug fortran/20541] INTEGER type declaration: ALLOCATABLE, compilation error

[kargl at gcc dot gnu dot org]

--- Additional Comments From kargl at gcc dot gnu dot org  2005-03-18 22:08 
---
Your code is illegal with respect to the Fortran 95 standard.  See section
4.4.1, page 38, of the (draft) standard, you'll find the following 

R426  component-attr-spec   is POINTER
or DIMENSION ( component-array-spec )

Note ALLOACTABLE is not listed above.

If you have Metcalf & Reid, Fortran 90/95 Explained, 2nd ed., you'll find on
page 107:

   If a variable-sized array component of a structure is required,
   unfortunately, an array pointer must be used (see Section 6.14).
   The prohibition on allocatable arrays here was made to keep the
   the feature simple, but this is now recognized as a mistake that
   will be corrected in Fortran 2000
  

-- 
   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug c++/20461] [4.0/4.1 Regression] ICE at "class 'C' does not have any field named 'f'" error

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-03-18 22:16 
---
Notice that the ICE happen only with checking enabled, but seems easy to fix
and we can avoid "confused by earlier errors, bailing out" otherwise.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug fortran/20538] compiling -finline-functions -O2 and we crash at runtime

[kargl at gcc dot gnu dot org]

--- Additional Comments From kargl at gcc dot gnu dot org  2005-03-18 22:24 
---
It appears to be an optimization bug.  It compiles and runs with
"-O" and "-O -finline-functions".  It seg faults with "-O2".  The
-finline-functions appears to be unrelated to the seg fault.

-- 


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

[Bug fortran/20538] compiling -finline-functions -O2 and we crash at runtime

[kargl at gcc dot gnu dot org]

--- Additional Comments From kargl at gcc dot gnu dot org  2005-03-18 22:36 
---
I added a "print *, size(bodies)" in the advance routine.  We have

troutmask:kargl[295] gfc -o jk -O2 jk.f90
troutmask:kargl[296] ./jk 1
-0.169075164
-595
-0.169075164
troutmask:kargl[297] gfc -o jk -O jk.f90
troutmask:kargl[298] ./jk 1
-0.169075164
   5
-0.169074954

Note, the correct answer is 5, so it looks like -O2 is screwing up the 
size() function.


-- 


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

[Bug ada/19526] Windows errorcodes wrong in Ada when tasking

[b201 at passagen dot se]

--- Additional Comments From b201 at passagen dot se  2005-03-18 22:45 
---
How come not many people see this as a bug? 
When a program behaves differently, just because 
a totally non-related task was introduced, I  
consider it a bug. I think Danny is on the right track. 
 
As for the remark of using internal gnat-units, I do state 
that I get the same result if I import WSAGetLastError myself, 
in the same way gnat.sockets.this does, and that way is  
the only way to go. 
function Last_Error return Interfaces.c.int (or long) 
pragma Import(stdcall,Last_Error,WSAGetLastError)  
 
/Björn 

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug tree-optimization/19108] [4.0/4.1 regression] ICE initializing arrays

[sayler at thewalrus dot org]

--- Additional Comments From sayler at thewalrus dot org  2005-03-18 23:00 
---
Bug still present.  The patch in #2 seems to fix the issue, though.

I can't say that the hash function chosen is the most efficient, but it's surely
better than an ICE.

-- 


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

[Bug fortran/20538] compiling -finline-functions -O2 and we crash at runtime

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-03-19 00:54 
---
Slightly reduced testcase, segfaults at -O2, runs with lower optimization. 
Removing any single statement leads to either illegal floating pointn numbers or
makes the segfault disappear:

  character(len=8) argv
  real*8, parameter :: tstep = 0.01d0
  real*8 :: e
  type body
 real*8 x, y,z,vx,vy,vz, mass
  end type body
  type(body), parameter :: jupiter = body(1d0, 1d0, 1d0, 1d0, 1d0, 1d0, 1d0 )
  type(body), parameter :: sun = body(0.0d0, 0.0d0, 0.0d0, 0.0d0, 0.0d0, 
0.0d0,1d0)

  type(body), dimension(2) :: bodies
  bodies = (/ sun, jupiter/)
  argv = "1"
  read (argv,*) num

  call offsetMomentum(1,bodies)
  do i=1,num
 call advance(tstep, bodies)
  end do
  e = 0.
  print *, e

contains

  subroutine offsetMomentum(k, bodies)
integer, intent(in) :: k
type(body), dimension(:), intent(inout) :: bodies
real*8 :: px, py, pz
do i=1,size(bodies)
   px =  bodies(i)%vx * bodies(i)%mass;
end do
bodies(k)%vx = -px
  end subroutine offsetMomentum


  subroutine advance(tstep, bodies)
  real*8, intent(in) :: tstep
  type(body), dimension(:), intent(inout) :: bodies

  real*8 dx, dy, dz, distance, mag
  integer i, j

  i = 1; j = 2; mag = 1.
dx = bodies(i)%x - bodies(j)%x
bodies(i)%vx = bodies(i)%vx - dx * bodies(j)%mass * mag

bodies(j)%vx = bodies(j)%vx + dx * bodies(i)%mass * mag
bodies(j)%vy = bodies(j)%vy + dy * bodies(i)%mass * mag
bodies(j)%vz = bodies(j)%vz + dz * bodies(i)%mass * mag

  do i=1,size(bodies)
 bodies(i)%x = bodies(i)%x + tstep * bodies(i)%vx
 bodies(i)%y = bodies(i)%y + tstep * bodies(i)%vy
 bodies(i)%z = bodies(i)%z + tstep * bodies(i)%vz
  end do

  end subroutine advance

  real*8 function energy(bodies)
type(body), dimension(:), intent(in) :: bodies
real*8 dx, dy, dz, distance
integer i, j

energy = 0.0d0
  end function energy

end

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-03-19 00:54:17
   date||


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

[Bug c/20546] New: Loading and storing of packed structure elements uses wrong endian for PPC EABI Little Endian

[aweiner at lsil dot com]

Using GCC 3.4 3.4.0 20040225 (prerelease) PPC EABI Little-Endian. For packed
structure element read/writes, compiler is loading/storing data as big-endian
instead of little-endian. Seen with all optimization levels, including off.
Phenomena not seen with unpacked structures.

Source:

typedef struct _FOO {
unsigned short a;
} __attribute((packed)) FOO;

FOO foo;

void test_case(void) {
foo.a = 0x2233;
}

Generated assembly:

packed_bug.o: file format elf32-powerpcle

Disassembly of section .text:

 :
   0:   e8 ff 21 94 stwur1,-24(r1)
   4:   14 00 e1 93 stw r31,20(r1)
   8:   78 0b 3f 7c mr  r31,r1
   c:   00 00 20 3d lis r9,0
  10:   00 00 29 39 addir9,r9,0
  14:   00 00 09 88 lbz r0,0(r9) ; superfluous read (optimizaions off)
  18:   00 00 00 70 andi.   r0,r0,0
  1c:   22 00 00 60 ori r0,r0,0x22
  20:   00 00 09 98 stb r0,0(r9) ; should be at 1(r9) not 0(r9)
  24:   01 00 09 88 lbz r0,1(r9) ; superfluous read (optimizations off)
  28:   00 00 00 70 andi.   r0,r0,0
  2c:   33 00 00 60 ori r0,r0,0x33
  30:   01 00 09 98 stb r0,1(r9) ; should be at 0(r9) not 1(r9)
  34:   00 00 61 81 lwz r11,0(r1)
  38:   fc ff eb 83 lwz r31,-4(r11)
  3c:   78 5b 61 7d mr  r1,r11
  40:   20 00 80 4e blr

Offset 20: storing the upper 8-bits (0x22) into byte #0 instead of byte #1
Offset 30: storing the lower 8-bits (0x33) into byte #1 instead of byte #0

Result:

Memory location contains 0x3322 instead of 0x2233.

Here is a disassembly of the same function but with the packed attribute 
removed:

packed_bug.o: file format elf32-powerpcle

Disassembly of section .text:

 :
   0:   e8 ff 21 94 stwur1,-24(r1)
   4:   14 00 e1 93 stw r31,20(r1)
   8:   78 0b 3f 7c mr  r31,r1
   c:   00 00 20 3d lis r9,0
  10:   33 22 00 38 li  r0,0x2233 ; correct little-endian value
  14:   00 00 09 b0 sth r0,0(r9)  ; correct, stored as little-endian
  18:   00 00 61 81 lwz r11,0(r1)
  1c:   fc ff eb 83 lwz r31,-4(r11)
  20:   78 5b 61 7d mr  r1,r11
  24:   20 00 80 4e blr

---

Compiler output (-v -save-temps):

c:\test>powerpcle-440-eabi-gcc -v -save-temps @options.cl packed_bug.c > t.txt
Reading specs from /cygdrive/c/gcc_3.4_ppc_440/bin/../lib/gcc/powerpcle-440-eabi
/3.4.0/specs
Configured with:  : (reconfigured)
Thread model: single
gcc version 3.4.0 20040225 (prerelease)
 /cygdrive/c/gcc_3.4_ppc_440/bin/../libexec/gcc/powerpcle-440-eabi/3.4.0/cc1.exe
 -E -quiet -v -I../../inc -I../.. -iprefix /cygdri
ve/c/gcc_3.4_ppc_440/bin/../lib/gcc/powerpcle-440-eabi/3.4.0/ -DVE
NDOR_GEN packed_bug.c -mstrict-align -m
cpu=440 -mno-sched-prolog -W -Wall -Wno-parentheses -Wno-unused -Wno-uninitializ
ed -Wno-format -finline-limit=200 -fworking-directory -o packed_bug.i
ignoring nonexistent directory "/cygdrive/c/gcc_3.4_ppc_440/bin/../lib/gcc/power
pcle-440-eabi/3.4.0/../../../../powerpcle-440-eabi/sys-include"
ignoring nonexistent directory "/cygdrive/e/gcc_3.4_ppc_440/lib/gcc/powerpcle-44
0-eabi/3.4.0/include"
ignoring nonexistent directory "/cygdrive/e/gcc_3.4_ppc_440/powerpcle-440-eabi/s
ys-include"
ignoring nonexistent directory "/cygdrive/e/gcc_3.4_ppc_440/powerpcle-440-eabi/i
nclude"
#include "..." search starts here:
#include <...> search starts here:
 ../../inc
 ../..
 /cygdrive/c/gcc_3.4_ppc_440/bin/../lib/gcc/powerpcle-440-eabi/3.4.0/include
 /cygdrive/c/gcc_3.4_ppc_440/bin/../lib/gcc/powerpcle-440-eabi/3.4.0/../../../..
/powerpcle-440-eabi/include
End of search list.
 /cygdrive/c/gcc_3.4_ppc_440/bin/../libexec/gcc/powerpcle-440-eabi/3.4.0/cc1.exe
 -fpreprocessed packed_bug.i -mstrict-align -quiet -dumpbase packed_bug.c -mcpu=
440 -mno-sched-prolog -auxbase packed_bug -g -W -Wall -Wno-parentheses -Wno-unus
ed -Wno-uninitialized -Wno-format -version -finline-limit=200 -o packed_bug.s
GNU C version 3.4.0 20040225 (prerelease) (powerpcle-440-eabi)
compiled by GNU C version 3.3.1 (cygming special).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=65463
 /cygdrive/c/gcc_3.4_ppc_440/bin/../lib/gcc/powerpcle-440-eabi/3.4.0/../../../..
/powerpcle-440-eabi/bin/as.exe -m440 -V -Qy -mregnames -m440 -o packed_bug.o pac
ked_bug.s
GNU assembler version 2.14 (powerpcle-440-eabi) using BFD version 2.14 20030612
 /cygdrive/c/gcc_3.4_ppc_440/bin/../libexec/gcc/powerpcle-440-eabi/3.4.0/collect
2.exe -V -Qy -dn -Bstatic -L/cygdrive/c/gcc_3.4_ppc_440/bin/../lib/gcc/powerpcle
-440-eabi/3.4.0 -L/cygdrive/c/gcc_3.4_ppc_440/bin/../lib/gcc -L/cygdrive/c/gcc_3
.4_ppc_440/bin/../lib/gcc/powerpcle-440-eabi/3.4.0/../../../../powerpcle-440-eab
i/lib packed_bug.o -lgcc -lgcc /cygdrive/c/gcc_3.4_ppc_440/bin/../lib/gcc/powerp
cle-440-eabi/3.4.0/crtsavres.o
/cygdrive/c/gcc_3.4_ppc_440/bin/../lib/gcc/powerpcle-440-eabi/3.4.0/../../../../
powerpcle-440-eabi/bin/ld: warning: cannot find entry symbol _

[Bug middle-end/20539] [4.0/4.1 Regression] ICE in simplify_subreg, at simplify-rtx.c:3674

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-03-19 
01:25 ---
some more subreg fun, weee!

-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org


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

[Bug target/20546] Loading and storing of packed structure elements uses wrong endian for PPC EABI Little Endian

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|critical|normal
  Component|c   |target


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

[Bug target/20546] Loading and storing of packed structure elements uses wrong endian for PPC EABI Little Endian

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-19 
01:26 ---
PPC LE is not really supported any more.

-- 


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

[Bug target/20529] m6811-elf-g++ ICE

[giovannibajo at libero dot it]

-- 
   What|Removed |Added

 CC||ciceron at gcc dot gnu dot
   ||org


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

[Bug fortran/20538] compiling -finline-functions -O2 and we crash at runtime

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-03-19 01:35 
---
Further reduction: segfaults at -O2, runs at -O0.
  real vx(1)
  num=2
  do i=1,num
 call advance(vx)
  end do
contains
  subroutine advance(bodies)
real, dimension(:)::bodies
bodies = 1.0
  end subroutine advance
end

-- 


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

[Bug fortran/20538] compiling -finline-functions -O2 and we crash at runtime

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-19 
01:42 ---
This might be the same as PR 16898.

-- 
   What|Removed |Added

  BugsThisDependsOn||16898


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

[Bug fortran/20538] compiling -finline-functions -O2 and we crash at runtime

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-03-19 01:47 
---
The failure is dependent on the function being a nested function, the following
doesn't segfault at -O2:
  subroutine advance(bodies)
real, dimension(:)::bodies
bodies = 1.0
  end subroutine advance
interface
  subroutine advance(bodies)
real, dimension(:)::bodies
  end subroutine advance
end interface
  real vx(1)
  num=2
  do i=1,num
 call advance(vx)
  end do
end


-- 


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

[Bug fortran/20538] compiling -finline-functions -O2 and we crash at runtime

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-03-19 01:57 
---
This modified testcase which removes the nested function, fails at -O2 by giving
 as output, but works at -O0. I'm not sure if this is a different
manifestation of the same bug, so I'm putting this here as something to look at
once this PR is fixed.

module m
  type body
 real*8 x, y, z, vx, vy, vz, mass
  end type body
contains
  subroutine offsetMomentum(k, bodies)
integer, intent(in) :: k
type(body), dimension(:), intent(inout) :: bodies
real*8 :: px, py, pz
px = 0.0d0
py = 0.0d0
pz = 0.0d0
do i=1,size(bodies)
   px = px + bodies(i)%vx * bodies(i)%mass;
   py = py + bodies(i)%vy * bodies(i)%mass;
   pz = pz + bodies(i)%vz * bodies(i)%mass;
end do
bodies(k)%vx = -px/SOLAR_MASS
bodies(k)%vy = -py/SOLAR_MASS
bodies(k)%vz = -pz/SOLAR_MASS
  end subroutine offsetMomentum


  subroutine advance(tstep, bodies)
  real*8, intent(in) :: tstep
  type(body), dimension(:), intent(inout) :: bodies

  real*8 dx, dy, dz, distance, mag
  integer i, j

  do i=1,size(bodies)
 do j=i+1,size(bodies)
dx = bodies(i)%x - bodies(j)%x
dy = bodies(i)%y - bodies(j)%y
dz = bodies(i)%z - bodies(j)%z

distance = sqrt(dx*dx + dy*dy + dz*dz)
mag = tstep / (distance * distance * distance)

bodies(i)%vx = bodies(i)%vx - dx * bodies(j)%mass * mag
bodies(i)%vy =  bodies(i)%vy - dy * bodies(j)%mass * mag
bodies(i)%vz =  bodies(i)%vz - dz * bodies(j)%mass * mag

bodies(j)%vx = bodies(j)%vx + dx * bodies(i)%mass * mag
bodies(j)%vy = bodies(j)%vy + dy * bodies(i)%mass * mag
bodies(j)%vz = bodies(j)%vz + dz * bodies(i)%mass * mag
 end do
  end do

  do i=1,size(bodies)
 bodies(i)%x = bodies(i)%x + tstep * bodies(i)%vx
 bodies(i)%y = bodies(i)%y + tstep * bodies(i)%vy
 bodies(i)%z = bodies(i)%z + tstep * bodies(i)%vz
  end do

  end subroutine advance

  real*8 function energy(bodies)
type(body), dimension(:), intent(in) :: bodies
real*8 dx, dy, dz, distance
integer i, j

energy = 0.0d0
do i=1,size(bodies)
   energy = energy + 0.5d0 * bodies(i)%mass *  &
( bodies(i)%vx * bodies(i)%vx + &
bodies(i)%vy * bodies(i)%vy + &
bodies(i)%vz * bodies(i)%vz)

   do j=i+1,size(bodies)
  dx = bodies(i)%x - bodies(j)%x
  dy = bodies(i)%y - bodies(j)%y
  dz = bodies(i)%z - bodies(j)%z
  distance = sqrt(dx*dx + dy*dy + dz*dz)
  energy = energy - (bodies(i)%mass * bodies(j)%mass) / distance;
   end do

end do
  end function energy

  subroutine main
  implicit none

  integer result, num, i, k
  character(len=8) argv
  real*8, parameter :: tstep = 0.01d0
  real*8, parameter ::  PI = 3.141592653589793d0
  real*8, parameter ::  SOLAR_MASS = 4 * PI * PI
  real*8, parameter ::  DAYS_PER_YEAR = 365.24d0
  real*8 :: e
  type(body), parameter :: jupiter = body( &
   4.84143144246472090d0,-1.16032004402742839d0, &
   -1.03622044471123109d-01, 1.66007664274403694d-03 * DAYS_PER_YEAR, &
   7.69901118419740425d-03 * DAYS_PER_YEAR, -6.90460016972063023d-05 *
DAYS_PER_YEAR, &
   9.54791938424326609d-04 * SOLAR_MASS)

  type(body), parameter :: saturn = body( &
   8.34336671824457987d+00, &
   4.12479856412430479d+00, &
   -4.03523417114321381d-01, &
   -2.76742510726862411d-03 * DAYS_PER_YEAR, &
   4.99852801234917238d-03 * DAYS_PER_YEAR, &
   2.30417297573763929d-05 * DAYS_PER_YEAR, &
   2.85885980666130812d-04 * SOLAR_MASS)

  type(body), parameter :: uranus = body( &
   1.28943695621391310d+01, &
   -1.5514016986312d+01, &
   -2.23307578892655734d-01, &
   2.96460137564761618d-03 * DAYS_PER_YEAR, &
   2.37847173959480950d-03 * DAYS_PER_YEAR, &
   -2.96589568540237556d-05 * DAYS_PER_YEAR, &
   4.36624404335156298d-05 * SOLAR_MASS )

  type(body), parameter :: neptune = body( &
   1.53796971148509165d+01, &
   -2.59193146099879641d+01, &
   1.79258772950371181d-01, &
   2.68067772490389322d-03 * DAYS_PER_YEAR, &
   1.62824170038242295d-03 * DAYS_PER_YEAR, &
   -9.51592254519715870d-05 * DAYS_PER_YEAR, &
   5.15138902046611451d-05 * SOLAR_MASS)

  type(body), parameter :: sun = body(0.0d0, 0.0d0, 0.0d0, 0.0d0, 0.0d0, 0.0d0,
SOLAR_MASS)

  type(body), dimension(5) :: bodies
  bodies = (/ sun, jupiter, saturn, uranus, neptune /)

  argv = "6000"
  read(argv,*) num

  call offsetMomentum(1,bodies)
  e = energy(bodies)
  write(*,'(f12.9)') e
  do i=1,num
 call advance(tstep, bodies)
  end do
  e = energy(bodies)
  write(*,'(f12.9)') e
end subroutine main
end module m

use m
call main
end


-- 


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

[Bug fortran/20538] compiling -finline-functions -O2 and we crash at runtime

[pbrook at gcc dot gnu dot org]

--- Additional Comments From pbrook at gcc dot gnu dot org  2005-03-19 
01:58 ---
Due to general gfortran lameness only contained functions are ever inlined.  
Top-level functions are never inlined.  

-- 


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

[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-19 
03:07 ---
Subject: Bug 19769

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-03-19 03:06:52

Modified files:
gcc: ChangeLog dwarf2out.c 

Log message:
Fix problem that caused compiled java code to trigger an internal gdb 
error.
PR c++/19769
* dwarf2out.c (declare_in_namespace): Ignore decls with an abstract
origin.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7907&r2=2.7908
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2out.c.diff?cvsroot=gcc&r1=1.571&r2=1.572



-- 


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

[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-03-19 
03:50 ---
Subject: Re:  [4.0/4.1 Regression] GCC produces wrong dwarf2
output that breaks gdb

On Sat, 2005-03-19 at 03:07 +, cvs-commit at gcc dot gnu dot org
wrote:
> --- Additional Comments From cvs-commit at gcc dot gnu dot org  
> 2005-03-19 03:07 ---
> Subject: Bug 19769
> 
> CVSROOT:  /cvs/gcc
> Module name:  gcc
> Changes by:   [EMAIL PROTECTED]   2005-03-19 03:06:52
> 


Just FYI (Maybe you are and the log message hasn't been processed by
bugzilla yet), this needs to go on the 4.0 branch as well, since the bug
exists there too.

Thanks so much for fixing this bug.




-- 


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

[Bug c++/19769] [4.0 Regression] GCC produces wrong dwarf2 output that breaks gdb

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-19 
05:27 ---
Fixed at least on the mainline (for 4.1).

-- 
   What|Removed |Added

Summary|[4.0/4.1 Regression] GCC|[4.0 Regression] GCC
   |produces wrong dwarf2 output|produces wrong dwarf2 output
   |that breaks gdb |that breaks gdb


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

[Bug c++/20547] New: undefined reference to "static const" fields of classes

[Hu dot YuehWei at gmail dot com]

The sample codes¡G
==
#include 
#include 

struct T
{
  static char const a = 3;
};

std::vector ddd;

int
main()
{
  ddd.push_back(T::a); /* this line of codes trigger the errors */

  std::cerr << ddd.front() << std::endl;

  return 0;
}


gcc-3.0.x 3.2.x 3.3.x 3.4.x compile the above program will produce errors like 
this:
===
/tmp/ccPOPHZ6.o(.text+0x124): In function `main':
: undefined reference to `T::a'
collect2: ld returned 1 exit status
===

However, if I use gcc-2.95, then there will be no errors.

If I modify the codes from:

...
ddd.push_back(T::a);
...

to

...
ddd.push_back(static_cast(T::a));
...

then gcc-3.0.x 3.2.x 3.3.x 3.4.x will be fine.

Is this a bug in gcc 3.x?

-- 
   Summary: undefined reference to "static const" fields of classes
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Hu dot YuehWei at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org


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