https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87428
--- Comment #2 from Richard Biener ---
Author: rguenth
Date: Wed Sep 26 07:05:01 2018
New Revision: 264594
URL: https://gcc.gnu.org/viewcvs?rev=264594&root=gcc&view=rev
Log:
2018-09-26 Richard Biener
PR debug/87428
PR debug/8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87362
--- Comment #17 from Richard Biener ---
Author: rguenth
Date: Wed Sep 26 07:05:01 2018
New Revision: 264594
URL: https://gcc.gnu.org/viewcvs?rev=264594&root=gcc&view=rev
Log:
2018-09-26 Richard Biener
PR debug/87428
PR debug/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
--- Comment #31 from Tamar Christina ---
> It seems that some paths are properly translated though, for example the
> library paths. Do you know why? It would be nice to have the gnatlink
> command line that gave rise to the invocation quoted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
--- Comment #32 from Eric Botcazou ---
> Full build log is here
> https://mistuke.blob.core.windows.net/binaries/logs/build.log
Thanks.
> It may be the quoting around the options for --LINK that's causing the shell
> not to convert the paths. T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
--- Comment #33 from Tamar Christina ---
> Do you know whether it would be possible to force the conversion by applying
> some trick to GCC_LINK in ada/gcc-interface/Makefile.in?
Yeah usually, cygpath -w would convert a path, seems we alias tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
--- Comment #34 from David ---
My primary concern in 87316 was about memory usage and this patch definitely
helps a lot with that. Thanks!
Using -ftree-coalesce-vars helps on >= 4.9 versions and does not seem to have
an adverse effect on test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67656
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67656
--- Comment #1 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Wed Sep 26 09:08:24 2018
New Revision: 264596
URL: https://gcc.gnu.org/viewcvs?rev=264596&root=gcc&view=rev
Log:
2018-09-26 Paolo Carlini
PR c++/67656
* g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 67656, which changed state.
Bug 67656 Summary: [concepts] matched variadics in expression constraint report
as unmatched
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67656
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87439
Bug ID: 87439
Summary: [9 regression] ICE in ix86_mode_needed, at
config/i386/i386.c:18907
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87439
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87415
--- Comment #3 from Aldy Hernandez ---
Created attachment 44753
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44753&action=edit
untested patch
1-bit signed fields are weird in that 0 - (-MIN) is still -MIN. In any other
world, it is an i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67655
--- Comment #1 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Wed Sep 26 09:23:00 2018
New Revision: 264638
URL: https://gcc.gnu.org/viewcvs?rev=264638&root=gcc&view=rev
Log:
2018-09-26 Paolo Carlini
PR c++/67655
* g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67655
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 67655, which changed state.
Bug 67655 Summary: [concepts] expression constraints and variadic expansions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67655
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87436
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87439
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87428
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87362
Bug 87362 depends on bug 87428, which changed state.
Bug 87428 Summary: "Missed" inline instances cause bogus DWARF to be emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87428
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71130
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85065
Paolo Carlini changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 71130, which changed state.
Bug 71130 Summary: [concepts] Ill-formed code declaring a variable with a
non-type concept not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71130
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71126
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85065
--- Comment #5 from Paolo Carlini ---
*** Bug 71126 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 71126, which changed state.
Bug 71126 Summary: [concepts] ICE on ill-formed code declaring a variable with
a non-type concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71126
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87440
Bug ID: 87440
Summary: GCC creates debug that confuses gdb
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87440
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71127
--- Comment #1 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Wed Sep 26 09:59:56 2018
New Revision: 264639
URL: https://gcc.gnu.org/viewcvs?rev=264639&root=gcc&view=rev
Log:
2018-09-26 Paolo Carlini
PR c++/71131
* g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71131
--- Comment #1 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Wed Sep 26 09:59:56 2018
New Revision: 264639
URL: https://gcc.gnu.org/viewcvs?rev=264639&root=gcc&view=rev
Log:
2018-09-26 Paolo Carlini
PR c++/71131
* g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71127
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85065
--- Comment #6 from Paolo Carlini ---
*** Bug 71127 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 71127, which changed state.
Bug 71127 Summary: [concepts] ICE on ill-formed code declaring a variable with
a template concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71127
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71131
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85065
--- Comment #7 from Paolo Carlini ---
*** Bug 71131 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 71131, which changed state.
Bug 71131 Summary: [concepts] Ill-formed code declaring a variable with a
template concept not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71131
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 67970, which changed state.
Bug 67970 Summary: [concepts] variable template bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67970
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67970
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77314
--- Comment #2 from Harald van Dijk ---
(In reply to Harald van Dijk from comment #1)
> A workaround for current GCC versions is to use an array of size 1.
That, by the way, shows an existing code generation problem:
struct S { S(); };
stru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68510
--- Comment #5 from Paolo Carlini ---
Can't reproduce with the active branches or the released 6.1.0 for that matter.
Marek, can you double check?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68437
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 68437, which changed state.
Bug 68437 Summary: [concepts] fold expression, pack expansion, and deduced
constraint requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68437
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77314
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87440
--- Comment #2 from Richard Biener ---
Created attachment 44754
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44754&action=edit
not working patch
Simply merging the single subblock of an inline block runs afoul several
issues:
- dead bloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87441
Bug ID: 87441
Summary: Found compiler internal error: in tsubst at
cp/pt.c:13657
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87442
Bug ID: 87442
Summary: Add options to filter files we want to instrument for
code coverage
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87443
Bug ID: 87443
Summary: GCC mixes abstract and concrete instances in abstract
origins for inlines
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87443
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87442
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #34 from Martin Liška ---
For the next version of the patch:
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01529.html
I seen even better results:
TOTAL warnings: 23
drivers/net/wireless/ralink/rt2x00/rt2800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87347
--- Comment #4 from Martin Jambor ---
Author: jamborm
Date: Wed Sep 26 11:58:18 2018
New Revision: 264640
URL: https://gcc.gnu.org/viewcvs?rev=264640&root=gcc&view=rev
Log:
[PR 87347] Prevent segfaults if TYPE_ARG_TYPES is NULL
2018-09-26 Mart
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87347
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #4 from Vincent Lefèvre ---
(In reply to jos...@codesourcery.com from comment #3)
> I believe this is correct for C99 (see the discussions in bug 82071): [...]
Bug 82071 has no discussions. The main reference is N1531, which one can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87442
calixte changed:
What|Removed |Added
CC||mcastelluccio at mozilla dot
com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87442
Martin Liška changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58774
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87439
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Uroš Bizjak ---
> Following patch should fix the problem:
[...]
It did indeed: bootstrapped without regressions on i386-pc-solaris2.11.
Thanks.
Rainer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87444
Bug ID: 87444
Summary: 'gcc -marc=native' sets L2 cache size equal to L3
cache size on i7 and i5 CPU
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87444
--- Comment #1 from Uroš Bizjak ---
This is by design.
A comment in driver-i386.c says:
/* Let the L3 replace the L2. This assumes inclusive caches
and single threaded program for now. */
if (level3.sizekb)
level2 = level3;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87444
--- Comment #2 from George ---
Forgive me, I am not a developer and I am not aware how this was designed. But
may I ask: why was it designed to be wrong and why only on particular CPUs?
Also: what happens when a wrong l2-cache-size is used? Won'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87444
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87434
--- Comment #1 from Richard Biener ---
+ rtx new_mem = gen_rtx_MEM (GET_MODE (mem), derived_ptr_reg);
+ MEM_COPY_ATTRIBUTES (new_mem, mem);
I think it's dangerous to use old MEMs attributes this way, esp. MEM_EXPR
and fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87444
--- Comment #4 from George ---
Richard Biener,
Thanks for the reply. Unfortunately I don't understand what it means - whether
I should set explicitly the correct l2-cache-size or if that has any effect on
the final binary.
But I realise this ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59439
Jonathan Wakely changed:
What|Removed |Added
Attachment #31405|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87434
--- Comment #2 from kelvin at gcc dot gnu.org ---
Thanks for this suggestion. I'll investigate further.
(My intent was to advise the compiler that this new memory address expression
computes the same memory location as the original memory addres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87443
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87443
--- Comment #3 from Richard Biener ---
Author: rguenth
Date: Wed Sep 26 14:35:48 2018
New Revision: 264643
URL: https://gcc.gnu.org/viewcvs?rev=264643&root=gcc&view=rev
Log:
2018-09-26 Richard Biener
PR debug/87443
* dwarf2ou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59439
--- Comment #9 from Jonathan Wakely ---
Using current trunk and -O2 to compile the benchmark in comment 8 I get:
snprintf
1 threads took 11 ms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59439
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87439
--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Sep 26 14:55:59 2018
New Revision: 264645
URL: https://gcc.gnu.org/viewcvs?rev=264645&root=gcc&view=rev
Log:
PR target/87439
* config/i386/i386.h (NUM_MODES_FO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71278
--- Comment #1 from Uroš Bizjak ---
Author: uros
Date: Tue Sep 25 14:26:11 2018
New Revision: 264571
URL: https://gcc.gnu.org/viewcvs?rev=264571&root=gcc&view=rev
Log:
PR target/71278
* config/i386/i386.md (frndintxf2_mask_pm): R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71278
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59439
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64120
--- Comment #9 from Paul Thomas ---
(In reply to Francois-Xavier Coudert from comment #0)
> The following code shows allocatable character does not work as it should:
>
>call g(1)
> contains
> subroutine g(x)
> integer :: x
> c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87441
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #5 from joseph at codesourcery dot com ---
It's 6.3.1.4 for conversions between real floating and integer types that,
in C99 but not C11, I think requires the resulting value to be
representable in the resulting real floating type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87414
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Wed Sep 26 17:00:49 2018
New Revision: 264651
URL: https://gcc.gnu.org/viewcvs?rev=264651&root=gcc&view=rev
Log:
PR target/87414
* config/i386/i386.c: Include debug.h and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #6 from Vincent Lefèvre ---
(In reply to jos...@codesourcery.com from comment #5)
> It's 6.3.1.4 for conversions between real floating and integer types that,
> in C99 but not C11, I think requires the resulting value to be
> repres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87445
Bug ID: 87445
Summary: missing null test optimization for a pointer member
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87445
Martin Sebor changed:
What|Removed |Added
Keywords||missed-optimization
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #7 from joseph at codesourcery dot com ---
On Wed, 26 Sep 2018, vincent-gcc at vinc17 dot net wrote:
> > It's 6.3.1.4 for conversions between real floating and integer types that,
> > in C99 but not C11, I think requires the resulti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #8 from Vincent Lefèvre ---
(In reply to jos...@codesourcery.com from comment #7)
> It's the "If the value being converted is in the range of values that can
> be represented but cannot be represented exactly" bit I'm concerned with,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #9 from joseph at codesourcery dot com ---
On Wed, 26 Sep 2018, vincent-gcc at vinc17 dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
>
> --- Comment #8 from Vincent Lefèvre ---
> (In reply to jos...@codesourcer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #30 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #10 from Joseph S. Myers ---
Author: jsm28
Date: Wed Sep 26 21:14:16 2018
New Revision: 264656
URL: https://gcc.gnu.org/viewcvs?rev=264656&root=gcc&view=rev
Log:
Support excess precision for integer / floating-point comparisons (PR c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
Vincent Lefèvre changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #13 from joseph at codesourcery dot com ---
On Wed, 26 Sep 2018, vincent-gcc at vinc17 dot net wrote:
> But there are no differences with 6.3.1.4 (when converting to a floating
> type):
> in both cases, either the value can be repre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #14 from Vincent Lefèvre ---
(In reply to jos...@codesourcery.com from comment #13)
> On Wed, 26 Sep 2018, vincent-gcc at vinc17 dot net wrote:
>
> > But there are no differences with 6.3.1.4 (when converting to a floating
> > type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #15 from Vincent Lefèvre ---
Note also that 6.3.1.5p2 occurs in case of explicit conversions or function
calls, not in typical floating-point expressions, in which types can be
promoted, but never demoted. So, I don't see really what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #16 from joseph at codesourcery dot com ---
On Wed, 26 Sep 2018, vincent-gcc at vinc17 dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
>
> --- Comment #14 from Vincent Lefèvre ---
> (In reply to jos...@codesourc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #17 from Vincent Lefèvre ---
(In reply to jos...@codesourcery.com from comment #16)
> On Wed, 26 Sep 2018, vincent-gcc at vinc17 dot net wrote:
> > which distinction?
>
> The one you made above, between values that can be represented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #18 from Vincent Lefèvre ---
Anyway, I recall that the behavior related to extra precision and range is
described by 6.3.1.8. Thus I really don't see why 6.3.1.4 and 6.3.1.5 would
come into play here (except in case of explicit conver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #19 from joseph at codesourcery dot com ---
On Wed, 26 Sep 2018, vincent-gcc at vinc17 dot net wrote:
> 6.3.1.5p2 is only about explicit conversions and function calls (otherwise,
> types are not demoted magically). But in my example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86957
--- Comment #6 from qinzhao at gcc dot gnu.org ---
Author: qinzhao
Date: Wed Sep 26 22:29:54 2018
New Revision: 264657
URL: https://gcc.gnu.org/viewcvs?rev=264657&root=gcc&view=rev
Log:
2018-09-26 Indu Bhagat
PR gcov-profile/86957
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #20 from joseph at codesourcery dot com ---
I think the statement in 6.3.1.8 is only observing a consequence of
specifications elsewhere, and stating that this excess range and precision
does not affect semantic types; it does not,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87364
--- Comment #4 from Will Wray ---
Thanks Martin,
I investigated enum template args with GCC bug 81932 test code,
repeating its GDB Python-debug-print test case for enum args.
Conclusion:
This change to enum printing does not cause GDB to fail t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #21 from Vincent Lefèvre ---
(In reply to jos...@codesourcery.com from comment #20)
> I think the statement in 6.3.1.8 is only observing a consequence of
> specifications elsewhere,
No, 6.3.1.8 gives a specification about the choice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #22 from joseph at codesourcery dot com ---
6.3.1.8 specifies *types*. It only gives some partial information about
*evaluation formats*, which is essentially a consequence of information
elsewhere (it states the possibility of wid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87392
--- Comment #8 from Eugeniu Rosca ---
On 2018-09-25 at 08:53:34 UTC, Jonathan Wakely wrote in comment #6:
> He already did. Comment 1 quotes the GCC manual which references
> the relevant sections of the standards.
Comment 1 does indeed referen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #23 from Vincent Lefèvre ---
(In reply to jos...@codesourcery.com from comment #22)
> 6.3.1.8 specifies *types*. It only gives some partial information about
> *evaluation formats*, which is essentially a consequence of information
1 - 100 of 108 matches
Mail list logo
