[Bug middle-end/81478] By default, GCC emits a function call for complex multiplication, should partially inline that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81478 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #8 from ktkachov at gcc dot gnu.org --- (In reply to Ben Woodard from comment #7) > We're hitting this issue over here at LLNL. On 86_64 it was just an > annoyance because users who ran into this problem just switched to ICC to > work around it. A similar thing happened with the power architecture where > the workaround was to use the XL compiler. ARM is making this a higher > priority issue for us because there are no vendor compilers to switch to. This looks like PR 70291. Can you please try a trunk compiler after r259889 ?
[Bug tree-optimization/85697] At -Os nontrivial ctor does not use SSE to zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85697
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-05-09
CC||jakub at gcc dot gnu.org
Component|target |tree-optimization
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
vectorization is not enabled at -Os (or at -O2), the SSE instructions are
generated by basic-block vectorization though I could imagine that
store-merging
could also generate those from
[100.00%]:
MEM[(struct &)&a] ={v} {CLOBBER};
MEM[(int *)&a] = 0;
MEM[(int *)&a + 8B] = 0;
UseA (&a);
_3 = a.a;
a ={v} {CLOBBER};
return _3;
The target would need to decide whether TImode stores are wanted or not
(via MAX_MOVE_PIECES or sth related). We could also, for -Os and some
embedded targets, consider emitting a memset from store-merging in case
regions are large enough and the initializer is memset compatible.
Similarly a MEM = {} could be used for zeroing, leaving actual implementation
to RTL expansion. What type to use here needs experimentation of course.
[Bug c/85709] New: Consistent variable, type and function attributes across ports
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85709 Bug ID: 85709 Summary: Consistent variable, type and function attributes across ports Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: david at westcontrol dot com Target Milestone: --- gcc supports many different targets. For some of these, there can be special attributes (variable, type, function) for particular features. This is important to programming low-level and bare-metal code. Often these are for particular features of the particular architecture, and that's fine. However, they can also be more general attributes that might be of interest or use across a range of ports. There are also cases where different ports have attributes for the same feature, but are inconsistent about naming or other details. Would it be possible to tidy this up a little, giving more features and greater consistency for people who work with multiple gcc targets? Examples of attributes that could be generalised and used on many ports : "naked" function attribute, for SPU, RISC-V, MSP430, AVR, and a few others. "critical" function attribute for MSP430, which disables global interrupts during the function. (Clearly this is not appropriate for all targets - but it would be useful on many more devices than just the MSP430.) "noinit" variable attribute for MSP430 that puts the variable in a different section (not .bss) which is not cleared at startup. This can improve startup times when you have large static arrays, and lets you keep data across resets. It would be useful on many microcontrollers and small systems. Examples of inconsistent attributes : "interrupt" function attributes handled in different ways in different ports, with different naming and details. Function attributes to explicitly save all volatile registers (useful for functions called from assembly or interrupt handlers), or to say that no registers need to be saved (useful for RTOS thread task functions) - some ports have these, with different names, but they are inconsistent and could be useful on many targets.
[Bug tree-optimization/85699] [9 regression] gcc.dg/nextafter-2.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85699 Richard Biener changed: What|Removed |Added Version|unknown |9.0 Target Milestone|--- |9.0
[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P2
--- Comment #2 from Richard Biener ---
Hmpf. Sounds like the issue requires "careful" preparation of stmt operand
order
(aka SSA name numbering). We've had issues in this area in the past.
Can you help me with isolating this to a single function inside that file?
Maybe try sticking __attribute__((optimize("no-tree-vectorize"))) on some
functions. Oh, there's also the vect_loop debug counter
(-fdbg-cnt=vect_loop:N).
Eventually we simply trigger a latent issue elsewhere when we now recognize
sth for SLP vectorization.
Otherwise I'll have to find a power8 machine where I can set up CPU 2017
myself (unlikely this week due to public holidays).
[Bug fortran/85701] ICE in mark_scope_block_unused, at tree-ssa-live.c:364
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85701 Richard Biener changed: What|Removed |Added Keywords||openacc --- Comment #2 from Richard Biener --- Sounds like wrecked BLOCK trees.
[Bug c/85704] [8/9 Regression] cc1 run out of memory when it compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85704 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Priority|P3 |P2 Status|UNCONFIRMED |NEW Known to work||7.3.0 Keywords||needs-bisection, ||needs-reduction Last reconfirmed|2018-05-08 00:00:00 |2018-05-09 Component|middle-end |c Ever confirmed|0 |1 Summary|cc1 run out of memory when |[8/9 Regression] cc1 run |it compile |out of memory when it ||compile Target Milestone|--- |8.2 Known to fail||8.1.0 --- Comment #4 from Richard Biener --- Confirmed with just -Os. We're stuck in parsing. Run till exit from #0 0x00874c8c in output_pending_init_elements ( all=1, braced_init_obstack=0x7fffc000) at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-typeck.c:9392 ...
[Bug c++/85707] -Wclass-memaccess should excempt safe usage inside of a class and its friends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85707 --- Comment #3 from Richard Biener --- Note for the example if you use -O3 the loop gets turned into memset() and the code generated is the same besides the memset being conditional on if (_buckets != 0) For the diagnostic, isn't class Position "enough" POD so we can avoid the diagnostic? So IMHO whatever the standard active considers (extended) PODs should be not warned about (or the warning get multiple levels so users get a choice?)
[Bug tree-optimization/70291] muldc3 code generation could be smarter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70291 Richard Biener changed: What|Removed |Added CC||smcallis at gmail dot com --- Comment #5 from Richard Biener --- *** Bug 81478 has been marked as a duplicate of this bug. ***
[Bug middle-end/81478] By default, GCC emits a function call for complex multiplication, should partially inline that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81478 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Richard Biener --- Indeed a duplicate. *** This bug has been marked as a duplicate of bug 70291 ***
[Bug tree-optimization/85694] Generation of vectorized AVG (Average) instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85694 --- Comment #4 from Richard Biener --- OK, so adding another pattern plus IFN would be the canonical way of vectorizing this.
[Bug c++/70693] valgrind error in get_visual_column
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70693
David Binderman changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED |---
--- Comment #2 from David Binderman ---
Problem seems to have come back, somewhere between revisions 259747 and 259789
/home/dcb/gcc/results.259742.ubsan/bin/gcc
/home/dcb/gcc/results.259747.asan/bin/gcc
/home/dcb/gcc/results.259789/bin/gcc
bug277.cc: In member function ‘bool
{anonymous}::SgmlFilter::process_char(FilterChar::Chr)’:
bug277.cc:54:39: internal compiler error: in operator[], at input.h:62
[Bug rtl-optimization/85638] [8/9 regression] build failure for Ada runtime with SJLJ exceptions on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85638 --- Comment #16 from Eric Botcazou --- Author: ebotcazou Date: Wed May 9 07:58:29 2018 New Revision: 260070 URL: https://gcc.gnu.org/viewcvs?rev=260070&root=gcc&view=rev Log: PR rtl-optimization/85638 * bb-reorder.c: Include common/common-target.h. (create_forwarder_block): New function extracted from... (fix_up_crossing_landing_pad): ...here. Rename into... (dw2_fix_up_crossing_landing_pad): ...this. (sjlj_fix_up_crossing_landing_pad): New function. (find_rarely_executed_basic_blocks_and_crossing_edges): In SJLJ mode, call sjlj_fix_up_crossing_landing_pad if there are incoming EH edges from both partitions and exit the loop after one iteration. Modified: trunk/gcc/ChangeLog trunk/gcc/bb-reorder.c
[Bug rtl-optimization/85638] [8/9 regression] build failure for Ada runtime with SJLJ exceptions on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85638 --- Comment #17 from Eric Botcazou --- Author: ebotcazou Date: Wed May 9 07:59:46 2018 New Revision: 260071 URL: https://gcc.gnu.org/viewcvs?rev=260071&root=gcc&view=rev Log: PR rtl-optimization/85638 * bb-reorder.c: Include common/common-target.h. (create_forwarder_block): New function extracted from... (fix_up_crossing_landing_pad): ...here. Rename into... (dw2_fix_up_crossing_landing_pad): ...this. (sjlj_fix_up_crossing_landing_pad): New function. (find_rarely_executed_basic_blocks_and_crossing_edges): In SJLJ mode, call sjlj_fix_up_crossing_landing_pad if there are incoming EH edges from both partitions and exit the loop after one iteration. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/bb-reorder.c
[Bug sanitizer/85556] attribute no_sanitize does not accept multiple options as documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85556 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Known to fail||8.1.0 --- Comment #2 from Martin Liška --- Mine.
[Bug ipa/85656] gcc.dg/ipa/ipa-icf-38.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85656 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-05-09 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Mine.
[Bug ipa/85607] [9 Regression] ice in add_type, at ipa-icf.c:1583
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85607 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-05-09 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Mine.
[Bug tree-optimization/70291] muldc3 code generation could be smarter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70291 --- Comment #6 from Wilco --- (In reply to ktkachov from comment #4) > Implemented for GCC 9. Since multiple people seem interested in the improvement, would it be useful to backport?
[Bug rtl-optimization/85638] [8/9 regression] build failure for Ada runtime with SJLJ exceptions on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85638 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Eric Botcazou --- Thanks for reporting the problem.
[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
--- Comment #39 from Richard Biener ---
(In reply to Jason Merrill from comment #38)
> (In reply to Jonathan Wakely from comment #37)
>
> If you add a
>
> Y y{};
>
> GCC warns about the Y constructor.
>
> We don't warn about the implicit X constructor because we don't clobber the
> object at the beginning of an implicit constructor, because
> value-initialization zero-initializes the object before calling the implicit
> constructor, and we mustn't clobber that initialization (bug 68006). The
> middle end relies on the clobber to know what's uninitialized, so we don't
> get the warning here.
>
> It would be appropriate to give a maybe-uninitialized warning here, though.
> I don't know how complicated it would be to do that using the existing
> mechanisms.
These case are difficult because they involve exported globals which GCC
thinks are always initialized. For the testcase only the initializer
of x prevails, the constructor of y is discarded before we run the
warning machinery. The initializer of x prevails in
__static_initialization_and_destruction_0 like
_1 = x.x2;
x.x1 = _1;
which has the aforementioned issue. So for a proper testcase we need
calls to the constructors (where we should warn in?) and the constructors
prevail.
Adding
Y y{};
makes Y::Y prevail and as you said we warn about it. IL:
Y::Y (struct Y * const this)
{
int _1;
:
MEM[(struct &)this_3(D)] ={v} {CLOBBER};
_1 = this_3(D)->y2;
this_3(D)->y1 = _1;
this_3(D)->y2 = 0;
return;
so - how do I make X::X used and thus prevail? It looks like it doesn't
really exist and the C++ FE even for
void foo() { X x{}; }
just outputs
;; Function void foo() (null)
;; enabled by -tree-original
{
struct X x = {.x2=0};
<>;
<;
}
which ends up as
foo ()
{
struct X x;
try
{
x = {};
_1 = x.x2;
x.x1 = _1;
}
finally
{
x = {CLOBBER};
}
}
so there is no uninitialized use.
OK, doing void foo() { X x; } shows
X::X (struct X * const this)
{
_1 = this->x2;
this->x1 = _1;
this->x2 = 0;
}
foo ()
{
struct X x;
try
{
X::X (&x);
}
finally
{
x = {CLOBBER};
}
}
warning would need inlining of the constructor which only happens after
the early warning pass, the late one isn't run at -O0 and with optimization
everything of course vanishes.
[Bug c++/33260] For scope warning despite -ffor-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33260 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED CC|gcc-bugs at gcc dot gnu.org| Known to work||6.1.0 Resolution|--- |FIXED --- Comment #2 from Paolo Carlini --- Fixed long time ago, in 6.1.0.
[Bug tree-optimization/85694] Generation of vectorized AVG (Average) instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85694 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||rsandifo at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #5 from rsandifo at gcc dot gnu.org --- We'd identified a similar problem with the corresponding AArch64 instruction. Hope to get round to this next week.
[Bug libstdc++/83140] assoc_legendre returns negated value when m is odd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83140 --- Comment #3 from Jonathan Wakely --- Dinkumware also have an implementation of the TR1 special functions.
[Bug c++/85707] -Wclass-memaccess should excempt safe usage inside of a class and its friends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85707 --- Comment #4 from Jonathan Wakely --- The Position type is trivially-copyable, so IMHO shouldn't warn about uses of memset/memcpy, but I'm not sure what the conditions for the warning are.
[Bug c++/85707] -Wclass-memaccess should excempt safe usage inside of a class and its friends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85707 --- Comment #5 from Jonathan Wakely --- IMHO classes and their friends should not have any special exemptions, because undefined behaviour is still undefined behaviour, it doesn't matter who does it. But in this case I don't think there is any UB.
[Bug c++/85707] -Wclass-memaccess should excempt safe usage inside of a class and its friends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85707 Richard Biener changed: What|Removed |Added Status|WAITING |NEW --- Comment #6 from Richard Biener --- Thus confirmed. Trivially copyable classes should not be warned on.
[Bug rtl-optimization/85180] Infinite loop in RTL DSE optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180 Romain Naour changed: What|Removed |Added CC||romain.naour at gmail dot com --- Comment #18 from Romain Naour --- (In reply to Richard Biener from comment #17) > (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? Ping?
[Bug middle-end/85599] Function need not be evaluated in logical expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599 janus at gcc dot gnu.org changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=57160 --- Comment #14 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #10) > Am I mistaken to read this as being handled by the middle-end? The short-circuiting is finally handled by the middle end, since the front end translates .and. into &&. See also comment 6. Apparently the standard does neither require nor forbid the short-circuiting (see c.l.f. discussion), but I would argue that it would be a more reasonable for gfortran to avoid the short-circuiting (by translating to &), at least if it is not clear whether the function has side effects. > If yes, the > situation is discussed in pr57160 comment 1. Right, this PR is very much related. > Does it means that 'check' has to be evaluated in > > if (flag) flag = check () > > even if flag==.false. ? No, I'm pretty sure that is not the case.
[Bug target/85626] [nvptx] __builtin_trap should not return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85626 --- Comment #1 from Tom de Vries --- Author: vries Date: Wed May 9 10:32:40 2018 New Revision: 260072 URL: https://gcc.gnu.org/viewcvs?rev=260072&root=gcc&view=rev Log: [nvptx] Make trap insn noreturn 2018-05-09 Tom de Vries PR target/85626 * config/nvptx/nvptx.md (define_insn "trap", define_insn "trap_if_true") (define_insn "trap_if_false"): Add exit after trap. Modified: trunk/gcc/ChangeLog trunk/gcc/config/nvptx/nvptx.md
[Bug rtl-optimization/85180] Infinite loop in RTL DSE optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180 --- Comment #19 from rguenther at suse dot de --- On Wed, 9 May 2018, romain.naour at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180 > > Romain Naour changed: > >What|Removed |Added > > CC||romain.naour at gmail dot com > > --- Comment #18 from Romain Naour --- > (In reply to Richard Biener from comment #17) > > (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? > > Ping? Jakub said it doesn't qualify give it's too risky.
[Bug target/85626] [nvptx] __builtin_trap should not return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85626 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #2 from Tom de Vries --- Patch committed, marking resolved-fixed.
[Bug c/85696] OpenMP with variably modified and default(none) won't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85696 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-05-09 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek --- Created attachment 44096 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44096&action=edit gcc9-pr85696.patch Untested fix.
[Bug ipa/85655] [8/9 Regression] ICE with -flto and -O2 during IPA pass: cp lto1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85655 --- Comment #3 from Martin Liška --- Started with r259319.
[Bug target/85231] [og7, openacc, nvptx] Too much shared memory claimed for long vector length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85231 Tom de Vries changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug tree-optimization/84958] int loads not eliminated against larger stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84958 Tom de Vries changed: What|Removed |Added Severity|normal |enhancement
[Bug lto/85583] [9 Regression] lto1: internal compiler error: in lto_balanced_map, at lto/lto-partition.c:833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85583 Martin Liška changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #3 from Martin Liška --- Can't reproduce, can you please provide output --verbose.
[Bug rtl-optimization/85645] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645 --- Comment #9 from Segher Boessenkool --- Author: segher Date: Wed May 9 12:12:33 2018 New Revision: 260074 URL: https://gcc.gnu.org/viewcvs?rev=260074&root=gcc&view=rev Log: regcprop: Avoid REG_CFA_REGISTER notes (PR85645) Changing a SET that has a REG_CFA_REGISTER note is wrong if we are changing the SET_DEST, or if the REG_CFA_REGISTER has nil as its argument, and maybe some other cases. It's never really useful to propagate into such an instruction, so let's just bail whenever we see such a note. PR rtl-optimization/85645 * regcprop.c (copyprop_hardreg_forward_1): Don't propagate into an insn that has a REG_CFA_REGISTER note. Modified: trunk/gcc/ChangeLog trunk/gcc/regcprop.c
[Bug target/85616] ARM target using -O2 may cause unaligned access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85616 Richard Earnshaw changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #7 from Richard Earnshaw --- Setting correct closed state.
[Bug rtl-optimization/85645] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645 --- Comment #10 from Segher Boessenkool --- Author: segher Date: Wed May 9 12:14:39 2018 New Revision: 260075 URL: https://gcc.gnu.org/viewcvs?rev=260075&root=gcc&view=rev Log: regrename: Don't rename the dest of a REG_CFA_REGISTER (PR85645) We should never change the destination of a REG_CFA_REGISTER, just like for insns with a REG_CFA_RESTORE, because we need to have the same control flow information on all branches that join. It is very doubtful that renaming the scratch registers used for prologue/epilogue will help anything either. PR rtl-optimization/85645 * regrename.c (build_def_use): Also kill the chains that include the destination of a REG_CFA_REGISTER note. Modified: trunk/gcc/ChangeLog trunk/gcc/regrename.c
[Bug lto/85583] [9 Regression] lto1: internal compiler error: in lto_balanced_map, at lto/lto-partition.c:833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85583 Martin Liška changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from Martin Liška --- (In reply to Martin Liška from comment #3) > Can't reproduce, can you please provide output --verbose. Not needed, I have another test-case that I've been reducing.
[Bug c++/85710] New: Enabling memset-elt-size warning causes ICE on memset of template member array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85710
Bug ID: 85710
Summary: Enabling memset-elt-size warning causes ICE on memset
of template member array
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jwyatt at feralinteractive dot com
Target Milestone: ---
The memset-elt-size warning causes an internal compiler error when compiling:
#include
template struct A { int a; };
template
class E
{
public:
void Clear();
private:
A mA[2];
};
template
void E::Clear()
{
memset(mA, 0, sizeof(int)*2);
}
It does not cause an ICE if mA is not an array, or is an array of size 1. It
does not cause an ICE if using memset(mA, 0, sizeof(mA)); or memset(&mA[0], 0,
sizeof(int)*2);
The code causes an ICE when compiled with:
g++ -Wmemset-elt-size test.cpp
It does not cause an ICE when compiled with:
g++ -Wall -Wextra -Wno-memset-elt-size
Reproduces in:
g++ (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1)
Configured with: ../gcc-8.1.0/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran
--enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto
--enable-plugins --enable-threads=posix --with-pkgversion=GCC-Explorer-Build
Thread model: posix
gcc version 8.1.0 (GCC-Explorer-Build)
Configured with: ../gcc-trunk-20180508/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran
--enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto
--enable-plugins --enable-threads=posix --with-pkgversion=GCC-Explorer-Build
Thread model: posix
gcc version 9.0.0 20180508 (experimental) (GCC-Explorer-Build)
Does not reproduce in:
Configured with: ../gcc-7.3.0/configure --prefix /root/staging
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--disable-bootstrap --enable-multiarch --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran --enable-ld=yes --enable-gold=yes
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id
--enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=GCC-Explorer-Build
Thread model: posix
gcc version 7.3.0 (GCC-Explorer-Build)
[Bug rtl-optimization/85645] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645 --- Comment #11 from Segher Boessenkool --- Author: segher Date: Wed May 9 12:48:43 2018 New Revision: 260076 URL: https://gcc.gnu.org/viewcvs?rev=260076&root=gcc&view=rev Log: shrink-wrap: Improve spread_components (PR85645) In the testcase for PR85645 we do a pretty dumb placement of the prologue/epilogue for the LR component: we place an epilogue for LR before a control flow split where one of the branches clobbers LR eventually, and the other does not. The branch that does clobber it will need a prologue again some time later. Because saving and restoring LR is a two step process---it needs to be moved via a GPR--- the backend emits CFI directives so that we get correct unwind information. But both regcprop and regrename do not properly handle such CFI directives leading to ICEs. Now, neither of the two branches needs to have LR restored at all, because both of the branches end up in an infinite loop. This patch makes spread_component return a boolean saying if anything was changed, and if so, it is called again. This obviously is finite (there is a finite number of basic blocks, each with a finite number of components, and spread_components can only assign more components to a block, never less). I also instrumented the code, and on a bootstrap+regtest spread_components made changes a maximum of two times. Interestingly though it made changes on two iterations in a third of the cases it did anything at all! PR rtl-optimization/85645 * shrink-wrap.c (spread_components): Return a boolean saying if anything was changed. (try_shrink_wrapping_separate): Iterate spread_components until nothing changes anymore. Modified: trunk/gcc/ChangeLog trunk/gcc/shrink-wrap.c
[Bug rtl-optimization/85645] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645 --- Comment #12 from Segher Boessenkool --- Author: segher Date: Wed May 9 12:51:00 2018 New Revision: 260077 URL: https://gcc.gnu.org/viewcvs?rev=260077&root=gcc&view=rev Log: rs6000: Give an argument to every REG_CFA_REGISTER (PR85645) The one for the prologue mflr did not have any value set, which means use the SET that is in the insn pattern. This works fine, except when some late pass decides to replace the SET_SRC -- this changes the meaning of the REG_CFA_REGISTER! Such passes should not do these things, but let's be more explicit here, for extra robustness. It could be argued that this defaulting is a design misfeature (it does not save much space either, etc.) PR rtl-optimization/85645 * config/rs6000/rs6000.c (rs6000_emit_prologue_components): Put a SET in the REG_CFA_REGISTER note for LR, don't leave it empty. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug rtl-optimization/85645] ICE in maybe_record_trace_start, at dwarf2cfi.c:2348
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645 --- Comment #13 from Segher Boessenkool --- Fixed on trunk. The comment 9 and comment 10 patches probably should be backported.
[Bug lto/85583] [9 Regression] lto1: internal compiler error: in lto_balanced_map, at lto/lto-partition.c:833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85583
--- Comment #5 from Martin Liška ---
Reduced test-case:
$ cat json.ii
class b {
public:
virtual ~b();
};
template class c : b {};
class B {
c d;
};
extern template class c;
main() { B a; }
$ ./xgcc -B. -flto=8 -O2 -std=gnu++17 json.ii
json.ii:10:6: warning: ISO C++ forbids declaration of ‘main’ with no type
[-Wreturn-type]
main() { B a; }
^
lto1: internal compiler error: in lto_balanced_map, at lto/lto-partition.c:836
0x62014f lto_balanced_map(int, int)
../../gcc/lto/lto-partition.c:836
0x614b2c do_whole_program_analysis
../../gcc/lto/lto.c:3179
0x614b2c lto_main()
../../gcc/lto/lto.c:3374
Honza, can you please fix that?
[Bug ipa/85607] [9 Regression] ice in add_type, at ipa-icf.c:1583
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85607 --- Comment #3 from Martin Liška --- Started with r259772. We should skip incomplete types in ICF. I'm cooking a patch for that.
[Bug tree-optimization/85699] [9 regression] gcc.dg/nextafter-2.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85699 --- Comment #2 from Jakub Jelinek --- If you are using glibc < 2.24, then maybe this is: https://sourceware.org/bugzilla/show_bug.cgi?id=20205
[Bug tree-optimization/85699] [9 regression] gcc.dg/nextafter-2.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85699 --- Comment #3 from Jakub Jelinek --- Created attachment 44097 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44097&action=edit gcc9-pr85699.patch Untested workaround (if we want to workaround libc bugs in the testsuite).
[Bug target/85711] New: ICE in aarch64_classify_address, at config/aarch64/aarch64.c:5678
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85711
Bug ID: 85711
Summary: ICE in aarch64_classify_address, at
config/aarch64/aarch64.c:5678
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: amker at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: aarch64-linux-gnu
Following ICEs:
$ aarch64-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/pr84682-2.c
asm("" : : "pir"(c));
^~~
0xdeadbeef aarch64_classify_address
.././../gcc/config/aarch64/aarch64.c:5677
0xdeadbeef aarch64_legitimate_address_hook_p
.././../gcc/config/aarch64/aarch64.c:5958
0xdeadbeef memory_address_addr_space_p(machine_mode, rtx_def*, unsigned char)
.././../gcc/recog.c:1334
0xdeadbeef address_operand(rtx_def*, machine_mode)
.././../gcc/recog.c:1073
0xdeadbeef asm_operand_ok(rtx_def*, char const*, char const**)
.././../gcc/recog.c:1816
0xdeadbeef expand_asm_stmt
.././../gcc/cfgexpand.c:3138
0xdeadbeef expand_gimple_stmt_1
.././../gcc/cfgexpand.c:3621
0xdeadbeef expand_gimple_stmt
.././../gcc/cfgexpand.c:3790
0xdeadbeef expand_gimple_basic_block
.././../gcc/cfgexpand.c:5819
0xdeadbeef execute
.././../gcc/cfgexpand.c:6425
[Bug c++/85710] [8/9 Regression] Enabling memset-elt-size warning causes ICE on memset of template member array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85710 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Known to work||7.3.0 Keywords||ice-on-valid-code, ||needs-bisection Last reconfirmed||2018-05-09 Ever confirmed|0 |1 Summary|Enabling memset-elt-size|[8/9 Regression] Enabling |warning causes ICE on |memset-elt-size warning |memset of template member |causes ICE on memset of |array |template member array Target Milestone|--- |8.2 Known to fail||8.1.0 --- Comment #1 from Richard Biener --- Confirmed.
[Bug tree-optimization/85712] New: [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85712 Bug ID: 85712 Summary: [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479 Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Starting from r251264 we ICE on: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/whole_file_9.f90 -O3 --param scev-max-expr-size=0 -c during GIMPLE pass: slsr /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/whole_file_9.f90:8:0: program test internal compiler error: Segmentation fault 0xc5b59f crash_signal ../../gcc/toplev.c:325 0x865faa dominated_by_p(cdi_direction, basic_block_def const*, basic_block_def const*) ../../gcc/dominance.c:1118 0x1464481 all_phi_incrs_profitable_1 ../../gcc/gimple-ssa-strength-reduction.c:3479 0x1464aa4 all_phi_incrs_profitable ../../gcc/gimple-ssa-strength-reduction.c:3550 0x1464aa4 replace_profitable_candidates ../../gcc/gimple-ssa-strength-reduction.c:3806 0x14649e3 replace_profitable_candidates ../../gcc/gimple-ssa-strength-reduction.c:3838 0x1468cbc analyze_candidates_and_replace ../../gcc/gimple-ssa-strength-reduction.c:3917 0x1468cbc execute ../../gcc/gimple-ssa-strength-reduction.c:3995
[Bug tree-optimization/85712] [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85712 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-09 Version|unknown |9.0 Ever confirmed|0 |1
[Bug target/85711] ICE in aarch64_classify_address, at config/aarch64/aarch64.c:5678
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85711 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #1 from ktkachov at gcc dot gnu.org --- This is awaiting review of Bin's patch https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01085.html
[Bug target/84332] ICE in insn_default_length, at config/s390/s390.md:9697 for -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84332 --- Comment #1 from Martin Liška --- May I please ping this..
[Bug c++/85713] New: [9 Regression] ICE in dependent_type_p, at cp/pt.c:24582 on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85713
Bug ID: 85713
Summary: [9 Regression] ICE in dependent_type_p, at
cp/pt.c:24582 on invalid code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Starting from r260050 we ICE on:
$ ./xg++ -B.
/home/marxin/BIG/Programming/llvm/tools/clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-generic-lambda-1y.cpp
/home/marxin/BIG/Programming/llvm/tools/clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-generic-lambda-1y.cpp:
In function ‘int main()’:
/home/marxin/BIG/Programming/llvm/tools/clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-generic-lambda-1y.cpp:37:20:
internal compiler error: in dependent_type_p, at cp/pt.c:24582
) -> int { return v + i + c
^~~
0x83a1ab dependent_type_p(tree_node*)
../../gcc/cp/pt.c:24582
0x6beb68 require_complete_types_for_parms
../../gcc/cp/decl.c:12571
0x6beb68 check_function_type
../../gcc/cp/decl.c:14743
0x6beb68 start_preparsed_function(tree_node*, tree_node*, int)
../../gcc/cp/decl.c:14959
0x728ab4 start_lambda_function(tree_node*, tree_node*)
../../gcc/cp/lambda.c:1393
0x779148 cp_parser_lambda_body
../../gcc/cp/parser.c:10656
0x777d36 cp_parser_lambda_expression
../../gcc/cp/parser.c:10170
0x76d154 cp_parser_primary_expression
../../gcc/cp/parser.c:5263
0x771190 cp_parser_postfix_expression
../../gcc/cp/parser.c:7005
0x7747ae cp_parser_unary_expression
../../gcc/cp/parser.c:8300
0x7758c0 cp_parser_cast_expression
../../gcc/cp/parser.c:9068
0x7759bd cp_parser_binary_expression
../../gcc/cp/parser.c:9169
0x77679a cp_parser_assignment_expression
../../gcc/cp/parser.c:9464
0x776fad cp_parser_constant_expression
../../gcc/cp/parser.c:9748
0x78f225 cp_parser_initializer_clause
../../gcc/cp/parser.c:21927
0x78f043 cp_parser_initializer
../../gcc/cp/parser.c:21867
0x78abe0 cp_parser_init_declarator
../../gcc/cp/parser.c:19678
0x77e300 cp_parser_simple_declaration
../../gcc/cp/parser.c:13038
0x77de43 cp_parser_block_declaration
../../gcc/cp/parser.c:12857
0x77d23d cp_parser_declaration_statement
../../gcc/cp/parser.c:12451
Where the file can be downloaded here:
https://github.com/llvm-mirror/clang/blob/master/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-generic-lambda-1y.cpp
[Bug c++/85713] [9 Regression] ICE in dependent_type_p, at cp/pt.c:24582 on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85713 Martin Liška changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-09 CC||paolo.carlini at oracle dot com Version|unknown |9.0 Ever confirmed|0 |1
[Bug tree-optimization/85712] [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85712 Richard Biener changed: What|Removed |Added Priority|P3 |P2 CC||wschmidt at gcc dot gnu.org Target Milestone|--- |8.2 --- Comment #1 from Richard Biener --- I think we've been here before. stmt_cand_map gets stale somehow. Oh, it's actually basis->cand_stmt that is no longer in the IL. It gets replaced by replace_one_candidate: #0 gsi_replace (gsi=0x7fffd5b0, stmt=, update_eh_info=false) at /space/rguenther/src/gcc-slpcost/gcc/gimple-iterator.c:428 #1 0x01ca03e7 in replace_one_candidate (c=0x2dcd280, i=0, basis_name=) at /space/rguenther/src/gcc-slpcost/gcc/gimple-ssa-strength-reduction.c:3741 #2 0x01ca074b in replace_profitable_candidates (c=0x2dcd280) at /space/rguenther/src/gcc-slpcost/gcc/gimple-ssa-strength-reduction.c:3829 #3 0x01ca09d9 in analyze_candidates_and_replace () at /space/rguenther/src/gcc-slpcost/gcc/gimple-ssa-strength-reduction.c:3917 #4 0x01ca0bd0 in (anonymous namespace)::pass_strength_reduction::execute (this=0x2cf1490, fun=0x76a5c160) at /space/rguenther/src/gcc-slpcost/gcc/gimple-ssa-strength-reduction.c:3995 I suppose gsi_replace (&gsi, copy_stmt, false); c->cand_stmt = copy_stmt; ^^^ this is supposed to fix it up. But we fixup only this and following (next_interp) candidates - but this one has "previous" ones. 52 [24] _99 = S.17_130 * iftmp.23_30; MULT : (S.17_130 + 0) * iftmp.23_30 : integer(kind=8) basis: 49 dependent: 63 sibling: 0 next-interp: 53 dead-savings: 0 53 [24] _99 = S.17_130 * iftmp.23_30; MULT : (iftmp.23_30 + 0) * S.17_130 : integer(kind=8) basis: 48 dependent: 0 sibling: 0 next-interp: 0 dead-savings: 0 Bill?
[Bug libgomp/83792] [openacc] Factor out async argument utility functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83792 --- Comment #3 from Tom de Vries --- Author: vries Date: Wed May 9 13:52:49 2018 New Revision: 260081 URL: https://gcc.gnu.org/viewcvs?rev=260081&root=gcc&view=rev Log: [openacc] Factor out async argument utility functions 2018-05-09 Tom de Vries PR libgomp/83792 * oacc-int.h (async_valid_stream_id_p, async_valid_p) (async_synchronous_p): New function. * oacc-async.c (acc_async_test, acc_wait, acc_wait_all_async): Use async_valid_p. * oacc-cuda.c (acc_get_cuda_stream, acc_set_cuda_stream): Use async_valid_stream_id_p. * oacc-mem.c (gomp_acc_remove_pointer): Use async_synchronous_p. * oacc-parallel.c (GOACC_parallel_keyed): Same. Modified: trunk/libgomp/ChangeLog trunk/libgomp/oacc-async.c trunk/libgomp/oacc-cuda.c trunk/libgomp/oacc-int.h trunk/libgomp/oacc-mem.c trunk/libgomp/oacc-parallel.c
[Bug libgomp/83792] [openacc] Factor out async argument utility functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83792 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Tom de Vries --- Patch committed, marking resolved-fixed.
[Bug c++/85714] New: -Wimplicit-fallthrough and nested exhaustive switch statements with enum classes and return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85714
Bug ID: 85714
Summary: -Wimplicit-fallthrough and nested exhaustive switch
statements with enum classes and return
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thomas.o...@pdv-fs.de
Target Milestone: ---
Nesting enum class switch statements which are exhaustive and whose cases all
return produces a false positive -Werror=implicit-fallthrough warning:
$ ~/gcc/8.1.0/bin/g++ -Wall -Wextra -c switch_fallthrough.cpp -Werror
switch_fallthrough.cpp: In function 'int example(Foo, Bar)':
switch_fallthrough.cpp:8:7: error: this statement may fall through
[-Werror=implicit-fallthrough=]
switch(b) {
^~
switch_fallthrough.cpp:13:5: note: here
case Foo::E2:
^~~~
Uncommenting the [[fallthrough]]; fixes this, but should not be required since
no fallthrough can happen.
Related, the last return -1 in the function should not be required since the
outer switch is also exhaustive.
enum class Foo { E1, E2 };
enum class Bar { A, B };
int example(Foo f, Bar b)
{
switch(f) {
case Foo::E1:
switch(b) {
case Bar::A: return 1;
case Bar::B: return 2;
}
///[[fallthrough]]; // -Wimplicit-fallthrough -- new in gcc 8.1
case Foo::E2:
switch(b) {
case Bar::A: return 3;
case Bar::B: return 4;
}
}
return -1; // -Wreturn-type -- already in gcc 7.3, should not be required
}
[Bug libgomp/83792] [openacc] Factor out async argument utility functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83792 Tom de Vries changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/85714] -Wimplicit-fallthrough and nested exhaustive switch statements with enum classes and return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85714 --- Comment #1 from Thomas Otto --- Created attachment 44098 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44098&action=edit -Werror=implicit-fallthrough false positive demo
[Bug tree-optimization/85712] [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85712 Bill Schmidt changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot gnu.org --- Comment #2 from Bill Schmidt --- I'll take a look. FYI, I will be traveling over the next week or so, so it may be later in the month before I can get this sorted out. Thanks for the heads-up!
[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832
claudio daffra changed:
What|Removed |Added
CC||daffra.claudio at gmail dot com
--- Comment #14 from claudio daffra ---
internal compiler error: in reshape_init_class
I have reproduce this error in source code below
C:\prj\cd>g++ src\prova.cpp -o prova.exe -std=c++14
src\prova.cpp: In function 'int main()':
src\prova.cpp:24:5: internal compiler error: in reshape_init_class, at
cp/decl.c:5484
t1 = { 1,"tok",{ .real=3.4 } ,1,2} ;
^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
C:\prj\cd>
#include
#include
#include
#include
typedef struct token_s
{
uint8_t sym ;
std::string tok ;
union {
uint64_tinteger ;
double real;
} ;
uint32_trow ;
uint32_tcol ;
} token_t ;
int main ( void )
{
token_t t1 ;
t1 = { 1,"tok",{ .real=3.4 } ,1,2} ;
wprintf ( L"%d %s %d %d
%d\n",t1.sym,t1.tok.c_str(),t1.integer,t1.row,t1.col ) ;
return 0 ;
}
[Bug c++/85715] New: internal compiler error: in reshape_init_class ( in anonymous union )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85715
Bug ID: 85715
Summary: internal compiler error: in reshape_init_class ( in
anonymous union )
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daffra.claudio at gmail dot com
Target Milestone: ---
Created attachment 44099
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44099&action=edit
error source code to reproduce it
internal compiler error: in reshape_init_class
I have reproduce this error in source code below
C:\prj\cd>g++ src\prova.cpp -o prova.exe -std=c++14
src\prova.cpp: In function 'int main()':
src\prova.cpp:24:5: internal compiler error: in reshape_init_class, at
cp/decl.c:5484
t1 = { 1,"tok",{ .real=3.4 } ,1,2} ;
^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
C:\prj\cd>
similar error : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832
#include
#include
#include
#include
typedef struct token_s
{
uint8_t sym ;
std::string tok ;
union {
uint64_tinteger ;
double real;
} ;
uint32_trow ;
uint32_tcol ;
} token_t ;
int main ( void )
{
token_t t1 ;
t1 = { 1,"tok",{ .real=3.4 } ,1,2} ;
wprintf ( L"%d %s %d %d
%d\n",t1.sym,t1.tok.c_str(),t1.integer,t1.row,t1.col ) ;
return 0 ;
}
C:\prj\cd>g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=C:/Qt/Qt5.10.1/Tools/mingw530_32/bin/../libexec/gcc/i686-w64-mingw32/5.3.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../../../src/gcc-5.3.0/configure --host=i686-w64-mingw32
--build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32
--with-sysroot=/c/mingw530/i686-530-posix-dwarf-rt_v4-rev0/mingw32
--with-gxx-include-dir=/mingw32/i686-w64-mingw32/include/c++ --enable-shared
--enable-static --disable-multilib --enable-languages=c,c++,fortran,lto
--enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp
--enable-libatomic --enable-lto --enable-graphite --enable-checking=release
--enable-fully-dynamic-string --enable-version-specific-runtime-libs
--disable-sjlj-exceptions --with-dwarf2 --disable-isl-version-check
--disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-gnu-as --with-gnu-ld --with-arch=i686
--with-tune=generic --with-libiconv --with-system-zlib
--with-gmp=/c/mingw530/prerequisites/i686-w64-mingw32-static
--with-mpfr=/c/mingw530/prerequisites/i686-w64-mingw32-static
--with-mpc=/c/mingw530/prerequisites/i686-w64-mingw32-static
--with-isl=/c/mingw530/prerequisites/i686-w64-mingw32-static
--with-pkgversion='i686-posix-dwarf-rev0, Built by MinGW-W64 project'
--with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-I/c/mingw530/i686-530-posix-dwarf-rt_v4-rev0/mingw32/opt/include
-I/c/mingw530/prerequisites/i686-zlib-static/include
-I/c/mingw530/prerequisites/i686-w64-mingw32-static/include' CXXFLAGS='-O2
-pipe -I/c/mingw530/i686-530-posix-dwarf-rt_v4-rev0/mingw32/opt/include
-I/c/mingw530/prerequisites/i686-zlib-static/include
-I/c/mingw530/prerequisites/i686-w64-mingw32-static/include' CPPFLAGS=
LDFLAGS='-pipe -L/c/mingw530/i686-530-posix-dwarf-rt_v4-rev0/mingw32/opt/lib
-L/c/mingw530/prerequisites/i686-zlib-static/lib
-L/c/mingw530/prerequisites/i686-w64-mingw32-static/lib
-Wl,--large-address-aware'
Thread model: posix
gcc version 5.3.0 (i686-posix-dwarf-rev0, Built by MinGW-W64 project)
C:\prj\cd>
[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
--- Comment #40 from Jason Merrill ---
(In reply to Richard Biener from comment #39)
> so - how do I make X::X used and thus prevail? It looks like it doesn't
> really exist
True, for C++14 and up, "X x{};" does aggregate initialization rather than
calling the constructor. We ought to warn about this at function scope, but we
clear the object first, so it isn't actually uninitialized.
As you found, removing the {} makes it use the constructor.
> OK, doing void foo() { X x; } shows
>
> X::X (struct X * const this)
> {
> _1 = this->x2;
> this->x1 = _1;
> this->x2 = 0;
> }
>
> foo ()
> {
> struct X x;
>
> try
> {
> X::X (&x);
> }
> finally
> {
> x = {CLOBBER};
> }
> }
>
> warning would need inlining of the constructor which only happens after
> the early warning pass, the late one isn't run at -O0 and with optimization
> everything of course vanishes.
I was wondering about a maybe-uninitialized warning for the constructor without
considering where it's called from; even if a particular object is
zero-initialized when we enter the implicit constructor, the constructor
shouldn't rely on that. Basically, warn as if there were a clobber, without
there actually being one.
[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808 --- Comment #41 from Manuel López-Ibáñez --- All these cases can be handled perfectly by the FE and there's a patch above. Why complicate it by expecting the ME to understand C++ mem-initializer semantics?
[Bug other/85716] New: No easy way for end-user to tell what GCC is doing when compilation is slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716 Bug ID: 85716 Summary: No easy way for end-user to tell what GCC is doing when compilation is slow Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- From #gcc on freenode: Hi, I just refactored some of my code and now gcc won't finish compiling and grows in memory size (18gig so far after 30 minutes) and I would like to know what it is doing there. Likely something is going on with some template instantiations or so, is there any sane debugging option that will tell what it does on a somewhat high level while going along? * PlasmaHH_ is now known as PlasmaHH PlasmaHH: -ftime-report would probably be the first thing to try dmalcolm: those seem to output only something after they are done, which doesn't seem to finish. at least it doesn't output anything here. hmmm maybe -Q then dmalcolm: I was afraid you come up with that, its tons of information and all on one line ^^ which is why I was looking for a somewhat abstract level... but guess there isn't much then... PlasmaHH: maybe there is something, and I'm just not thinking of it. Seems to me like a valid thing to be able to "ask the compiler" about. dmalcolm: maybe that giant amount of (to me) unreadable output of -Q is just a consequence of something going wrong... PlasmaHH: if there were linebreaks, would it be more readable? (my job is improving GCC usability, so it's a serious question) dmalcolm: definetly. since it seems to output every function... I tried to split on ) but thats not too good for when there is a ) in the function signature or so PlasmaHH: I think I'll open a BZ about this for GCC 9; it seems like there's room for improvement here most of the part (where things get wrong) seem to be really weird, probably functors being passed to functors ad inf. so if they were on one line I could much easier see that its indeed one big functor, at the moment its just a big mess :/ taking things apart a bit the signature of one function is so far mentioned 184049 times in that -Q dump, possibly at various recursion depths that doesnt sound good perhaps a infinite recursion bug, or perhaps some kind of exponential template expansion? As noted above, I'm capturing this in BZ as it seems like there's room for improvement here. Am I missing something, or is there no "easy" way (for some definition of "easy") for an end-user to track what GCC is doing during a very long compile? Some "brainstorm"-ish ideas: Should -Q add newlines? Maybe with timestamps? Maybe a option to have some kind of timestamp-based logging, emitting a series of lines of the form: [TIMESTAMP] Doing something perhaps piggy-backing off of the timevar hooks, so that if something within GCC goes off into the weeds, the user can see e.g. which function it's having trouble with.
[Bug other/85716] No easy way for end-user to tell what GCC is doing when compilation is slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716 David Malcolm changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Target Milestone|--- |9.0
[Bug tree-optimization/85699] [9 regression] gcc.dg/nextafter-2.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85699 --- Comment #4 from Andrey Guskov --- Jakub, here is the requested output: bug at 136 aa == -3.36210314311209350626267781732175260e-4932L / 4.0L + 3.64519953188247460252840593361941982e-4951L bug at 145 aa == -3.36210314311209350626267781732175260e-4932L / 4.0L + 3.64519953188247460252840593361941982e-4951L
[Bug c++/85717] New: anonymous union in initializer list : do not handle the types correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85717
Bug ID: 85717
Summary: anonymous union in initializer list : do not handle
the types correctly
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daffra.claudio at gmail dot com
Target Milestone: ---
Created attachment 44100
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44100&action=edit
anonymous union in initializer list : do not handle the types correctly
anonymous union in initializer list : do not handle the types correctly
when i use initializer list in anonyumouse union, g++ gives this error code
more or less i expected;
C:\prj\cd>g++ src\prova.cpp -o prova.exe -std=c++14
src\prova.cpp: In function 'int main()':
src\prova.cpp:31:5: error: narrowing conversion of
'3.3999e+0' from 'double' to 'uint64_t {aka long long unsigned
int}' inside { } [-Wnarrowing]
t1 = { 1 ,"a",3.4 } ;
^
indeed in a normal way, code below all works o perfectly
t1.real = 6.6 ;
std::cout << t1.real << "\n" ;
t1.integer = 3 ;
std::cout << t1.integer << "\n" ;
despite result change if i swith union member
union {
uint64_tinteger ;
double real;
} ;
i put
union {
double real;
uint64_tinteger ;
} ;
source code error
#include
#include
#include
#include
#include
typedef struct token_s
{
uint8_t sym ;
std::string tok ;
union {
double real;
uint64_tinteger ;
} ;
} token_t ;
int main ( void )
{
assert ( sizeof(uint64_t)==sizeof(double) ) ;
token_t t1 ;
t1.real = 6.6 ;
std::cout << t1.real << "\n" ;
t1.integer = 3 ;
std::cout << t1.integer << "\n" ;
t1 = { 1 ,"a",3.4 } ;
std::cout << t1.real << "\n" ;
t1 = { 1 ,"a",2 } ;
std::cout << t1.integer << "\n" ;
return 0 ;
}
[Bug c++/85707] -Wclass-memaccess should excempt safe usage inside of a class and its friends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85707
Martin Sebor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |WONTFIX
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
--- Comment #7 from Martin Sebor ---
In the test case, the warning is intended because the access in
HashTable::init_table_memset() bypasses the constructor of the Position class.
If the constructor had other side-effects (e.g., count the number of objects of
the class) bypassing it could violate the invariant (see the example below).
Detecting this sort of a problem is one the design goals of the warning.
To avoid the warning either cast the argument to void* or access the array via
the address of the Position::index member of the first element of the table_
array:
memset (&table_->index, 0xff, sizeof(Position) * _buckets);
Alternatively, suppress the warning via #pragma GCC diagnostic.
$ cat pr85707.C && gcc -O2 -S -Wall pr85707.C
struct S
{
static int count;
int i;
S () {
++count;
__builtin_memset (this, 0, sizeof *this);
}
~S () { --count; }
void f () { __builtin_memset (this, 0, sizeof *this); } // no warning (see
pr84850)
void g (S *p) {
__builtin_memset (p, 0, sizeof *p); // -Wclass-memaccess
}
};
pr85707.C: In member function ‘void S::g(S*)’:
pr85707.C:17:38: warning: ‘void* __builtin_memset(void*, int, long unsigned
int)’ clearing an object of non-trivial type ‘struct S’; use assignment or
value-initialization instead [-Wclass-memaccess]
__builtin_memset (p, 0, sizeof *p); // -Wclass-memaccess
^
pr85707.C:1:8: note: ‘struct S’ declared here
struct S
^
As a side note, in the solution added for pr84850, -Wclass-memaccess was
relaxed to avoid triggering for raw memory accesses to *this in non-static
member functions of non-nontrivial classes with no non-trivial members. It was
a deliberate decision to avoid applying the solution to accesses to objects
other than *this.
[Bug other/85716] No easy way for end-user to tell what GCC is doing when compilation is slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716 --- Comment #1 from David Malcolm --- Another idea: maybe reuse the hierarchical logging support from libgccjit? (possibly with an option to add timestamps or somesuch). See: https://gcc.gnu.org/onlinedocs/jit/internals/index.html#example-of-log-file
[Bug other/85716] No easy way for end-user to tell what GCC is doing when compilation is slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716 --- Comment #2 from David Malcolm --- (or indeed, showing GGC usage)
[Bug c++/85718] New: Incorrect name mangling for va_list on mipsel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85718
Bug ID: 85718
Summary: Incorrect name mangling for va_list on mipsel
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roliver at roku dot com
Target Milestone: ---
#include
extern void log(char const* fmt, ...);
extern void log(char const* fmt, va_list args);
int main() {
int i = 5;
log("Location of i: %p", &i);
return 0;
}
On mipsel, 'log(char const* fmt, va_list args)' is incorrectly mangled to
_Z3logPKcPv rather than _Z3logPKcSt9__va_list which is used on other platforms.
In the above example, code is incorrectly generated to call _Z3logPKcPv on
mipsel whereas the correct code to call _Z3logPKcz is generated on other
platforms. (i.e. the generated code attempts to call the 'va_list'
implementation rather than '...').
[Bug libgomp/82901] GOACC_declare calls GOACC_enter_exit_data with async arg 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82901 --- Comment #3 from Tom de Vries --- Author: vries Date: Wed May 9 16:01:30 2018 New Revision: 260085 URL: https://gcc.gnu.org/viewcvs?rev=260085&root=gcc&view=rev Log: [openacc, libgomp] Use GOMP_ASYNC_SYNC in GOACC_declare 2018-05-09 Tom de Vries PR libgomp/82901 * oacc-parallel.c (GOACC_declare): Use GOMP_ASYNC_SYNC as async argument to GOACC_enter_exit_data. Modified: trunk/libgomp/ChangeLog trunk/libgomp/oacc-parallel.c
[Bug libgomp/82901] GOACC_declare calls GOACC_enter_exit_data with async arg 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82901 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #4 from Tom de Vries --- marking resolved-fixed.
[Bug c++/85707] -Wclass-memaccess should excempt safe usage inside of a class and its friends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85707 --- Comment #8 from Mathias Stearn --- > If the constructor had other side-effects (e.g., count > the number of objects of the class) bypassing it could > violate the invariant. I thought one of the points of friendship was to allow friends to violate a class's invariants temporarily as long as they promise that the class is left in a valid state in the end. Since presumably a class and its friends are maintained by the same people, they are aware of what the actual requirements of the class are, even if they can't be stated precisely in the language today.
[Bug c++/85713] [9 Regression] ICE in dependent_type_p, at cp/pt.c:24582 on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85713 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|paolo.carlini at oracle dot com| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #1 from Paolo Carlini --- Too bad. Anyway, c++/84588 is just a minor error-recovery issue, thus for now I'm simply reverting the commit.
[Bug lto/83201] [7/8 Regression] SPEC CPU2017 505.mcf_r produces incorrect output when built with -flto and FDO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83201 john henning changed: What|Removed |Added CC||mailboxnotfound at yahoo dot com --- Comment #21 from john henning --- Comments from SPEC CPU Documentation Guy: As described at https://www.spec.org/cpu2017/Docs/faq.html#Miscompare.07 https://www.spec.org/cpu2017/Docs/benchmarks/505.mcf_r.html#Portability SPEC's recommendation is to use -fno-strict-aliasing The patch attached to this bug is not approved by SPEC. SPEC generally does not change benchmarks after release (no moving targets); more detail is at the above links. John Henning SPEC CPU Subcommittee Secretary
[Bug c++/85718] Incorrect name mangling for va_list on mipsel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85718
luke at diamand dot org changed:
What|Removed |Added
CC||luke at diamand dot org
--- Comment #1 from luke at diamand dot org ---
You can also see the problem with this code:
#include
void log(char const *fmt, void *foo)
{
}
void log(char const *fmt, va_list args)
{
}
With the v8 compiler I get this:
mipsel-linux-gnu-g++-8 -std=c++14 -Wall -c bar.cpp
bar.cpp:8:6: error: redefinition of ‘void log(const char*, va_list)’
void log(char const *fmt, va_list args)
^~~
bar.cpp:4:6: note: ‘void log(const char*, void*)’ previously defined here
void log(char const *fmt, void *foo)
^~~
With a non-MIPS compiler it compiles just fine.
[Bug c++/85713] [9 Regression] ICE in dependent_type_p, at cp/pt.c:24582 on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85713 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed May 9 16:17:36 2018 New Revision: 260086 URL: https://gcc.gnu.org/viewcvs?rev=260086&root=gcc&view=rev Log: /cp 2018-05-09 Paolo Carlini PR c++/85713 Revert: 2018-05-08 Paolo Carlini PR c++/84588 * parser.c (cp_parser_parameter_declaration_list): When the entire parameter-declaration-list is erroneous maybe call abort_fully_implicit_template. /testsuite 2018-05-09 Paolo Carlini PR c++/85713 Revert: 2018-05-08 Paolo Carlini PR c++/84588 * g++.dg/cpp1y/pr84588.C: New. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp1y/pr84588.C
[Bug c++/84588] [8 Regression] internal compiler error: Segmentation fault (contains_struct_check())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84588 --- Comment #8 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed May 9 16:17:36 2018 New Revision: 260086 URL: https://gcc.gnu.org/viewcvs?rev=260086&root=gcc&view=rev Log: /cp 2018-05-09 Paolo Carlini PR c++/85713 Revert: 2018-05-08 Paolo Carlini PR c++/84588 * parser.c (cp_parser_parameter_declaration_list): When the entire parameter-declaration-list is erroneous maybe call abort_fully_implicit_template. /testsuite 2018-05-09 Paolo Carlini PR c++/85713 Revert: 2018-05-08 Paolo Carlini PR c++/84588 * g++.dg/cpp1y/pr84588.C: New. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp1y/pr84588.C
[Bug c++/85713] [9 Regression] ICE in dependent_type_p, at cp/pt.c:24582 on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85713 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #3 from Paolo Carlini --- Done.
[Bug c++/85713] [9 Regression] ICE in dependent_type_p, at cp/pt.c:24582 on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85713 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |9.0 paolo at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |--- Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|9.0 |--- --- Comment #3 from Paolo Carlini --- Done. --- Comment #4 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed May 9 16:19:09 2018 New Revision: 260087 URL: https://gcc.gnu.org/viewcvs?rev=260087&root=gcc&view=rev Log: /cp 2018-05-09 Paolo Carlini PR c++/85713 Revert: 2018-05-08 Paolo Carlini PR c++/84588 * parser.c (cp_parser_parameter_declaration_list): When the entire parameter-declaration-list is erroneous maybe call abort_fully_implicit_template. /testsuite 2018-05-09 Paolo Carlini PR c++/85713 Revert: 2018-05-08 Paolo Carlini PR c++/84588 * g++.dg/cpp1y/pr84588.C: New. Removed: trunk/gcc/testsuite/g++.dg/cpp1y/pr84588.C
[Bug c++/84588] [8 Regression] internal compiler error: Segmentation fault (contains_struct_check())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84588 --- Comment #9 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed May 9 16:19:09 2018 New Revision: 260087 URL: https://gcc.gnu.org/viewcvs?rev=260087&root=gcc&view=rev Log: /cp 2018-05-09 Paolo Carlini PR c++/85713 Revert: 2018-05-08 Paolo Carlini PR c++/84588 * parser.c (cp_parser_parameter_declaration_list): When the entire parameter-declaration-list is erroneous maybe call abort_fully_implicit_template. /testsuite 2018-05-09 Paolo Carlini PR c++/85713 Revert: 2018-05-08 Paolo Carlini PR c++/84588 * g++.dg/cpp1y/pr84588.C: New. Removed: trunk/gcc/testsuite/g++.dg/cpp1y/pr84588.C
[Bug c++/84588] [8/9 Regression] internal compiler error: Segmentation fault (contains_struct_check())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84588 Paolo Carlini changed: What|Removed |Added Summary|[8 Regression] internal |[8/9 Regression] internal |compiler error: |compiler error: |Segmentation fault |Segmentation fault |(contains_struct_check()) |(contains_struct_check()) --- Comment #10 from Paolo Carlini --- Reverted for now the fix, caused c++/85713.
[Bug c++/85718] Incorrect name mangling for va_list on mipsel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85718 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-05-09 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- That suggests that va_list is void* for MIPS, which is a valid implementation because the type of va_list is unspecified. Assuming that va_list will be the same type across all targets (and therefore that functions taking va_list will always have the same mangled name) is a bad assumption. But we need preprocessed source as requested by https://gcc.gnu.org/bugs/
[Bug c++/85713] [9 Regression] ICE in dependent_type_p, at cp/pt.c:24582 on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85713 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #5 from Paolo Carlini --- .
[Bug target/85718] Incorrect name mangling for va_list on mipsel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85718 --- Comment #3 from Andreas Schwab --- See gcc/config/mips/mips.c:mips_build_builtin_va_list. va_list is a simple void* unless compiling for EABI.
[Bug target/85718] Incorrect name mangling for va_list on mipsel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85718 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Jonathan Wakely --- So then this behaviour is correct and working as intended.
[Bug target/85719] New: Unclear docs for AVR io attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85719 Bug ID: 85719 Summary: Unclear docs for AVR io attribute Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- Target: avr-*-* https://gcc.gnu.org/onlinedocs/gcc/AVR-Variable-Attributes.html#index-io-variable-attribute_002c-AVR says "The address specified in the address in the data address range." What is this supposed to mean? Is it stating a requirement that users must meet? Also the grammar in the next paragraph should be fixed: "Otherwise, the variable it is not assigned an address,"
[Bug middle-end/85599] Function need not be evaluated in logical expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599 --- Comment #15 from Steve Kargl --- On Wed, May 09, 2018 at 10:25:59AM +, janus at gcc dot gnu.org wrote: > > --- Comment #14 from janus at gcc dot gnu.org --- > (In reply to Dominique d'Humieres from comment #10) > > Am I mistaken to read this as being handled by the middle-end? > > The short-circuiting is finally handled by the middle end, since the front end > translates .and. into &&. See also comment 6. > > Apparently the standard does neither require nor forbid the short-circuiting > (see c.l.f. discussion), but I would argue that it would be a more reasonable > for gfortran to avoid the short-circuiting (by translating to &), at least if > it is not clear whether the function has side effects. > To be clear. 1) Are you proposing that .AND. should be special-cased to force evaluation of both operands? 2) Are you proposing that the operands in rational expressions must be evaluated? 3) Are you proposing that the operands for all operators must be evaluated? If the answer to any of the above is 'yes', then add a new option -fno-short-circuit and implement it to transform result = op1 binop op2 into tmp1 = op1 tmp2 = op2 result = tmp1 BINOP tmp2 where BINOP differs from binop in that it knows tmp1 and tmp2 have been evaluated. To be completely symmetric, you'll need a similar treatment for unary operators. That is result = unop op1 becomes tmp1 = op1 result = UNOP tmp1 The flow of the compiler would then be parse code if (no short circuit) then walk expression trees forcing evaulation of all operands else front optimize pass (walk expression trees) end if Give everything to middle-end Seems like a good method to pessimize performance.
[Bug c/82967] "did you mean" suggestions are way too suggestive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82967
--- Comment #3 from David Malcolm ---
Another example:
ia3230612.c:4:41: error: '__i386__' undeclared here (not in a function); did
you mean '__DATE__'?
&& sizeof (long) == 4 ? 1 : -1] = { __i386__ };
^~~~
__DATE__
[Bug c/82967] "did you mean" suggestions are way too suggestive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82967 David Malcolm changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=69968 --- Comment #4 from David Malcolm --- Note that this could well interact with PR 69968 (use of Damerau-Levenshtein, rather than Levenshtein for edit distance): allowing transpositions will make some distances shorter. For the __i386__ vs __DATE__ case, maybe we should detect leading/trailing underscores and ignore them when computing if the edit distance is reasonable. It's an edit distance of 4 (4 substitutions) on a length of 8, but perhaps the effective length should be 4 (ignoring the underscores)?
[Bug c++/85707] -Wclass-memaccess should excempt safe usage inside of a class and its friends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85707 --- Comment #9 from Martin Sebor --- The purpose of friendship is to grant access to class members that would otherwise be inaccessible. The purpose of constructors is to establish class invariants, and it is the responsibility of member functions and friends to maintain them. There can certainly be implementation-only functions that need to temporarily break invariants and HashTable::init_table_memset() could be viewed as one, but those are the exceptions to the rule. The goal of the warning is to help detect likely coding mistakes. In some cases, it's impossible to reliably distinguish these from carefully crafted code that is actually safe. It's a judgment call whether to err on the side of false positives or false negatives. I think the MongoDB use cases are sufficiently rare and specialized that warning for them is acceptable even though the code is safe. The warnings are easy to avoid, either by following the suggestions, or by suppressing it by one of the techniques I mentioned. This might even provide an opportunity to improve the code. Expert programmers should have no problem with that. Relaxing the warning, on the other hand, would compromise its goal at the expense of less experienced or less careful programmers. As an aside, using assignment and copy constructors should be at least as efficient as calling memset and memcpy, and ideally more, and they should always be preferred over the raw memory functions. If/where they aren't as efficient please open bugs for missing optimizations.
[Bug other/85716] No easy way for end-user to tell what GCC is doing when compilation is slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716 --- Comment #3 from David Malcolm --- More from #gcc on freenode: dmalcolm - A flag to have gcc spit out what it's doing on long-runnign compiles would be immensely useful! I'm still trying to debug compile runs with checking=all running incredibly slowly, and haven't been able to bifurcate a particular test yet. ...perhaps a flag to echo the checking in progress and statistics as it runs? [...reference to this PR...] I think the timestamp logging would be great, as well as a marker for transitions between compilation phases. TemptorSent: OK if I paste this IRC log into that BZ, or do you want to add a comment to it? also, do you need absolute timestamps, or is relative-to-start-of-cc1 ok? (I was just going to use relative to start of cc1) (or cc1plus, whatever) Relative should be fine, although tagging the start time with the absolute time may be useful.
[Bug go/82131] FAIL: TestCgoCallbackGC in gotools testsuite; segfaults in morestack.S:529
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82131 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Uroš Bizjak --- The segfault is gone with the latest gcc-9.
[Bug other/85716] No easy way for end-user to tell what GCC is doing when compilation is slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716 --- Comment #4 from David Malcolm --- Also, I'm not sure if it's available, but if we could print the parent process and commandline passed at the beginning of an error report, and tag the output for the error report with the PIDs, it would make tracking things in parallel builds much easier.
[Bug c++/85720] New: bad codegen for looped assignment of primitives at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85720
Bug ID: 85720
Summary: bad codegen for looped assignment of primitives at -O2
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/g/qp19Cv
using SIZE_T = decltype(sizeof(0));
void fill(char* p, SIZE_T n) {
for (SIZE_T i = 0; i < n; i++){
p[i] = -1;
}
}
fill(char*, unsigned long):
testrsi, rsi
je .L1
add rsi, rdi
.L3:
mov BYTE PTR [rdi], -1
add rdi, 1
cmp rdi, rsi
jne .L3
.L1:
ret
At -O3 it basically just tail-calls memset.
Also applies to other types than char, but char is most egregious.
This ticket is spun out of from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85707
