[Bug rtl-optimization/84842] [7/8/9 Regression] ICE in verify_target_availability, at sel-sched.c:1569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842 --- Comment #14 from Alexander Monakov --- Thanks. I think the root cause on this x86_64 testcase is different. Arseny, in the meantime if by chance you have another x86_64 variant of this failure that doesn't require -funroll-all-loops, please post it as well.
[Bug tree-optimization/85275] copyheader peels off almost the entire iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85275 --- Comment #3 from Richard Biener --- Author: rguenth Date: Mon Apr 30 07:23:36 2018 New Revision: 259754 URL: https://gcc.gnu.org/viewcvs?rev=259754&root=gcc&view=rev Log: 2018-04-30 Richard Biener PR tree-optimization/28364 PR tree-optimization/85275 * tree-ssa-loop-ch.c (ch_base::copy_headers): Stop after copying first exit test. * gcc.dg/tree-ssa/copy-headers-5.c: New testcase. * gcc.dg/tree-ssa/predcom-8.c: Likewise. * gcc.dg/tree-ssa/cunroll-13.c: Rewrite to gimple testcase. * gcc.dg/tree-ssa/ivopt_mult_1.c: XFAIL. * gcc.dg/tree-ssa/ivopt_mult_1g.c: Add gimple variant that still passes. * gcc.dg/tree-ssa/ivopt_mult_2.c: XFAIL. * gcc.dg/tree-ssa/ivopt_mult_2g.c: Add gimple variant that still passes. * gcc.dg/tree-ssa/ssa-dom-thread-7.c: Adjust. * gcc.dg/tree-ssa/20030710-1.c: Likewise. * gcc.dg/tree-ssa/20030711-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-5.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_1g.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_2g.c trunk/gcc/testsuite/gcc.dg/tree-ssa/predcom-8.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/20030710-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/20030711-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/cunroll-13.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c trunk/gcc/tree-ssa-loop-ch.c
[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364 --- Comment #33 from Richard Biener --- Author: rguenth Date: Mon Apr 30 07:23:36 2018 New Revision: 259754 URL: https://gcc.gnu.org/viewcvs?rev=259754&root=gcc&view=rev Log: 2018-04-30 Richard Biener PR tree-optimization/28364 PR tree-optimization/85275 * tree-ssa-loop-ch.c (ch_base::copy_headers): Stop after copying first exit test. * gcc.dg/tree-ssa/copy-headers-5.c: New testcase. * gcc.dg/tree-ssa/predcom-8.c: Likewise. * gcc.dg/tree-ssa/cunroll-13.c: Rewrite to gimple testcase. * gcc.dg/tree-ssa/ivopt_mult_1.c: XFAIL. * gcc.dg/tree-ssa/ivopt_mult_1g.c: Add gimple variant that still passes. * gcc.dg/tree-ssa/ivopt_mult_2.c: XFAIL. * gcc.dg/tree-ssa/ivopt_mult_2g.c: Add gimple variant that still passes. * gcc.dg/tree-ssa/ssa-dom-thread-7.c: Adjust. * gcc.dg/tree-ssa/20030710-1.c: Likewise. * gcc.dg/tree-ssa/20030711-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-5.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_1g.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_2g.c trunk/gcc/testsuite/gcc.dg/tree-ssa/predcom-8.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/20030710-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/20030711-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/cunroll-13.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c trunk/gcc/tree-ssa-loop-ch.c
[Bug tree-optimization/85275] copyheader peels off almost the entire iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85275 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.0 Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.0 Resolution|--- |FIXED --- Comment #34 from Richard Biener --- Fixed.
[Bug sanitizer/85556] attribute no_sanitize does not accept multiple options as documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85556 Richard Biener changed: What|Removed |Added Keywords||documentation, ||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-30 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug c++/85557] Incorrect calculation of function arguments with C++17 sequencing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85557 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-04-30 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- If they are indeterminately sequenced then 2 is a valid result, no? 4 would be only required if evaluation order is right-to-left.
[Bug c++/85558] ICE in make_rtl_for_nonlocal_decl when using static member of template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85558 Richard Biener changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-30 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. clang complains: t.C:4:17: error: friend declaration specifying a default argument must be a definition friend void doInitUser(bool = triggerBug::doInit); ^
[Bug middle-end/85560] Missed optimization in niter analysis for bit-by-bit variable zeroing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85560 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-30 Component|rtl-optimization|middle-end Summary|Missed optimization in |Missed optimization in |bit-by-bit variable zeroing |niter analysis for ||bit-by-bit variable zeroing Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. GCC fails to prove the loop is finite. This is a niter / SCEV analysis issue. It's a bit convoluted case so I'm not sure how we can handle this easily. GIMPLE: [local count: 955630224]: # a_10 = PHI # bits_11 = PHI <1(2), bits_7(3)> _1 = ~bits_11; a_6 = _1 & a_10; bits_7 = bits_11 << 1; if (a_6 == 0) goto ; [11.00%] else goto ; [89.00%] we do have the force-simulation code which in theory could also be used to compute an upper bound rather than an exact niter count. But then for this case it needs to maintain fuzzy lattices (for bits).
[Bug middle-end/85563] [8/9 regression] -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Component|c |middle-end Target Milestone|--- |8.2 Summary|[8 regression] |[8/9 regression] |-Wmaybe-uninitialized false |-Wmaybe-uninitialized false |alarm regression with |alarm regression with |__builtin_unreachable and |__builtin_unreachable and |GCC 8 |GCC 8
[Bug middle-end/85567] [7/8/9 Regression] internal compiler error: in gimplify_modify_expr, at gimplify.c:5797 when using sincos()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85567 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-30 Known to work||6.4.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |7.4 Summary|internal compiler error: in |[7/8/9 Regression] internal |gimplify_modify_expr, at|compiler error: in |gimplify.c:5797 when using |gimplify_modify_expr, at |sincos()|gimplify.c:5797 when using ||sincos() Ever confirmed|0 |1 Known to fail||7.1.0, 8.0.1 --- Comment #1 from Richard Biener --- Confirmed. Happens during inlining when folding # .MEM = VDEF <.MEM> sincos (x_2(D), sinx_3(D), cosx_4(D)); which runs through the GENERIC call folder which replaces sincos with cexpi: *sinx_3(D) = IMAGPART_EXPR >;, *cosx_4(D) = REALPART_EXPR >; Mine.
[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-30 Component|lto |bootstrap Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Summary|ltobootstrap miscompare |[9 Regression] |with trunk and x86-64 |non-bootstrap-debug ||miscompare with trunk Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. Happens as soon as we compare debug info thus any build-config besides bootstrap-debug is affected. Caused by 2018-04-26 Richard Biener * Makefile.tpl (STAGE1_TFLAGS): Add -fno-checking. (STAGE2_CFLAGS): Likewise. (STAGE2_TFLAGS): Likewise. (STAGE3_CFLAGS): Add -fchecking. (STAGE3_TFLAGS): Likewise. (STAGEtrain_CFLAGS): Filter out -fchecking. (STAGEtrain_TFLAGS): Likewise. * Makefile.in: Re-generate. I'm testing a (first step) fix.
[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571 --- Comment #2 from Richard Biener --- Author: rguenth Date: Mon Apr 30 08:18:03 2018 New Revision: 259755 URL: https://gcc.gnu.org/viewcvs?rev=259755&root=gcc&view=rev Log: 2018-04-30 Richard Biener PR bootstrap/85571 * Makefile.tpl (STAGE3_CFLAGS): Use -fchecking=1. (STAGE3_TFLAGS): Likewise. (STAGEtrain_CFLAGS): Filter out -fchecking=1. (STAGEtrain_TFLAGS): Likewise. * Makefile.in: Regenerate. * dwarf2out.c (gen_producer_string): Ignore -fchecking[=]. Modified: trunk/ChangeLog trunk/Makefile.in trunk/Makefile.tpl trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug rtl-optimization/85180] Infinite loop in RTL DSE optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180 --- Comment #16 from romain.naour at smile dot fr --- Hi, gcc 7.3.0 is affected by this bug but only on microblaze architecture, see [1]. Do you plan to backport this patch on gcc 7.x? It is safe to do so without take the risk to break something with other architecture or optimization level? Best regards, Romain [1] http://lists.busybox.net/pipermail/buildroot/2018-April/220156.html
[Bug go/85429] Several gotools tests FAIL with Solaris as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85429 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #7 from Ian Lance Taylor --- > Do you think you could work out a patch that handles the various different > cases? Sure, if I can figure out how to determine whether or not gas is in use.
[Bug c++/85557] Incorrect calculation of function arguments with C++17 sequencing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85557 --- Comment #2 from Evgeniy Shcherbina --- There is 2 parameter calculations: "first" and "second", no matter what is evaluated first or second, the "first" parameter should be initialized with `i = 1`, and "second" with `i = 2`. So "first" should always be equal to 1 and "second" to 2. Currently it works as if the value assignment to parameters is done after the both arguments are calculated which to my knowledge is wrong. Argument calculation and parameter assignment is an atomic step as far as other parameters are concerned.
[Bug rtl-optimization/85180] Infinite loop in RTL DSE optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180 --- Comment #17 from Richard Biener --- (In reply to romain.naour from comment #16) > Hi, > > gcc 7.3.0 is affected by this bug but only on microblaze architecture, see > [1]. > Do you plan to backport this patch on gcc 7.x? > It is safe to do so without take the risk to break something with other > architecture or optimization level? > > Best regards, > Romain > > [1] http://lists.busybox.net/pipermail/buildroot/2018-April/220156.html The bug isn't a regression so technically it doesn't qualify. OTOH it looks reasonably safe to backport and the bug is annoying. Jakub, would you be ok with a backport?
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #42 from Andrew Haley --- On 04/29/2018 05:42 PM, rguenther at suse dot de wrote:> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 > > --- Comment #41 from rguenther at suse dot de --- > On April 29, 2018 1:51:58 PM GMT+02:00, "aph at gcc dot gnu.org" > wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 >> >> --- Comment #40 from Andrew Haley --- >> (In reply to rguent...@suse.de from comment #29) >> >>> Note I repeatedly said this part of the standard is just stupid. It >> makes >>> most if not all type-based alias analysis useless. >> >> I don't think so. It does mean that we'd have to feed all declared >> union types (or, at least the ones containing structs with common >> initial sequences) into the alias oracle. While unpleasant, in that >> simply declaring a type without even declaring an object of that type >> changes code generation, it doesn't render all type-based alias >> analysis useless. > > How do you handle this within the LTO framework? In order to use type-based alias analysis in any LTO framework it's necessary to save type information, and this is just more type information. The question is, I suppose, how to handle the scopes of union declarations. I'd just treat them as being global, which in practice isn't unrealistic because such declarations are in header files in global scope and shared anyway. So, if any union types with a common initial sequence are declared anywhere in a program, then their member types alias. Alternatively, a tighter implementation might restrict such declarations to a compilation unit, in which case the alias oracle would scan only the union types declared in that unit. >>> Which means I'll refuse any patches implementing it in a way that >>> affects default behavior. >> >> Maybe --pedantic or even --pedantic-aliasing? > > Whatever you call it I doubt any working solution will fit nicely > into our existing TBAA framework. Well, perhaps not, but this is the language specification. > When I read the language text then a union declaration in between > two accesses will change the semantic of the second? Not necessarily. It would be correct to collect all union declarations at the end of parsing and then use those to feed the alias oracle. There's no actual need to restrict their scope. Sure, it would lead to GCC being somewhat over-cautious, but that's OK.
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #43 from Richard Biener ---
(In reply to Andrew Haley from comment #42)
> On 04/29/2018 05:42 PM, rguenther at suse dot de wrote:>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
> >
> > --- Comment #41 from rguenther at suse dot de ---
> > On April 29, 2018 1:51:58 PM GMT+02:00, "aph at gcc dot gnu.org"
> > wrote:
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
> >>
> >> --- Comment #40 from Andrew Haley ---
> >> (In reply to rguent...@suse.de from comment #29)
> >>
> >>> Note I repeatedly said this part of the standard is just stupid. It
> >> makes
> >>> most if not all type-based alias analysis useless.
> >>
> >> I don't think so. It does mean that we'd have to feed all declared
> >> union types (or, at least the ones containing structs with common
> >> initial sequences) into the alias oracle. While unpleasant, in that
> >> simply declaring a type without even declaring an object of that type
> >> changes code generation, it doesn't render all type-based alias
> >> analysis useless.
> >
> > How do you handle this within the LTO framework?
>
> In order to use type-based alias analysis in any LTO framework it's
> necessary to save type information, and this is just more type
> information. The question is, I suppose, how to handle the scopes of
> union declarations. I'd just treat them as being global, which in
> practice isn't unrealistic because such declarations are in header
> files in global scope and shared anyway.
>
> So, if any union types with a common initial sequence are declared
> anywhere in a program, then their member types alias. Alternatively,
> a tighter implementation might restrict such declarations to a
> compilation unit, in which case the alias oracle would scan only the
> union types declared in that unit.
So for the middle-end the easiest thing would be if the FE would comply
to its existing semantics and for the initial sequences generate a
transparent struct. Thus,
union {
struct A { int i; float f; double z; } a;
struct B { int i; float f; void *p; } b;
};
would cause the FE to "implement" struct A and B like
struct __init_seq1 { int i; float f; };
struct A { struct __init_seq1 _transp_memb1; double z; } a;
struct B { struct __init_seq1 _transp_memb2; void *p; } b;
then everything would work as expected from an aliasing point of view.
The difficulty is probably that argument passing of A and B might
change depending on how the ABIs are defined and how the backend handles
those wrapping structs.
But as you can clearly see the above would be also a way for the user
to get what the clause permits without the clause being present. So
I'm not sure why this clause was added.
> >>> Which means I'll refuse any patches implementing it in a way that
> >>> affects default behavior.
> >>
> >> Maybe --pedantic or even --pedantic-aliasing?
> >
> > Whatever you call it I doubt any working solution will fit nicely
> > into our existing TBAA framework.
>
> Well, perhaps not, but this is the language specification.
language specifications have defects ...
> > When I read the language text then a union declaration in between
> > two accesses will change the semantic of the second?
>
> Not necessarily. It would be correct to collect all union
> declarations at the end of parsing and then use those to feed the
> alias oracle. There's no actual need to restrict their scope. Sure,
> it would lead to GCC being somewhat over-cautious, but that's OK.
given the TBAA oracle is filled on-demand it is important that both
outcomes are allowed. I still don't see how we can make it work easily
in the middle-end.
For anyone wanting to make GCC comply I suggest the above sketched route
and start with looking how backends deal with this kind of wrapping in
their argument passing.
[Bug target/85572] New: faster code for absolute value of __v2di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85572
Bug ID: 85572
Summary: faster code for absolute value of __v2di
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
The absolute value for 64-bit integer SSE vectors is only optimized when
AVX512VL is available. Test case (`-O2 -ffast-math` and one of -mavx512vl,
-msse4, or -msse2):
#include
__v2di abs(__v2di x) {
return x < 0 ? -x : x;
}
With SSE4 I suggest:
abs(long long __vector(2)):
pxor %xmm1, %xmm1
pcmpgtq %xmm0, %xmm1
pxor %xmm1, %xmm0
psubq %xmm1, %xmm0
ret
in C++:
auto neg = reinterpret_cast<__v2di>(x < 0);
return (x ^ neg) - neg;
Without SSE4:
abs(long long __vector(2)):
movdqa %xmm0, %xmm2
pxor %xmm1, %xmm1
psrlq $63, %xmm2
psubq %xmm2, %xmm1
pxor %xmm1, %xmm0
paddq %xmm2, %xmm0
ret
in C++:
auto neg = -reinterpret_cast<__v2di>(reinterpret_cast<__v2du>(x) >> 63);
return (x ^ neg) - neg;
related issue for scalars: #67510
[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571 --- Comment #3 from Richard Biener --- Not yet fixed. As we compare LTO bytecode but that includes the .opts section we now have -f[no-]checking there... We can't remove it there since we of course want to have different settings at link-time. A custom do-compare script like bootstrap-debug.mk provides might be a workaround for this particular issue. Maybe time to finally not compare LTO bytecode (but then we need to compare binaries which we don't do - but we could now that we share the checksums). OTOH stage2 and stage3 cc1 even differ in the size of the .text section... So we have "real" bugs to fix here as well it seems ;)
[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571 --- Comment #4 from Richard Biener --- contrib/compare-debug strips off LTO sections but that would leave us with a no-op compare. On any target using non-native sections just stripping .gnu.lto_.opts will be difficult in such script, so we'd need to build a compare-lto tool and use that. But as said, comparing LTO bytecode is of questionable value and comparing the binaries doesn't work...
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #44 from Davin McCall --- > Well, perhaps not, but this is the language specification. The "one special guarantee" clause appears in the section describing union member access via the "." or "->" operators, implying that it only applies to the access of union members via the union. As has been pointed out by others, the guarantee is surely not meant to trump all other rules regarding access, so this is a reasonable interpretation (since otherwise, it is totally unclear when it does apply and what exactly "it is permitted" even means). Note that without that clause, type punning structs via a union would essentially be impossible (since layout is implementation defined or unspecified). The "common initial sequence" requirement is the only part of the standard which requires that structs with similar members have them layed out in the same order and alignment. Since this only matters for type punning, it again makes sense that this would be specified in the one section which actually allows for type punning (even if only in a non-normative footnote) - that is, union member access via a union. It's clear why it is needed for this, but to extend that to any access of union members (including not via the union) seems like a stretch. If that was intended, why isn't it specified in 6.5? The only thing that suggests an alternative interpretation to what I've described above is the requirement that the declaration of the completed type of the union be visible, which is redundant if the access must be via the union type. However, interpreting this to mean that the "special guarantee" applies globally is far more problematic than assuming that the requirement is just redundant.
[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571 --- Comment #5 from Richard Biener --- The following should work: Index: config/bootstrap-lto.mk === --- config/bootstrap-lto.mk (revision 259755) +++ config/bootstrap-lto.mk (working copy) @@ -1,5 +1,7 @@ # This option enables LTO for stage2 and stage3 in slim mode +do-compare = /bin/true + STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 STAGEprofile_CFLAGS += -flto=jobserver -frandom-seed=1
[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571 --- Comment #6 from Richard Biener --- Or more sophisticated allow to override/amend what we compare in the .mk snippets and compare $(exeext) instead of ($objext) for bootstrap-lto.
[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571 --- Comment #7 from Richard Biener --- Created attachment 44041 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44041&action=edit patch Like this. Will fail as well because cc1 will differ (does not differ without LTO).
[Bug target/85572] faster code for absolute value of __v2di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85572 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-30 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Hmm, looks like C doesn't like the conditional. Eh. Confirmed with C++ where we expand to piecewise operation. The target needs to provide abs patterns if that shouldn't happen.
[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571 --- Comment #8 from Richard Biener --- So even w/o the -f[no-]checking flags I see then when comparing stage2 and stage3 cc1: > readelf -S /abuild/rguenther/obj/prev-gcc/cc1 | grep -C 1 .text 0008 0008 AX 0 0 8 [14] .text PROGBITS 0057be60 0017be60 00feb92a AX 0 0 16 > readelf -S /abuild/rguenther/obj/gcc/cc1 | grep -C 1 .text 0008 0008 AX 0 0 8 [14] .text PROGBITS 0057be60 0017be60 00feb5ba AX 0 0 16 assembly shows (after stripping reloc offset differences - bah, objdump should have a way to substitute zero for all of those): @@ -11420,24 +11420,6 @@ xx: xx xx xxmov%rxx,%rdi xx: xx xx xx xx xx mov$0xb,%esi xx: xx xx xx xx xx xxllq xx <_Zxxtrxx_contains_struct_chxxk_xxilxx PK9trxx_noxxtrxx_noxx_structure_enumPKciS4_> - xx: xx xx xxmov%r8,%rdi - xx: xx xx xx xx xx xxllq xx <_ZLxxi_tag_bindingP9trxx_noxx.part.xx > - xx: xx xx xxmov%rxx,%rdi - xx: xx xx xx xx xx xxllq xx <_ZLxxi_symbol_bindingP9trxx_noxx.part .xx> - xx: xx xx xxmov%r8,%rdi - xx: xx xx xx xx xx xxllq xx <_ZLxxi_tag_bindingP9trxx_noxx.part.xx > - xx: xx xx xxmov%rxx,%rdi - xx: xx xx xx xx xx xxllq xx <_ZLxxi_symbol_bindingP9trxx_noxx.part .xx> - xx: xx xx xx xx xx mov$0xxx,%xxx - xx: xx xx xx xx xx mov$0xxx,%esi - xx: xx xx xx xx xx mov$0xxx,%xxi - xx: xx xx xx xx xx xxllq xx <_Zxxncy_xxortPKciS0_> - xx: xx xx xx xx xx xx mov$0xxx,%rxx - xx: xx xx xx xx xx mov$0xxx,%xxx - xx: xx xx xx xx xx mov$0xxx,%xxx - xx: xx xx xxmov%rxx,%rdi - xx: xx xx xx xx xx mov$0x1,%esi - xx: xx xx xx xx xx xxllq xx <_Zxxtrxx_contains_struct_chxxk_xxilxxPK9trxx_noxxtrxx_noxx_structure_enumPKciS4_> xx: xx xx xx xx xx xx mov$0xxx,%rxx xx: xx xx xx xx xx mov$0xxx,%xxx xx: xx xx xx xx xx mov$0xxx,%xxx @@ -11480,6 +11462,20 @@ xx: xx xx xx xx xx mov$0xxx,%esi xx: xx xx xxmov%rxx,%rdi xx: xx xx xx xx xx xxllq xx <_Zxxtrxx_chxxk_xxilxxPK9trxx_noxxPKciS3_z> + xx: xx xx xxmov%r8,%rdi + xx: xx xx xx xx xx xxllq xx <_ZLxxi_tag_bindingP9trxx_noxx.part.xx> + xx: xx xx xxmov%rxx,%rdi + xx: xx xx xx xx xx xxllq xx <_ZLxxi_symbol_bindingP9trxx_noxx.part.xx> + xx: xx xx xx xx xx mov$0xxx,%xxx + xx: xx xx xx xx xx mov$0xxx,%esi + xx: xx xx xx xx xx mov$0xxx,%xxi + xx: xx xx xx xx xx xxllq xx <_Zxxncy_xxortPKciS0_> + xx: xx xx xx xx xx xx mov$0xxx,%rxx + xx: xx xx xx xx xx mov$0xxx,%xxx + xx: xx xx xx xx xx mov$0xxx,%xxx + xx: xx xx xxmov%rxx,%rdi + xx: xx xx xx xx xx mov$0x1,%esi + xx: xx xx xx xx xx xxllq xx <_Zxxtrxx_contains_struct_chxxk_xxilxxPK9trxx_noxxtrxx_noxx_structure_enumPKciS4_> xx: xx xx xx xx xx xx mov$0xxx,%rxx xx: xx xx xx xx xx mov$0xxx,%xxx xx: xx xx xx xx xx mov$0xxx,%xxx ... xx <_ZLxx_parser_postfix_expressionPxx_parser.cold.xx>: - xx: xx xx xx xx xx xxllq xx <_ZN3vxxIxxva_hxxp6vl_ptrExxquick_pushERKb.isra.xx.part.xx> + xx: xx xx xx xx xx xxllq xx <_ZN3vxxIxxva_hxxp6vl_ptrEixEj.isra.xx.part.xx> xx: xx xx xx xx xx xx mov$0xxx,%rxx so different BB re-ordering / partitioning? For example in the case of gengtype from stage2/stage3 .text has the same size but .debug_info size differs by one byte. But gentype code differs as well: @@ -2884,6 +2884,7 @@ xx: xx xx xx xx xx xxllq xx <_ZLxxpxxk_state_tokeni> xx: xx xx xx xx xx mov$0x1,%xxi xx: xx xx xxmov%rax,%rxx + xx: xx xx xx xx mov%rax,(%rsp) xx: xx xx xx xx xx xxllq xx <_ZLxxpxxk_state_tokeni> xx: xx xx xx xx xx mov$0x2,%xxi xx: xx xx xxmov%rax,%rbp ...
[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571 --- Comment #9 from Jan Hubicka --- > > so different BB re-ordering / partitioning? That would be probably best visible from bb-reorder dumps. However... > > For example in the case of gengtype from stage2/stage3 .text has the same size > but .debug_info size differs by one byte. But gentype code differs as well: > > @@ -2884,6 +2884,7 @@ >xx: xx xx xx xx xx xxllq xx <_ZLxxpxxk_state_tokeni> >xx: xx xx xx xx xx mov$0x1,%xxi >xx: xx xx xxmov%rax,%rxx > + xx: xx xx xx xx mov%rax,(%rsp) This is something else and such changes may make partitioning to diverge. So perhaps first debug this one? >xx: xx xx xx xx xx xxllq xx <_ZLxxpxxk_state_tokeni> >xx: xx xx xx xx xx mov$0x2,%xxi >xx: xx xx xxmov%rax,%rbp > ... > > -- > You are receiving this mail because: > You reported the bug.
[Bug c++/85573] New: gcc 7.3.0 cannot compile recent LLVM for AMD GPU shaders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85573 Bug ID: 85573 Summary: gcc 7.3.0 cannot compile recent LLVM for AMD GPU shaders Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sylvain.bertrand at gmail dot com Target Milestone: --- I tried to compile a recent LLVM for AMD GPU shaders, but was unable due to the compilation error reported here: https://bugs.llvm.org/show_bug.cgi?id=37287 It seems the c++ used in recent LLVM hits something unimplemented in g++.
[Bug c++/85573] gcc 7.3.0 cannot compile recent LLVM for AMD GPU shaders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85573 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-04-30 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- As requested when creating this bug, please read https://gcc.gnu.org/bugs and provide the necessary information (at the very least the output of gcc -v and preprocessed source).
[Bug bootstrap/85571] [9 Regression] non-bootstrap-debug miscompare with trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571
--- Comment #10 from Richard Biener ---
On the gcc-8 branch cc1 and friends compare OK so this is a recent regression.
Will try with checking enabled to be extra sure. Then there are only few
changes on trunk that are suspicious.
+/* Compare types based on source file location. */
+
+static int
+cmp_type_location (const void *p1_, const void *p2_)
+{
+ tree *p1 = (tree*)(const_cast(p1_));
+ tree *p2 = (tree*)(const_cast(p2_));
+ if (*p1 == *p2)
+return 0;
+
+ tree tname1 = TYPE_NAME (*p1);
+ tree tname2 = TYPE_NAME (*p2);
+
+ const char *f1 = DECL_SOURCE_FILE (tname1);
+ const char *f2 = DECL_SOURCE_FILE (tname2);
+
+ int r = strcmp (f1, f2);
+ if (r == 0)
this should probably split paths.
+ /* Register ODR types. */
+ for (unsigned i = 0; i < odr_types.length (); i++)
+register_odr_type (odr_types[i]);
I suspect the order may have effects on code-generation.
[Bug c++/85573] gcc 7.3.0 cannot compile recent LLVM for AMD GPU shaders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85573 Manuel Lauss changed: What|Removed |Added CC||manuel.lauss at googlemail dot com --- Comment #2 from Manuel Lauss --- Works with gcc-7.3.1 for me, latest llvm git snapshot.
[Bug c++/85573] gcc 7.3.0 cannot compile recent LLVM for AMD GPU shaders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85573 --- Comment #3 from Sylvain Bertrand --- On Mon, Apr 30, 2018 at 12:43:04PM +, manuel.lauss at googlemail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85573 > > Manuel Lauss changed: > >What|Removed |Added > > CC||manuel.lauss at googlemail > dot com > > --- Comment #2 from Manuel Lauss --- > Works with gcc-7.3.1 for me, latest llvm git snapshot. Then I guess I'll wait for the release of 7.3.1 or 8.1 then (will arrive soon I guess). If it works, I'll notify the llvm "guys" to update their compilation requirements to gcc 7.3.1 and gcc 8.1 (it was gcc 4.8.0). I got many miscompilations resulting in segfaults in recent git gcc, that's why I prefer to wait for an official release.
[Bug c++/85573] gcc 7.3.0 cannot compile recent LLVM for AMD GPU shaders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85573 --- Comment #4 from Jonathan Wakely --- 7.3.1 will never be released, it's a post-7.3.0 and pre-7.4.0 development snapshot. If you are getting segfaults from snapshots now and you don't report them then the final release is likely to have the same segfaults.
[Bug lto/85574] New: [9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 Bug ID: 85574 Summary: [9 Regression] LTO bootstapped binaries differ Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: needs-bisection Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- See PR85571 (which is about LTO IL differences). Binaries like cc1 and build/gengtype differ between stage2 and stage3. This is a regression from GCC8 where they compare just fine (double-checked with and without checking for c,c++ bootstrap-lto). I tried the attached but it doesn't help so I suspect the partitioning changes instead (unstable sorts?).
[Bug lto/85574] [9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/85557] Incorrect calculation of function arguments with C++17 sequencing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85557 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Status|WAITING |NEW --- Comment #3 from Jonathan Wakely --- "The initialization of a parameter, including every associated value computation and side effect, is indeterminately sequenced with respect to that of any other parameter." That's indeterminately sequenced, not unsequenced: "Evaluations A and B are indeterminately sequenced when either A is sequenced before B or B is sequenced before A, but it is unspecified which. [ Note: Indeterminately sequenced evaluations cannot overlap, but either could be executed first. — end note ]" So the function is called as foo(1, 2), but it's unspecified whether i==1 or i==2 afterwards.
[Bug c++/77840] List-initialization and copy-constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77840 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely --- Closing as invalid based on my comments above.
[Bug c++/63707] Brace initialization of array sometimes fails if no copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63707 Jonathan Wakely changed: What|Removed |Added CC||mosra at centrum dot cz --- Comment #9 from Jonathan Wakely --- *** Bug 70395 has been marked as a duplicate of this bug. ***
[Bug c++/70395] [C++11] Error when initializing array of non-copyable non-trivial type in constructor initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70395 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > Probably a dup of PR 63707 I'll add this testcase there. *** This bug has been marked as a duplicate of bug 63707 ***
[Bug c++/63707] Brace initialization of array sometimes fails if no copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63707
--- Comment #10 from Jonathan Wakely ---
Testcase from PR 70395
struct NonCopyable {
NonCopyable(const NonCopyable&) = delete;
NonCopyable(NonCopyable&&) = delete;
NonCopyable& operator=(const NonCopyable&) = delete;
NonCopyable& operator=(NonCopyable&&) = delete;
NonCopyable() {}
~NonCopyable() {} // to make it non-trivial
};
struct A {
A(): _a{} {}
~A() {}
NonCopyable _a[5];
} a;
[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835 --- Comment #17 from Jonathan Wakely --- Jason, should this be FIXED instead of SUSPENDED?
[Bug fortran/85575] New: Acceptance of invalid code: ordering of declaration statements with implicit typing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575 Bug ID: 85575 Summary: Acceptance of invalid code: ordering of declaration statements with implicit typing Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- I think I saw discussions on this topic already on c.l.f. I am having the following subroutine (and the recursive attribute doesn't play a role) 1 recursive function constr_quark_loopline(ho,sho) result(cl) 2 integer, dimension(sho), intent(in) :: ho 3 integer, dimension(sho) :: hor 4 integer, intent(in) :: sho 5 [...] 6 end function constr_quark_loopline Intel gives an error message error #6415: This name cannot be assigned this data type because it conflicts with prior uses of the name. [SHO] in the case this is an external procedure, or a module procedure with or without 'implicit none' in the head of the module. First of all, I would like to get it confirmed that this is really a contradiction of the standard, and that the order of the declarations matters. In case this is a module procedure without implicit none or an external procedure, implicit typing rules apply and sho would be considered to be a real, such that later specifying it as an integer is a contradiction. gfortran and nagfor complain: integer, intent(in) :: sho 1 Error: Symbol ‘sho’ at (1) already has basic type of REAL and Error: rec.f90, line 8: Symbol SHO has already been implicitly typed detected at SHO@ The strange thing (which seems a compiler bug to me) is that gfortran compiles this code when it is a module procedure with 'implicit none'. This seems a (gfortran) compiler bug to me to accept this code. I see this behavior with all gfortran versions that I can get a hold on, 4.8, 4.9., 5.4, 6.3, 7.3, 8.0 and 9.0. That is the reason I filed this report. Comments are appreciated. And yes, of course, I know that having the declaration of sho first solves all the problems, but this is 3rd-party code.
[Bug c++/85576] New: A template union containing a friend function causes non-template type used as a template error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85576
Bug ID: 85576
Summary: A template union containing a friend function causes
non-template type used as a template error
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: malcolm.parsons at gmail dot com
Target Milestone: ---
For this code:
template
union Union {
friend bool operator==(const Union& a, const Union& b) {
return true;
}
T t;
};
Union i;
GCC reports an error:
:9:10: error: non-template type 'Union' used as a template
Union i;
^
Clang and MSVC both accept this code: https://godbolt.org/g/S9p7hw
[Bug c++/85576] A template union containing a friend function causes non-template type used as a template error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85576 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-30 Ever confirmed|0 |1
[Bug c++/85577] New: list-initialization chooses initializer-list constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85577
Bug ID: 85577
Summary: list-initialization chooses initializer-list
constructor
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
namespace std
{
typedef long unsigned int size_t;
template
class initializer_list
{
public:
typedef _E value_type;
typedef const _E& reference;
typedef const _E& const_reference;
typedef size_t size_type;
typedef const _E* iterator;
typedef const _E* const_iterator;
private:
iterator _M_array;
size_type _M_len;
constexpr initializer_list(const_iterator __a, size_type __l)
: _M_array(__a), _M_len(__l) { }
public:
constexpr initializer_list() : _M_array(0), _M_len(0) { }
constexpr size_type
size() { return _M_len; }
constexpr const_iterator
begin() { return _M_array; }
constexpr const_iterator
end() { return begin() + size(); }
};
template T&& move(T& t) { return static_cast(t); }
template
struct vector {
vector(vector&&) noexcept { }
vector(initializer_list) = delete;
};
}
struct A {
A(A const&) = delete;
A& operator=(A const&) = delete;
A(A&&) = default;
A& operator=(A&&) = default;
A(std::vector&& v) : v{std::move(v)} { }
std::vector v;
};
v.ii: In constructor ‘A::A(std::vector&&)’:
v.ii:54:41: error: use of deleted function
‘std::vector::vector(std::initializer_list) [with T = A]’
A(std::vector&& v) : v{std::move(v)} { }
^
v.ii:45:5: note: declared here
vector(initializer_list) = delete;
^~
The move constructor should be used, not the initialize-list one.
[Bug c++/85577] list-initialization chooses initializer-list constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85577 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-30 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Clang and EDG accept it.
[Bug lto/85574] [9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Jan Hubicka --- Attachement seems to be missing. How do I reproduce it? The partitioning changes are not really affecting any sorting. The changes will be null with -flto-partitioning=
[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829 --- Comment #14 from joseph at codesourcery dot com --- As I said in comment#10, I think the solution is to remove the specs making -mieee-fp imply -lieee. (Principally the spec in gnu-user.h. I don't think this should depend on what libc is in use. No doubt the similar spec in m32r/linux.h should be changed similarly, though I'm not aware of a glibc port to m32r, don't know what libc was used with that port, and the Linux kernel port to m32r has now been removed along with several others for 4.17.)
[Bug c/81405] [8 Regression] Buffer overflow when consolidating printing of out-of-order fix-it hints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81405 --- Comment #5 from David Malcolm --- Author: dmalcolm Date: Mon Apr 30 15:01:56 2018 New Revision: 259768 URL: https://gcc.gnu.org/viewcvs?rev=259768&root=gcc&view=rev Log: Use char_span for return type of location_get_source_line location_get_source_line returns a const char * that isn't 0-terminated, writing back a length through an int * param. This is error-prone, as all call-sites have to take into account the lack of 0-termination, and respect the length of the buffer. It's cleaner to bundle together this pointer+length state into a class, so this patch does so, reusing the "char_span" class that I introduced in r250187 (as part of the fix for PR c/81405). The patch also adds assertions to all access to the char_span. gcc/c-family/ChangeLog: * c-format.c (get_corrected_substring): Update for location_get_source_line returning a char_span. Use a char_span when handling the prefix of the correction. * c-indentation.c (get_visual_column): Update for location_get_source_line returning a char_span. (get_first_nws_vis_column): Likewise. gcc/ChangeLog: * diagnostic-show-locus.c (layout::layout): Update for location_get_source_line returning a char_span. (struct char_span): Move to input.h. (struct correction): Update for fields in char_span becoming private. (struct source_line): Update for location_get_source_line returning a char_span. (layout::print_line): Likewise. * edit-context.c (edited_file::print_content): Likewise. (edited_file::print_diff_hunk): Likewise. (edited_file::print_run_of_changed_lines): Likewise. (edited_file::get_num_lines): Likewise. (edited_line::edited_line): Likewise. * final.c (asm_show_source): Likewise. * input.c (location_get_source_line): Convert return type from const char * to char_span, losing the final "line_len" param. (dump_location_info): Update for the above. (get_substring_ranges_for_loc): Likewise. Use a char_span when handling the literal within the line. (test_reading_source_line): Update for location_get_source_line returning a char_span. * input.h (class char_span): Move here from diagnostic-show-locus.c, converting from a struct to a class. Make data members private. (char_span::operator bool): New. (char_span::length): New. (char_span::get_buffer): New. (char_span::operator[]): New. (char_span::subspan): Make const. (char_span::xstrdup): New. (location_get_source_line): Convert return type from const char * to char_span, losing the final "line_size" param. gcc/testsuite/ChangeLog: * gcc.dg/plugin/diagnostic_plugin_test_show_locus.c (test_show_locus): Update for location_get_source_line returning a char_span. Use char_span for handling words in the "test_many_nested_locations" fix-it example. Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-format.c trunk/gcc/c-family/c-indentation.c trunk/gcc/diagnostic-show-locus.c trunk/gcc/edit-context.c trunk/gcc/final.c trunk/gcc/input.c trunk/gcc/input.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_show_locus.c
[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982 --- Comment #18 from Jason Merrill --- Author: jason Date: Mon Apr 30 15:21:01 2018 New Revision: 259772 URL: https://gcc.gnu.org/viewcvs?rev=259772&root=gcc&view=rev Log: PR c++/61982 - dead stores to destroyed objects. gcc/cp/ * call.c (build_trivial_dtor_call): New, assigns a clobber. (build_over_call, build_special_member_call): Use it. * cp-tree.h: Declare it. * init.c (build_delete): Remove trivial path. gcc/ * gimplify.c (gimplify_modify_expr): Simplify complex lvalue on LHS of clobber. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/lifetime-dse1.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/init.c trunk/gcc/gimplify.c
[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #19 from Jason Merrill --- Fixed for GCC 9.
[Bug c++/85573] gcc 7.3.0 cannot compile recent LLVM for AMD GPU shaders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85573 --- Comment #5 from Sylvain Bertrand --- On Mon, Apr 30, 2018 at 01:02:20PM +, redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85573 > > --- Comment #4 from Jonathan Wakely --- > 7.3.1 will never be released, it's a post-7.3.0 and pre-7.4.0 development > snapshot. > > If you are getting segfaults from snapshots now and you don't report them then > the final release is likely to have the same segfaults. Then 8.1 release which is supposed to be soon enough. No update on AMD shader compiler in the mean time.
[Bug c++/85557] Incorrect calculation of function arguments with C++17 sequencing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85557 --- Comment #4 from Evgeniy Shcherbina --- Jonathan, yes it *should* be called as foo(1, 2) but the result is as if it is called as foo(1, 1). --- Comment #5 from Evgeniy Shcherbina --- Jonathan, yes it *should* be called as foo(1, 2) but the result is as if it is called as foo(1, 1).
[Bug c++/85557] Incorrect calculation of function arguments with C++17 sequencing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85557 --- Comment #4 from Evgeniy Shcherbina --- Jonathan, yes it *should* be called as foo(1, 2) but the result is as if it is called as foo(1, 1). --- Comment #5 from Evgeniy Shcherbina --- Jonathan, yes it *should* be called as foo(1, 2) but the result is as if it is called as foo(1, 1).
[Bug c++/85557] Incorrect calculation of function arguments with C++17 sequencing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85557 --- Comment #6 from Jonathan Wakely --- Yes that's why I confirmed the bug by changing the status to NEW.
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #45 from Andrew Haley ---
(In reply to Davin McCall from comment #44)
> > Well, perhaps not, but this is the language specification.
>
> The "one special guarantee" clause appears in the section describing union
> member access via the "." or "->" operators, implying that it only applies
> to the access of union members via the union.
I don't believe that's what is intended, or that you can make such a
conclusion based on the section in which the rule appears. It applies
to other accesses too, as is (somewhat) made clear by the rationale in
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n685.htm:
The proposed solution is to require that a union declaration be visible
if aliases through a common initial sequence (like the above) are possible.
Therefore the following TU provides this kind of aliasing if desired:
union utag {
struct tag1 { int m1; double d2; } st1;
struct tag2 { int m1; char c2; } st2;
};
int similar_func(struct tag1 *pst2, struct tag2 *pst3) {
pst2->m1 = 2;
pst3->m1 = 0; /* might be an alias for pst2->m1 */
return pst2->m1;
}
I know this is non-normative and not even in the standard, but it does
explain what was intended.
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #46 from James Kuyper Jr. --- (In reply to Andrew Haley from comment #42) ... > In order to use type-based alias analysis in any LTO framework it's > necessary to save type information, and this is just more type > information. ... Speaking from a developer's perspective rather than an implementor's perspective, the implementation already needs to keep track of where the union's completed definition is in scope, because it's only in those locations where it would be permitted to define an object having the union's type. This is just a different use for the same information; it shouldn't require storing any additional information; nor should it require holding on to that information for any longer than is already required. As a matter of efficient implementation, rather than correctness, I think it might be useful to store, for each struct type, a list of the union definitions for which this might be an issue, a list that would not be needed for any other reason. However, most of the time, that list would be empty - only when it's not empty would the compiler need to review that list to determine which other struct types might be permitted to alias this type, to a limited extent. > ... The question is, I suppose, how to handle the scopes of > union declarations. I'd just treat them as being global, which in > practice isn't unrealistic because such declarations are in header > files in global scope and shared anyway. Why not use the actual scope of the completed union declaration, which is what the relevant rule refers to? > So, if any union types with a common initial sequence are declared > anywhere in a program, then their member types alias. As I understand it, the visibility rule was added specifically for the purpose of NOT requiring that the entire program be covered by this exception. Knowledgeable people writing code intended to take advantage of this feature of C are likely to carefully place completed declarations of the union's type so they disable those optimizations only where they need to be disabled, and to minimize the amount of code where this exception would unnecessarily disable useful optimizations.
[Bug fortran/85575] Acceptance of invalid code: ordering of declaration statements with implicit typing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575 --- Comment #1 from Jürgen Reuter --- Ok, after discussion on the Intel Forum I found out that this is based on Section 7.1.11p7 of the f2008 standard , Specification expression: A variable in a specication expression shall have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, or by host or use association. If a variable in a specification expression is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm the implied type and type parameters. But it is not clear whether the compiler actually has to detect this.
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #47 from Andrew Haley ---
(In reply to Richard Biener from comment #43)
> (In reply to Andrew Haley from comment #42)
> >
> > So, if any union types with a common initial sequence are declared
> > anywhere in a program, then their member types alias. Alternatively,
> > a tighter implementation might restrict such declarations to a
> > compilation unit, in which case the alias oracle would scan only the
> > union types declared in that unit.
>
> So for the middle-end the easiest thing would be if the FE would comply
> to its existing semantics and for the initial sequences generate a
> transparent struct. Thus,
>
> union {
> struct A { int i; float f; double z; } a;
> struct B { int i; float f; void *p; } b;
> };
>
> would cause the FE to "implement" struct A and B like
>
> struct __init_seq1 { int i; float f; };
> struct A { struct __init_seq1 _transp_memb1; double z; } a;
> struct B { struct __init_seq1 _transp_memb2; void *p; } b;
>
> then everything would work as expected from an aliasing point of view.
> The difficulty is probably that argument passing of A and B might
> change depending on how the ABIs are defined and how the backend handles
> those wrapping structs.
Nice. I've got to admit that's a clever, idea, but it's also a very
big gotcha.
> But as you can clearly see the above would be also a way for the user
> to get what the clause permits without the clause being present. So
> I'm not sure why this clause was added.
That's somewhat explained by N685, which does contain the rationale.
In short: proposal before N685 was to allow *every* pair of pointers
to structures with a common initial sequence to alias. The revised
version (which was accepted) restricts this to structures with a
common initial sequence where a union of these structures is visible
to the compiler.
> language specifications have defects ...
Yabbut, N685 was accepted and the proposal does explain why. Maybe it
shouldn't have been done that way, but it was done, and it was done
deliberately, as far as I can see.
> > > When I read the language text then a union declaration in between
> > > two accesses will change the semantic of the second?
> >
> > Not necessarily. It would be correct to collect all union
> > declarations at the end of parsing and then use those to feed the
> > alias oracle. There's no actual need to restrict their scope. Sure,
> > it would lead to GCC being somewhat over-cautious, but that's OK.
>
> given the TBAA oracle is filled on-demand it is important that both
> outcomes are allowed.
Okay, I don't get this. Why not simply say that if a union type with
the initial common sequence exists anywhere, it is as though it were
declared at the start of every TU.
> I still don't see how we can make it work easily in the middle-end.
I don't think I ever said it would be easy! I am saying, though, that
it's not the end of TBAA as we know it, but a refinement in which a
front end can feed into the alias oracle sets of types that are known
to alias.
You can think of it as a declaration:
__alias__ {
type_a, type_b, type_c
};
which is an additional input to the oracle.
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #48 from James Kuyper Jr. --- (In reply to Davin McCall from comment #44) > > Well, perhaps not, but this is the language specification. > > The "one special guarantee" clause appears in the section describing union > member access via the "." or "->" operators, implying that it only applies > to the access of union members via the union. ... I find nothing objectionable about that statement - it is indeed impossible to create code which relies upon the special guarantee in 6.5.2.3p6 without accessing the union members via the '.' or '->' operators. However, I believe that you mean something more restricted than what you're actually saying, because the code given in the original bug report does in fact access the union members via '.' operator, in the expressions &u.s1 and &u.s2, to create a situation where, as I understand it, that special guarantee is fully applicable. Could you expand on your description of what you think is required, to make it clear why it doesn't apply in this case?
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #49 from Andrew Haley --- (In reply to James Kuyper Jr. from comment #46) > (In reply to Andrew Haley from comment #42) > ... > > In order to use type-based alias analysis in any LTO framework it's > > necessary to save type information, and this is just more type > > information. ... > > > ... The question is, I suppose, how to handle the scopes of > > union declarations. I'd just treat them as being global, which in > > practice isn't unrealistic because such declarations are in header > > files in global scope and shared anyway. > > Why not use the actual scope of the completed union declaration, > which is what the relevant rule refers to? The principle of type-based alias analysis is that all you know about two types is their types, not the location of any code that uses them. There are no scopes. The oracle, given only the types, has to say whether they alias or not, regardless of where those types are used in a program. The location isn't an input to the oracle. Bear in mind that inlining and other kinds of code motion happen, and code is often evaluated "outside" the scopes in which it was written and in a completely different order. That's all perfectly normal optimization. Besides, when the alias oracle is consulted, all that scope stuff has gone. It's only relevant to the front end. > > So, if any union types with a common initial sequence are declared > > anywhere in a program, then their member types alias. > > As I understand it, the visibility rule was added specifically for > the purpose of NOT requiring that the entire program be covered by > this exception. I don't think so. As I read it, it was a way of declaring to the compiler that they types are intended to alias. > Knowledgeable people writing code intended to take advantage of this > feature of C are likely to carefully place completed declarations of > the union's type so they disable those optimizations only where they > need to be disabled, and to minimize the amount of code where this > exception would unnecessarily disable useful optimizations. Perhaps so, yes, but in practice it'd be pretty hard to do that. Functions can only be defined in the other scope, and there's no way to undefine a union type. I guess you could be clever and put all of the functions which needed to know about the aliasing at the end of a translation unit.
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #50 from Andrew Haley --- (In reply to Andrew Haley from comment #49) > > Perhaps so, yes, but in practice it'd be pretty hard to do that. > Functions can only be defined in the other scope, Should be "the outer scope" > and there's no way > to undefine a union type. I guess you could be clever and put all of > the functions which needed to know about the aliasing at the end of a > translation unit.
[Bug target/85572] faster code for absolute value of __v2di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85572 --- Comment #2 from Jakub Jelinek --- Created attachment 44042 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44042&action=edit gcc8-pr85572.patch Untested fix.
[Bug web/85578] New: broken links in gcc-8.0.1-RC-20180427/INSTALL/specific.html, and out of date prerequisites.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85578 Bug ID: 85578 Summary: broken links in gcc-8.0.1-RC-20180427/INSTALL/specific.html, and out of date prerequisites.html Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: andrewm.roberts at sky dot com Target Milestone: --- The file INSTALL/specific.html in gcc-8.0.1-RC-20180427 contains many broken links. All links that include target-x-x are broken, only the simple ones like avr are working. avr link is: file:///home/aroberts/gcc/gcc/gcc-8.0.1-RC-20180427/INSTALL/specific.html#avr which references: aarch64*-*-* link is: file:///home/aroberts/gcc/gcc/gcc-8.0.1-RC-20180427/INSTALL/specific.html#aarch64-x-x which fails to reference: This is obviously broken. And seems to apply to all the none trivial links. Also in prerequisites.html, are the versions for mpc, mpfr, gmp, isl etc ok, or are they out of date? I see that the download_prerequisites is referencing: gmp='gmp-6.1.0.tar.bz2' mpfr='mpfr-3.1.4.tar.bz2' mpc='mpc-1.0.3.tar.gz' isl='isl-0.18.tar.bz2'
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #51 from James Kuyper Jr. --- (In reply to Andrew Haley from comment #49) > (In reply to James Kuyper Jr. from comment #46) > > (In reply to Andrew Haley from comment #42) > > ... > > > In order to use type-based alias analysis in any LTO framework it's > > > necessary to save type information, and this is just more type > > > information. ... > > > > > ... The question is, I suppose, how to handle the scopes of > > > union declarations. I'd just treat them as being global, which in > > > practice isn't unrealistic because such declarations are in header > > > files in global scope and shared anyway. > > > > Why not use the actual scope of the completed union declaration, > > which is what the relevant rule refers to? > > The principle of type-based alias analysis is that all you know about > two types is their types, not the location of any code that uses them. > There are no scopes. The oracle, given only the types, has to say > whether they alias or not, regardless of where those types are used in > a program. The location isn't an input to the oracle. > > Bear in mind that inlining and other kinds of code motion happen, and > code is often evaluated "outside" the scopes in which it was written > and in a completely different order. That's all perfectly normal > optimization. > > Besides, when the alias oracle is consulted, all that scope stuff has > gone. It's only relevant to the front end. I was only pointing out that implementing this special guarantee where it applies, and only where it applies, requires keeping information that must already have been collected. If the current design discards that information before performing the relevant optimizations, I can understand that this would require a significant re-design - but the re-design takes the form of saving information already collected, not of collecting additional information. > > > So, if any union types with a common initial sequence are declared > > > anywhere in a program, then their member types alias. > > > > As I understand it, the visibility rule was added specifically for > > the purpose of NOT requiring that the entire program be covered by > > this exception. > > I don't think so. As I read it, it was a way of declaring to the > compiler that they types are intended to alias. By "the visibility rule", I mean, very specifically, the phrase "anywhere that a declaration of the completed type of the union is visible". If the intent had been to disable aliasing throughout the entire program, that intent could have been expressed by simply removing those words entirely; if there was any doubt that people would understand the absence of those words correctly, then they could have been replaced with the phrase "anywhere, regardless of whether or not the completed type of the union was visible". I don't see any plausible reason for the committee to write "anywhere that a declaration of the completed type of the union is visible", unless that phrase was intended to restrict applicability of the special guarantee. > > Knowledgeable people writing code intended to take advantage of this > > feature of C are likely to carefully place completed declarations of > > the union's type so they disable those optimizations only where they > > need to be disabled, and to minimize the amount of code where this > > exception would unnecessarily disable useful optimizations. > > Perhaps so, yes, but in practice it'd be pretty hard to do that. > Functions can only be defined in the other scope, and there's no way > to undefine a union type. True, but failing to define the union type is quite trivial. If I were writing code that used both struct types, but not the union type, and did nothing that relied upon the fact that they can alias each other, I would simply not #include the header that defines the completed union type, #including only the header that defines the struct types. If I needed to put such code in the same translation unit as code which actually needs the union declaration, I would put the code that doesn't need it before the #include, and put the code that does need it after the #include - but that would probably be more trouble than it's worth.
[Bug fortran/85575] Acceptance of invalid code: ordering of declaration statements with implicit typing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to Jürgen Reuter from comment #1) > Ok, after discussion on the Intel Forum I found out that this is based on > Section 7.1.11p7 of the f2008 standard , Specification expression: > > A variable in a specication expression shall have its type and type > parameters, if any, specified by a previous > declaration in the same scoping unit, by the implicit typing rules in > effect for the scoping unit, or by host or use > association. If a variable in a specification expression is typed by the > implicit typing rules, its appearance in any > subsequent type declaration statement shall confirm the implied type and > type parameters. > > But it is not clear whether the compiler actually has to detect this. If it is a numbered constraint, then the compiler must detect the problem. If it is unnumbered, then the above "shall"'s apply to the program(mer). A compiler can, but is not required to report a problem.
[Bug c++/85305] Parameter pack expression in lambda capture list fails as part of a fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85305 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug lto/85574] [9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 --- Comment #2 from rguenther at suse dot de --- On April 30, 2018 5:01:30 PM GMT+02:00, "hubicka at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 > >Jan Hubicka changed: > > What|Removed |Added > > CC||hubicka at gcc dot gnu.org > >--- Comment #1 from Jan Hubicka --- >Attachement seems to be missing. How do I reproduce it? You reproduce w/o attachment, just LTO bootstrap up to comparison stage and then cmp cc1 or gengtype. Works fine on the branch, miscompares on trunk. >The partitioning changes are not really affecting any sorting. The >changes >will be null with -flto-partitioning=
[Bug go/85429] Several gotools tests FAIL with Solaris as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85429 --- Comment #9 from Ian Lance Taylor --- I suppose if worst comes to worst we can try it both ways.
[Bug c++/85039] [6/7 Regression] internal compiler error: in nested_anon_class_index, at cp/mangle.c:1626
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85039 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|6.5 |8.0 --- Comment #7 from Jason Merrill --- Closing; we generally don't backport fixes for invalid code.
[Bug c++/58063] default arguments evaluated twice per call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.9.4, 5.2.0, 6.0 Resolution|--- |FIXED Target Milestone|--- |4.9.4 --- Comment #17 from Jason Merrill --- This was fixed a while back.
[Bug c++/84701] casting to ( unsigned typeof(variable) ) gives wrong results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84701 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug tree-optimization/85579] New: [9 regression] SIGSEV in fortran test case gfortran.dg/pr51434.f90 starting with r259754
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85579 Bug ID: 85579 Summary: [9 regression] SIGSEV in fortran test case gfortran.dg/pr51434.f90 starting with r259754 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- Sorry, I don't know enough about fortran to know whether there is something wrong with the test case. seurer@makalu-lp1:~/gcc/build/gcc-test2$ /home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../gfortran -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../ -B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/pr51434.f90 -fno-diagnostics-show-caret -fdiagnostics-color=never -O1 -pedantic-errors -B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs -B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs -lm -g3 -o ./pr51434.exe seurer@makalu-lp1:~/gcc/build/gcc-test2$ gdb ./pr51434.exe (gdb) run Starting program: /home/seurer/gcc/build/gcc-test2/./pr51434.exe Program received signal SIGSEGV, Segmentation fault. 0x1770 in bar () at /home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/pr51434.f90:18 18 if (any(c%t /= ['a', 'b', 'c', 'd', 'e'])) stop 2 Missing separate debuginfos, use: debuginfo-install glibc-2.17-196.el7_4.2.ppc64 zlib-1.2.7-17.el7.ppc64 (gdb) where #0 0x1770 in bar () at /home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/pr51434.f90:18 #1 main (argc=, argv=) at /home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/pr51434.f90:14 #2 0x3fffb7a36bec in .generic_start_main.isra.0 () from /lib64/libc.so.6 #3 0x3fffb7a36e14 in .__libc_start_main () from /lib64/libc.so.6 #4 0x in ?? ()
[Bug tree-optimization/85579] [9 regression] SIGSEV in fortran test case gfortran.dg/pr51434.f90 starting with r259754
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85579 seurer at gcc dot gnu.org changed: What|Removed |Added Target||powerpc64*-*-* CC||rguenth at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Host||powerpc64*-*-* Build||powerpc64*-*-* --- Comment #1 from seurer at gcc dot gnu.org --- This occurs on powerpc64 both LE and BE.
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #52 from Davin McCall --- (In reply to James Kuyper Jr. from comment #48) > > The "one special guarantee" clause appears in the section describing union > > member access via the "." or "->" operators, implying that it only applies > > to the access of union members via the union. ... > > I find nothing objectionable about that statement - it is indeed impossible > to create code which relies upon the special guarantee in 6.5.2.3p6 without > accessing the union members via the '.' or '->' operators. However, I > believe that you mean something more restricted than what you're actually > saying, because the code given in the original bug report does in fact > access the union members via '.' operator, in the expressions &u.s1 and > &u.s2, to create a situation where, as I understand it, that special > guarantee is fully applicable. > Could you expand on your description of what you think is required, to make > it clear why it doesn't apply in this case? It isn't clear that "&u.s1" for example actually accesses either "u" or its member "s1", and I would argue that it doesn't for either. I read it how (if I understand correctly) GCC has up until now interpreted it: the "special guarantee" is for expressions directly involving member access via the union. Once you take the address of the member, and later dereference it via "*", you are dealing with a different operator and the guarantee doesn't apply. I'll admit that this is still making some assumptions, but it's an interpretation that is far more at peace with the rest of the standard. (In reply to Andrew Haley from comment #45) > (In reply to Davin McCall from comment #44) > > The "one special guarantee" clause appears in the section describing union > > member access via the "." or "->" operators, implying that it only applies > > to the access of union members via the union. > > I don't believe that's what is intended, or that you can make such a > conclusion based on the section in which the rule appears. It applies > to other accesses too, as is (somewhat) made clear by the rationale in > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n685.htm: It certainly may not be what is intended by N685, but I think it's normally reasonable to conclude that a statement in a particular section of a document applies to that section and not more universally than that; in this case, the "universal" interpretation flatly contradicts the strict aliasing rule and any other rule which would otherwise disallow access, which seems extremely problematic to me. In general it appears the committee have asserted that the "universal" interpretation (which since N685 requires visibility of the union declaration to be effective) is the correct one, but my argument is that the actual text of the standard strongly implies something different, and that the interpretation being pushed instead turns another portion of the standard text into nonsense. It's extremely problematic in my view that a more reasonable reading is considered incorrect and that this can only be known with external knowledge outside the text of the specification itself. Never the less, I take your point.
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #53 from James Kuyper Jr. --- (In reply to Davin McCall from comment #52) > (In reply to James Kuyper Jr. from comment #48) > > > The "one special guarantee" clause appears in the section describing union > > > member access via the "." or "->" operators, implying that it only applies > > > to the access of union members via the union. ... > > > > I find nothing objectionable about that statement - it is indeed impossible > > to create code which relies upon the special guarantee in 6.5.2.3p6 without > > accessing the union members via the '.' or '->' operators. However, I > > believe that you mean something more restricted than what you're actually > > saying, because the code given in the original bug report does in fact > > access the union members via '.' operator, in the expressions &u.s1 and > > &u.s2, to create a situation where, as I understand it, that special > > guarantee is fully applicable. > > Could you expand on your description of what you think is required, to make > > it clear why it doesn't apply in this case? > > It isn't clear that "&u.s1" for example actually accesses either "u" or its > member "s1", and I would argue that it doesn't for either. I agree: that expression does not access u or s1. However, because those pointers are passed to f(), which does dereference them, f() does accesses those members, and it does so via the use of the '.' operator in the calling routine. Therefore, you need, at a minimum, to modify "accesses via" to "accesses directly via", in order to convey your intended meaning. I don't see anything in the standard's wording of 6.5.2.3p6 to justify restricting what it says to direct accesses - it says "it is permitted to inspect", without specifying restrictions on how the inspection may be performed. The words "anywhere that a declaration of the completed type of the union is visible." would become pointless with your interpretation. You already need a visible complete declaration of the union to directly access it's members without violating a constraint. Those words are only needed if the guarantee was intended to apply even when the access is not direct.
[Bug libstdc++/68397] std::tr1::expint fails in __expint_En_cont_frac for some long double arguments due to low __max_iter value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68397 --- Comment #6 from emsr at gcc dot gnu.org --- Author: emsr Date: Mon Apr 30 19:51:13 2018 New Revision: 259777 URL: https://gcc.gnu.org/viewcvs?rev=259777&root=gcc&view=rev Log: 2018-04-30 Edward Smith-Rowland <3dw...@verizon.net> PR libstdc++/pr66689 - comp_ellint_3 and ellint_3 return garbage values * include/tr1/ell_integral.tcc: Correct the nu sign convention in ellint_3 and comp_ellint_3. * testsuite/tr1/5_numerical_facilities/special_functions/ 06_comp_ellint_3/check_value.cc: Regen with correct values. * testsuite/tr1/5_numerical_facilities/special_functions/ 14_ellint_3/check_value.cc: Ditto. * testsuite/special_functions/06_comp_ellint_3/check_value.cc: Ditto. * testsuite/special_functions/13_ellint_3/check_value.cc: Ditto. * testsuite/special_functions/06_comp_ellint_3/pr66689.cc: New. * testsuite/special_functions/13_ellint_3/pr66689.cc: New. * testsuite/tr1/5_numerical_facilities/special_functions/ 06_comp_ellint_3/pr66689.cc: New. * testsuite/tr1/5_numerical_facilities/special_functions/ 14_ellint_3/pr66689.cc: New. 2018-04-30 Edward Smith-Rowland <3dw...@verizon.net> PR libstdc++/68397 std::tr1::expint fails ... long double arguments. * include/tr1/exp_integral.tcc: Increase iteration limits. * testsuite/tr1/5_numerical_facilities/special_functions/15_expint/ pr68397.cc: New test. * testsuite/special_functions/14_expint/pr68397.cc: New test. svn commit \ --This line, and those below, will be ignored-- ChangeLog \ M ChangeLog M include/tr1/ell_integral.tcc A testsuite/special_functions/06_comp_ellint_3/pr66689.cc A testsuite/special_functions/13_ellint_3/pr66689.cc A testsuite/tr1/5_numerical_facilities/special_functions/06_comp_ellint_3/pr66689.cc A testsuite/tr1/5_numerical_facilities/special_functions/14_ellint_3/pr66689.cc M testsuite/special_functions/06_comp_ellint_3/check_value.cc M testsuite/special_functions/13_ellint_3/check_value.cc M testsuite/tr1/5_numerical_facilities/special_functions/06_comp_ellint_3/check_value.cc M testsuite/tr1/5_numerical_facilities/special_functions/14_ellint_3/check_value.cc M include/tr1/exp_integral.tcc A testsuite/special_functions/14_expint/pr68397.cc A testsuite/tr1/5_numerical_facilities/special_functions/15_expint/pr68397.cc include/tr1/ell_integral.tcc \ testsuite/special_functions/06_comp_ellint_3/pr66689.cc \ testsuite/special_functions/13_ellint_3/pr66689.cc \ testsuite/tr1/5_numerical_facilities/special_functions/06_comp_ellint_3/pr66689.cc \ testsuite/tr1/5_numerical_facilities/special_functions/14_ellint_3/pr66689.cc \ testsuite/special_functions/06_comp_ellint_3/check_value.cc \ testsuite/special_functions/13_ellint_3/check_value.cc \ testsuite/tr1/5_numerical_facilities/special_functions/06_comp_ellint_3/check_value.cc \ testsuite/tr1/5_numerical_facilities/special_functio Added: branches/gcc-7-branch/libstdc++-v3/testsuite/special_functions/06_comp_ellint_3/pr66689.cc branches/gcc-7-branch/libstdc++-v3/testsuite/special_functions/13_ellint_3/pr66689.cc branches/gcc-7-branch/libstdc++-v3/testsuite/special_functions/14_expint/pr68397.cc branches/gcc-7-branch/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/06_comp_ellint_3/pr66689.cc branches/gcc-7-branch/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/14_ellint_3/pr66689.cc branches/gcc-7-branch/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/15_expint/pr68397.cc Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/include/tr1/ell_integral.tcc branches/gcc-7-branch/libstdc++-v3/include/tr1/exp_integral.tcc branches/gcc-7-branch/libstdc++-v3/testsuite/special_functions/06_comp_ellint_3/check_value.cc branches/gcc-7-branch/libstdc++-v3/testsuite/special_functions/13_ellint_3/check_value.cc branches/gcc-7-branch/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/06_comp_ellint_3/check_value.cc branches/gcc-7-branch/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/14_ellint_3/check_value.cc
[Bug c++/85580] New: "conflicting C language linkage declaration" warning for variables with identical names in `extern "C"` functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85580
Bug ID: 85580
Summary: "conflicting C language linkage declaration" warning
for variables with identical names in `extern "C"`
functions
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie_chopin at op dot pl
Target Milestone: ---
Here's a minimal test case executed with 8.0.1-RC-20180427 (compiled for
arm-none-eabi target, but I think the problem is not target-specific):
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
$ cat test.cpp
extern "C"
{
void f1()
{
union some_type{
char a[2];
int b;
} variable;
}
void f2()
{
union some_type{
char a[2];
int b;
} variable;
}
}
$ arm-none-eabi-gcc test.cpp -c
test.cpp: In function 'void f2()':
test.cpp:17:5: warning: conflicting C language linkage declaration
'f2()::some_type variable'
} variable;
^~~~
test.cpp:9:5: note: previous declaration 'f1()::some_type variable'
} variable;
^~~~
$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (bleeding-edge-toolchain) 8.0.1 20180427 (prerelease)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
For the problem to appear:
- functions with the types and variables have to be extern "C"
- the file must be C++
- there has to be both a type and a variable
- the variables must have identical names
The problem was spotted with ARM CMSIS headers, where similar pattern exists:
https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS/Core/Include/cmsis_gcc.h#L1929
Related discussion on mailing list:
https://gcc.gnu.org/ml/gcc/2018-04/msg00191.html
[Bug c++/85580] [8/9 Regression] "conflicting C language linkage declaration" warning for variables with identical names in `extern "C"` functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85580 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-30 CC||jakub at gcc dot gnu.org, ||nathan at gcc dot gnu.org Target Milestone|--- |8.0 Summary|"conflicting C language |[8/9 Regression] |linkage declaration"|"conflicting C language |warning for variables with |linkage declaration" |identical names in `extern |warning for variables with |"C"` functions |identical names in `extern ||"C"` functions Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r253622.
[Bug c++/84701] casting to ( unsigned typeof(variable) ) gives wrong results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84701 --- Comment #4 from Jason Merrill --- Author: jason Date: Mon Apr 30 21:21:32 2018 New Revision: 259780 URL: https://gcc.gnu.org/viewcvs?rev=259780&root=gcc&view=rev Log: PR c++/84701 - unsigned typeof. * decl.c (grokdeclarator): Overhaul diagnostics for invalid use of long/short/signed/unsigned. Added: trunk/gcc/testsuite/g++.dg/ext/typeof13.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/g++.dg/cpp1z/decomp3.C
[Bug c++/85305] Parameter pack expression in lambda capture list fails as part of a fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85305 --- Comment #1 from Jason Merrill --- Author: jason Date: Mon Apr 30 21:21:25 2018 New Revision: 259779 URL: https://gcc.gnu.org/viewcvs?rev=259779&root=gcc&view=rev Log: PR c++/85305 - pack in lambda init-capture. * parser.c (cp_parser_initializer): Add subexpression_p parm; don't check_for_bare_parameter_packs in a subexpression. (cp_parser_lambda_introducer): Use it. Added: trunk/gcc/testsuite/g++.dg/cpp1z/fold-lambda2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c
[Bug c++/85305] Parameter pack expression in lambda capture list fails as part of a fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85305 Jason Merrill changed: What|Removed |Added Known to work||9.0 --- Comment #2 from Jason Merrill --- Fixed on trunk so far.
[Bug c++/85305] Parameter pack expression in lambda capture list fails as part of a fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85305 Jason Merrill changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/84701] casting to ( unsigned typeof(variable) ) gives wrong results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84701 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #5 from Jason Merrill --- Fixed for GCC 9.
[Bug c++/85580] [8/9 Regression] "conflicting C language linkage declaration" warning for variables with identical names in `extern "C"` functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85580 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug tree-optimization/77485] Missed dead store elimination of aggregate store followed by partial stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77485 Bug 77485 depends on bug 33562, which changed state. Bug 33562 Summary: [6 Regression] aggregate DSE disabled https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33562 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/33562] [6 Regression] aggregate DSE disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33562 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #35 from Jeffrey A. Law --- We're not going to backport this any of the release branches.
[Bug fortran/85581] New: implied DO not initializing array as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85581
Bug ID: 85581
Summary: implied DO not initializing array as expected
Product: gcc
Version: 6.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: urbanjost at comcast dot net
Target Milestone: ---
I expect the two functions to be equivalent, but returnarrB acts like
(char(64+isize),I=1,isize) instead of (char(64+i),I=1,isize) was specified???
program uuidgen
implicit none
character(len=:),allocatable :: methods(:)
methods=[returnarrA(26),returnarrA(5)]
write(*,'(*("[",a,"]":,","))')methods
methods=[returnarrB(26),returnarrB(5)]
write(*,'(*("[",a,"]":,","))')methods
contains
function returnarrA(isize) result(arr)
integer,intent(in) :: isize
character(len=1),allocatable :: arr(:) !<== len=1
integer :: i
arr=[character(len=1) ::(char(64+i),i=1,isize)]
end function returnarrA
function returnarrB(isize) result(arr)
integer,intent(in) :: isize
character(len=:),allocatable :: arr(:) !<== len=:
integer :: i
arr=[character(len=1) ::(char(64+i),i=1,isize)]
end function returnarrB
end program uuidgen
Output
[A],[B],[C],[D],[E],[F],[G],[H],[I],[J],[K],[L],[M],[N],[O],[P],[Q],[R],[S],[T],[U],[V],[W],[X],[Y],[Z],[A],[B],[C],[D],[E]
[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[Z],[E],[E],[E],[E],[E]
Expecting returnarrA() and returnarrB() functions to return the same results.
That is, I expect
[A],[B],[C],[D],[E],[F],[G],[H],[I],[J],[K],[L],[M],[N],[O],[P],[Q],[R],[S],[T],[U],[V],[W],[X],[Y],[Z],[A],[B],[C],[D],[E]
[A],[B],[C],[D],[E],[F],[G],[H],[I],[J],[K],[L],[M],[N],[O],[P],[Q],[R],[S],[T],[U],[V],[W],[X],[Y],[Z],[A],[B],[C],[D],[E]
~
[Bug c++/85523] Add fix-it hint for missing return statement in assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85523 --- Comment #5 from David Malcolm --- Author: dmalcolm Date: Tue May 1 00:10:10 2018 New Revision: 259783 URL: https://gcc.gnu.org/viewcvs?rev=259783&root=gcc&view=rev Log: Add gcc_rich_location::add_fixit_insert_formatted This patch adds a support function to class gcc_rich_location to make it easier for fix-it hints to use idiomatic C/C++ indentation, for use by the patch for PR c++/85523. gcc/ChangeLog: PR c++/85523 * gcc-rich-location.c (blank_line_before_p): New function. (use_new_line): New function. (gcc_rich_location::add_fixit_insert_formatted): New function. * gcc-rich-location.h (gcc_rich_location::add_fixit_insert_formatted): New function. gcc/testsuite/ChangeLog: PR c++/85523 * gcc.dg/plugin/diagnostic-test-show-locus-generate-patch.c (test_add_fixit_insert_formatted_single_line): New function. (test_add_fixit_insert_formatted_multiline): New function. Extend expected output of generated patch to include fix-it hints for these. * gcc.dg/plugin/diagnostic_plugin_test_show_locus.c: Include "gcc-rich-location.h". Add test coverage for gcc_rich_location::add_fixit_insert_formatted. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc-rich-location.c trunk/gcc/gcc-rich-location.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-show-locus-generate-patch.c trunk/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_show_locus.c
[Bug c++/85523] Add fix-it hint for missing return statement in assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85523 --- Comment #6 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg1.html
[Bug other/69968] RFC: Use Damerau-Levenshtein within spellcheck.c, rather than Levenshtein
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69968 David Malcolm changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org --- Comment #4 from David Malcolm --- Candidate patch: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85523
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #54 from Davin McCall --- (In reply to James Kuyper Jr. from comment #53) > [...] However, because those > pointers are passed to f(), which does dereference them, f() does accesses > those members, and it does so via the use of the '.' operator in the calling > routine. Therefore, you need, at a minimum, to modify "accesses via" to > "accesses directly via", in order to convey your intended meaning. I thought it was clear that I was referring to access via the union. That is certainly what I did mean. > > I don't see anything in the standard's wording of 6.5.2.3p6 to justify > restricting what it says to direct accesses - it says "it is permitted to > inspect", without specifying restrictions on how the inspection may be > performed. As I have said, it is in a section regarding access and in a paragraph discussing "use of unions". While I understand what you are saying, I don't feel my own interpretation is really that difficult to fathom, and I'm not the only one to take it. See http://archive.is/PnW28 (DR 257). > The words "anywhere that a declaration of the completed type of the union > is visible." would become pointless with your interpretation. Yes, as I already said.
[Bug fortran/85547] Run-time error: character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85547 --- Comment #5 from Walter Spector --- Turns out my third case, in comment #2, is incorrect. To correct it, line 5 should read: path = (/ 'xyz/' /) With this correction, my current trunk snapshot works ok. (Doesn't apply to the first two examples though.)
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #55 from James Kuyper Jr. --- > ou need, at a minimum, to modify "accesses via" to > "accesses directly via", in order to convey your intended meaning. (In reply to Davin McCall from comment #54) > (In reply to James Kuyper Jr. from comment #53) > > [...] However, because those > > pointers are passed to f(), which does dereference them, f() does accesses > > those members, and it does so via the use of the '.' operator in the calling > > routine. Therefore, you need, at a minimum, to modify "accesses via" to > > "accesses directly via", in order to convey your intended meaning. > > I thought it was clear that I was referring to access via the union. That is > certainly what I did mean. The problem is, you're using a statement that the access must occur via a union, with the implication that the code in question does not access the member through the union. The code in the original bug report does in fact access the members through the union - indirectly, but through the union. It's not possible to bypass the u.s1 step; the fact that u.s1 is the operand of an & operator and the resulting pointer value is an argument to a function call, and that the called function is the one that actually accesses the member through that pointer, does not change the fact that the access came about as the result of the use of the '.' operator on a union object. Therefore, if you want your wording to convey your belief that such indirect use of the member selection operator is excluded, your wording needs modification to make that clear. Of course, if so modified, it would be saying something with no actual support in the C standard. > > I don't see anything in the standard's wording of 6.5.2.3p6 to justify > > restricting what it says to direct accesses - it says "it is permitted to > > inspect", without specifying restrictions on how the inspection may be > > performed. > > As I have said, it is in a section regarding access and in a paragraph > discussing "use of unions". While I understand what you are saying, I don't > feel my own interpretation is really that difficult to fathom, and I'm not > the only one to take it. See http://archive.is/PnW28 (DR 257). True, but keep in mind that the committee did not agree with his objections. The example he was complaining about is still present in the current version of the standard, without any changes that address the issues he raised (I happen to agree with him that it would have been better to use a common initial sequence with a length greater than one member, and to use a member other than the first one for the example). > > The words "anywhere that a declaration of the completed type of the union > > is visible." would become pointless with your interpretation. > > Yes, as I already said. The standard explicitly says, referring to the same example mentioned in DR 257, that the second code fragment is not valid, but only "because the union type is not visible within function f", implying that it would be valid if the declaration of the union type were moved so that it would be visible inside f(). If it were so moved, it would be essentially equivalent to the code which was the original defect report. While examples are non-normative, that example implies that the visibility clause was intended to actually serve a purpose (and it seems obvious to me that it actually does so).
[Bug target/81274] x86 optimizer emits unnecessary LEA instruction when using AVX intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81274 --- Comment #2 from Peter Cordes --- The stray LEA bug seems to be fixed in current trunk (9.0.0 20180429), at least for this testcase. Gcc's stack-alignment strategy seems to be improved overall (not copying the return address when not needed), so probably it's really fixed. It's still present in 7.3.
[Bug tree-optimization/85582] New: wrong code at -O1 and above on x86_64-linux-gnu in 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85582
Bug ID: 85582
Summary: wrong code at -O1 and above on x86_64-linux-gnu in
32-bit mode
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 9.0.0 20180501 (experimental) [trunk revision 259787] (GCC)
$
$ gcctk -m32 -O0 small.c; ./a.out
$
$ gcctk -m32 -O1 small.c
$ ./a.out
Floating point exception (core dumped)
$
-
int a, b, d = 2, e;
long long c = 1;
int main ()
{
int g = 6;
L1:
e = d;
if (a)
goto L1;
g--;
int i = c >> ~(~e | ~g);
L2:
c = (b % c) * i;
if (!e)
goto L2;
return 0;
}
