With current trunk (r150327, but has been broken for a couple months at least)
bootstrap fails if LDFLAGS contains -Wl,--as-needed.
x86_64-unknown-linux-gnu-gcc -O -DIN_GCC -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-lo
--- Comment #3 from xenofears at gmail dot com 2009-08-01 01:31 ---
Created an attachment (id=18281)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18281&action=view)
A patch to fix the the error cause by using a non-static attribute
This patch reverts a line of code to 4.4.x branc
--- Comment #2 from xenofears at gmail dot com 2009-08-01 01:28 ---
Created an attachment (id=18280)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18280&action=view)
Patch to fix Ignore_Output
I propose this to be committed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4092
Fails to vectorize when compiled with g++ -ftree-vectorizer-verbose=7 -S -O3
-march=core2 -msse3 -mfpmath=sse -Wall -o t test.c
$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=ht
--- Comment #1 from jon_y at users dot sourceforge dot net 2009-08-01
00:03 ---
For the Ignore_Output procedure, we can use "Pragma Unreferenced (S);" to fix
the problem, I'm not too sure about the others.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40926
--- Comment #1 from meissner at gcc dot gnu dot org 2009-07-31 22:03
---
I suspect this may be related to a problem with building for altivec that I
noticed after checking in the first of the powerpc changes. If possible, could
you rebuild the compiler with BOOT_CFLAGS='-g -O2 -mno-alt
--- Comment #6 from meissner at gcc dot gnu dot org 2009-07-31 22:01
---
It is probably related to my powerpc power7 checkin starting with 148869. It
may or may not be related to an issue I am looking at in that if you build the
compiler with altivec, it miscompiles the code, and 403.g
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-07-31 21:57
---
Fixed on trunk
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #3 from rearnsha at gcc dot gnu dot org 2009-07-31 21:56
---
Subject: Bug 40914
Author: rearnsha
Date: Fri Jul 31 21:56:28 2009
New Revision: 150319
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150319
Log:
PR tree-optimization/40914
* ipa-prop.c (i
These are not new, at least the ones in output.adb / ads. As for prj-proc.adb,
I removed the new Current_Item_Name. I know little to nothing about programming
in ada and how to fix it so that the output works in showing the
Current_Item_Name.
These seem like normal errors and don't know why they
--- Comment #1 from bbnickell at gmail dot com 2009-07-31 18:18 ---
Additionally, there does not appear to be a way to represent the dot argument
in the current IA64 name-mangling scheme:
http://www.codesourcery.com/public/cxx-abi/abi.html#mangling-type
I would like some clarifying rem
--- Comment #16 from sezeroz at gmail dot com 2009-07-31 18:16 ---
(In reply to comment #15)
> Created an attachment (id=18279)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18279&action=view) [edit]
> [ __attribute__((optimize("0"))) difference ]
>
> Hmm, __attribute__((optimize(
--- Comment #15 from sezeroz at gmail dot com 2009-07-31 18:07 ---
Created an attachment (id=18279)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18279&action=view)
[ __attribute__((optimize("0"))) difference ]
Hmm, __attribute__((optimize("0"))) does seem to disable inlining and
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-07-31 17:44
---
Yes, and of course remove the inline qualifier ;)
I have no idea what optimize(0) will do and why it should affect the bug
you are seeing (I guess it disallows inlining, which is why I think noinline
is a better c
--- Comment #13 from sezeroz at gmail dot com 2009-07-31 16:46 ---
(In reply to comment #12)
> noinline attributes would be better I think.
>
noinline for the inline functions??
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40909
--- Comment #3 from manu at gcc dot gnu dot org 2009-07-31 16:46 ---
A reduced testcase:
extern inline const char *
_strnchr (const char *str, char c, unsigned size);
extern inline void *
_memcpy (void *dst, const void *src, const unsigned size)
{
if (__builtin_constant_p (size))
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-07-31 16:42
---
noinline attributes would be better I think.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40909
--- Comment #3 from paolo dot carlini at oracle dot com 2009-07-31 16:26
---
Actually, this one seems invalid to me: std::map does *not* define an
operator[](std::initializer_list<>). Waiting a bit for Jason to confirm, then
closing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #19 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-31 16:17 ---
(In reply to comment #18)
Yes. But not an option. Make it default and make it optional to disable the
alignment. Make it default, because such option would be useless if all
libraries didn't u
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-31 16:16
---
I'm sorry Jason, a ping... ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39901
--- Comment #4 from paolo dot carlini at oracle dot com 2009-07-31 16:14
---
Waiting...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
S
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last re
--- Comment #3 from paolo dot carlini at oracle dot com 2009-07-31 16:13
---
Let's suspend the issue, but anyway, has to wait for std::pair to stabilize a
bit in the Standard. To be clear, this is the original issue, which has been
filed after our original implementation of a previous D
--- Comment #5 from laurent at guerby dot net 2009-07-31 16:08 ---
Current progress:
boot ok 148068
boot ok 148575
boot ok 148638
boot ok 148702
boot ok 148829
boot ko 148892
boot ko 148956
boot ko 149083
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40637
--- Comment #3 from mec at google dot com 2009-07-31 16:04 ---
Subject: Re: gcc -Waddress lost some useful warnings
Yes, I think this is a bug, because the behavior of gcc doesn't match
its documentation.
First, I think the C++ standard forbids a function from having a null
address:
--- Comment #11 from sezeroz at gmail dot com 2009-07-31 16:02 ---
(In reply to comment #10)
> Filed MingW bug here:
> https://sourceforge.net/tracker/?func=detail&aid=2830386&group_id=2435&atid=102435
>
Wrong project tracker. Please go to
https://sourceforge.net/tracker/?group_id=2028
--- Comment #10 from ppluzhnikov at google dot com 2009-07-31 15:56 ---
Filed MingW bug here:
https://sourceforge.net/tracker/?func=detail&aid=2830386&group_id=2435&atid=102435
--
ppluzhnikov at google dot com changed:
What|Removed |Added
-
--- Comment #18 from hjl dot tools at gmail dot com 2009-07-31 15:51
---
(In reply to comment #17)
> "Even if we align the incoming stack properly, we still have to align the
> outgoing stack to 16byte"
>
> I'm not opposing it. What I mean is: every function will have stack frame size
--- Comment #17 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-31 15:31 ---
"Even if we align the incoming stack properly, we still have to align the
outgoing stack to 16byte"
I'm not opposing it. What I mean is: every function will have stack frame size
that is multi
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-31 15:28
---
These issues are known, and the specifications of std::pair for C++0x are in
flux. The updated specifications will be implemented in due course, when
sufficiently stable vs the removal of Concepts and the paral
--- Comment #1 from richard-gccbugzilla at metafoo dot co dot uk
2009-07-31 15:26 ---
Working draft N2914, 20.3.3 says:
template
struct pair {
[...]
requires CopyConstructible && CopyConstructible pair(const T1 &x,
const T2 &y);
... and this is (modulo concept constraints) presen
--- Comment #16 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-31 15:22 ---
H.J. Lu: No, you only have to align the stack in functions that do 16-byte SSE.
I mean this:
there are two possible reasons for aligning the stack
1) improved performance (double, long double
This expression:
std::pair(0, 0)
... compiles with -std=c++98, but does not compile with -std=c++0x. We have
tens, possibly hundreds, of such constructs in our codebase. Either this is a
libstdc++ bug or an (I think fairly serious) issue in the changes to std::pair
in the C++-0x working paper.
--- Comment #2 from manu at gcc dot gnu dot org 2009-07-31 15:13 ---
Is this really a bug or not?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33925
--- Comment #4 from manu at gcc dot gnu dot org 2009-07-31 15:11 ---
Geir, have you run the testcase with other compilers? What is the result?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33720
--- Comment #3 from manu at gcc dot gnu dot org 2009-07-31 14:51 ---
What is the bad code generated? What were you expecting? Can you remove any
unused classes and functions from the testcase. It is excessively large.
Thanks.
--
manu at gcc dot gnu dot org changed:
What
--- Comment #3 from manu at gcc dot gnu dot org 2009-07-31 14:40 ---
I am going to close this. First I don't know what the C++ standard says and
there are too many open and unconfirmed bugs for anyone to care about this.
--
manu at gcc dot gnu dot org changed:
What|Re
--- Comment #1 from manu at gcc dot gnu dot org 2009-07-31 14:47 ---
This is confirmed in GCC 4.5.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2009-07-31 14:42 ---
Reported against 3.4.4, not reproducible in trunk, no answer in more than one
year.
Closing as WORKSFORME.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #15 from hjl dot tools at gmail dot com 2009-07-31 14:27
---
It is too late to change now. Even if we align the incoming
stack properly, we still have to align the outgoing stack
to 16byte since the existing binaries which use SSE won't
align the stack. That means we have to
--- Comment #25 from paolo dot carlini at oracle dot com 2009-07-31 13:57
---
Something like this should be enough, barring objections, I'll polish it, add a
testcase and submit it.
Index: c-cppbuiltin.c
===
--- c-cppbuilt
--- Comment #14 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-31 13:54 ---
Jakub: And how many other "bugs" like this are there? 75% of binaries in /bin
are "buggy". Do you think it is really sensible to declare that majority of
Linux software is buggy?
--
http:/
--- Comment #24 from paolo dot carlini at oracle dot com 2009-07-31 13:14
---
Oops, now I understand, was overlooking 18.4.2. Great. Thus we could just
arrange for those feature macros to be automagically defined when -std=c++0x
(gnu++0x). Do we have already have something similar elsew
--- Comment #23 from joseph at codesourcery dot com 2009-07-31 13:09
---
Subject: Re: -related issues (C99 issues)
On Fri, 31 Jul 2009, paolo dot carlini at oracle dot com wrote:
> Note, in C++1x, those macros should be effectively predefined *only* when
> is included, not when is
--- Comment #22 from paolo dot carlini at oracle dot com 2009-07-31 13:04
---
Note, in C++1x, those macros should be effectively predefined *only* when
is included, not when is included. Thus, I agree - note
I'm not completely sure to get all your points - for those targets such as GC
--- Comment #21 from joseph at codesourcery dot com 2009-07-31 12:54
---
Subject: Re: -related issues (C99 issues)
On Fri, 31 Jul 2009, paolo dot carlini at oracle dot com wrote:
> I'm wondering if there is something we can/should do here about C++1x: in the
> new Standard (see 18.4.
--- Comment #20 from paolo dot carlini at oracle dot com 2009-07-31 12:40
---
I'm wondering if there is something we can/should do here about C++1x: in the
new Standard (see 18.4.1/2 in n2914, for example), for we have:
The header defines all functions, types, and macros the same as C
--- Comment #17 from paolo dot carlini at oracle dot com 2009-07-31 12:22
---
With the patch I applied the build doesn't fail anymore. Of course, the
testcases still fail, at compile-time, if is not available and
defining the required types.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #16 from paolo at gcc dot gnu dot org 2009-07-31 12:19 ---
Subject: Bug 40912
Author: paolo
Date: Fri Jul 31 12:19:26 2009
New Revision: 150312
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150312
Log:
2009-07-31 Paolo Carlini
PR libstdc++/40912 (partial
--- Comment #3 from jakub at gcc dot gnu dot org 2009-07-31 12:13 ---
This has been broken even on the trunk, since r146669 till r146847 (so it works
again with r146848), no idea whether it is the same thing or not, nor whether
r146848 really fixed it rather than just made it latent (and
--- Comment #1 from dcb314 at hotmail dot com 2009-07-31 11:40 ---
(In reply to comment #0)
> I just tried to bootstrap gcc 4.5 mainline snapshot 20090730
> and it failed when comparing stage 2 and stage3.
The extra word --enable-build-with-cxx seems to be significant,
because when I re
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-31 11:14 ---
Confirmed. Trunk works for me.
If I disable gcse the testcase is no longer miscompiled (likewise if I
disable tree PRE which only hoists some conversions - thus likely const/copy
propagation goes wrong or addresses
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-07-31 10:52
---
Patch proposed here:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01816.html
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from jakub at gcc dot gnu dot org 2009-07-31 10:45 ---
Isn't this related to allowing to generate FMA on those targets that support
it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40921
--- Comment #9 from sezeroz at gmail dot com 2009-07-31 09:59 ---
Interesting that the problem occurs only with the inlined version: if the test
object is linked with a non-inline version in a separate *.a file, the test
behaves correctly.. BTW, neither 4.4 nor 4.5 complains even with
-
--- Comment #15 from htl10 at users dot sourceforge dot net 2009-07-31
09:55 ---
(In reply to comment #14)
> Note, in the meanwhile, if you want to build to test other parts of the C++
> library, other things, whatever, you can always pass --disable-libstdcxx-pch
Thanks for the tips.
--- Comment #14 from paolo dot carlini at oracle dot com 2009-07-31 09:49
---
Note, in the meanwhile, if you want to build to test other parts of the C++
library, other things, whatever, you can always pass --disable-libstdcxx-pch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4091
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-07-31 09:48 ---
With 4.4 you are probably simply lucky ;) This is an aliasing violation
because
C even considers
struct A { int i; };
struct B { int i; };
to be different. If the indirection isn't needed why provide two structs
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-31 09:42 ---
Confirmed. This is the job of the tree-ssa reassociation pass.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from paolo dot carlini at oracle dot com 2009-07-31 09:41
---
The problem here is very simple, unless c/448 is completely fixed for all the
targets and closed, the feature, since uses types must be
completely disabled if such header doesn't exist or doesn't provide the
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-31 09:38 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #1 from kretz at kde dot org 2009-07-31 09:24 ---
Created an attachment (id=18278)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18278&action=view)
minimal testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40924
After upgrading to 4.4.1 one of my unit tests started failing reproducibly.
I tried to find the part of -O3 (compared to -O2) that caused the failure and I
was able to "fix" the error by changing "optimize >= 3" to "optimize >= 4" in
tree-ssa-loop.c lines 509 and 550. That's the minimal change to
--- Comment #7 from rguenther at suse dot de 2009-07-31 09:19 ---
Subject: Re: [4.5 Regression] FAIL: StackTrace2 output
- source compiled test
On Thu, 30 Jul 2009, aph at gcc dot gnu dot org wrote:
> --- Comment #6 from aph at gcc dot gnu dot org 2009-07-30 17:24 ---
> This
--- Comment #7 from rguenther at suse dot de 2009-07-31 09:12 ---
Subject: Re: SRA scalarizes dead objects,
single-use objects
On Thu, 30 Jul 2009, jamborm at gcc dot gnu dot org wrote:
> --- Comment #6 from jamborm at gcc dot gnu dot org 2009-07-30 17:10
> ---
> Created an
I just tried to bootstrap gcc 4.5 mainline snapshot 20090730
and it failed when comparing stage 2 and stage3.
There is the output
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
x86_64-unknown-linux-gnu/libstdc++-v
--- Comment #13 from jakub at gcc dot gnu dot org 2009-07-31 07:12 ---
So, you found a glibc bug, which can be easily fixed by:
--- libc/malloc/Makefile 2009-05-16 19:23:36.0 +0200
+++ libc/malloc/Makefile 2009-07-31 09:09:51.760080072 +0200
@@ -104,6 +104,7 @@ $(objpfx)memusages
68 matches
Mail list logo
