http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #5 from David Greene greened at obbligato dot org ---
(In reply to Jonathan Wakely from comment #4)
Clang uses the same registers as GCC:
Ok, but that still doesn't explain why. Can you point me to wording in either
the x86-64 ABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #6 from David Greene greened at obbligato dot org ---
Bug filed against clang to see what they have to say.
http://llvm.org/bugs/show_bug.cgi?id=19675
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #8 from David Greene greened at obbligato dot org ---
(In reply to H.J. Lu from comment #7)
It is the matter of if the size of
---
struct B { };
struct X : public B { long p; };
---
is size of long or not.
I don't understand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #10 from David Greene greened at obbligato dot org ---
(In reply to H.J. Lu from comment #9)
Y is returned as {NO_CLASS, INTEGER} in register. psABI doesn't
explicitly say how NO_CLASS should be handled in this case. GCC
simply
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #12 from David Greene greened at obbligato dot org ---
(In reply to H.J. Lu from comment #11)
That is correct and Y is classified as INTEGER with 2 fields:
NO_CLASS, INTEGER. The question is how NO_CLASS should be handled.
Since
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #13 from David Greene greened at obbligato dot org ---
I see that 3.2.3 4 (b) is talking about considering adjacent fields in an
eightbyte. Is the intent to classify each eightbyte in an aggregate and then
consider each eightbyte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #15 from David Greene greened at obbligato dot org ---
(In reply to H.J. Lu from comment #14)
I think GCC is correct.
I agree. Thanks for working through the explanation with me.
: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: greened at obbligato dot org
Created attachment 32745
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32745action=edit
Testcase
gcc appears to use the wrong sequence
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #1 from David Greene greened at obbligato dot org ---
This is on Linux/SuSE/SLES 11.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #3 from David Greene greened at obbligato dot org ---
(In reply to Andrew Pinski from comment #2)
Y is a non-POD.
So...?
The ABI doesn't talk about POD vs. non-POD. It talks about copy constructors
and destructors.
Can you explain
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55881
--- Comment #3 from David Greene greened at obbligato dot org 2013-01-07
21:49:58 UTC ---
(In reply to comment #1)
What is the output of GCC?
warning.cpp: In function 'int main(int, char**)':
warning.cpp:5:19: warning: 'n' may be used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55881
--- Comment #4 from David Greene greened at obbligato dot org 2013-01-07
21:50:51 UTC ---
(In reply to comment #2)
Well - confirmed. Unlikely to be fixed.
That's _very_ unfortunate. It makes the pragma almost useless in practice.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55881
Bug #: 55881
Summary: #pragma GCC diagnostic ignored ignored when inlining
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity:
at gcc dot gnu dot org
ReportedBy: greened at obbligato dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45600
--- Comment #1 from greened at obbligato dot org 2010-09-08 16:08 ---
Compile with -c -mavx reduced.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45600
--- Comment #2 from greened at obbligato dot org 2010-09-08 16:09 ---
Created an attachment (id=21740)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21740action=view)
Reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45600
--- Comment #5 from greened at obbligato dot org 2010-09-08 18:52 ---
Why is the code undefined? Can you explain in terms of the original test
source? I don't immediately see anything undefined there.
--
greened at obbligato dot org changed:
What|Removed
--- Comment #7 from greened at obbligato dot org 2010-09-08 18:58 ---
(In reply to comment #5)
Why is the code undefined? Can you explain in terms of the original test
source? I don't immediately see anything undefined there.
Ah, the cast from int field5 to v4df? Yes, that doesn't
--- Comment #8 from greened at obbligato dot org 2010-09-08 18:59 ---
(In reply to comment #6)
The alignment of llvm_cbe__24__StackDv_P53 is only 64bits so you are casting
to
a greater aligned type and then dereferencing it.
I didn't know that typing something as a vector
--- Comment #11 from greened at obbligato dot org 2010-09-08 19:16 ---
(In reply to comment #9)
If it's an illegal program, gcc should at least emit a warning, if not an
error.
It is not an invalid program,
Yes, you are quite right. I will take this up with the LLVM folks
++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: greened at obbligato dot org
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35969
--- Comment #1 from greened at obbligato dot org 2008-04-18 03:12 ---
Created an attachment (id=15493)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15493action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35969
--- Comment #2 from greened at obbligato dot org 2008-04-18 03:13 ---
Created an attachment (id=15494)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15494action=view)
Unpreprocessed source
Includes comments describing the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #4 from greened at obbligato dot org 2008-04-18 03:26 ---
Subject: Re: GLIBCXX_DEBUG: list::merge triggers bad
assert
pinskia at gcc dot gnu dot org wrote:
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-18 03:23
---
I don't know if the SGI website
--- Comment #5 from greened at obbligato dot org 2008-04-18 04:16 ---
Ok, the closest thing I could find is the 1998 draft standard:
http://www.kuzbass.ru:8086/docs/isocpp/lib-containers.html#lib.sequences
It says that splice invalidates only the iterators and references
--- Comment #4 from greened at obbligato dot org 2007-07-25 19:47 ---
It is also broken on trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32346
--- Comment #3 from greened at obbligato dot org 2007-07-24 19:59 ---
This is also broken in 4.2.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32346
ReportedBy: greened at obbligato dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32346
--- Comment #1 from greened at obbligato dot org 2007-06-14 20:48 ---
Created an attachment (id=13705)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13705action=view)
Preprocessed testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32346
--- Comment #2 from greened at obbligato dot org 2007-06-14 20:50 ---
Configuration:
g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /tools/gcc-4.2.0/configure --prefix=/tools/i686-pc-linux-gnu
--disable-shared --with-gnu-as --with-gnu-ld
--with-build-time-tools
30 matches
Mail list logo
