[Bug libfortran/20156] gfortran - bus error on backspace

[kargl at gcc dot gnu dot org]

--- Additional Comments From kargl at gcc dot gnu dot org  2005-02-26 06:28 
---
Dale,

I believe Bud Davis or Thomas Koening are the logical people
to look at your patch.  If either one doesn't pursue your patch
within the next week drop me an email.

One thing to keep in mind.  The patch here is fairly minimal
so it probably doesn't need copyright assignment paperwork on
file with FSF.  However, if you send additional patches
(which I strongly encourage :-) and if you don't have paperwork
on file with the FSF, please consider pursuing assignment.

-- 


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

[Bug libfortran/20156] gfortran - bus error on backspace

[dir at lanl dot gov]

--- Additional Comments From dir at lanl dot gov  2005-02-26 03:28 ---
I looked into the fortran source code and found a quick fix for the the
backspace bugs that were stopping my programs. In source file backspace.c. 

1). changed 

new = file_position (current_unit->s) - *p - length;
to 
new = file_position (current_unit->s) - *p - 2*length;

2). deleted
if (u->current_record)
   next_record (1);
 
3). added 
   if (u->mode==WRITING){
  flush(u->s);
  struncate (u->s);
  u->mode = READING;
   }
   
4). added 
 u->endfile = NO_ENDFILE;
 u->current_record = 0;

These changes fix  bugs 20125 and 20156 and a few others that I had not yet
reported. I have run 48 test problems with 5 of my programs on the Macintosh
with these changes and they all ran correctly. If this is of value to the person
that actually fixes these problems please feel free to use it in any way.

[dir:~/fe/mystic/decks] dir% diff -c
/Users/dir/gfortran/gcc/libgfortran/io/backspace.c 
/Users/dir/junk/io/backspace.c
*** /Users/dir/gfortran/gcc/libgfortran/io/backspace.c  Fri Feb 25 18:48:05 2005
--- /Users/dir/junk/io/backspace.c  Wed Jan 12 13:27:30 2005
***
*** 111,117 
if (p == NULL)
  goto io_error;
  
!   new = file_position (current_unit->s) - *p - 2*length;
if (sseek (current_unit->s, new) == FAILURE)
  goto io_error;
  
--- 111,117 
if (p == NULL)
  goto io_error;
  
!   new = file_position (current_unit->s) - *p - length;
if (sseek (current_unit->s, new) == FAILURE)
  goto io_error;
  
***
*** 155,175 
  u->endfile = AT_ENDFILE;
else
  {
if (file_position (u->s) == 0)
goto done;  /* Common special case */
!   if (u->mode==WRITING){
!  flush(u->s);
!  struncate (u->s);
!u->mode = READING;
!   }
if (u->flags.form == FORM_FORMATTED)
formatted_backspace ();
else
unformatted_backspace ();
- u->endfile = NO_ENDFILE;
-   u->current_record = 0;
  }
- 
  
   done:
library_end ();
--- 155,171 
  u->endfile = AT_ENDFILE;
else
  {
+   if (u->current_record)
+   next_record (1);
+ 
if (file_position (u->s) == 0)
goto done;  /* Common special case */
! 
if (u->flags.form == FORM_FORMATTED)
formatted_backspace ();
else
unformatted_backspace ();
  }
  
   done:
library_end ();



-- 


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

[Bug middle-end/20218] Can't use __attribute__ ((visibility ("hidden"))) to hide a symbol

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2005-02-26 02:30 ---
>From the elf spec:
If different visibility attributes are specified for distinct references to or
definitions of a symbol, the 
most constraining visibility attribute must be propagated to the resolving
symbol in the linked object. 
The attributes, ordered from least to most constraining, are: STV_PROTECTED,
STV_HIDDEN and 
STV_INTERNAL.

You can't have 2 definitions. The above lines apply to cases where there is
only one definition and others are just references.

-- 


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

[Bug middle-end/20218] Can't use __attribute__ ((visibility ("hidden"))) to hide a symbol

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-26 
02:00 ---
Huh, foo is defined in a different TU (module in elf terms).
Where in the elf documention says this what you said should happen?

-- 


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

[Bug middle-end/20218] Can't use __attribute__ ((visibility ("hidden"))) to hide a symbol

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2005-02-26 01:42 ---
It is a gcc bug where gcc failed to mark "foo" as hidden with

gcc -O -g -fPIC   -c -o bar.o bar.c

foo is defined in foo2.c.

-- 


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

[Bug libgcj/20169] Serialization: readResolve does not work

[bonniot at users dot sf dot net]

--- Additional Comments From bonniot at users dot sf dot net  2005-02-26 
01:35 ---
After some investigation, I think I understand what is going wrong. It seems
like readResolve is only called if it is declared in the deserialized object's
class. However, it should also be searched for in the classes's parents,
provided the method there is visible (that is, normal rules apply).

I submitted a related testcase to mauve:
http://sources.redhat.com/ml/mauve-patches/2005/msg00032.html

-- 


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

[Bug middle-end/20218] Can't use __attribute__ ((visibility ("hidden"))) to hide a symbol

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-26 
01:24 ---
Hmm, from the elf spec:
If different visibility attributes are specified for distinct references to or 
definitions of a symbol, the 
most constraining visibility attribute must be propagated to the resolving 
symbol in the linked object. 
The attributes, ordered from least to most constraining, are: STV_PROTECTED, 
STV_HIDDEN and 
STV_INTERNAL.

So is this really a binutils bug and not a gcc one?

-- 


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

[Bug tree-optimization/20219] Missed optimisation sin / tan --> cos

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-26 
01:13 ---
Confirmed, nice catch.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|rtl-optimization|tree-optimization
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-26 01:13:02
   date||


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

[Bug c++/20220] [4.0/4.1 Regression] Rejecting invalid template code, breaks most of Boost

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-26 
00:58 ---
This worked with 4.0.0 20050113 but fails with 20050210.

-- 


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

[Bug c++/20220] [4.0/4.1 Regression] Rejecting invalid template code, breaks most of Boost

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-26 
00:55 ---
Easy reduction:
template  class b {};
template  class a
{
static const T value = i;
  b(value+1) > next;
};

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-26 00:55:09
   date||


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

[Bug c++/20220] [4.0/4.1 Regression] Rejecting invalid template code, breaks most of Boost

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-02-26 
00:46 ---
Created an attachment (id=8288)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8288&action=view)
Preprocessed source (to be reduced)


-- 


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

[Bug c++/20220] [4.0/4.1 Regression] Rejecting invalid template code, breaks most of Boost

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.0.0
Version|unknown |4.0.0


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

[Bug c++/20220] New: [4.0/4.1 Regression] Rejecting invalid template code, breaks most of Boost

[giovannibajo at libero dot it]

The attached preprocessed source code is an example of a recent regresion of 
the C++ frontend which totally *kills* Boost: test rate dropped from 90% to 9% 
because of this! This used to work like 2 weeks ago...

-- 
   Summary: [4.0/4.1 Regression] Rejecting invalid template code,
breaks most of Boost
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: giovannibajo at libero dot it
CC: gcc-bugs at gcc dot gnu dot org,mw8329 at yahoo dot com
dot au


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

[Bug target/20199] -fvisibility-inlines-hidden broken on powerpc64-linux

[janis at gcc dot gnu dot org]

--- Additional Comments From janis at gcc dot gnu dot org  2005-02-26 00:15 
---
My command line in the previous comment should have said "-o libx.so".

-- 


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

[Bug rtl-optimization/20219] Missed optimisation sin / tan --> cos

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||19987
  nThis||
   Severity|normal  |enhancement
   Keywords||missed-optimization


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

[Bug target/20199] -fvisibility-inlines-hidden broken on powerpc64-linux

[janis at gcc dot gnu dot org]

--- Additional Comments From janis at gcc dot gnu dot org  2005-02-25 23:53 
---
Ah, yes.  I haven't come up with a testcase that doesn't use libstdc++,
but the following testcase fails without the patch referenced in
comment #28 and passes with it:

#pragma GCC visibility push(default)
#include 
#pragma GCC visibility pop

void foo()
{
std::allocator c2;
}

Command line: g++ -m64 -fvisibility-inlines-hidden -shared -o libx.C x.C

Without the #pragmas, this works with 20050223 mainline and binutils
when  is replaced by ; there are explicit instantiations in
libstdc++ for allocator but not for allocator.  This is all
with -m64, with -m32 I haven't seen any problems at all.

-- 


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

[Bug rtl-optimization/20219] New: Missed optimisation sin / tan --> cos

[christophe dot jaillet at wanadoo dot fr]

GCC knows how to optimise
tan * cos --> sin   (fold-const line 7734)
cos * tan --> sin
sin / cos --> tan   (fold-const line 8080)
cos / sin --> 1.0 / tan (fold-const line 8094)

but misses
sin / tan --> cos
tan / sin --> 1.0 / cos

-- 
   Summary: Missed optimisation sin / tan --> cos
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christophe dot jaillet at wanadoo dot fr
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/20217] Switching off the optimization triggers undefined reference at link time when building Linux kernel.

[stiriac at oddpost dot com]

--- Additional Comments From stiriac at oddpost dot com  2005-02-25 23:25 
---
You mean this behavior is perfectly normal for the compiler ? 
This means the optimization flag plays somehow a redundant role with the 
options enabling/disabling error or warning messages ?

I haven't seen anything like this in the Gcc doc, though I cannot say I learnt 
it by heart :)

-- 


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

[Bug middle-end/20218] Can't use __attribute__ ((visibility ("hidden"))) to hide a symbol

[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=20218

[Bug middle-end/20218] Can't use __attribute__ ((visibility ("hidden"))) to hide a symbol

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2005-02-25 23:02 ---
Created an attachment (id=8287)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8287&action=view)
A testcase

On ia32

[EMAIL PROTECTED] hidden]$ make
gcc -O -g   -c -o main.o main.c
gcc -O -g -fPIC   -c -o foo1.o foo1.c
gcc -O -g -fPIC   -c -o bar.o bar.c
gcc -O -g -fPIC   -c -o foo2.o foo2.c
ar rcs libfoo.a foo2.o
gcc -o libbar.so -shared bar.o libfoo.a
gcc -o main main.o foo1.o libbar.so -Wl,-rpath,.
./main
make: *** [all] Error 1

On x86_64 with the older linker:
gcc -B/usr/bin/ -O -g   -c -o main.o main.c
gcc -B/usr/bin/ -O -g -fPIC   -c -o foo1.o foo1.c
gcc -B/usr/bin/ -O -g -fPIC   -c -o bar.o bar.c
gcc -B/usr/bin/ -O -g -fPIC   -c -o foo2.o foo2.c
ar rcs libfoo.a foo2.o
gcc -B/usr/bin/ -o libbar.so -shared bar.o libfoo.a
gcc -B/usr/bin/ -o main main.o foo1.o libbar.so -Wl,-rpath,.
./main
./main: Symbol `foo' causes overflow in R_X86_64_PC32 relocation
./main: Symbol `bar' causes overflow in R_X86_64_PC32 relocation
make: *** [all] Segmentation fault

On x86_64 with the newer linker:

gcc -O -g   -c -o main.o main.c
gcc -O -g -fPIC   -c -o foo1.o foo1.c
gcc -O -g -fPIC   -c -o bar.o bar.c
gcc -O -g -fPIC   -c -o foo2.o foo2.c
ar rcs libfoo.a foo2.o
gcc -o libbar.so -shared bar.o libfoo.a
/usr/local/bin/ld: bar.o: relocation R_X86_64_PC32 against `foo' can not be
used when making a shared object; recompile with -fPIC
/usr/local/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make: *** [libbar.so] Error 1


-- 


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

[Bug middle-end/20218] New: Can't use __attribute__ ((visibility ("hidden"))) to hide a symbol

[hjl at lucon dot org]

When __attribute__ ((visibility ("hidden"))) is used to hide/optimize
a symbol, foo, defined in another .o/archive file, foo isn't marked as
hidden. As the result, I get either runtime or linktime error.

-- 
   Summary: Can't use __attribute__ ((visibility ("hidden"))) to
hide a symbol
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/20217] Switching off the optimization triggers undefined reference at link time when building Linux kernel.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
22:51 ---
You ask a linux kernel person :) or you read the source to make sure that all 
extern inline functions 
have a corresponding normal definition.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug middle-end/20217] Switching off the optimization triggers undefined reference at link time when building Linux kernel.

[stiriac at oddpost dot com]

--- Additional Comments From stiriac at oddpost dot com  2005-02-25 22:48 
---
(In reply to comment #1)
> Are you sure that this is a GCC bug, IIRC the linux kernel uses extern inline.

How to judge ? I do change nothing to the Linux kernel but I change a 
compilation flag and I get undefined symbols at link. The compiler does not 
signal any error even a warning. I'm not a Gcc expert but the common sense 
tells me is someting the compiler should report as error or warning before 
reaching the link phase.

-- 


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

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2005-02-25 22:40 
---

Personally, I think the better approach for the libstdc++ parts is to allow
__attribute__ visibility on namespace declarations.

That way, all this goo could be removed, and centralized in one place. Ie,
c++config.h could have something like:

namespace std __attribute__ ((visibility ("default") ));
{
 
}


And volia! We are done.

(When I first saw this, I thought that the solution being proposed was mass
decoration of std:: names with some kind of pseudo-__declspec bullshit. Of
course, that is a non-starter, so I'm glad to see the thinking has evolved a 
bit.)

-benjamin





-- 
   What|Removed |Added

 CC||bkoz at gcc dot gnu dot org


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

[Bug target/19930] gcc.dg/pr19402-2.c fails on ia64-hpux

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
22:27 ---
Fixed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.0.0


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

[Bug target/19930] gcc.dg/pr19402-2.c fails on ia64-hpux

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-25 
22:22 ---
Subject: Bug 19930

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-02-25 22:22:45

Modified files:
gcc: ChangeLog libgcc2.c libgcc2.h 
gcc/doc: tm.texi 
gcc/config/ia64: t-ia64 lib1funcs.asm hpux.h 

Log message:
PR target/19930
* doc/tm.texi (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Document.
(LIBGCC2_HAS_DF_MODE): New.
(LIBGCC2_HAS_XF_MODE): New.
(LIBGCC2_HAS_TF_MODE): New.
* libgcc2.h (LIBGCC2_HAS_XF_MODE): New name for HAVE_XFMODE.
(LIBGCC2_HAS_TF_MODE): New name for HAVE_TFMODE.
* libgcc2.c (LIBGCC2_HAS_XF_MODE): New name for HAVE_XFMODE.
(LIBGCC2_HAS_TF_MODE): New name for HAVE_TFMODE.
(LIBGCC2_HAS_DF_MODE): New name for HAVE_DFMODE.
* config/ia64/t-ia64 (LIB1ASMFUNCS): Remove __compat
and add _fixtfdi, _fixunstfdi, _floatditf
* lib1funcs.asm: Remove L__compat. Add L_fixtfdi,
L_fixunstfdi, L_floatditf.
* config/ia64/hpux.h (LIBGCC2_HAS_XF_MODE): Define.
(LIBGCC2_HAS_TF_MODE): Define.

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.3&r2=2.7592.2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/libgcc2.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.185&r2=1.185.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/libgcc2.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.37&r2=1.37.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/tm.texi.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.414&r2=1.414.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/t-ia64.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.22&r2=1.22.42.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/lib1funcs.asm.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.16&r2=1.16.70.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/hpux.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.47&r2=1.47.2.1



-- 


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

[Bug middle-end/20217] Switching off the optimization triggers undefined reference at link time when building Linux kernel.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
22:08 ---
Are you sure that this is a GCC bug, IIRC the linux kernel uses extern inline.

-- 
   What|Removed |Added

  Component|c   |middle-end


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

[Bug c/20217] New: Switching off the optimization triggers undefined reference at link time when building Linux kernel.

[stiriac at oddpost dot com]

1. the exact version of GCC;
% gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit 
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-49)

2. the system type;
% uname -a
Linux engst3lux.afceng.afc.local 2.4.21-27.0.1.EL #1 Mon Dec 20 18:56:53 EST
2004 i686 i686 i386 GNU/Linux

3. the options given when GCC was configured/built;
Please see #1.

4. the complete command line that triggers the bug;
Please see the description below.

5. the compiler output (error messages, warnings, etc.)
Please see the description below.

6. the preprocessed file (*.i*) 
Out of scope.


DESCRIPTION.

Summary:
Building the Linux kernel with "-O2" ends successfully.
Building the Linux kernel with "-O0" or "no optimization flags" breaks at final
link with undefined symbols.

Detail:
I got this problem when building a Linux kernel without optimization for debug
purpose on an embedded target. I retested on my host (#2) which is a Dell PC
with preinstalled RedHat Entreprise Linux (#1). I tested building the Linux
kernel 2.6.6, 2.6.8 and 2.6.10. The behavior is present with all these
distributions. I think is a Gcc problem because depends of the presence/absence
of the "-O[0|1|2|3|s]" flags. The undefined symbols are the whole family of
network conversion macros: "htonl, htons,...".

To get the faulty behaviour:
1. Get a Linux kernel distribution (2.6.10 by example)
2. Install it
3. cd in linux-2-6-10
4. do a "make defconfig"
5. edit the Makefile
6. look for the line: "ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE"
7. change the third line beneath from: "CFLAGS  += -O2"
to: "CFLAGS  += -O0" (uppercase o zero)
8. do a "make 2>&1 | tee make.log"
9. the final link phase fails with undefined symbols:

Extract from output:
   ld -m elf_i386  -r -o init/built-in.o init/main.o init/version.o
init/mounts.o init/initramfs.o
ld -m elf_i386  -T arch/i386/kernel/vmlinux.lds.s
arch/i386/kernel/head.o arch/i386/kernel/init_task.o  
 init/built-in.o --start-group  usr/built-in.o  arch/i386/kernel/built-in.o 
arch/i386/mm/built-in.o  arch/i386/
mach-default/built-in.o  arch/i386/crypto/built-in.o  kernel/built-in.o 
mm/built-in.o  fs/built-in.o  ipc/built
-in.o  security/built-in.o  crypto/built-in.o  lib/lib.a  arch/i386/lib/lib.a 
lib/built-in.o  arch/i386/lib/bui
lt-in.o  drivers/built-in.o  sound/built-in.o  arch/i386/pci/built-in.o 
arch/i386/oprofile/built-in.o  arch/i38
6/power/built-in.o  net/built-in.o --end-group  -o .tmp_vmlinux1
fs/built-in.o(.text+0xa0969): In function `ext3_get_dev_journal':
: undefined reference to `ntohl'
fs/built-in.o(.text+0xa0980): In function `ext3_get_dev_journal':
: undefined reference to `ntohl'

-- 
   Summary: Switching off the optimization triggers undefined
reference at link time when building Linux kernel.
   Product: gcc
   Version: 3.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stiriac at oddpost dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/20216] [4.0/4.1 Regression] Simple loop runs out of stack at -O1

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
21:36 ---
(In reply to comment #2)
> Note that patch I attached is against the apple-ppc-branch. So, it may not
> apply to the mainline as is. 

It looks like it should from my updated sources.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-25 21:36:07
   date||


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

[Bug target/19930] gcc.dg/pr19402-2.c fails on ia64-hpux

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-25 
21:34 ---
Subject: Bug 19930

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-25 21:34:49

Modified files:
gcc: ChangeLog libgcc2.h libgcc2.c 
gcc/doc: tm.texi 
gcc/config/ia64: t-ia64 lib1funcs.asm hpux.h 

Log message:
PR target/19930
* doc/tm.texi (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Document.
(LIBGCC2_HAS_DF_MODE): New.
(LIBGCC2_HAS_XF_MODE): New.
(LIBGCC2_HAS_TF_MODE): New.
* libgcc2.h (LIBGCC2_HAS_XF_MODE): New name for HAVE_XFMODE.
(LIBGCC2_HAS_TF_MODE): New name for HAVE_TFMODE.
* libgcc2.c (LIBGCC2_HAS_XF_MODE): New name for HAVE_XFMODE.
(LIBGCC2_HAS_TF_MODE): New name for HAVE_TFMODE.
(LIBGCC2_HAS_DF_MODE): New name for HAVE_DFMODE.
* config/ia64/t-ia64 (LIB1ASMFUNCS): Remove __compat
and add _fixtfdi, _fixunstfdi, _floatditf
* lib1funcs.asm: Remove L__compat. Add L_fixtfdi,
L_fixunstfdi, L_floatditf.
* config/ia64/hpux.h (LIBGCC2_HAS_XF_MODE): Define.
(LIBGCC2_HAS_TF_MODE): Define.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7597&r2=2.7598
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/libgcc2.h.diff?cvsroot=gcc&r1=1.37&r2=1.38
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/libgcc2.c.diff?cvsroot=gcc&r1=1.185&r2=1.186
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/tm.texi.diff?cvsroot=gcc&r1=1.414&r2=1.415
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/t-ia64.diff?cvsroot=gcc&r1=1.22&r2=1.23
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/lib1funcs.asm.diff?cvsroot=gcc&r1=1.16&r2=1.17
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/hpux.h.diff?cvsroot=gcc&r1=1.47&r2=1.48



-- 


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

[Bug tree-optimization/20216] [4.0/4.1 Regression] Simple loop runs out of stack at -O1

[fjahanian at apple dot com]

--- Additional Comments From fjahanian at apple dot com  2005-02-25 21:32 
---
Created an attachment (id=8286)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8286&action=view)
A proposed patch to fix this

Note that patch I attached is against the apple-ppc-branch. So, it may not
apply to the mainline
as is. 

-- 


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

[Bug tree-optimization/20216] [4.0/4.1 Regression] Simple loop runs out of stack at -O1

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
21:30 ---
Confirmed.

-- 
   What|Removed |Added

   Keywords||compile-time-hog, memory-hog
Summary|Simple loop runs out of |[4.0/4.1 Regression] Simple
   |stack at -O1|loop runs out of stack at -
   ||O1
   Target Milestone|--- |4.0.0


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

[Bug tree-optimization/20216] New: Simple loop runs out of stack at -O1

[fjahanian at apple dot com]

Following test case runs out of stack space when
gcc tries to compute factorial (159). I have a patch which does two simple 
things. 1) it rewrites 
tree_fold_factorial
function into its non-recursive version, and 2) it sets a limit before deciding 
to call chrec_evaluate. This 
limit is arbitrary in this
patch. Author of the algorithm may want to decide when to stop evaluating 
feasibility of this 
optimization. Note that even with this limit,
the computed factorial overflows. So, even a much smaller limit is needed if 
this value is significant.

/* bad.c */
static unsigned int *buffer;

void FUNC (void)
{
 unsigned int *base;
 int i, j;

 for (i = 0; i < 4; i++)
  for (j = 0; j < 160; j++)
   *base++ = buffer[j];
}

% mygccm5 -c -O1 bad.c
Out of stack space.
Try running 'limit stacksize unlimited' in the shell to raise its limit.

-- 
   Summary: Simple loop runs out of stack at -O1
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fjahanian at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-apple-darwin
  GCC host triplet: powerpc-apple-darwin
GCC target triplet: powerpc-apple-darwin


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

[Bug preprocessor/20183] -D option handling doesn't account for character sets

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
21:25 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-25 21:25:58
   date||


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

[Bug tree-optimization/20204] [4.0/4.1 regression] miscompilation of asm-declared registers

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|4.1.0   |4.0.0


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

[Bug tree-optimization/20204] [4.0/4.1 regression] miscompilation of asm-declared registers

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.1.0


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

[Bug tree-optimization/20204] [4.0/4.1 regression] miscompilation of asm-declared registers

[dnovillo at gcc dot gnu dot org]

--- Additional Comments From dnovillo at gcc dot gnu dot org  2005-02-25 
21:18 ---
Fixed.  http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01625.html

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/20204] [4.0/4.1 regression] miscompilation of asm-declared registers

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-25 
21:12 ---
Subject: Bug 20204

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-25 21:12:34

Modified files:
gcc: ChangeLog tree-into-ssa.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: pr20204.c 

Log message:
PR tree-optimization/20204
* tree-into-ssa.c (insert_phi_nodes_for): Do not use
REWRITE_THIS_STMT markers on PHI nodes.
(rewrite_initialize_block): Likewise.

testsuite/ChangeLog

PR tree-optimization/20204
* testsuite/gcc.dg/pr20204.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7596&r2=2.7597
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-into-ssa.c.diff?cvsroot=gcc&r1=2.41&r2=2.42
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5084&r2=1.5085
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20204.c.diff?cvsroot=gcc&r1=1.1&r2=1.2



-- 


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

[Bug tree-optimization/20204] [4.0/4.1 regression] miscompilation of asm-declared registers

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-25 
21:10 ---
Subject: Bug 20204

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-02-25 21:10:30

Modified files:
gcc: ChangeLog tree-into-ssa.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: pr20204.c 

Log message:
PR tree-optimization/20204
* tree-into-ssa.c (insert_phi_nodes_for): Do not use
REWRITE_THIS_STMT markers on PHI nodes.
(rewrite_initialize_block): Likewise.

testsuite/ChangeLog

PR tree-optimization/20204
* testsuite/gcc.dg/pr20204.c: New test.

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.2&r2=2.7592.2.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-into-ssa.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.41&r2=2.41.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084&r2=1.5084.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20204.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug middle-end/19956] [4.0/4.1 Regression] ICE copy_tree_r, at tree-inline.c:2320 on simple Ada code

[kenner at vlsi1 dot ultra dot nyu dot edu]

--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu  
2005-02-25 20:44 ---
Subject: Re:   [4.0/4.1 Regression] ICE copy_tree_r, at tree-inline.c:2320 on 
simple Ada code

Richard, any idea? This is not ACATS but has been reported to affect
real Ada code.

Not yet.  I'm caught deep in the bowels of PR19900 right now ...


-- 


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

[Bug middle-end/19956] [4.0/4.1 Regression] ICE copy_tree_r, at tree-inline.c:2320 on simple Ada code

[laurent at guerby dot net]

--- Additional Comments From laurent at guerby dot net  2005-02-25 20:42 
---
> Someone who has more knowlege about the gimplifier and PLACEHOLDER_EXPRs
should look into this 

Richard, any idea? This is not ACATS but has been reported to affect real Ada 
code.


-- 
   What|Removed |Added

 CC||kenner at vlsi1 dot ultra
   ||dot nyu dot edu


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

[Bug libfortran/17992] reading empty line does not return 0

[coudert at clipper dot ens dot fr]

--- Additional Comments From coudert at clipper dot ens dot fr  2005-02-25 
19:50 ---
I'm no language lawyer, but this works (returns two zeros and no error) for Sun,
PGF, IBM, MIPSpro and Intel compilers. I think this should be considered as a
bug (I confirm it is still present in CVS).

-- 
   What|Removed |Added

 CC||coudert at clipper dot ens
   ||dot fr


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

[Bug java/20215] gcj does not accept classes with same name fields

[bonniot at users dot sf dot net]

--- Additional Comments From bonniot at users dot sf dot net  2005-02-25 
19:50 ---
Created an attachment (id=8285)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8285&action=view)
Testcase


-- 


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

[Bug target/20214] [3.3/3.4/4.0 Regression] ICE with register name which is not a register in x86

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
19:49 ---
By the way here is the ICE:
t4.c: In function ‘main’:
t4.c:5: internal compiler error: in print_reg, at config/i386/i386.c:6241
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

-- 


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

[Bug java/20215] New: gcj does not accept classes with same name fields

[bonniot at users dot sf dot net]

According to the JVM spec, class files can have several fields with the same
name. As long as they have different types, they will be distinguished since all
field operations specify both the name and the field of the field. Sun's JVM
accepts such classes, and correctly distinguishes the fields, as you can see in
the attached testcase. Here is the disassembly of this class:

Access flags: 0x20 super
This class: 2=DuplicateField, super: 4=java.lang.Object
Interfaces (count: 0):

Fields (count: 2):
Field name:"foo" static Signature: 6=java.lang.String
Field name:"foo" static Signature: 7=int

Methods (count: 3):

Method name:"" Signature: 9=()void
Attribute "Code", length:17, max_stack:1, max_locals:1, code_length:5
  0: aload_0
  1: invokespecial #11= ()void>
  4: return

Method name:"main" public static Signature: 14=(java.lang.String[])void
Attribute "Code", length:31, max_stack:2, max_locals:1, code_length:19
  0: getstatic #20=
  3: getstatic #22=
  6: invokevirtual #28=
  9: getstatic #20=
 12: getstatic #30=
 15: invokevirtual #33=
 18: return

Method name:"" static Signature: 9=()void
Attribute "Code", length:24, max_stack:1, max_locals:0, code_length:12
  0: ldc #36=
  2: putstatic #22=
  5: sipush 42
  8: putstatic #30=
 11: return


Sun's JVM correctly executes that program:

$ java DuplicateField
WOW
42

gcj fails during compilation with:

$ gcj DuplicateField.class
DuplicateField.java: In class 'DuplicateField':
DuplicateField.java: In method 'DuplicateField.main(java.lang.String[])':
DuplicateField.java:0: error: mismatching signature for field 'foo' in
'DuplicateField'
DuplicateField.java: In method 'DuplicateField.()':
DuplicateField.java:0: error: mismatching signature for field 'foo' in
'DuplicateField'

Surprisingly, gij also fails with:

Exception in thread "main" java.lang.NullPointerException
   at java.io.PrintStream.println(java.lang.String) 
(/tmp/gcc/lib/libgcj.so.6.0.0)
   at DuplicateField.main(java.lang.String[]) (Unknown Source)
   at gnu.java.lang.MainThread.call_main() (/tmp/gcc/lib/libgcj.so.6.0.0)
   at gnu.java.lang.MainThread.run() (/tmp/gcc/lib/libgcj.so.6.0.0)

gcj (GCC) 4.0.0 20050223

-- 
   Summary: gcj does not accept classes with same name fields
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonniot at users dot sf dot net
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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

[Bug target/20214] [3.3/3.4/4.0 Regression] ICE with register name which is not a register in x86

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Known to fail||4.0.0 3.3.3 3.2.3 3.4.0
  Known to work||3.0.4 2.95.3


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

[Bug target/20214] [3.3/3.4/4.0 Regression] ICE with register name which is not a register in x86

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


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

[Bug target/20214] New: [3.3/3.4/4.0 Regression] ICE with register name which is not a register in x86

[pinskia at gcc dot gnu dot org]

The following invalid x86 code ICEs on the mainline and has since at least 
3.2.3:
int main()
{
  register void *return_dst __asm__ ("r13");
  return *(int*)(return_dst);
}

-- 
   Summary: [3.3/3.4/4.0 Regression] ICE with register name which is
not a register in x86
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: minor
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libstdc++/20213] New: cassert header documentation wrong

[fmhess at users dot sourceforge dot net]

The cassert header states: 
 
 *  This is the C++ version of the Standard C Library header @c assert.h, 
 *  and its contents are (mostly) the same as that header, but are all 
 *  contained in the namespace @c std. 
 
However, this bug report http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15771 
indicates that the assert macro is (and should be) in the global namespace, 
not in std.

-- 
   Summary: cassert header documentation wrong
   Product: gcc
   Version: 3.3.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fmhess at users dot sourceforge dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/20212] [4.0 Regression] attribute unused vs. member function template

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
19:00 ---
Actually I figured out an obvious way to reduce it after looking at the error 
message and seeing that the 
unused parameter was pointing to the prototype of the function:
template void f(int);
void g(int i)
{
  f<0>(i);
}
template void f(int i __attribute__((unused)) )
{}


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||4.0.0
  Known to work||3.4.0
   Last reconfirmed|-00-00 00:00:00 |2005-02-25 19:00:48
   date||
   Target Milestone|--- |4.0.0


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

[Bug rtl-optimization/20211] autoincrement generation is poor

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-02-25 
18:59 ---
What is the compile-time impact of this patch on cc-i compilation, the usual 
C++ testcases, and SPEC? I am sure this is something worthwile to mention for 
a review.

And BTW, out of curiosity, does the new pass have to live in regmove.c?

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-25 18:59:53
   date||


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

[Bug rtl-optimization/20211] autoincrement generation is poor

[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=20211

[Bug c++/20212] [4.0 Regression] attribute unused vs. member function template

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
18:41 ---
I will try to reduce this later today.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Keywords||diagnostic
Summary|attribute unused vs. member |[4.0 Regression] attribute
   |function template   |unused vs. member function
   ||template


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

[Bug tree-optimization/19938] Missed jump threading opportunity due to signedness difference

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
18:38 ---
And in 4.0 also.

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


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

[Bug c++/20212] attribute unused vs. member function template

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2005-02-25 18:15 
---
Created an attachment (id=8283)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8283&action=view)
pre-processed file, bzip2 compressed


-- 


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

[Bug c++/20212] New: attribute unused vs. member function template

[bkoz at gcc dot gnu dot org]

Works with: 3.4.2
Fails with: 4.0.0

For some reason, the attached output warns (oddly) with the attached code:

%COMP.sh "-g -O2 -Wunused -Wextra" debug.ii
/mnt/hd/src/gcc/libstdc++-v3/src/debug.cc: In instantiation of 'void
__gnu_debug::_Error_formatter::_M_format_word(char*, int, const char*, _Tp)
const [with _Tp = const void*]':
/mnt/hd/src/gcc/libstdc++-v3/src/debug.cc:274:   instantiated from here
/mnt/hd/bld/gcc.disable-c99/i686-pc-linux-gnu/libstdc++-v3/include/debug/formatter.h:363:
warning: unused parameter '__n'
/mnt/hd/src/gcc/libstdc++-v3/src/debug.cc: In instantiation of 'void
__gnu_debug::_Error_formatter::_M_format_word(char*, int, const char*, _Tp)
const [with _Tp = const char*]':
/mnt/hd/src/gcc/libstdc++-v3/src/debug.cc:383:   instantiated from here
/mnt/hd/bld/gcc.disable-c99/i686-pc-linux-gnu/libstdc++-v3/include/debug/formatter.h:363:
warning: unused parameter '__n'
/mnt/hd/src/gcc/libstdc++-v3/src/debug.cc: In instantiation of 'void
__gnu_debug::_Error_formatter::_M_format_word(char*, int, const char*, _Tp)
const [with _Tp = unsigned int]':
/mnt/hd/src/gcc/libstdc++-v3/src/debug.cc:473:   instantiated from here
/mnt/hd/bld/gcc.disable-c99/i686-pc-linux-gnu/libstdc++-v3/include/debug/formatter.h:363:
warning: unused parameter '__n'
/usr/bin/ld: cannot find -lv3test
collect2: ld returned 1 exit status

I believe this code to be fine (indeed, with 3.4.x I have no warning.)

I tried to reduce this down but didn't hit anything with the obvious reduction.
So, I file this instead.

-benjamin

-- 
   Summary: attribute unused vs. member function template
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu 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=20212

[Bug tree-optimization/19938] Missed jump threading opportunity due to signedness difference

[rakdver at gcc dot gnu dot org]

-- 
Bug 19938 depends on bug 19937, which changed state.

Bug 19937 Summary: [4.0 regression] Wrong loop exit (causes binutils to fail)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19937

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/19937] [4.0 regression] Wrong loop exit (causes binutils to fail)

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2005-02-25 
17:04 ---
Also in 4.0.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/19937] [4.0 regression] Wrong loop exit (causes binutils to fail)

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-25 
16:58 ---
Subject: Bug 19937

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-02-25 16:56:28

Modified files:
gcc: ChangeLog tree-ssa-loop-ivopts.c 

Log message:
PR tree-optimization/19937
* tree-ssa-loop-ivopts.c (rewrite_use_compare): Cast the final value
to the type of the induction variable.

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&r2=2.7592.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.49&r2=2.49.2.1



-- 


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

[Bug tree-optimization/17863] [4.0 Regression] threefold performance loss, not inlining as much

[rguenth at gcc dot gnu dot org]

--- Additional Comments From rguenth at gcc dot gnu dot org  2005-02-25 
16:56 ---
Yes, the regression is even worse on the closed-duplicate #18704.  There you can
also find some analysis of inline parameter tuning.

-- 


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

[Bug tree-optimization/14703] Inadequate optimization of inline templated functions

[rguenth at gcc dot gnu dot org]

--- Additional Comments From rguenth at gcc dot gnu dot org  2005-02-25 
16:53 ---
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01571.html

improves this to the extent that the inliner now estimates the size of
fibconst to
   nsize
 0,1,2  0
   31
   42
   54
   67

etc., i.e. to the number of additions required.

Inlining all of fibconst<90> now only requires the appropriate limits, or,
of course folding during inlining.

-- 
   What|Removed |Added

 CC||rguenth at tat dot physik
   ||dot uni-tuebingen dot de


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

[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests

[aoliva at gcc dot gnu dot org]

--- Additional Comments From aoliva at gcc dot gnu dot org  2005-02-25 
16:53 ---
Hard-linking is an option, although we can't rely on hard-links being available.
 Soft-linking would require even more pathname tweaking, it's just not worth it.

Anyhow, thanks for testing, I see what the problem is, and I'll have a new patch
for you soon.

-- 


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

[Bug tree-optimization/20204] [4.0 regression] miscompilation of asm-declared registers

[dnovillo at gcc dot gnu dot org]

--- Additional Comments From dnovillo at gcc dot gnu dot org  2005-02-25 
16:48 ---
(In reply to comment #9)
> I've confirmed on this other machine that the update caused the same breakage.
> 
Ah, yes.  I see it now.  The reorg tickled a bug in the renamer:

# n_21 = V_MUST_DEF 
n = D.1158_28
...
n_48 = PHI 
:
...
# VUSE 
n.5_40 = n;


That's wrong.  The last VUSE should be VUSE .  Virtual operands should
always be in FUD-chain form.

Working on a fix.

-- 
   What|Removed |Added

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


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

[Bug tree-optimization/17863] [4.0 Regression] threefold performance loss, not inlining as much

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-02-25 
16:43 ---
Why isn't this a critical regression? We're regressing *badly* on code 
generation.

-- 
   What|Removed |Added

   Severity|normal  |critical


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

[Bug target/19019] GCC ldouble format incompatibility with XLC long double

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-25 
16:42 ---
Subject: Bug 19019

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2005-02-25 16:42:01

Modified files:
gcc: ChangeLog reload.c 
gcc/config/rs6000: rs6000.md 

Log message:
Backport from mainline:
2005-02-24  David Edelsohn  <[EMAIL PROTECTED]>
PR target/19019
* reload.c (operands_match_p): Only increment register number for
SCALAR_INT_MODE_P modes in multiple hard registers.
* config/rs6000/rs6000.md (trunctfdf2): Remove register constraints.
Fix formatting.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.805&r2=2.2326.2.806
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reload.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.229.4.7&r2=1.229.4.8
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.md.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.284.4.16&r2=1.284.4.17



-- 


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

[Bug c++/20209] [3.3/3.4/4.0 Regression] Missing warnings for "aggregate has a partly bracketed initializer"

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-02-25 16:38 
---
Yeah, caused by addition of reshape_init.
Bigger testcase:

// PR c++/20209
// { dg-do compile }
// { dg-options "-Wmissing-braces" }

struct S { char a[6]; int b[2]; };
struct T { int a; int b[2]; };
struct U { int a; T b; };
struct V { char a[6]; int b[2]; int c; };
struct W { int a; int b[2]; int c; };
struct X { int a; W b; int c; };

S a = { { "hello" }, { 1, 2 } };
S b = { { "hello" }, 1, 2 };// { dg-warning "" }
S c = { "hello", { 1, 2 } };
S d = { "hello", 1, 2 };// { dg-warning "" }
T e = { 1, { 2, 3 } };
T f = { 1, 2, 3 };  // { dg-warning "" }
U g = { 1, { 2, { 3, 4 } } };
U h = { 1, 2, { 3, 4 } };   // { dg-warning "" }
U i = { 1, 2, 3, 4 };   // { dg-warning "" }
V j = { { "hello" }, { 1, 2 }, 3 };
V k = { { "hello" }, 1, 2, 3 }; // { dg-warning "" }
V l = { "hello", { 1, 2 }, 3 };
V m = { "hello", 1, 2, 3 }; // { dg-warning "" }
W n = { 1, { 2, 3 }, 4 };
W o = { 1, 2, 3, 4 };   // { dg-warning "" }
X p = { 1, { 2, { 3, 4 }, 5 }, 6 };
X q = { 1, 2, { 3, 4 }, 5, 6 }; // { dg-warning "" }
X r = { 1, 2, 3, 4, 5, 6 }; // { dg-warning "" }


-- 
   What|Removed |Added

 CC||mark at codesourcery dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-25 16:38:03
   date||


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

[Bug tree-optimization/19794] [meta-bug] Jump threading related bugs

[kazu at cs dot umass dot edu]

-- 
Bug 19794 depends on bug 19938, which changed state.

Bug 19938 Summary: Missed jump threading opportunity due to signedness 
difference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19938

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches

[kazu at cs dot umass dot edu]

-- 
Bug 19721 depends on bug 19938, which changed state.

Bug 19938 Summary: Missed jump threading opportunity due to signedness 
difference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19938

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/19938] Missed jump threading opportunity due to signedness difference

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2005-02-25 16:29 
---
Yes, this is fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

Re: signed enum bug

[Eric Botcazou]

> The compiler outputs a bg branch instruction when it should use a bgu. The
> cause seems to be related to having a negative value in the enumeration.

Fixed in 3.4.4pre:

_Z13DummyFunction10tTestEnum2:
.LLFB2:
!#PROLOGUE# 0
!#PROLOGUE# 1
add %o0, -2, %o0
cmp %o0, 1
bgu .LL2
mov 0, %g1
mov 2, %g1
.LL2:
retl
mov %g1, %o0
.LLFE2:
.size   _Z13DummyFunction10tTestEnum2, .-_Z13DummyFunction10tTestEnum2
.ident  "GCC: (GNU) 3.4.4 20050224 (prerelease)"

-- 
Eric Botcazou

[Bug rtl-optimization/20211] New: autoincrement generation is poor

[amylaar at gcc dot gnu dot org]

When a processor does not allow register+offset addressing for a register
class, as for the floating point registers on the SH3E / SH4, the way to
avoid excessive reloads and to expose the issue to the rtl optimizers is
to disallow this addressing mode for the machine modes for which pseudo
registers are usually allocated to the register class in question, i.e.
SFmode / DFmode in our example.
Thus, when there is a structure access to a member with such a mode and a
non-zero offset, the address cannot be expressed directly, and thus,
during rtl expansion, the sum is calculated into a pseudo register first.
cse typically places these additions together at the start of a basic
block; the idea there is that we might find some cse opportunities, and
if not, combine can do something with these sums.  However, that doesn't
work when these sums are used as addresses and the machine mode of the
access does not allow reg+offset addressing.  The auto-increment generation
is flow can't do anything useful with these sums either, since the auto-inc
generation in flow only looks for cases where a memory access already matches
an exitsing add.  Thus we end up with lots of adds and sky-high register
pressure.  On two-address machines, there i an added problem that the
adds are so arranged that (at least, not counting reloads...) a
two-instruction sequence is needed to do the additions.

What is required is an optimization pass that finds all the uses of a sum
of a base register and an offset in a basic block, and figures out where an
auto-increment addressing mode can be profitably used, and also to reduce the
register pressure and number of reg-reg copies.

A patch against 4.0 20050218 is here:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01612.html

-- 
   Summary: autoincrement generation is poor
   Product: gcc
   Version: 2.95
Status: UNCONFIRMED
  Keywords: missed-optimization, patch
  Severity: enhancement
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
OtherBugsDependingO 17652
 nThis:


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

[Bug other/17652] [meta-bug] GCC 4.1 pending patches

[amylaar at gcc dot gnu dot org]

-- 
   What|Removed |Added

  BugsThisDependsOn||20211


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

[Bug tree-optimization/20204] [4.0 regression] miscompilation of asm-declared registers

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2005-02-25 16:05 
---
I've confirmed on this other machine that the update caused the same breakage.


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-25 16:05:49
   date||


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

signed enum bug

[Aaron Coleman]

[My first time at reporting, so please bear with me if I do something wrong...]
 
The compiler outputs a bg branch instruction when it should use a bgu. The 
cause seems to be related to having a negative value in the enumeration. If I 
just comment out the DummyValue1 line, the code is correct. It does this at any 
optimization level of 1 or higher, and I haven't figured out if there is a 
specific optimization I can turn off as a work around.
 
  add   %o0, -2, %o0
  cmp   %o0, 1
  .stabn 68,0,13,.LLM3-_Z13DummyFunction10tTestEnum2
.LLM3:
  .stabn 68,0,15,.LLM4-_Z13DummyFunction10tTestEnum2
.LLM4:
  bg    .LL2
  mov   0, %o0
  .stabn 68,0,16,.LLM5-_Z13DummyFunction10tTestEnum2
.LLM5:
  mov   2, %o0
.LL2:
.LLBE3:
.LLBE2:
  retl
  nop
 
 
 
Thanks,
Aaron Coleman
Software Engineering Manager
Lowrance Electronics, Inc.
12000 E Skelly Dr.
Tulsa, OK 74128
918-437-6881 x8551
 


test.ii
Description: test.ii
Reading specs from /compilers/sparc-elf/lib/gcc/sparc-elf/3.4.0/specs
Configured with: /gcc_src/gcc-3.4-20040317/configure 
--prefix=/compilers/sparc-elf --target=sparc-elf --enable-languages=c++ 
--with-newlib --enable-clocale=generic --enable-cxx-flags=-fno-exceptions 
--disable-hosted-libstdcxx
Thread model: single
gcc version 3.4.0 20040317 (prerelease)
 /compilers/sparc-elf/libexec/gcc/sparc-elf/3.4.0/cc1plus.exe -E -quiet -v 
-D__sparc_v8__ -D__sparc_v8__ test.cpp -mcpu=v8 -mcpu=v8 -mtune=v8 -mv8 -m32 
-Werror -Wall -fworking-directory -O1 -o test.ii
ignoring nonexistent directory 
"/compilers/sparc-elf/lib/gcc/sparc-elf/3.4.0/../../../../include/c++/3.4.0/backward"
ignoring nonexistent directory 
"/compilers/sparc-elf/lib/gcc/sparc-elf/3.4.0/../../../../sparc-elf/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /compilers/sparc-elf/lib/gcc/sparc-elf/3.4.0/../../../../include/c++/3.4.0
 
/compilers/sparc-elf/lib/gcc/sparc-elf/3.4.0/../../../../include/c++/3.4.0/sparc-elf
 /compilers/sparc-elf/lib/gcc/sparc-elf/3.4.0/include
 /compilers/sparc-elf/lib/gcc/sparc-elf/3.4.0/../../../../sparc-elf/include
End of search list.
 /compilers/sparc-elf/libexec/gcc/sparc-elf/3.4.0/cc1plus.exe -fpreprocessed 
test.ii -mcpu=v8 -quiet -dumpbase test.cpp -mcpu=v8 -mtune=v8 -mv8 -m32 
-auxbase-strip test.o -g -O1 -Werror -Wall -version -o test.s
GNU C++ version 3.4.0 20040317 (prerelease) (sparc-elf)
compiled by GNU C version 3.3.1 (cygming special).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 /compilers/sparc-elf/lib/gcc/sparc-elf/3.4.0/../../../../sparc-elf/bin/as.exe 
-V -Qy -s -o test.o test.s
GNU assembler version 040202 (sparc-elf) using BFD version 040202 20040202

[Bug tree-optimization/20204] [4.0 regression] miscompilation of asm-declared registers

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2005-02-25 15:59 
---
I was lucky enough to have a source tree from just before the suspected change
in the machine where I test using geoffk's script.  (It's a RH9 machine as
opposed to FC2, so thus we can supposedly also rule out miscompilation by the
host gcc.)  I have updated just the suspected change.  Test in progress.

-- 


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

[Bug target/16350] gcc only understands little endian ARM systems

[vapier at gentoo dot org]

--- Additional Comments From vapier at gentoo dot org  2005-02-25 15:49 
---
this also applies pretty nicely to 3.3.5, 3.4.2, 3.4.3, and even gcc cvs HEAD :(

one question though ... going by config/arm/arm.h, wouldnt you want to
use this logic instead ?
#if TARGET_BIG_ENDIAN_DEFAULT
#define TARGET_ENDIAN_DEFAULT ARM_FLAG_BIG_END
#else
#define TARGET_ENDIAN_DEFAULT -ARM_FLAG_BIG_END
#endif

granted i havent fully tested this change from '0' to '-ARM_FLAG_BIG_END',
but it *seems* to work :)

also, what do we have to do in order to get this into mainline gcc ?
this simple patch has been hanging around for a while :/

-- 


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

[Bug c++/20207] null constructor not needed in multiple inheritance

[Serge dot Iovleff at univ-lille1 dot fr]

--- Additional Comments From Serge dot Iovleff at univ-lille1 dot fr  
2005-02-25 15:43 ---
(In reply to comment #1)
> I think this is invalid code but I don't know how to produce it right now.
Yes you can add an explicit call to the constructor of A0 in B and C,
in this case the error deseappear.

hovewer, as B and C are abstract virtual class, this constructor should never be
called by these class, but only by the derived class, like D.


-- 


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

[Bug tree-optimization/20210] asm "=m" not taken into account

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
15:35 ---
This is a dup of bug 20188 which I am testing a patch for already.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/20188] [4.0 Regression] asm and memory operands does not add a V_MAY_DEF

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
15:35 ---
*** Bug 20210 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||jakub at gcc dot gnu dot org


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

[Bug tree-optimization/20204] [4.0 regression] miscompilation of asm-declared registers

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2005-02-25 15:35 
---
In response to comment #6:
Building a CRIS toolchain with simulator (but see further below):
The general steps are exactly as any other simulator target,
follow http://gcc.gnu.org/simtest-howto.html>, though you need
the cris-sim.exp as per
http://gcc.gnu.org/ml/gcc-bugs/2005-02/msg00138.html>
(now in dejagnu CVS; not on sourceware).  Because the baseboard file
is not in the installed dir, special steps are necessary:
"mkdir ~/dejagnuboards"
Put cris-sim.exp in ~/dejagnurc
"echo 'set boards_dir ~/dejagnuboards' > ~/.dejagnurc"
Then proceed as per simtest-howto.html

But you actually just need to build cc1 and observe the assembly I posted.

And again, I think I need to point out that a bug in handling of
*asm-declared registers* is unlikely to show "widespread carnage".
But I certainly see how it can be overlooked and broken in tree-ssa
cleanup operations!

I have not tried reverting the patch but will do later, hoping it can
convince you that the "reorganization" caused this regression (whether
directly or indirectly exposing bugs elsewhere).


-- 


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

[Bug tree-optimization/20210] New: asm "=m" not taken into account

[jakub at gcc dot gnu dot org]

The following testcase is miscompiled on {powerpc,i386,x86_64}-redhat-linux
(well, any other for which an __asm is written).

extern void abort (void);

unsigned short v = 0x0300;

void
foo (unsigned short *p)
{
  *p = v;
}

int
bar (void)
{
  unsigned short x;
  volatile unsigned short *z;
  foo (&x);
  const unsigned int y = x;
  z = &x;
#ifdef __powerpc__
  __asm __volatile ("sthbrx %1,0,%2" : "=m" (*z) : "r" (y), "r" (z));
#elif defined __i386__ || defined __x86_64__
  __asm __volatile ("movb %b1,1(%2); movb %h1,(%2)" : "=m" (*z) : "r" (y), "r"
(z));
#endif
  return (x & 1) == 0;
}

int
main (void)
{
  if (bar ())
abort ();
  return 0;
}

In final_cleanup, bar is:
bar ()
{
  const unsigned intD.3 yD.1507;
  short unsigned intD.8 xD.1505;

  # BLOCK 0
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  #   xD.1505_11 = V_MAY_DEF ;
  foo (&xD.1505);
  yD.1507 = (const unsigned intD.3) xD.1505;
  #   xD.1505_12 = V_MAY_DEF ;
  __asm__ __volatile__("movb %b1,1(%2); movb %h1,(%2)":"=m" xD.1505:"r" yD.1507,
"r" &xD.1505);
  return (intD.0) (yD.1507 ^ 1) & 1;
  # SUCC: EXIT [100.0%]

}

which is wrong, it must reread xD.1505 instead of assuming xD.1505 == yD.1507.

-- 
   Summary: asm "=m" not taken into account
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,mikpe at csd dot uu dot
se


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

[Bug tree-optimization/20188] [4.0 Regression] asm and memory operands does not add a V_MAY_DEF

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
15:17 ---
(In reply to comment #13)
> (In reply to comment #12)
> This is the right fix.  Could you bootstrap and test it?  A test case for this
> would need a dg-scan test for two 'if ()' statements (i.e., we should not 
> value
> number the second if() out).
Will do.

-- Pinski

-- 
   What|Removed |Added

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


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

[Bug c++/20207] null constructor not needed in multiple inheritance

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
15:10 ---
I think this is invalid code but I don't know how to produce it right now.

-- 


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

[Bug inline-asm/20202] asm("movq %0, %mm0" : : "X"(*a)) generates invalid asm code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
15:07 ---
'X' means "Any operand whatsoever is allowed." so %eax there is fine.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/20188] [4.0 Regression] asm and memory operands does not add a V_MAY_DEF

[dnovillo at gcc dot gnu dot org]

--- Additional Comments From dnovillo at gcc dot gnu dot org  2005-02-25 
15:04 ---
(In reply to comment #12)

> if (lhs && (TREE_CODE (lhs) == TREE_LIST || EXPR_P (lhs))
> will works for everyone, it works for this testcase too but I have not
> bootstrapped or tested it yet.
>
This is the right fix.  Could you bootstrap and test it?  A test case for this
would need a dg-scan test for two 'if ()' statements (i.e., we should not value
number the second if() out).


Thanks.  Diego.

-- 


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

[Bug c++/20209] [3.3/3.4/4.0 Regression] Missing warnings for "aggregate has a partly bracketed initializer"

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
15:04 ---
Obviously I compiled with "-W -Wall".
I wonder how this regression was missed for so long.

-- 
   What|Removed |Added

  Known to fail||3.3.3 3.4.0 4.0.0
  Known to work||3.2.3


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

[Bug c++/20209] [3.3/3.4/4.0 Regression] Missing warnings for "aggregate has a partly bracketed initializer"

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |3.4.4


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

[Bug c++/20175] [3.4 Regression] Warnings are issued when initializing struct members with "strings"

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
15:02 ---
(In reply to comment #6)
> (In reply to comment #3)
> > Patch here: 
> 
> This fixes the obvious case but it also makes the following pass with no
> warnings and that is wrong, note especially S1 and S3!
That looks like a different bug, I am filing a new bug for this (PR 20209).

-- 


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

[Bug c++/20209] New: [3.3/3.4/4.0 Regression] Missing warnings for "aggregate has a partly bracketed initializer"

[pinskia at gcc dot gnu dot org]

The following should have warnings:
struct S { char a[6]; int b[2]; };

S S0 = { { "hello" }, { 1, 2 } };
S S1 = { { "hello" }, 1, 2 }; // { dg-warning "" }
S S2 = { "hello", { 1, 2 } };
S S3 = { "hello", 1, 2 }; // { dg-warning "" }

-- 
   Summary: [3.3/3.4/4.0 Regression] Missing warnings for "aggregate
has a partly bracketed initializer"
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/20175] [3.4 Regression] Warnings are issued when initializing struct members with "strings"

[gcc at magfr dot user dot lysator dot liu dot se]

--- Additional Comments From gcc at magfr dot user dot lysator dot liu dot 
se  2005-02-25 14:55 ---
(In reply to comment #3)
> Patch here: 

This fixes the obvious case but it also makes the following pass with no
warnings and that is wrong, note especially S1 and S3!

struct S { char a[6]; int b[2]; };

S S0 = { { "hello" }, { 1, 2 } };
S S1 = { { "hello" }, 1, 2 }; // Highly suspicious
S S2 = { "hello", { 1, 2 } };
S S3 = { "hello", 1, 2 }; // Highly suspicious


-- 


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

[Bug c++/20208] [4.0 Regression] No array-to-pointer decay happens for template functions

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


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

[Bug c++/2892] No array-to-pointer decay happens for template functions

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  BugsThisDependsOn||20208


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

[Bug c++/20208] New: [4.0 Regression] No array-to-pointer decay happens for template functions

[pinskia at gcc dot gnu dot org]

At -O1 and above, the following code ICE because well, the same reason why PR 
2892 fails currently 
really:
extern "C" void abort();

template 
inline void *Foo (T arg) { return &arg[0]; }

int main () {
  int bry[2];
  if (Foo(bry) != bry)
abort();
}

I filed this a seperate bug because well the ICE is a regression even though 
fixing PR 2892 will fix this 
also.

-- 
   Summary: [4.0 Regression] No array-to-pointer decay happens for
template functions
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
OtherBugsDependingO 2892
 nThis:


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

[Bug c++/20207] New: null constructor not needed in multiple inheritance

[Serge dot Iovleff at univ-lille1 dot fr]

In a "dreaded" diamon hierarchy
  A0
  |
  A
 / \
B   C
 \ /
  D

I get a request for a default constructor for A0 from the compiler
(gcc 3.4.4 )

If I drop A0, the error desappear.

testtemplate2.cpp: In constructor `B::B(int) [with TYPE = int]':
testtemplate2.cpp:57:   instantiated from `D::D(int) [with TYPE =
int]'::A0() »
testtemplate2.cpp:64:   instantiated from here::A0(const A0&)
testtemplate2.cpp:37: erreur: pas de fonction concordante pour l'appel à «
A0::A0() »
testtemplate2.cpp:15: note: candidats sont: A0::A0(const A0&)
testtemplate2.cpp:18: note: A0::A0(TYPE) [with TYPE = int]
testtemplate2.cpp: In constructor `C::C(int) [with TYPE = int]':
testtemplate2.cpp:57:   instantiated from `D::D(int) [with TYPE = int]'
testtemplate2.cpp:64:   instantiated from here
testtemplate2.cpp:47: erreur: pas de fonction concordante pour l'appel à «
A0::A0() »
testtemplate2.cpp:15: note: candidats sont: A0::A0(const A0&)
testtemplate2.cpp:18: note: A0::A0(TYPE) [with TYPE = int]



template
class A0
{ protected:
const int n;
  public:
 A0(TYPE a ) : n(a) { ;}
~A0() { ;}
virtual void foo() =0;
};

template
class A : public virtual A0
{
  public:
 A(TYPE a ) : A0(a) { ;}
~A() { ;}
virtual void foo() =0;
};

template
class B : public virtual A
{
  public:
 B(int b= 0) : A(b)
 { ;}
~B() { ;}
virtual void foo() =0;
};

template
class C : public virtual A
{
  public:
 C(int c= 0) : A(c)
 { ;}
~C() { ;}
virtual void foo() =0;
};

template
class D : public virtual B, public virtual C
{
  public:
 D(int d= 0) : A0(d), A(d), B(d), C(d)
 { ;}
~D() { ;}
virtual void foo() { ;}
};

int main(int argc, char *argv[])
{
  D d(4);
}

-- 
   Summary: null constructor not needed in multiple inheritance
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Serge dot Iovleff at univ-lille1 dot fr
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests

[rearnsha at gcc dot gnu dot org]

--- Additional Comments From rearnsha at gcc dot gnu dot org  2005-02-25 
14:07 ---
The build fails:

rm -fr .libs/libgcj.lax/libgcjgc_convenience.a
mkdir .libs/libgcj.lax/libgcjgc_convenience.a
(cd .libs/libgcj.lax/libgcjgc_convenience.a &&
/work/rearnsha/gnu/egcs/binutils/ar x
/work/rearnsha/gnu/egcs/arm-elf/thumb/libjava/../boehm-gc/.libs/libgcjgc_convenience.a)
copying selected object files to avoid basename conflicts...
rm -fr .libs/libgcj.lax
mkdir .libs/libgcj.lax
cp org/ietf/jgss/MessagesBundle.properties.o
.libs/libgcj.lax/lt1-MessagesBundle.properties.o
cp .libs/libgcj.lax/libgcj0_convenience.a/EventListener.o
.libs/libgcj.lax/lt2-EventListener.o
cp: cannot stat `.libs/libgcj.lax/libgcj0_convenience.a/EventListener.o': No
such file or directory
cp .libs/libgcj.lax/libgcj0_convenience.a/ContentHandler.o
.libs/libgcj.lax/lt3-ContentHandler.o
cp: cannot stat `.libs/libgcj.lax/libgcj0_convenience.a/ContentHandler.o': No
such file or directory
cp .libs/libgcj.lax/libgcj0_convenience.a/Attributes.o
.libs/libgcj.lax/lt4-Attributes.o
cp: cannot stat `.libs/libgcj.lax/libgcj0_convenience.a/Attributes.o': No such
file or directory

etc.

Incidentally, wouldn't it be more efficient to use links (either hard or soft)
rather than doing a copy?

-- 
   What|Removed |Added

 AssignedTo|aoliva at gcc dot gnu dot   |rearnsha at gcc dot gnu dot
   |org |org
 Status|WAITING |ASSIGNED
   Last reconfirmed|2005-02-24 22:01:51 |2005-02-25 14:07:21
   date||


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

[Bug tree-optimization/20204] [4.0 regression] miscompilation of asm-declared registers

[dnovillo at gcc dot gnu dot org]

--- Additional Comments From dnovillo at gcc dot gnu dot org  2005-02-25 
13:31 ---

Could you show me how to configure a cris-axis-elf target and build a 
simulator?  
Have you tried undoing the tree-into-ssa.c change?  It should be easy with:

$ cvs up -r 2.40 tree-into-ssa.c

If there had been a bug in the tree-into-ssa.c changes we would be seeing
widespread carnage on every target.  And that is just not the case:

http://gcc.gnu.org/ml/gcc-testresults/2005-02/msg01103.html
http://gcc.gnu.org/ml/gcc-testresults/2005-02/msg01100.html
http://gcc.gnu.org/ml/gcc-testresults/2005-02/msg01101.html

Diego.

-- 


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

[Bug target/20203] [4.0 Regression] unrecognizable insn building binutils

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
12:39 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug c++/20206] [4.0 Regression] COMDAT broken for C++ thunks

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|normal  |critical
   Keywords||wrong-code


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

[Bug c++/20195] [4.0 Regression] Internal compiler error on legal code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
12:33 ---
So lets close it as fixed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
Summary|Internal compiler error on  |[4.0 Regression] Internal
   |legal code  |compiler error on legal code
   Target Milestone|--- |4.0.0


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

[Bug rtl-optimization/20117] [4.0 Regression] duplicated labels in PIC

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-25 
12:32 ---
Fixed in 4.0.0 (before the branch) so closing as fixed.

-- 
   What|Removed |Added

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


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