http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #9 from Jakub Jelinek ---
The reason why some changes appear in stdarg functions is:
ix86_update_stack_boundary:
/* x86_64 vararg needs 16byte stack alignment for register save
area. */
if (TARGET_64BIT
&& cfun->stdarg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52695
--- Comment #7 from Ryan Hill ---
(In reply to Jakub Jelinek from comment #5)
> No idea what "brokeness" the above talks about, it works just fine for me in
> C++, so IMHO it just should always include x86intrin.h, but certainly if
> __MMX__ is de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54448
--- Comment #6 from Hin-Tak Leung ---
The latest with 4.6.4 and 4.7.3 :
http://gcc.gnu.org/ml/gcc-testresults/2014-01/msg00048.html
http://gcc.gnu.org/ml/gcc-testresults/2014-01/msg00049.html
seems to be a lot healthier.
During the course of the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59657
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59657
Bug ID: 59657
Summary: SSE intrinsics translates to AVX instructions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654
--- Comment #9 from janus at gcc dot gnu.org ---
Created attachment 31557
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31557&action=edit
reduce test case
Reduced test case. Should print '1' and does so with 4.7.4, but prints '0' with
4.8 an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41171
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656
Bug ID: 59656
Summary: weak_ptr::lock function crashes when compiling with
-fno-exceptions flag
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59642
--- Comment #2 from Marc Glisse ---
(In reply to Marc Glisse from comment #1)
> I've noticed the same in other PRs, normally we manage to track the actual
> value of *p, but we don't manage that when *p was written by __builtin_mem*,
> which shoul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59651
--- Comment #4 from belagod at gcc dot gnu.org ---
Thanks for looking at this.
Just to clarify, do you mean loop versioning happens in the up-counting loop?
Because in the down-counting loop, a partition seems to be happening with 2
iterations of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59648
--- Comment #8 from David Kredba ---
Thank you!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59648
--- Comment #7 from Markus Trippelsdorf ---
You cannot use full paths for your test output, because
creduce will run each iteration in a new directory. So
try changing it from:
-flto=4 -o /dev/null /home/dave2/$TESTCASE /home/dave2/libxservertes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59648
--- Comment #6 from David Kredba ---
Maybe to reduce ii file containing events.i and all ii files that creates
libxservertest.a together?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59648
--- Comment #5 from David Kredba ---
I tried to write a script for c-reduce. It writes output from compiler in two
steps but grep not waits and c-reduce not wanted to accept it as valid for
reducing case becuse test error level was not OK.
When I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654
tlcclt changed:
What|Removed |Added
Attachment #31554|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59648
--- Comment #4 from Markus Trippelsdorf ---
Xext/panoramiX.c sets:
int PanoramiXNumScreens = 0;
and events.i has:
extern __attribute__((visibility("default"))) int PanoramiXNumScreens;
...
typedef struct {
int screens[16];
int numScreens;
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Status|U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59633
--- Comment #3 from Marc Glisse ---
(In reply to Volker Reichelt from comment #2)
> Well, because the C-frontend compiles it, the C++-frontend used to compile
> it and even clang (3.2) compiles it, I was under the impression that this
> should com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59648
Andrew Pinski changed:
What|Removed |Added
Status|RESOLVED|WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59648
--- Comment #2 from David Kredba ---
I am sorry but Xorg guys are saying this is gcc problem:
https://bugs.freedesktop.org/show_bug.cgi?id=71127
-O2 compilation is used wide in distributions so in my opinion this issue needs
resolution on one of
20 matches
Mail list logo
