--- Comment #7 from sezeroz at gmail dot com 2009-07-31 06:30 ---
Besides my question in comment #6, I wonder why is this actually considered an
aliasing violation? The only difference between struct stat and struct
_stat64i32 is the time fields: _stat64i32 has __time64_t and stat has
--- Comment #3 from andriys at gmail dot com 2009-07-31 06:56 ---
I'm linking using g++ driver, so shared libgcc is enabled by default in 4.4.0.
I've just tried to enabled shared libstdc++ as described in the Release Notes
to the MinGW GCC 4.4.0 release, which made no difference.
More
--- Comment #4 from andriys at gmail dot com 2009-07-31 06:58 ---
Created an attachment (id=18277)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18277action=view)
Modified test case (not dependent on libstdc++ at all)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40918
--- 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 @@
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!
--- 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
--- 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
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 make it
--- 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=18278action=view)
minimal testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40924
--- 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
--- 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 random feature, since uses stdint.h types must be
completely disabled if such header doesn't exist or
--- 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
--
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 #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
--- 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
--
--- 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 #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 #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 #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 #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
--- 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
--- 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
--- 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=gccview=revrev=150312
Log:
2009-07-31 Paolo Carlini paolo.carl...@oracle.com
PR
--- 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 stdint.h is not available and
defining the required types.
--
--- 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 cstdint we have:
The header defines all functions, types, and macros the
--- Comment #21 from joseph at codesourcery dot com 2009-07-31 12:54
---
Subject: Re: stdint.h-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
--- 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
cstdint is included, not when stdint.h is included. Thus, I agree - note
I'm not completely sure to get all your points - for those
--- Comment #23 from joseph at codesourcery dot com 2009-07-31 13:09
---
Subject: Re: stdint.h-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
cstdint is included,
--- 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
--- 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?
--
--- 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
===
---
--- 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
--- 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: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
--- 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: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 #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 #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
This expression:
std::pairT*, U*(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
--- 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
--- Comment #1 from richard-gccbugzilla at metafoo dot co dot uk
2009-07-31 15:26 ---
Working draft N2914, 20.3.3 says:
template VariableType T1, VariableType T2
struct pair {
[...]
requires CopyConstructibleT1 CopyConstructibleT2 pair(const T1 x,
const T2 y);
... and this is
--- 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
--- 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
--- 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
that
--- Comment #10 from ppluzhnikov at google dot com 2009-07-31 15:56 ---
Filed MingW bug here:
https://sourceforge.net/tracker/?func=detailaid=2830386group_id=2435atid=102435
--
ppluzhnikov at google dot com changed:
What|Removed |Added
--- 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=detailaid=2830386group_id=2435atid=102435
Wrong project tracker. Please go to
https://sourceforge.net/tracker/?group_id=202880
--- 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
--- 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 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
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- 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
--- 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 #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
--- 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.
--
--- 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 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 #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 #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
--- 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=18279action=view)
[ __attribute__((optimize(0))) difference ]
Hmm, __attribute__((optimize(0))) does seem to disable inlining and the
--- 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=18279action=view) [edit]
[ __attribute__((optimize(0))) difference ]
Hmm, __attribute__((optimize(0)))
--- 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
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 #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=gccview=revrev=150319
Log:
PR tree-optimization/40914
* ipa-prop.c
--- 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
--- 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
--- 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
--- 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
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
--- 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=18280action=view)
Patch to fix Ignore_Output
I propose this to be committed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40926
--- 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=18281action=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 branch
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
71 matches
Mail list logo
