https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780
--- Comment #8 from russelldub at gmail dot com ---
> May be the patch should be submitted to fort...@gcc.gnu.org (for next stage1).
I'd be happy if this could be resolved. Should I submit or someone with more
clout among the gfortran maintainer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63743
Thomas Preud'homme changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369
--- Comment #6 from Matthias Klose ---
I see this with -O3, not -O3. working to get a reduced test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369
--- Comment #5 from Martin Sebor ---
While I haven't isolated it yet I suspect a bug in nettle and not one in gcc,
for at least three reasons:
First, the failures are insensitive to optimization levels. Second, the same
two failures also appear
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
seen when enabling mpx and x32 multilibs
looks like the configure.tgt is too permissive
x86_64-*-linux* | i?86-*-linux*)
libtool: compile: /home/packages/gcc/5/gcc-5-5-20150310/build/./gcc/xgcc
-B/home/packages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61047
--- Comment #19 from Jakub Jelinek ---
*** Bug 65383 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65383
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
gcc version 5.0.0 20150310 (experimental) [trunk revision 221299] (GCC)
$
$ gcc-trunk -Os small.c; ./a.out
0
$ gcc-4.6.4 -O2 small.c; ./a.out
0
$
$ gcc-trunk -O2 small.c
$ ./a.out
Segmentation fault (core dumped)
$
-
int printf (const char *, ...);
int a, b, c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
--- Comment #13 from Jeffrey A. Law ---
But you can need updates that extend beyond the scope of the SEME I would
think. That was my recollection from looking at ways to minimize the number of
blocks the renamer had to examine after threading.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
--- Comment #12 from Sebastian Pop ---
(In reply to Jeffrey A. Law from comment #11)
> That is unless the SEME copier tries to update SSA internally, but that's
> painful.
I have also tried to update the SSA only in the copied basic blocks: grap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
--- Comment #11 from Jeffrey A. Law ---
>From a sequencing standpoint, you do your block copying & wire up the new
blocks. Then you have to remove unreachable blocks, rebuild dominators then
update hte SSA graph.
That is unless the SEME copier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
--- Comment #10 from Sebastian Pop ---
Created attachment 35005
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35005&action=edit
add update_ssa to seme copier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
--- Comment #9 from Sebastian Pop ---
I added a pass of update_ssa after each invocation of the SEME copier, and that
produced 26 extra fails (on top of the failing test) in the hmmer make check.
The problem with adding an update_ssa is that we h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65382
Jonathan Wakely changed:
What|Removed |Added
Keywords||accepts-invalid
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65370
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65382
--- Comment #1 from Vlad Gheorghiu ---
I compiled with gcc5 and also with gcc4.9.2, using `-Wall -Wextra -pedantic`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65024
--- Comment #12 from Paul Thomas ---
Author: pault
Date: Tue Mar 10 22:24:01 2015
New Revision: 221338
URL: https://gcc.gnu.org/viewcvs?rev=221338&root=gcc&view=rev
Log:
2015-03-10 Paul Thomas
PR fortran/65024
* trans-expr.c (gfc_con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65370
--- Comment #6 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Tue Mar 10 22:20:41 2015
New Revision: 221337
URL: https://gcc.gnu.org/viewcvs?rev=221337&root=gcc&view=rev
Log:
/cp
2015-03-10 Paolo Carlini
PR c++/65370
* decl.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
--- Comment #8 from Jeffrey A. Law ---
There's not enough information in those comments to definitively say the SEME
copier isn't updating the SSA graph properly. If I were looking at this, I'd
want the dump as we enter VRP or DOM (whichever is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64441
Tim Shen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369
--- Comment #4 from Martin Sebor ---
I've downloaded nettle-3.0 from http://ftp.gnu.org/gnu/nettle, built it with
the default options (-O2) with last week's trunk (5.0.0 20150303) and the
system GCC 4.8.3 on a ppc64le box running RHEL 7.1, and ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #50 from boger at us dot ibm.com ---
(In reply to Ian Lance Taylor from comment #49)
> libbacktrace returns the line number that you actually care about: the line
> number of the call instruction. There is no question that that is cor
cimal-float --disable-bootstrap --disable-alsa
--prefix=/home/bergner/gcc/install/gcc-fsf-mainline-vlad-lra-r221324
Thread model: posix
gcc version 5.0.0 20150310 (experimental) [trunk revision 221324] (GCC)
[bergner@makalu-lp1 LRA]$
/home/bergner/gcc/build/gcc-fsf-mainline-vlad-lra-r221324/gcc/x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65368
Jakub Jelinek changed:
What|Removed |Added
Summary|[4.8/4.9/5 |[4.8/4.9
|Regression]_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #49 from Ian Lance Taylor ---
libbacktrace returns the line number that you actually care about: the line
number of the call instruction. There is no question that that is correct.
You say that it is a problem if the PC does not mat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #48 from boger at us dot ibm.com ---
(In reply to Ian Lance Taylor from comment #47)
> We have to separate backtrace_full and backtrace_simple, which are part of
> the libbacktrace library, from functions like runtime_callers which are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65024
--- Comment #11 from Paul Thomas ---
Author: pault
Date: Tue Mar 10 19:39:05 2015
New Revision: 221334
URL: https://gcc.gnu.org/viewcvs?rev=221334&root=gcc&view=rev
Log:
2015-03-10 Paul Thomas
PR fortran/65024
* trans-expr.c (gfc_con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64896
--- Comment #11 from Yvan Roux ---
Author: yroux
Date: Tue Mar 10 19:20:30 2015
New Revision: 221333
URL: https://gcc.gnu.org/viewcvs?rev=221333&root=gcc&view=rev
Log:
gcc/
2015-03-10 Yvan Roux
Backport from trunk r220489.
2015-02-06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64895
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63491
--- Comment #7 from Vladimir Makarov ---
(In reply to Peter Bergner from comment #6)
> (In reply to Vladimir Makarov from comment #5)
> > Sorry, I can not reproduce the bug on the today trunk. Probably it was
> > fixed by numerous changes in LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65127
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Tue Mar 10 19:10:43 2015
New Revision: 221332
URL: https://gcc.gnu.org/viewcvs?rev=221332&root=gcc&view=rev
Log:
PR c++/65127
* parser.c (parsing_nsdmi): Don't return true if curr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64950
--- Comment #3 from vries at gcc dot gnu.org ---
> 0005-Postpone-expanding-va_arg-until-pass_stdarg.patch
> Submitted for stage1:
> https://gcc.gnu.org/ml/gcc-patches/2015-02/msg01332.html
Pinged: https://gcc.gnu.org/ml/gcc-patches/2015-03/msg005
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64441
--- Comment #4 from Tim Shen ---
Author: timshen
Date: Tue Mar 10 18:41:46 2015
New Revision: 221330
URL: https://gcc.gnu.org/viewcvs?rev=221330&root=gcc&view=rev
Log:
PR libstdc++/64441
* include/bits/regex.h (match_results<>::size,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #47 from Ian Lance Taylor ---
We have to separate backtrace_full and backtrace_simple, which are part of the
libbacktrace library, from functions like runtime_callers which are part of
libgo. The libbacktrace library is used by sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65333
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65381
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070
Dominique d'Humieres changed:
What|Removed |Added
CC||jwmwalrus at gmail dot com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65333
--- Comment #3 from Jason Merrill ---
Author: jason
Date: Tue Mar 10 17:44:48 2015
New Revision: 221328
URL: https://gcc.gnu.org/viewcvs?rev=221328&root=gcc&view=rev
Log:
PR c++/65333
DR 1558
* pt.c (dependent_type_p_r): Check both c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65381
Bug ID: 65381
Summary: ICE during array result, assignment
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65127
--- Comment #5 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #3)
> So it seems current_class_ptr is no longer just NULL or a PARM_DECL, but can
> be also ADDR_EXPR of a PLACEHOLDER_EXPR. Dunno if the right fix is
> just
> bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65332
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65333
--- Comment #2 from Jason Merrill ---
*** Bug 65332 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380
--- Comment #1 from Tobias Burnus ---
Created attachment 35004
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35004&action=edit
two.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380
Bug ID: 65380
Summary: [5 Regression] LTO: ICE in add_symbol_to_partition_1,
at lto/lto-partition.c:158
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65333
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
Aldy Hernandez changed:
What|Removed |Added
Summary|[4.8/4.9/5 Regression] |[4.8/4.9 Regression] cross
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65379
Bug ID: 65379
Summary: ifcvt does not clean up dead instructions
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
--- Comment #42 from Aldy Hernandez ---
Author: aldyh
Date: Tue Mar 10 16:37:53 2015
New Revision: 221326
URL: https://gcc.gnu.org/viewcvs?rev=221326&root=gcc&view=rev
Log:
PR bootstrap/25672
* configure.ac: Do not initialize CFLAGS_FOR_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #45 from Ian Lance Taylor ---
If we change the PC returned by backtrace_full, and then use that changed PC to
look up file/line information, we might get different results. That seems
clear. My next question is: when does this matte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65378
--- Comment #1 from David Malcolm ---
(In reply to David Malcolm from comment #0)
[...]
> Message in question is here in ipa-devirt.c:
> if (!warning_at (DECL_SOURCE_LOCATION (TYPE_NAME (t1)), OPT_Wodr,
> "type %qT violates one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65367
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65367
--- Comment #4 from Marek Polacek ---
Author: mpolacek
Date: Tue Mar 10 15:57:45 2015
New Revision: 221325
URL: https://gcc.gnu.org/viewcvs?rev=221325&root=gcc&view=rev
Log:
PR sanitizer/65367
* ubsan.c (ubsan_expand_objsize_ifn): Update
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65378
Bug ID: 65378
Summary: Tweak to wording of -Wodr message
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Ass
n/install/gcc-host-libs --without-ppl --without-cloog
--enable-languages=c,fortran,c++ --disable-bootstrap
Thread model: posix
gcc version 5.0.0 20150310 (experimental) [trunk revision 221324] (GCC)
[pthaugen@igoo testsuite]$ ~/install/gcc/trunk/bin/g++ -std=c++98 -O2
-ftree-vectorize -fno-ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65323
--- Comment #4 from Paolo Carlini ---
I sent a patch to the mailing list about this. If we don't want to apply it and
we want to be super-conservative, we can indeed simply do this, with a comment,
in my opinion:
@@ -11227,11 +11243,14 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65323
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #44 from boger at us dot ibm.com ---
If we do the increment of the pc to fix it in the callback, here is how that
happens:
- backtrace_full gets the pc and decrements by 1
- backtrace_full calls backtrace_pcinfo to look up the file, fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #43 from Ian Lance Taylor ---
I'm getting confused. I think I need to talk about one thing at a time.
You say that libbacktrace is returning incorrect line numbers. That obviously
needs to be fixed. When does that happen?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65366
--- Comment #1 from Jan Kratochvil ---
[patch] PR other/65366: Fix gdbhooks.py for GDB with Python3
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00502.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65286
Markus Trippelsdorf changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358
James Greenhalgh changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65286
--- Comment #10 from Jakub Jelinek ---
Author: jakub
Date: Tue Mar 10 13:54:11 2015
New Revision: 221324
URL: https://gcc.gnu.org/viewcvs?rev=221324&root=gcc&view=rev
Log:
PR target/65286
* config/rs6000/t-linux: For powerpc64* target se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65286
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Tue Mar 10 13:52:48 2015
New Revision: 221323
URL: https://gcc.gnu.org/viewcvs?rev=221323&root=gcc&view=rev
Log:
PR target/65286
* config/rs6000/t-linux: For powerpc64* target set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65286
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Tue Mar 10 13:43:44 2015
New Revision: 221322
URL: https://gcc.gnu.org/viewcvs?rev=221322&root=gcc&view=rev
Log:
PR target/65286
* config/rs6000/t-linux: For powerpc64* target set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #24 from Sven ---
Comment #4 mentions typedef int myint __attribute__((aligned(1)));
That shouldn't even work. The GCC documentation on Type Attributes mentions
that "The aligned attribute can only increase the alignment". It goes on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342
--- Comment #10 from Alan Modra ---
> permitted? (i.e. modifying %1, which is an input operand)
Yes. You're outputting assembly, practically anything goes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342
--- Comment #9 from Alan Modra ---
As far as fixing the real underlying problem goes, I'm not so familiar with the
darwin support that I can state with certainty that you need to fix movdi_low
and friends.
It might help to explain why powerpc64-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #23 from Sven ---
FYI: I have asked the llvm folks to add a warning to their compiler for the
when a pointer to a member of a packed struct is assigned to an "ordinary"
pointer with higher alignment guarantees. Clearly, I agree with c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #28 from Richard Biener ---
(In reply to rguent...@suse.de from comment #27)
> On Tue, 10 Mar 2015, jakub at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
> >
> > Jakub Jelinek changed:
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342
--- Comment #8 from Iain Sandoe ---
BTW, is:
(define_insn "movdi_low_st"
[(set (mem:DI (lo_sum:DI (match_operand:DI 1 "gpc_reg_operand" "b,b,b")
(match_operand 2 "" "Y,,")))
(match_operand:DI 0 "gpc_reg_operand"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342
--- Comment #7 from Iain Sandoe ---
(In reply to Alan Modra from comment #6)
> Created attachment 35001 [details]
> workaround
>
> You might like to consider this patch that effectively reverts r210201 for
> Darwin. This should cure the regress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65367
--- Comment #3 from Marek Polacek ---
Reduced:
int
foo (char *p)
{
return *((const char *) "") - *p;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #27 from rguenther at suse dot de ---
On Tue, 10 Mar 2015, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
>
> Jakub Jelinek changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342
--- Comment #6 from Alan Modra ---
Created attachment 35001
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35001&action=edit
workaround
You might like to consider this patch that effectively reverts r210201 for
Darwin. This should cure th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #26 from Richard Biener ---
Author: rguenth
Date: Tue Mar 10 12:44:01 2015
New Revision: 221321
URL: https://gcc.gnu.org/viewcvs?rev=221321&root=gcc&view=rev
Log:
2015-03-09 Richard Biener
PR middle-end/44563
* tree-inlin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #42 from boger at us dot ibm.com ---
(In reply to Ian Lance Taylor from comment #41)
> I really don't want libbacktrace to be processor-dependent. That makes all
> uses of it more complex for no significant gain. Maybe we should c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65343
--- Comment #2 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
> Maybe we want to placement-new the mutexes into a buffer so they are never
> destroyed, although on mingw that will show up as leaked resources at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #24 from Richard Biener ---
So in gimple_expand_calls_inline we could look only at BBs last stmt for the
actual inlining but for the rest just do the basic-block splitting. And then
perform that walk backwards. This should remove the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #23 from Richard Biener ---
Funnily apart from the IPA inline summary updating issue the next important
time-hog is basic-block splitting we do for inlining a call. This is because
split_block moves the tail of the block to a new one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65363
--- Comment #3 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> FRE can only eliminate the dominated one (obviously), so the first one is
> the one prevailing.
I don't understand that.
Say we have load A (loading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65370
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|paolo.carlin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65377
--- Comment #8 from npl at chello dot at ---
This (and the Iso recommendation) doesnt answer the question whether the
__has_cpp_attribute macro should be defined for C sources either (it seems
illogical to me).
Guess its undefined and not a bug, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
Richard Biener changed:
What|Removed |Added
Known to work||4.8.3, 5.0
Summary|[4.9/5 Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
--- Comment #7 from Richard Biener ---
Author: rguenth
Date: Tue Mar 10 11:16:33 2015
New Revision: 221318
URL: https://gcc.gnu.org/viewcvs?rev=221318&root=gcc&view=rev
Log:
2015-03-10 Richard Biener
PR middle-end/63155
* tree-ssa-co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65377
--- Comment #7 from Markus Trippelsdorf ---
Unfortunately https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02357.html hasn't
been checked in yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65377
--- Comment #6 from npl at chello dot at ---
(In reply to npl from comment #3)
> 1) It simply shouldnt fail.
> 2) this is a generic header for C and C++.
>
> __has_cpp_attribute(clang::fallthrough) should resolve to 0 and not fail.
> This is a bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65377
--- Comment #5 from Andrew Pinski ---
Use the proper check if you are want check if you are compiling c++ code first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65377
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65365
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65377
npl at chello dot at changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65365
--- Comment #3 from Jakub Jelinek ---
Ok with me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65365
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |4.9.4
--- Comment #2 from Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65377
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65377
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65377
Bug ID: 65377
Summary: [5.0 Regression] cpp attribute check ala clang fails
to compile
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: major
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64895
--- Comment #6 from vries at gcc dot gnu.org ---
>From PR64342 comment 7:
Register allocation seems to progress similarly, up until this message in
reload, which seems to be directly related to the r216154 patch:
...
Spill r86 after risky tra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65370
Markus Trippelsdorf changed:
What|Removed |Added
CC||paolo.carlini at oracle dot com
1 - 100 of 146 matches
Mail list logo
