https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70021
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953
--- Comment #12 from john.frankish at outlook dot com ---
Is there any hope of a patch to fix this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70023
Bug ID: 70023
Summary: [4.9/5/6 Regression] ICE: in assign_by_spills, at
lra-assigns.c:1417 with
-fno-sched-critical-path-heuristic -fschedule-insns
-m8bit-idiv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69824
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70021
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70017
Dominik Vogt changed:
What|Removed |Added
Summary|Ada: c52103x test failure |c52103x and c52104x test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70022
Bug ID: 70022
Summary: [4.9/5/6 Regression] ICE: in tree_to_shwi, at
tree.c:7328 with out-of-bounds vector index
Product: gcc
Version: 6.0
Status: UNCONFIRMED
K
trunk/mpfr-3.1.3/bin
--with-mpc=/gcc-trunk/mpc-1.0.3/bin --prefix=/gcc-trunk/bin
Thread model: posix
gcc version 6.0.0 20160229 (experimental) (Revision=233809)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70005
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70020
Bug ID: 70020
Summary: Forward propagation leaves compile-time computable
conditional in IL
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70009
--- Comment #3 from cesar at gcc dot gnu.org ---
Thanks for the info. I'm travelling this week, so I won't have a chance to look
at this until next Monday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011
--- Comment #6 from Bill Schmidt ---
Author: wschmidt
Date: Tue Mar 1 04:14:15 2016
New Revision: 233840
URL: https://gcc.gnu.org/viewcvs?rev=233840&root=gcc&view=rev
Log:
2016-02-29 Bill Schmidt
PR target/70011
* gcc.dg/vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826
--- Comment #14 from Martin Sebor ---
(In reply to Andrew Pinski from comment #12)
Thank your for catching it. I did actually read all the comments. The trouble
is that there are several test cases here and I missed the one in the second
half
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67813
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826
Bill Seurer changed:
What|Removed |Added
CC||seurer at linux dot
vnet.ibm.com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70019
Martin Sebor changed:
What|Removed |Added
Keywords||wrong-code
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70019
Bug ID: 70019
Summary: VLA size overflow not detected
Product: gcc
Version: 4.9.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69961
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69961
--- Comment #3 from Patrick Palka ---
Author: ppalka
Date: Tue Mar 1 01:24:44 2016
New Revision: 233838
URL: https://gcc.gnu.org/viewcvs?rev=233838&root=gcc&view=rev
Log:
Fix PR c++/69961 (invalid ctor call with dependent args)
gcc/cp/ChangeLo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68948
--- Comment #16 from Patrick Palka ---
Author: ppalka
Date: Tue Mar 1 01:24:44 2016
New Revision: 233838
URL: https://gcc.gnu.org/viewcvs?rev=233838&root=gcc&view=rev
Log:
Fix PR c++/69961 (invalid ctor call with dependent args)
gcc/cp/ChangeL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #21 from David Malcolm ---
Author: dmalcolm
Date: Tue Mar 1 01:02:49 2016
New Revision: 233836
URL: https://gcc.gnu.org/viewcvs?rev=233836&root=gcc&view=rev
Log:
PR preprocessor/69985: fix ICE with long lines in -Wformat
gcc/testsu
: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160229 (experimental) [trunk revision 233802] (GCC)
$:
$: gcc-trunk -O2 -fgraphite-identity small.c
small.c: In function ‘main’:
small.c:3:5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69706
--- Comment #11 from Eric Botcazou ---
Author: ebotcazou
Date: Tue Mar 1 00:22:26 2016
New Revision: 233833
URL: https://gcc.gnu.org/viewcvs?rev=233833&root=gcc&view=rev
Log:
PR target/69706
* config/sparc/sparc.c (NWORDS_UP): R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70005
--- Comment #3 from Jeffrey A. Law ---
Author: law
Date: Tue Mar 1 00:04:48 2016
New Revision: 233829
URL: https://gcc.gnu.org/viewcvs?rev=233829&root=gcc&view=rev
Log:
PR tree-optimization/70005
* tree-ssa-uncprop.c (associate_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70005
--- Comment #2 from Jeffrey A. Law ---
Thanks. Something unexpected slipped through the IL confusing uncprop. So
there's really two issues here. Why did an always-true/always-false test
manage to survive until uncprop, a missed optimization, b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #6 from Jeffrey A. Law ---
Author: law
Date: Mon Feb 29 22:45:41 2016
New Revision: 233824
URL: https://gcc.gnu.org/viewcvs?rev=233824&root=gcc&view=rev
Log:
PR tree-optimization/6
* gimple-ssa-split-paths.c (spli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46459
--- Comment #7 from Harald Anlauf ---
The patch of comment #1 (adjusted to current trunk) regtests cleanly
for me.
(In reply to Mikael Morin from comment #5)
> The initial test doesn't lead to a segfault any more.
>
> It is now rejected with:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69988
--- Comment #8 from John Paul Adrian Glaubitz ---
(In reply to jos...@codesourcery.com from comment #7)
> libgo.so should have been linked with -lc (probably an implicit -lc from
> some spec used when linking shared libraries).
Can you suggest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69988
--- Comment #7 from joseph at codesourcery dot com ---
libgo.so should have been linked with -lc (probably an implicit -lc from
some spec used when linking shared libraries).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69989
--- Comment #11 from Jeffrey A. Law ---
The last proposal (clear LOOPS_NEED_FIXUP) is a possibility. I can poke at
that a bit, but I really wonder if it'd be better for gcc-7 and for gcc-6 if we
should just use localized fixups rather than tryin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69988
--- Comment #6 from John Paul Adrian Glaubitz ---
(In reply to Andreas Schwab from comment #5)
> The gccgo commandline uses -static-libgcc. Make sure that -lgcc is linked
> after libgo.
Shouldn't it be -lc since the symbols in question are now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984
--- Comment #9 from Edmar Wienskoski ---
Ok. Thanks for the clarification.
The comparison is made with an unsigned variable, but gcc
is certain that this variable cannot have (legally) a value that
cannot be represented in an int.
That is why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70018
--- Comment #6 from Sanjoy Das ---
(In reply to Andrew Pinski from comment #5)
> Oh I see pure/const behavior.
>
> The problem is more complex, in that in one TU, the comdat function is
> figured out to be pure/const so we remove the store befor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70018
Andrew Pinski changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637
--- Comment #5 from marc at kdab dot com ---
You have a very narrow test of NRVO.
You're using a completely transparent type, though I give you that defining the
copy and move ctors in a separate TU does not change the outcome. At some point
I'l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70018
--- Comment #4 from Sanjoy Das ---
(In reply to Andrew Pinski from comment #2)
> So in summary what you are seeing is two effects going into effect here:
> undefined behavior of division by 0 and ODR.
There is no division by zero (or any other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70018
--- Comment #3 from Sanjoy Das ---
(In reply to Andrew Pinski from comment #1)
> In C++ code, the one definition rule says that all TU that contains an
> inline function, they need to have the same definition. If they have
> different definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #5 from Jeffrey A. Law ---
It's widely known that that node splitting can turn an irreducible loop into a
reducible loop. And that's precisely what's happening here. Sigh.
Something tells me that long term we may want some degree o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70018
--- Comment #2 from Andrew Pinski ---
Also one more point, in this example both inline functions have the same
definition. Both answers are valid answers for this case. That is doing the
division (causing the trap on x86_64) don't have to happe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70018
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70002
--- Comment #5 from Jakub Jelinek ---
See e.g. PR61925.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70002
--- Comment #4 from Jakub Jelinek ---
The problem I see e.g. in aarch64 or rs6000 is that it in some cases uses
NULL_TREE for old_tree or new_tree, and in that case doesn't change anything.
But in reality, not changing anything if old_tree != new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70018
Bug ID: 70018
Summary: Possible issue around IPO and C++ inline functions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70002
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70002
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70009
Andrew Pinski changed:
What|Removed |Added
Target|powerpc*-*-*|powerpc*-*-*, aarch64-*-*
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984
--- Comment #8 from Jakub Jelinek ---
0x7fff * 0x7 is 0x3fff0001 and that is representable in int, so there is no
overflow.
0xb504 * 0xb504 is 0x7ffea810 and thus also representable in int, no overflow.
0xb505ULL * 0xb505ULL is 0x80001219ULL,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984
--- Comment #7 from Andrew Pinski ---
(In reply to Edmar Wienskoski from comment #6)
> Hummm, You are almost convincing me, one last question,
> be patient with me.
>
> As Andrew posted:
> C = A * B
> should be equivalent to:
> C = (unsigned lon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70002
Andrew Pinski changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70016
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984
--- Comment #6 from Edmar Wienskoski ---
Hummm, You are almost convincing me, one last question,
be patient with me.
As Andrew posted:
C = A * B
should be equivalent to:
C = (unsigned long)( ((int)A) * ((int)B) )
The variables are promoted *bef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69811
Jakub Jelinek changed:
What|Removed |Added
Summary|[5/6 Regression] A gcc |A gcc folding issue at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70017
Bug ID: 70017
Summary: Ada: c52103x test failure on s390x
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984
--- Comment #5 from Jakub Jelinek ---
Even if the computation is 32-bit, by the time you multiply say (unsigned short
int) 0x with itself, you get undefined behavior.
So, as has been said, if you want to perform the multiplication in unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70006
--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #5)
> > OK, How about WONTFIX? If the programmer fixes the
> > issue reported in the "duplicate" error message, then
> > the problem goes away.
>
> W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69788
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Target|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #20 from David Malcolm ---
In r230331 I added a range-packing optimization; looks like I forgot to update
linemap_position_for_loc_and_offset accordingly. Sorry. The input "offset" is
a column offset, and that is no longer applicabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011
Bill Schmidt changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69983
--- Comment #5 from Richard Biener ---
comment #2 (In reply to Richard Biener from comment #2)
> So we fail analyzing the loop nest because a) the loop header check of the
> inner
> loop makes it conditionally executed, b) we have outer loop IV c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70014
--- Comment #1 from Richard Earnshaw ---
More importantly, the constraint on operand 2 is for just a constant. but the
predicate accepts a register. That's something the register allocator could
not handle.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637
--- Comment #4 from Thomas Braun ---
(I'm no gcc dev at all)
In general gcc is much better in doing NRVO/URVO than other compilers according
to my analysis [1]. So maybe the competitors need to get better first ;)
[1]: http://www.byte-physics.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #19 from Manuel López-Ibáñez ---
(In reply to Manuel López-Ibáñez from comment #18)
> I don't really understand why this is the case: we seem to waste a lot of
> location numbers that do not point to anything. If there is a way to tel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984
--- Comment #4 from Edmar Wienskoski ---
I forgot that default on x86 is 64 bits.
Repeating the test with -m32 still shows the signed comparison.
Here:
#include
void main ()
{
unsigned short int A, B;
unsigned long C,D;
unsigned long E =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53637
--- Comment #3 from marc at kdab dot com ---
This really should be top priority. But no comment on it for almost three years
by GCC devs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055
--- Comment #6 from marc at kdab dot com ---
To expand on my previous comment: the compiler is even allowed to elide the
copy if that would save a read/write from a volatile object. So I don't see how
this can be implemented anywhere except the fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63433
Ramana Radhakrishnan changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #18 from Manuel López-Ibáñez ---
I think the heuristic I implemented to figure out on which map we can encode
the new location does not work.
The heuristic assumes that if map[0].start_location <= loc + offset <
map[1].start_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65189
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69798
--- Comment #4 from Marek Polacek ---
There are two c_parser_postfix_expression calls that should probably be guarded
with something like
8044 if (c_parser_peek_2nd_token (parser)->type !=
CPP_OPEN_PAREN
8045 ||
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70007
H.J. Lu changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #3 from H.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44281
Bernd Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69994
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Mon Feb 29 15:30:50 2016
New Revision: 233816
URL: https://gcc.gnu.org/viewcvs?rev=233816&root=gcc&view=rev
Log:
2016-02-29 Richard Biener
PR tree-optimization/69994
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69994
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69984
--- Comment #2 from Edmar Wienskoski ---
Right, but the variables A and B are *unsigned short*.
Both A, and B are promoted to signed int, but max value is 65535.
So, the result of A*B *can* be bigger than 31 bits.
Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70016
--- Comment #2 from ktkachov at gcc dot gnu.org ---
this_target_ira_int->x_init_cost is NULL when it's used, causing the ICE.
I would have expected target_reinit to have properly initialised it when called
through save_target_globals_default_opts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65985
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69995
--- Comment #6 from Jason Merrill ---
Author: jason
Date: Mon Feb 29 14:49:17 2016
New Revision: 233813
URL: https://gcc.gnu.org/viewcvs?rev=233813&root=gcc&view=rev
Log:
PR c++/69995
* constexpr.c (cxx_eval_store_expression): Un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65985
--- Comment #7 from Jason Merrill ---
Author: jason
Date: Mon Feb 29 14:49:12 2016
New Revision: 233812
URL: https://gcc.gnu.org/viewcvs?rev=233812&root=gcc&view=rev
Log:
PR c++/65985
* constexpr.c (build_constexpr_constructor_me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69995
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70008
--- Comment #1 from Richard Earnshaw ---
Huh? The attribute
(set_attr "arch" "*,a")
Should disable the second alternative for Thumb.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011
--- Comment #3 from Bill Schmidt ---
I'll have a look at the differences in output from GCC 5 and GCC 6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70016
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69652
--- Comment #10 from Ilya Enkovich ---
Author: ienkovich
Date: Mon Feb 29 14:32:24 2016
New Revision: 233811
URL: https://gcc.gnu.org/viewcvs?rev=233811&root=gcc&view=rev
Log:
gcc/testsuite/
2016-02-29 Yuri Rumyantsev
PR tree-optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70016
Bug ID: 70016
Summary: [Regression] pr52429.c fails since r233745
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #17 from David Malcolm ---
(In reply to David Malcolm from comment #16)
> Created attachment 37825 [details]
> Minimal reproducer
>
> Looks like BZ line-wrapped the inline copy; here it is as an attachment.
Interestingly, Chromium l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69798
--- Comment #3 from Marek Polacek ---
Started with r204172.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #16 from David Malcolm ---
Created attachment 37825
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37825&action=edit
Minimal reproducer
Looks like BZ line-wrapped the inline copy; here it is as an attachment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #15 from David Malcolm ---
A minimal reproducer:
$ cat t3.c
extern int printf (const char *__restrict __format, ...);
void test (void)
{
printf
("%llu012334567890123345678901233456789012334567890123345678901233456789012334567890123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69995
--- Comment #4 from Jason Merrill ---
Author: jason
Date: Mon Feb 29 14:25:57 2016
New Revision: 233810
URL: https://gcc.gnu.org/viewcvs?rev=233810&root=gcc&view=rev
Log:
PR c++/69995
* constexpr.c (cxx_eval_store_expression): Un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #14 from David Malcolm ---
(gdb) p *map
$8 = { = {start_location = 98229568, reason = LC_RENAME_VERBATIM},
to_file = 0x2709850 "cmds-check.c", to_line = 7836,
included_from = -1, sysp = 0 '\000', m_column_and_range_bits = 12,
m_ran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #13 from Markus Trippelsdorf ---
Yeah, see also comment 5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #12 from David Malcolm ---
(In reply to Manuel López-Ibáñez from comment #11)
> (In reply to Markus Trippelsdorf from comment #6)
> > Bingo! With both files present I can even reproduce it on my x86_64 machine.
>
> Unfortunately, I c
1 - 100 of 148 matches
Mail list logo
