[Bug fortran/30452] Strange syntax error with high-value character

[Thomas dot Koenig at online dot de]

--- Comment #3 from Thomas dot Koenig at online dot de  2007-01-13 08:42 
---
Subject: Re:  Strange syntax error with high-value character

jvdelisle at gcc dot gnu dot org wrote:

> Turns out that the character 254 which is Hex FE is also the 2's complement
> representation of -2 which is what is used to signal an error if there is a
> missing delimiter.  It should not be converting this to an int -2

Same thing happens for character 255, BTW.


-- 


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

Where did you get so small prick?

[Janosevic Maria]

Salute Man

Don't tell me why your schlong is so small,
I will better help you to make it really Bigger!

Why bigger? Because over 74% of all women need a longer
one-eyed monster to satisfy their desire!

Go there and get your solution: http://www.nattiaho.com

It'll really help you!

We will ship it worldwide within 24 hours, and if
you find our product useless - we'll refund all your money!



--
piultfugqpuuupuosququtusqgrmrusmnsrqsmrg
dfkjghwenflgkdwdfwkjgghs
These words were  so unexpected and so absurd that Stepa decided he had
not heard them. In utter bewilderment he bounded back  into the bedroom  and
froze on the threshold.  His  hair  rose and a  mild sweat broke out on  his
forehead.
The visitor was no longer alone in the bedroom. The second armchair was
now occupied by the creature who had materialised in the hall. He was now to
be seen  quite  plainly--feathery  moustache,  one  lens  of  his  pince-nez
glittering, the  other missing. But  worst of all wa:s the third invader : a
black cat of revolting proportions sprawled in a nonchalant attitude on  the
pouffe, a glass of vodka in one paw and a fork, on which he had just speared

[Bug fortran/30452] Strange syntax error with high-value character

[Thomas dot Koenig at online dot de]

--- Comment #4 from Thomas dot Koenig at online dot de  2007-01-13 11:51 
---
Subject: Re:  Strange syntax error with high-value character

jvdelisle at gcc dot gnu dot org wrote:

> Turns out that the character 254 which is Hex FE is also the 2's complement
> representation of -2 which is what is used to signal an error if there is a
> missing delimiter.  It should not be converting this to an int -2

Here's a patch which fixes the testcase.

Currently regtesting.


--- Comment #5 from Thomas dot Koenig at online dot de  2007-01-13 11:51 
---
Created an attachment (id=12895)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12895&action=view)


-- 


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

[Bug libstdc++/14991] stream::attach(int fd) porting entry out-of-date

[pcarlini at suse dot de]

-- 

pcarlini at suse dot de changed:

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

[Bug libstdc++/14991] stream::attach(int fd) porting entry out-of-date

[paolo at gcc dot gnu dot org]

--- Comment #2 from paolo at gcc dot gnu dot org  2007-01-13 12:24 ---
Subject: Bug 14991

Author: paolo
Date: Sat Jan 13 12:24:02 2007
New Revision: 120749

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120749
Log:
2007-01-13  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/14991
* docs/html/17_intro/porting-howto.html ([3]): Mention stdio_filebuf.
* docs/html/17_intro/porting-howto.xml: Remove.

* docs/html/17_intro/porting-howto.html: Remove spurious end tags
pointed out by validator.w3.org.

Removed:
trunk/libstdc++-v3/docs/html/17_intro/porting-howto.xml
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/docs/html/17_intro/porting-howto.html


-- 


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

[Bug libstdc++/14991] stream::attach(int fd) porting entry out-of-date

[paolo at gcc dot gnu dot org]

--- Comment #3 from paolo at gcc dot gnu dot org  2007-01-13 12:24 ---
Subject: Bug 14991

Author: paolo
Date: Sat Jan 13 12:24:20 2007
New Revision: 120750

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120750
Log:
2007-01-13  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/14991
* docs/html/17_intro/porting-howto.html ([3]): Mention stdio_filebuf.
* docs/html/17_intro/porting-howto.xml: Remove.

* docs/html/17_intro/porting-howto.html: Remove spurious end tags
pointed out by validator.w3.org.

Removed:
branches/gcc-4_2-branch/libstdc++-v3/docs/html/17_intro/porting-howto.xml
Modified:
branches/gcc-4_2-branch/libstdc++-v3/ChangeLog
branches/gcc-4_2-branch/libstdc++-v3/docs/html/17_intro/porting-howto.html


-- 


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

[Bug libstdc++/14991] stream::attach(int fd) porting entry out-of-date

[pcarlini at suse dot de]

--- Comment #4 from pcarlini at suse dot de  2007-01-13 12:25 ---
Fixed for 4.2.0.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

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


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

[Bug fortran/30367] gfortran compile times excessive with -Wall

[Bil dot Kleb at NASA dot gov]

--- Comment #3 from Bil dot Kleb at NASA dot gov  2007-01-13 12:35 ---
I've just tried to duplicate the compile time difference with -Wall and found
that the -Wall was a red herring -- it always takes 169 minutes to compile our
code with gfortran, -Wall or not.

This is about 8 times longer than any other compiler, even with the SGI
compiler running on hardware that is an order of magnitude slower than the
hardware gfortran is running on.

Our current compiler guantlet includes: Absoft-10.0.3, NAG-5.1.282, g95-0.91,
PGI-6.2.4, Sun-8.3.35_2, gfortran-20070103, ifort-9.1.040, SGI-7.41,
LaheyX-6.10a, and LaheyX-8.00a.  (Where -O0 is the only compiler option
specified for all compilers.)

Gfortran's compilation time is mainly due to a three routines that take on the
order of 1/2 hour each. These routines are long (~10KLOC) and compute large
Jacobian matrices formed from many temporary variables.


-- 


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

[Bug target/8512] [hppa64-hp-hpux11.11] libstdc++-v3 fails to build with HP assembler

[danglin at gcc dot gnu dot org]

--- Comment #11 from danglin at gcc dot gnu dot org  2007-01-13 16:01 
---
The problem reported in the PR is fixed in 4.0.  Other issues that
prevented building libstdc++-v3 using HP as are fixed in 4.0.4 by
these two changes:

http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01060.html
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01138.html


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/28451] [4.0/4.1/4.2/4.3 regression] ICE with invalid default template parameter

[reichelt at gcc dot gnu dot org]

--- Comment #2 from reichelt at gcc dot gnu dot org  2007-01-13 17:08 
---
This seems to be a duplicate of PR29573, as it was fixed by the same patch.


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


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/29573] [4.0/4.1/4.2 regression] ICE after parse error in template argument

[reichelt at gcc dot gnu dot org]

--- Comment #4 from reichelt at gcc dot gnu dot org  2007-01-13 17:08 
---
*** Bug 28451 has been marked as a duplicate of this bug. ***


-- 


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

[Bug target/30406] ICE in LOGICAL(8) functions

[dominiq at lps dot ens dot fr]

--- Comment #24 from dominiq at lps dot ens dot fr  2007-01-13 17:09 ---
I have applied the change to the latest snapshot (4.3.0 20070112) and the tests
compile now without error on OSX 10.3.9.

Thanks.


-- 


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

[Bug fortran/30367] gfortran compile times excessive with -Wall

[kargl at troutmask dot apl dot washington dot edu]

--- Comment #4 from kargl at troutmask dot apl dot washington dot edu  
2007-01-13 17:23 ---
Subject: Re:  gfortran compile times excessive with
 -Wall

Bil dot Kleb at NASA dot gov wrote:
> 
> Gfortran's compilation time is mainly due to a three routines that take on the
> order of 1/2 hour each. These routines are long (~10KLOC) and compute large
> Jacobian matrices formed from many temporary variables.
> 

Do these routines use a large number of modules?
Any possibility of sending one of the problematic
routines to us to profile the compiler?  Can you
run "gfortran -S -fmem-report -ftime-report" with
one of the files and attach the info here?


-- 


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

[Bug c/28492] -Wmissing-format-attribute causes warning for vsnprintf()

[h dot b dot furuseth at usit dot uio dot no]

--- Comment #1 from h dot b dot furuseth at usit dot uio dot no  2007-01-13 
18:40 ---
The warning is a bit misleading,
  "function might be possible candidate for 'printf' format attribute"
means the _calling_ function might be such a candidate, not the function
being called on the line it warns about.

The warning is still spurious in this case though, and gcc could tell that:
A function cannot be such a candidate if it has a prototype without variable
arguments.  Here is another example of such a spurious warning:

Hallvard


-- 

h dot b dot furuseth at usit dot uio dot no changed:

   What|Removed |Added

 CC||h dot b dot furuseth at usit
   ||dot uio dot no


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

[Bug fortran/30452] Strange syntax error with high-value character

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2007-01-13 18:45 
---
Assuming this regression tests OK, I think this is an "obvious and simple" 
Thanks :)


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c/30456] New: tgmath.h not found

[schnetter at aei dot mpg dot de]

It seems that tgmath.h is not available on Darwin:

$ gcc-dp-4.2 -std=gnu99 -Wall -o complex complex.c 
complex.c:3:20: error: tgmath.h: No such file or directory

$ gcc-dp-4.2 --version
gcc-dp-4.2 (GCC) 4.2.0 20060729 (experimental)

There is no file tgmath.h provided with the compiler that could be installed (I
checked revision 120754).  There is a file tgmath.h that ships as part of
libstdc++, but this is only a C++ wrapper.

tgmath.h exists in glibc, but my system does not use glibc.  Naively trying to
use this file leads to a syntax error on the line containing
#if __GNUC_PREREQ (2, 7)

I found a discussion on the gcc mailing list from August 2004 which discusses
this topic: . 
Apparently there was a somewhat heated discussion on whether it would be useful
or appropriate to include tgmath.h with the compiler.

Since my operating system does not have a tgmath.h, I would like to argue that
gcc should "fixinclude" it by providing a fallback implementation.

By the way,  marks tgmath.h as "done".


-- 
   Summary: tgmath.h not found
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schnetter at aei dot mpg dot de
 GCC build triplet: i386-apple-darwin8.7.1
  GCC host triplet: i386-apple-darwin8.7.1
GCC target triplet: i386-apple-darwin8.7.1


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

[Bug c/30457] New: Please warn about va_start(ap, invalid)

[h dot b dot furuseth at usit dot uio dot no]

Here is some undefined behavior which it would be nice if gcc
warned about, since stdarg is such a hairy part of the standard:

#include 

void foo(register short paramN, ...)
{
  va_list ap;

  va_start(ap, paramN); // Undefined by C99 7.15.1.4p4 (va_start):
  // "If the parameter parmN is declared with the register storage
  //  class, with a function or array type, or with a type that is
  //  not compatible with the type that results after application of
  //  the default argument promotions, the behavior is undefined."

  // gcc does warn about the following, undefined by C99 7.15.1.1p2:
  (void) va_arg(ap, char);
  // "warning: 'char' is promoted to 'int' when passed through '...'
  //  warning: (so you should pass 'int' not 'char' to 'va_arg')
  //  note: if this code is reached, the program will abort"

  va_end(ap);
}


-- 
   Summary: Please warn about va_start(ap, invalid)
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
 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=30457

[Bug c/30456] tgmath.h not found

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-01-13 18:58 ---
tgmath.h is not required to be provided by a freestanding compiler so we don't
include it.
Read: http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00921.html

Which is the follow up by JSM on this matter.

We will not fix this as the libc should provide it.

And no GCC should not fixincludes a version of your OS.  Your OS should provide
one.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug fortran/30435] Slash at end of input not recognized according to standard

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2007-01-13 19:08 
---
Subject: Bug 30435

Author: jvdelisle
Date: Sat Jan 13 19:08:40 2007
New Revision: 120755

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120755
Log:
2007-01-13  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libgfortran/30435
* io/list_read.c (finish_separator): Don't call next_record.
(list_formatted_read_scalar): Clean up some comments and whitespace.
(nml_read_obj): Whitespace fix.

Modified:
branches/gcc-4_2-branch/libgfortran/ChangeLog
branches/gcc-4_2-branch/libgfortran/io/list_read.c


-- 


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

[Bug fortran/30435] Slash at end of input not recognized according to standard

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2007-01-13 19:11 
---
Subject: Bug 30435

Author: jvdelisle
Date: Sat Jan 13 19:11:02 2007
New Revision: 120756

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120756
Log:
2007-01-13  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libgfortran/30435
* gfortran.dg/list_read_6.f90: New test.

Added:
branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/list_read_6.f90
Modified:
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug testsuite/12325] gcc.dg/torture/builtin-attr-1.c assumes all targets support inf

[ghazi at gcc dot gnu dot org]

--- Comment #2 from ghazi at gcc dot gnu dot org  2007-01-13 19:43 ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01146.html

Confirm that it cures the testcase on a vax would be nice...


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ghazi at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-10-30 17:26:06 |2007-01-13 19:43:44
   date||


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

[Bug fortran/30435] Slash at end of input not recognized according to standard

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2007-01-13 21:00 
---
Subject: Bug 30435

Author: jvdelisle
Date: Sat Jan 13 21:00:31 2007
New Revision: 120758

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120758
Log:
2007-01-13  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libgfortran/30435
* io/list_read.c (finish_separator): Don't call next_record.
(list_formatted_read_scalar): Clean up some comments and whitespace.
(nml_read_obj): Whitespace fix.

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


-- 


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

[Bug fortran/30435] Slash at end of input not recognized according to standard

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2007-01-13 21:03 
---
Subject: Bug 30435

Author: jvdelisle
Date: Sat Jan 13 21:03:17 2007
New Revision: 120759

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120759
Log:
2007-01-13  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libgfortran/30435
* gfortran.dg/list_read_6.f90: New test.

Added:
branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/list_read_6.f90
Modified:
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/30435] Slash at end of input not recognized according to standard

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2007-01-13 21:05 
---
Fixed on 4.1, 4.2, and 4.3

Drew, thanks for reporting this bug.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/30367] gfortran compile times excessive with -Wall

[Bil dot Kleb at NASA dot gov]

--- Comment #5 from Bil dot Kleb at NASA dot gov  2007-01-13 21:11 ---
Created an attachment (id=12896)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12896&action=view)
Entire compilation log with -fmem-report -ftime-report turned on

The trouble routines are part of the Adjoint code:

 residual_turbpart.f90
 residual_turbulent.f90
 precond_turbpart.f90
 precond_turbulent.f90


-- 


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

[Bug tree-optimization/30440] internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:1472

[jasonmbechtel at gmail dot com]

--- Comment #8 from jasonmbechtel at gmail dot com  2007-01-13 21:11 ---
I filed the bug with Ubuntu.  It is bug #79132:

https://launchpad.net/ubuntu/+source/gcc-defaults/+bug/79132


-- 


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

[Bug fortran/30367] gfortran compile times excessive with -Wall

[Bil dot Kleb at NASA dot gov]

--- Comment #6 from Bil dot Kleb at NASA dot gov  2007-01-13 21:12 ---
Created an attachment (id=12897)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12897&action=view)
Lakos-style use associations for residual_turbpart.f90


-- 


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

[Bug tree-optimization/30440] internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:1472

[jasonmbechtel at gmail dot com]

--- Comment #9 from jasonmbechtel at gmail dot com  2007-01-13 21:12 ---
I also noticed while recreating the bug for the Ubuntu submission that I made a
mistake in my original bug report here.  It should be

  cd Situs_2.2.1/src
  make all

(Note the "/src".)


-- 


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

[Bug fortran/30367] gfortran compile times excessive with -Wall

[Bil dot Kleb at NASA dot gov]

--- Comment #7 from Bil dot Kleb at NASA dot gov  2007-01-13 21:13 ---
Created an attachment (id=12898)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12898&action=view)
Lakos-style use associations for residual_turbulent.f90


-- 


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

[Bug fortran/30367] gfortran compile times excessive with -Wall

[Bil dot Kleb at NASA dot gov]

--- Comment #8 from Bil dot Kleb at NASA dot gov  2007-01-13 21:13 ---
Created an attachment (id=12899)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12899&action=view)
Lakos-style use associations for precond_turbpart.f90


-- 


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

[Bug fortran/30367] gfortran compile times excessive with -Wall

[Bil dot Kleb at NASA dot gov]

--- Comment #9 from Bil dot Kleb at NASA dot gov  2007-01-13 21:14 ---
Created an attachment (id=12900)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12900&action=view)
Lakos-style use associations for precond_turbulent.f90


-- 


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

[Bug fortran/30367] gfortran compile times excessive with -Wall

[Bil dot Kleb at NASA dot gov]

--- Comment #10 from Bil dot Kleb at NASA dot gov  2007-01-13 21:17 ---
Based on the Lakos-style analysis of the dependencies for these particular
routines, it /might/ be possible to supply self-contained source; but it will
take a while to check with the powers that be.


-- 


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

[Bug c++/30458] New: ice for legal code at -O3

[dcb314 at hotmail dot com]

I just tried to compile Suse Linux package bzflag-2.0.8-22
with the new GNU C compiler version 4.3 snapshot 20070112.

The compiler said

TimeBomb.cxx: In function 'bool timeBombBoom()':
TimeBomb.cxx:23: error: address taken, but ADDRESSABLE bit not set
timeBomb

TimeBomb.cxx:23: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

Preprocessed source code attached. Flag -O3 required.


-- 
   Summary: ice for legal code at -O3
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64_suse_linux


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

[Bug c++/30458] ice for legal code at -O3

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2007-01-13 21:22 ---
Created an attachment (id=12901)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12901&action=view)
C++ source code


-- 


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

[Bug fortran/30367] gfortran compile times excessive with -Wall

[Bil dot Kleb at NASA dot gov]

--- Comment #11 from Bil dot Kleb at NASA dot gov  2007-01-13 21:28 ---
Created an attachment (id=12902)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12902&action=view)
An excerpt from precond_turbulent.f90

Here's an excerpt from one of the offenders.  Note: the module only has a
single routine and it has a ridiculous amount of local variables...


-- 


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

[Bug rtl-optimization/30367] gfortran compile times excessive with -Wall

[pinskia at gcc dot gnu dot org]

--- Comment #12 from pinskia at gcc dot gnu dot org  2007-01-13 21:29 
---
 global alloc  :2249.91 (100%) usr   0.28 (76%) sys2250.16 (100%) wall 
  3897 kB (13%) ggc
 flow 2:   0.04 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
 447 kB ( 2%) ggc
 reg stack :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   7 kB ( 0%) ggc
 final :   0.12 ( 0%) usr   0.00 ( 0%) sys   0.12 ( 0%) wall   
   0 kB ( 0%) ggc
 TOTAL :2251.56 0.37  2251.91 
29616 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --disable-checking to disable checks.


But I note you have checking enabled so can you recompile GCC with
--enable-checking=release?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|fortran |rtl-optimization


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

[Bug c++/30458] ice for legal code at -O3

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-01-13 21:33 ---
Can you try after:
http://gcc.gnu.org/ml/gcc-cvs/2007-01/msg00460.html 

?


-- 


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

[Bug c++/30458] ice for legal code at -O3

[dcb314 at hotmail dot com]

--- Comment #3 from dcb314 at hotmail dot com  2007-01-13 21:38 ---
(In reply to comment #2)
> Can you try after:
> http://gcc.gnu.org/ml/gcc-cvs/2007-01/msg00460.html 

I can't process this until the next snapshot, due 20070119.

Is that soon enough ?


-- 


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

[Bug fortran/30367] gfortran compile times excessive for routines with large numbers of local variables

[Bil dot Kleb at NASA dot gov]

--- Comment #13 from Bil dot Kleb at NASA dot gov  2007-01-13 21:47 ---
Unfortunately, I am working from a binary release I got from 

 http://gcc.gnu.org/wiki/GFortranBinaries.

Specifically, I have the 03-Jan-2007 the 32-bit binary from:

 http://quatramaran.ens.fr/~coudert/gfortran/gfortran-linux.tar.gz

Is there an alternative binary available, or will I have to compile from
source?


-- 

Bil dot Kleb at NASA dot gov changed:

   What|Removed |Added

  Component|rtl-optimization|fortran
Summary|gfortran compile times  |gfortran compile times
   |excessive with -Wall|excessive for routines with
   ||large numbers of local
   ||variables


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

[Bug fortran/30283] Specification expression not properly recognized in declaration

[pault at gcc dot gnu dot org]

--- Comment #1 from pault at gcc dot gnu dot org  2007-01-13 22:12 ---
This looks quite easy:

  pure integer function bar (n)
integer, intent(in) :: n
bar = n
  end function bar

works. Somebody has forgotten to transfer the result typespec to that of the
specification expression.

Paul


-- 


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

[Bug rtl-optimization/30367] gfortran compile times excessive for routines with large numbers of local variables

[jvdelisle at gcc dot gnu dot org]

--- Comment #14 from jvdelisle at gcc dot gnu dot org  2007-01-13 22:13 
---
The binaries will be rebuilt in a few days.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|fortran |rtl-optimization


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

[Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory

[rguenth at gcc dot gnu dot org]

--- Comment #21 from rguenth at gcc dot gnu dot org  2007-01-13 23:02 
---
The patch fixed the freefem memory regression.


-- 


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

[Bug rtl-optimization/30455] i386 generates unnecessary TEST instructions for arithmetic ops on memory

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2007-01-13 23:27 ---
Addition (addl) operates in CCGOCmode and is not compatible with requested
CCZmode. Following that, test insn will be eliminated in this example:

int add_zf(int *x, int y, int a, int b)
{
 if ((*x + y) < 0)
  return a;
 else
  return b;
}

add_zf:
addl(%rdi), %esi
movl%edx, %eax
cmovns  %ecx, %eax
ret

However, having assignment to *x, we enter RTL generation with:

:
  D.1972 = *x;
  temp.27 = y + D.1972;
  *x = temp.27;
  if (temp.27 < 0) goto ; else goto ;

this gets expanded into:
;; D.1972 = *x
(insn 14 12 0 (set (reg:SI 59 [ D.1972 ])
(mem:SI (reg/v/f:DI 61 [ x ]) [2 S4 A32])) -1 (nil)
(nil))

;; temp.27 = y + D.1972
(insn 15 14 0 (parallel [
(set (reg:SI 58 [ temp.27 ])
(plus:SI (reg/v:SI 62 [ y ])
(reg:SI 59 [ D.1972 ])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))

;; *x = temp.27
(insn 16 15 0 (set (mem:SI (reg/v/f:DI 61 [ x ]) [2 S4 A32])
(reg:SI 58 [ temp.27 ])) -1 (nil)
(nil))

;; if (temp.27 < 0) goto ;
(insn 17 16 18 (set (reg:CCGOC 17 flags)
(compare:CCGOC (reg:SI 58 [ temp.27 ])
(const_int 0 [0x0]))) -1 (nil)
(nil))

Combine pass then creates:

(insn 15 14 16 2 (parallel [
(set (reg:SI 58 [ temp.27 ])
(plus:SI (reg/v:SI 62 [ y ])
(mem:SI (reg/v/f:DI 61 [ x ]) [2 S4 A32])))
(clobber (reg:CC 17 flags))
]) 207 {*addsi_1} (insn_list:REG_DEP_TRUE 6 (insn_list:REG_DEP_TRUE 7
(nil)))
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_DEAD (reg/v:SI 62 [ y ])
(nil

(insn 16 15 40 2 (set (mem:SI (reg/v/f:DI 61 [ x ]) [2 S4 A32])
(reg:SI 58 [ temp.27 ])) 40 {*movsi_1} (insn_list:REG_DEP_TRUE 15
(nil))
(expr_list:REG_DEAD (reg/v/f:DI 61 [ x ])
(nil)))

(insn 40 16 41 2 (set (reg:CCGOC 17 flags)
(compare:CCGOC (reg:SI 58 [ temp.27 ])
(const_int 0 [0x0]))) 3 {*cmpsi_ccno_1} (nil)
(expr_list:REG_DEAD (reg:SI 58 [ temp.27 ])
(nil)))

Unfortunatelly, combine pass will not create a combination of insn 15 and insn
16 because reg 58 is not dead in insn 16. However, combination of insn 15, insn
16 _and_ insn 40 would produce correct pattern and something similar to your
proposed asm (cmovns instead of cmovne).


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
  Component|target  |rtl-optimization
 Ever Confirmed|0   |1
  Known to fail||4.3.0
   Last reconfirmed|-00-00 00:00:00 |2007-01-13 23:27:24
   date||


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

[Bug rtl-optimization/30455] i386 generates unnecessary TEST instructions for arithmetic ops on memory

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2007-01-13 23:43 ---
(In reply to comment #1)

> 
> Combine pass then creates:
> 
> (insn 15 14 16 2 (parallel [
> (set (reg:SI 58 [ temp.27 ])
> (plus:SI (reg/v:SI 62 [ y ])
> (mem:SI (reg/v/f:DI 61 [ x ]) [2 S4 A32])))
> (clobber (reg:CC 17 flags))
> ]) 207 {*addsi_1} (insn_list:REG_DEP_TRUE 6 (insn_list:REG_DEP_TRUE 7
> (nil)))
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (expr_list:REG_DEAD (reg/v:SI 62 [ y ])
> (nil
> 
> (insn 16 15 40 2 (set (mem:SI (reg/v/f:DI 61 [ x ]) [2 S4 A32])
> (reg:SI 58 [ temp.27 ])) 40 {*movsi_1} (insn_list:REG_DEP_TRUE 15
> (nil))
> (expr_list:REG_DEAD (reg/v/f:DI 61 [ x ])
> (nil)))
> 
> (insn 40 16 41 2 (set (reg:CCGOC 17 flags)
> (compare:CCGOC (reg:SI 58 [ temp.27 ])
> (const_int 0 [0x0]))) 3 {*cmpsi_ccno_1} (nil)
> (expr_list:REG_DEAD (reg:SI 58 [ temp.27 ])
> (nil)))

Huh, is there any reason why insn 40 does not have any insn links?? It should
link to insn 15 as it uses reg 58. This is also seen in .140r.life1 pass.


-- 


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

[Bug ada/26649] hang c34007j

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2007-01-14 00:30 ---
This is still present in 4.1.2 20070111 (prerelease) on hppa1.1-hp-hpux10.20.


-- 


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

[Bug testsuite/30459] New: FAIL: g++.dg/eh/ia64-2.C (test for excess errors)

[danglin at gcc dot gnu dot org]

Executing on host: /xxx/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/xxx/gnu/gc
c/objdir/gcc/testsuite/g++/../../
/xxx/gnu/gcc/gcc/gcc/testsuite/g++.dg/eh/ia64-
2.C  -nostdinc++
-I/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/include
/hppa1.1-hp-hpux10.20
-I/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/in
clude -I/xxx/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/xxx/gnu/gcc/gcc/libstdc++-v3/
include/backward -I/xxx/gnu/gcc/gcc/libstdc++-v3/testsuite -fmessage-length=0 
-
O2-L/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/./libstdc++-v3/src/.libs 
-L/xx
x/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/./libstdc++-v3/src/.libs
-L/xxx/gnu/gcc/ob
jdir/hppa1.1-hp-hpux10.20/./libiberty  -lm   -o ./ia64-2.exe(timeout = 600)
/xxx/gnu/gcc/gcc/gcc/testsuite/g++.dg/eh/ia64-2.C:18: warning: weak declaration
of 'p' not supported
output is:
/xxx/gnu/gcc/gcc/gcc/testsuite/g++.dg/eh/ia64-2.C:18: warning: weak declaration
of 'p' not supported

FAIL: g++.dg/eh/ia64-2.C (test for excess errors)
Excess errors:
/xxx/gnu/gcc/gcc/gcc/testsuite/g++.dg/eh/ia64-2.C:18: warning: weak declaration
of 'p' not supported

Setting LD_LIBRARY_PATH to
.:/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/./libstdc+
+-v3/src/.libs:/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/./libstdc++-v3/src/.libs
:/xxx/gnu/gcc/objdir/gcc:.:/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/./libstdc++-
v3/src/.libs:/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/./libstdc++-v3/src/.libs:/
xxx/gnu/gcc/objdir/gcc
PASS: g++.dg/eh/ia64-2.C execution test


-- 
   Summary: FAIL: g++.dg/eh/ia64-2.C (test for excess errors)
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa1.1-hp-hpux10.20
  GCC host triplet: hppa1.1-hp-hpux10.20
GCC target triplet: hppa1.1-hp-hpux10.20


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

[Bug testsuite/25223] FAIL: g++.old-deja/g++.abi/vtable2.C

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2007-01-14 00:50 ---
Also present in 4.1.2 20070111 (prerelease).


-- 


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

[Bug target/10127] -fstack-check let's program crash

[jbuck at gcc dot gnu dot org]

--- Comment #5 from jbuck at gcc dot gnu dot org  2007-01-14 00:51 ---
I do not see this crash with gcc 4.1.1.  Is it still present?
I did see it with 3.4.2.


-- 


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

[Bug target/30052] memory hog on x86-64

[arekm at pld-linux dot org]

--- Comment #5 from arekm at pld-linux dot org  2007-01-14 00:54 ---
-O0 passes

-O0 -fdefer-pop -fdelayed-branch -fguess-branch-probability -fcprop-registers
-fif-conversion -fif-conversion2 -ftree-ccp -ftree-dce -ftree-dominator-opts
-ftree-dse -ftree-ter -ftree-lrs -ftree-sra -ftree-copyrename -ftree-fre
-ftree-ch -funit-at-a-time -fmerge-constants  -fomit-frame-pointer 

passes

-O1 fails
-O2 fails


-- 


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

Re: [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory

[Daniel Berlin]

okay, i'll update changelog, submit and commit.

On 13 Jan 2007 23:02:13 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:



--- Comment #21 from rguenth at gcc dot gnu dot org  2007-01-13 23:02 
---
The patch fixed the freefem memory regression.


--


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

[Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory

[dberlin at dberlin dot org]

--- Comment #22 from dberlin at gcc dot gnu dot org  2007-01-14 01:22 
---
Subject: Re:  Compiling FreeFem3d uses unreasonable amount of time and memory

okay, i'll update changelog, submit and commit.

On 13 Jan 2007 23:02:13 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #21 from rguenth at gcc dot gnu dot org  2007-01-13 23:02 
> ---
> The patch fixed the freefem memory regression.
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
>
>


-- 


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

[Bug driver/30460] New: asm_debug is not initialized in gcc.c

[rschiele at uni-mannheim dot de]

asm_debug is not initialized in gcc.c. This can lead to a sigsegv when using a
custom specs file that does not overwrite asm_debug but other predefined spec
values.

Example:

---
*invoke_as:
%{!S:-o %|.s |
 nesc-as %(asm_options) %m.s %A }

---


-- 
   Summary: asm_debug is not initialized in gcc.c
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rschiele at uni-mannheim dot de
 GCC build triplet: *-*-*
  GCC host triplet: *-*-*
GCC target triplet: *-*-*


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

[Bug driver/30460] asm_debug is not initialized in gcc.c

[rschiele at uni-mannheim dot de]

--- Comment #1 from rschiele at uni-mannheim dot de  2007-01-14 01:56 
---
Created an attachment (id=12903)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12903&action=view)
Fix for the problem.

BTW: This is also true for 4.2.x and 4.1.x. I have not looked into older
releases.


-- 


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

[Bug driver/30460] asm_debug is not initialized in gcc.c

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-01-14 02:10 ---
actually asm_debug is initialized in init_spec, with the following comment:
  /* Initialize here, not in definition.  The IRIX 6 O32 cc sometimes chokes
 on ?: in file-scope variable initializations.  */
  asm_debug = ASM_DEBUG_SPEC;


Oh, init_spec is not called because you read in the spec so there is no need to
call the initializer:
  /* Read the specs file unless it is a default one.  */
  if (specs_file != 0 && strcmp (specs_file, "specs"))
read_specs (specs_file, TRUE);
  else
init_spec ();

so your patch is incorrect as it might cause a bootstrap failure (unless IRIX 6
support has been removed).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |minor
   Keywords|patch   |


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

[Bug driver/30460] asm_debug is not initialized in gcc.c

[rschiele at gmail dot com]

--- Comment #3 from rschiele at gmail dot com  2007-01-14 02:21 ---
Andrew, it does not help to initialize in init_spec() because init_spec() is
only called when there is _no_ spec file found.


-- 


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

[Bug driver/30460] [4.0/4.1/4.2/4.3 Regression] asm_debug is not initialized in gcc.c when using a specs file

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||3.3.3 3.4.0 4.0.0 4.1.0
   ||4.2.0 4.0.4 4.1.2 4.1.1
   ||4.1.0 4.0.3 4.0.2 4.0.1
  Known to work||3.0.4
Summary|asm_debug is not initialized|[4.0/4.1/4.2/4.3 Regression]
   |in gcc.c|asm_debug is not initialized
   ||in gcc.c when using a specs
   ||file
   Target Milestone|--- |4.0.4


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

[Bug driver/30460] [4.0/4.1/4.2/4.3 Regression] asm_debug is not initialized in gcc.c when using a specs file

[rschiele at gmail dot com]

--- Comment #4 from rschiele at gmail dot com  2007-01-14 03:12 ---
What about just calling init_spec() _allways_ _before_ reading the default
specs file instead of calling it only when there is no default specs file?


-- 


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

[Bug libgcj/30454] [4.3 Regression] classpath/gnu/javax/crypto/jce/GnuCrypto.java:431: error: cannot find file for class gnu.javax.crypto.jce.mac.HMacSHA512Spi

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-01-14 03:44 ---
This also happens on powerpc-darwin8.5.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |blocker
 GCC target triplet|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11,
   ||powerpc-darwin8.5
   Keywords||build
Summary|classpath/gnu/javax/crypto/j|[4.3 Regression]
   |ce/GnuCrypto.java:431:  |classpath/gnu/javax/crypto/j
   |error: cannot find file for |ce/GnuCrypto.java:431:
   |class   |error: cannot find file for
   |gnu.javax.crypto.jce.mac.HMa|class
   |cSHA512Spi  |gnu.javax.crypto.jce.mac.HMa
   ||cSHA512Spi
   Target Milestone|--- |4.3.0


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

[Bug c++/30434] wrong parse of exception declaration list in virtual functions with multiple inheritence

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-01-14 04:39 ---
The specific wording in the C++ standard:
15.4/3
If a virtual function has an exception-specification, all declarations,
including the definition, of any function that overrides that virtual function
in any dirived class shall only allow exception that are allowed by the
exception-specification of the base class virtual function.


-- 


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

[Bug c++/30434] wrong parse of exception declaration list in virtual functions with multiple inheritence

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-01-14 04:46 ---
Since in this case we have:
struct a1
struct a2
both of which have virtualfunction with no exception-specification

and then we have
struct b : a1
struct c: a2
which have virtutalfunction with an exception-specification

and now we have:
struct d : b, c
which have a virutualfunction with a differnet exception-specification from b
or c



I think this case is invalid because the base class of D has a different
exception-specification for get_obj_type


>I have no error when D only inherits from either B or C.

I do with both 4.0.4 and the trunk so that would be a bug in the compiler you
are using I think.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c/30439] Intended Behaviour? #include searches for signal.h in local directory

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2007-01-14 04:56 ---
#include <...> search starts here:
 /home/cbs/local/include
 .
 /usr/local/include
 /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include
 /usr/include




Are you sure you don't have any of the following env variables set
(see http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Environment-Variables.html) :
CPATH
C_INCLUDE_PATH
CPLUS_INCLUDE_PATH
OBJC_INCLUDE_PATH


-- 


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

[Bug libgcj/30419] [4.3 Regression] libjava failed to build

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||build
Summary|libjava failed to build |[4.3 Regression] libjava
   ||failed to build
   Target Milestone|--- |4.3.0


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

[Bug middle-end/30442] Expanded array initialization can use memset builtin function

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-01-14 05:01 ---
This is a bit complex, we could use a loop reroller to roll this into a loop
and then transform that loop into memset for test1.
For test2 it is simple and a patch was presented at last year's gcc summit (and
I posted an older version of that patch a year or two ago).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|i686-pc-linux-gnu   |
   GCC host triplet|i686-pc-linux-gnu   |
 GCC target triplet|i686-pc-linux-gnu   |
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2007-01-14 05:01:04
   date||
Summary|Array initialization can use|Expanded array
   |memset builtin function |initialization can use
   ||memset builtin function


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

[Bug middle-end/30443] [4.3 Regression] 4.3 internal compiler error: verify_cgraph_node failed

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-01-14 05:02 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/30438] Unused variable should raise warning with -Wunused

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-01-14 05:09 ---
The variable is set but not read from.
There is another bug about this for the C/C++ front-ends and a new option for
this case instead of just using -Wunused.

I would considered t in comment #1 as being used as it is set.


-- 


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

[Bug libgcj/30448] libjava configure script mix up with .c / .java using gcj /gcc

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-01-14 05:11 ---
I have not seen this before in my buildings.

How did you configure gcc?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|java|libgcj
Summary|libjava configure script mix|libjava configure script mix
   |up with .c / .java using gcj|up with .c / .java using gcj
   |/gcc|/gcc


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

[Bug target/30451] incorrect attributes in *movti_ppc64 of rs6000.md

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-01-14 05:21 ---
I don't see why the attr type matters here as we always split it.  Can you
describe the case where something goes because of attr having the wrong type?


-- 


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

[Bug fortran/30432] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-01-14 05:28 ---
Hmmm, I wonder if ia64 is broken for the following C case:
TU1.c:
int f();
int g(int a, double c, int d)
{
  return f(a, d);
}

TU2.c:
int f(int a, double b)
{
  return b;
}


the named agrument is defined by:
  current_function_stdarg
= (fntype
   && TYPE_ARG_TYPES (fntype) != 0
   && (TREE_VALUE (tree_last (TYPE_ARG_TYPES (fntype)))
   != void_type_node));

But I wonder if we get it even more incorrect someother cases too.


-- 


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

[Bug preprocessor/28227] valid #ifdef rejected

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-01-14 05:36 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug target/30451] incorrect attributes in *movti_ppc64 of rs6000.md

[dkwan at transmeta dot com]

--- Comment #3 from dkwan at transmeta dot com  2007-01-14 05:47 ---
There is additional code for the CELL PPU to adjust the latencies of data and
address operands of integer stores. The code requires accurate load/store
attributes. I guess there is nothing in the main-line gcc that relies on the
load/store attributes being correct so it does not matter in the main line.


-- 


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

[Bug fortran/30437] [4.0/4.1/4.2/4.3 Regression] -Wno-all is rejected when fortran is included

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-01-14 05:49 ---
This is actually caused by fortran/lang.opt which differs from c.opt in that it
RejectNegative's.

So if someone configures without fortran (Apple or you in this case), you will
get -Wno-all but if you configure with fortran, you don't.
c.opt:
Wall
C ObjC C++ ObjC++
Enable most warning messages


fortran/lang.opt:
Wall
Fortran RejectNegative
; Documented in C

java/lang.opt:
Wall
Java
; Documented for C

ada/lang.opt:
Wall
Ada
; Documented for C


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|driver  |fortran
 Ever Confirmed|0   |1
  Known to fail|4.1.2 4.3.0 |4.0.0 4.0.4 4.1.1
  Known to work|4.0.1 4.1.1 |3.4.0
   Last reconfirmed|-00-00 00:00:00 |2007-01-14 05:49:41
   date||
Summary|-Wno-all is rejected|[4.0/4.1/4.2/4.3 Regression]
   ||-Wno-all is rejected when
   ||fortran is included
   Target Milestone|--- |4.0.4


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

[Bug middle-end/30403] [4.3 Regression] libssp/ssp.c:177: ICE: in cgraph_expand_function, at cgraphunit.c:973

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-01-14 05:58 ---
I think this was already fixed by:
r120577 | hubicka | 2007-01-08 03:18:40 -0800 (Mon, 08 Jan 2007) | 7 lines


* cgraphunit.c (cgraph_process_new_functions): Reset reachable flag.
(cgraph_analyze_function): break out from ...
(cgraph_finalize_compilation_unit): ... here.
(cgraph_expand_function): Remove forgoten commented out line.
(cgraph_optimize): Analyze functions.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|other   |middle-end
   Keywords||build, ice-on-valid-code
  Known to work||4.3.0
Summary|libssp/ssp.c:177: ICE: in   |[4.3 Regression]
   |cgraph_expand_function, at  |libssp/ssp.c:177: ICE: in
   |cgraphunit.c:973|cgraph_expand_function, at
   ||cgraphunit.c:973
   Target Milestone|--- |4.3.0


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

[Bug target/30413] %z produces ICE for char operands

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-01-14 06:02 ---
Confirmed, not a regression.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|inline-asm  |target
 Ever Confirmed|0   |1
   GCC host triplet|i686-pc-cygwin  |
 GCC target triplet|i686-pc-cygwin  |i686-*-*
   Keywords||ice-on-invalid-code
  Known to fail||2.95 3.2.3 3.4.0 4.0.0 4.2.0
   ||4.0.4 4.1.2 3.0.4
   Last reconfirmed|-00-00 00:00:00 |2007-01-14 06:02:37
   date||


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

[Bug c++/27962] [4.1 regression] ICE with invalid template parameter in specialization

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2007-01-14 06:05 ---
(In reply to comment #8)
> Just like PR 27668, I cannot confirm this bug for 4.1.1 or the 4.1 branch; it
> passes for me.
Unless something changed between 20061204 and now, I can reproduce this on the
4.1 branch:
t.cc:6: error: ‘struct T’ is not a valid type for a template constant parameter
t.cc:6: confused by earlier errors, bailing out

Note the confused by earlier errors is the ICE really.



-- 


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

[Bug fortran/30437] [4.0/4.1/4.2/4.3 Regression] -Wno-all is rejected when fortran is included

[chris dot pickett at mail dot mcgill dot ca]

--- Comment #3 from chris dot pickett at mail dot mcgill dot ca  2007-01-14 
06:06 ---
I don't think that's the right explanation.

cc1: error: unrecognized command line option "-Wno-all"
...
--enable-languages=c
...
gcc version 4.3.0 20070110 (experimental)

Although fortran may have a RejectNegative---in this case it's being rejected
without fortran---so it's a separate bug that fortran rejects -Wno-all, IMO.


-- 


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

[Bug tree-optimization/30440] internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:1472

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2007-01-14 06:07 
---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/28545] [4.1 Regression] Wrong code for hoisted multiplication

[pinskia at gcc dot gnu dot org]

--- Comment #21 from pinskia at gcc dot gnu dot org  2007-01-14 06:07 
---
*** Bug 30440 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jasonmbechtel at gmail dot
   ||com


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

[Bug fortran/30437] [4.0/4.1/4.2/4.3 Regression] -Wno-all is rejected (even when fortran is not included)

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-01-14 06:13 ---
(In reply to comment #3)
> Although fortran may have a RejectNegative---in this case it's being rejected
> without fortran---so it's a separate bug that fortran rejects -Wno-all, IMO.

Not really. 4.0.4 fails the same way if you include fortran:
[EMAIL PROTECTED] ~]$ ~/gcc-4.0/bin/gcc -Wno-all t.cc
cc1plus: error: unrecognized command line option "-Wno-all"
Configured with: /home/pinskia/src/gcc/gcc-4.0/gcc/configure
--prefix=/home/pinskia/gcc-4.0/

So does 4.1.1.

Oh I mean include fortran in the sources really.  This is still just caused by
fortran rejecting -Wno-all.


-- 


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

[Bug driver/30460] [4.0/4.1/4.2/4.3 Regression] asm_debug is not initialized in gcc.c when using a "default" specs file

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-01-14 06:16 ---
In my mind this is a minor issue because the way you are using the specs file
is wrong, you are using the defaults spec file and not using the overriding
one.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-01-14 06:16:27
   date||
Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2/4.3 Regression]
   |asm_debug is not initialized|asm_debug is not initialized
   |in gcc.c when using a specs |in gcc.c when using a
   |file|"default" specs file


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

[Bug target/30413] %z produces ICE for char operands

[cnovikov at pacbell dot net]

--- Comment #2 from cnovikov at pacbell dot net  2007-01-14 06:17 ---
(In reply to comment #1)
> Confirmed, not a regression.
> 

You set keywords to "ice-on-invalid-code". In my opinion, the code is valid. %z
is supposed to add an appropriate data width IA-32 insn suffix: l for dwords, w
for words, b for bytes. The expected behavior here is for %z0 to produce "b" in
the assembler output, since "a" is a char.


-- 


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

[Bug target/30413] %z produces ICE for char operands

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-01-14 06:34 ---
(In reply to comment #2)
> (In reply to comment #1)
> > Confirmed, not a regression.
> > 
> 
> You set keywords to "ice-on-invalid-code". 

Maybe you are correct but I don't think %zN is documented anywhere.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |


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

[Bug c++/30423] compile with -O2 fails.

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug target/10127] -fstack-check let's program crash

[ebotcazou at gcc dot gnu dot org]

--- Comment #6 from ebotcazou at gcc dot gnu dot org  2007-01-14 07:34 
---
> I do not see this crash with gcc 4.1.1.  Is it still present?
> I did see it with 3.4.2.

-fstack-check doesn't work on Linux/x86 and Linux/x86-64 without runtime
support.
Only the Ada compiler currently implements it.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 GCC target triplet||x86-linux, x86_64-linux


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