http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59897
--- Comment #6 from Yury Gribov y.gribov at samsung dot com ---
Dominique, please check and close if it works for you.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59575
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Attachment #31934|0 |1
is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57884
Yury Gribov y.gribov at samsung dot com changed:
What|Removed |Added
CC||y.gribov at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59913
--- Comment #5 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #4)
I'm still bisecting, but I suspect two recent commits to lra-constraints:
r206938
2014-01-22 Vladimir Makarov vmaka...@redhat.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59594
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
On:
#define N 1024
int ia[N + 1];
int ib[N + 1];
void
f1 (void)
{
int i;
for (i = 0; i N; i++)
{
ia[i + 1] = 1;
ib[i] = ia[i];
}
}
void
f2 (void)
{
int i;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59318
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59352
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59404
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59463
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59540
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59548
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||fdumont at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||adam at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59681
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||jason at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||jason at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59548
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #9 from Kostya Serebryany kcc at gcc dot gnu.org ---
It still fails for me. It has nothing to do with make -jN. When I
I tried running this on the fresh gcc trunk.
During the 3-rd stage I get this:
checking how to run the C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #10 from Kostya Serebryany kcc at gcc dot gnu.org ---
H.J., can you send the contents of /proc/PID/{maps,smaps,status}
of the failing process before it dies?
(you can use ASAN_OPTIONS=sleep_before_dying=1000)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #11 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Kostya Serebryany from comment #9)
It still fails for me. It has nothing to do with make -jN. When I
I tried running this on the fresh gcc trunk.
During the 3-rd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59384
--- Comment #4 from Nick Tomlinson nick.tomlinson at arm dot com ---
Created attachment 31944
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31944action=edit
Example that is broken when the suggested patch is used.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59384
--- Comment #5 from Nick Tomlinson nick.tomlinson at arm dot com ---
Hello
I tried the new patch against the suggested revision (patch and revision from
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01170.html). While I was able to
patch and build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59933
Bug ID: 59933
Summary: for loop goes wild with assert() enabled
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59933
--- Comment #1 from Mark Warner warnerme at ptd dot net ---
Created attachment 31945
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31945action=edit
C source of subroutines which contain problem for loop
This is a file from OPUS. As sent it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
Bug ID: 59934
Summary: Bootstrap fail since r206941: expmed.h:252:33: error:
array subscript is above array bounds
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
Andreas Krebbel krebbel at gcc dot gnu.org changed:
What|Removed |Added
Target|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #12 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Kostya Serebryany from comment #10)
H.J., can you send the contents of /proc/PID/{maps,smaps,status}
of the failing process before it dies?
(you can use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #13 from Kostya Serebryany kcc at gcc dot gnu.org ---
If you run cc1plus under GDB, you will get
Breakpoint 6, __sanitizer::Report (
format=format@entry=0x284f6f0 ERROR: %s failed to allocate 0x%zx (%zd)
bytes of %s: %d\n)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #14 from H.J. Lu hjl.tools at gmail dot com ---
Created attachment 31946
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31946action=edit
/proc/cc1plus/{maps,smaps,status}
This is the output of cat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #15 from Kostya Serebryany kcc at gcc dot gnu.org ---
This looks very weird:
60200120-60200121 rw-p 00:00 0
60200121-60200122 rw-p 00:00 0
We have two adjacent mappings with the same perms
which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #16 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Kostya Serebryany from comment #15)
This looks very weird:
60200120-60200121 rw-p 00:00 0
60200121-60200122 rw-p 00:00 0
We have
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59917
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 31947
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31947action=edit
gcc49-pr59917.patch
Untested partial fix, which fixes the first testcase, but still ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
--- Comment #2 from Andreas Krebbel krebbel at gcc dot gnu.org ---
Created attachment 31948
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31948action=edit
Preprocessed file
compile with: -O2 -Warray-bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #17 from Kostya Serebryany kcc at gcc dot gnu.org ---
When I look at my /proc/PID/maps of cc1plus, I see this:
...
6100-6103 rw-p 00:00 0
6103-6110 ---p 00:00 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
Kostya Serebryany kcc at gcc dot gnu.org changed:
What|Removed |Added
CC||eugeni.stepanov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935
Bug ID: 59935
Summary: [4.9 Regression] Firefox build fails with: built-in:
internal compiler error: Segmentation fault
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #19 from Kostya Serebryany kcc at gcc dot gnu.org ---
(In reply to Kostya Serebryany from comment #18)
eugenis@ says he sees something similar on Ubuntu 13.10.
Actually, only on Ubuntu 14.04 candidate.
Looks like a fresh regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920
Carlos O'Donell carlos at redhat dot com changed:
What|Removed |Added
CC||carlos at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #20 from Evgeniy Stepanov eugeni.stepanov at gmail dot com ---
I can confirm that the issue can be reproduced on 3.13.0-5-generic (ubuntu
14.04 candidate), and can not be reproduced on 3.11.0-15-generic (ubuntu
13.10).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #21 from Evgeniy Stepanov eugeni.stepanov at gmail dot com ---
A reproducer without ASan:
#include stdlib.h
#include stdio.h
#include unistd.h
#include sys/mman.h
int main() {
char * p = (char*)0x61904c1e;
for (int i = 0; i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59927
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
Reduced testcase:
typedef unsigned int (__attribute__ ((ms_abi)) *F) (long);
void
foo (F f)
{
f (0);
}
or even:
extern void bar (int) __attribute__ ((ms_abi));
void
foo (void)
{
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #22 from Kostya Serebryany kcc at gcc dot gnu.org ---
A quick workaround would be to change
static const uptr kUserMapSize = 1 16;
in sanitizer_common/sanitizer_allocator.h
to something like 17 or 18.
We can also try using mremap.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 /tmp % cat foo.c
#define _GNU_SOURCE
markus@x4 /tmp % gcc -D_GNU_SOURCE -c foo.c
foo.c:1:0: warning: _GNU_SOURCE redefined [enabled by default]
#define
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935
Dodji Seketeli dodji at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524
--- Comment #13 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org ---
Author: paolo
Date: Fri Jan 24 15:45:14 2014
New Revision: 207047
URL: http://gcc.gnu.org/viewcvs?rev=207047root=gccview=rev
Log:
/cp
2014-01-24 Paolo Carlini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524
--- Comment #14 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org ---
Author: paolo
Date: Fri Jan 24 15:53:07 2014
New Revision: 207048
URL: http://gcc.gnu.org/viewcvs?rev=207048root=gccview=rev
Log:
/cp
2014-01-24 Paolo Carlini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||law at redhat dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59548
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.6.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
For C I believe it's valid to jump back into a scope like that. I don't
think it affects reuse of stack space, because the variables in the scope
that was
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886
--- Comment #8 from Jason Merrill jason at gcc dot gnu.org ---
Author: jason
Date: Fri Jan 24 16:47:54 2014
New Revision: 207051
URL: http://gcc.gnu.org/viewcvs?rev=207051root=gccview=rev
Log:
PR c++/59886
PR c++/59659
* typeck2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59659
--- Comment #11 from Jason Merrill jason at gcc dot gnu.org ---
Author: jason
Date: Fri Jan 24 16:47:54 2014
New Revision: 207051
URL: http://gcc.gnu.org/viewcvs?rev=207051root=gccview=rev
Log:
PR c++/59886
PR c++/59659
* typeck2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59936
Bug ID: 59936
Summary: undefined reference to gfortran
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557
Matthew Krafczyk krafczyk.matthew at gmail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59659
--- Comment #12 from Jason Merrill jason at gcc dot gnu.org ---
Author: jason
Date: Fri Jan 24 17:09:07 2014
New Revision: 207052
URL: http://gcc.gnu.org/viewcvs?rev=207052root=gccview=rev
Log:
PR c++/59886
PR c++/59659
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886
--- Comment #10 from Jason Merrill jason at gcc dot gnu.org ---
Author: jason
Date: Fri Jan 24 17:09:07 2014
New Revision: 207052
URL: http://gcc.gnu.org/viewcvs?rev=207052root=gccview=rev
Log:
PR c++/59886
PR c++/59659
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58550
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
I think it is just warning on dead code, but GCC doesn't know it is dead code.
s390 doesn't have any partial or vector modes, so expmed_mode_index
because MIN_MODE_PARTIAL_INT and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
--- Comment #5 from Jeffrey A. Law law at redhat dot com ---
I'd kindof suspected something along those lines and I've had to fix problems
like this in the past.
I'll have to look at how we dealt with this in the past.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
Now, if we want to fix this on the expmed.h side, either:
--- gcc/expmed.h2014-01-03 11:40:57.228320531 +0100
+++ gcc/expmed.h2014-01-24 18:30:12.513908749 +0100
@@ -221,9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org ---
Perhaps we could set gimple_set_no_warning on the jump threaded stmts and honor
that in VRP array checking. Or TREE_NO_WARNING on the handled_component_p
operands of the threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59820
--- Comment #4 from Richard Henderson rth at gcc dot gnu.org ---
Should be fixed in glibc mainline, by
commit 4ab6acaebd0047dc37c6493946484be9f1b4920b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59820
Richard Henderson rth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59231
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58561
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59540
--- Comment #2 from Nenad Vukicevic nenad at intrepid dot com ---
I just rechecked the latest trunk. Still the same problem. I am running the
build on x86 VM with 4Gb of memory and I suspect that gcc ran out of memory as
it took a long time to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59540
--- Comment #3 from Nenad Vukicevic nenad at intrepid dot com ---
Created attachment 31950
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31950action=edit
Preprocessed file that causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58550
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58550
--- Comment #5 from Jason Merrill jason at gcc dot gnu.org ---
Author: jason
Date: Fri Jan 24 19:05:39 2014
New Revision: 207055
URL: http://gcc.gnu.org/viewcvs?rev=207055root=gccview=rev
Log:
PR c++/58550
* decl.c (grokdeclarator): Turn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59224
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59898
--- Comment #5 from ignat at gmx dot net ---
16 overloadable memory allocation functions??? brave new world!
Nothing against the possibility to have explicit alignment (when you need to
align to a cache line, page or disk-block), but why not just
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59231
--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com ---
However, what Jason suggested at the time was ANOTHER job for
c_inhibit_evaluation_warning (emphasis mine). In my mind that was important
because I saw a clear consistency
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #5)
-g isn't needed to reproduce this. Started with r198096, the huge function
with ~ 5000 or how many basic blocks has over 200 setjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59548
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org ---
Author: redi
Date: Fri Jan 24 20:08:20 2014
New Revision: 207059
URL: http://gcc.gnu.org/viewcvs?rev=207059root=gccview=rev
Log:
PR libstdc++/59548
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59548
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59529
--- Comment #1 from emsr at gcc dot gnu.org ---
Author: emsr
Date: Fri Jan 24 20:15:00 2014
New Revision: 207060
URL: http://gcc.gnu.org/viewcvs?rev=207060root=gccview=rev
Log:
2014-01-24 Ed Smith-Rowland 3dw...@verizon.net
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59531
--- Comment #2 from emsr at gcc dot gnu.org ---
Author: emsr
Date: Fri Jan 24 20:15:00 2014
New Revision: 207060
URL: http://gcc.gnu.org/viewcvs?rev=207060root=gccview=rev
Log:
2014-01-24 Ed Smith-Rowland 3dw...@verizon.net
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59530
--- Comment #2 from emsr at gcc dot gnu.org ---
Author: emsr
Date: Fri Jan 24 20:15:00 2014
New Revision: 207060
URL: http://gcc.gnu.org/viewcvs?rev=207060root=gccview=rev
Log:
2014-01-24 Ed Smith-Rowland 3dw...@verizon.net
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
--- Comment #8 from Jeffrey A. Law law at redhat dot com ---
Setting TREE_NO_WARNING seems wrong to me. That would really seem better
suited for cases where we have already warned on that expression and don't want
to warn on it again. This case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59932
--- Comment #4 from Zhendong Su su at cs dot ucdavis.edu ---
(In reply to Andrew Pinski from comment #3)
(In reply to Zhendong Su from comment #2)
(In reply to Andrew Pinski from comment #1)
I don't see why you think this is not undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59919
--- Comment #6 from Jeffrey A. Law law at gcc dot gnu.org ---
Author: law
Date: Fri Jan 24 20:51:22 2014
New Revision: 207061
URL: http://gcc.gnu.org/viewcvs?rev=207061root=gccview=rev
Log:
PR tree-optimization/59919
* tree-vrp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59919
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59825
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674
--- Comment #9 from Andreas Schwab sch...@linux-m68k.org ---
x86 works around its weird ABI by dynamic stack realignment. That's what needs
to be implemented for your ABI as well.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
--- Comment #9 from Jeffrey A. Law law at redhat dot com ---
Jakub,
I think your second approach is the better solution. It'll abort rather than
silently returning a value which may or may not be appropriate in the caller's
context.
ie,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
But with the second patch we'll generate bigger code (because we pass arguments
to fancy_abort) and it really is a will never happen case, if you don't have
any partial (or vector)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59561
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Fri Jan 24 23:17:25 2014
New Revision: 207065
URL: http://gcc.gnu.org/viewcvs?rev=207065root=gccview=rev
Log:
PR middle-end/59561
* cfgloopmanip.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #21 from Paul H. Hargrove PHHargrove at lbl dot gov ---
A build from svn trunk (r207062) completed w/o problems.
I see:
Configuring in i686-pc-linux-gnu/libsanitizer
followed later by
checking for necessary platform features...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59937
Bug ID: 59937
Summary: [constexpr] bogus diagnostic used in its own
initializer
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59938
Bug ID: 59938
Summary: [C++11] Bogus ... is not a constant expression
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303
--- Comment #10 from Andrew Pinski pinskia at gcc dot gnu.org ---
I noticed this also when I was helping out an uboot developer here at Cavium
for Octeon.
Really I think someone should get LTO working for uboot.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59939
Bug ID: 59939
Summary: No warning on signedness changes caused by implicit
conversion
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59939
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
IIRC this was done so that code which uses macros and have conditional code
like:
MACRO1 || fn1(a, b)
1 - 100 of 113 matches
Mail list logo
