http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #3 from Jakub Jelinek ---
Not even with r202421.
Content of main with that revision for x86_64 -Os is:
.cfi_startproc
pushq%rcx
.cfi_def_cfa_offset 16
movla(%rip), %esi
testl%esi, %esi
je.L4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #2 from Zhendong Su ---
(In reply to Jakub Jelinek from comment #1)
> Can't reproduce this, neither with 64-bit nor 32-bit.
Jakub, perhaps fixed in later revisions? I tested it using 202421.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
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=58342
Bug 58342 depends on bug 58340, which changed state.
Bug 58340 Summary: [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler
error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380
--- Comment #11 from Jeffrey A. Law ---
Fixed on trunk.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380
--- Comment #10 from Jeffrey A. Law ---
Author: law
Date: Wed Sep 11 02:23:48 2013
New Revision: 202489
URL: http://gcc.gnu.org/viewcvs?rev=202489&root=gcc&view=rev
Log:
PR tree-optimization/58380
* tree-ssa-threadupdate.c (thread_block):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58386
--- Comment #1 from Dmitry G. Dyachenko ---
Forget to mention: FAIL from c#1 was with make -j5 / 4 CPU
with -enable-checking=release and 'make' FAIL differ
checking for x86_64-unknown-linux-gnu-gcc...
/home/dimhen/build/gcc_current/./gcc/xgcc
-B
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58385
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
++,objc,obj-c++,fortran,lto
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130910 (experimental) [trunk revision 202421] (GCC)
$ gcc-trunk -O1 small.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
--- Comment #10 from davidxl at google dot com ---
When an incoming edge to a phi is a critical edge, the 'use BB' for the phi arg
should be in the split BB of the edge. Pushing the use into either the Source
BB or the dest BB will result in exte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
--- Comment #41 from Kai Tietz ---
Author: ktietz
Date: Tue Sep 10 16:19:45 2013
New Revision: 202474
URL: http://gcc.gnu.org/viewcvs?rev=202474&root=gcc&view=rev
Log:
Backport from trunk.
PR libstdc++/54314
* config/abi/p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58346
--- Comment #7 from joseph at codesourcery dot com ---
On Tue, 10 Sep 2013, rguenther at suse dot de wrote:
> A similar (runtime) error can be provoked by subtracting pointers
> to array elements of variable size that happen to have zero size
> a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58374
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56671
Tudor Bosman changed:
What|Removed |Added
CC||tudorb at fb dot com
--- Comment #2 from T
ead model: posix
gcc version 4.9.0 20130910 (experimental) (GCC)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58386
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58382
--- Comment #3 from dave.anglin at bell dot net ---
Agreed. Testing fix.
Thanks,
Dave
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
--- Comment #9 from davidxl at google dot com ---
(In reply to Richard Biener from comment #5)
> Confirmed with the C++ FE, works with the C FE. Does not warn on trunk (for
> no good reason I think, the reason seems to be presence of loop structur
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58382
--- Comment #2 from rsandifo at gcc dot gnu.org
---
I think this is a target bug. The backend prologue code has things like:
addr = gen_rtx_MEM (DFmode, gen_rtx_POST_INC (DFmode, tmpreg));
but {PRE,POST}_{INC,DEC} is an address rtx,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
--- Comment #8 from davidxl at google dot com ---
(In reply to Neil Vachharajani from comment #7)
> It seems like the whole problem is that the loop early exit goes through
> bb_6 which is the same path the back-edge goes through.
There is also on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58374
--- Comment #2 from Caroline Tice ---
Even though I logged in to Bugzilla, I can't seem to edit any of the fields
above, but to the best of my knowledge a patch to fix this problem has been
committed to GCC and this bug should be marked as fixed a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58367
--- Comment #3 from Markus Trippelsdorf ---
(In reply to Markus Trippelsdorf from comment #2)
> Todays trunk is fine again. I guess r58343 might be the fix.
I meant r202441 is the fix and therefore this bug may be a dup of PR58343.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58361
--- Comment #3 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Sep 10 16:53:15 2013
New Revision: 202476
URL: http://gcc.gnu.org/viewcvs?rev=202476&root=gcc&view=rev
Log:
PR target/58361
* arm/vfp.md (combine_vcvt_f32_): Fix pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58367
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
Neil Vachharajani changed:
What|Removed |Added
CC||nvachhar at google dot com
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58386
Bug ID: 58386
Summary: [4.9 regression] libstdc++.so.6: undefined symbol:
htab_hash_pointer
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
--- Comment #4 from R Copley ---
(In reply to Kai Tietz from comment #1)
> MS' abi doesn't allow this. So I doubt we will be able to implement that
> for this target. If we want to re-align stack on function-base we will run
> into troubles with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58385
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58361
Richard Earnshaw changed:
What|Removed |Added
Keywords||wrong-code
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
--- Comment #3 from R Copley ---
Created attachment 30794
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30794&action=edit
Assembly-language code compiled from attachment 1
Compiled with GCC 4.7.2 from the MinGW-w64 toolchain.
Compile comman
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58386
--- Comment #2 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Tue Sep 10 18:45:29 2013
New Revision: 202480
URL: http://gcc.gnu.org/viewcvs?rev=202480&root=gcc&view=rev
Log:
2013-09-10 Paolo Carlini
PR bootstrap/58386
Revert:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58385
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milesto
c/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/regehr/z/compiler-source/gcc/configure
--prefix=/home/regehr/z/compiler-install/gcc-r202470-install
--enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 4.9.0 20130910 (experimental) (GCC)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
--- Comment #35 from Jakub Jelinek ---
The #c34 testcase seems to fail starting r199048 till current HEAD.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58374
--- Comment #1 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Tue Sep 10 16:00:13 2013
New Revision: 202470
URL: http://gcc.gnu.org/viewcvs?rev=202470&root=gcc&view=rev
Log:
Move VTV_SUPPORTED check after AC_CANONICAL_SYSTEM
PR other/5837
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380
--- Comment #8 from Jeffrey A. Law ---
This looks like slightly different variant of 58343 where we thread through a
loop header when we really didn't want to.
I haven't tracked it through to the ICE, but from looking at the CFG and the
registere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58375
Georg-Johann Lay changed:
What|Removed |Added
Keywords||ra
Status|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
--- Comment #2 from R Copley ---
Created attachment 30793
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30793&action=edit
As before, but with explicitly 32-byte aligned variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58375
--- Comment #3 from Georg-Johann Lay ---
Created attachment 30792
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30792&action=edit
Channel.cpp C++ source
Confirmed with this source, looks like a register allocator issue.
$ avr-g++ Channel.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380
--- Comment #9 from David Binderman ---
(In reply to Jeffrey A. Law from comment #7)
> Presumably David bootstrapped the trunk, then built k3d?
Yes, the bootstrap ran fine with the usual -g -O2 on BOOT_CFLAGS.
> If this failure occurs in a sta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58369
--- Comment #3 from Mikael Pettersson ---
The ICE occurs because reload is asking for a DFmode (8-byte) subreg of an
XFmode (12-byte) hardreg, but 12 % 8 != 0 so the gcc_assert fails.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58361
--- Comment #4 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Sep 10 16:55:44 2013
New Revision: 202477
URL: http://gcc.gnu.org/viewcvs?rev=202477&root=gcc&view=rev
Log:
PR target/58361
* arm/vfp.md (combine_vcvt_f32_): Fix pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
davidxl at google dot com changed:
What|Removed |Added
CC||davidxl at google dot com
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58384
--- Comment #1 from Yuri Rumyantsev ---
Created attachment 30791
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30791&action=edit
test-case to reproduce
This is compile only test which must be compiled with pre-reload scheduler,
i.e.
with '-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58361
--- Comment #2 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Sep 10 16:46:55 2013
New Revision: 202475
URL: http://gcc.gnu.org/viewcvs?rev=202475&root=gcc&view=rev
Log:
PR target/58361
* arm/vfp.md (combine_vcvt_f32_): Fix pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58384
Bug ID: 58384
Summary: [4.9 regression] Runfail on spec2000/253.perlbmk if
lto and pre-reload scheduler is used on x86 after
r200133.
Product: gcc
Version: 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
--- Comment #23 from Paolo Carlini ---
Thanks a lot Chris. Sorry if I bother you for a few minutes more: when you say
"doing away with skipping optimizations altogether", you mean, essentially,
using the algorithm we have got now for forward itera
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58382
--- Comment #1 from John David Anglin ---
Breakpoint 1, trunc_int_for_mode (c=8, mode=DFmode)
at ../../gcc/gcc/explow.c:55
55gcc_assert (SCALAR_INT_MODE_P (mode));
(gdb) bt
#0 trunc_int_for_mode (c=8, mode=DFmode) at ../../gcc/gcc/exp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381
--- Comment #1 from Martin Husemann ---
The global pointer "line_table" is changed to the contents of the precompiled
header file in gt_pch_restore in this loop:
/* Read in all the global pointers, in 6 easy loops. */
for (rt = gt_ggc_rtab;
I have a generated C code file that contains a very large number of function
calls, all with similar function names (ie ff1, ff2, ff3, ..., ff50). It
compiles using gcc versions 3.4.6 and 4.1.2.
But using version 4.4.7, it gets gcc: Internal error: Segmentation
fault (program cc1)
The co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58335
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
--- Comment #40 from Pawel Sikora ---
$ grep ZTv0 *
gnu.ver:_ZTv0_n12_NS*;
gnu.ver:_ZTv0_n24_NS*;
gnu-versioned-namespace.ver:_ZTv0_n24_NS*;
versioned namespace doesn't provide *n12* for i686.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381
--- Comment #2 from Martin Husemann ---
Created attachment 30790
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30790&action=edit
Restore line_table and input_location before calling fatal_error when failing a
pch load
With this patch, the f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380
--- Comment #7 from Jeffrey A. Law ---
202296 doesn't change anything WRT sequencing of operations; it merely allows
the threader to dive a bit deeper into the CFG to determine a final target for
a jump threading opportunity.
Presumably David boo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
--- Comment #22 from Chris Jefferson ---
Her are some comparisons. Just to compare, I also checked doing away with
skipping optimisations altogether. Binary sizes (-O3, stripped)
current head: 11928
my code: 12248
Mitsuru: 11384
No ski
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380
--- Comment #6 from Richard Biener ---
The symptom hints at a released SSA name being looked at. That happens
if cfgcleanup looks at a dead code region (we especially run
TODO_cleanup_cfg before TODO_update_ssa to allow passes to be forgiving
wit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107
--- Comment #24 from Jack Howarth ---
(In reply to David Fang from comment #22)
> Do one of these apple libunwind sources (0.30, 0.35.1) correspond to what's
> bundled in libgcc_s in darwin8,9,10?
>
> http://opensource.apple.com/tarballs/libunwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380
Markus Trippelsdorf changed:
What|Removed |Added
CC||markus at trippelsdorf dot de
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380
--- Comment #4 from Marek Polacek ---
Thanks, the .ii file is huge and after an ~hour of reducing the creduce is
still at original file...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58382
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
Target Mil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #3 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
--- Comment #21 from Paolo Carlini ---
Sorry. Take my 1sec and 3.5secs, as, say, 4.5secs and 20secs. You see may
point.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
Paolo Carlini changed:
What|Removed |Added
Severity|minor |normal
--- Comment #20 from Paolo Carlini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58364
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
--- Comment #19 from Chris Jefferson ---
(In reply to Mitsuru Kariya from comment #15)
> Created attachment 30775 [details]
> Patch
>
> For your convenience, I attached a patch for this problem.
>
> This algorithm is always scanned to reverse or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58383
jgreenhalgh at gcc dot gnu.org changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58379
--- Comment #2 from Martin Husemann ---
(In reply to Richard Biener from comment #1)
> If you have a system that randomizes then you have to re-define the hook.
Besides ASLR there are various things out of control of the compiler that do
result i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58383
Bug ID: 58383
Summary: ICE when RTL folds vector operations using constants
after gne_int_mode changes
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58369
--- Comment #2 from Mikael Pettersson ---
Created attachment 30787
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30787&action=edit
hand-reduced test case
This is as small as I can get it without losing the ICE.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58373
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #5 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58373
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58343
Markus Trippelsdorf changed:
What|Removed |Added
CC||markus at trippelsdorf dot de
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380
Marek Polacek changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #2 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
Paolo Carlini changed:
What|Removed |Added
CC||paolo.carlini at oracle dot com
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58343
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58343
--- Comment #4 from Jeffrey A. Law ---
Author: law
Date: Tue Sep 10 12:29:58 2013
New Revision: 202441
URL: http://gcc.gnu.org/viewcvs?rev=202441&root=gcc&view=rev
Log:
PR tree-optimization/58343
* tree-ssa-threadupdate.c (thread_block):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58382
Bug ID: 58382
Summary: [4.9 Regression] unwind.inc:136:1: ICE: in
trunc_int_for_mode, at explow.c:55
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58365
Jakub Jelinek changed:
What|Removed |Added
Summary|[4.7/4.8/4.9 Regression]|[4.7 Regression] likely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58365
--- Comment #10 from Jakub Jelinek ---
Author: jakub
Date: Tue Sep 10 11:48:30 2013
New Revision: 202435
URL: http://gcc.gnu.org/viewcvs?rev=202435&root=gcc&view=rev
Log:
PR rtl-optimization/58365
* cfgcleanup.c (merge_memattrs): Also cle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58365
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Tue Sep 10 11:47:19 2013
New Revision: 202434
URL: http://gcc.gnu.org/viewcvs?rev=202434&root=gcc&view=rev
Log:
PR rtl-optimization/58365
* cfgcleanup.c (merge_memattrs): Also clea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
--- Comment #4 from Paolo Carlini ---
This one works for me but only with 4.8.x, not with mainline, and -Og didn't
exist in 4.7.x, thus it would not qualify as a regression, I'm afraid.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58379
--- Comment #1 from Richard Biener ---
Well, it doesn't _rely_ on it - it basically makes systems where that is the
case work out of the box (every system pre address-space-randomization area).
If you have a system that randomizes then you have t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55491
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57495
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55543
Kai Tietz changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #6 from Kai Tietz ---
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58378
--- Comment #6 from Olivier Grisel ---
Alright thanks again. For reference I just discovered that the issue has
recently been fixed in Python 3.4 by adding a new `forkserver` option to
multiprocessing.
http://bugs.python.org/issue8713
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52217
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58378
--- Comment #5 from Jakub Jelinek ---
Having a pthread_atfork child hook that would do freeing of memory, or
pthread_mutex_init etc. would only make invalid any OpenMP program using fork,
even those that use it correctly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381
Bug ID: 58381
Summary: crash in diagnostic_report_current_module when a
fatal_error happens during PCH processing on
NetBSD/spa64rc
Product: gcc
Version: 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58378
--- Comment #4 from Olivier Grisel ---
Thanks for the explanation. Would you consider a solution that would preserve
the state of the parent process and would just reset the thread pool data on
the child?
Otherwise we will have to consider that t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47596
Kai Tietz changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53485
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #2 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
--- Comment #3 from Roland Dreier ---
Even simpler test case for me:
$ cat x.cpp
// gcc -Og -Wall -Werror -c x.cpp
int pop ();
int pop_first_bucket;
int my_pop ()
{
int out;
while (pop_first_bucket)
if (pop_first_bucket && (ou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49922
Kai Tietz changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52061
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38614
Kai Tietz changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
--- Comment #2 from Roland Dreier ---
arg, I really apologize. I copied and pasted from the wrong window and ended
up with a test case that does NOT reproduce the issue, even on my system. Here
is one I triple checked does fail (and everything i
1 - 100 of 134 matches
Mail list logo
