[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[jvdelisle at verizon dot net]

--- Additional Comments From jvdelisle at verizon dot net  2005-02-11 08:18 
---
For what its worth, with the files all in the one directory.  g77 passes on -O0
and -O1, and hangs on -O2 and -O3.  Test set up is as in Comment #33.

-- 


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

[Bug middle-end/19875] bug when installing R on OSF1

[k dot maillard at oxagen dot co dot uk]

--- Additional Comments From k dot maillard at oxagen dot co dot uk  
2005-02-11 08:36 ---
Subject: RE:  bug when installing R on OSF1


Thank you for your answer.  I have installed R on a LINUX machine
instead.

-Original Message-
From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED]

Sent: 10 February 2005 15:29
To: Karine Maillard
Subject: [Bug middle-end/19875] bug when installing R on OSF1




--

   What|Removed |Added


   Severity|critical|normal
  Component|fortran |middle-end
 GCC target triplet||alpha-dec-osf
   Keywords||ice-on-valid-code


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

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


This message contains confidential and potentially legally privileged 
information solely
for its intended recipients and others may not distribute, copy or use it. If 
you have
received this communication in error, please tell us by return email and delete 
it, and
any copies of it.


-- 


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

[Bug c++/19762] [3.4 regression] ICE in invalid explicit instantiation of a destructor

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-02-11 
08:44 ---
Mark, I still get the failure on the 3.4 branch:

dPR19762.cc:2: error: wrong number of template arguments (0, should be 1)
dPR19762.cc:1: error: provided for `template > struct A'
dPR19762.cc:2: error: ISO C++ forbids declaration of `type name' with no type
dPR19762.cc:2: error: abstract declarator `int' used as declaration
dPR19762.cc:2: internal compiler error: tree check: expected class 'd', have 'x'
(error_mark) in do_decl_instantiation, at cp/pt.c:10671
Please submit a full bug report, [etc.]


-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug c++/19666] [3.3/3.4 Regression] Trouble with prt-to-members: rejects-valid/ICE in fold_convert

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-02-11 09:55 
---
Patch here: 

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug middle-end/19858] [4.0 Regression] ICE on simple SSE code

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-02-11 09:59 
---
Patch here: 

-- 
   What|Removed |Added

   Keywords|ssemmx  |patch


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

[Bug rtl-optimization/18560] better optimalization of EOR/MOV block.

[rearnsha at gcc dot gnu dot org]

--- Additional Comments From rearnsha at gcc dot gnu dot org  2005-02-11 
10:15 ---
The new register allocator (new-ra) has been removed because it was buggy and
there were no plans to fix it.  I was using it to show that the initial MOV was
an unrelated issue.

Your code snippet shows that the rotate and the EOR are being merged, which is
what this PR was about.

-- 


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

[Bug rtl-optimization/18560] better optimalization of EOR/MOV block.

[pluto at pld-linux dot org]

--- Additional Comments From pluto at pld-linux dot org  2005-02-11 10:47 
---
(In reply to comment #4)
> The new register allocator (new-ra) has been removed because it was buggy and
> there were no plans to fix it.
> I was using it to show that the initial MOV was an unrelated issue.
> Your code snippet shows that the rotate and the EOR are being merged,
> which is what this PR was about.

The PR is about initial eor/mov opt., not eor/rotate ;-)

At this moment the comercial IAR compiler generates good code.
The GCC should be good too :)

reverse:
 0x0D04 E0201860  EOR  R1, R0, R0, ROR #16
 0x0D08 E3C118FF  BIC  R1, R1, #0xFF
 0x0D0C E1A01421  MOV  R1, R1, LSR #8
 0x0D10 E0210460  EOR  R0, R1, R0, ROR #8
 0x0D14 E12FFF1E  BX   LR


-- 


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

[Bug tree-optimization/19899] New: ICE: tree check: expected real_cst, have integer_cst in const_binop, at fold-const.c:1490 with -ftree-vectorize -msse2

[commie1 at gmx dot net]

/tmp/gcc4/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1 -quiet -v render.c -quiet
-dumpbase render.c -msse2 -auxbase render -O -ftree-vectorize -o render.s 
-version

GNU C version 4.0.0 20050211 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.0.0 20050211 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
render.c: In function 'render':
render.c:2: internal compiler error: tree check: expected real_cst, have
integer_cst in const_binop, at fold-const.c:1490

Configured with: ../gcc/configure --prefix=/tmp/gcc4 --enable-languages=c
--disable-nls




void render()
{
  float i;
  for (i=1; i>=0; i--) {}
  i=1;
}



-- 
   Summary: ICE: tree check: expected real_cst, have integer_cst in
const_binop, at fold-const.c:1490 with -ftree-vectorize
-msse2
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: commie1 at gmx dot net
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=19899

[Bug rtl-optimization/18560] better optimalization of EOR/MOV block.

[rearnsha at gcc dot gnu dot org]

--- Additional Comments From rearnsha at gcc dot gnu dot org  2005-02-11 
11:13 ---
I've linked this to the register-allocator meta-bug

-- 
   What|Removed |Added

  BugsThisDependsOn||18427
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug rtl-optimization/18427] [meta-bug] We need a better register allocator

[pluto at pld-linux dot org]

--- Additional Comments From pluto at pld-linux dot org  2005-02-11 11:27 
---
CC /me

-- 
   What|Removed |Added

 CC||pluto at pld-linux dot org


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

[Bug ada/19900] New: ACATS c391002 c432002 ICE categorize_ctor_elements_1

[laurent at guerby dot net]

This was introduced very recently, happens on x86 and x86_64.

/home/guerby/work/gcc/build/build-20050210T230923/gcc/xgcc -c
-B/home/guerby/work/gcc/build/build-20050210T230923/gcc/ -gnatws -O2
-I/home/guerby/work/gcc/build/build-20050210T230923/gcc/testsuite/ada/acats/support
c391002.adb
+===GNAT BUG DETECTED==+
| 4.0.0 20050210 (experimental) (x86_64-unknown-linux-gnu) GCC error:  |
| in categorize_ctor_elements_1, at expr.c:4374|
| Error detected at c391002.adb:232:5  |

/home/guerby/work/gcc/build/build-20050210T230923/gcc/xgcc -c
-B/home/guerby/work/gcc/build/build-20050210T230923/gcc/ -gnatws -O2
-I/home/guerby/work/gcc/build/build-20050210T230923/gcc/testsuite/ada/acats/support
c432002.adb
+===GNAT BUG DETECTED==+
| 4.0.0 20050210 (experimental) (x86_64-unknown-linux-gnu) GCC error:  |
| in categorize_ctor_elements_1, at expr.c:4374|
| Error detected at c432002.adb:560:5  |

-- 
   Summary: ACATS c391002 c432002 ICE categorize_ctor_elements_1
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug ada/19901] New: ACATS c85006e ICE block does not dominate

[laurent at guerby dot net]

This happened very recently, at least on x86 and x86_64

/home/guerby/work/gcc/build/build-20050210T230912/gcc/xgcc -c
-B/home/guerby/work/gcc/build/build-20050210T230912/gcc/ -gnatws -O2
-I/home/guerby/work/gcc/build/build-20050210T230912/gcc/testsuite/ada/acats/support
c85006e.adb
c85006e.adb: In function 'C85006E':
c85006e.adb:38: error: Definition in block 212 does not dominate use in block 
1130
for SSA_NAME: D.2824_6496in statement:
ivtmp.1438_81335 = &(*D.2840_6502)[5 ...]{lb: D.2824_6496 sz: 1}[0]{lb: 5 sz: 
1};
+===GNAT BUG DETECTED==+
| 4.0.0 20050210 (experimental) (i686-pc-linux-gnu) verify_ssa failed. |
| Error detected at c85006e.adb:702:5  |

-- 
   Summary: ACATS c85006e ICE block does not dominate
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug ada/18818] ACATS cd10002 fails at runtime

[laurent at guerby dot net]

--- Additional Comments From laurent at guerby dot net  2005-02-11 11:44 
---
Now fixed on x86 and x86_64 (recent commit).

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/18714] Runtime hang in LAPACK routine SLAMC1 - in Quetzal benchmark suite

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-02-11 
11:47 ---
Not a GCC bug.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug ada/19902] New: ACATS cxa3004 cxb3006 fail at compile time "ambiguous expression"

[laurent at guerby dot net]

Probably related to recent changes, might be an ACATS problem.

/home/guerby/work/gcc/build/build-20050210T230912/gcc/xgcc -c
-B/home/guerby/work/gcc/build/build-20050210T230912/gcc/ -gnatws -O2
-I/home/guerby/work/gcc/build/build-20050210T230912/gcc/testsuite/ada/acats/support
cxa3004.adb
cxa3004.adb:87:48: ambiguous expression (cannot resolve "To_Wide_Character")
cxa3004.adb:87:48: possible interpretation at a-chahan.ads:122
cxa3004.adb:87:48: possible interpretation at a-chahan.ads:120
cxa3004.adb:93:53: ambiguous expression (cannot resolve "To_Wide_Character")
cxa3004.adb:93:53: possible interpretation at a-chahan.ads:122
cxa3004.adb:93:53: possible interpretation at a-chahan.ads:120
cxa3004.adb:98:53: ambiguous expression (cannot resolve "To_Wide_Character")
cxa3004.adb:98:53: possible interpretation at a-chahan.ads:122
cxa3004.adb:98:53: possible interpretation at a-chahan.ads:120
cxa3004.adb:220:27: ambiguous expression (cannot resolve "To_Wide_Character")
cxa3004.adb:220:27: possible interpretation at a-chahan.ads:122
cxa3004.adb:220:27: possible interpretation at a-chahan.ads:120
cxa3004.adb:222:27: ambiguous expression (cannot resolve "To_Wide_Character")
cxa3004.adb:222:27: possible interpretation at a-chahan.ads:122
cxa3004.adb:222:27: possible interpretation at a-chahan.ads:120
gnatmake: "cxa3004.adb" compilation error

/home/guerby/work/gcc/build/build-20050210T230912/gcc/xgcc -c
-B/home/guerby/work/gcc/build/build-20050210T230912/gcc/ -gnatws -O2
-I/home/guerby/work/gcc/build/build-20050210T230912/gcc/testsuite/ada/acats/support
cxb30061.adb
cxb30061.adb:182:23: ambiguous expression (cannot resolve "To_Wide_Character")
cxb30061.adb:182:23: possible interpretation at a-chahan.ads:122
cxb30061.adb:182:23: possible interpretation at a-chahan.ads:120
cxb30061.adb:188:23: ambiguous expression (cannot resolve "To_Wide_Character")
cxb30061.adb:188:23: possible interpretation at a-chahan.ads:122
cxb30061.adb:188:23: possible interpretation at a-chahan.ads:120
cxb30061.adb:194:23: ambiguous expression (cannot resolve "To_Wide_Character")
cxb30061.adb:194:23: possible interpretation at a-chahan.ads:122
cxb30061.adb:194:23: possible interpretation at a-chahan.ads:120
cxb30061.adb:258:10: ambiguous expression (cannot resolve "Is_Nul_Terminated")
cxb30061.adb:258:10: possible interpretation at i-c.ads:161
cxb30061.adb:258:10: possible interpretation at i-c.ads:118
cxb30061.adb:264:14: ambiguous expression (cannot resolve "Is_Nul_Terminated")
cxb30061.adb:264:14: possible interpretation at i-c.ads:161
cxb30061.adb:264:14: possible interpretation at i-c.ads:118
gnatmake: "cxb30061.adb" compilation error

-- 
   Summary: ACATS cxa3004 cxb3006 fail at compile time "ambiguous
expression"
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug ada/19903] New: ACATS cxa4006 cxa4017 ada.string.(un)bounded fail at runtime

[laurent at guerby dot net]

May be linked to recent commits, happens on x86 and x86_64, unanalyzed yet.

,.,. CXA4006 ACATS 2.5 05-02-11 01:15:38
 CXA4006 Check that the subprograms defined in package
Ada.Strings.Bounded are available, and that they produce
correct results.
   * CXA4006 Exception raised in Test_Block.
 CXA4006 FAILED .

,.,. CXA4017 ACATS 2.5 05-02-11 01:16:04
 CXA4017 Check that the subprograms defined in package
Ada.Strings.Wide_Bounded are available, and that they
produce correct results.
   * CXA4017 Exception raised in Test_Block.
 CXA4017 FAILED .

-- 
   Summary: ACATS cxa4006 cxa4017 ada.string.(un)bounded fail at
runtime
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
CC: gcc-bugs at gcc dot gnu dot org


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

Re: [Bug ada/19902] New: ACATS cxa3004 cxb3006 fail at compile time "ambiguous expression"

[Arnaud Charlet]

> Probably related to recent changes, might be an ACATS problem.

Right, these tests should be removed from the repository, or modified.
We've informed the ACAA about this issue (incompatibility with Ada 2005).

Arno

[Bug ada/19902] ACATS cxa3004 cxb3006 fail at compile time "ambiguous expression"

[charlet at adacore dot com]

--- Additional Comments From charlet at adacore dot com  2005-02-11 12:03 
---
Subject: Re:  New: ACATS cxa3004 cxb3006 fail at compile time "ambiguous 
expression"

> Probably related to recent changes, might be an ACATS problem.

Right, these tests should be removed from the repository, or modified.
We've informed the ACAA about this issue (incompatibility with Ada 2005).

Arno


-- 


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

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

[aph at gcc dot gnu dot org]

--- Additional Comments From aph at gcc dot gnu dot org  2005-02-11 12:07 
---
This is a workaround for everyone that needs to use debugging on HEAD.

If we can't get this bug fixed soon something like this will need to be 
committed.


Index: include/posix-threads.h
===
RCS file: /cvs/gcc/gcc/libjava/include/posix-threads.h,v
retrieving revision 1.26
diff -u -r1.26 posix-threads.h
--- include/posix-threads.h 11 Oct 2004 17:49:39 -  1.26
+++ include/posix-threads.h 11 Feb 2005 12:05:52 -
@@ -204,12 +204,10 @@
 _Jv_Thread_t *_Jv_ThreadInitData (java::lang::Thread *thread);
 void _Jv_ThreadDestroyData (_Jv_Thread_t *data);
 
-inline java::lang::Thread *
-_Jv_ThreadCurrent (void)
-{
-  extern pthread_key_t _Jv_ThreadKey;
-  return (java::lang::Thread *) pthread_getspecific (_Jv_ThreadKey);
-}
+
+extern pthread_key_t _Jv_ThreadKey;
+#define _Jv_ThreadCurrent()\
+  ((java::lang::Thread *) pthread_getspecific (_Jv_ThreadKey))
 
 #ifdef JV_HASH_SYNCHRONIZATION
 // Should be specialized to just load the "current thread" register
@@ -339,12 +337,9 @@
 
 #endif /* JV_HASH_SYNCHRONIZATION */
 
-inline _Jv_Thread_t *
-_Jv_ThreadCurrentData (void)
-{
-  extern pthread_key_t _Jv_ThreadDataKey;
-  return (_Jv_Thread_t *) pthread_getspecific (_Jv_ThreadDataKey);
-}
+extern pthread_key_t _Jv_ThreadDataKey;
+#define _Jv_ThreadCurrentData()\
+   ((_Jv_Thread_t *) pthread_getspecific (_Jv_ThreadDataKey))
 
 inline void
 _Jv_ThreadYield (void)


-- 
   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-02-11 
12:09 ---
(In reply to comment #39)

> One suspect is this code snippet from gcc/config/ia64.c :
> 
> static bool
> ia64_rtx_costs (rtx x, int code, int outer_code, int *total)

> case DIV:
> case UDIV:
> case MOD:
> case UMOD:
>   /* We make divide expensive, so that divide-by-constant will be
>  optimized to a multiply.  */
>   *total = COSTS_N_INSNS (60);

That's not it.  I changed that one to a low value, and still got
the same results.

Thomas

-- 


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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-02-11 
12:10 ---
(In reply to comment #40)

>  ** On entry to DGEEV  parameter number  1 had an illegal value

I had that one, as well.  There are some routines which occur more than
once.  Copying the files from the right directories solved that problem.

Thomas

-- 


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

[Bug target/19300] [4.0 Regression] PCH failures on sparc-linux

[phython at gcc dot gnu dot org]

--- Additional Comments From phython at gcc dot gnu dot org  2005-02-11 
12:48 ---
Created an attachment (id=8174)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8174&action=view)
copy some  code from pa-host.c

 This seems to fix some pch failures on sparc64-linux.  I don't trust my
testing so far though.

-- 
   What|Removed |Added

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


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

[Bug fortran/19904] New: Division by zero leads to error

[schnetter at aei dot mpg dot de]

I want to define a parameter that contains a nan.  When I use a division by 
zero in a parameter statement, gfortran aborts with an error instead of 
setting the parameter to nan.  (The Intel Fortran compiler accepts this 
parameter statement without warning.) 
 
subroutine x 
  implicit none 
  double precision, parameter :: zero=0, nan=0/zero 
end subroutine x 
 
$ ~/gcc/bin/gfortran -c zero.f90 
 In file zero.f90:3 
 
  double precision, parameter :: zero=0, nan=0/zero 
 1 
Error: Division by zero at (1) 
 
$ ~/gcc/bin/gfortran --version 
GNU Fortran 95 (GCC 4.0.0 20050126 (experimental))

-- 
   Summary: Division by zero leads to error
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schnetter at aei dot mpg dot de
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=19904

[Bug c/19881] strange warning about alloca

[bruno at clisp dot org]

--- Additional Comments From bruno at clisp dot org  2005-02-11 13:13 
---
> the warning is not the FSF's gcc, you two should have filed it with Redhat 
> instead. 
 
You're right: Current gcc CVS ("gcc version 4.0.0 20050211 (experimental)") 
doesn't 
show the warning. So it appears to be a RedHat-only problem. 
 

-- 


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

[Bug c/19881] strange warning about alloca

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-11 
13:29 ---
(In reply to comment #4)
> > the warning is not the FSF's gcc, you two should have filed it with Redhat 
> > instead. 
>  
> You're right: Current gcc CVS ("gcc version 4.0.0 20050211 (experimental)") 
> doesn't 
> show the warning. So it appears to be a RedHat-only problem. 

Which is why PR 14236 is still open :)  In fact I said the FSF's gcc did not 
have it in my first comment 
when I marked this as a dup because you can complain there.  But note the 
warning shows what 
happens now with VLA/alloca so in that sense the warning is correct, if you 
want the behavor to change 
it is a very hard problem to fix.

-- 


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

[Bug c++/19891] [4.0 Regression] Covariant returns are broken

[nathan at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |nathan at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-02-11 04:42:53 |2005-02-11 13:30:49
   date||


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

[Bug tree-optimization/19899] ICE: tree check: expected real_cst, have integer_cst in const_binop, at fold-const.c:1490 with -ftree-vectorize -msse2

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-11 
13:39 ---
Confirmed.

-- 
   What|Removed |Added

 CC||dorit at il dot ibm dot com
   Severity|critical|normal
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2005-02-11 13:39:33
   date||


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

[Bug ada/19902] ACATS cxa3004 cxb3006 fail at compile time "ambiguous expression"

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-11 13:40:09
   date||


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

[Bug ada/19900] ACATS c391002 c432002 ICE categorize_ctor_elements_1

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-11 
13:41 ---
This looks like a front-end problem:
  /* We don't expect more than one element of the union to be
 initialized.  Not sure what we should do otherwise... */
  gcc_assert (TREE_CHAIN (list) == NULL);

-- 


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

[Bug tree-optimization/19901] ACATS c85006e ICE block does not dominate

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-11 
13:43 ---
Most likely different IV selection make this show up so this is a latent bug in 
ivopts.
See  and others, Kenner was 
trying to fix this 
for a while now.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|ada |tree-optimization
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-11 13:43:38
   date||


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

[Bug tree-optimization/19901] ACATS c85006e ICE block does not dominate

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-11 
13:47 ---
http://gcc.gnu.org/ml/gcc/2004-11/msg01200.html
http://gcc.gnu.org/ml/gcc/2004-12/msg00144.html
And more

-- 


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

[Bug fortran/19904] Division by zero leads to error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-11 
13:50 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2005-02-11 13:50:33
   date||


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

[Bug tree-optimization/18437] vectorizer failed for matrix multiplication

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-11 
14:12 ---
We now get:
t3.c:9: note: not vectorized: can't determine dependence between: 
(*D.1338_16)[0] and 
(*D.1336_10)[i_53]


-- 
   What|Removed |Added

   Last reconfirmed|2004-11-12 02:43:04 |2005-02-11 14:12:15
   date||


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

[Bug tree-optimization/18439] vectorizer failed for vector normalization

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-11 
14:19 ---
Really there are two problems which cause the missed vectorizor.  One is that 
we don't scalarize the 
static variables that well.  So that is the bug which really needs to be fixed 
first and really is not related 
to the vectorizor at all.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Last reconfirmed|2004-11-12 02:43:29 |2005-02-11 14:19:47
   date||


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

[Bug tree-optimization/19905] New: Extra V_MAY_DEF on a static variable whose address is not taken (we should be able to move the load out of the loop)

[pinskia at gcc dot gnu dot org]

The following two functions should be the same (note don't compile with 
-ffast-math or even -fno-
math-errno as sqrt is marked as pure)

#define NUMPOINTS 20

float opoints[NUMPOINTS];

double sqrt (double);

void NormalizeVectors (void)
{
  int i, r;
  float s, x, y, z;
  static float d = 0.0;
  
  d += 0.2f;
  
  if (d > 4)
d = 0.0;
  
  for (i=0; i 4)
d = 0.0;
  s = d;

  for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=19905

[Bug tree-optimization/18439] vectorizer failed for vector normalization

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-11 
14:47 ---
I filed PR 19905 for the missed optimization not really related (but blocking) 
the tree vectorizor.

-- 
   What|Removed |Added

  BugsThisDependsOn||19905


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

[Bug tree-optimization/19905] Extra V_MAY_DEF on a static variable whose address is not taken (we should be able to move the load out of the loop)

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||18439
  nThis||


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

[Bug c/19906] New: multilib setup fails when building canadian

[greg dot weeks at timesys dot com]

The mklibgcc fails to setup the multilib directories correctly when building
canadian.

I have a patch that works for me and is covered under the TimeSys copyright
assignment.

-- 
   Summary: multilib setup fails when building canadian
   Product: gcc
   Version: 3.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: greg dot weeks at timesys dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-linux
  GCC host triplet: i686-timesys-linux
GCC target triplet: powerpc64-linux


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

[Bug c/19906] multilib setup fails when building canadian

[greg dot weeks at timesys dot com]

--- Additional Comments From greg dot weeks at timesys dot com  2005-02-11 
14:57 ---
Created an attachment (id=8175)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8175&action=view)
proposed patch


-- 


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

[Bug c/19906] multilib setup fails when building canadian

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-11 
15:01 ---
This is a dup of bug 12984.  Could you attach the patch there and send it to 
gcc-patches?

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug bootstrap/12984] libgcc*.so files are mis-installed when doing a candian cross

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

 CC||greg dot weeks at timesys
   ||dot com


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

[Bug c/19906] multilib setup fails when building canadian

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-11 
15:01 ---
Also could you make a patch for the mainline first.

-- 


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

[Bug c++/17805] too liberal operator lookup

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-02-11 
15:20 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00453.html

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |aoliva at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
   Keywords||patch


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

[Bug bootstrap/12984] libgcc*.so files are mis-installed when doing a candian cross

[greg dot weeks at timesys dot com]

--- Additional Comments From greg dot weeks at timesys dot com  2005-02-11 
15:24 ---
The patch does apply with some fuzz to the mainline CVS.

-- 


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

[Bug java/19907] New: Incorrect code generated for ManifestElement.java

[aph at gcc dot gnu dot org]

The bytecode compiler generates incorrect code for the attached .class file.

-- 
   Summary: Incorrect code generated for ManifestElement.java
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: aph at gcc dot gnu dot org
ReportedBy: aph at gcc dot gnu dot org
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=19907

[Bug java/19907] Incorrect code generated for ManifestElement.java

[aph at gcc dot gnu dot org]

--- Additional Comments From aph at gcc dot gnu dot org  2005-02-11 16:37 
---
Created an attachment (id=8177)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8177&action=view)
ManifestElement.class


-- 


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

[Bug java/19908] New: Inlining of final fields incompatible with Sun's implementation

[dog at bluezoo dot org]

The issue reported on the mailing list

  http://gcc.gnu.org/ml/java/2005-02/msg00031.html

shows that gcj will not inline a primitive final field that is i initialised
where it is declared, whereas Sun's implementation will (1.5).

The output of FinalFieldChange is

   Ng Keng Yap, 27 of IQ=150 from Malaysia

whereas Sun 1.5 outputs

   Ng Keng Yap, 27 of IQ=110 from Malaysia

-- 
   Summary: Inlining of final fields incompatible with Sun's
implementation
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dog at bluezoo dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
  GCC host triplet: powerpc-apple-darwin7.7.0


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

[Bug java/19907] Incorrect code generated for ManifestElement.java

[aph at gcc dot gnu dot org]

--- Additional Comments From aph at gcc dot gnu dot org  2005-02-11 16:41 
---
The method ArrayList.add() return a boolean, so the bytecode compiler generates
a temp of type promoted_boolean.  Unfortunately, the same temp is used later as
an int.

This problem arises because promoted booleans in the Java VM are really an
integer type, not a boolean type.  It's perfectly legal to store a boolean and
then read an int for the same slot.  So, we need to use int temporaries for
booleans, not promoted_boolean.


-- 
   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-11 16:41:01
   date||


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

[Bug java/19908] Inlining of final fields incompatible with Sun's implementation

[dog at bluezoo dot org]

--- Additional Comments From dog at bluezoo dot org  2005-02-11 16:41 
---
Created an attachment (id=8178)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8178&action=view)
The Person class


-- 


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

[Bug java/19908] Inlining of final fields incompatible with Sun's implementation

[dog at bluezoo dot org]

--- Additional Comments From dog at bluezoo dot org  2005-02-11 16:42 
---
Created an attachment (id=8179)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8179&action=view)
The main class to reproduce the bug


-- 


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

[Bug java/19908] Inlining of final fields incompatible with Sun's implementation

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Attachment #8178|text/x-java-source  |text/plain
  mime type||


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

[Bug java/19908] Inlining of final fields incompatible with Sun's implementation

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Attachment #8179|text/x-java-source  |text/plain
  mime type||


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

[Bug java/19908] Inlining of final fields incompatible with Sun's implementation

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-11 
16:54 ---
As dicussed there are still questions if this is wrong code or not.  Yes this 
is not the same as Sun's implementation but that means nothing really.

-- 


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

[Bug c++/16529] [3.4/4.0 regression] ICE for: namespace-alias shall no be declared as the name of any other entity

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-02-11 
16:58 ---
Btw, fix and testcase are here (wrongly attributed to PR16489):
http://gcc.gnu.org/ml/gcc-cvs/2004-08/msg00026.html


-- 


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

[Bug c++/11762] namespace aliasing ICE in warn_extern_redeclared_static

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-02-11 
17:04 ---


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

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE
   Target Milestone|--- |3.4.2


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

[Bug c++/16529] [3.4/4.0 regression] ICE for: namespace-alias shall no be declared as the name of any other entity

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-02-11 
17:04 ---
*** Bug 11762 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||bkoz at gcc dot gnu dot org


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

[Bug fortran/19904] Division by zero leads to error

[sgk at troutmask dot apl dot washington dot edu]

--- Additional Comments From sgk at troutmask dot apl dot washington dot 
edu  2005-02-11 17:10 ---
Gfortran is a Fortran 95 compiler, and AFAIK gfortran's behavior conforms
to the Fortran 95 standard, because it has no allowance for floating point
exception.  Someday, gfortran may/will support Technical Report ISO/IEC
15580: 1998(E), which will then permit the use of the ieee_arithmetic,
ieee_features, and ieee_exceptions intrinsic modules.

If you want to set a NaN in gfortran you can do,

program test
   real nan
   integer duh
   equivalence (nan,duh)
   duh = z'FFC0'
   print*, nan
end program test

The question then becomes "what are going to do with NaN?"
I suspect the gfortran's behavior of the numeric rational
operation and numeric binary operation may give undefined
behavior, which is again permitted by the Fortran 95 standard.

-- 


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

[Bug c++/19253] [3.4/4.0 regression] bad error message / ICE for invalid template parameter

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-02-11 
17:12 ---
Mark, the first code snippet in comment #3 still crashes on mainline.
So this is not yet fixed on mainline.


-- 
   What|Removed |Added

Summary|[3.4 regression] bad error  |[3.4/4.0 regression] bad
   |message / ICE for invalid   |error message / ICE for
   |template parameter  |invalid template parameter


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

[Bug c++/19253] [3.4/4.0 regression] bad error message / ICE for invalid template parameter

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-02-11 
17:13 ---
Sorry, I meant comment #2, of course.


-- 


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

[Bug c++/19755] [3.3/3.4/4.0 Regression] -Wmissing-braces doesn't warn anymore

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-11 
17:15 ---
Subject: Bug 19755

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-11 17:15:51

Modified files:
gcc/cp : ChangeLog decl.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/warn: Wbraces1.C 

Log message:
PR c++/19755
* decl.c (reshape_init): Issue warnings about missing braces.

PR c++/19755
* g++.dg/warn/Wbraces1.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4622&r2=1.4623
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1361&r2=1.1362
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5016&r2=1.5017
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/Wbraces1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug fortran/19904] Division by zero leads to error

[schnetter at aei dot mpg dot de]

--- Additional Comments From schnetter at aei dot mpg dot de  2005-02-11 
17:17 ---
Actually, gfortran handles nans correctly (according to the IEEE standard) in 
all other cases.  I can e.g. generate a nan through the expression a/b, if I 
only hide from the compiler the fact that b is zero, so that it generates code 
that performs the division at run time, and does not try to evaluate it at 
compile time. 
 
Also, while your argument is correct that the Fortran 95 standard does not 
require nans to be handled correctly, your code is also undefined according to 
the Fortran 95 standard, because you use the variable "nan" without defining 
it: if you assign to an equivalenced storage an integer value, then you are 
only allowed to read out the integer value, and vice versa for the real value. 
 

-- 


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

[Bug c++/19755] [3.3/3.4/4.0 Regression] -Wmissing-braces doesn't warn anymore

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-11 
17:20 ---
Subject: Bug 19755

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2005-02-11 17:20:03

Modified files:
gcc/testsuite  : ChangeLog 
gcc/cp : ChangeLog decl.c 
Added files:
gcc/testsuite/g++.dg/warn: Wbraces1.C 

Log message:
PR c++/19755
* decl.c (reshape_init): Issue warnings about missing braces.

PR c++/19755
* g++.dg/warn/Wbraces1.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.359&r2=1.3389.2.360
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/Wbraces1.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.197&r2=1.3892.2.198
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.1174.2.29&r2=1.1174.2.30



-- 


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

[Bug c++/19755] [3.3 Regression] -Wmissing-braces doesn't warn anymore

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-02-11 
17:22 ---
Fixed in GCC 3.4.4.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
Summary|[3.3/3.4/4.0 Regression] -  |[3.3 Regression] -Wmissing-
   |Wmissing-braces doesn't warn|braces doesn't warn anymore
   |anymore |


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

[Bug c++/18604] [3.4/4.0 Regression] Strong using lookup conflicts

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-02-11 
17:23 ---
Jason, will you be able to look into this PR?

-- 


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

[Bug fortran/18918] Eventually support the co-array f95 extension in gfortran

[jblomqvi at cc dot hut dot fi]

--- Additional Comments From jblomqvi at cc dot hut dot fi  2005-02-11 
17:24 ---
You might want to check out the "global arrays" toolkit at
http://www.emsl.pnl.gov/docs/global/ga.html

GA implements the same programming model as Co-Array Fortran, but it's a
library, so any standard F95 compiler should do.

-- 


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

[Bug c++/19878] [4.0 Regression] ICE in import_export_decl

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mark at codesourcery dot com
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug c++/19403] [4.0 Regression] name lookup is broken with friends

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-02-11 
17:37 ---
This looks like a duplicate of PR 1016 to me.


-- 
   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org


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

[Bug fortran/19904] Division by zero leads to error

[sgk at troutmask dot apl dot washington dot edu]

--- Additional Comments From sgk at troutmask dot apl dot washington dot 
edu  2005-02-11 17:44 ---
You are probably right that my example does not conform to the standard,
because I don't use equilance() and I whipped up the example in a minute
without inspection of its conformance.

Anyway, if you want to make gfortran accept your code, constant folding
is done in arith.c.  I suggest that you add a -fallow_inf_nan option
to gfortran and make the appropriate modifications to arith.c

-- 


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

[Bug c++/19894] pointer-to-void member not rejected in template

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2005-02-11 17:44 
---
Quite naively, I would say that this could even be ok, just that there will 
never be a member variable the address of which one could initialize this 
pointer-to-member with. Do you have chapter and verse where this is 
prohibited? 
 
W. 

-- 


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

[Bug c++/19253] [3.4/4.0 regression] bad error message / ICE for invalid template parameter

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2005-02-11 17:50 
---
Volker, you seem to be on a quest to make gcc accept without crashing even  
the most obnoxious wrong code snippets without ICEing. How do you generate 
all these snippets? 
 
(As a sidenote, even if they are technically regressions, I don't consider 
such artificial codes really important to fix. There are more important 
things, and we get this right for gcc 4.6.2, that'll be ok with me as well :-) 
 
W. 

-- 


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

[Bug c/19909] New: verify-flow-info: wrong frequency ...

[cgweav at email dot com]

gcc-3.4.3 internal compiler error at -O3 -fno-strict-aliasing,
disappears with -O2.
(linux-2.4.29, glibc-2.3.3-200410112214, binutils-2.15.92.0.2).

gcc -v (CFLAGS="-march=i686 -O2" ../gcc-3.4.3/configure ...):

Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/usr --enable-shared --enable-
threads=posix --enable-checking --enable-__cxa_atexit --enable-languages=c,c++ -
-disable-nls

Thread model: posix
gcc version 3.4.3

gcc's error report:

 ../term
 /usr/X11R6/include
 /usr/src/gnuplot-4.0.0/gd1.3/include
 /usr/include/libpng12
 /usr/local/include
 /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include
 /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/include
 /usr/include
End of search list.
 /usr/libexec/gcc/i686-pc-linux-gnu/3.4.3/cc1 -fpreprocessed plot3d.i -quiet -
dumpbase plot3d.c -march=i686 -auxbase-strip plot3d.o -O3 -Wall -version -fno-
strict-aliasing -o plot3d.s
GNU C version 3.4.3 (i686-pc-linux-gnu)
compiled by GNU C version 3.4.3.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
plot3d.c: In function `eval_3dplots':
plot3d.c:1771: error: verify_flow_info: Wrong frequency of block 174 -1
plot3d.c:1771: internal compiler error: verify_flow_info failed

I don't see any button on this bugzilla form
to attach the preprocessed source file. I
have it, ask me for it at 

-- 
   Summary: verify-flow-info: wrong frequency ...
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cgweav at email dot com
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=19909

[Bug debug/19885] [4.0 Regression] avr dwarf-2 support is broken for head 4.0

[bjoern dot m dot haase at web dot de]

--- Additional Comments From bjoern dot m dot haase at web dot de  
2005-02-11 19:00 ---
I have tried to trace back the date when dwarf2 support startet to fail. So far 
I have found out that it was broken already at december 5th 2004. 
 
Yours, 
 
Björn   

-- 


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

[Bug debug/19885] [4.0 Regression] avr dwarf-2 support is broken for head 4.0

[bjoern dot m dot haase at web dot de]

--- Additional Comments From bjoern dot m dot haase at web dot de  
2005-02-11 19:04 ---
Subject: Re:  [4.0 Regression] avr dwarf-2 support is broken for head 4.0

Am Freitag, 11. Februar 2005 00:36 schrieb ericw at evcohs dot com:
> --- Additional Comments From ericw at evcohs dot com  2005-02-10 23:36
> --- As an aside, DWARF2 is about to become the default debugging
> information used in WinAVR, for both Atmel's AVR Studio and for use with
> avr-gdb/avr-insight. So this one is crucial for having a successful 4.0.0
> release for the avr target.

Hi Eric, 

brief question:

As far as I know you have monitored Thorleif Sandes attempts of getting the 
dwarf support working for avr-studio. Do you remember that it was necessary 
at the time to implement  bug-fixes for getting it functional for gcc 3.4. ?

Yours,

Björn


-- 


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

[Bug tree-optimization/19910] New: ICE with -ftree-loop-linear

[dalej at apple dot com]

The following gets an ICE with -O3 -ftree-loop-linear:

int x[6][5][4];
int y[6][5][4];
void initx(void)
{
  int a,b,c;
  int index = 0;
  for(a = 5; a >=2; a--)
for (b = (a - 1); b >=1; b--)
  for (c = (b - 1); c >=0; c--)
x[a][b][c] = index++;
}
void inity(void)
{
  int d,e,f;
  int index = 0;
  for(d = 5; d >=2; d--)
for (e = (d - 1); e >=1; e--)
  for (f = (e - 1); f >=0; f--)
y[d][e][f] = index++;
}
void foo() {
  initx();
  inity();
}

-- 
   Summary: ICE with -ftree-loop-linear
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dalej at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-apple-darwin8.0.0
  GCC host triplet: powerpc-apple-darwin8.0.0
GCC target triplet: powerpc-apple-darwin8.0.0


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

[Bug target/17993] Error in dwarf2 debug output of bitfield members

[ericw at evcohs dot com]

-- 
   What|Removed |Added

 CC||bjoern dot m dot haase at
   ||web dot de


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

[Bug target/17994] avr-gcc does not output a dwarf2 .debug_frame section

[ericw at evcohs dot com]

-- 
   What|Removed |Added

 CC||bjoern dot m dot haase at
   ||web dot de


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

[Bug rtl-optimization/19909] verify-flow-info: wrong frequency ...

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c   |rtl-optimization


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

[Bug rtl-optimization/19909] verify-flow-info: wrong frequency ...

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-11 
19:29 ---
We need the preprocessed source.
Read .

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING


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

[Bug target/19087] Overflowed address in dwarf debug line information

[ericw at evcohs dot com]

-- 
   What|Removed |Added

 CC||bjoern dot m dot haase at
   ||web dot de


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

[Bug target/10768] ICEs on compilation of ada support library for avr

[ericw at evcohs dot com]

--- Additional Comments From ericw at evcohs dot com  2005-02-11 19:38 
---
Bernd, does this still fail on the most recent HEAD?

Eric

-- 


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

[Bug ada/19632] x86_64 RHE3 internal error: segmentation fault

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-11 
20:22 ---
Subject: Bug 19632

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-11 20:22:25

Modified files:
gcc/cp : ChangeLog pt.c 

Log message:
PR c++/19632
* pt.c (get_mostly_instantiated_function_type): Save and restore
flag_access_control instead of push/pop_access_scope.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4623&r2=1.4624
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.974&r2=1.975



-- 


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

[Bug libstdc++/19911] New: Using std::string find the n field always causes nothing to be found

[grogers at cray dot com]

This is for all flavors of find.

According to the documentation I can find.

#include 
#include 

using namespace std;

int main(int argc, char **argv)
{
string test("this should be a bunch of words");
size_t p = test.find("s");  // correct at 3
cerr << "p = " << p << ", npos = " << string::npos << endl;
p = test.find("s", 5);  // correct at 5
cerr << "p = " << p << ", npos = " << string::npos << endl;
p = test.find("s", 5, 5);   // incorrect, should be 5 is npos
cerr << "p = " << p << ", npos = " << string::npos << endl;
}

-- 
   Summary: Using std::string find the n field always causes nothing
to be found
   Product: gcc
   Version: 3.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: grogers at cray dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/19904] Division by zero leads to error

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug c++/19403] [4.0 Regression] name lookup is broken with friends

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-11 
20:34 ---
(In reply to comment #13)
> This looks like a duplicate of PR 1016 to me.

It might be a dup bug the example in this bug was able to compile in 3.4.0 and 
before.

-- 


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

[Bug libstdc++/19911] Using std::string find the n field always causes nothing to be found

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-11 
20:46 ---
No string.find (const char *s, size_type pos, size_t n) returns the same as:
string.find(string(s, n), pos)
which means you are allocating a string with length 5 but the string is really 
only of lenght 1 so this will not be able to find the string.

This documented by 21.3.6.1 of the C++ standard.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug java/19907] Incorrect code generated for ManifestElement.java

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-11 
20:50 ---
Patch here: .

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Keywords||patch, wrong-code


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

[Bug java/19834] Eclipse bytecode miscompiled with -O --indirect-dispatch

[mckinlay at redhat dot com]

--- Additional Comments From mckinlay at redhat dot com  2005-02-11 20:56 
---
19907 is a dupe of this.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug java/19907] Incorrect code generated for ManifestElement.java

[mckinlay at redhat dot com]

--- Additional Comments From mckinlay at redhat dot com  2005-02-11 20:56 
---
*** Bug 19834 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||mckinlay at redhat dot com


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

[Bug libstdc++/19911] Using std::string find the n field always causes nothing to be found

[grogers at cray dot com]

--- Additional Comments From grogers at cray dot com  2005-02-11 20:59 
---
Subject: Re:  Using std::string find the n field always
 causes nothing to be found

Okay, doesn't make much sense.

The docs I found on the web all had it described as n being the number 
of characters past pos to search.

pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-11 
> 20:46 ---
> No string.find (const char *s, size_type pos, size_t n) returns the same as:
> string.find(string(s, n), pos)
> which means you are allocating a string with length 5 but the string is 
> really 
> only of lenght 1 so this will not be able to find the string.
> 
> This documented by 21.3.6.1 of the C++ standard.
> 



-- 


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

[Bug tree-optimization/19910] ICE with -ftree-loop-linear

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2005-02-11 21:06:54
   date||


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

[Bug middle-end/19858] [4.0 Regression] ICE on simple SSE code

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-11 
21:08 ---
Subject: Bug 19858

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-11 21:08:44

Modified files:
gcc: ChangeLog fold-const.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/compile: 20050210-1.c 

Log message:
PR middle-end/19858
* fold-const.c (make_bit_field_ref): If bitpos == 0 and bitsize
is number of inner's bits, avoid creating a BIT_FIELD_REF.

* gcc.c-torture/compile/20050210-1.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7449&r2=2.7450
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.504&r2=1.505
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5017&r2=1.5018
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20050210-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug tree-optimization/19910] ICE with -ftree-loop-linear

[dberlin at gcc dot gnu dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-02-11 
21:09 ---
This is caused by generating a complex linear offset in the transformed loop,
which the "back to gcc" converter doesn't handle ATM, since they were never
generated before.

(I didn't completly minimize linear offset generation.  If i did, you'd notice
that this loop really goes from  5 to MAX (2, j) or something like that)
Loop w
  step size = -1
  linear offset:
Linear expression: -i + j constant: 5   invariants:   denominator: 1
  lower bound:
Linear expression: i - j constant: 0   invariants:   denominator: 1
  upper bound:
Linear expression: i - j constant: -3   invariants:   denominator: 1
Linear expression: i constant: -5   invariants:   denominator: 1


-- 


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

[Bug c++/19666] [3.3/3.4 Regression] Trouble with prt-to-members: rejects-valid/ICE in fold_convert

[cvs-commit at gcc dot gnu dot org]

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

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-11 21:10:16

Modified files:
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/other: ptrmem6.C 

Log message:
PR c++/19666
2004-06-08  Andrew Pinski  <[EMAIL PROTECTED]>
* fold-const.c (fold_convert): Treat OFFSET_TYPE like
POINTER_TYPE and INTEGER_TYPE.

* gcc/testsuite/g++.dg/other/ptrmem6.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5018&r2=1.5019
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/other/ptrmem6.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug c++/19634] [4.0 regression] Infinite memory usage on Alpha

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-02-11 21:10 
---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/19911] Using std::string find the n field always causes nothing to be found

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-02-11 21:11 
---
I'm maintaining the string class, and Andrew is 100% right: please browse the
standard (or any good book, such as Josuttis, if you like) instead of trusting
"docs on the web" ;)

-- 


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

[Bug c++/19666] [3.3/3.4 Regression] Trouble with prt-to-members: rejects-valid/ICE in fold_convert

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-11 
21:13 ---
Subject: Bug 19666

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2005-02-11 21:12:56

Modified files:
gcc: ChangeLog fold-const.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/other: ptrmem6.C 

Log message:
PR c++/19666
2004-06-08  Andrew Pinski  <[EMAIL PROTECTED]>
* fold-const.c (fold_convert): Treat OFFSET_TYPE like
POINTER_TYPE and INTEGER_TYPE.

* gcc/testsuite/g++.dg/other/ptrmem6.C: New test.

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.797&r2=2.2326.2.798
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.322.2.15&r2=1.322.2.16
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.360&r2=1.3389.2.361
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/other/ptrmem6.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug c++/19666] [3.3 Regression] Trouble with prt-to-members: rejects-valid/ICE in fold_convert

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-11 
21:15 ---
Fixed in the 3.4 branch, it is a rejects valid for the 3.3 branch but most 
likely will not get fixed there as 
many different places call convert instead of fold_convert on the 3.3 branch 
compared to the 3.4/4.0.

-- 
   What|Removed |Added

   Keywords|ice-on-valid-code, patch|
  Known to work|3.2.3 4.0.0 |3.2.3 4.0.0 3.4.4
Summary|[3.3/3.4 Regression] Trouble|[3.3 Regression] Trouble
   |with prt-to-members:|with prt-to-members:
   |rejects-valid/ICE in|rejects-valid/ICE in
   |fold_convert|fold_convert
   Target Milestone|3.4.4   |3.3.6


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

[Bug middle-end/19858] [4.0 Regression] ICE on simple SSE code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-11 
21:16 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/19912] New: GCC does not disclose parentheses

[l_belev at yahoo dot com]

GCC generates different codes for the both functions:
  int f1(int k) { return k*k+k; }
  int f2(int k) { return k*(k+1); }

also the generated code for, say '(k*k+k) + (k*(k+1))'
calculates the two parts independently and then sums them,
whereas the code for '(k*k+k) + (k*k+k)' just calculates
k*k+k once and then doubles it.

This is not the case with two other compilers i tested -
intel's icc and the microsoft's compiler.

I think that this way GCC is missing very important
and basic opportunities for optimizations.
For example there are many macros out there in the
wilderness, that heavily rely on such kind of
optimizations that disclose parentheses.

-- 
   Summary: GCC does not disclose parentheses
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: l_belev at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/19912] GCC does not disclose parentheses

[joseph at codesourcery dot com]

--- Additional Comments From joseph at codesourcery dot com  2005-02-11 
21:34 ---
Subject: Re:  New: GCC does not disclose parentheses

On Fri, 11 Feb 2005, l_belev at yahoo dot com wrote:

> GCC generates different codes for the both functions:
>   int f1(int k) { return k*k+k; }
>   int f2(int k) { return k*(k+1); }
> 
> also the generated code for, say '(k*k+k) + (k*(k+1))'
> calculates the two parts independently and then sums them,
> whereas the code for '(k*k+k) + (k*k+k)' just calculates
> k*k+k once and then doubles it.

Note that the first expression can involve undefined behavior when the 
second doesn't, so transformations between these forms would be invalid 
with -ftrapv and until we have internal overflow flags on expressions we 
could only transform in one direction without -fwrapv.

(Consider k == -46341 with 32-bit int.  The first expression involves 
signed integer overflow, undefined behavior in ISO C which needs a trap 
with -ftrapv, while the second doesn't.)



-- 


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