[Bug target/102255] target uses STABS by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102255 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:0458154caafc5438cecf1db8cf96076e384244ab commit r12-3436-g0458154caafc5438cecf1db8cf96076e384244ab Author: Richard Biener Date: Thu Sep 9 15:08:22 2021 +0200 Remove dbx.h, do not set PREFERRED_DEBUGGING_TYPE from dbxcoff.h, lynx.h The following removes the unused config/dbx.h file and removes the setting of PREFERRED_DEBUGGING_TYPE from dbxcoff.h which is overridden by all users (djgpp/mingw/cygwin) via either including config/i386/djgpp.h or config/i386/cygming.h There are still circumstances where mingw and cygwin default to STABS, namely when HAVE_GAS_PE_SECREL32_RELOC is not defined and the target defaults to 32bit code generation. The new style handling DBX_DEBUGGING_INFO is in line with dbxelf.h which does not define PREFERRED_DEBUGGING_TYPE either. The patch also removes the PREFERRED_DEBUGGING_TYPE define from lynx.h which always follows elfos.h already defaulting to DWARF, so the comment about STABS being the default is misleading and outdated. 2021-09-09 Richard Biener PR target/102255 * config/dbx.h: Remove. * config/dbxcoff.h: Do not define PREFERRED_DEBUGGING_TYPE. * config/lynx.h: Likewise.
[Bug rtl-optimization/102254] [12 Regression] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102254 --- Comment #7 from Hongtao.liu --- And here is invalid subreg from general_operand #ifdef INSN_SCHEDULING /* On machines that have insn scheduling, we want all memory reference to be explicit, so outlaw paradoxical SUBREGs. However, we must allow them after reload so that they can get cleaned up by cleanup_subreg_operands. */ if (!reload_completed && MEM_P (sub) && paradoxical_subreg_p (op)) return false; #endif /* Avoid memories with nonzero SUBREG_BYTE, as offsetting the memory may result in incorrect reference. We should simplify all valid subregs of MEM anyway. But allow this after reload because we might be called from cleanup_subreg_operands. ??? This is a kludge. */ if (!reload_completed && maybe_ne (SUBREG_BYTE (op), 0) && MEM_P (sub)) return false; if (REG_P (sub) && REGNO (sub) < FIRST_PSEUDO_REGISTER && !REG_CAN_CHANGE_MODE_P (REGNO (sub), GET_MODE (sub), mode) && GET_MODE_CLASS (GET_MODE (sub)) != MODE_COMPLEX_INT && GET_MODE_CLASS (GET_MODE (sub)) != MODE_COMPLEX_FLOAT /* LRA can generate some invalid SUBREGS just for matched operand reload presentation. LRA needs to treat them as valid. */ && ! LRA_SUBREG_P (op)) return false; /* FLOAT_MODE subregs can't be paradoxical. Combine will occasionally create such rtl, and we must reject it. */ if (SCALAR_FLOAT_MODE_P (GET_MODE (op)) /* LRA can use subreg to store a floating point value in an integer mode. Although the floating point and the integer modes need the same number of hard registers, the size of floating point mode can be less than the integer mode. */ && ! lra_in_progress && paradoxical_subreg_p (op)) return false;
[Bug c++/102257] call of overloaded 'tuple' is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257
--- Comment #3 from 康桓瑋 ---
(In reply to Andrew Pinski from comment #2)
> See https://wg21.link/cwg1228 this might be invalid code and GCC is correct
> in rejecting it.
Maybe. But why does GCC accept the following?
#include
#include
int main() {
std::tuple t{{}, {}};
}
https://godbolt.org/z/ePovjh3fa
[Bug inline-asm/102264] Macro Intrinsics fail to use all the registers on the machine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102264 --- Comment #2 from Nicholai Tukanov --- (In reply to Andrew Pinski from comment #1) > There seems to be some extra moves the register allocator cannot remove and > that is causing some extra spilling. > > Your loop has 32 live variables and that is just at the limit. Can the register allocator be modified to recognize the other registers? The problem seems limited to the compute instruction (vpdpwssd in this case). I specifically choose 32 to max out the registers. Since the compute instruction gets limited to half of that (zmm0-zmm15), the extra moves are killing the performance.
[Bug c/102268] Wrong code with aliasing union pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102268 --- Comment #1 from Davin McCall --- (fails with -O2)
[Bug rtl-optimization/102254] [12 Regression] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102254
--- Comment #6 from Hongtao.liu ---
Another testcase cut from pr102154
#define MODFL __builtin_modfl
void foo() {
long iptrll;
MODFL(0.5l, (long double *));
}
$ ./xgcc -B. pr48641.c -frounding-math -Og -fno-tree-fre
pr48641.c: In function ‘foo’:
pr48641.c:5:1: error: unrecognizable insn:
5 | }
| ^
(insn 5 2 0 2 (set (subreg:TF (reg/v:DI 92 [ iptrll ]) 0)
(const_double:TF 0.0 [0x0.0p+0])) "pr48641.c":4:3 -1
(nil))
during RTL pass: vregs
[Bug c/102268] New: Wrong code with aliasing union pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102268
Bug ID: 102268
Summary: Wrong code with aliasing union pointers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: davmac at davmac dot org
Target Milestone: ---
The following code is adapted from an LLVM PR:
https://bugs.llvm.org/show_bug.cgi?id=34632
The "test" function is called with all three pointers pointing to the same
union object. Note there are only reads from the active union object so this is
not a type-punning issue. I've also changed the original test case to show that
the issue is present even if changing the active union object requires
assignment directly to the corresponding union member, though it's not clear if
this should be necessary.
Runs ok with GCC 9.4; fails with every version since and on trunk.
--- begin ---
struct s1 {unsigned short x;};
struct s2 {unsigned short x;};
union s1s2 { struct s1 v1; struct s2 v2; };
static int read_s1x(struct s1 *p) { return p->x; }
static void write_s2x(struct s2 *p, int v) { p->x=v;}
int test(union s1s2 *p1, union s1s2 *p2, union s1s2 *p3)
{
if (read_s1x(>v1))
{
unsigned short temp;
// Active member is v1, so this is fine:
temp = p3->v1.x;
struct s2 t2 = { temp };
// now change active member to v2, and write to it:
p3->v2 = t2;
write_s2x(>v2,1234);
temp = p3->v2.x;
// now change active member back to v1:
struct s1 t1 = { temp };
p3->v1 = t1;
}
return read_s1x(>v1);
}
int test2(int x)
{
union s1s2 q[2];
struct s1 t1 = { 4321 };
q->v1 = t1; // ensure active member is v1
return test(q,q+x,q+x);
}
int main(void)
{
if(test2(0) == 4321) __builtin_abort();
}
--- end ---
[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID Keywords||GC, ice-on-valid-code --- Comment #19 from Andrew Pinski --- No testcase provided in over 2 years so closing as invalid.
[Bug rtl-optimization/102254] [12 Regression] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102254
--- Comment #5 from Hongtao.liu ---
and also ICE for (subreg:DF(reg:SF)), but ok for (subreg:v2df(reg:SF)0)
void
foo (void)
{
float x;
*((double *) ) = 0;
}
typedef double v2df __attribute__((vector_size(16)));
void
foo1 (v2df a)
{
float x;
*((v2df*) ) = a;
}
[Bug c++/102267] Can't compare pointers to non-specialization instantiated variables during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102267 --- Comment #3 from Andrew Pinski --- Yes the problem is GCC is broken for all comparison of declarations.
[Bug rtl-optimization/102254] [12 Regression] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102254 --- Comment #4 from Hongtao.liu --- Yes, also ICE for x86_64-linux-gnu-gcc
[Bug c++/102267] Can't compare pointers to non-specialization instantiated variables during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102267
Johel Ernesto Guerrero Peña changed:
What|Removed |Added
Summary|Can't compare pointers to |Can't compare pointers to
|instantiated variables |non-specialization
|during constant evaluation |instantiated variables
||during constant evaluation
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICATE |---
--- Comment #2 from Johel Ernesto Guerrero Peña ---
More generally: https://godbolt.org/z/63qoWc1zv.
```C++
template struct x { static constexpr char v{}; };
template<> struct x<2> { static constexpr char v{}; };
template<> struct x<3> { static constexpr char v{}; };
static_assert(<0>::v != <1>::v);
static_assert(<2>::v != <3>::v);
```
```
:4:24: error: non-constant condition for static assertion
4 | static_assert(<0>::v != <1>::v);
| ~^~~
:4:24: error: '((& x<0>::v) != (& x<1>::v))' is not a constant
expression
Compiler returned: 1
```
[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681 Andrew Pinski changed: What|Removed |Added Severity|normal |major
[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681 --- Comment #11 from Andrew Pinski --- *** Bug 102267 has been marked as a duplicate of this bug. ***
[Bug c++/102267] Can't compare pointers to instantiated variables during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102267 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 69681. *** This bug has been marked as a duplicate of bug 69681 ***
[Bug c++/102267] New: Can't compare pointers to instantiated variables during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102267
Bug ID: 102267
Summary: Can't compare pointers to instantiated variables
during constant evaluation
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
Target Milestone: ---
This is specified at https://eel.is/c++draft/expr.eq#3. See
https://godbolt.org/z/n995WdYff.
```C++
template constexpr char v{};
template<> constexpr char v<2>{};
template<> constexpr char v<3>{};
static_assert(<0> != <1>);
static_assert(<2> != <3>);
```
```
:4:21: error: non-constant condition for static assertion
4 | static_assert(<0> != <1>);
| ~~^~~~
:4:21: error: '((& v<0>) != (& v<1>))' is not a constant expression
Compiler returned: 1
```
[Bug c++/58738] forward declaration of function inside function cause link problem with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58738 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=95677 --- Comment #4 from Andrew Pinski --- I suspect maybe r11-3699 fixed this.
[Bug c++/58738] forward declaration of function inside function cause link problem with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58738 Andrew Pinski changed: What|Removed |Added Known to fail||10.1.0, 4.8.1, 9.1.0 Known to work||11.1.0, 12.0 --- Comment #3 from Andrew Pinski --- This seems to have been fixed in GCC 11+.
[Bug target/102211] [12 regression] ICE introduced by r12-3277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102211 --- Comment #7 from Andrew Waterman --- On Tue, Sep 7, 2021 at 10:55 PM wilson at gcc dot gnu.org via Gcc-bugs wrote: > > The hardware may trap if > you access a 32-bit value which is not properly NaN-boxed. I don't think the following affects the resolution of the ticket, but just for the record, trapping is _not_ an option the ISA permits. The only legal outcome from using an improperly NaN-boxed value as an argument to an instruction that requires NaN-boxed inputs is that the canonical NaN is substituted in its place.
Re: [Bug target/102211] [12 regression] ICE introduced by r12-3277
On Tue, Sep 7, 2021 at 10:55 PM wilson at gcc dot gnu.org via Gcc-bugs wrote: > > The hardware may trap if > you access a 32-bit value which is not properly NaN-boxed. I don't think the following affects the resolution of the ticket, but just for the record, trapping is _not_ an option the ISA permits. The only legal outcome from using an improperly NaN-boxed value as an argument to an instruction that requires NaN-boxed inputs is that the canonical NaN is substituted in its place.
[Bug target/102211] [12 regression] ICE introduced by r12-3277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102211
Segher Boessenkool changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org,
||segher at gcc dot gnu.org
--- Comment #6 from Segher Boessenkool ---
(In reply to Jim Wilson from comment #4)
> Yes, moving SI/DI values to FP regs is OK. However, RISC-V requires that FP
> values in FP registers be stored NaN-boxed. So an SFmode value in a 64-bit
> FP reg has the upper 32-bits of all ones, and the lower 32-bits is the
> value. Thus if accessed as a 64-bit value, you get a NaN.
On Power, a (scalar) SF value is usually stored in DF format. It is the insns
that force the outputs to SP, the inputs in general can be anything.
> The hardware may
> trap if you access a 32-bit value which is not properly NaN-boxed.
We used to have such games as well :-) Thankfully it was largely transparent.
> Using
> qemu to check this may not be good enough, as last time I looked at qemu it
> wasn't handling NaN-boxing correctly, but this was over a year ago, so maybe
> it has been fixed since. I don't know.
QEMU in general optimises for speed, not for correct emulation. If you have
inputs that are invalid it will have more surprising outputs.
> This code sequence is not OK
> foo:
> fmv.d.x fa5,a0
> fmul.s fa0,fa0,fa5
> because we are moving a 64-bit DImode value to an FP reg and then treating
> it as SFmode, which is not OK because the value won't be NaN-boxed and may
> trap at run time.
A situation very similar to the Power problem.
> I would think that TARGET_CAN_CHANGE_MODE_CLASS could help here, but it
> isn't being called inside general_operand when called from fwprop1 where the
> bad substitution happens. Because we have a pseudo-register, and it is only
> called for hard registers.
The documentation says
===
@cindex @code{TARGET_CAN_CHANGE_MODE_CLASS} and subreg semantics
The rules above apply to both pseudo @var{reg}s and hard @var{reg}s.
If the semantics are not correct for particular combinations of
@var{m1}, @var{m2} and hard @var{reg}, the target-specific code
must ensure that those combinations are never used. For example:
@smallexample
TARGET_CAN_CHANGE_MODE_CLASS (@var{m2}, @var{m1}, @var{class})
@end smallexample
must be false for every class @var{class} that includes @var{reg}.
===
so the code does not do what the documentation says?
> I don't see a way to fix this as a backend change with current
> validate_subreg, other than by replacing register_operand with
> riscv_register_operand, and putting the subreg check I need inside
> riscv_register_operand. And likewise for any other affected predicate, like
> move_operand. This will be a big change, though a lot of it will be
> mechanical. As an optimization, we can continue to use register_operand in
> any pattern that can't use FP registers.
The first thing that will have to be done is to restore the status quo, to
make your, my, and all other affected targets work again (there very likely
are more, the problems are all in not-so-very normal cases, not to mention
not all targets are tested so heavily -- which reinforces my argument that
there should have been testsuite cases added that trap this on all targets).
After that, yeah, our backends should be improved. That requires some new
stuff in the middle end as well afaics, there really are reasons Power and
RISC-V both did such terrible thing -- but it certainly should not be done
with a knife at the throat, this is some serious re-engineering, it cannot
be done at a snap of the fingers.
> As a middle end change, I need a new hook in general_operand to reject
> subregs that we can't support on RISC-V.
That may be a good design that is suitable for others as well, it is quite
nicely general. Mike, will that do all we need for the SF subregs as well?
A little problem with this is most of our operands do not inherit from
general_operand. A somewhat bigger problem is: what about predicates, do
those not need changes as well, for good machine code quality?
> Or maybe re-add the check I need to validate_subreg as a hook, so it can be
> conditionally enabled for RISC-V.
Yeah... But it should be re-enabled *by default*, to start with.
> We can allow (subreg:SF (reg:DI)) if it gets allocated to an integer
> register. It is only when it is allocated to an FP register that it can't
> work. I don't know offhand if that can be described. But disallowing the
> subreg always for RISC-V is simpler and also works.
(subreg:SF (reg:DI)) does two things at once: an actual subreg, and a bit_cast.
We should not express both of those with the same rtx code, since we do not
allow subregs of subregs (and that is a good thing!)
[Bug c++/38557] dynamic_cast should give a warning/error for non related classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38557 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Severity|normal |enhancement
[Bug libgcc/59714] complex division is surprising on targets with FMA (was: on aarch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714 --- Comment #11 from Patrick McGehearty --- Thanks! On 9/9/2021 5:54 PM, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714 > > --- Comment #10 from Andrew Pinski --- > (In reply to Patrick McGehearty from comment #9) > r12-228-g54f0224d55a1b56dde092460ddf76913670e6efc > > Just making it easier for links here. >
[Bug libgcc/59714] complex division is surprising on targets with FMA (was: on aarch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714 --- Comment #10 from Andrew Pinski --- (In reply to Patrick McGehearty from comment #9) r12-228-g54f0224d55a1b56dde092460ddf76913670e6efc Just making it easier for links here.
[Bug libgcc/59714] complex division is surprising on targets with FMA (was: on aarch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714 Patrick McGehearty changed: What|Removed |Added CC||patrick.mcgehearty at oracle dot c ||om --- Comment #9 from Patrick McGehearty --- The patch 54f0224d55a1b56dde092460ddf76913670e6efc "Practical improvement to libgcc complex divide" made substantial improvements to the algorithms used and thus the accuracy of complex divide for IEEE-754 precisions for half, float, double, and long-double precision. In particular, when examining randomly generated values uniformly distributed over the full exponent range, 2 bit errors dropped from 1.88% to less than one in 10,000. The particular input values discussed in this problem report no longer show any errors whether or not FMA is used. See the patch for more complete details.
[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154 --- Comment #20 from Segher Boessenkool --- (In reply to rguent...@suse.de from comment #18) > So I wonder if it makes sense to allow lowpart subregs of any mode when > the inner mode is integer. We really really really should make a separate bit_cast rtx code. Other than that I agree, yes. But I do fear there will be quite a bit of fallout from that still, albeit less than with the current patch. > There's already > > /* ??? Similarly, e.g. with (subreg:DF (reg:TI)). Though > store_bit_field > is the culprit here, and not the backends. */ > else if (known_ge (osize, regsize) && known_ge (isize, osize)) > ; > > where regsize is REGMODE_NATURAL_SIZE (imode) but with a HFmode > subreg of DImode the known_ge (osize, regsize) doesn't apply > (I wonder what that condition is about - it looks rather arbitrary). Very long ago it made sense to consider quantities greater than "regsize" to take up more than one register. Nowadays we have normal registers bigger than "regsize" (which actually is the size of the mode used).
[Bug target/39549] Nonoptimal byte load. mov (%rdi),%al better then movzbl (%rdi),%eax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39549 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization
[Bug target/102265] s390: Inefficient code for __builtin_ctzll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102265 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug inline-asm/102266] RFE: x86: print operand with optional (%rip) suffix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102266 Andrew Pinski changed: What|Removed |Added Component|c |inline-asm Severity|normal |enhancement
[Bug c/102266] New: RFE: x86: print operand with optional (%rip) suffix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102266 Bug ID: 102266 Summary: RFE: x86: print operand with optional (%rip) suffix Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: hpa at zytor dot com Target Milestone: --- Target: x86 In the Linux kernel we reasonably frequently use extended asm operand modifiers like %P[]/%p[] for encoding a memory operand that *must not* use register-indirect forms. On x86-64, they can sometimes be encoded as %rip-relative, however, there is currently no convenient way for doing so without also making the assembly code x86-64 specific whereas it otherwise would be perfectly fine dual mode. I would therefore like to request one of the following, in order of preference: 1. A modifier to emit a memory immediate operand (i.e. a constant sans $) with a (%rip) suffix assuming it can be so encoded. 2. A simple macro (like %=) that emits (%rip) on x86-64 but nothing on i386. The priority of this is quite low, but it is probably simple to implement.
[Bug inline-asm/102264] Macro Intrinsics fail to use all the registers on the machine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102264 --- Comment #1 from Andrew Pinski --- There seems to be some extra moves the register allocator cannot remove and that is causing some extra spilling. Your loop has 32 live variables and that is just at the limit.
[Bug fortran/100988] Missed optimization: RESTRICT missing for optional arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100988 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-09-09 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug fortran/100988] Missed optimization: RESTRICT missing for optional arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100988 --- Comment #1 from anlauf at gcc dot gnu.org --- *** Bug 53699 has been marked as a duplicate of this bug. ***
[Bug fortran/53699] Missing "restrict" qualifier for OPTIONAL dummy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53699 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from anlauf at gcc dot gnu.org --- PR100988 has a draft patch for the same issue. *** This bug has been marked as a duplicate of bug 100988 ***
[Bug c++/102262] No reason given for constexpr function that uses non-constexpr destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102262
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Seems ensure_literal_type_for_constexpr_object doesn't emit any errors in
instatiations of constexpr functions:
if (CLASS_TYPE_P (stype) && !COMPLETE_TYPE_P (complete_type (stype)))
/* Don't complain here, we'll complain about incompleteness
when we try to initialize the variable. */;
else if (!literal_type_p (type))
{
if (DECL_DECLARED_CONSTEXPR_P (decl))
...
else
{
if (!is_instantiation_of_constexpr (current_function_decl))
{
auto_diagnostic_group d;
error_at (DECL_SOURCE_LOCATION (decl),
"variable %qD of non-literal type %qT in "
"% function", decl, type);
explain_non_literal_class (type);
decl = error_mark_node;
}
cp_function_chain->invalid_constexpr = true;
}
When parsing, this isn't reached because of && !processing_template_decl, and
when it is instantiated, is_instantiation_of_constexpr (current_function_decl)
is true and so it doesn't emit the error, but just sets invalid_constexpr.
[Bug target/102265] New: s390: Inefficient code for __builtin_ctzll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102265
Bug ID: 102265
Summary: s390: Inefficient code for __builtin_ctzll
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
unsigned long long ctzll(unsigned long long x)
{
return __builtin_ctzll(x);
}
creates:
lcgr%r1,%r2
ngr %r2,%r1
lghi%r1,63
flogr %r2,%r2
sgrk%r2,%r1,%r2
lgfr%r2,%r2
br %r14
Optimal sequence for z15 uses population count, for all others use ^ 63 instead
of 63 -.
unsigned long long ctzll_opt(unsigned long long x)
{
#if __ARCH__ >= 13
return __builtin_popcountll((x-1) & ~x);
#else
return __builtin_clzll(x & -x) ^ 63;
#endif
}
< z15:
lcgr%r1,%r2
ngr %r2,%r1
flogr %r2,%r2
xilf%r2,63
lgfr%r2,%r2
br %r14
=> 1 instruction saved.
z15:
.cfi_startproc
lay %r1,-1(%r2)
ncgrk %r2,%r1,%r2
popcnt %r2,%r2,8
br %r14
.cfi_endproc
=> On z15 only 3 instructions required.
[Bug c++/102262] No reason given for constexpr function that uses non-constexpr destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102262
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Simpler testcase, the class doesn't need to be a template, but check does:
struct S
{
constexpr S () { }
~S () { }
};
template
constexpr bool check ()
{
T t;
return true;
}
constexpr bool a = check ();
constexpr bool check2 ()
{
S s;
return true;
}
constexpr bool b = check2 ();
because check2 is diagnosed properly:
pr102262.C: In function ‘constexpr bool check2()’:
pr102262.C:18:5: error: variable ‘s’ of non-literal type ‘S’ in ‘constexpr’
function
18 | S s;
| ^
pr102262.C:1:8: note: ‘S’ is not literal because:
1 | struct S
|^
pr102262.C:1:8: note: ‘S’ does not have ‘constexpr’ destructor
[Bug c/45464] Warning missing using -Wall when comparing unsigned int and sum of unsigned chars.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45464 --- Comment #3 from Andrew Pinski --- Actually I think only the warning for the three add case is wrong and here is why: adding two (unsigned) 8bit integers together will only give you a max a 9bit integer. so comparing b and (a+a) is fine Adding three 8bit (unsigned) integers together will give a 10bit integer. It just happens GCC can figure out the first case of adding two 8bit integers will not change value for signed vs unsigned while adding the third add, for the warning, gcc does not figure that out.
[Bug inline-asm/102264] New: Macro Intrinsics fail to use all the registers on the machine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102264 Bug ID: 102264 Summary: Macro Intrinsics fail to use all the registers on the machine Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm Assignee: unassigned at gcc dot gnu.org Reporter: ntukanov at cmu dot edu Target Milestone: --- I am trying to use custom intrinsics in order to have more control over the assembly that the compiler is generating. The concept of these custom intrinsics comes from http://users.ece.cmu.edu/~franzf/papers/wpmvp16.pdf. For performance reasons, my code requires me to use all the available SIMD registers on the machine, but when I use my custom intrinsics, I am only getting half of the SIMD registers which leads to register spilling. This is the code and generated assembly in question: https://godbolt.org/z/fqn53G9qT Any help would be greatly appericated.
[Bug c++/102257] call of overloaded 'tuple' is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257 --- Comment #2 from Andrew Pinski --- See https://wg21.link/cwg1228 this might be invalid code and GCC is correct in rejecting it.
[Bug c++/102247] Overload resolution with brace-init is ambiguous when it shouldn't be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102247 --- Comment #4 from TC --- See also PR 60027 and its duplicates.
[Bug c++/90284] -Wunused-value points to the wrong expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90284
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #2 from Andrew Pinski ---
Testcase:
int incorrect_warning()
{
return (0 ? 0 : 0, 999);
}
int correct_warning()
{
return (0, 999);
}
[Bug c++/102247] Overload resolution with brace-init is ambiguous when it shouldn't be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102247 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=70637 --- Comment #3 from Andrew Pinski --- This looks almost exactly the same as PR 70637.
[Bug libstdc++/102259] ifstream::read(…, count) fails when count >= 2^31 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259 --- Comment #1 from Jonathan Wakely --- Well it works fine on other systems, which is probably why nobody noticed it. I have no way to debug this.
[Bug c++/87814] [9 Regression] ICE in in tsubst_copy, at cp/pt.c:15962 with range-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87814 Andrew Pinski changed: What|Removed |Added CC||tower120 at gmail dot com --- Comment #13 from Andrew Pinski --- *** Bug 86574 has been marked as a duplicate of this bug. ***
[Bug c++/86574] ICE on std::prev with ranges::view::transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86574 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Andrew Pinski --- Dup of bug 87814. Fixed in GCC 9. *** This bug has been marked as a duplicate of bug 87814 ***
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED Keywords||wrong-code --- Comment #12 from anlauf at gcc dot gnu.org --- Here's the mail to the ML: https://gcc.gnu.org/pipermail/fortran/2021-September/056494.html Unless there is fallout, I'll see if this can be backported to open branches.
[Bug target/102239] powerpc suboptimal boolean test of contiguous bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2021-09-09 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Segher Boessenkool --- Confirmed. So the relevant insn (parallel [(set (reg:CC 123) (compare:CC (and:DI (reg:DI 124) (const_int 25769803776 [0x6])) (const_int 0 [0]))) (clobber (scratch:DI))]) is matched by *and3_2insn but not by any pattern that ends up as just one insn. Not *and3_mask_dot, because that doesn't do a shift first, is just an AND and there are no machine insns to do that; but there is no pattern for what we can do. *rotl3_mask_dot cannot do this either; the base and the dot2 of that cannot be done, they return a shifted result, but that doesn't matter for comparing it to 0. So we should add a specialised version.
[Bug c++/102258] dynamic_cast to derived type fails during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102258 --- Comment #2 from Johel Ernesto Guerrero Peña --- That still doesn't work because you can't compare (the addresses of) different `std::type_info` objects.
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490 --- Comment #11 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:5fe0865ab788bdc387b284a3ad57e5a95a767b18 commit r12-3432-g5fe0865ab788bdc387b284a3ad57e5a95a767b18 Author: Harald Anlauf Date: Thu Sep 9 21:34:01 2021 +0200 Fortran - out of bounds in array constructor with implied do loop gcc/fortran/ChangeLog: PR fortran/98490 * trans-expr.c (gfc_conv_substring): Do not generate substring bounds check for implied do loop index variable before it actually becomes defined. gcc/testsuite/ChangeLog: PR fortran/98490 * gfortran.dg/bounds_check_23.f90: New test.
[Bug target/102250] [11/12 Regression] python is not documented as a Prerequisite for building for riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102250 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #3 from Jim Wilson --- There is no python requirement for building a riscv linux compiler. It is only needed if the user specifies the optional --with-arch configure option, and if the user specifies a non-canonical form of the architecture string in the --with-arch option string. Otherwise gcc will build fine without python. A later patch fixed this to check for python before using it, after Andreas Schwab complained about this.
[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #19 from seurer at gcc dot gnu.org ---
This also prevents gcc from being built if it includes go on powerpc LE:
libtool: compile: /home/seurer/gcc/git/build/gcc-test/./gcc/gccgo
-B/home/seurer/gcc/git/build/gcc-test/./gcc/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
-O2 -g -I . -c -fgo-pkgpath=strconv
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/atob.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/atoc.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/atoi.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/bytealg.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/ctoa.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/decimal.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/doc.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/eisel_lemire.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/ftoa.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/ftoaryu.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/isprint.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/itoa.go
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/quote.go -fPIC -o
.libs/strconv.o
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go: In function
'strconv.parseFloatPrefix':
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go:704:1: error:
unrecognizable insn:
704 | func parseFloatPrefix(s string, bitSize int) (float64, int, error) {
| ^
(insn 351 350 352 35 (set (reg:SF 219 [ SR.5776 ])
(subreg:SF (reg:DI 237 [ GOTMP.360 ]) 0))
"/home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go":601:15 -1
(nil))
during RTL pass: vregs
/home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go:704:1: internal compiler
error: in extract_insn, at recog.c:2769
0x102b46d3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/seurer/gcc/git/gcc-test/gcc/rtl-error.c:108
0x102b4723 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/seurer/gcc/git/gcc-test/gcc/rtl-error.c:116
0x10afebe7 extract_insn(rtx_insn*)
/home/seurer/gcc/git/gcc-test/gcc/recog.c:2769
0x1070e8f7 instantiate_virtual_regs_in_insn
/home/seurer/gcc/git/gcc-test/gcc/function.c:1611
0x1070e8f7 instantiate_virtual_regs
/home/seurer/gcc/git/gcc-test/gcc/function.c:1985
0x1070e8f7 execute
/home/seurer/gcc/git/gcc-test/gcc/function.c:2034
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED CC||anlauf at gcc dot gnu.org Status|WAITING |RESOLVED --- Comment #30 from anlauf at gcc dot gnu.org --- Thanks for the confirmation! Closing.
[Bug c++/102263] New: Requesting enhanced warning on returning pointer/reference to local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102263
Bug ID: 102263
Summary: Requesting enhanced warning on returning
pointer/reference to local
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
gcc (and clang) both warn on both of these functions:
int* a() {
int i = 0;
return
}
int& b() {
int i = 0;
return i;
}
Which is great. Both of these functions are bad. However, add an extra layer:
struct Ptr { int* p; };
struct Ref { int& r; };
Ptr c() {
int i = 0;
return Ptr{.p=};
}
Ref d() {
int i = 0;
return Ref{.r=i};
}
And now gcc (nor clang) warn on either of these two functions. But 'c' and 'd'
are just as much returning a pointer/reference to a local variable as 'a' and
'b' are, and it would be extremely helpful to warn on these cases.
More motivating example from C++20 would be something like this (which came up
in discussion of P2415):
std::vector get_ints();
auto doubled_ints() {
auto ints = get_ints();
return ints | std::views::transform([](int i){ return i * 2; });
}
This is returning an object that has a member that has a member that has a
pointer to a local variable. Which is bad, this dangles! It would be super cool
if such a function got a warning slapped onto it.
[Bug c++/102262] No reason given for constexpr function that uses non-constexpr destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102262 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-09-09 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. Interesting only MSVC provides the reason: (15): error C2131: expression did not evaluate to a constant (11): note: failure was caused by call of undefined function or one not declared 'constexpr' (11): note: see usage of 'foo::~foo' clang does not either: :15:16: error: static_assert expression is not an integral constant expression static_assert( check>() ); ^ :11:5: note: non-literal type 'foo' cannot be used in a constant expression T t; ^ :15:16: note: in call to 'check()' static_assert( check>() ); ^ Nor EDG (ICC): (15): error: expression must have a constant value static_assert( check>() ); ^ (15): note: cannot call non-constexpr function "check() [with T=foo]" (declared at line 9) static_assert( check>() ); ^
[Bug c++/102257] call of overloaded 'tuple' is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=102247
--- Comment #1 from Andrew Pinski ---
Take:
#include
#include
int main() {
std::tuple t{{}, 0};
}
- CUT
GCC does reject this though with the following error message:
: In function 'int main()':
:6:44: error: converting to 'std::allocator_arg_t' from initializer
list would use explicit constructor 'constexpr
std::allocator_arg_t::allocator_arg_t()'
6 | std::tuple t{{}, 0};
|^
So the question becomese does the conversion happen while chosing the overload
for the tuple constructor?
Looks like GCC is the only one which rejects this as being ambiguous too.
I did try:
struct tag{};
struct alloc {explicit alloc(int){};};
template
struct tuple {
tuple(tag, const alloc&);
tuple(const T1&, const T2&);
};
class t2{};
tuple tt{{},0};
and GCC accepts this so is suprising based on the error message of the other
one.
Also you don't need std::string, a simple class like this will fail:
#include
class t2{};
int main() {
std::tuple t{{}, 0};
}
[Bug c++/102258] dynamic_cast to derived type fails during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102258
--- Comment #1 from Johel Ernesto Guerrero Peña ---
Workaround for my use-case: https://godbolt.org/z/5Woe8dvan.
```C++
#include
#include
#include
#include
#include
struct B { virtual ~B() = default; };
struct D : B { int x{1}; constexpr ~D() override { } };
template
requires(
std::is_pointer_v and
not std::is_same_v>,
std::remove_cv_t> and
std::derived_from, Base>)
[[nodiscard]] constexpr auto dynamic_downcast(Base* b)
-> decltype(_cast&>(*b)) {
if (b == nullptr) return nullptr;
if ((*b) == (std::remove_pointer_t&))
return _cast&>(*b);
throw std::bad_cast{};
}
int main() {
[]() consteval {
B* b = new D;
assert(dynamic_downcast(b)->x == 1);
delete b;
}();
}
```
[Bug c++/102262] New: No reason given for constexpr function that uses non-constexpr destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102262
Bug ID: 102262
Summary: No reason given for constexpr function that uses
non-constexpr destructor
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
template
struct foo
{
constexpr foo() { }
~foo() { }
};
template
constexpr bool check()
{
T t;
return true;
}
static_assert( check>() );
The error doesn't tell you what's wrong:
ce.C:15:31: error: non-constant condition for static assertion
15 | static_assert( check>() );
|~~~^~
ce.C:15:31: error: 'constexpr bool check() [with T = foo]' called in a
constant expression
ce.C:9:16: note: 'constexpr bool check() [with T = foo]' is not usable as
a 'constexpr' function because:
9 | constexpr bool check()
|^
The problem is that the destructor is not constexpr.
[Bug c++/102261] New: [12 Regression] ICE: Segmentation fault (in build_this_conversion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102261
Bug ID: 102261
Summary: [12 Regression] ICE: Segmentation fault (in
build_this_conversion)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
g++-12.0.0-alpha20210905 snapshot (g:a827909537cf085e5673ca7816b7bd7151d89fc5)
ICEs when compiling the following testcase, extracted from
gcc/testsuite/gcc.target/i386/pr80173.c:
typedef int V __attribute__ ((vector_size (2 * sizeof (int;
struct U { V a; V b; };
int
bar (int i)
{
register struct U u asm ("xmm7");
u = (struct U) {{-1, 0}, {-1, 0}};
return u.b[i];
}
% x86_64-unknown-linux-gnu-g++-12.0.0 -c lfxfq1vi.cc
lfxfq1vi.cc: In function 'int bar(int)':
lfxfq1vi.cc:9:35: error: address of explicit register variable 'u' requested
9 | u = (struct U) {{-1, 0}, {-1, 0}};
| ^
lfxfq1vi.cc:9:35: internal compiler error: Segmentation fault
0x1143d7f crash_signal
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/toplev.c:328
0x915231 build_this_conversion
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/cp/call.c:2291
0x915e53 add_function_candidate
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/cp/call.c:2464
0x917186 add_candidates
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/cp/call.c:6207
0x92648f add_candidates
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/cp/call.c:6076
0x92648f add_operator_candidates
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/cp/call.c:6361
0x92677e build_new_op_1
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/cp/call.c:6569
0x9275dd build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/cp/call.c:6957
0xb8ceff cp_build_modify_expr(unsigned int, tree_node*, tree_code, tree_node*,
int)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/cp/typeck.c:8936
0xb8d92c build_x_modify_expr(unsigned int, tree_node*, tree_code, tree_node*,
int)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/cp/typeck.c:9201
0xa8595a cp_parser_assignment_expression
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/cp/parser.c:10242
0xa870f2 cp_parser_expression
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/cp/parser.c:10371
0xa8a918 cp_parser_expression_statement
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/cp/parser.c:12564
0xa96d0a cp_parser_statement
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/cp/parser.c:12360
0xa97dcd cp_parser_statement_seq_opt
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/cp/parser.c:12712
0xa97ea8 cp_parser_compound_statement
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/cp/parser.c:12661
0xab86c0 cp_parser_function_body
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/cp/parser.c:24854
0xab86c0 cp_parser_ctor_initializer_opt_and_function_body
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/cp/parser.c:24905
0xab944a cp_parser_function_definition_after_declarator
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/cp/parser.c:31016
0xaba78b cp_parser_function_definition_from_specifiers_and_declarator
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/cp/parser.c:30932
[Bug target/102260] amdgcn offload compiler fails to configure, not matching target directive's target id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102260 Andrew Stubbs changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-09 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |ams at gcc dot gnu.org --- Comment #1 from Andrew Stubbs --- In addition to changing the amdgcn_target syntax in LLVM 13, the LLVM GCN guys have also renamed the "sram-ecc" attribute to "sramecc" on the CLI, and have not provided any backwards compatibility for either change. These are not helpful decisions and will require configure tests in GCC to support all the variations. :-( I'm working on it.
[Bug target/102260] New: amdgcn offload compiler fails to configure, not matching target directive's target id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102260 Bug ID: 102260 Summary: amdgcn offload compiler fails to configure, not matching target directive's target id Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org Target Milestone: --- building the amdgcn offload compiler using the current trunk fails with newer LLVM versions (used as the "binutils). LLVM 9 is known to work, LLVM 10 to 13 don't work, with LLVM 13 bailing outin the libgcc gfx900 configure: configure:3566: /packages/gcc/snap/gcc-snapshot-20210909/build-gcn/./gcc/xgcc -B/packages/gcc/snap/gcc-snapshot-20210909/build-gc n/./gcc/ -nostdinc -B/packages/gcc/snap/gcc-snapshot-20210909/build-gcn/amdgcn-amdhsa/gfx900/newlib/ -isystem /packages/gcc/snap/ gcc-snapshot-20210909/build-gcn/amdgcn-amdhsa/gfx900/newlib/targ-include -isystem /packages/gcc/snap/gcc-snapshot-20210909/src-gc n/newlib/libc/include -B/usr/lib/gcc-snapshot/amdgcn-amdhsa/bin/ -B/usr/lib/gcc-snapshot/amdgcn-amdhsa/lib/ -isystem /usr/lib/gcc -snapshot/amdgcn-amdhsa/include -isystem /usr/lib/gcc-snapshot/amdgcn-amdhsa/sys-include -march=gfx900 -o conftest -g -O2 conf test.c >&5 /tmp/ccuvyB8E.s:1:17: error: .amdgcn_target directive's target id amdgcn-unknown-amdhsa--gfx900 does not match the specified targ et id amdgcn-unknown-amdhsa--gfx900:xnack- .amdgcn_target "amdgcn-unknown-amdhsa--gfx900" ^
[Bug c++/102229] [11/12 Regression] 'decltype(auto)' cannot be cv-qualified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102229 --- Comment #8 from Jason Merrill --- (In reply to Marek Polacek from comment #6) > Thanks. With the latter interpretation in mind, it seems my earlier fix > should be mitigated so that we allow > > constexpr decltype(auto) > but not > constexpr const decltype(auto) > > Yes? I think so, yes. > Do you want me to raise this with the CWG? Please.
[Bug libstdc++/102221] Missed optimizations for algorithms over std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102221
--- Comment #5 from Giuseppe D'Angelo ---
Here's a further testcase that doesn't even use unique_ptr:
#include
#include
using ptr = int *;
using rawptr = int *;
#ifndef RESTRICT
#define RESTRICT
#endif
void swap(ptr & RESTRICT a, ptr & RESTRICT b)
{
if (std::addressof(a) == std::addressof(b))
__builtin_unreachable();
ptr tmp = a; a = nullptr; // ptr tmp = std::move(a)
// a = std::move(b)
#if ONE
{
// a.reset(b.release())
rawptr tmp = b; // b.release()
b = nullptr;
rawptr old = a; // a.reset(tmp)
a = tmp;
delete old;
}
#elif TWO
{
// move+swap
rawptr tmp = b; b = nullptr; // ptr tmp = std::move(b)
{ // a.swap(tmp)
rawptr tmp2 = a;
a = tmp;
tmp = tmp2;
}
// ~tmp
delete tmp;
}
#elif THREE
{
delete a; a = b; b = nullptr;
}
#else
#error
#endif
delete b; b = tmp; tmp = nullptr; // b = std::move(tmp)
delete tmp;
}
https://gcc.godbolt.org/z/bv1T64ndo
ONE and TWO don't elide the delete, unless the arguments are marked
__restrict__. THREE does elide it. Sounds like some escape analysis going
wrong, combined with unique_ptr's self-move-assignment safety (that "bans"
THREE's implementation).
[Bug libstdc++/102259] New: ifstream::read(…, count) fails when count >= 2^31 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259
Bug ID: 102259
Summary: ifstream::read(…, count) fails when count >= 2^31 on
darwin
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mimomorin at gmail dot com
Target Milestone: ---
Created attachment 51431
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51431=edit
Testcase for ifstream::read(…, count >= 2^31)
I tried to read a large file using `ifstream::read` on Mac, but it fails to
read any byte when count >= 2^31. Note that the system is 64-bit and
`std::streamsize` has 8 bytes.
Here is a testcase.
#include
#include
int main() {
std::ifstream is{"2GB.bin", std::ios::binary}; // filesize >= 2^31 bytes
auto buffer = new char[1LL << 31];
is.read(buffer, 1LL << 31);
std::cout << is.good() << " (" << is.gcount() << " bytes)\n";
// Expected output: "1 (2147483648 bytes)"
// Actual output (on Mac): "0 (0 bytes)"
}
My system is macOS 10.15 running on x86_64 Mac. The testcase failed on
Homebrew's GCC (ver. 6, 9, 10, 11) and MacPorts' GCC (ver. 6), but it succeeded
on LLVM Clang (trunk) and Apple Clang (ver. 12).
`ifstream::read(…, count)` works fine when count < 2^31. So if we split
is.read(buffer, 1LL << 31);
into
is.read(buffer, (1LL << 31) - 1);
is.read(buffer + (1LL << 31) - 1, 1);
then everything goes OK.
Additionally, `istringstream::read(…, count >= 2^31)` works fine both on GCC
and Clang.
I don't think this simple issue went unnoticed, so maybe I've missed something.
[Bug c++/102258] New: dynamic_cast to derived type fails during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102258
Bug ID: 102258
Summary: dynamic_cast to derived type fails during constant
evaluation
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/dsEzaxW47.
```C++
struct B { virtual ~B() = default; };
struct D : B { constexpr ~D() override { } };
int main() {
[]() consteval {
B* b = new D;
dynamic_cast(*b);
delete b;
}();
}
```
```
: In function 'int main()':
:8:4: in 'constexpr' expansion of 'main()::().main()::()'
:6:5: error: reference 'dynamic_cast' failed
6 | dynamic_cast(*b);
| ^~~~
:6:5: note: dynamic type 'D [1]' of its operand does not have a base
class of type 'D'
Compiler returned: 1
```
[Bug c++/102229] [11/12 Regression] 'decltype(auto)' cannot be cv-qualified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102229
--- Comment #7 from Net Can ---
here is my use case:
https://github.com/netcan/config-loader/blob/master/include/config-loader/serialize/TypeSerializer.h
the key is
```c++
#define TYPE_SERIALIZER(_type, _typeName) \
struct TypeSerializer \
{ static constexpr decltype(auto) name = _typeName; }
template<> TYPE_SERIALIZER((int8_t), "int8_t"); // (1)
template
TYPE_SERIALIZER((std::vector),
concat("vector<", TypeSerializer::name, ">")); // (2)
```
in case (1), the `name` type is `const char(&)[N]`, but in case(2), the `name`
type is `array[N]`, so I use `decltype(auto)` rather `auto`, becase latter
loses char length info.
I tried `static decltype(auto)` not work because it is defined in class, and
requires `constexpr`.
[Bug c++/102257] New: call of overloaded 'tuple' is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257
Bug ID: 102257
Summary: call of overloaded 'tuple' is ambiguous
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
The following code failed since gcc-11, which seems to be a language bug.
#include
#include
int main() {
std::tuple t{{}, 0};
}
https://godbolt.org/z/qMfhxoss3
[Bug target/102255] target uses STABS by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102255 Richard Biener changed: What|Removed |Added Target|i[34567]86-*-cygwin*, |i[34567]86-*-cygwin*, |x86_64-*-cygwin*, |x86_64-*-cygwin*, |i[34567]86-*-mingw*,|i[34567]86-*-mingw*, |x86_64-*-mingw* |x86_64-*-mingw*, ||i?86-*-darwin* --- Comment #1 from Richard Biener --- i?86-*-darwin* also uses STABS for pre-darwin9 32bit compiles via i386/darwin.h /* Darwin on x86_64 uses dwarf-2 by default. Pre-darwin9 32-bit compiles default to stabs+. darwin9+ defaults to dwarf-2. */ #ifndef DARWIN_PREFER_DWARF #undef PREFERRED_DEBUGGING_TYPE #ifdef HAVE_AS_STABS_DIRECTIVE #define PREFERRED_DEBUGGING_TYPE (TARGET_64BIT ? DWARF2_DEBUG : DBX_DEBUG) #else #define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG #endif #endif but it looks like DARWIN_PREFER_DWARF is always set.
[Bug target/102256] New: target uses STABS by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102256 Bug ID: 102256 Summary: target uses STABS by default Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- The following ELF targets use STABS by default: avr-*-* - through avr/elf.h rx*-* forced through rx/rx.h when TARGET_AS100_SYNTAX
[Bug target/101981] GCC10 produces bigger asm for simple switch than GCC7 - cortexM4 since r8-2701-g9dc3d6a96167b4c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101981
--- Comment #7 from Thibaut M. ---
There are other regressions (in term of code size) but not sure if this is the
same.
For example, this code:
```C
#include
void big_switch(int a) {
switch (a) {
default:
printf("default a(%d)\n", a);
case 0x1:
case 0x2:
// case 0x3:
// case 0x4:
case 0x5:
case 0x6:
// case 0x7:
// case 0x8:
// case 0x9:
case 0xA:
case 0xD:
case 0xE:
case 0xF:
// case 0x10:
case 0x11:
case 0x12:
// case 0x13:
// case 0x14:
case 0x15:
case 0x17:
case 0x18:
case 0x19:
case 0x1A:
// case 0x1B:
case 0x1C:
case 0x1D: {
printf("a(%d)\n", a);
} break;
}
}
int main(void) {
big_switch(2);
return 0;
}
```
with compile parameters `arm-none-eabi-gcc -Os -mcpu=cortex-m4 ./switch.c`
the asm is lighter with GCC7.3.1 than with GCC10.3.1.
While GCC7.3.1 (20 lines)
```asm
8134 :
cmp r0, #29
push{r4, lr}
mov r4, r0
bhi.n 8146
movsr2, #1
ldr r3, [pc, #28] ; (815c )
lslsr2, r0
andsr3, r2
cbnzr3, 814e
mov r1, r4
ldr r0, [pc, #20] ; (8160 )
bl 8264
mov r1, r4
ldr r0, [pc, #16] ; (8164 )
ldmia.w sp!, {r4, lr}
b.w 8264
nop
.word 0x37a6e466
.word 0xf5f8
.word 0xf600
```
GCC10.3.1 (24 lines)
```asm
813c :
subsr3, r0, #1
push{r4, lr}
mov r4, r0
cmp r3, #28
bhi.n 8168
tbb [pc, r3]
.short 0x1313
.word 0x13130f0f
.word 0x130f0f0f
.word 0x13130f0f
.word 0x13130f13
.word 0x0f130f0f
.word 0x13131313
.short 0x130f
.byte 0x13
.byte 0x00
mov r1, r0
ldr r0, [pc, #16] ; (817c )
bl 828c
mov r1, r4
ldr r0, [pc, #8]; (817c )
ldmia.w sp!, {r4, lr}
b.w 828c
.word 0x0001011c
```
Not a big difference in term of instructions is this case but as much as the
switch increases, the difference becomes huge (in my case it switched from 75
to 94 lines)
Code size increases of about 10%.
@Martin, do you know if this is linked?
[Bug target/102255] New: target uses STABS by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102255 Bug ID: 102255 Summary: target uses STABS by default Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- The STABS debugging format is supposed to be deprecated for GCC 12 but these targets still default to it from config.gcc including dbxcoff.h: i[34567]86-*-cygwin* x86_64-*-cygwin* i[34567]86-*-mingw* | x86_64-*-mingw* the configs include i386/cygming.h as well override that with DWARF when #if TARGET_64BIT_DEFAULT || defined (HAVE_GAS_PE_SECREL32_RELOC) the HAVE_GAS_PE_SECREL32_RELOC define/check is from 2004 it seems that's old enough to require. In fact install.texi suggests 2.20 is the minimal supported version for cygwin, mingw does not document any required version. I'm inclined to diff --git a/gcc/config/dbxcoff.h b/gcc/config/dbxcoff.h index d491cff961f..bd705f93711 100644 --- a/gcc/config/dbxcoff.h +++ b/gcc/config/dbxcoff.h @@ -25,12 +25,6 @@ along with GCC; see the file COPYING3. If not see #define DBX_DEBUGGING_INFO 1 -/* Generate DBX debugging information by default. */ - -#ifndef PREFERRED_DEBUGGING_TYPE -#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG -#endif - /* Be function-relative for block and source line stab directives. */ #define DBX_BLOCKS_FUNCTION_RELATIVE 1 diff --git a/gcc/config/i386/cygming.h b/gcc/config/i386/cygming.h index ac458cdfee1..e2d759a7572 100644 --- a/gcc/config/i386/cygming.h +++ b/gcc/config/i386/cygming.h @@ -27,7 +27,7 @@ along with GCC; see the file COPYING3. If not see #if (DWARF2_DEBUGGING_INFO) #define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG #else -#define PREFERRED_DEBUGGING_TYPE DBX_DEBUG +#define PREFERRED_DEBUGGING_TYPE NO_DEBUG #endif #undef TARGET_SEH
[Bug rtl-optimization/102254] [12 Regression] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102254 --- Comment #3 from Richard Biener --- (In reply to Jakub Jelinek from comment #2) > And maybe also should throw away (with a warning) or turn into > __builtin_unreachable () during GIMPLE passes. Because it is a clear UB. Yes, a candidate for isolate-paths IMHO. Not sure if it would count as "dereference" and thus applicable at -fisolate-erroneous-paths-dereference.
[Bug c++/102247] Overload resolution with brace-init is ambiguous when it shouldn't be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102247
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #2 from TC ---
struct X { explicit X() {} };
struct Y { Y() {} };
void f(X);
void f(Y);
void g() {
f({}); // GCC rejects, clang accepts
}
GCC is correct. For copy-list-initialization, explicitness of constructor is
not considered in forming implicit conversion sequences; rather, if a explicit
constructor is chosen, the program is ill-formed. See core issue 1228 and
[over.match.list].
[Bug rtl-optimization/102254] [12 Regression] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102254 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- And maybe also should throw away (with a warning) or turn into __builtin_unreachable () during GIMPLE passes. Because it is a clear UB.
[Bug rtl-optimization/102254] [12 Regression] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102254 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 CC||crazylht at gmail dot com --- Comment #1 from Richard Biener --- Likely another fallout of the subreg saga. This is one kind of subreg we probably should continue to disallow (paradoxical float<->int subreg).
[Bug target/102254] New: [12 Regression] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102254
Bug ID: 102254
Summary: [12 Regression] ICE: in extract_insn, at recog.c:2769
(error: unrecognizable insn)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: aarch64-linux-gnu
gcc-12.0.0-alpha20210905 snapshot (g:a827909537cf085e5673ca7816b7bd7151d89fc5)
ICEs when compiling the following testcase w/ -Og:
void
foo (void)
{
int x;
*((double *) ) = 0;
}
% aarch64-linux-gnu-gcc-12.0.0 -Og -c zkc6b9w3.c
zkc6b9w3.c: In function 'foo':
zkc6b9w3.c:7:1: error: unrecognizable insn:
7 | }
| ^
(insn 5 2 0 2 (set (subreg:DF (reg/v:SI 92 [ x ]) 0)
(const_double:DF 0.0 [0x0.0p+0])) "zkc6b9w3.c":6:22 -1
(nil))
during RTL pass: vregs
zkc6b9w3.c:7:1: internal compiler error: in extract_insn, at recog.c:2769
0x75df07 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/rtl-error.c:108
0x75df27 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/rtl-error.c:116
0x75c539 extract_insn(rtx_insn*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/recog.c:2769
0xbc758c instantiate_virtual_regs_in_insn
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/function.c:1611
0xbc758c instantiate_virtual_regs
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/function.c:1985
0xbc758c execute
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/function.c:2034
[Bug target/102252] svbool_t with SVE can generate invalid assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102252 ktkachov at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from ktkachov at gcc dot gnu.org --- Testing a patch
[Bug target/102252] svbool_t with SVE can generate invalid assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102252
--- Comment #3 from ktkachov at gcc dot gnu.org ---
The RTL for the offending insn:
(insn 9 8 10 (set (reg:VNx16BI 68 p0)
(mem:VNx16BI (plus:DI (mult:DI (reg:DI 1 x1 [93])
(const_int 8 [0x8]))
(reg/f:DI 0 x0 [92])) [2 work_3(D)->array[offset_4(D)]+0 S8
A16])) "asm.c":29:29 4465 {*aarch64_sve_movvnx16bi}
(nil))
That addressing mode isn't valid for predicate loads.
In aarch64.c:aarch64_classify_address if we set allow_reg_index_p to false when
vec_flags & VEC_SVE_PRED that fixes it, but will need more testing
[Bug middle-end/102253] scalability issues with large loop depth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102253 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Keywords||compile-time-hog --- Comment #2 from Richard Biener --- The unroll and ivcanon issues are all from invoking estimate_numbers_of_iterations which for each loop walks the whole loop body (including conditionally executed parts) and on the signed IV increment invokes infer_loop_bounds_from_signedness which performs SCEV analysis. It's highly unlikely that there's useful info from stmts in inner loop given we're looking for an evolution in the outer loop. The code is also calling analyze_scalar_evolution with a loop that's not the loop the stmt is in which might be a correctness issue. idx_infer_loop_bounds seems to do the correct thing here. Possibly all SCEV analysis could be performed once and instantiated in the outermost loop we're interested in. That is, we'd walk the outermost loop and fill in bounds for the whole subnest with a single IL walk. While scalar evolutions are cached, the instantiations are not.
[Bug target/102252] svbool_t with SVE can generate invalid assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102252 ktkachov at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-09-09 Status|UNCONFIRMED |NEW CC||ktkachov at gcc dot gnu.org Target||aarch64 Ever confirmed|0 |1 --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug middle-end/102253] scalability issues with large loop depth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102253 --- Comment #1 from Richard Biener --- replacing the loop bound 1024 with 'b' moves the two offenders off the radar leaving, with N == 1 ipa function summary : 12.91 ( 11%) 0.00 ( 0%) 12.92 ( 11%) 9800k ( 0%) loop init : 11.08 ( 9%) 0.12 ( 15%) 11.19 ( 9%) 1677M ( 65%) branch prediction : 81.17 ( 68%) 0.05 ( 6%) 81.12 ( 67%) 51M ( 2%) TOTAL : 119.93 0.78120.77 2567M where IPA function summary might be because of the artificial testcase construction relying on inlining.
[Bug c/102245] [12 Regression] false int-in-bool-context warning with shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102245
--- Comment #6 from Andrew Pinski ---
Here is a testcase which will hit the warning on all targets and not just ILP32
specific ones:
int
foo (_Bool x)
{
int v = 0;
return (v & ~1u) | (1u & (x << 0));
}
[Bug middle-end/102253] New: scalability issues with large loop depth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102253
Bug ID: 102253
Summary: scalability issues with large loop depth
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
When investigating an improvement to LIMs fill_always_executed_in I created
the following testcase which creates a loop nest of depth N with conditionally
executed subloops.
extern void foobar (int);
template
struct bar
{
static void baz(int b, int)
{
if (b & (1 << (a % 32)))
for (int i = 0; i < 1024; ++i)
bar::baz (b, i);
}
};
template <>
struct bar<0>
{
static void baz (int, int i) { foobar (i); }
};
void __attribute__((flatten)) foo(int b)
{
#ifndef N
#define N 10
#endif
bar::baz (b, 0);
}
For N == 900 (the maximum unless you also specify -ftemplate-depth) and -O1 we
see
tree canonical iv : 1.42 ( 13%) 0.00 ( 0%) 1.42 ( 13%)
28M ( 13%)
complete unrolling : 2.80 ( 27%) 0.00 ( 0%) 2.81 ( 26%)
42M ( 19%)
integrated RA : 3.41 ( 32%) 0.32 ( 80%) 3.72 ( 34%)
640k ( 0%)
TOTAL : 10.54 0.40 10.96
224M
For N == 1800 and -O1 it is already
tree canonical iv : 30.43 ( 28%) 0.05 ( 14%) 30.50 ( 28%)
116M ( 15%)
complete unrolling : 63.96 ( 59%) 0.06 ( 17%) 64.04 ( 59%)
175M ( 22%)
tree iv optimization : 5.75 ( 5%) 0.00 ( 0%) 5.77 ( 5%)
126M ( 16%)
integrated RA : 1.40 ( 1%) 0.12 ( 34%) 1.53 ( 1%)
1754k ( 0%)
TOTAL : 108.35 0.35108.75
796M
For reference compile-time with N == 450 is 2.5s with
tree canonical iv : 0.18 ( 7%) 0.00 ( 0%) 0.19 ( 7%)
6904k ( 10%)
complete unrolling : 0.34 ( 14%) 0.00 ( 0%) 0.34 ( 13%)
8412k ( 13%)
[Bug target/102252] svbool_t with SVE can generate invalid assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102252 --- Comment #1 from Gilles Gouaillardet --- Created attachment 51430 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51430=edit a test that works FWIW, the attached test_svfloat.cpp passes. It is very similar to test_svbool.cpp but it "abstracts" a svfloat32_t instead of a svbool_t.
[Bug target/102252] New: svbool_t with SVE can generate invalid assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102252 Bug ID: 102252 Summary: svbool_t with SVE can generate invalid assembly Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gilles.gouaillardet at gmail dot com Target Milestone: --- Created attachment 51429 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51429=edit a simple reproducer Let's consider the attached test_svbool.cpp and compile it with SVE fixed 512 bits: $ g++ -march=armv8.2-a+sve -msve-vector-bits=512 -c test_svbool.cpp /tmp/cc38qRcE.s: Assembler messages: /tmp/cc38qRcE.s:44: Error: invalid addressing mode at operand 2 -- `ldr p0,[x0,x1,lsl 3]' The generated assembly is invalid and cannot be assembled. All branches that support SVE (10, 11 and 12) are affected. FWIW, the code compiles just fine with LLVM 12, 13 and main branches. This code is a trimmed version of an improvement for GROMACS.
[Bug middle-end/33262] Disappearing loop conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33262 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=32328, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=32772, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=32716, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=32303 Status|UNCONFIRMED |RESOLVED Target Milestone|--- |4.4.0 --- Comment #4 from Andrew Pinski --- This looks like it was working correctly in GCC 4.4.7. It does look like it is broken in GCC 4.1.2 though. I suspect it was fixed by r127629 as -fno-strict-aliasing in GCC 4.1.2 also causes the correct code. So going to close it was fixed for 4.4.0 and link it to the ones which were known to be fixed by r127629 .
[Bug middle-end/79173] add-with-carry and subtract-with-borrow support (x86_64 and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173 --- Comment #13 from Andrew Pinski --- (In reply to Vincent Lefèvre from comment #12) > One issue is that _addcarry_u64 / x86intrin.h are not documented, so the > conditions of its use in portable code are not clear. I suppose that it is > designed to be used in a target-independent compiler builtin. None of the x86 intrinsics are documented except on the Intel intrinsics guide page: e.g: https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_addcarry_u64
[Bug middle-end/79173] add-with-carry and subtract-with-borrow support (x86_64 and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173 --- Comment #12 from Vincent Lefèvre --- (In reply to Andrew Pinski from comment #11) > x86 has _addcarry_u64 which gets it mostly (see PR 97387). > > The clang builtins __builtin_*_overflow are there but not the __builtin_add* > builtins. > > GCC does do a decent job of optimizing the original code now too. By "original code", do you mean the code with _addcarry_u64 (I haven't tested)? Otherwise, I don't see any optimization at all on the code I posted in Comment 0. One issue is that _addcarry_u64 / x86intrin.h are not documented, so the conditions of its use in portable code are not clear. I suppose that it is designed to be used in a target-independent compiler builtin.
[Bug c++/94039] conditional operator fails to use proper overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94039 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-09-09 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- [expr.cond]/6 I think applies here. Confirmed.
[Bug c++/102251] Valid code is rejected in Conditional operator with unique conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102251 --- Comment #1 from Andrew Pinski --- Understanding [expr.cond]/3 part of the standard is hard ... Also EDG and GCC produce the same results here. Very similar to PR 87605.
[Bug libstdc++/100851] Using std::thread on Alpine Linux/musl causes SIGABRT after main when unloading a shared library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100851 --- Comment #4 from michaldrozd at protonmail dot ch --- PR 91737 seems similar enough to be related I've narrowed it down to the -Wl,-init functionality, if you comment out this lines it exits cleanly. https://github.com/eclipse/paho.mqtt.c/blob/master/src/CMakeLists.txt#L220 Interestingly enough if you edit the function https://github.com/eclipse/paho.mqtt.c/blob/master/src/MQTTClient.c#L119 to do absolutely nothing it still aborts, so it seems it's something with the init functionality itself, not this specific function
[Bug c/102245] [12 Regression] false int-in-bool-context warning with shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102245 --- Comment #5 from Richard Biener --- I think the warning should work on unfolded (un-narrowed) trees or shorten_binary_op should from a INTEGER_TYPEd operation not create a BOOLEAN_TYPEd one (but maybe simply build a unsigned int:1 for it)?
[Bug middle-end/102243] [12 Regression] ice in get_range_query since r12-3300-gece28da924dd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102243 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Last reconfirmed||2021-09-09 Summary|[12 Regression] ice in |[12 Regression] ice in |get_range_query |get_range_query since ||r12-3300-gece28da924dd Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Martin Liška --- (In reply to Andrew Pinski from comment #1) > I suspect r12-3300-gece28da924dd Confirmed. @Andrew: When marking a culprit revision, please CC the revision author.
[Bug c++/102251] New: Valid code is rejected in ternary operator with unique conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102251
Bug ID: 102251
Summary: Valid code is rejected in ternary operator with unique
conversion
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
Ternary operator ?: here must convert A into B using B::B(const A &)
```
#include
class A;
struct B {
B() {}
B(const A &) {}
};
class A : B {};
static_assert(std::is_convertible_v);
int main() {
void( true ? B{} : A{} );
}
```
but GCC prints the error "'B' is an inaccessible base of 'A'"
Other compilers accept the code: https://gcc.godbolt.org/z/oxefo4h5n
[Bug target/102154] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-3277-gd2874d905647a1d146dafa60199d440e837adc4d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154 --- Comment #18 from rguenther at suse dot de --- On Wed, 8 Sep 2021, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154 > > --- Comment #17 from Segher Boessenkool --- > (In reply to Hongtao.liu from comment #15) > > as discussed in > > https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578437.html, allow > > specific float-int subreg seems weird. > > Indiscriminately allowing all of them is a bad idea. No machine (that has > more than just integer hardware) can actually use those, resulting in ICEs > (like here) or inefficient code generated by reload, or a mix, or worse. > > > And when i look the pattern, it also seems to be strange to disallow subreg > > in operands[1], IMHO things like TARGET_ALLOW_SF_SUBREG should be done in > > TARGET_CAN_CHANGE_MODE_CLASS, so reload/lra will do the right thing. > > No. We usually have this in the predicates. But there simply is no even > remotely efficient way to do such moves, so we should not pretend there is. So I wonder if it makes sense to allow lowpart subregs of any mode when the inner mode is integer. There's already /* ??? Similarly, e.g. with (subreg:DF (reg:TI)). Though store_bit_field is the culprit here, and not the backends. */ else if (known_ge (osize, regsize) && known_ge (isize, osize)) ; where regsize is REGMODE_NATURAL_SIZE (imode) but with a HFmode subreg of DImode the known_ge (osize, regsize) doesn't apply (I wonder what that condition is about - it looks rather arbitrary). The above allowance also doesn't restrict the subreg offset in any way.
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 --- Comment #29 from Toon Moene --- On 9/8/21 10:05 PM, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 > > anlauf at gcc dot gnu.org changed: > > What|Removed |Added > > Status|NEW |WAITING > > --- Comment #28 from anlauf at gcc dot gnu.org --- > (In reply to Toon Moene from comment #27) >> Yes, I am now convince this works (64 leads to stop 1, but 63 works). > > So has this been definitely fixed, and can we close it? > Yes, it can be closed - thanks !
[Bug target/93990] [x86] Silly code generation for _addcarry_u32/_addcarry_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93990 --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > That leaves if there case where the first argument is non-zero and the > result is used. I think going the route that Jakub mentions is best for this > last case. Maybe even generic builtins/internal functions for this case even as clang has __builtin_addc, etc.
[Bug target/97387] we are near 2021, add carry intrinsic still does the wrong thing and generates silly code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97387 Andrew Pinski changed: What|Removed |Added Depends on||93990 --- Comment #15 from Andrew Pinski --- PR 93990 is another related issue here. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93990 [Bug 93990] [x86] Silly code generation for _addcarry_u32/_addcarry_u64
[Bug middle-end/79173] add-with-carry and subtract-with-borrow support (x86_64 and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97387 Component|target |middle-end --- Comment #11 from Andrew Pinski --- x86 has _addcarry_u64 which gets it mostly (see PR 97387). The clang builtins __builtin_*_overflow are there but not the __builtin_add* builtins. GCC does do a decent job of optimizing the original code now too.
[Bug libstdc++/100851] Using std::thread on Alpine Linux/musl causes SIGABRT after main when unloading a shared library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100851 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91737 --- Comment #3 from Andrew Pinski --- Or maybe it was caused by PR 91737.
