https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802
--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to vries from comment #5)
> So the question is: should ifn_va_arg have ECF_NOTHROW?
Adding ECF_NOTHROW to ifn_va_arg also fixes the ICE.
And at gimplify_va_arg_expr, the VA_ARG_EXPR tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549
--- Comment #30 from rguenther at suse dot de ---
On Fri, 17 Apr 2015, jason at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549
>
> Jason Merrill changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65807
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |5.2
--- Comment #2 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65805
Richard Biener changed:
What|Removed |Added
Known to work||6.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802
--- Comment #7 from Richard Biener ---
(In reply to vries from comment #6)
> (In reply to vries from comment #5)
> > So the question is: should ifn_va_arg have ECF_NOTHROW?
>
> Adding ECF_NOTHROW to ifn_va_arg also fixes the ICE.
>
> And at gim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65797
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |5.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65796
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802
--- Comment #8 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #7)
> (In reply to vries from comment #6)
> > (In reply to vries from comment #5)
> > > So the question is: should ifn_va_arg have ECF_NOTHROW?
> >
> > Addi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #5 from Richard Bie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809
Dominique d'Humieres changed:
What|Removed |Added
Target|x86_64-apple-darwin14.3 |*-apple-darwin*
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809
--- Comment #2 from Jakub Jelinek ---
So most likely r211689 ? Can you attach assembly created by r211688 and
r211689 ?
Isn't this just a darwin linker bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809
--- Comment #3 from Dominique d'Humieres ---
Created attachment 35361
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35361&action=edit
assembly created by r211652
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809
--- Comment #4 from Dominique d'Humieres ---
Created attachment 35362
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35362&action=edit
assembly created by r211698
The difference between the assembly created by r211652 and r211698 is the
si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65807
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801
--- Comment #3 from Paolo Carlini ---
Ok, thus what shall we do? Shall we go back to my minimal patch which only
touched enums? https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00880.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810
--- Comment #5 from Dominique d'Humieres ---
Why is this not seen on powerpc64-unknown-linux-gnu at
https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg02317.html?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809
--- Comment #5 from Iain Sandoe ---
(In reply to Dominique d'Humieres from comment #4)
> Created attachment 35362 [details]
> assembly created by r211698
>
> The difference between the assembly created by r211652 and r211698 is the
> single line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65807
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
vries at gcc dot gnu.org changed:
What|Removed |Added
CC||rth at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
--- Comment #59 from Uroš Bizjak ---
(In reply to vries from comment #58)
> Given the fix of PR64950, we should be able to remove the workaround
> committed for this PR.
I have started bootstrap/regtest with the following revert:
--cut here--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801
--- Comment #5 from Paolo Carlini ---
Well, at the time I think we agreed that we wanted to be strict at least about
enums... Otherwise, yes, we can do that plus setting ok = true in that case
too, thus collapsing the last two ifs (+ reverting th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65811
Bug ID: 65811
Summary: ice in vague_linkage_p
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64134
--- Comment #3 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Mon Apr 20 10:29:26 2015
New Revision: 29
URL: https://gcc.gnu.org/viewcvs?rev=29&root=gcc&view=rev
Log:
[AArch64] PR/64134: Make aarch64_expand_vector_init use 'i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65811
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809
--- Comment #6 from Jakub Jelinek ---
No, __emutls_v.a certainly is not a user variable, that is an artificial
object, the thread local variable of course lives elsewhere.
You could just drop the stabs for TLS vars on the floor, stabs really does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65812
Bug ID: 65812
Summary: gcc 4.9.1 doesn't warn about uninitialized variable
use declared in a switch/case statement when compiled
with -O
Product: gcc
Version: 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65673
--- Comment #3 from Marek Polacek ---
The following seems to work and regtests cleanly. But I have to say I'm
somewhat dubious now about changing this at all. I suppose I should try to
compile e.g. the Linux kernel with this patch and see if an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65812
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809
--- Comment #7 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #6)
> No, __emutls_v.a certainly is not a user variable, that is an artificial
> object, the thread local variable of course lives elsewhere.
> You could just drop the st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65812
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65812
--- Comment #3 from Joe Perches ---
Thank you both for your very prompt replies.
It might be useful to have a -Wunused-eliminated type extra warning
though that might be very noisy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65813
Bug ID: 65813
Summary: GO: bug347.go segment violation on S390x
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65811
Marek Polacek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131
--- Comment #20 from Thomas Koenig ---
First submitted patch:
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00969.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65811
--- Comment #3 from Marek Polacek ---
struct foo { int i; };
static void fn1 ();
inline void
fn1 ()
{
static struct foo a[1];
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788
--- Comment #6 from H.J. Lu ---
r18 failed for me:
https://gcc.gnu.org/ml/gcc-regression/2015-04/msg00231.html
My GCC was configured with
--prefix=/export/gnu/import/git/gcc-test-spec-lto/usr --enable-clocale=gnu
--with-system-zlib --enabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788
--- Comment #7 from rguenther at suse dot de ---
On Mon, 20 Apr 2015, hjl.tools at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788
>
> --- Comment #6 from H.J. Lu ---
> r18 failed for me:
>
> https://gcc.gnu.org/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788
--- Comment #8 from H.J. Lu ---
I am using ld.bfd from binutils master branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788
--- Comment #9 from Richard Biener ---
Can you please try to reduce it to a testcase?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810
--- Comment #6 from Alan Modra ---
It isn't seen most of the time because the failure happens only when r2 isn't
16-byte aligned (50% chance) and the r2 offset to a long double constant is
n*64k+32k-8 (0.012% chance per long double). libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60806
Maxim Kuvyrkov changed:
What|Removed |Added
CC||mkuvyrkov at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65807
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Mon Apr 20 13:30:01 2015
New Revision: 32
URL: https://gcc.gnu.org/viewcvs?rev=32&root=gcc&view=rev
Log:
PR debug/65807
* dwarf2out.c (add_AT_wide): Clear attr.dw_attr_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65807
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Mon Apr 20 13:31:02 2015
New Revision: 33
URL: https://gcc.gnu.org/viewcvs?rev=33&root=gcc&view=rev
Log:
PR debug/65807
* dwarf2out.c (add_AT_wide): Clear attr.dw_attr_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65814
Bug ID: 65814
Summary: [5/6 Regression] FAIL:
libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_on_dev
ice-1.c -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0 exec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65814
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65742
Jakub Jelinek changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65807
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65808
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65812
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #40 from mwahab at gcc dot gnu.org ---
(In reply to Andrew Macleod from comment #25)
> Documentation needs updating for sure... The rules have changed under us
> since originally SEQ_CST and sync were intended to be the same thing...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65812
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #12 from Robbert ---
(In reply to Richard Biener from comment #10)
> and see how this will make PTA useless (all pointers passed to a function
> whose result might be used in a way to take advantage of an equality relation
> need to b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65808
--- Comment #2 from David L. ---
(In reply to Marek Polacek from comment #1)
> I don't think it is a bug. If you use -pedantic, it doesn't matter whether
> -std=c11 or -std=gnu11 (the default) is in effect.
> If you want to suppress the warning,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65681
--- Comment #1 from Andrew Sutton ---
This is a good one. It is a regression, but it didn't have to do with the
resolution of partial specializations.
The substitution into requires-expressions was too eagerly doing full semantic
on analysis on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65808
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809
--- Comment #8 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #7)
> (In reply to Jakub Jelinek from comment #6)
> > --- gcc/dbxout.c 2015-02-04 23:36:33.875630546 +0100
> > +++ gcc/dbxout.c 2015-04-20 12:27:14.579948127 +0200
> > @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809
--- Comment #9 from Jakub Jelinek ---
Then perhaps one needs to check
TREE_CODE (decl) == VAR_DECL
&& (TREE_STATIC (decl) || DECL_EXTERNAL (decl))
&& decl_tls_model (decl) != TLS_MODEL_NONE
instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801
--- Comment #6 from Jason Merrill ---
(In reply to Paolo Carlini from comment #5)
> Well, at the time I think we agreed that we wanted to be strict at least
> about enums... Otherwise, yes, we can do that plus setting ok = true in that
> case too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801
--- Comment #7 from Paolo Carlini ---
Yes, I was thinking that in such cases clang does something we don't normally
do (ie, an hard error by default suppressible with a -Wno-*). Let me see if we
can achieve that as you suggested.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809
--- Comment #10 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #9)
> Then perhaps one needs to check
>
> TREE_CODE (decl) == VAR_DECL
> && (TREE_STATIC (decl) || DECL_EXTERNAL (decl))
> && decl_tls_model (decl) != TLS_MODEL_NONE
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64918
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65815
Bug ID: 65815
Summary: std::array initialization with initializer list: a =
{x,y,z} incorrectly flagged as syntax error
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65815
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788
H.J. Lu changed:
What|Removed |Added
Status|WAITING |NEW
LE (GCC) version 6.0.0 20150420 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.3 20140911 (Red Hat 4.8.3-7), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 6.0.0 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #41 from mwahab at gcc dot gnu.org ---
(In reply to torvald from comment #38)
> (In reply to Andrew Macleod from comment #34)
>
> Also, if you look at the IA-64 __sync_lock_release vs. GCC docs'
> __sync_lock_release, the latter is li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801
--- Comment #8 from Paolo Carlini ---
Jason, as far as I can see *nowhere* else in the compiler we fiddle with
flag_pedantic_errors, all the tweaks I tried look super hackish to me :( If we
are Ok with just going back to pedwarns the attached pas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801
--- Comment #9 from Paolo Carlini ---
Created attachment 35367
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35367&action=edit
Draft patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65815
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65813
--- Comment #1 from Ian Lance Taylor ---
I think you know this, but to be clear, the test is supposed to dereference a
null pointer, and then it's supposed to recover from the run time panic.
The program should unwind the stack for the signal an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65813
Dominik Vogt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65606
Marek Polacek changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816
Bug ID: 65816
Summary: Constructor delegation does not perform
zero-initialization
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816
Jonathan Wakely changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65658
--- Comment #2 from Jeffrey A. Law ---
Author: law
Date: Mon Apr 20 17:13:52 2015
New Revision: 42
URL: https://gcc.gnu.org/viewcvs?rev=42&root=gcc&view=rev
Log:
PR tree-optimization/65658
* tree-ssa-threadupdate.c (redirection_b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65732
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65817
Bug ID: 65817
Summary: libcc1: ICE: SEGV: c_incomplete_type_error()
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65817
--- Comment #1 from Jan Kratochvil ---
Created attachment 35368
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35368&action=edit
GDB patch
GDB patch to crash GCC.
together with:
cat >1.c <
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65817
--- Comment #2 from Jan Kratochvil ---
Created attachment 35369
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35369&action=edit
Attempted GCC fix.
With this GCC fix and the GDB reproducer it looks as fixed:
gdb command line:1:1: error: i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801
--- Comment #10 from Paolo Carlini ---
I'm also attaching what I have for the forced pedantic-errors idea.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801
--- Comment #11 from Paolo Carlini ---
Created attachment 35370
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35370&action=edit
Draft patch 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65658
--- Comment #3 from Jeffrey A. Law ---
Author: law
Date: Mon Apr 20 19:35:50 2015
New Revision: 47
URL: https://gcc.gnu.org/viewcvs?rev=47&root=gcc&view=rev
Log:
PR tree-optimization/65658
* tree-ssa-threadupdate.c (redire
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65658
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801
--- Comment #12 from Jason Merrill ---
(In reply to Paolo Carlini from comment #11)
> Draft patch 2
I think let's go with this. It's odd, but not complex and does what we want.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65818
Bug ID: 65818
Summary: libiberty/vprintf-support.c:41:1: ICE: in expand_i
fn_va_arg_1, at tree-stdarg.c:1095
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801
Paolo Carlini changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65180
--- Comment #6 from boger at us dot ibm.com ---
I have verified this testcase now passes on ppc64le with today's gcc-5-branch
and with gcc trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801
--- Comment #14 from Jakub Jelinek ---
(In reply to Paolo Carlini from comment #13)
> Ok, I'll commit it in an hour or so to trunk. Is it too late for 5.1?
It is IMHO too late for that, but not too late for 5.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65818
--- Comment #1 from John David Anglin ---
Created attachment 35371
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35371&action=edit
Preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819
Bug ID: 65819
Summary: overzealous checking in gfc_check_dependency for
identical=true
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819
Thomas Koenig changed:
What|Removed |Added
Keywords||missed-optimization
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801
--- Comment #15 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Mon Apr 20 21:46:59 2015
New Revision: 49
URL: https://gcc.gnu.org/viewcvs?rev=49&root=gcc&view=rev
Log:
/cp
2015-04-20 Paolo Carlini
PR c++/65801
* typeck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65820
Bug ID: 65820
Summary: escape backslashes in .d file
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65821
Bug ID: 65821
Summary: [4.8.2 regression] incorrect debug line # info for
main
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65767
--- Comment #3 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Apr 21 02:23:18 2015
New Revision: 55
URL: https://gcc.gnu.org/viewcvs?rev=55&root=gcc&view=rev
Log:
PR testsuite/65767
* g++.dg/lto/pr65276_0.C: Change nam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65822
Bug ID: 65822
Summary: [4.8.2 regression] Used variant fun names in dwarf
info for CTORs
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65821
--- Comment #1 from Andrew Pinski ---
It is doing (b+3) first which is from :5 which seems correct to me. Default
arguments should have a line information right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65821
--- Comment #2 from chihin ko ---
(In reply to Andrew Pinski from comment #1)
> It is doing (b+3) first which is from :5 which seems correct to me. Default
> arguments should have a line information right?
Then gdb should stop at line 30 first
1 - 100 of 108 matches
Mail list logo
