http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #15 from David Greene ---
(In reply to H.J. Lu from comment #14)
> I think GCC is correct.
I agree. Thanks for working through the explanation with me.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #13 from David Greene ---
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 separately for assigning argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #12 from David Greene ---
(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 the "Returning of Values" se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #10 from David Greene ---
(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 skips NO_CLASS when assigning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #8 from David Greene ---
(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. The class of conce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #6 from David Greene ---
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 #5 from David Greene ---
(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 or Itanium ABI that describe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #3 from David Greene ---
(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 what POD has to do with thi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
--- Comment #1 from David Greene ---
This is on Linux/SuSE/SLES 11.
: 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=32745&action=edit
Testcase
gcc appears to use the wrong seque
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55881
--- Comment #4 from David Greene 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
--- Comment #3 from David Greene 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 uninitialized in this functi
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: majo
--- 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
--- 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 somethi
--- 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?
--- 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|Re
--- 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=21740&action=view)
Reduced testcase
--
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
ed 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 #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 t
--- 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 k
--- 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=15494&action=view)
Unpreprocessed source
Includes comments describing the problem.
--
http://gcc.gnu.org/bugzilla/show_
--- 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=15493&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35969
P3
Component: libstdc++
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 #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
--- 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
--- 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=13705&action=view)
Preprocessed testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32346
nu dot org
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
30 matches
Mail list logo
