[Bug target/19724] ICE when building a m68hc11 cross-compiler on ia64

--- Additional Comments From wilson at gcc dot gnu dot org 2005-02-20 00:34 --- I built an m68hc11 cross compiler from mainline, last updated Thursday, without binutils/newlib, on an IA-64 Debian unstable system whose system compiler is gcc-3.3.5 (Debian 1:3.3.5-2). The result can compi

[Bug c++/20099] New: -pthreads should imply -fno-threadsafe-statics

The '-fno-threadsafe-statics' is purely a pessimization for POSIX pthreads code. Since the POSIX standard already requires a mutex around operations that modify data, and the C++ standard specifies lazy initialization, POSIX code will already have mutexes to make static initialization thread safe.

[Bug c++/20098] Unresolved dependent "static const" symbol in template

--- Additional Comments From wwieser at gmx dot de 2005-02-20 00:49 --- Subject: Re: Unresolved dependent "static const" symbol in template On Sunday 20 February 2005 01:34, pinskia at gcc dot gnu dot org wrote: > Yes you need to have declare the storage for the static variables (even >

[Bug c++/20099] -pthreads should imply -fno-threadsafe-statics

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-20 00:52 --- Note -fthreadsafe-statics, never made it into the FSF's 3.4.x, only 4.0.0. Also note this is required by the C++ ABI. -- What|Removed |Added

[Bug c++/20099] -pthreads should imply -fno-threadsafe-statics

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-20 01:01 --- Actually this code was added because well it is hard to deal with mutexies in these cases. -- What|Removed |Added ---

[Bug c++/20099] -pthreads should imply -fno-threadsafe-statics

--- Additional Comments From davids at webmaster dot com 2005-02-20 01:09 --- Do we agree that this is a pure pessimization for POSIX-compliant code? Do we agree that POSIX already requires a mutex to protect code that might modify an object? -- What|Removed

[Bug c++/20099] -pthreads should imply -fno-threadsafe-statics

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-20 01:14 --- No, see the following code: class A { A(); int t; }; void f() { static A a; } So how can someone know that A will modify memory? In fact the mutex is made sure so that a is only initialized once.

[Bug libstdc++/20091] [4.0 Regression] 18_support/14026.cc execution test fails

--- Additional Comments From hp at gcc dot gnu dot org 2005-02-20 02:01 --- Also on cris-elf and mmix-knuth-mmixware, regression introduced between LAST_UPDATED "Sat Feb 19 00:34:51 UTC 2005" and "Sat Feb 19 14:33:53 UTC 2005". (This narrows the window quite a bit.) -- http://gcc.gnu

[Bug c++/20099] -pthreads should imply -fno-threadsafe-statics

--- Additional Comments From davids at webmaster dot com 2005-02-20 02:46 --- In your example: class A { A(); int t; }; void f() { static A a; } I don't get it. What's the problem with this? Obviously, if you plan to call 'f()' from multiple threads, you must do it while holding

[Bug c++/20099] -pthreads should imply -fno-threadsafe-statics

--- Additional Comments From davids at webmaster dot com 2005-02-20 02:50 --- You say, "how can someone know that A will modify memory"? The answer is, the C++ standard says so, section 7.1.2. They simply read that section of the standard, and they know that the function might modify me

[Bug tree-optimization/20100] New: [4.0 regression] static call incorrectly judged constant, moved out of loop

In the test-case to be attached and entered in gcc.c-torture/execute alt. gcc.dg/torture as prN-1.c, there's a call to get_n, which is moved out of the loop. This happens before rtl passes. The FC3-bundled gcc known as gcc-3.4.2-6.fc3 (for i686) does not have this bug. Trunk as of LAST_UPDATE

[Bug libfortran/19872] closed and re-opened file not overwriten

--- Additional Comments From bdavis at gcc dot gnu dot org 2005-02-20 03:09 --- proposed patch: http://gcc.gnu.org/ml/fortran/2005-02/msg00182.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19872

[Bug tree-optimization/20100] [4.0 regression] static call incorrectly judged constant, moved out of loop

--- Additional Comments From hp at gcc dot gnu dot org 2005-02-20 03:10 --- Created an attachment (id=8237) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8237&action=view) Test-case The " && n < 5" condition is there only to make the test terminate, as the bug would otherwise caus

[Bug tree-optimization/20100] [4.0 regression] static call incorrectly judged constant, moved out of loop

--- Additional Comments From hp at gcc dot gnu dot org 2005-02-20 03:16 --- Correction to the description: s/there's a call to get_n/in function get_n, there's loop calling function ring_empty/. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20100

[Bug tree-optimization/20100] [4.0 regression] static call incorrectly judged constant, moved out of loop

--- Additional Comments From hp at gcc dot gnu dot org 2005-02-20 03:32 --- Observed at -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20100

Bug

The attached code produces some garbage. With -O3 even worse. Attached source and assembly file. Fikret Skrgic int main() { unsigned * a=malloc(1*sizeof(unsigned)), * b=a+1, * c=a+2, * d=a+3; register unsigned x, y, z, w; register int i; for(i=0;i<625;

[Bug libfortran/20085] iargc returns wrong count for number of program arguments

--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2005-02-20 05:00 --- Patch is here http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01148.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20085

[Bug fortran/20101] New: zero prints incorrectly with 1pe12.4

I have never seen zero printed with a negative exponent before - [dir:~/tests/gfortran] dir% gfortran -o format format.f [dir:~/tests/gfortran] dir% format 0.E-01 [dir:~/tests/gfortran] dir% cat format.f program main zero=0 write(6,1000)zero 1000 format(1pe12.4) end

[Bug rtl-optimization/20100] [4.0 regression] static call incorrectly judged constant, moved out of loop

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-20 06:16 --- Currently in 4.0.x, pure/const is found by the rtl and not by tree wise (now on the tree profiling branch it is found on the tree level). Then again this might be fixed by: 2005-02-19 Zdenek Dvorak <[EM

[Bug libstdc++/20091] [4.0 Regression] 18_support/14026.cc execution test fails

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-20 06:18 --- This was caused by: 2005-02-18 Richard Henderson <[EMAIL PROTECTED]> PR libstdc++/10606 * except.c (do_get_exception_ptr): New. (expand_start_catch_block): Use it. 2005-02-18 Ric

[Bug c++/20099] -pthreads should imply -fno-threadsafe-statics

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-20 06:21 --- No, the point is if you expose an API to the user, why should the user of the API know that you modify the memory. Let the compiler do the work for you instead of doing the work in this case. --

[Bug libfortran/19872] closed and re-opened file not overwriten

-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||patch

[Bug libfortran/20101] zero prints incorrectly with 1pe12.4

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-20 06:28 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW

[Bug middle-end/5169] paradoxical subreg problem

--- Additional Comments From schlie at comcast dot net 2005-02-20 06:44 --- (In reply to comment #7) With respect to: and paradoxical subreg semantics on targets which support modes_tieable (assuming that paradoxical subreg semantics appl

[Bug middle-end/5169] paradoxical subreg problem

--- Additional Comments From schlie at comcast dot net 2005-02-20 06:50 --- (In reply to comment #8) > - nor does it seem to make sence in any circumstance to referance a wider > logical value than may be stored in a register or memory, without presuming > it's higher-order bits are of s

Re: Bug

> The attached code produces some garbage. With -O3 even worse. Attached > source and assembly file. How does that relate to the compiler? Could you precisely describe what you think goes wrong with the compiler here? -- Eric Botcazou

[Bug libfortran/19302] intrinsic_nearest.f90 fails

--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-20 07:42 --- Proposed fix: http://gcc.gnu.org/ml/fortran/2005-02/msg00098.html -- What|Removed |Added

<    1   2