[Bug libstdc++/13943] call of overloaded `llabs(int)' is ambiguous

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-05-22 09:15 
---
Gaby, can you have a look? It seems to me that we should use the same approach
used in std_cmath.h for fpclassify & co. In particular, when _GLIBCXX_USE_C99
is defined - that explicitly checks for llabs and lldiv - do *not* open code
llabs and lldiv. Probably the open coding of the overloads abs(long long) and
div(long long, long long) should stay, however, as a straightforward extension
of 26.5/4 for long long.

-- 
   What|Removed |Added

 CC||pcarlini at suse dot de, gdr
   ||at integrable-solutions dot
   ||net


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

[Bug libstdc++/13943] call of overloaded `llabs(int)' is ambiguous

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-05-22 09:32 
---
Same for strt* and the other functions. Also we should remember to add to the
acinclude check for c99_stdlib the functions strtoll and strtoull, currently
missing.

(PS. In the meanwhile, done a minimal check that the approach used in std_cmath
for the classification macros appear to work well also for llabs)

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

[Bug web/21679] Download > Releases doesn't take me to appropriate info

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-05-22 10:21 
---
Yes, in my opinion too, in Download -> Releases should be present info strictly
about the Download of Releases ;), therefore, probably, immediately the list of
mirrors, or a link to it and, probably, some minimal info about how to navigate
in the directory trees of the servers (as mentioned by Dave). Detailed info
about each release, together with fixed bugs and so on - what we have in 
releases/
#timeline - should be definitely available, of course, but elsewhere, not from
the Download link of the homepage: in fact, we *already* have a Timeline link in
the homepage, maybe suffices, but should point to a separate page about the
timeline only.

-- 


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

[Bug libstdc++/13943] call of overloaded `llabs(int)' is ambiguous

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-05-22 10:32 ---
Subject: Re:  call of overloaded `llabs(int)' is ambiguous

"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:

| Gaby, can you have a look?

Yup.  Just woke up and many people are awaiting in the TODO queue...

-- Gaby


-- 


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

[Bug web/21679] Download > Releases doesn't take me to appropriate info

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-05-22 10:33 
---
Another thought: maybe we want to keep the Timeline, and all the interesting
info about each release, easily reachable from the download info. In that case
we could consider linking the Timeline, that, as I said before would have a
separate page, from Download -> Releases.

-- 


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

[Bug tree-optimization/21630] [4.1 Regression] gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1 fails

[irar at il dot ibm dot com]

--- Additional Comments From irar at il dot ibm dot com  2005-05-22 11:42 
---
The problem is in vect-none.c itself. This patch fixes the problem 
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02124.html (waiting for ok). 

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |irar at il dot ibm dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-22 11:42:09
   date||


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

[Bug c++/13830] Invalid covariant type for identical type, friend related

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2005-05-22 
11:42 ---
Also fixed in GCC 4.0.1.

-- 


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

[Bug c++/15453] Friend declaration treated as a declaration in scope.

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2005-05-22 
11:43 ---
Also fixed in GCC 4.0.1.

-- 


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

[Bug c/21706] New: MAXPATHLEN usage in [gcc]/gcc/tlink.c

[ams at gnu dot org]

Please do not use MAXPATHLEN, it is a arbitrary limit, and is not
defined on GNU.  Currently gcc 4.0.0 is unbuildable on GNU since
[gcc]/gcc/tlink.c assumes that MAXPATHLEN is defined.  Please do not
use these kind of limits in GNU programs.

Suggested fix is to declare initial_cwd as:

  char *initial_cwd;

and then instead of doing:

  getcwd (initial_cwd, sizeof (initial_cwd));

do:

  initial_cwd = getcwd (NULL, 0);

Note: getcwd (NULL, 0) is a GNU extention, and might not be available
on non-GNU platforms.  (End of Note)

Sorry for not supplying a patch, happy hacking.

-- 
   Summary: MAXPATHLEN usage in [gcc]/gcc/tlink.c
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P1
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ams at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-gnu0.3
  GCC host triplet: i686-pc-gnu0.3
GCC target triplet: i686-pc-gnu0.3


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

[Bug c/21706] MAXPATHLEN usage in [gcc]/gcc/tlink.c

[schwinge-bugzilla-gcc dot gnu dot org at nic-nac-project dot de]

-- 
   What|Removed |Added

 CC||schwinge-bugzilla-gcc dot
   ||gnu dot org at nic-nac-
   ||project dot de


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

[Bug middle-end/21706] MAXPATHLEN usage in [gcc]/gcc/tlink.c

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-22 
14:04 ---
What about using PATH_MAX which is part of the POSIX standard?



-- 
   What|Removed |Added

   Severity|critical|normal
  Component|c   |middle-end
   Keywords||build
   Priority|P1  |P2


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

[Bug c++/13830] Invalid covariant type for identical type, friend related

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.1


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

[Bug c++/15453] Friend declaration treated as a declaration in scope.

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.1


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

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   GCC host triplet|x86_64-unknown-linux-gnu|
 GCC target triplet||x86_64-unknown-linux-gnu


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

[Bug target/20036] gcc.dg/compat/vector-[12]_y.c fails to compile

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-22 
14:13 ---
Fixed in 4.0.0 and above.

-- 
   What|Removed |Added

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


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

[Bug testsuite/21707] New: g++.old-deja/g++.jason/thunk3.C: syntax error target selector

[themis_hv at yahoo dot co dot uk]

when running the testsuite
(http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01434.html)

g++.old-deja/g++.jason/thunk3.C contains  syntax error
in target selector "xfail rs6000-*-* powerpc-*-eabi
m68k-*-coff mn10300-*-* v850-*-* sh-*-* sh64-*-*
h8*-*-* xtensa-*-* m32r*-*" for " dg-do 1 run { xfail
rs6000-*-* powerpc-*-eabi m68k-*-coff mn10300-*-*
v850-*-* sh-*-* sh64-*-* h8*-*-* xtensa-*-* m32r*-* }
"

I get this error

-- 
   Summary: g++.old-deja/g++.jason/thunk3.C: syntax error
target selector
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: themis_hv at yahoo dot co dot uk
CC: gcc-bugs at gcc dot gnu dot org,themis_hv at yahoo dot
co dot uk
 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=21707

[Bug testsuite/21707] [4.1 Regression] g++.old-deja/g++.jason/thunk3.C: syntax error target selector

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-22 
14:50 ---
Confirmed, see the whole thread: 
.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-22 14:50:43
   date||
Summary|g++.old-|[4.1 Regression] g++.old-
   |deja/g++.jason/thunk3.C:|deja/g++.jason/thunk3.C:
   |syntax error|syntax error target selector
   |target selector |
   Target Milestone|--- |4.1.0


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

[Bug middle-end/21706] MAXPATHLEN usage in [gcc]/gcc/tlink.c

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-05-22 15:35 ---
Subject: Re:  MAXPATHLEN usage in [gcc]/gcc/tlink.c

"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| What about using PATH_MAX which is part of the POSIX standard?

I think the point was about arbitray limit; and as far as I can tell
GNU does not claim to be POSIX, does it? ;-)

-- Gaby


-- 


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

[Bug middle-end/21706] MAXPATHLEN usage in [gcc]/gcc/tlink.c

[schwab at suse dot de]

--- Additional Comments From schwab at suse dot de  2005-05-22 15:36 ---
Like most POSIX limits PATH_MAX may not be defined if the actual limit is not  
fixed.  

-- 


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

[Bug testsuite/21707] [4.1 Regression] g++.old-deja/g++.jason/thunk3.C: syntax error target selector

[themis_hv at yahoo dot co dot uk]

--- Additional Comments From themis_hv at yahoo dot co dot uk  2005-05-22 
15:46 ---
Testing patch  (from thread 
) 

-- 


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

[Bug libfortran/21708] New: gfortran.dg/dev_null.f90 fails to run

[kargl at gcc dot gnu dot org]

gfortran.dg/dev_null.f90 fails to run.  It appears that the
implementation of READ(..., end=100) does not properly check
for EOF.  For discussion see,

http://gcc.gnu.org/ml/fortran/2005-05/msg00147.html

This problem affects FreeBSD, Darwin, and I suspect also
OpenBSD and NetBSD due to their common legacy.

-- 
   Summary: gfortran.dg/dev_null.f90 fails to run
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/21709] New: [3.4 regression] ICE on compile-time complex NaN

[debian-gcc at lists dot debian dot org]

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

[EMAIL PROTECTED]:/tmp% cat test.c
double _Complex f(void) { return 1.0iF / 0.0; }

[EMAIL PROTECTED]:/tmp% gcc-3.4 -c test.c 
test.c: In function `f':
test.c:1: internal compiler error: Segmentation fault

Problem not present in 4.0.

-- 
   Summary: [3.4 regression] ICE on compile-time complex NaN
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/21709] [3.4 regression] ICE on compile-time complex NaN

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-22 
16:08 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||ice-on-valid-code
  Known to fail||3.4.0 4.0.0 4.1.0
  Known to work||3.3.3
   Last reconfirmed|-00-00 00:00:00 |2005-05-22 16:08:39
   date||
   Target Milestone|--- |3.4.5


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

[Bug AWT/21598] rendering problem with button text

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-05-22 
16:26 ---
I think the problem here is that the applet calls
setBounds on the buttons in question.  But maybe this is
valid as it explicitly asks for a certain size font?
FWIW the contents of the buttons do look off-center vertically.


-- 


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

[Bug bootstrap/21683] [Regression] build failure on i386-mingw (sys/wait.h header)

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-22 
17:01 ---
Subject: Bug 21683

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-22 17:01:03

Modified files:
fixincludes: ChangeLog fixincl.c 

Log message:
PR target/21683
* fixincl.c: Don't include  if SEPARATE_FIX_PROC.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/ChangeLog.diff?cvsroot=gcc&r1=1.42&r2=1.43
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/fixincl.c.diff?cvsroot=gcc&r1=1.7&r2=1.8



-- 


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

[Bug bootstrap/21683] [Regression] build failure on i386-mingw (sys/wait.h header)

[gdr at gcc dot gnu dot org]

--- Additional Comments From gdr at gcc dot gnu dot org  2005-05-22 17:06 
---
Patch applied.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/21683] [4.1 Regression] build failure on i386-mingw (sys/wait.h header)

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|[Regression] build failure  |[4.1 Regression] build
   |on i386-mingw (sys/wait.h   |failure on i386-mingw
   |header) |(sys/wait.h header)
   Target Milestone|--- |4.1.0


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

[Bug tree-optimization/21582] (optimisation) VRP pass could/should use non-null function attribute

[kazu at cs dot umass dot edu]

-- 
   What|Removed |Added

  BugsThisDependsOn||18373


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

[Bug tree-optimization/21076] [4.1 Regression] ACATs ICE cxh1001 at tree-vrp.c:124

[kazu at cs dot umass dot edu]

-- 
   What|Removed |Added

  BugsThisDependsOn||18373


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

[Bug tree-optimization/21348] tree-vrp.c:has_assert_expr is useless.

[kazu at cs dot umass dot edu]

-- 
   What|Removed |Added

  BugsThisDependsOn||18373


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

[Bug fortran/20178] COMPLEX function returns incompatible with g77

[Tobias dot Schlueter at physik dot uni-muenchen dot de]

--- Additional Comments From Tobias dot Schlueter at physik dot 
uni-muenchen dot de  2005-05-22 18:10 ---
Subject: Re:  COMPLEX function returns incompatible with
 g77

Tobias Schlüter wrote:
>>>--- Additional Comments From tobi at gcc dot gnu dot org  2005-05-10 
>>>22:23 ---
>>>Fixed on the mainline.  I will commit this to the branch after the obligatory
>>>testing and the necessary changes (unfortunately -fsecond-underscore became 
>>>the
>>>default on the branch).
>>
>>
>>[ Sorry for the late reply ]
>>
>>I wonder if that really means we have to stick to -fsecond-underscore on 
>>the 4.0 branch.  Only 4.0.0 is out, and it is very probable that 
>>*nobody* uses it for any serious work in Fortran anyway.
>>
>>I feel we can safely change the default, even on the branch.
> 
> 
> I'm also inclined to doing this, 4.0.1 will probably be vastly more usable
> than 4.0, but I'd still like to get feedback from the list.  It's really a
> minor incompatibility.  Especially since a lot of people seem to use
> '-fno-second-underscore'.

I'll commit this during the week, unless somebody objects.  Toon's approval
together with no objections so far is enough for me, but I wanted to give
everybody a last chance to object.

- Tobi


-- 


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

[Bug libfortran/21708] gfortran.dg/dev_null.f90 fails to run

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-05-22 
18:19 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/21593] FAIL: gfortran.dg/dev_null.f90

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-05-22 
18:19 ---
*** Bug 21708 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||kargl at gcc dot gnu dot org


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

[Bug fortran/21593] FAIL: gfortran.dg/dev_null.f90

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-05-22 
18:20 ---
>From PR21708: "This problem affects FreeBSD, Darwin, and I suspect also
OpenBSD and NetBSD due to their common legacy."

-- 


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

[Bug c/21710] New: gcc-3.4.4 ICE when compiling glibc-2.3.5 for arm

[mikpe at csd dot uu dot se]

/*
 * gcc3_arm_bug.c
 * Written by Mikael Pettersson, [EMAIL PROTECTED], 2005-05-22.
 * Adapted from glibc-2.3.5/sysdeps/generic/s_fmax.c
 *
 * gcc-3.4.4 configured for arm-unknown-linux gets an
 * internal compiler error when compiling this program
 * with optimisation enabled:
 *
 * gcc3_arm_bug.c: In function `__fmax':
 * gcc3_arm_bug.c:28: internal compiler error: in elim_reg_cond, at flow.c:3267
 *
 * Notes:
 * - gcc-3.4.4 was built as a cross-compiler for arm-unknown-linux
 *   hosted on i686-pc-linux-gnu. The cross-compilation toolchain
 *   consisted of binutils-2.16, gcc-3.4.4, glibc-2.3.5, and kernel
 *   headers from linux-2.4.30.
 * - Using -O0 prevents the ICE.
 * - gcc-3.4.4, gcc-3.3.6, and gcc-3.2.3 all exhibit this bug.
 * - gcc-4.0.1 (20050521) does not have this bug.
 */
extern int __isnan (double __value);

double
__fmax (double x, double y)
{
return (__builtin_isgreaterequal(x, y) || __isnan (y)) ? x : y;
}

int main(void) { return 0; }

-- 
   Summary: gcc-3.4.4 ICE when compiling glibc-2.3.5 for arm
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at csd dot uu dot se
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: arm-unknown-linux


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

[Bug c/21711] New: compiler crash while compiling mySQL 4.1.9

[terry-palmer at btconnect dot com]

[EMAIL PROTECTED] mysys]# gcc -v -save-temps -
DDEFAULT_BASEDIR=\"/usr/local/mysql\" -DDATADIR="\"/usr/local/mysql/var\"" -
DDEFAULT_CHARSET_HOME="\"/usr/local/mysql\"" -
DSHAREDIR="\"/usr/local/mysql/share/mysql\"" -DHAVE_CONFIG_H -I. -I. -I.. -
I../include -I.-O3 -DDBUG_OFF-MT default.o -MD -MP -
MF ".deps/default.Tpo" -c -o default.o default.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /usr/local/src/gcc-4.0.0/configure
Thread model: posix
gcc version 4.0.0
 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1 -E -quiet -v -I. -I. -I.. -
I../include -I. -MD default.d -MF .deps/default.Tpo -MP -MT default.o -MQ 
default.o -DDEFAULT_BASEDIR="/usr/local/mysql" -
DDATADIR="/usr/local/mysql/var" -DDEFAULT_CHARSET_HOME="/usr/local/mysql" -
DSHAREDIR="/usr/local/mysql/share/mysql" -DHAVE_CONFIG_H -DDBUG_OFF default.c -
mtune=pentiumpro -O3 -fpch-preprocess -o default.i
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/lib/gcc/i686-pc-linux-
gnu/4.0.0/../../../../i686-pc-linux-gnu/include"
ignoring duplicate directory "."
ignoring duplicate directory "."
#include "..." search starts here:
#include <...> search starts here:
 .
 ..
 ../include
 /usr/local/include
 /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include
 /usr/include
End of search list.
 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1 -fpreprocessed default.i -
quiet -dumpbase default.c -mtune=pentiumpro -auxbase-strip default.o -O3 -
version -o default.s
GNU C version 4.0.0 (i686-pc-linux-gnu)
compiled by GNU C version 4.0.0.
GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=96507
default.c: In function ‘print_defaults’:
default.c:535: internal compiler error: in get_indirect_ref_operands, at tree-
ssa-operands.c:1449
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

-- 
   Summary: compiler crash while compiling mySQL 4.1.9
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry-palmer at btconnect 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=21711

[Bug libfortran/21376] libfortran "E" output format causes FPE

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-05-22 
18:35 ---
Patch submitted for review.

-- 
   What|Removed |Added

URL||http://gcc.gnu.org/ml/fortra
   ||n/2005-05/msg00249.html
   Keywords||patch


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

[Bug c/21711] compiler crash while compiling mySQL 4.1.9

[terry-palmer at btconnect dot com]

--- Additional Comments From terry-palmer at btconnect dot com  2005-05-22 
18:37 ---
Created an attachment (id=8948)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8948&action=view)
pre-processed output as requested


-- 


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

[Bug rtl-optimization/21710] gcc-3.4.4 ICE when compiling glibc-2.3.5 for arm

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c   |rtl-optimization
   Keywords||ice-on-valid-code


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

[Bug rtl-optimization/15068] ICE in elim_reg_cond

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

 CC||mikpe at csd dot uu dot se


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

[Bug rtl-optimization/21710] gcc-3.4.4 ICE when compiling glibc-2.3.5 for arm

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-22 
18:47 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/21711] compiler crash while compiling mySQL 4.1.9

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-22 
18:47 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/21173] [4.0/4.1 regression] miscompiled pointer subtraction broke Linux kernel

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

 CC||terry-palmer at btconnect
   ||dot com


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

[Bug tree-optimization/21705] FRE does not eliminate a redundant pure call.

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-05-22 
18:55 ---
Subject: Re:  FRE does not eliminate a
redundant pure call.

On Sun, 2005-05-22 at 13:42 +, kazu at cs dot umass dot edu wrote:
> 
A patch was sent to kazu privately that bootstrapped and regtested okay,
and fixses this bug.
i'll commit it after the slush.




-- 


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

[Bug testsuite/21707] [4.1 Regression] g++.old-deja/g++.jason/thunk3.C: syntax error target selector

[themis_hv at yahoo dot co dot uk]

--- Additional Comments From themis_hv at yahoo dot co dot uk  2005-05-22 
19:06 ---
Kazuhiro Inaoka's patch 
(http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01937.html) resolves this problem

Test summary available at
http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01442.html


-- 


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

[Bug testsuite/21630] [4.1 Regression] gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1 fails

[themis_hv at yahoo dot co dot uk]

--- Additional Comments From themis_hv at yahoo dot co dot uk  2005-05-22 
19:11 ---
(In reply to comment #3)
> The problem is in vect-none.c itself. This patch fixes the problem 
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02124.html (waiting for ok). 

FYI I have regression tested this patch and I still get

FAIL: gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1

Test summary available at
http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01442.html




-- 


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

[Bug tree-optimization/21712] New: inconsistent loop optimization

[TazForEver at dlfp dot org]

gcc -v
Lecture des spécification à partir de /usr/lib/gcc-lib/powerpc-linux/3.3.6/specs
Configuré avec: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm
--enable-java-awt=xlib --enable-objc-gc --disable-multilib powerpc-linux
Modèle de thread: posix
version gcc 3.3.6 (Debian 1:3.3.6-5)


BEGIN_CODE
#define CONST __attribute__((const))

int get_type1(void) CONST;
int get_type2(void) CONST;

void* cast(void*, int) CONST;

void do_something(void*);

void baz(void* p)
{
while(1)
{
do_something(cast(p, get_type1()));
do_something(cast(p, get_type2()));
}
}
END_CODE


gcc-4.0 -Wall -O3 -S

BEGIN_ASM
baz:
mflr 0
stwu 1,-16(1)
stw 30,8(1)
mr 30,3
stw 31,12(1)
stw 0,20(1)
bl get_type1
mr 4,3
mr 3,30
bl cast
mr 31,3
.L3:
mr 3,31
bl do_something
bl get_type2
mr 4,3
mr 3,30
bl cast
bl do_something
b .L3
END_ASM


why the call to get_type2() and cast() are not moved outside the loop just like
get_type1() and the first call to cast() ?
Thanks.

-- 
   Summary: inconsistent loop optimization
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: TazForEver at dlfp dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-22 
19:24 ---
Confirmed.

-- 
   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org, pinskia at gcc dot gnu
   ||dot org
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2005-05-22 19:24:04
   date||
Summary|inconsistent loop   |missed optimization due with
   |optimization|const function and pulling
   ||out of loops


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

[Bug tree-optimization/9814] gcc fails to optimise if (l&2) l|=2 away

[roger at eyesopen dot com]

--- Additional Comments From roger at eyesopen dot com  2005-05-22 19:25 
---
I posted a patch here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01956.html
to implement this in the RTL optimizers.  Better to get it linked to the PR,
than slip through the cracks.  The proposed change to noce_emit_move_insn is
also related to another missed optimization PR, whose number I can no longer
remember.  Something to do with synthesized insn not getting recognized without
the needed clobbers.

I agree with Kazu that these transformations should also be implemented at the
tree-ssa level. I think once I commit the RTL solution to mainline CVS (so these
optimizations are performed somewhere), I'll unassign the PR (from myself), and
leave the tree-optimization PR open as an enhancement request.


-- 
   What|Removed |Added

   Keywords||patch


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

[Bug fortran/18923] segfault after subroutine name confusion

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-05-22 
19:26 ---
There is no segfault any more:

$ gfc pr18923.f90
 In file pr18923.f90:3

  subroutine foo(i)
   1
Error: PROGRAM attribute conflicts with PROCEDURE attribute at (1)
 In file pr18923.f90:4

integer :: i
   1
Error: Unexpected data declaration statement in CONTAINS section at (1)
 In file pr18923.f90:5

character(len=selected_int_kind(i)) :: c
   1
Error: Unexpected data declaration statement in CONTAINS section at (1)
 In file pr18923.f90:6

  end subroutine bar
1
Error: Expecting END PROGRAM statement at (1)
 In file pr18923.f90:7

end program foo
  1
 Internal Error at (1):
 gfc_get_default_type(): Bad symbol

-- 
   What|Removed |Added

   Last reconfirmed|2004-12-14 22:35:13 |2005-05-22 19:26:20
   date||


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

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2005-05-22 
19:36 ---
Because do_something does not have to return, therefore
get_type2 does not necessarily have to be executed.
In this case we cannot move the call to get_type2 from
the loop (since do_something could for example initialize
some table used internally by get_type2).

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[TazForEver at dlfp dot org]

--- Additional Comments From TazForEver at dlfp dot org  2005-05-22 19:54 
---
const
Many functions do not examine any values except their arguments, and have no
effects except the return value. Basically this is just slightly more strict
class than the pure attribute below, since function is not allowed to read
global memory.

So get_type2() should not use any global table. Right ?

-- 


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

Re: [Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[Daniel Berlin]

On Sun, 2005-05-22 at 19:36 +, rakdver at gcc dot gnu dot org wrote:
> --- Additional Comments From rakdver at gcc dot gnu dot org  2005-05-22 
> 19:36 ---
> Because do_something does not have to return, therefore
> get_type2 does not necessarily have to be executed.
> In this case we cannot move the call to get_type2 from
> the loop (since do_something could for example initialize
> some table used internally by get_type2).
> 

This is wrong.
do_something can't write.
it's const.

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-05-22 
19:54 ---
Subject: Re:  missed optimization due with
const function and pulling out of loops

On Sun, 2005-05-22 at 19:36 +, rakdver at gcc dot gnu dot org wrote:
> --- Additional Comments From rakdver at gcc dot gnu dot org  2005-05-22 
> 19:36 ---
> Because do_something does not have to return, therefore
> get_type2 does not necessarily have to be executed.
> In this case we cannot move the call to get_type2 from
> the loop (since do_something could for example initialize
> some table used internally by get_type2).
> 

This is wrong.
do_something can't write.
it's const.




-- 


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

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[rakdver at atrey dot karlin dot mff dot cuni dot cz]

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2005-05-22 19:56 ---
Subject: Re:  missed optimization due with const function and pulling out of 
loops

> > Because do_something does not have to return, therefore
> > get_type2 does not necessarily have to be executed.
> > In this case we cannot move the call to get_type2 from
> > the loop (since do_something could for example initialize
> > some table used internally by get_type2).
> > 
> 
> This is wrong.
> do_something can't write.
> it's const.

do_something is not const.


-- 


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

[Bug tree-optimization/21705] FRE does not eliminate a redundant pure call.

[kazu at cs dot umass dot edu]

-- 
   What|Removed |Added

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


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

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[rakdver at atrey dot karlin dot mff dot cuni dot cz]

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2005-05-22 20:01 ---
Subject: Re:  missed optimization due with const function and pulling out of 
loops

> const
> Many functions do not examine any values except their arguments, and have 
> no
> effects except the return value. Basically this is just slightly more strict
> class than the pure attribute below, since function is not allowed to read
> global memory.
> 
> So get_type2() should not use any global table. Right ?

this depends on interpretation of this definition.  Some people want
this to read "behaves as if" and thus allow for example caching of the
results of such function.  For more discussion see PR19828.

Nevertheless, even if we are very strict with the definition, moving
get_type2 out of the loop is not a good idea, since get_type2 might
potentially be very expensive (and we have no way how to determine
that this is not the case), thus we would lose in case get_type2
should be never executed.


-- 


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

[Bug c++/21713] New: Syntax error

[igodard at pacbell dot net]

class index {};
int main (){
index i;
}


gets you:

foo.cc: In function `int main()':
foo.cc:3: error: `index' undeclared (first use this function)
foo.cc:3: error: (Each undeclared identifier is reported only once for each
function it appears in.)
foo.cc:3: error: expected `;' before "i"

-- 
   Summary: Syntax error
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[TazForEver at dlfp dot org]

--- Additional Comments From TazForEver at dlfp dot org  2005-05-22 20:12 
---
OK, I understand :/
Thanks for you quick explanations.

-- 


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

[Bug c++/21713] Syntax error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-22 
20:14 ---
index is a POSIX function.

-- 


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

[Bug c++/21713] Syntax error

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-05-22 20:24 
---
The test doesn't #include any posix functions. The problem seems to be a partial
hide of the name, because a simple declaration works:

int index;
int main (){
index  = 0;
}

gives no errors. Interestingly, 

class index {};
int main (){
class index i;
}

gets you:

foo.cc: In function `int main()':
foo.cc:3: error: aggregate `index i' has incomplete type and cannot be defined


-- 


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

[Bug c++/21713] [3.4 Regression] Syntax error

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||rejects-valid
  Known to fail||3.3.3 3.0.4 3.2.3 3.4.0
  Known to work||2.95 4.0.0 4.1.0
Summary|Syntax error|[3.4 Regression] Syntax
   ||error
   Target Milestone|--- |3.4.5


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

[Bug c++/21713] [3.4 Regression] Syntax error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-22 
20:30 ---
Confirmed, fixed in 4.0.0 at least but a regression from 2.95.3.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-22 20:30:14
   date||


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

[Bug c++/21713] [3.4 Regression] Syntax error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-22 
20:38 ---
Fixed in 3.4.4 and above at least.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|3.4.5   |3.4.4


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

[Bug c++/21713] [3.4 Regression] Syntax error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-22 
20:43 ---
Reopening to ...

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug c++/21713] [3.4 Regression] Syntax error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-22 
20:43 ---
Mark as a dup of bug 15862.

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

-- 
   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/15862] [3.4/4.5 Regression] 'enum yn' fails

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-22 
20:43 ---
*** Bug 21713 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||igodard at pacbell dot net


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

[Bug c++/18327] [3.3 Regression] ICE while compiling valid c code with g++

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-22 
20:59 ---
Fixed for 3.4.4 so closing as such.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|3.4.5   |3.4.4


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

[Bug c++/20407] Rejects valid C99 for the C++ front-end

[pinskia at gcc dot gnu dot org]

-- 
Bug 20407 depends on bug 18327, which changed state.

Bug 18327 Summary: [3.3 Regression] ICE while compiling valid c code with g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18327

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug web/21679] Download > Releases doesn't take me to appropriate info

[gerald at pfeifer dot com]

--- Additional Comments From gerald at pfeifer dot com  2005-05-22 21:00 
---
I just committed the following patch.

PR web/21679
Add links to the Releases and Snapshots pages near the top of the
navigation bar (the former replacing the current Timline link) and
remove these links from the Download section in the navigation.

This resolves the usability problem described in comment #4; it removes
the "Timeline" link, which also is somewhat problematic (in that it did
not provide the development roadmap nor snapshots), in favor of one link
for releases and snapshots, each.

There are two different paths two downloading a release: one via the
Releases page (which provides various options) and one via the Download
section and the two links there.

The only issue I do not agree with is the usability of the mirrors page:
all one needs to do is choose one mirror site (= selecting a link) and
then navigate to the releases (or snapshots) subdirectory there (= selecting
another link out quite few).


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/15405] [3.4 Regression] Bug box, verify_flow_info failed when using -funroll-all-loops -O1

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|[3.3/3.4 Regression] Bug|[3.4 Regression] Bug box,
   |box, verify_flow_info failed|verify_flow_info failed when
   |when using -funroll-all-|using -funroll-all-loops -O1
   |loops -O1   |


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

[Bug debug/20830] [3.4 Regression] bad debug info for static nested struct with virtual function

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|[3.3/3.4 Regression] bad|[3.4 Regression] bad debug
   |debug info for static nested|info for static nested
   |struct with virtual function|struct with virtual function


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

[Bug target/21283] [4.0/4.1 regression] ICE with doubles

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-05-22 21:06 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  GCC build triplet|i686-pc-linux-gnu   |
   GCC host triplet|i686-pc-linux-gnu   |
   Keywords||ice-on-valid-code
  Known to fail||4.0.1 4.1.0
  Known to work||3.4.5
   Last reconfirmed|-00-00 00:00:00 |2005-05-22 21:06:04
   date||
Summary|ICE with doubles|[4.0/4.1 regression] ICE
   ||with doubles


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

Re: [Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[Daniel Berlin]

> .
> 
> Nevertheless, even if we are very strict with the definition, moving
> get_type2 out of the loop is not a good idea, since get_type2 might
> potentially be very expensive (and we have no way how to determine
> that this is not the case), thus we would lose in case get_type2
> should be never executed.
> 
> 

Don't we attempt to detect zero trip loops?
(If not, we should :P)

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-05-22 
21:10 ---
Subject: Re:  missed optimization due with
const function and pulling out of loops

> .
> 
> Nevertheless, even if we are very strict with the definition, moving
> get_type2 out of the loop is not a good idea, since get_type2 might
> potentially be very expensive (and we have no way how to determine
> that this is not the case), thus we would lose in case get_type2
> should be never executed.
> 
> 

Don't we attempt to detect zero trip loops?
(If not, we should :P)



-- 


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

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[rakdver at atrey dot karlin dot mff dot cuni dot cz]

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2005-05-22 21:13 ---
Subject: Re:  missed optimization due with const function and pulling out of 
loops

> > Nevertheless, even if we are very strict with the definition, moving
> > get_type2 out of the loop is not a good idea, since get_type2 might
> > potentially be very expensive (and we have no way how to determine
> > that this is not the case), thus we would lose in case get_type2
> > should be never executed.
> > 
> > 
> 
> Don't we attempt to detect zero trip loops?
> (If not, we should :P)

I don't see how this is relevant to the PR.


-- 


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

[Bug libfortran/21376] libfortran "E" output format causes FPE

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-22 
21:17 ---
Subject: Bug 21376

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-22 21:17:43

Modified files:
libgfortran: ChangeLog 
libgfortran/io : write.c 

Log message:
PR libfortran/21376
* io/write.c (output_float): Rework logic to avoid call to log10
with argument equal to zero.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.226&r2=1.227
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/write.c.diff?cvsroot=gcc&r1=1.37&r2=1.38


--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-22 
21:17 ---
Subject: Bug 21376

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-22 21:17:44

Modified files:
libgfortran: ChangeLog 
libgfortran/io : write.c 

Log message:
PR libfortran/21376
* io/write.c (output_float): Rework logic to avoid call to log10
with argument equal to zero.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.37&r2=1.163.2.38
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/write.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.23.2.6&r2=1.23.2.7



-- 


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

[Bug libfortran/21376] libfortran "E" output format causes FPE

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-22 
21:17 ---
Subject: Bug 21376

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-22 21:17:43

Modified files:
libgfortran: ChangeLog 
libgfortran/io : write.c 

Log message:
PR libfortran/21376
* io/write.c (output_float): Rework logic to avoid call to log10
with argument equal to zero.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.226&r2=1.227
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/write.c.diff?cvsroot=gcc&r1=1.37&r2=1.38


--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-22 
21:17 ---
Subject: Bug 21376

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-22 21:17:44

Modified files:
libgfortran: ChangeLog 
libgfortran/io : write.c 

Log message:
PR libfortran/21376
* io/write.c (output_float): Rework logic to avoid call to log10
with argument equal to zero.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.37&r2=1.163.2.38
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/write.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.23.2.6&r2=1.23.2.7



-- 


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

Re: [Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[Daniel Berlin]

On Sun, 2005-05-22 at 21:13 +, rakdver at atrey dot karlin dot mff
dot cuni dot cz wrote:
> --- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
> dot cz  2005-05-22 21:13 ---
> Subject: Re:  missed optimization due with const function and pulling out of 
> loops
> 
> > > Nevertheless, even if we are very strict with the definition, moving
> > > get_type2 out of the loop is not a good idea, since get_type2 might
> > > potentially be very expensive (and we have no way how to determine
> > > that this is not the case), thus we would lose in case get_type2
> > > should be never executed.
> > > 
> > > 
> > 
> > Don't we attempt to detect zero trip loops?
> > (If not, we should :P)
> 
> I don't see how this is relevant to the PR.
> 

Uh, you claimed we won't move get_type2 out, even if it is const,
becuase it might not normally execute.

If we can't prove we don't execute the loop, you should move it out.
Otherwise, your logic would hold for get_type1 just the same, which we
*do* move out of the loop.

IOW, there is no reason to move get_type1 out but not get_type2

> 

[Bug libstdc++/13943] call of overloaded `llabs(int)' is ambiguous

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-05-22 21:20 
---
Actually, I have a much better idea, that I'm testing right now: no need for
complex template-based tricks (in this case, at variance with the case of
classification macros, we *know* the type of the arguments!): llabs and lldiv
are protected by _GLIBCXX_USE_C99, therefore in namespace __gnu_cxx we can
simply do 'using ::llabs' ;)

-- 


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

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-05-22 
21:20 ---
Subject: Re:  missed optimization due with
const function and pulling out of loops

On Sun, 2005-05-22 at 21:13 +, rakdver at atrey dot karlin dot mff
dot cuni dot cz wrote:
> --- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
> dot cz  2005-05-22 21:13 ---
> Subject: Re:  missed optimization due with const function and pulling out of 
> loops
> 
> > > Nevertheless, even if we are very strict with the definition, moving
> > > get_type2 out of the loop is not a good idea, since get_type2 might
> > > potentially be very expensive (and we have no way how to determine
> > > that this is not the case), thus we would lose in case get_type2
> > > should be never executed.
> > > 
> > > 
> > 
> > Don't we attempt to detect zero trip loops?
> > (If not, we should :P)
> 
> I don't see how this is relevant to the PR.
> 

Uh, you claimed we won't move get_type2 out, even if it is const,
becuase it might not normally execute.

If we can't prove we don't execute the loop, you should move it out.
Otherwise, your logic would hold for get_type1 just the same, which we
*do* move out of the loop.

IOW, there is no reason to move get_type1 out but not get_type2

> 



-- 


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

[Bug libfortran/21376] libfortran "E" output format causes FPE

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-05-22 
21:21 ---
Fixed. Thanks for reporting!

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[rakdver at atrey dot karlin dot mff dot cuni dot cz]

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2005-05-22 21:23 ---
Subject: Re:  missed optimization due with const function and pulling out of 
loops

> > > > Nevertheless, even if we are very strict with the definition, moving
> > > > get_type2 out of the loop is not a good idea, since get_type2 might
> > > > potentially be very expensive (and we have no way how to determine
> > > > that this is not the case), thus we would lose in case get_type2
> > > > should be never executed.
> > > > 
> > > > 
> > > 
> > > Don't we attempt to detect zero trip loops?
> > > (If not, we should :P)
> > 
> > I don't see how this is relevant to the PR.
> > 
> 
> Uh, you claimed we won't move get_type2 out, even if it is const,
> becuase it might not normally execute.
> 
> If we can't prove we don't execute the loop, you should move it out.

I still don't understand what you mean.

> Otherwise, your logic would hold for get_type1 just the same, which we
> *do* move out of the loop.
> 
> IOW, there is no reason to move get_type1 out but not get_type2

The reason is that get_type1 is always executed when the loop is
entered, while get_type2 is not.


-- 


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

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[dberlin at gcc dot gnu dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-05-22 
21:25 ---
This is not invalid, we have no good reason to move get_type1 out of the loop
but not get_type2.
We can't cost either of them, yet we move one out of the loop, and not the 
other.

Maybe you should actually look at the dumps and see why we do this, instead of
just randomly claiming it might be expensive when get_type1's call could be just
as expensive.

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |


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

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2005-05-22 
21:29 ---
G you should first try to understand what is happening, and then
reopen the bug.

get_type1 is always executed when the loop is entered, therefore moving it
out of the loop is always a win.

get_type2 does not have to be executed (in case the first call to do_something
exits), thus moving it out may cause problems in case the get_type2 call is
expensive.

-- 
   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-22 
21:32 ---
No this should happen.

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |


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

[Bug libfortran/20006] $ format extension doesn't work

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-05-22 
21:32 ---
OK, let's try it again. The facts are the following:
  1. there is no mechanism in gfortran to issue warnings at runtime when those
depend on compilation flags
  2. the meaning of $ as an edit descriptor is not ambiguous

I will submit a patch to enable $ as an edit descriptor, issue a warning if this
descriptor is found at compile time (for example, in a format statement, or in a
constant format string). And we'll keep this PR open to remember that when point
1 above (no strict conformance warnings in library) is fixed, I'll add the check
needed.

-- 
   What|Removed |Added

  Component|fortran |libfortran


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

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-22 
21:34 ---
Then if you say it is expensive, why do we move the divide above the loop:
#define CONST __attribute__((const))

int get_type1(void) CONST;
int get_type2(void) CONST;

void* cast(void*, int) CONST;

void do_something(void*);

void baz(void* p)
{
while(1)
{
do_something(cast(p, get_type1()));
do_something(cast(p, ((int)p)/4));
}
}

-- 
   What|Removed |Added

 Status|REOPENED|NEW


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

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2005-05-22 
21:36 ---
Do you still believe we should move gettype2 out of the loop???

#define CONST __attribute__((const))

int get_type1(void) CONST;
int get_type2(void) CONST;

void* cast(void*, int) CONST;

void do_something(void*);

void baz(void* p)
{
while(1)
{
do_something(cast(p, get_type1()));
do_something(cast(p, get_type2()));
}
}

void do_something(void)
{
  exit(0);
}

int gettype2(void)
{
  int i, s = 0;

  for (i = 0; i < 100; i++)
s += just_waste_time (i);
  return s;
}

-- 


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

[Bug middle-end/21309] [4.0/4.1 regression] internal compiler error: in expand_mult_const, at expmed.c:2884

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-05-22 21:39 ---
Confirmed, reduced testcase:

char c; void f () { c /= 10; }


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  GCC build triplet|x86_64--netbsd  |
   GCC host triplet|x86_64--netbsd  |
  Known to fail||4.0.1 4.1.0
  Known to work||3.4.5
   Last reconfirmed|-00-00 00:00:00 |2005-05-22 21:39:49
   date||
Summary|internal compiler error: in |[4.0/4.1 regression]
   |expand_mult_const, at   |internal compiler error: in
   |expmed.c:2884   |expand_mult_const, at
   ||expmed.c:2884


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

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2005-05-22 
21:41 ---
As for why we move the division -- most of the time, the behavior described
below will not happen.  So if we have a reasonable estimate on how long the
moved calculation may take (which we have with division), we risk it and move
the computation speculatively even if we are not sure whether it will be
executed or not.

However the function call may spent arbitrary amount of time, which may be a
problem.  Furthermore, some programs use more benevolent definitions of "const"
and "pure" that cause correctness problems in case non-executed call becomes
executed, see PR19828.

-- 


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

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-22 
21:43 ---
const is different from pure, const cannot read from memory.

-- 


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

[Bug java/21714] New: libjava bootstrap failure in java/lang/natConcreteProcess.cc

[cato at df dot lth dot se]

Bootstrapping gcc "4.1.0 20050521 (experimental)" fails when compiling libjava:
  java/lang/natConcreteProcess.cc:25:21: error: pthread.h: No such file or 
directory
  java/lang/natConcreteProcess.cc: In member function 'void
java::lang::ConcreteProcess$ProcessManager::init()':
  java/lang/natConcreteProcess.cc:105: error: 'pthread_self' was not declared in
this scope

because NetBSD 1.6 does not have threads.

This is a regression, since bootstrapping gcc 3.4 works.

-- 
   Summary: libjava bootstrap failure in
java/lang/natConcreteProcess.cc
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cato at df dot lth dot se
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
 GCC build triplet: i386-unknown-netbsdelf1.6.2
  GCC host triplet: i386-unknown-netbsdelf1.6.2
GCC target triplet: i386-unknown-netbsdelf1.6.2


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

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[rakdver at atrey dot karlin dot mff dot cuni dot cz]

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2005-05-22 21:50 ---
Subject: Re:  missed optimization due with const function and pulling out of 
loops

> const is different from pure, const cannot read from memory.

this is something that have been discussed many times; some people like
the definition with "behaves like if" (that enables you for example to
cache or precompute the results of the function) more, and it is used in
several existing programs.  Anyway, the argument that the function may
be costly is valid regardless of whether you want to strictly enforce
the no memory access constraint, or whether you use the more useful
definition.


-- 


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

[Bug libgcj/21714] libjava bootstrap failure in java/lang/natConcreteProcess.cc

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|java|libgcj
   Keywords||build


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

Re: [Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[Daniel Berlin]

On Sun, 2005-05-22 at 21:36 +, rakdver at gcc dot gnu dot org wrote:
> --- Additional Comments From rakdver at gcc dot gnu dot org  2005-05-22 
> 21:36 ---
> Do you still believe we should move gettype2 out of the loop???

Okay, let's compromise.
If i move cgraph do noreturn and infinite loop detection, so that we
know everything we can about do_something and gettype2 that is possible,
and we detect neither for do_something, are you still going to claim
that we shouldn't move it out of the loop?

ISTM that presuming a call in a loop is incredibly expensive seems
wrong, when that call is const. Your case seems the very extreme corner
case, not the common case.

People mark const on simple calls (remember, const can't read from
anything but readonly memory), not huge monster calls that do lots of
stuff.

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-05-22 
21:56 ---
Subject: Re:  missed optimization due with
const function and pulling out of loops

On Sun, 2005-05-22 at 21:36 +, rakdver at gcc dot gnu dot org wrote:
> --- Additional Comments From rakdver at gcc dot gnu dot org  2005-05-22 
> 21:36 ---
> Do you still believe we should move gettype2 out of the loop???

Okay, let's compromise.
If i move cgraph do noreturn and infinite loop detection, so that we
know everything we can about do_something and gettype2 that is possible,
and we detect neither for do_something, are you still going to claim
that we shouldn't move it out of the loop?

ISTM that presuming a call in a loop is incredibly expensive seems
wrong, when that call is const. Your case seems the very extreme corner
case, not the common case.

People mark const on simple calls (remember, const can't read from
anything but readonly memory), not huge monster calls that do lots of
stuff.








-- 


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

Re: [Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[Daniel Berlin]

On Sun, 2005-05-22 at 21:51 +, rakdver at atrey dot karlin dot mff
dot cuni dot cz wrote:
> --- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
> dot cz  2005-05-22 21:50 ---
> Subject: Re:  missed optimization due with const function and pulling out of 
> loops
> 
> > const is different from pure, const cannot read from memory.
> 
> this is something that have been discussed many times; some people like
> the definition with "behaves like if" (that enables you for example to
> cache or precompute the results of the function) more, and it is used in
> several existing programs.  Anyway, the argument that the function may
> be costly is valid regardless of whether you want to strictly enforce
> the no memory access constraint, or whether you use the more useful
> definition.
> 

These people are strictly wrong, and will in fact get burned by the new
pure/const detection (which is better about recursive calls).

We shouldn't let people who have the wrong definition of const get in
the way of optimization

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[rakdver at atrey dot karlin dot mff dot cuni dot cz]

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2005-05-22 22:05 ---
Subject: Re:  missed optimization due with const function and pulling out of 
loops

> > --- Additional Comments From rakdver at gcc dot gnu dot org  2005-05-22 
> > 21:36 ---
> > Do you still believe we should move gettype2 out of the loop???
> 
> Okay, let's compromise.
> If i move cgraph do noreturn and infinite loop detection, so that we
> know everything we can about do_something and gettype2 that is possible,
> and we detect neither for do_something, are you still going to claim
> that we shouldn't move it out of the loop?

If we know that do_something must return (which would currently only be
the case if it was const or pure), gettype2 will be moved out of the loop.

> ISTM that presuming a call in a loop is incredibly expensive seems
> wrong, when that call is const. Your case seems the very extreme corner
> case, not the common case.
> 
> People mark const on simple calls (remember, const can't read from
> anything but readonly memory (*) ), not huge monster calls that do lots of
> stuff.

Except when they don't :-)  Moving 'pure' functions out of loops without
checking whether they must be executed or nor causes correctness
problems.  For 'const' functions this is more interesting, as there
are definitions of 'const' that allow things that would make it
incorrect, and definitions that don't (especially (*) is by no means
accepted by everyone -- mentioning it at a mailing list is a good start
for a flame war).  As you claim, const functions usually are fast, so
by not moving them we do not cause a disaster.  By moving them, we can.


-- 


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

[Bug tree-optimization/21712] missed optimization due with const function and pulling out of loops

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-05-22 
22:05 ---
Subject: Re:  missed optimization due with
const function and pulling out of loops

On Sun, 2005-05-22 at 21:51 +, rakdver at atrey dot karlin dot mff
dot cuni dot cz wrote:
> --- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
> dot cz  2005-05-22 21:50 ---
> Subject: Re:  missed optimization due with const function and pulling out of 
> loops
> 
> > const is different from pure, const cannot read from memory.
> 
> this is something that have been discussed many times; some people like
> the definition with "behaves like if" (that enables you for example to
> cache or precompute the results of the function) more, and it is used in
> several existing programs.  Anyway, the argument that the function may
> be costly is valid regardless of whether you want to strictly enforce
> the no memory access constraint, or whether you use the more useful
> definition.
> 

These people are strictly wrong, and will in fact get burned by the new
pure/const detection (which is better about recursive calls).

We shouldn't let people who have the wrong definition of const get in
the way of optimization



-- 


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