https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #12 from Markus Trippelsdorf ---
1) Your malloc is too small. It has to be sizeof (biggest member).
So you're invoking undefined behavior.
2) In the if statement, where you probe the different members, you
also invoke undefined behav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
M Welinder changed:
What|Removed |Added
Attachment #33809|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #81 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #80)
> (In reply to Oleg Endo from comment #79)
> > Hm, maybe it's better to name this "legitimize_address_displacement" or
> > "legitimize_address_offset"?
>
> Sure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #80 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #79)
> Hm, maybe it's better to name this "legitimize_address_displacement" or
> "legitimize_address_offset"?
Sure. I'm not sure whether that targetm function is a goo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #79 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #78)
> Created attachment 33813 [details]
> a trial patch for the issue c#76
>
> With it, the generated code for c#76 test case looks similar with
> the one with non LR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #78 from Kazumoto Kojima ---
Created attachment 33813
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33813&action=edit
a trial patch for the issue c#76
With it, the generated code for c#76 test case looks similar with
the one w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53061
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53061
--- Comment #2 from Manuel López-Ibáñez ---
Author: manu
Date: Sun Oct 26 21:21:58 2014
New Revision: 216720
URL: https://gcc.gnu.org/viewcvs?rev=216720&root=gcc&view=rev
Log:
In cp/error.c, I separate the initialization of the diagnostic contex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63650
--- Comment #6 from Richard PALO ---
For that matter, the following is sufficient to
reproduce the problem, the rest is mostly to simulate
the xulrunner environment that is failing to build.
--->8--
#ifnde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63650
--- Comment #5 from Richard PALO ---
(In reply to Daniel Krügler from comment #4)
> (In reply to Richard PALO from comment #3)
> > I initially replied that there was an error in my original, please
> > correct the first three lines to:
> > #ifnde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651
Bug ID: 63651
Summary: Lot of failures in obj(c|-c++) with yosemite
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63650
--- Comment #4 from Daniel Krügler ---
(In reply to Richard PALO from comment #3)
> I initially replied that there was an error in my original, please
> correct the first three lines to:
> #ifndef HIDDEN
> #define HIDDEN __attribute__((visibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63650
--- Comment #3 from Richard PALO ---
I initially replied that there was an error in my original, please
correct the first three lines to:
#ifndef HIDDEN
#define HIDDEN __attribute__((visibility("hidden")))
#endif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #4 from Uroš Bizjak ---
Please note that:
(define_insn "*pushtf"
[(set (match_operand:TF 0 "push_operand" "=<,<")
(match_operand:TF 1 "general_no_elim_operand" "x,*roF"))]
"TARGET_64BIT || TARGET_SSE"
{
/* This insn should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63650
--- Comment #2 from Richard PALO ---
Created attachment 33812
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33812&action=edit
nsFastLoadFile.ii
this is the original error:
> gmake[4]: Entering directory
> '/tmp/pkgsrc/devel/xulrunner192/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Uroš Bizjak changed:
What|Removed |Added
Keywords||ra
Target|Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63650
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #14 from Keith Thompson ---
The C standard requires that, if y "happens to immediately follow"
x in the address space, then a pointer just past the end of x shall
compare equal to a pointer to the beginning of y (C99 and C11 6.5.9p6).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #10 from Mikael Pettersson ---
I now think the test case is invalid. There is special provision in the
standard for accessing "the wrong member" of a union, but the member has to be
a struct type which shares a prefix with the curren
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63650
Bug ID: 63650
Summary: conflicting type attributes specified for ‘virtual..'
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63649
Markus Trippelsdorf changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |trippels at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63649
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33661
--- Comment #11 from Adam Lackorzynski ---
Confirming issue still exists for 4.7.4, 4.8.4, 4.9.2 and 5.0 (tested on
x86_64).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36722
Adam Lackorzynski changed:
What|Removed |Added
CC||adam at os dot
inf.tu-dresden.de
late< typename T > void Per_cpu::f1() {}
class A { static Per_cpu a; };
static Per_cpu_ctor_data __b;
__attribute__((init_priority(0xfffe))) Per_cpu A::a;
$ g++ --version
g++ (GCC) 5.0.0 20141026 (experimental)
$ uname -m
x86_64
$ g++ -c -std=c++0x -O1 t.i
mem_space.i:31:59: internal compiler err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63648
--- Comment #1 from s-wakaba ---
Comment on attachment 33811
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33811
compile error with gcc 4.8.2
at line #13
typename enable_if::type, int>::value,
int>::type*, // error with gcc 4.8.x
typenam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63648
Bug ID: 63648
Summary: compile error w/ pointer argument of
result_of-is_same-enable_if returns
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63647
--- Comment #2 from Andrew Pinski ---
Oh wait that is arch64 and not aarch64. my eyes are playing tricks on me. I
guess arm64 would have been a better macro for aarch64 (If ARM would have
listened).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63647
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
29 matches
Mail list logo
