[Bug target/39224] ABI attribute doesn't work with long double
--- Comment #2 from ktietz at gcc dot gnu dot org 2009-02-18 08:18 --- (In reply to comment #1) I think long double on w64 is the same as double. I am not sure if gcc.dg/callabi/func-1.c is a valid test. the long double is supported as 96-bit floating point for gcc. This isn't as ms_abi declares it, but I follow here the 32-bit port. So we allow higher precision, and by vendor specific headers it has not much affects, beside that the vendor specific scanf/printf functions can't print it proper. Therefore the mingw runtime provides C99 compliant (and gnu-style compiant) alternatives to print/scan them. I am verifying it at the moment for w64 target, if we have here same issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #11 from jakub at gcc dot gnu dot org 2009-02-18 08:20 --- Unfortunately I'm still seeing these warnings on the original unreduced testcase. I'll attach them momentarily. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #12 from jakub at gcc dot gnu dot org 2009-02-18 08:23 --- Created an attachment (id=17320) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17320action=view) ai2.ii.bz2 Original (almost) unreduced testcase. The: warning: dereferencing pointer 'anonymous' does break strict-aliasing rules warnings are now gone, but the: warning: dereferencing pointer '__x.1949' does break strict-aliasing rules (9 of them) are not. cc1plus -m32 -O2 -Wall -quiet to reproduce. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #13 from jakub at gcc dot gnu dot org 2009-02-18 08:24 --- Created an attachment (id=17321) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17321action=view) ai3.ii.bz2 Slightly reduced. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug regression/39228] New: 387 optimised __builtin_isinf() gives incorrect result
#include stdio.h
#include math.h
int main()
{
double a= 10.0;
double b= 1e+308;
printf(%d %d %d\n, isinf(a*b), __builtin_isinf(a*b), __isinf(a*b));
return 0;
}
mtay...@drizzle-dev:~$ gcc -o test test.c
mtay...@drizzle-dev:~$ ./test
0 0 1
mtay...@drizzle-dev:~$ gcc -o test test.c -std=c99
mtay...@drizzle-dev:~$ ./test
1 0 1
mtay...@drizzle-dev:~$ gcc -o test test.c -mfpmath=sse -march=pentium4
mtay...@drizzle-dev:~$ ./test
1 1 1
mtay...@drizzle-dev:~$ g++ -o test test.c
mtay...@drizzle-dev:~$ ./test
1 0 1
Originally I found the simple isinf() case to be different on x86 than x86-64,
ppc32 and sparc (32 and 64).
After more research, I found that x86-64 uses the sse instructions to do it
(and using sse is the only way for __builtin_isinf() to produce correct
results). For the g++ built version, it calls __isinf() instead of inlining
(and as can be seen, the __isinf() version is always correct).
Specifically, it's because the optimised 387 code is doing the math in double
extended precision inside the FPU. 10.0*1e308 fits in 80bits but not in 64bit.
Any code that forces it to be stored and loaded gets the correct result too.
e.g.
mtay...@drizzle-dev:~$ cat test-simple.c
#include stdio.h
#include math.h
int main()
{
double a= 10.0;
double b= 1e+308;
volatiledouble c= a*b;
printf(%d\n, isinf(c));
return 0;
}
mtay...@drizzle-dev:~$ gcc -o test-simple test-simple.c
mtay...@drizzle-dev:~$ ./test-simple
1
With this code you can easily see the load and store:
8048407: dc 0d 18 85 04 08 fmull 0x8048518
804840d: dd 5d f0fstpl -0x10(%ebp)
8048410: dd 45 f0fldl -0x10(%ebp)
8048413: d9 e5 fxam
While if you remove volatile, the load and store doesn't happen (at least on
-O3, on -O0 it hasn't been optimised away):
8048407: dc 0d 18 85 04 08 fmull 0x8048518
804840d: c7 44 24 04 10 85 04movl $0x8048510,0x4(%esp)
8048414: 08
8048415: c7 04 24 01 00 00 00movl $0x1,(%esp)
804841c: d9 e5 fxam
This is also a regression from 4.2.4 as it just calls isinf() and doesn't
expand the 387 code inline. My guess is the 387 optimisation was added in 4.3.
Recommended fix: store and load in the 387 version so to operate on same
precision as elsewhere.
--
Summary: 387 optimised __builtin_isinf() gives incorrect result
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stewart at flamingspork dot com
GCC build triplet: gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12)
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39228
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #14 from jakub at gcc dot gnu dot org 2009-02-18 08:31 --- Created an attachment (id=17322) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17322action=view) glibmm.ii.bz2 Testcase from another package. Similarly to the ai* (wesnoth-1.5), in this case also some warnings went away with yesterday's fix, but not all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug target/39224] ABI attribute doesn't work with long double
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-02-18 08:47 --- (In reply to comment #2) I am verifying it at the moment for w64 target, if we have here same issues. Yes, on w64 targets we have the same issue. By adding print methods, it seems that the return value of the foreign abi is passed/treated wrong. This testcases were run by me last time about beginning of January this year and they seem to work fine at this date. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-18 08:47:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
[Bug target/39222] out of memory bootstrapping
--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-18 08:54 --- Yeah, with ulimit you can always pick some limit almost any change might go over. As a bug should be only considered if memory usage increases a lot, daily tiny increases and decreases in memory usage aren't a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39222
[Bug tree-optimization/26939] loop number of iterations analysis not working
--- Comment #23 from rguenther at suse dot de 2009-02-18 09:34 --- Subject: Re: loop number of iterations analysis not working On Wed, 18 Feb 2009, rakdver at kam dot mff dot cuni dot cz wrote: --- Comment #21 from rakdver at kam dot mff dot cuni dot cz 2009-02-18 04:11 --- Subject: Re: loop number of iterations analysis not working If the program terminates before i would wrap, then the number of iterations was not MAXINT. And since it can't wrap, it is not infinite in any case. I agree you can't prove the number of iterations (since bar could exit), but the requiring the assumption i != MAXINT still seems useless. What do you propose that the number of iterations analysis should return, then? Note that the function call is artificial in the testcase (just to make the loop non-empty). A poor choice admittedly ;) But yes, I expected that i != MAXINT follows from i's signedness. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug fortran/39229] New: fixed-form: silent line truncation in procedure calls
If 'warn' after PRINT is removed, the snippet is accepted as is, without further warning. I'm not sure if this kind of thing is legal to begin with, but I'd at least expect a warning for both truncated lines. $ cat trunc.f PRINT *, MIN(1 nowarn , 2) ! warn END $ gfortran-svn -ffixed-form -Wall -Wextra trunc.f trunc.f:2.72: , 2) 1 Warning: Line truncated at (1) $ gfortran-svn -v gcc version 4.4.0 20090217 (experimental) (GCC) -- Summary: fixed-form: silent line truncation in procedure calls Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39229
[Bug target/39228] [4.3/4.4 Regression] 387 optimised __builtin_isinf() gives incorrect result
--- Comment #1 from ubizjak at gmail dot com 2009-02-18 09:47 --- Looking into it. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Component|regression |target Ever Confirmed|0 |1 GCC build triplet|gcc version 4.3.2 (Ubuntu | |4.3.2-1ubuntu12)| Last reconfirmed|-00-00 00:00:00 |2009-02-18 09:47:25 date|| Summary|387 optimised |[4.3/4.4 Regression] 387 |__builtin_isinf() gives |optimised __builtin_isinf() |incorrect result|gives incorrect result Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39228
[Bug target/39082] union with long double doesn't follow x86-64 psABI
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2009-02-18 09:51 --- Please make sure the warning is issued only for appropriate languages (it is not needed in Ada for example and the wording doesn't make sense). TIA. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39082
[Bug c/39223] volatile bug on AVR
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-18 10:03 --- Please fill out GCC version this bug is reported against. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39223
[Bug c++/39225] ICE if destructor doen't match class name
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-18 10:11 --- It works for me with the release-checking built 4.3.3 release (as well as 4.3.0, 4.3.1 and 4.3.2). With the branch r143959 and checking enabled it gives test.cc:6: internal compiler error: tree check: expected class type, have exceptional (identifier_node) in constructor_name_full, at cp/name-lookup.c:1715 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. so I'm not sure if this is a regression. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-checking, ice-on- ||invalid-code Known to fail||4.3.4 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39225
[Bug target/39222] out of memory bootstrapping
--- Comment #4 from aj at gcc dot gnu dot org 2009-02-18 10:17 --- Increasing ulimit from 100 to 110 (10 %!) did not help, increasing it to 120 helped. So, we have now hit quite some increase of memory usage with just this single commit and not just a few bytes... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39222
[Bug fortran/39229] No warning of truncated lines if a continuation line follows
--- Comment #1 from burnus at gcc dot gnu dot org 2009-02-18 10:20 --- I think that also happens if one does not have a procedure call but simply have a succeeding continuation line, e.g.: print *, min(1,2) [...] some long line , 2 And it seems to happen also with free-form code which has warning enabled by default. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-18 10:20:31 date|| Summary|fixed-form: silent line |No warning of truncated |truncation in procedure |lines if a continuation line |calls |follows http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39229
Re: [Bug target/39226] New: [4.4 Regression] gcc_assert (verify_initial_elim_offsets ()); ICE
This is mostly likely due to my no micro code patch. I see what causes
it tommorow.
Sent from my iPhone
On Feb 17, 2009, at 11:55 PM, jakub at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
/* { dg-do compile } */
/* { dg-options -O2 } */
/* { dg-options -O2 -mtune=cell -mminimal-toc { target { powerpc*-
*-* lp64
} } } */
struct A
{
char *a;
unsigned int b : 1;
unsigned int c : 31;
};
struct B
{
struct A *d;
};
void
foo (struct B *x, unsigned long y)
{
if (x-d[y].c)
return;
if (x-d[y].b)
x-d[y].a = 0;
}
ICEs with -m64 -O2 -mtune=cell -mminimal-toc, as elimination offsets
change.
--
Summary: [4.4 Regression] gcc_assert
(verify_initial_elim_offsets
()); ICE
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39226
[Bug target/39226] [4.4 Regression] gcc_assert (verify_initial_elim_offsets ()); ICE
--- Comment #1 from pinskia at gmail dot com 2009-02-18 10:30 ---
Subject: Re: New: [4.4 Regression] gcc_assert (verify_initial_elim_offsets
()); ICE
This is mostly likely due to my no micro code patch. I see what causes
it tommorow.
Sent from my iPhone
On Feb 17, 2009, at 11:55 PM, jakub at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org
wrote:
/* { dg-do compile } */
/* { dg-options -O2 } */
/* { dg-options -O2 -mtune=cell -mminimal-toc { target { powerpc*-
*-* lp64
} } } */
struct A
{
char *a;
unsigned int b : 1;
unsigned int c : 31;
};
struct B
{
struct A *d;
};
void
foo (struct B *x, unsigned long y)
{
if (x-d[y].c)
return;
if (x-d[y].b)
x-d[y].a = 0;
}
ICEs with -m64 -O2 -mtune=cell -mminimal-toc, as elimination offsets
change.
--
Summary: [4.4 Regression] gcc_assert
(verify_initial_elim_offsets
()); ICE
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39226
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39226
[Bug target/39228] [4.3/4.4 Regression] 387 optimised __builtin_isinf() gives incorrect result
--- Comment #2 from ubizjak at gmail dot com 2009-02-18 10:33 --- Created an attachment (id=17323) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17323action=view) patch Patch currently in testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39228
[Bug fortran/39230] New: ASSOCIATED undefined pointers
Consider the following snippet: implicit none integer, pointer :: p print *,associated(p) end This is actually invalid and should probably trigger a runtime error. Section 13.7.13 of the Fortran 2003 standard says that the pointer argument of ASSOCIATED should not be undefined, which it is in the case above (cf. section 16.4.2). Also see the discussion in http://gcc.gnu.org/ml/fortran/2006-06/msg00235.html and follow-ups. Right now the above program simply prints T. This is kind of dangerous, since it looks like the pointer is associated with some target, while in fact it is not. ifort prints F. I didn't check other compilers. -- Summary: ASSOCIATED undefined pointers Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39230
[Bug target/39224] ABI attribute doesn't work with long double
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-02-18 10:45 --- ok, I found the issue, which causes here the problem. The x86_64 abi returns TFmode in rax,edx which is stored in aligned stack variable as 96 bits, but the upper 32-bits (which have to be zero initialized) aren't set. For w64 there are stored 128-bit in this case as desired. So the compare of those two results is failing, because on x86_64 abi the upper 32-bits have random values. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
[Bug target/39222] out of memory bootstrapping
--- Comment #5 from jakub at gcc dot gnu dot org 2009-02-18 10:46 --- But not on the same source, but different one (insn-recog.c grew because of that change). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39222
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-02-18 10:54 --- *sigh* Looks like PR39074. I chickened out to backport this from a-i branch... I'll have a second look. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug c++/39225] ICE if destructor doen't match class name
--- Comment #3 from christi at uni-hd dot de 2009-02-18 11:10 --- Created an attachment (id=17324) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17324action=view) preprocessed test.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39225
[Bug target/39228] [4.3/4.4 Regression] 387 optimised __builtin_isinf() gives incorrect result
--- Comment #3 from stewart at flamingspork dot com 2009-02-18 11:20
---
To implement a work around for us, I'm proposing the patch below.
- the tmp2 being volatile was for who knows what reason (old code)
- The check should (on c99 systems or those with the right compile options
enabled, which we do have) detect that we calculate at 80bits but store at 64.
- the volatile temp should ensure a write to memory (and subsequent read)
- where the check is false, the whole code path should be optimised out.
Perhaps it should also be surrounded by an ifdef for the specific gcc version
(3.4)?
Thoughts are very welcome.
=== modified file 'drizzled/function/math/round.cc'
--- drizzled/function/math/round.cc 2008-12-16 06:21:46 +
+++ drizzled/function/math/round.cc 2009-02-18 09:59:40 +
@@ -111,14 +111,22 @@
tmp2 is here to avoid return the value with 80 bit precision
This will fix that the test round(0.1,1) = round(0.1,1) is true
*/
- volatile double tmp2;
+ double tmp2;
tmp=(abs_dec array_elements(log_10) ?
log_10[abs_dec] : pow(10.0,(double) abs_dec));
+ double value_times_tmp= value * tmp;
+
+ if(sizeof(double) sizeof(double_t))
+ {
+volatile double t= value_times_tmp;
+value_times_tmp= t;
+ }
+
if (dec_negative isinf(tmp))
tmp2= 0;
- else if (!dec_negative isinf(value * tmp))
+ else if (!dec_negative isinf(value_times_tmp))
tmp2= value;
else if (truncate)
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39228
[Bug target/39224] ABI attribute doesn't work with long double
--- Comment #5 from ubizjak at gmail dot com 2009-02-18 12:06 --- (In reply to comment #4) ok, I found the issue, which causes here the problem. The x86_64 abi returns TFmode in rax,edx which is stored in aligned stack XFmode -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
[Bug target/39224] ABI attribute doesn't work with long double
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-02-18 12:11 --- (In reply to comment #5) (In reply to comment #4) ok, I found the issue, which causes here the problem. The x86_64 abi returns TFmode in rax,edx which is stored in aligned stack XFmode right, sorry I meant XFmode -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
[Bug tree-optimization/39203] LTO and -fwhole-program do not play along well
--- Comment #13 from dnovillo at google dot com 2009-02-18 12:26 --- Subject: Re: LTO and -fwhole-program do not play along well On Tue, Feb 17, 2009 at 20:42, hubicka at ucw dot cz gcc-bugzi...@gcc.gnu.org wrote: --- Comment #12 from hubicka at ucw dot cz 2009-02-18 01:42 --- Subject: Re: LTO and -fwhole-program do not play along well I believe we should be set already. During LTO read, we execute ipa_passes, which runs all_small_ipa_passes. So, pass_ipa_function_and_variable_visibility is run both while writing the IL and right after we read it in. Is that what you were referring to? Well, you need to localize stuff at WHOPR stage, so small IPA passes are unlikely going to be executable there except for those not needing function bodies (like the visibility pass, but unlike inlining and other stuff included). Are those still skipped via the lto flag gate? Yes, with whopr, the only time we can ever operate in whole-program mode is when we run the analysis stage (-fwpa). The other two stages cannot operate in whole-program mode as they only deal with a partial graph. For -flto, however, we can enable whole-program mode as we are dealing with the whole callgraph at once. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39203
[Bug target/39226] [4.4 Regression] gcc_assert (verify_initial_elim_offsets ()); ICE
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-18 12:28 --- Yeah. Unlike anddi3_internal3_mc insn, anddi3_internal3_nomc only has an alternative with t for the and64_2_operand that is not slightly disparaged (?s), so for masks that match mask_operand or mask64_operand reload decides to reload the DImode constant into register, which needs to be put into memory and needs a TOC register etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39226
[Bug gcov-profile/39220] -fprofile-generate and -fprofile-use are not equivalent to their component flags. Get directories wrong
--- Comment #4 from jeremy at jeremybennett dot com 2009-02-18 12:28 --- Thanks for the advice. I had not realized that ccache was a separate program. I've taken up the issue with them. Jeremy -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39220
[Bug tree-optimization/39207] [4.4 Regression] Strict aliasing warnings in libstdc++ headers
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-02-18 12:56 --- Ok, a backported patch fixes all three new testcases. I was avoiding the backport to avoid late performance and/or compile-time regressions, so I'll give the patch (and one accompanied change that went to the branch to fix performance regressions) some performance testing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|ASSIGNED Last reconfirmed|2009-02-17 10:41:14 |2009-02-18 12:56:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
[Bug rtl-optimization/17387] Redundant zero extension instructions in loop optimization
--- Comment #23 from bonzini at gnu dot org 2009-02-18 13:02 --- Gcc doesn't know/remember movlS(,%rax,4), %eax will zero extend to 64bit. I don't know you can touch only the lower 32bit bits. This could be fixed by LOAD_EXTEND_OP, right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
[Bug c/32061] (Wlogical-op) wording of warning of constant logicials need improvement
--- Comment #5 from manu at gcc dot gnu dot org 2009-02-18 13:13 --- Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00824.html -- manu at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||02/msg00824.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32061
[Bug c++/36954] Wrong warning with -Wlogical-op
--- Comment #1 from manu at gcc dot gnu dot org 2009-02-18 13:15 --- Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00824.html -- manu at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||02/msg00824.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36954
[Bug target/39082] union with long double doesn't follow x86-64 psABI
--- Comment #11 from hjl dot tools at gmail dot com 2009-02-18 14:08 --- (In reply to comment #10) Please make sure the warning is issued only for appropriate languages (it is not needed in Ada for example and the wording doesn't make sense). TIA. I believe that warning is turned on for C ObjC C++ ObjC++ only. Did you run into any problems? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39082
[Bug target/39224] ABI attribute doesn't work with long double
--- Comment #7 from hjl dot tools at gmail dot com 2009-02-18 14:13 --- (In reply to comment #6) (In reply to comment #5) (In reply to comment #4) ok, I found the issue, which causes here the problem. The x86_64 abi returns TFmode in rax,edx which is stored in aligned stack XFmode right, sorry I meant XFmode w64 ABI doesn't cover XFmode. Why do you use integer registers for XFmode? It doesn't make any senses to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
[Bug target/39228] [4.3/4.4 Regression] 387 optimised __builtin_isinf() gives incorrect result
--- Comment #4 from ubizjak at gmail dot com 2009-02-18 14:15 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00825.html -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||02/msg00825.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39228
[Bug target/39224] ABI attribute doesn't work with long double
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-02-18 14:23 --- (In reply to comment #7) (In reply to comment #6) (In reply to comment #5) (In reply to comment #4) ok, I found the issue, which causes here the problem. The x86_64 abi returns TFmode in rax,edx which is stored in aligned stack XFmode right, sorry I meant XFmode w64 ABI doesn't cover XFmode. Why do you use integer registers for XFmode? It doesn't make any senses to me. As I said above there are two reasons. First 32-bit code supports XFmode, too. Also the vendor specific library supports 96-bit floating point, too. But not as native type, they use a struct for this (what is the current implementation in gcc to pass them as memory reference). So there is no good reason for not supporting XFmode types for w64 IMHO. This issue here seems to be more the store size in x86_64 abi. Hasn't x86_64 also the need to have those types store 16-bytes aligned? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
[Bug c/39231] Optimized code gives wrong result
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-18 14:37 --- gcc -o t t.c -O2 -Wstrict-overflow t.c: In function main: t.c:13: warning: assuming signed overflow does not occur when simplifying conditional to constant negating signed 0x8000 invokes undefined behavior. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39231
[Bug target/39082] union with long double doesn't follow x86-64 psABI
--- Comment #14 from hjl dot tools at gmail dot com 2009-02-18 15:10 --- (In reply to comment #12) I believe that warning is turned on for C ObjC C++ ObjC++ only. Wrong. A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00834.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39082
[Bug fortran/39229] No warning of truncated lines if a continuation line follows
--- Comment #2 from burnus at gcc dot gnu dot org 2009-02-18 16:41 --- I'm not sure if this kind of thing is legal to begin with Well, the Fortran standard only has: Free form: If a line consists entirely of characters of default kind (4.4.4), it may contain at most 132 characters. If a line contains any character that is not of default kind, the maximum number of characters allowed on the line is processor dependent. [3.3.1] Fixed form: If a source line contains only default kind characters, it shall contain exactly 72 characters; otherwise, its maximum number of characters is processor dependent. Thus a conforming program may not have more than 72/132 characters in a line (incl. comments) and this is no issue. The standard does not write anything about what the compiler has to do. Common is that 73+ characters are ignored in fixed form and thus several people used it to put comments there. Additionally, everyone assumes that longer lines are OK as long as long as there is a ! before 72/132. (- all compilers I know do so). As free form indicates non-legacy code and as F90 has ! comments, the truncation trick wont work. Some compilers truncates, some give an error, some a warning (and stop - or continue reading the line) and some simply read on. gfortran does: Fixed form: Truncating + optional warning Free form: Truncating + default-on warning optionally: Accept longer lines (n characters or infinity) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39229
[Bug c/39232] apparent bizarre miscompilation on AVR
--- Comment #1 from regehr at cs dot utah dot edu 2009-02-18 16:41 --- Created an attachment (id=17326) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17326action=view) failure-inducing C program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39232
[Bug c++/39219] attribute doesn't work with enums properly
--- Comment #6 from sebor at roguewave dot com 2009-02-18 16:50 ---
(In reply to comment #5)
Should attribute work on enum constants?
Not sure if this is a question for me but IMO, it should. I would expect
individual enumerators to be more heavily referenced than their types
(sometimes even exclusively) and the warning to be of equal importance
for both. In addition, just like declaring a class deprecated implies
that all members of the class are deprecated, so should declaring
an enumeration deprecated imply that all its enumerators are.
Finally, since enumerators of unnamed types can be declared deprecated
not issuing the warning would make such declarations pointless:
$ cat u.cpp g++ -W -Wall -Werror -c u.cpp
enum __attribute__((deprecated)) { e };
int i = e; // warning missing
$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39219
[Bug tree-optimization/39233] New: [4.4 Regression] ivopts + vrp miscompilation
extern void abort (void);
__attribute__((noinline)) void
foo (void *p)
{
long l = (long) p;
if (l 0 || l 6)
abort ();
}
int
main ()
{
int i;
for (i = 6; i = 0; i--)
foo ((void *) (long) i);
return 0;
}
is miscompiled (into endless loop). First ivopts decides to use a pointer IV,
going from (void *) 6 down, with (void *) ivtmp.51 != (void *) -1 as loop
condition, then VRP comes in and as pointers can never wrap around, optimizes
the loop condition into 1.
--
Summary: [4.4 Regression] ivopts + vrp miscompilation
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39233
[Bug tree-optimization/39233] [4.4 Regression] ivopts + vrp miscompilation
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39233
[Bug tree-optimization/39233] [4.4 Regression] ivopts + vrp miscompilation
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-18 17:24 --- Caused by PR31358. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39233
[Bug fortran/39230] ASSOCIATED undefined pointers
--- Comment #1 from burnus at gcc dot gnu dot org 2009-02-18 17:28 ---
This is actually invalid
Yes, but this is a requirement to the program(mer) not to the compiler.
and should probably trigger a runtime error.
Yes, but only with some checking option, otherwise it really gets too slow.
Especially in the general case, you cannot easily check this. Setting
by default ptr = NULL only hides the problem.
* * *
I think what you want is some -fcheck=pointer option (I think there is a PR
about his). That option would initialize pointer with some bogus value, e.g.
extern intptr_t _gfortran_bogus_pointer;
integer *p, *bogus_local;
bogus_local = _gfortran_bogus_pointer;
p = bogus_local
{
logical D14;
if (p == _gfortran_bogus_pointer)
_gfortran_runtime_error(Bogus pointer at %C);
D14 = (p == NULL)
print *, D14
}
_gfortran_bogus_pointer is in libgfortran and the advantage is that one can
also check called arguments, e.g.
call foo(ptr)
...
subroutine foo(ptr)
if(associated(ptr)) ...
Disadvantage is the speed, but that should not matter for a checking option.
The checking has to be done before:
- ASSOCIATED, DEALLOCATE
- Actual arguments, which don't expect a pointer argument
- Expressions which use the pointer (esp. var = ptr; is ptr = uninit_ptr
valid?)
- BUT: Not for allocate, NULL(uninitialized_pointer) or ptr = NULL(),
nullify(ptr), ...
I was once about to implement this, but especially if you want to get all cases
right, it is a bigger patch. One could presumably start by initializing the
pointer by bogus_pointer and add the checking before associate and
deallocate, which should cover the most common problems.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39230
[Bug fortran/39230] ASSOCIATED undefined pointers
--- Comment #2 from burnus at gcc dot gnu dot org 2009-02-18 17:32 --- The other bug is PR 29616. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39230
[Bug target/39082] union with long double doesn't follow x86-64 psABI
--- Comment #15 from hjl dot tools at gmail dot com 2009-02-18 17:43 --- (In reply to comment #13) Created an attachment (id=17325) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17325action=view) [edit] Ada testcase (botca...@red) ~ $ gcc -S p.ads p.ads:16: note: The ABI of passing union with long double has changed in GCC 4.4 A new patch is at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00855.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39082
[Bug tree-optimization/39233] [4.4 Regression] ivopts + vrp miscompilation
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-18 17:47 --- I will have a look. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-18 17:47:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39233
[Bug target/39179] [4.4 Regression] Wrong code in c++ for const members initialized in external file
--- Comment #20 from jason at gcc dot gnu dot org 2009-02-18 17:47 --- (In reply to comment #19) I suppose it's a question of what module means. module is used in a lot of different ways, but this usage definitely refers to the current translation unit: /* In a VAR_DECL, FUNCTION_DECL, NAMESPACE_DECL or TYPE_DECL, nonzero means name is to be accessible from outside this module. [...] #define TREE_PUBLIC(NODE) ((NODE)-base.public_flag) Looking at more uses of binds_local_p and the RTL SYMBOL_FLAG_LOCAL, it does seem to be primarily used for references to the current translation unit. Which means that the i386 back end is using it incorrectly somewhere; we don't need a GOT lookup for any reference to a symbol in another translation unit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug tree-optimization/39233] [4.4 Regression] ivopts + vrp miscompilation
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-18 17:50 --- Confirmed on x86_64 with -O2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||x86_64-*-* Known to work||4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39233
[Bug target/39179] [4.4 Regression] Wrong code in c++ for const members initialized in external file
--- Comment #21 from jason at gcc dot gnu dot org 2009-02-18 17:51 --- OTOH, the use of visibility in default_binds_local_p is also wrong under this interpretation... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug tree-optimization/39234] New: Call to constant function pointer not inlined
Even when compiled with -O3, the call to f() is not inlined in the following
testcase:
typedef void (*fptr_t)();
void extfunc(const fptr_t *f);
static inline void inlinable() {}
void test()
{
const fptr_t f = inlinable;
extfunc(f);
f();
}
$ gcc-4.4 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-svn/configure --program-suffix=-4.4
--enable-languages=c
Thread model: posix
gcc version 4.4.0 20090218 (experimental) (GCC)
--
Summary: Call to constant function pointer not inlined
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpirch at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39234
[Bug tree-optimization/39233] [4.4 Regression] ivopts + vrp miscompilation
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-02-18 17:53 ---
This one also fails on i?86-*-*:
extern void abort (void);
__attribute__((noinline)) void
foo (void *p)
{
long l = (long) p;
if (l 0 || l 6)
abort ();
}
int
main ()
{
short i;
for (i = 6; i = 0; i--)
foo ((void *) (long) i);
return 0;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC target triplet|x86_64-*-* |x86_64-*-*, i?86-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39233
[Bug target/39179] [4.4 Regression] Wrong code in c++ for const members initialized in external file
--- Comment #22 from jason at gcc dot gnu dot org 2009-02-18 18:06 --- Seems like we already had this discussion last year, starting at http://gcc.gnu.org/ml/gcc/2007-06/msg00848.html The conclusion there was that binds_local_p means binds to this executable/shared library, and the PE definition is correct under that meaning. The conclusion in that discussion was that users need to check DECL_EXTERNAL as well if they want to check whether something will bind to the current translation unit. Which leads me back to my patch attached above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug target/39179] [4.4 Regression] Wrong code in c++ for const members initialized in external file
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-02-14 16:55:18 |2009-02-18 18:10:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug target/39179] [4.4 Regression] Wrong code in c++ for const members initialized in external file
--- Comment #23 from jason at gcc dot gnu dot org 2009-02-18 18:31 --- ...and then of course there's the actual documentation: TARGET_BINDS_LOCAL_P (tree exp) Returns true if exp names an object for which name resolution rules must resolve to the current ``module'' (dynamic shared library or executable image). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug c++/39225] ICE if destructor doen't match class name
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-02-18 18:46 --- And: GNU C++ (GCC) version 4.4.0 20090116 (experimental) [trunk revision 143448] (powerpc64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20090116 (experimental) [trunk revision 143448], GMP version 4.2.2, MPFR version 2.3.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39225
[Bug tree-optimization/39233] [4.4 Regression] ivopts + vrp miscompilation
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-02-18 18:47 --- This patch fixes it, with unknown side-effects. It should be ok for the common sizetype extensions due to POINTER_PLUS_EXPR (sizetype is unsigned for sane languages). Index: tree-scalar-evolution.c === --- tree-scalar-evolution.c (revision 144265) +++ tree-scalar-evolution.c (working copy) @@ -2799,6 +2799,14 @@ simple_iv (struct loop *loop, gimple stm || chrec_contains_symbols_defined_in_loop (iv-base, loop-num)) return false; + /* If we folded casts and the result is a type where overflow is + undefined the IV may not be simple as it can have introduced + undefined overflow that wasn't there before. */ + if (folded_casts + (TYPE_OVERFLOW_UNDEFINED (type) + || POINTER_TYPE_P (type))) +return false; + iv-no_overflow = !folded_casts TYPE_OVERFLOW_UNDEFINED (type); return true; The following patch would be slightly less intrusive (only affects IVOPTs), but possibly other passes might be affected by the same bug. OTOH it doesn't affect number-of-iterations analysis, which the above does. Index: tree-ssa-loop-ivopts.c === --- tree-ssa-loop-ivopts.c (revision 144265) +++ tree-ssa-loop-ivopts.c (working copy) @@ -887,6 +887,14 @@ determine_biv_step (gimple phi) if (!simple_iv (loop, phi, name, iv, true)) return NULL_TREE; + /* If the IV may overflow and the result is a type we know does not + overflow we may have introduced undefined overflow. Do not use + that induction variable. */ + if (!iv.no_overflow + (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (name)) + || POINTER_TYPE_P (TREE_TYPE (name +return NULL_TREE; + return integer_zerop (iv.step) ? NULL_TREE : iv.step; } @@ -992,6 +1000,15 @@ find_givs_in_stmt_scev (struct ivopts_da if (!simple_iv (loop, stmt, lhs, iv, true)) return false; + + /* If the IV may overflow and the result is a type we know does not + overflow we may have introduced undefined overflow. Do not use + that induction variable. */ + if (!iv-no_overflow + (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (lhs)) + || POINTER_TYPE_P (TREE_TYPE (lhs +return false; + iv-base = expand_simple_operations (iv-base); if (contains_abnormal_ssa_name_p (iv-base) in the end someone finally should sit down and make overflowing/non-overflowing arithmetic explicit in the IL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39233
[Bug c++/39225] ICE if destructor doen't match class name
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-02-18 18:47 --- And in the release of 4.3.2 with checking turned on. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.4.0 |4.4.0 4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39225
[Bug target/39224] ABI attribute doesn't work with long double
--- Comment #10 from hjl dot tools at gmail dot com 2009-02-18 18:53 --- The problem is callee returns long double via a pointer to a structure. But caller thinks callee returns long double in rax/edx. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
[Bug tree-optimization/39233] [4.4 Regression] ivopts + vrp miscompilation
--- Comment #6 from jakub at gcc dot gnu dot org 2009-02-18 18:56 --- Would it be possible for known loop bounds to still use pointer etc. ivopts if we can ensure the overflow doesn't happen on that interval (+-1)? Say if the same testcase goes for (i = 16; i = 10; i--) instead of for (i = 6; i = 0; i--)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39233
[Bug target/39224] ABI attribute doesn't work with long double
--- Comment #11 from hjl dot tools at gmail dot com 2009-02-18 19:22 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00870.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||02/msg00870.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
[Bug target/39226] [4.4 Regression] gcc_assert (verify_initial_elim_offsets ()); ICE
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-02-18 19:34 --- Hmm, for the PS3 toolchain, I think I just removed anddi3_internal3_mc. Mine. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-18 19:34:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39226
[Bug target/39226] [4.4 Regression] gcc_assert (verify_initial_elim_offsets ()); ICE
--- Comment #4 from jakub at gcc dot gnu dot org 2009-02-18 19:40 --- You mean anddi3_internal3_nomc, right? If so, I guess anddi3_internal2_nomc should be removed too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39226
[Bug target/39226] [4.4 Regression] gcc_assert (verify_initial_elim_offsets ()); ICE
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-02-18 19:41 --- (In reply to comment #4) You mean anddi3_internal3_nomc, right? If so, I guess anddi3_internal2_nomc should be removed too. I will have to look at what I did, I know I ran into a case where a constant was being generated but really does not need to be generated ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39226
[Bug rtl-optimization/39235] New: get_simple_loop_desc returns uninitialized memory
get_simple_loop_desc uses the XNEW macro to allocate the new loop description, thus the memory is not initialized. At least the desc-infinite field thus can remain uninitialized when the function returns. As long as the optimizers only punt on infinity that can result in pseudo-random missed optimizations; as soon as something more intelligent is done with this information, this results in compiler crashes. I have a one-letter patch for this problem (plus two lines of comment), but we're still waiting for the FSF acknowledgement that our Copyright Assignment is on file. -- Summary: get_simple_loop_desc returns uninitialized memory Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39235
[Bug c++/39225] [4.3/4.4 Regression] ICE if destructor doen't match class name
-- hjl dot tools at gmail dot com changed: What|Removed |Added Known to fail|4.3.4 |4.3.4 4.4.0 Known to work|4.4.0 4.3.2 |4.3.2 Summary|ICE if destructor doen't|[4.3/4.4 Regression] ICE if |match class name|destructor doen't match ||class name Target Milestone|4.3.4 |4.4.0 Version|4.3.3 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39225
[Bug c++/39225] [4.3/4.4 Regression] ICE if destructor doen't match class name
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39225
[Bug rtl-optimization/39235] get_simple_loop_desc returns uninitialized memory
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-18 20:57 --- Such patch would be obvious and a minor change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39235
[Bug target/39179] [4.4 Regression] Wrong code in c++ for const members initialized in external file
--- Comment #24 from jason at gcc dot gnu dot org 2009-02-18 21:01 --- Subject: Bug 39179 Author: jason Date: Wed Feb 18 21:01:03 2009 New Revision: 144270 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144270 Log: PR target/39179 * tree-ssa-ccp.c (get_symbol_constant_value): Don't assume zero value if DECL_EXTERNAL. * tree-sra.c (sra_walk_gimple_assign): Likewise. * target.h (gcc_target::binds_local_p): Clarify module. * tree.h (TREE_PUBLIC): Clarify module. Added: trunk/gcc/testsuite/g++.dg/opt/const6.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cfns.h trunk/gcc/cp/ptree.c trunk/gcc/target.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/init/const7.C trunk/gcc/tree-pretty-print.c trunk/gcc/tree-sra.c trunk/gcc/tree-ssa-ccp.c trunk/gcc/tree.h trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug c++/39236] New: G++ sets TREE_STATIC and DECL_EXTERNAL on the same VAR_DECLs
G++ uses TREE_STATIC to mean will be written out statically somewhere rather than write out statically in this TU; it should be set on VAR_DECLs that also have DECL_EXTERNAL set. Historically we've set DECL_EXTERNAL on anything that we weren't yet sure whether or not we were going to write out in the current TU in order to support assemble_external; now that we are always in unit-at-a-time mode that isn't necessary anymore, so we can do away with the DECL_NOT_REALLY_EXTERN trickery. -- Summary: G++ sets TREE_STATIC and DECL_EXTERNAL on the same VAR_DECLs Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39236
[Bug target/39179] [4.4 Regression] Wrong code in c++ for const members initialized in external file
--- Comment #25 from jason at gcc dot gnu dot org 2009-02-18 21:09 --- Fixed. The C++ static/extern issue has been added as PR 39236. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug c++/39225] [4.3/4.4 Regression] ICE if destructor doen't match class name
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-02-18 20:19:20 |2009-02-18 21:24:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39225
[Bug rtl-optimization/17387] Redundant zero extension instructions in loop optimization
--- Comment #24 from hjl dot tools at gmail dot com 2009-02-18 21:24
---
I tried:
--- config/i386/i386.h.zero 2009-02-18 08:42:40.0 -0800
+++ config/i386/i386.h 2009-02-18 13:16:26.0 -0800
@@ -1940,6 +1940,11 @@ do {
\
is done just by pretending it is already truncated. */
#define TRULY_NOOP_TRUNCATION(OUTPREC, INPREC) 1
+/* When in 64-bit mode, move insns will zero extend SImode. All other
+ references are unknown. */
+#define LOAD_EXTEND_OP(MODE) \
+ (TARGET_64BIT (MODE) == SImode ? ZERO_EXTEND : UNKNOWN)
+
/* A macro to update M and UNSIGNEDP when an object whose type is
TYPE and which has the specified mode and signedness is to be
stored in a register. This macro is only called when TYPE is a
It makes no differences.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
[Bug rtl-optimization/17387] Redundant zero extension instructions in loop optimization
--- Comment #25 from hjl dot tools at gmail dot com 2009-02-18 21:31 --- All 32bit load insns are zero extended to 64bit, not just move. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
[Bug libstdc++/39237] New: Overloaded Operator delete not called
Hello,
We use a unit testing framework which overloads operator new and operator
delete to track memory allocations and detect leaks. According to it, vector's
push_back method allocates memory through operator new but does not release it
through operator delete.
I am not sure if this is because the memory is not released, is not released
through delete, or that the overloaded operator is simply not called.
The simple test case is as follows;
#include vector
#include iostream
int main (int argc, char ** argv)
{
{
std::vector int objects;
objects.push_back(1);
}
return 0;
}
static int allocatedBlocks = 0;
void* operator new(size_t size)
{
allocatedBlocks++;
void * toReturn = malloc(size);
std::cerr operator new(size = size
), returns: toReturn
allocatedBlocks: allocatedBlocks std::endl;
return toReturn;
}
void operator delete(void* mem)
{
if(mem == NULL)
return;
allocatedBlocks--;
std::cerr operator delete(mem = mem ) allocatedBlocks:
allocatedBlocks std::endl;
free(mem);
}
-
Using gcc 3.2.3, running this program yields the following output:
operator new(size = 320), returns: 0x503010 allocatedBlocks: 1
Using gcc 4.1.2, I get the expected:
operator new(size = 4), returns: 0x503010 allocatedBlocks: 1
operator delete(mem = 0x503010) allocatedBlocks: 0
I read in the FAQ that containers save memory for later re-use, but shouldn't
it be released when the vector goes out of scope?
Please see the preprocessed source (attached) and the g++ information below.
--
/home/riouxc/temp g++ -v -save-temps simple_vector.cpp
Reading specs from /isv/gnu/bin/../lib/gcc-lib/x86_64-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--enable-languages=c,c++ --disable-libgcj --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-47.3)
/isv/gnu/bin/../lib/gcc-lib/x86_64-redhat-linux/3.2.3/cpp0 -lang-c++
-D__GNUG__=3 -D__DEPRECATED -D__EXCEPTIONS -v -iprefix
/isv/gnu/bin/../lib/gcc-lib/x86_64-redhat-linux/3.2.3/ -D__GNUC__=3
-D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=3 -D__GXX_ABI_VERSION=102 -D__ELF__
-Dunix -D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__
-D__unix -D__linux -Asystem(posix) -D__NO_INLINE__ -D__STDC_HOSTED__=1
-D_GNU_SOURCE -Acpu=x86_64 -Amachine=x86_64 -D__x86_64 -D__x86_64__
-D__SIZE_TYPE__=unsigned long int -D__PTRDIFF_TYPE__=long int -D__tune_athlon__
-D__tune_athlon_sse__ -D__LONG_MAX__=9223372036854775807L -D__LP64__ -D_LP64
simple_vector.cpp simple_vector.ii
GNU CPP version 3.2.3 20030502 (Red Hat Linux 3.2.3-47.3) (cpplib) (x86-64
Linux/ELF)
ignoring nonexistent directory /isv/gnu/bin/../x86_64-redhat-linux/include
ignoring nonexistent directory /usr/x86_64-redhat-linux/include
ignoring duplicate directory /usr/include/c++/3.2.3
ignoring duplicate directory /usr/include/c++/3.2.3/x86_64-redhat-linux
ignoring duplicate directory /usr/include/c++/3.2.3/backward
ignoring duplicate directory
/usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/include
#include ... search starts here:
#include ... search starts here:
/isv/gnu/bin/../include/c++/3.2.3
/isv/gnu/bin/../include/c++/3.2.3/x86_64-redhat-linux
/isv/gnu/bin/../include/c++/3.2.3/backward
/isv/gnu/bin/../lib/gcc-lib/x86_64-redhat-linux/3.2.3/include
/usr/local/include
/usr/include
End of search list.
/isv/gnu/bin/../lib/gcc-lib/x86_64-redhat-linux/3.2.3/cc1plus -fpreprocessed
simple_vector.ii -quiet -dumpbase simple_vector.cpp -version -o simple_vector.s
GNU CPP version 3.2.3 20030502 (Red Hat Linux 3.2.3-47.3) (cpplib) (x86-64
Linux/ELF)
GNU C++ version 3.2.3 20030502 (Red Hat Linux 3.2.3-47.3) (x86_64-redhat-linux)
compiled by GNU C version 3.2.3 20030502 (Red Hat Linux 3.2.3-47.3).
as -V -Qy -o simple_vector.o simple_vector.s
GNU assembler version 2.15.92.0.2 (x86_64-redhat-linux) using BFD version
2.15.92.0.2 20040927
/isv/gnu/bin/../lib/gcc-lib/x86_64-redhat-linux/3.2.3/collect2 --eh-frame-hdr
-m elf_x86_64 -Y P,/usr/lib64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/isv/gnu/bin/../lib/gcc-lib/x86_64-redhat-linux/3.2.3/../../../../lib64/crt1.o
/isv/gnu/bin/../lib/gcc-lib/x86_64-redhat-linux/3.2.3/../../../../lib64/crti.o
/isv/gnu/bin/../lib/gcc-lib/x86_64-redhat-linux/3.2.3/crtbegin.o
-L/isv/gnu/bin/../lib/gcc-lib/x86_64-redhat-linux/3.2.3
-L/isv/gnu/bin/../lib/gcc-lib -L/usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3
-L/isv/gnu/bin/../lib/gcc-lib/x86_64-redhat-linux/3.2.3/../../../../lib64
-L/isv/gnu/bin/../lib/gcc-lib/x86_64-redhat-linux/3.2.3/../../..
-L/usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/../../../../lib64
-L/usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/../../.. -L/lib/../lib64
-L/usr/lib/../lib64 simple_vector.o -lstdc++ -lm
[Bug libstdc++/39237] Overloaded Operator delete not called
--- Comment #1 from caroline dot rioux at ca dot ibm dot com 2009-02-18 21:39 --- Created an attachment (id=17327) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17327action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39237
[Bug target/39224] ABI attribute doesn't work with long double
--- Comment #13 from hjl at gcc dot gnu dot org 2009-02-18 21:40 --- Subject: Bug 39224 Author: hjl Date: Wed Feb 18 21:40:08 2009 New Revision: 144272 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144272 Log: 2009-02-18 H.J. Lu hongjiu...@intel.com PR target/39224 * config/i386/i386.c (ix86_return_in_memory): Properly check ABI. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
[Bug libstdc++/39237] Overloaded Operator delete not called
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-18 21:45 --- Fixed in 4.1.0 as mentioned already. 3.3.x is no longer maintained and any bug that is reported against that old version is most likely not going to be ever fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39237
[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy
--- Comment #17 from danglin at gcc dot gnu dot org 2009-02-18 21:54 --- Configuring with --disable-stage-checking, I see the following for cc1: -bash-3.2$ size cc1 text data bss dechex filename 28977798 496932 623152 300978821cb41da cc1 Given the branch distance limit for arm, --disable-stage-checking is probably not a great solution. The text size for arm seems very large. It's more than twice the size of text on hppa. In fact, all the sizes are much bigger than on hppa: d...@hiauly6:~/gnu/gcc-4.4/objdir/stage1-gcc$ size cc1 text data bss dechex filename 13321030 168288 334952 13824270 d2f10e cc1 Long branch stub placement seems broken even with binutils head. Possibly, building with -ffunction-sections is the work around. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523
[Bug libgomp/39217] g++4.3.3 OpenMP (aka omp) for loop hangs
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-18 21:55 --- We need a preprocessed source or at least a self contained example. It might be the case you don't use the correct barriers or atomics when doing updates of a global variable. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Summary|g++4.3.3 OpenMP (aka omp) |g++4.3.3 OpenMP (aka omp) |for loop hangs |for loop hangs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39217
Re: Pass by reference problem
On Mon, Feb 16, 2009 at 7:29 PM, e211 e...@hotmail.com wrote:
//The following code works and there is no way it should. Seems like a bug
someone put in on purpose
#include iostream
using namespace std;
void swap(int *x, int *y)
{
int temp;
temp = *x;
*x = *y;
*y = temp;
}
int main()
{
int x = 10;
int y = 20;
cout x y endl;
swap(x,y); //how does this work, there is no way this should compile
and
run and actually work
cout x y endl;
}
iostream is bringing in the definition of std::swap which takes a
reference. And you have a using namespace std; there.
Thanks,
Andrew Pinski
[Bug libstdc++/39237] Overloaded Operator delete not called
--- Comment #3 from caroline dot rioux at ca dot ibm dot com 2009-02-18 22:02 --- (In reply to comment #2) Fixed in 4.1.0 as mentioned already. 3.3.x is no longer maintained and any bug that is reported against that old version is most likely not going to be ever fixed. Ok thanks for your input. Was this explicitly fixed or a result of other framework changes? Is there any way a patch exists and could be applied? I ask because it is unlikely we will move to gcc4 in the short term. Is gcc3.4.x still supported? Because it also occurs there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39237
[Bug libstdc++/39237] Overloaded Operator delete not called
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-18 22:06 --- (In reply to comment #3) Ok thanks for your input. Was this explicitly fixed or a result of other framework changes? Is there any way a patch exists and could be applied? Off hand I don't know. I ask because it is unlikely we will move to gcc4 in the short term. Is gcc3.4.x still supported? Because it also occurs there. Nope, only currently 4.2 and above are being maintained. Is there a reason why you unlikely to move to 4.x in the short term? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39237
[Bug target/39179] [4.4 Regression] Wrong code in c++ for const members initialized in external file
--- Comment #26 from ebotcazou at gcc dot gnu dot org 2009-02-18 22:11 --- Fixed. The C++ static/extern issue has been added as PR 39236. You have installed a lot more things than what's described in the ChangeLog. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug libstdc++/39237] Overloaded Operator delete not called
--- Comment #5 from caroline dot rioux at ca dot ibm dot com 2009-02-18 22:15 --- (In reply to comment #4) Nope, only currently 4.2 and above are being maintained. Is there a reason why you unlikely to move to 4.x in the short term? We have a big code base and changing compilers is done seldom and very carefully. This bug will be one more reason to move though, so that's good :) Is there any way you would know exactly what the bug is in this case? Is it a leak, or that the memory is not free'd through delete, or that the overloaded operator is not called when it should? I searched the bug database but couldn't find anything similar. Thanks again! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39237
[Bug tree-optimization/39234] Call to constant function pointer not inlined
--- Comment #2 from dpirch at gmail dot com 2009-02-18 22:16 --- extfunc cannot change the value of f, it would lead to undefined behavior. If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type, the behavior is undefined. (ISO/IEC 9899:TC3, 6.7.3) BTW, the function is actually inlined if f is declared as static const. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39234
[Bug testsuite/38166] g++.dg/ext/visibility/class1.C fails at -m64 on i686-apple-darwin9
--- Comment #2 from janis at gcc dot gnu dot org 2009-02-18 22:19 --- Subject: Bug 38166 Author: janis Date: Wed Feb 18 22:19:26 2009 New Revision: 144274 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144274 Log: 2009-02-18 Jack Howarth howa...@bromo.med.uc.edu PR testsuite/38166 * g++.dg/ext/visibility/class1.C: Revert revision 122348 and skip on Darwin. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/visibility/class1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38166
[Bug testsuite/38165] g++.dg/pubtypes.C fails at -m32/-m64 on i686-apple-darwin9
--- Comment #4 from janis at gcc dot gnu dot org 2009-02-18 23:18 --- Subject: Bug 38165 Author: janis Date: Wed Feb 18 23:17:56 2009 New Revision: 144277 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144277 Log: 2009-02-18 Jack Howarth howa...@bromo.med.uc.edu PR testsuite/38165 * g++.dg/pubtypes.C: Adopt Radar 4535968 fix to testcase. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/pubtypes.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38165
[Bug target/39224] ABI attribute doesn't work with long double
--- Comment #14 from hjl dot tools at gmail dot com 2009-02-18 23:42 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
[Bug c++/39219] attribute doesn't work with enums properly
--- Comment #7 from hjl dot tools at gmail dot com 2009-02-18 23:44 --- (In reply to comment #3) A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00790.html Jason, can you take a look at this one line fix? Thanks. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39219
[Bug c++/39188] G++ doesn't handle static anonymous union right
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-18 23:45 --- (In reply to comment #2) A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00714.html Jason, Richard, can you review this wrong-code fix? Thanks. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com, ||rguenther at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39188
[Bug target/39179] [4.4 Regression] Wrong code in c++ for const members initialized in external file
--- Comment #27 from jason at gcc dot gnu dot org 2009-02-19 01:12 --- I reverted the mistaken checkins a few seconds later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
[Bug c++/39219] attribute doesn't work with enums properly
--- Comment #8 from hjl at gcc dot gnu dot org 2009-02-19 01:58 --- Subject: Bug 39219 Author: hjl Date: Thu Feb 19 01:58:15 2009 New Revision: 144284 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144284 Log: gcc/cp 2009-02-18 H.J. Lu hongjiu...@intel.com PR c++/39219 * parser.c (cp_parser_enum_specifier): Apply all attributes. gcc/testsuite/ 2009-02-18 H.J. Lu hongjiu...@intel.com PR c++/39219 * g++.dg/parse/attr3.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/attr3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39219
[Bug libstdc++/39238] New: trunk revision 144279 - cfenv:54: error: �::fenv_t� has not been declared
I am getting this Warning: O0g.gch: created and used with differing settings of '-momit-leaf-frame-pointer' and this error: # gcc/xgcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --prefix=/usr/local/gcc4 --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-multilib --enable-decimal-float --with-long-double-128 --with-included-gettext --enable-stage1-checking --enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8 --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local --without-ppl Thread model: posix gcc version 4.4.0 20090218 (experimental) [trunk revision 144279] (GCC) # gmake ... Making all in include gmake[4]: Entering directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include' mkdir -p ./i386-pc-solaris2.11/bits/stdtr1c++.h.gch g++ -Winvalid-pch -x c++-header -g -O2 -I/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include/i386-pc-solaris2.11 -I/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include -I/usr/share/src/gcc_trunk/libstdc++-v3/libsupc++ -O2 -g /usr/share/src/gcc_trunk/libstdc++-v3/include/precompiled/stdtr1c++.h -o i386-pc-solaris2.11/bits/stdtr1c++.h.gch/O2g.gch /usr/share/src/gcc_trunk/libstdc++-v3/include/precompiled/stdtr1c++.h:34:25: warning: /usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include/i386-pc-solaris2.11/bits/stdc++.h.gch/O0g.gch: created and used with differing settings of '-momit-leaf-frame-pointer' In file included from /usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include/tr1/cfenv:51, from /usr/share/src/gcc_trunk/libstdc++-v3/include/precompiled/stdtr1c++.h:38: /usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include/tr1_impl/cfenv:54: error: ::fenv_t has not been declared /usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include/tr1_impl/cfenv:55: error: ::fexcept_t has not been declared /usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include/tr1_impl/cfenv:58: error: ::feclearexcept has not been declared /usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include/tr1_impl/cfenv:59: error: ::fegetexceptflag has not been declared /usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include/tr1_impl/cfenv:60: error: ::feraiseexcept has not been declared /usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include/tr1_impl/cfenv:61: error: ::fesetexceptflag has not been declared /usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include/tr1_impl/cfenv:62: error: ::fetestexcept has not been declared /usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include/tr1_impl/cfenv:64: error: ::fegetround has not been declared /usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include/tr1_impl/cfenv:65: error: ::fesetround has not been declared /usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include/tr1_impl/cfenv:67: error: ::fegetenv has not been declared /usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include/tr1_impl/cfenv:68: error: ::feholdexcept has not been declared /usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include/tr1_impl/cfenv:69: error: ::fesetenv has not been declared /usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include/tr1_impl/cfenv:70: error: ::feupdateenv has not been declared gmake[4]: *** [i386-pc-solaris2.11/bits/stdtr1c++.h.gch/O2g.gch] Error 1 gmake[4]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3' gmake[1]: *** [all-target-libstdc++-v3] Error 2 gmake[1]: Leaving directory `/usr/share/src/gcc_build' gmake: *** [all] Error 2 All was well last week ... Looking back at an old Build Log I tried this command: /usr/share/src/gcc_build/./gcc/xgcc -shared-libgcc -B/usr/share/src/gcc_build/./gcc -nostdinc++ -L/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/src -L/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/src/.libs -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -Winvalid-pch -x c++-header -g -O2 -I/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include/i386-pc-solaris2.11 -I/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include -I/usr/share/src/gcc_trunk/libstdc++-v3/libsupc++ -O2 -g /usr/share/src/gcc_trunk/libstdc++-v3/include/precompiled/stdtr1c++.h -o i386-pc-solaris2.11/bits/stdtr1c++.h.gch/O2g.gch works without error, but ... # gmake (short wait) ... i386-pc-solaris2.11/libstdc++-v3/include/i386-pc
[Bug libstdc++/39238] trunk revision 144279 - cfenv:54: error: �::fenv_t� has not been declared
--- Comment #1 from rob1weld at aol dot com 2009-02-19 02:21 --- New warning different GCC executable was just 'xgcc' instead of 'g++'. Next error in 'extc++.h.gch/O2g.gch' is fixed by: /usr/share/src/gcc_build/./gcc/xgcc -shared-libgcc -B/usr/share/src/gcc_build/./gcc -nostdinc++ -L/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/src -L/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/src/.libs -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -Winvalid-pch -x c++-header -g -O2 -I/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include/i386-pc-solaris2.11 -I/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include -I/usr/share/src/gcc_trunk/libstdc++-v3/libsupc++ -O2 -g /usr/share/src/gcc_trunk/libstdc++-v3/include/precompiled/extc++.h -o i386-pc-solaris2.11/bits/extc++.h.gch/O2g.gch Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39238
[Bug libstdc++/39238] trunk revision 144279 - cfenv:54: error: �::fenv_t� has not been declared
--- Comment #2 from rob1weld at aol dot com 2009-02-19 02:30 --- That worked. The build continues until it fails here: # gmake (5 minutes) ... Making all in src gmake[4]: Entering directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/src' ... -DPIC -o .libs/parallel_settings.o /bin/sh ../libtool --tag CXX --mode=link g++ -Wl,-O1 -Wl,-z,relro -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o libstdc++.la -rpath /usr/local/gcc4/lib -version-info 6:11:0 -lm atomic.lo bitmap_allocator.lo pool_allocator.lo mt_allocator.lo codecvt.lo compatibility.lo complex_io.lo ctype.lo debug.lo functexcept.lo hash.lo hash_c++0x.lo globals_io.lo hashtable.lo hashtable_c++0x.lo ios.lo ios_failure.lo ios_init.lo ios_locale.lo limits.lo limits_c++0x.lo list.lo debug_list.lo locale.lo locale_init.lo locale_facets.lo localename.lo math_stubs_float.lo math_stubs_long_double.lo stdexcept.lo strstream.lo system_error.lo tree.lo allocator-inst.lo concept-inst.lo fstream-inst.lo ext-inst.lo ios-inst.lo iostream-inst.lo istream-inst.lo istream.lo locale-inst.lo misc-inst.lo ostream-inst.lo sstream-inst.lo streambuf-inst.lo streambuf.lo string-inst.lo valarray-inst.lo wlocale-inst.lo wstring-inst.lo mutex.lo condition_variable.lo chrono.lo thread.lo atomicity.lo codecvt_members.lo collate_members.lo ctype_members.lo messages_members.lo monetary_members.lo numeric_members.lo time_members.lo basic_file.lo c++locale.lo parallel_list.lo parallel_settings.lo ../libsupc++/libsupc++convenience.la libtool: link: g++ -shared -nostdlib /usr/lib/crti.o /usr/lib/values-Xa.o /usr/local/lib/gcc/i386-pc-solaris2.11/4.4.0/crtbegin.o .libs/atomic.o .libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o .libs/codecvt.o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o .libs/debug.o .libs/functexcept.o .libs/hash.o .libs/hash_c++0x.o .libs/globals_io.o .libs/hashtable.o .libs/hashtable_c++0x.o .libs/ios.o .libs/ios_failure.o .libs/ios_init.o .libs/ios_locale.o .libs/limits.o .libs/limits_c++0x.o .libs/list.o .libs/debug_list.o .libs/locale.o .libs/locale_init.o .libs/locale_facets.o .libs/localename.o .libs/math_stubs_float.o .libs/math_stubs_long_double.o .libs/stdexcept.o .libs/strstream.o .libs/system_error.o .libs/tree.o .libs/allocator-inst.o .libs/concept-inst.o .libs/fstream-inst.o .libs/ext-inst.o .libs/ios-inst.o .libs/iostream-inst.o .libs/istream-inst.o .libs/istream.o .libs/locale-inst.o .libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o .libs/streambuf-inst.o .libs/streambuf.o .libs/string-inst.o .libs/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o .libs/mutex.o .libs/condition_variable.o .libs/chrono.o .libs/thread.o .libs/atomicity.o .libs/codecvt_members.o .libs/collate_members.o .libs/ctype_members.o .libs/messages_members.o .libs/monetary_members.o .libs/numeric_members.o .libs/time_members.o .libs/basic_file.o .libs/c++locale.o .libs/parallel_list.o .libs/parallel_settings.o -Wl,--whole-archive ../libsupc++/.libs/libsupc++convenience.a -Wl,--no-whole-archive -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/local/lib -L/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.0 -L/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.0/../../../../i386-pc-solaris2.11/lib -L/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.0/../../.. /usr/local/lib/libstdc++.so -lm -lgcc_s /usr/local/lib/gcc/i386-pc-solaris2.11/4.4.0/crtend.o /usr/lib/crtn.o -Wl,-O1 -Wl,-z -Wl,relro -Wl,-soname -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.11 ld: fatal: option -z has illegal argument `relro' usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VW:Y:?] file(s) [-64] enforce a 64-bit link-edit [-a]create an absolute file [-b]do not do special PIC relocations in a.out [-B direct | nodirect] establish direct bindings, or inhibit direct binding to, the object being created [-B dynamic | static] search for shared libraries|archives [-B eliminate] eliminate unqualified global symbols from the symbol table [-B group] relocate object from within group [-B local] reduce unqualified global symbols to local [-B reduce] process symbol reductions [-B symbolic] bind external references to definitions when creating shared objects [-c name] record configuration file `name' [-C]demangle C++ symbol name diagnostics [-d y | n] operate in dynamic|static mode [-D token,...] print diagnostic messages [-e epsym], [--entry epsym] use `epsym' as entry point address [-f name], [--auxiliary name] specify library for which this file is an auxiliary
[Bug testsuite/38166] g++.dg/ext/visibility/class1.C fails at -m64 on i686-apple-darwin9
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-02-19 02:31 --- Fixed on current gcc trunk. -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38166
