http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40154
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59939
--- Comment #7 from Zhendong Su ---
Andrew, this actually feels to me more like a static type checking issue, i.e.,
whether the code is dead or not isn't all that relevant here. The important
thing is that the function fn1 takes two unsigned int's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59940
Bug ID: 59940
Summary: Imprecise column number for -Wconversion
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59939
--- Comment #6 from Andrew Pinski ---
(In reply to Chengnian Sun from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > (In reply to Chengnian Sun from comment #3)
> > > (In reply to Andrew Pinski from comment #1)
> > > > IIRC this was
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59939
--- Comment #5 from Chengnian Sun ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Chengnian Sun from comment #3)
> > (In reply to Andrew Pinski from comment #1)
> > > IIRC this was done so that code which uses macros and have condit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59929
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59939
--- Comment #4 from Andrew Pinski ---
(In reply to Chengnian Sun from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > IIRC this was done so that code which uses macros and have conditional code
> > like:
> >
> > MACRO1 || fn1(a, b)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59929
--- Comment #5 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Sat Jan 25 03:20:44 2014
New Revision: 207070
URL: http://gcc.gnu.org/viewcvs?rev=207070&root=gcc&view=rev
Log:
Get stack adjustment from push operand in pushsf splitter
pushsf for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59939
--- Comment #3 from Chengnian Sun ---
(In reply to Andrew Pinski from comment #1)
> IIRC this was done so that code which uses macros and have conditional code
> like:
>
> MACRO1 || fn1(a, b)
Sorry, I do not understand. Can you elaborate more? W
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59913
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59939
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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)
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=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=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=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=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=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=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=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=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=59825
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=59919
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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=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=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=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=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=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=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=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=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=59224
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
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=58550
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=59920
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
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=59231
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
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=59820
--- Comment #4 from Richard Henderson ---
Should be fixed in glibc mainline, by
commit 4ab6acaebd0047dc37c6493946484be9f1b4920b
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=59656
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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=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 #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 #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=58550
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
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=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=27557
Matthew Krafczyk changed:
What|Removed |Added
CC||krafczyk.matthew at gmail dot
com
---
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=59886
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=59934
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Assignee
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=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
--- 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=59935
Dodji Seketeli changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned a
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=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=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 #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=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=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 #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=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
Kostya Serebryany changed:
What|Removed |Added
CC||eugeni.stepanov at gmail dot
com
---
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=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=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=59920
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
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=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=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=57524
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
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=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 #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=59934
Andreas Krebbel changed:
What|Removed |Added
Target||s390x-ibm-linux
Priority|P3
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=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=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=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=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=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=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 #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=59548
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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
1 - 100 of 113 matches
Mail list logo
