http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59897
--- Comment #6 from Yury Gribov ---
Dominique, please check and close if it works for you.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59575
Jakub Jelinek changed:
What|Removed |Added
Attachment #31934|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57884
Yury Gribov changed:
What|Removed |Added
CC||y.gribov at samsung dot com
--- Comment #3
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
>
> PR rtl-opti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59594
--- Comment #6 from Jakub Jelinek ---
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;
for (i = 0; i < N; i++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59318
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59352
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59404
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59463
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59540
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59548
Paolo Carlini changed:
What|Removed |Added
CC||fdumont at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766
Paolo Carlini changed:
What|Removed |Added
CC||adam at jessamine dot co.uk
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59681
Paolo Carlini changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766
Paolo Carlini changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59548
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #9 from Kostya Serebryany ---
> 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 preprocessor... ../libibert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #10 from Kostya Serebryany ---
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 ---
(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 stage I get this:
> ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59384
--- Comment #4 from Nick Tomlinson ---
Created attachment 31944
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31944&action=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 ---
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 GCC, I get an incorrect warni
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 ---
Created attachment 31945
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31945&action=edit
C source of subroutines which contain problem for loop
This is a file from OPUS. As sent it can't be run, but the
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 changed:
What|Removed |Added
Target||s390x-ibm-linux
Priority|P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #12 from H.J. Lu ---
(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 ASAN_OPTIONS=sleep_before_dying=1000)
If
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #13 from Kostya Serebryany ---
> 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")
This happens due
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #14 from H.J. Lu ---
Created attachment 31946
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31946&action=edit
/proc/cc1plus/{maps,smaps,status}
This is the output of "cat /proc/cc1plus/{maps,smaps,status}".
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #15 from Kostya Serebryany ---
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 are not merged by the ke
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #16 from H.J. Lu ---
(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 two adjacent mappings wi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59917
--- Comment #2 from Jakub Jelinek ---
Created attachment 31947
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31947&action=edit
gcc49-pr59917.patch
Untested partial fix, which fixes the first testcase, but still ICEs with the
second testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
--- Comment #2 from Andreas Krebbel ---
Created attachment 31948
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31948&action=edit
Preprocessed file
compile with: -O2 -Warray-bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #17 from Kostya Serebryany ---
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
6110-61100098 rw-p 00:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
Kostya Serebryany changed:
What|Removed |Added
CC||eugeni.stepanov at gmail dot
com
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935
Bug ID: 59935
Summary: [4.9 Regression] Firefox build fails with: :
internal compiler error: Segmentation fault
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #19 from Kostya Serebryany ---
(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 in Kernel.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935
Markus Trippelsdorf changed:
What|Removed |Added
Last reconfirmed||2014-1-24
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920
Carlos O'Donell changed:
What|Removed |Added
CC||carlos at redhat dot com
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #20 from Evgeniy Stepanov ---
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 ---
A reproducer without ASan:
#include
#include
#include
#include
int main() {
char * p = (char*)0x61904c1e;
for (int i = 0; i < 100; ++i)
mmap(p + i * 4096, 4096, PROT_WRITE | PROT_READ, MAP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59927
--- Comment #4 from Jakub Jelinek ---
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)
{
bar (0);
}
Why do you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #22 from Kostya Serebryany ---
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.
However I'd like to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935
--- Comment #1 from Markus Trippelsdorf ---
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 _GNU_SOURCE
^
:0:0: note: this is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935
Dodji Seketeli changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524
--- Comment #13 from 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=207047&root=gcc&view=rev
Log:
/cp
2014-01-24 Paolo Carlini
PR c++/57524
* name-loo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524
--- Comment #14 from 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=207048&root=gcc&view=rev
Log:
/cp
2014-01-24 Paolo Carlini
PR c++/57524
* name-loo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Assignee
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59548
Jonathan Wakely changed:
What|Removed |Added
Known to work||4.6.4
Summary|Abort after co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920
--- Comment #4 from 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 left have no defined values at lon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886
--- Comment #8 from Jason Merrill ---
Author: jason
Date: Fri Jan 24 16:47:54 2014
New Revision: 207051
URL: http://gcc.gnu.org/viewcvs?rev=207051&root=gcc&view=rev
Log:
PR c++/59886
PR c++/59659
* typeck2.c (process_init_constructor_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59659
--- Comment #11 from Jason Merrill ---
Author: jason
Date: Fri Jan 24 16:47:54 2014
New Revision: 207051
URL: http://gcc.gnu.org/viewcvs?rev=207051&root=gcc&view=rev
Log:
PR c++/59886
PR c++/59659
* typeck2.c (process_init_constructor
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 changed:
What|Removed |Added
CC||krafczyk.matthew at gmail dot
com
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59659
--- Comment #12 from Jason Merrill ---
Author: jason
Date: Fri Jan 24 17:09:07 2014
New Revision: 207052
URL: http://gcc.gnu.org/viewcvs?rev=207052&root=gcc&view=rev
Log:
PR c++/59886
PR c++/59659
* g++.dg/opt/value-init2.C: Remove.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886
--- Comment #10 from Jason Merrill ---
Author: jason
Date: Fri Jan 24 17:09:07 2014
New Revision: 207052
URL: http://gcc.gnu.org/viewcvs?rev=207052&root=gcc&view=rev
Log:
PR c++/59886
PR c++/59659
* g++.dg/opt/value-init2.C: Remove.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58550
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
--- Comment #4 from Jakub Jelinek ---
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 MIN_MODE_VECTOR_INT are 0 bec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
--- Comment #5 from Jeffrey A. Law ---
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 ---
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 +221,11 @@ expmed_mode_inde
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
--- Comment #7 from Jakub Jelinek ---
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 stmts.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #34
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59820
--- Comment #4 from Richard Henderson ---
Should be fixed in glibc mainline, by
commit 4ab6acaebd0047dc37c6493946484be9f1b4920b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59820
Richard Henderson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59231
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58561
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59540
--- Comment #2 from Nenad Vukicevic ---
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 come back with an error.
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59540
--- Comment #3 from Nenad Vukicevic ---
Created attachment 31950
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31950&action=edit
Preprocessed file that causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58550
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58550
--- Comment #5 from Jason Merrill ---
Author: jason
Date: Fri Jan 24 19:05:39 2014
New Revision: 207055
URL: http://gcc.gnu.org/viewcvs?rev=207055&root=gcc&view=rev
Log:
PR c++/58550
* decl.c (grokdeclarator): Turn pedwarn about auto retu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59224
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
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 ---
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 rationale in the fix. Before changi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920
--- Comment #6 from Jakub Jelinek ---
(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 calls in it, so
> > star
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59548
--- Comment #6 from Jonathan Wakely ---
Author: redi
Date: Fri Jan 24 20:08:20 2014
New Revision: 207059
URL: http://gcc.gnu.org/viewcvs?rev=207059&root=gcc&view=rev
Log:
PR libstdc++/59548
* include/debug/safe_base.h (_Safe_sequence_base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59548
Jonathan Wakely changed:
What|Removed |Added
Known to work||4.9.0
Summary|[4.7/4.8/4.9 R
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=207060&root=gcc&view=rev
Log:
2014-01-24 Ed Smith-Rowland <3dw...@verizon.net>
PR libstdc++
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=207060&root=gcc&view=rev
Log:
2014-01-24 Ed Smith-Rowland <3dw...@verizon.net>
PR libstdc++
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=207060&root=gcc&view=rev
Log:
2014-01-24 Ed Smith-Rowland <3dw...@verizon.net>
PR libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
--- Comment #8 from Jeffrey A. Law ---
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 is pretty different.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59932
--- Comment #4 from Zhendong Su ---
(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 behavior.
> > > If p1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59919
--- Comment #6 from Jeffrey A. Law ---
Author: law
Date: Fri Jan 24 20:51:22 2014
New Revision: 207061
URL: http://gcc.gnu.org/viewcvs?rev=207061&root=gcc&view=rev
Log:
PR tree-optimization/59919
* tree-vrp.c (find_assert_locations_1): Do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59919
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59825
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674
--- Comment #9 from Andreas Schwab ---
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 ---
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, returning 0 when we don't (for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
--- Comment #10 from Jakub Jelinek ---
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) modes, then no mode will ha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59561
--- Comment #7 from Jakub Jelinek ---
Author: jakub
Date: Fri Jan 24 23:17:25 2014
New Revision: 207065
URL: http://gcc.gnu.org/viewcvs?rev=207065&root=gcc&view=rev
Log:
PR middle-end/59561
* cfgloopmanip.c (copy_loop_info): If
loop->
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #21 from Paul H. Hargrove ---
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... no
So the added configure
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
Prio
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 ---
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 ---
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
