[Bug c++/100646] [11/12 Regression] gcc -E -fdirectives-only causes "error: unterminated comment" when no new line at the end of file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100646 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d15a2d261b24adcbfe5e663b15dde3df5d2b3486 commit r12-934-gd15a2d261b24adcbfe5e663b15dde3df5d2b3486 Author: Jakub Jelinek Date: Thu May 20 09:09:07 2021 +0200 libcpp: Fix up -fdirectives-only handling of // comments on last line not terminated with newline [PR100646] As can be seen on the testcases, before the -fdirectives-only preprocessing rewrite the preprocessor would assume // comments are terminated by the end of file even when newline wasn't there, but now we error out. The following patch restores the previous behavior. 2021-05-20 Jakub Jelinek PR preprocessor/100646 * lex.c (cpp_directive_only_process): Treat end of file as termination for !is_block comments. * gcc.dg/cpp/pr100646-1.c: New test. * gcc.dg/cpp/pr100646-2.c: New test.
[Bug tree-optimization/94589] Optimize (i<=>0)>0 to i>0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589
--- Comment #24 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2b536797f7e43c55072a3215735f5833f1d6d218
commit r12-935-g2b536797f7e43c55072a3215735f5833f1d6d218
Author: Jakub Jelinek
Date: Thu May 20 09:10:38 2021 +0200
phiopt: Simplify (X & Y) == X -> (X & ~Y) == 0 even in presence of integral
conversions [PR94589]
On Wed, May 19, 2021 at 10:15:53AM +0200, Christophe Lyon via Gcc-patches
wrote:
> After this update, the test fails on arm and aarch64: according to the
> logs, the optimization is still performed 14 times.
Seems this is because
if (change
&& !flag_syntax_only
&& (load_extend_op (TYPE_MODE (TREE_TYPE (and0)))
== ZERO_EXTEND))
{
tree uns = unsigned_type_for (TREE_TYPE (and0));
and0 = fold_convert_loc (loc, uns, and0);
and1 = fold_convert_loc (loc, uns, and1);
}
in fold-const.c adds on these targets extra casts that prevent the
optimizations.
2021-05-20 Jakub Jelinek
PR tree-optimization/94589
* match.pd ((X & Y) == X -> (X & ~Y) == 0): Simplify even in
presence
of integral conversions.
[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928 --- Comment #10 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:94fa4c67b95c12482b6087d8eef2d72f7b7ea254 commit r12-936-g94fa4c67b95c12482b6087d8eef2d72f7b7ea254 Author: Jakub Jelinek Date: Thu May 20 09:17:40 2021 +0200 openmp: Handle explicit linear clause properly in combined constructs with target [PR99928] linear clause should have the effect of firstprivate+lastprivate (or for IVs not declared in the construct lastprivate) on outer constructs and eventually map(tofrom:) on target when combined with it. 2021-05-20 Jakub Jelinek PR middle-end/99928 * gimplify.c (gimplify_scan_omp_clauses) : For explicit linear clause when combined with target, make it map(tofrom:) instead of no clause or firstprivate. * c-c++-common/gomp/pr99928-4.c: Remove all xfails. * c-c++-common/gomp/pr99928-5.c: Likewise.
[Bug target/100693] New: PPC: missing 64-bit addg6s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100693 Bug ID: 100693 Summary: PPC: missing 64-bit addg6s Product: gcc Version: 8.3.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: --- gcc only provides unsigned int __builtin_addg6s (unsigned int, unsigned int); but addg6s is a 64-bit operation. I require unsigned long long __builtin_addg6s (unsigned long long, unsigned long long); . I for now use inline assembly.
[Bug target/100694] New: PPC: initialization of __int128 is very inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100694
Bug ID: 100694
Summary: PPC: initialization of __int128 is very inefficient
Product: gcc
Version: 8.3.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: ---
Initializing a __int128 from 2 64-bit integers is implemented very inefficient.
The most natural code which works good on all other platforms generate
additional 2 li 0 + 2 or instructions.
void test2(unsigned __int128* res, unsigned long long hi, unsigned long long
lo)
{
unsigned __int128 i = hi;
i <<= 64;
i |= lo;
*res = i;
}
_Z5test2Poyy:
.LFB15:
.cfi_startproc
li 8,0
li 11,0
or 10,5,8
or 11,11,4
std 10,0(3)
std 11,8(3)
blr
.long 0
.byte 0,9,0,0,0,0,0,0
.cfi_endproc
While for the above sample, "+" instead "|" solves the issues, it generates
addc+addz in other more complicated scenarsion.
The most ugly workaround I can think of I now use as workaround.
void test4(unsigned __int128* res, unsigned long long hi, unsigned long long
lo)
{
union
{ unsigned __int128 i;
struct
{
unsigned long long lo;
unsigned long long hi;
} s;
} u;
u.s.lo = lo;
u.s.hi = hi;
*res = u.i;
}
This generates the expected code sequence in all cases I have looked at.
_Z5test4Poyy:
.LFB17:
.cfi_startproc
std 5,0(3)
std 4,8(3)
blr
.long 0
.byte 0,9,0,0,0,0,0,0
.cfi_endproc
Please merge li 0 + or to nop.
[Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #36 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:9e0a5e3ea37f9d7d2b6f2dab7c0bfbeaf08466a3 commit r12-937-g9e0a5e3ea37f9d7d2b6f2dab7c0bfbeaf08466a3 Author: Tobias Burnus Date: Thu May 20 09:51:10 2021 +0200 Testsuite/Fortran: gfortran.dg/pr96711.f90 - fix expected value for PowerPC [PR96983] gcc/testsuite/ChangeLog: PR fortran/96983 * gfortran.dg/pr96711.f90: Use 2**digit(x) instead of a hard-coded value; add comments regarding what the code does.
[Bug middle-end/100685] #pragma GCC push_options ineffective for optimize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100685
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2021-05-20
--- Comment #2 from Martin Liška ---
(In reply to Richard Biener from comment #1)
> IIRC we changed behavior so that optimize appends to the global options,
> thus optimize("no-tree-pre") gives you -O2 -fno-tree-pre instead of
> -O0 -fno-tree-pre.
Not yet, the patch was sent but then I decided to postpone it for GCC 12.
>
> But -O2 -O1 should still get you -O1 and thus the same as -O1 stand-alone.
> So sth is broken it seems?
>
> push_options simply haves the old state for restore, it does not stash
> away previous applied options.
I'll investigate what has changed in GCC 11.
[Bug lto/100692] [11 Regression] ICE in fld_incomplete_type_of, at tree.c:5452
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100692 Martin Liška changed: What|Removed |Added Summary|[11/12 Regression] ICE in |[11 Regression] ICE in |fld_incomplete_type_of, at |fld_incomplete_type_of, at |tree.c:5452 |tree.c:5452 --- Comment #3 from Martin Liška --- Btw. fixed on master with r12-299-ga0fdff3cf33f7284.
[Bug lto/100692] [11 Regression] ICE in fld_incomplete_type_of, at tree.c:5452
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100692 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #4 from Martin Liška --- And started with r11-7095-g7b258ac7afaaf7d8.
[Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #37 from CVS Commits --- The releases/gcc-11 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:271fc1caac433e84e6389e73a5bf07350ea545e2 commit r11-8445-g271fc1caac433e84e6389e73a5bf07350ea545e2 Author: Tobias Burnus Date: Thu May 20 09:51:10 2021 +0200 Testsuite/Fortran: gfortran.dg/pr96711.f90 - fix expected value for PowerPC [PR96983] gcc/testsuite/ChangeLog: PR fortran/96983 * gfortran.dg/pr96711.f90: Use 2**digit(x) instead of a hard-coded value; add comments regarding what the code does. (cherry picked from commit 9e0a5e3ea37f9d7d2b6f2dab7c0bfbeaf08466a3)
[Bug lto/100692] [11 Regression] ICE in fld_incomplete_type_of, at tree.c:5452
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100692 --- Comment #5 from Richard Biener --- Created attachment 50849 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50849&action=edit reduced testcase
[Bug other/100695] New: Format decoder, quoting in 'dump_printf' etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100695
Bug ID: 100695
Summary: Format decoder, quoting in 'dump_printf' etc.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
Target Milestone: ---
For user-visible '-fopt-info' diagnostics ('dump_printf' etc.), I'm trying to
pretty-print a TREE DECL, using the '%T' format code. As in other compiler
diagnostics, I'd like the output to be quoted, so I tried using '%qT' but that
prints the same as '%T' (unexpected?). Using '%<%T%>' prints the desired
output -- but GCC bootstrap doesn't like that one:
[...]/gcc/omp-low.c:10171:33: error: ‘T’ conversion used within a quoted
sequence [-Werror=format=]
10171 |"variable %<%T%> ", decl);
| ^
I'll work around that, but something seems inconsistent here?
[Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #38 from Tobias Burnus --- I think GCC 12/mainline is now fixed. The second patch was only applied to GCC 12 – it might need to be backported? (I have not checked GCC 11 with PowerPC.) (If there are remaining/new issues, I recommend to open a new PR.) Commits done: [For Sparc, I think] commit r11-7595, Eric Botcazou, Wed Mar 10 12:05:53 2021 +0100 Do not assume that __float128 exists [For PowerPC] commit r12-54, Michael Meissner, Wed Apr 21 23:02:07 2021 -0400 Fix Fortran rounding issues, PR fortran/96983. [Testcase only, for PowerPC] commitr12-937, Tobias Burnus, Thu May 20 09:51:10 2021 +0200 Backport: r11-8445 Testsuite/Fortran: gfortran.dg/pr96711.f90 - fix expected value for PowerPC [PR96983]
[Bug fortran/96711] Internal Compiler Error on NINT() Function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #22 from Tobias Burnus --- (In reply to anlauf from comment #21) > Please see PR96983 for the fallout. Note: That fallout PR is now fixed (at least for GCC 12, one of the three patches might still need backporting to GCC 11).
[Bug c/42579] [PATCH] support for obtaining file basename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42579 --- Comment #9 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:1a9b3f04c11eb467a8dc504a37dad57a371a0d4c commit r12-938-g1a9b3f04c11eb467a8dc504a37dad57a371a0d4c Author: Christophe Lyon Date: Thu May 20 08:10:50 2021 + c: Add support for __FILE_NAME__ macro (PR c/42579) The toolchain provided by ST for stm32 has had support for __FILENAME__ for a while, but clang/llvm has recently implemented support for __FILE_NAME__, so it seems better to use the same macro name in GCC. It happens that the ST patch is similar to the one proposed in PR c/42579. Given these input files: :: mydir/myinc.h :: char* mystringh_file = __FILE__; char* mystringh_filename = __FILE_NAME__; char* mystringh_base_file = __BASE_FILE__; :: mydir/mysrc.c :: char* mystring_file = __FILE__; char* mystring_filename = __FILE_NAME__; char* mystring_base_file = __BASE_FILE__; we produce: $ gcc mydir/mysrc.c -I . -E char* mystringh_file = "./mydir/myinc.h"; char* mystringh_filename = "myinc.h"; char* mystringh_base_file = "mydir/mysrc.c"; char* mystring_file = "mydir/mysrc.c"; char* mystring_filename = "mysrc.c"; char* mystring_base_file = "mydir/mysrc.c"; 2021-05-20 Christophe Lyon Torbjörn Svensson PR c/42579 libcpp/ * include/cpplib.h (cpp_builtin_type): Add BT_FILE_NAME entry. * init.c (builtin_array): Likewise. * macro.c (_cpp_builtin_macro_text): Add support for BT_FILE_NAME. gcc/ * doc/cpp.texi (Common Predefined Macros): Document __FILE_NAME__. gcc/testsuite/ * c-c++-common/spellcheck-reserved.c: Add tests for __FILE_NAME__. * c-c++-common/cpp/file-name-1.c: New test.
[Bug c/42579] [PATCH] support for obtaining file basename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42579 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||clyon at gcc dot gnu.org --- Comment #10 from Christophe Lyon --- Fixed on trunk: we now support __FILE_NAME__, like clang.
[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205 --- Comment #23 from SRINATH PARVATHANENI --- (In reply to rguent...@suse.de from comment #22) > On Wed, 19 May 2021, bernd.edlinger at hotmail dot de wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205 > > > > --- Comment #21 from Bernd Edlinger --- > > Hi Srinath, > > > > when we add new assertions to gcc we use always a gcc_checking_assert > > nowadays, that is also the case here. > > > > The assertion is only firing in your compiler because it is a development > > snapshot 10.3.1. So that is an experimemtal version. > > 10.3.1 is not an experimental version, so the assert should not fire > there unless you configure with --enable-checking (which you might > have done). Thanks rguent...@suse.de and Bernd Edlinger. My I'm again having confusion with the wording development/release/experiment versions. All development versions checks for gcc_checking_assert whether --enable-checking=yes or --enable-checking=no (eg: 10.3.1), but release versions only check for gcc_checking_assert when --enable-checking=yes (eg:10.3.0). If I wanted to build a toolchain using development version (eg:10.3.1) and for this test to not to fail , I should either pass --enable-checking=no or apply this patch (which was committed to trunk) on the top of gcc-10.3.1 source code. Is my understanding correct?
[Bug target/100637] [i386] Vectorize 4-byte vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100637 --- Comment #3 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:507359e1d4d18614eb9679043995edf0675b6ff5 commit r12-940-g507359e1d4d18614eb9679043995edf0675b6ff5 Author: Uros Bizjak Date: Thu May 20 11:11:21 2021 +0200 i386: Add mult-high and shift patterns for 4-byte vectors [PR100637] 2021-05-20 Uroš Bizjak gcc/ PR target/100637 * config/i386/mmx.md (Yv_Yw): Revert adding V4QI and V2HI modes. (*3): Use Yw instad of constrint. (mulv4hi3_highpart): New expander. (*mulv2hi3_highpart): New insn pattern. (mulv2hi3_higpart): New expander. (*v2hi3): New insn pattern. (v2hi3): New expander. * config/i386/sse.md (smulhrsv2hi3): New expander. (*smulhrsv2hi3): New insn pattern. gcc/testsuite/ PR target/100637 * gcc.target/i386/pr100637-1w.c (shl, ashr, lshr): New tests.
[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205 --- Comment #24 from rguenther at suse dot de --- On Thu, 20 May 2021, sripar01 at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205 > > --- Comment #23 from SRINATH PARVATHANENI --- > (In reply to rguent...@suse.de from comment #22) > > On Wed, 19 May 2021, bernd.edlinger at hotmail dot de wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205 > > > > > > --- Comment #21 from Bernd Edlinger --- > > > Hi Srinath, > > > > > > when we add new assertions to gcc we use always a gcc_checking_assert > > > nowadays, that is also the case here. > > > > > > The assertion is only firing in your compiler because it is a development > > > snapshot 10.3.1. So that is an experimemtal version. > > > > 10.3.1 is not an experimental version, so the assert should not fire > > there unless you configure with --enable-checking (which you might > > have done). > > Thanks rguent...@suse.de and Bernd Edlinger. > > My I'm again having confusion with the wording development/release/experiment > versions. > > All development versions checks for gcc_checking_assert whether > --enable-checking=yes or --enable-checking=no (eg: 10.3.1), but release > versions only check for gcc_checking_assert when --enable-checking=yes > (eg:10.3.0). No. gcc_checking_assert is enabled when --enable-checking=yes --enable-checking defaults to =yes on the master branch. On release branches it defaults to =release, that includes snapshots and thus 10.3.1. > If I wanted to build a toolchain using development version (eg:10.3.1) and for > this test to not to fail , I should either pass --enable-checking=no or apply > this patch (which was committed to trunk) on the top of gcc-10.3.1 source > code. > > Is my understanding correct? You don't need anything special for 10.3.1, that is not a development version. If you do not specify any --enable-checking at configure time the default is that the assert does not trigger and thus the ICE should not happen.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #217 from John Buddery --- Thanks very much for adding the binutils patch. Sorry, I'm new to .md definitions, so I've probably got this wrong. Did you mean something like: (define_insn "call_nogp_longcall" [(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s")) (const_int 0)) (clobber (match_operand:DI 1 "register_operand" "=b,b"))] "TARGET_HPUX && ia64_tune == PROCESSOR_ITANIUM2" "@ br.call%+.many %1 = %0 brl.call%+.many %1 = %0" [(set_attr "itanium_class" "br,scall")]) (define_insn "call_nogp" [(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s")) (const_int 0)) (clobber (match_operand:DI 1 "register_operand" "=b,b"))] "" "br.call%+.many %1 = %0" [(set_attr "itanium_class" "br,scall")]) I assume you need a second instruction to catch the case where the condition doesn't match ? Itanium 1 support seems to have been dropped at some point, so -mtune only accepts options mapping to Itanium2. So, I couldn't test the br case on HP.
[Bug fortran/96711] Internal Compiler Error on NINT() Function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711 --- Comment #23 from bernd.eggen at gmail dot com --- Many thanks Tobias, noted - bw, Bernd On Thu, 20 May 2021 at 09:12, burnus at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711 > > Tobias Burnus changed: > >What|Removed |Added > > > CC||burnus at gcc dot gnu.org > > --- Comment #22 from Tobias Burnus --- > (In reply to anlauf from comment #21) > > Please see PR96983 for the fallout. > > Note: That fallout PR is now fixed (at least for GCC 12, one of the three > patches might still need backporting to GCC 11). > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug.
[Bug tree-optimization/100696] New: mult_higpart is not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100696
Bug ID: 100696
Summary: mult_higpart is not vectorized
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
Following testcases:
--cut here--
#define N 4
short r[N], a[N], b[N];
unsigned short ur[N], ua[N], ub[N];
void mul (void)
{
int i;
for (i = 0; i < N; i++)
r[i] = a[i] * b[i];
}
/* { dg-final { scan-assembler "pmullw" } } */
void mulhi (void)
{
int i;
for (i = 0; i < N; i++)
r[i] = ((int) a[i] * b[i]) >> 16;
}
/* { dg-final { scan-assembler "pmulhw" } } */
void umulhi (void)
{
int i;
for (i = 0; i < N; i++)
ur[i] = ((unsigned int) ua[i] * ub[i]) >> 16;
}
/* { dg-final { scan-assembler "pmulhuw" } } */
void smulhrs (void)
{
int i;
for (i = 0; i < N; i++)
r[i] = int) a[i] * b[i]) >> 14) + 1) >> 1;
}
/* { dg-final { scan-assembler "pmulhrsw" } } */
--cut here--
should all vectorize for x86_64 with "-O3 -mssse3" to their vector
instructions.
Currently the compiler vectorizes only pmullw and much more complex pmulhrsw,
but not pmulhw and pmulhuw.
For N = 2 (SLP vectorization?), the compiler manages to vectorize mul and none
of the other testcases.
[Bug c/100697] New: Missing fwprop for argument register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100697
Bug ID: 100697
Summary: Missing fwprop for argument register
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
cat test.c
extern double top[100];
int foo (long long j, double a) {
top[j] += a;
return 0;
}
gcc10.3 -g0 -O3 -march=armv8.2-a test.c -save-temps -S, can also be test base
on https://gcc.godbolt.org.
.type foo, %function
foo:
.LFB0:
.cfi_startproc
mov x2, x0 -- redundant could be fwprop
adrpx1, top
add x1, x1, :lo12:top
mov w0, 0
ldr d1, [x1, x2, lsl 3]
faddd0, d1, d0
str d0, [x1, x2, lsl 3]
ret
If x0 fwprop into both ldr and str, then the insn mov x2, x0 can be deleted.
[Bug c++/100698] New: Error when initializing a struct member of type char[N] with short string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100698
Bug ID: 100698
Summary: Error when initializing a struct member of type
char[N] with short string literal
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iDingDong at outlook dot com
Target Milestone: ---
//---
struct [[maybe_unused]] A {
char a[5];
};
int main() {
A x = { .a = "Hey!" }; // OK
A y = { .a = { 'H', 'i', '\0' } }; // OK
A z = { .a = "Hi" }; // error: C99 designator 'a' outside aggregate
initializer
return 0;
}
//---
Compiled with
> g++ -std=c++20 test.cpp
This error is only triggered when attempting to initialize an array of char
with a string literal of smaller size than the array was defined.
[Bug testsuite/100655] 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100655 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205 --- Comment #25 from SRINATH PARVATHANENI --- (In reply to rguent...@suse.de from comment #24) > On Thu, 20 May 2021, sripar01 at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205 > > > > --- Comment #23 from SRINATH PARVATHANENI --- > > (In reply to rguent...@suse.de from comment #22) > > > On Wed, 19 May 2021, bernd.edlinger at hotmail dot de wrote: > > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205 > > > > > > > > --- Comment #21 from Bernd Edlinger > > > > --- > > > > Hi Srinath, > > > > > > > > when we add new assertions to gcc we use always a gcc_checking_assert > > > > nowadays, that is also the case here. > > > > > > > > The assertion is only firing in your compiler because it is a > > > > development > > > > snapshot 10.3.1. So that is an experimemtal version. > > > > > > 10.3.1 is not an experimental version, so the assert should not fire > > > there unless you configure with --enable-checking (which you might > > > have done). > > > > Thanks rguent...@suse.de and Bernd Edlinger. > > > > My I'm again having confusion with the wording > > development/release/experiment > > versions. > > > > All development versions checks for gcc_checking_assert whether > > --enable-checking=yes or --enable-checking=no (eg: 10.3.1), but release > > versions only check for gcc_checking_assert when --enable-checking=yes > > (eg:10.3.0). > > No. gcc_checking_assert is enabled when --enable-checking=yes > --enable-checking defaults to =yes on the master branch. On release > branches it defaults to =release, that includes snapshots and thus > 10.3.1. > > > If I wanted to build a toolchain using development version (eg:10.3.1) and > > for > > this test to not to fail , I should either pass --enable-checking=no or > > apply > > this patch (which was committed to trunk) on the top of gcc-10.3.1 source > > code. > > > > Is my understanding correct? > > You don't need anything special for 10.3.1, that is not a development > version. If you do not specify any --enable-checking at configure > time the default is that the assert does not trigger and thus > the ICE should not happen. Thanks for the clarification.
[Bug libstdc++/100676] Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100676 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.2 --- Comment #2 from Jonathan Wakely --- Using __builtin_unreachable works, and the diagnostic seems acceptable: In file included from /home/jwakely/gcc/12/include/c++/12.0.0/iosfwd:38, from /home/jwakely/gcc/12/include/c++/12.0.0/string_view:40, from sv.C:1: sv.C:5:21: in 'constexpr' expansion of 'f()' sv.C:3:56: in 'constexpr' expansion of 's.std::basic_string_view::front()' /home/jwakely/gcc/12/include/c++/12.0.0/string_view:251:9: error: '__builtin_unreachable()' is not a constant expression 251 | __glibcxx_assert(this->_M_len > 0); | ^~~~
[Bug fortran/100651] Weird memory corruption with multiple triggers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100651 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #1 from G. Steinmetz --- Confirmed on my environment (x86_64-pc-linux-gnu), that example gives : $ a.out T -279921664 Operating system error: Cannot allocate memory Memory allocation failure in xrealloc Error termination. Backtrace: #0 0x40d217 in write_character at ../../../libgfortran/io/write.c:1416 #1 0x41227e in list_formatted_write_scalar at ../../../libgfortran/io/write.c:1900 #2 0x402688 in __test_intnode_MOD_test_casting_fail at .../pr100651.f90:126 #3 0x4026b7 in MAIN__ at .../pr100651.f90:136 #4 0x4026ee in main at .../pr100651.f90:133 Initialization completed without "optional" and "present..." : $ a.out T 7 err_msg: foo bar
[Bug fortran/100651] Weird memory corruption with multiple triggers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100651 --- Comment #2 from G. Steinmetz --- Simplified a bit : $ cat z1.f90 module m type :: t contains procedure, pass(this) :: assign_to_string generic :: assignment(=) => assign_to_string end type contains subroutine assign_to_string(string, this) character(:), allocatable, intent(out) :: string class(t), intent(in) :: this end subroutine assert_code(err_msg) character(:), optional, allocatable, intent(inout) :: err_msg err_msg = 'foo bar' end function to_int(err_msg) result(ptr) integer :: ptr character(:), optional, allocatable, intent(inout) :: err_msg ptr = 1 call assert_code(err_msg) end end program main use m type, extends(t) :: t2 real(8) :: value = 1 end type type(t2) :: x integer :: n character(:), allocatable :: err_msg x = t2(2) n = to_int(err_msg) print *, 'allocated :', allocated(err_msg) print *, 'len : ', len(err_msg) ! print *, 'len_trim : ', len_trim(err_msg) print *, 'err_msg : ', err_msg end $ cat z2.f90 module m type :: t contains procedure, pass(this) :: assign_to_string generic :: assignment(=) => assign_to_string end type contains subroutine assign_to_string(string, this) character(:), allocatable, intent(out) :: string class(t), intent(in) :: this end subroutine assert_code(err_msg) character(:), allocatable, intent(inout) :: err_msg err_msg = 'foo bar' end function to_int(err_msg) result(ptr) integer :: ptr character(:), allocatable, intent(inout) :: err_msg ptr = 1 call assert_code(err_msg) end end program main use m type, extends(t) :: t2 real(8) :: value = 1 end type type(t2) :: x integer :: n character(:), allocatable :: err_msg x = t2(2) n = to_int(err_msg) print *, 'allocated :', allocated(err_msg) print *, 'len : ', len(err_msg) ! print *, 'len_trim : ', len_trim(err_msg) print *, 'err_msg : ', err_msg end $ gfortran-12-20210516 z1.f90 -g -O0 && ./a.out allocated : T len : 0 Operating system error: Cannot allocate memory Memory allocation failure in xrealloc Error termination. Backtrace: #0 0x40d1c7 in write_character at ../../../libgfortran/io/write.c:1416 #1 0x41222e in list_formatted_write_scalar at ../../../libgfortran/io/write.c:1900 #2 0x40265e in MAIN__ at .../z1.f90:36 #3 0x4026a4 in main at .../z1.f90:24 $ gfortran-12-20210516 z2.f90 -g -O0 && ./a.out allocated : T len : 7 err_msg : foo bar
[Bug c++/100699] New: g++ doesn't warn uninitialized field when the class is derived from another class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100699
Bug ID: 100699
Summary: g++ doesn't warn uninitialized field when the class is
derived from another class
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mytbk920423 at gmail dot com
Target Milestone: ---
GCC doesn't warn on the following code when class B is a derived class.
--- test.hh ---
#include
class Base
{
int v;
public:
Base(int u): v(u) {}
int get() { return v; }
};
class A
{
int a;
public:
A(int a_): a(a_) {}
void print() { printf("%d\n", a); }
};
class B: public Base
{
A a;
int b;
public:
B(int b_);
void print() { a.print(); }
};
-- end of test.hh ---
- test.cpp -
#include "test.hh"
B::B(int b_):
Base(b_),
a(b), b(100)
{}
end of test.cpp ---
clang++ warns as follows:
$ clang++ -Og -g -Wall -Wextra -c test.cpp
test.cpp:5:4: warning: field 'b' is uninitialized when used here
[-Wuninitialized]
a(b), b(100)
^
1 warning generated.
[Bug c++/100700] New: -Wreturn-type has many false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700
Bug ID: 100700
Summary: -Wreturn-type has many false positives
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gonzalo.gadeschi at gmail dot com
Target Milestone: ---
Example (https://clang.godbolt.org/z/o85KbdG7h):
int f(unsigned i) {
if (i < unsigned(-1)) return i;
}
enum E { A, B };
int h(E e) {
switch (e) {
case A: return 0;
case B: return 0;
}
}
compiled with g++ (no -Wall, no -Wextra) warns with:
warning: control reaches end of non-void function [-Wreturn-type]
for "f" and "h".
Notice that clang, which implements the same warning, does not warn for "h"
(https://clang.godbolt.org/z/Ev9eqsqPf).
[Bug rtl-optimization/100701] New: [12 Regression] wrong code with -O -fschedule-insns2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100701 Bug ID: 100701 Summary: [12 Regression] wrong code with -O -fschedule-insns2 Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 50850 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50850&action=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc -O -fschedule-insns2 testcase.c $ ./a.out Aborted $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-940-20210520111231-g507359e1d4d-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-940-20210520111231-g507359e1d4d-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20210520 (experimental) (GCC)
[Bug c/100702] New: Strict overflow warning regression in gcc 8 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100702
Bug ID: 100702
Summary: Strict overflow warning regression in gcc 8 onwards
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: ---
Incorrect code like this example relies on two's complement wrapping to do what
the programmer wanted:
void foo(int *a)
{
int i;
for (i=0; i
[Bug tree-optimization/100696] mult_higpart is not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100696 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Blocks||53947 Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-20 Target||x86_64-*-* Keywords||missed-optimization --- Comment #1 from Richard Biener --- We only have a widening multiplication pattern, not a separate high-part one. When you increase N to 8 you'll see we need a VF of 8 to do [local count: 119292720]: vect__1.24_26 = MEM [(short int *)&a]; vect__3.27_23 = MEM [(short int *)&b]; vect_patt_29.28_22 = WIDEN_MULT_LO_EXPR ; vect_patt_29.28_21 = WIDEN_MULT_HI_EXPR ; vect__6.29_20 = vect_patt_29.28_22 >> 16; vect__6.29_19 = vect_patt_29.28_21 >> 16; vect__7.30_18 = VEC_PACK_TRUNC_EXPR ; MEM [(short int *)&r] = vect__7.30_18; resulting in mulhi: .LFB1: .cfi_startproc movdqa b(%rip), %xmm0 pmullw a(%rip), %xmm0 movdqa %xmm0, %xmm1 movdqa b(%rip), %xmm2 pmulhw a(%rip), %xmm2 punpcklwd %xmm2, %xmm1 punpckhwd %xmm2, %xmm0 psrad $16, %xmm1 psrad $16, %xmm0 pshufb .LC0(%rip), %xmm1 pshufb .LC1(%rip), %xmm0 por %xmm1, %xmm0 movaps %xmm0, r(%rip) ret for smulhrs there's a special pattern: t.c:40:17: note: widen_mult pattern recognized: patt_37 = _1 w* _3; t.c:40:17: note: vect_recog_mulhs_pattern: detected: _8 = _7 >> 1; t.c:40:17: note: created pattern stmt: patt_36 = .MULHRS (_1, _3); t.c:40:17: note: mult_high pattern recognized: patt_35 = (int) patt_36; t.c:40:17: note: extra pattern stmt: patt_36 = .MULHRS (_1, _3); t.c:40:17: note: vect_is_simple_use: operand _7 >> 1, type of def: internal t.c:40:17: note: vect_is_simple_use: operand .MULHRS (_1, _3), type of def: internal t.c:40:17: note: vect_recog_cast_forwprop_pattern: detected: _9 = (short int) _8; t.c:40:17: note: cast_forwprop pattern recognized: patt_34 = (short int) patt_36; so we miss sth of that for the [u]mulhi cases. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug c++/100703] New: __vector_pair and __vector_quad cannot be passed by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100703
Bug ID: 100703
Summary: __vector_pair and __vector_quad cannot be passed by
reference
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alexander.gr...@tu-dresden.de
Target Milestone: ---
The PowerPC intrinsic types __vector_pair and __vector_quad cannot be passed by
reference but only by pointer.
Reproducer code:
void ploadRhsMMA(__vector_pair&){}
int main(){
__vector_pair p;
ploadRhsMMA(p);
}
This creates an error "invalid conversion from type »* __vector_pair«"
This error looks wrong to me: Why wouldn't I be able to pass a type by
reference when I can pass it by pointer? GCC can handle both the same so it is
at least inconsistent.
Furthermore this breaks the commonly used assumption, that the following
functions can take any argument:
template
void foo(T&&);
template
void bar(const T&);
This now breaks for those intrinsics and a workaround is painful as everything
needs to be covnerted to pointers when those are part of an overload set (for
example)
[Bug target/100701] [12 Regression] wrong code with -O -fschedule-insns2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100701
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2021-05-20
Target||x86_64-*-* i?86-*-*
Status|UNCONFIRMED |NEW
Component|rtl-optimization|target
CC||uros at gcc dot gnu.org
Target Milestone|--- |12.0
--- Comment #1 from Richard Biener ---
orq %rdi, %rsi
pshuflw $0, %xmm3, %xmm0
movq%xmm0, %rbp
and %rbx, %rbp
je .L4
Confirmed. Somehow the mmx_andv8qi3 doesn't clobber CC:
(insn 19 88 15 2 (parallel [
(set (reg:CCZ 17 flags)
(compare:CCZ (ior:DI (reg:DI 4 si [158])
(reg:DI 5 di [orig:101 i ] [101]))
(const_int 0 [0])))
(clobber (reg:DI 4 si [158]))
]) "t.c":13:6 562 {*iordi_3}
(expr_list:REG_DEAD (reg:DI 4 si [158])
(expr_list:REG_UNUSED (reg:DI 4 si [158])
(nil
(insn:TI 15 19 89 2 (set (reg:V4HI 20 xmm0 [106])
(vec_duplicate:V4HI (truncate:HI (reg:SI 23 xmm3 [162] "t.c":12:5
1459 {*vec_dupv4hi}
(expr_list:REG_DEAD (reg:SI 23 xmm3 [162])
(nil)))
(insn:TI 89 15 17 2 (set (reg/v:V8QI 6 bp [orig:95 a ] [95])
(reg:V8QI 20 xmm0 [106])) "t.c":12:5 1302 {*movv8qi_internal}
(expr_list:REG_DEAD (reg:V8QI 20 xmm0 [106])
(nil)))
(insn:TI 17 89 20 2 (set (reg/v:V8QI 6 bp [orig:95 a ] [95])
(and:V8QI (reg/v:V8QI 6 bp [orig:95 a ] [95])
(reg/v:V8QI 3 bx [orig:98 a ] [98]))) "t.c":12:5 1422
{*mmx_andv8qi3}
(nil))
(jump_insn 20 17 25 2 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref:DI 113)
(pc))) "t.c":13:6 822 {*jcc}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 7 (nil)))
[Bug c/100702] Strict overflow warning regression in gcc 8 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100702 Richard Biener changed: What|Removed |Added Keywords||diagnostic Version|unknown |11.1.0 --- Comment #1 from Richard Biener --- You can use -fsanitize=undefined to get runtime diagnostics, the compile-time warnings were mostly inefficient and/or had too many false positives to be useful and thus were largely removed.
[Bug jit/100688] Add support for link section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688 --- Comment #5 from Antoni --- This is much less work as I'm reusing the rustc front-end.
[Bug c++/100675] std::string_view::find in constexpr function is not constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100675 --- Comment #2 from Jonathan Wakely --- Maybe we should just get rid of the __constant_string_p stuff entirely.
[Bug c/100702] Strict overflow warning regression in gcc 8 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100702 --- Comment #2 from David Brown --- Runtime diagnostics can be very useful - but they are a different kind of warning. In particular, they only show what errors have occurred during your testing - they don't show what errors /might/ occur. There is a general rule that the earlier you find your problems, the cheaper, faster and easier they are to handle. Compile-time checks are better than run-time checks when all else is equal. Clearly compile-time checks have more risk of false-positives - that's why it's important that most are optional or can be disabled by pragmas or particular code constructs. But when they /can/ be used, they are preferable. In this particular example, there is no doubt of the undefined behaviour and the infinite loop. The compiler knows about them. It would not be a false positive to issue a warning in such cases. Another limitation of runtime diagnostics is their use in embedded systems. gcc is heavily used in microcontrollers, where you often do not have much in the way of a console output, no file system, etc. Runtime diagnostic opportunities are far more limited in such cases. I fully appreciate that compile-time warnings are difficult, especially avoiding false positives, and if you say that a warning here would be too niche or too difficult to justify the effort, I am happy to accept that. But run-time diagnostics are not a replacement - they are an additional and complementary tool. Please do not consider sanitizers as a substitute for static analysis and compile-time error checking and warnings.
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 --- Comment #11 from CVS Commits --- The master branch has been updated by Joern Rennecke : https://gcc.gnu.org/g:66c5f24788652a49b528f14e23e8121ad0935ace commit r12-942-g66c5f24788652a49b528f14e23e8121ad0935ace Author: Joern Rennecke Date: Thu May 20 13:21:41 2021 +0100 libstdc++: Disable floating_to_chars.cc on 16 bit targets This patch conditionally disables the compilation of floating_to_chars.cc on 16 bit targets, thus fixing a build failure for these targets as the POW10_SPLIT_2 array exceeds the maximum object size. libstdc++-v3/ PR libstdc++/100361 * include/std/charconv (to_chars): Hide the overloads for floating-point types for 16 bit targets. * src/c++17/floating_to_chars.cc: Don't compile for 16 bit targets. * testsuite/20_util/to_chars/double.cc: Run this test only on size32plus targets. * testsuite/20_util/to_chars/float.cc: Likewise. * testsuite/20_util/to_chars/long_double.cc: Likewise.
[Bug target/99977] arm: ICE with __sync_bool_compare_and_swap and -mcpu=cortex-m23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99977 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Alex Coplan : https://gcc.gnu.org/g:0a193c95590779aad4036f18258b0eebb9f70a62 commit r10-9838-g0a193c95590779aad4036f18258b0eebb9f70a62 Author: Alex Coplan Date: Tue Apr 27 14:56:15 2021 +0100 arm: Fix ICEs with compare-and-swap and -march=armv8-m.base [PR99977] The PR shows two ICEs with __sync_bool_compare_and_swap and -mcpu=cortex-m23 (equivalently, -march=armv8-m.base): one in LRA and one later on, after the CAS insn is split. The LRA ICE occurs because the @atomic_compare_and_swap_1 pattern attempts to tie two output operands together (operands 0 and 1 in the third alternative). LRA can't handle this, since it doesn't make sense for an insn to assign to the same operand twice. The later (post-splitting) ICE occurs because the expansion of the cbranchsi4_scratch insn doesn't quite go according to plan. As it stands, arm_split_compare_and_swap calls gen_cbranchsi4_scratch, attempting to pass a register (neg_bval) to use as a scratch register. However, since the RTL template has a match_scratch here, gen_cbranchsi4_scratch ignores this argument and produces a scratch rtx. Since this is all happening after RA, this is doomed to fail (and we get an ICE about the insn not matching its constraints). It seems that the motivation for the choice of constraints in the atomic_compare_and_swap pattern comes from an attempt to satisfy the constraints of the cbranchsi4_scratch insn. This insn requires the scratch register to be the same as the input register in the case that we use a larger negative immediate (one that satisfies J, but not L). Of course, as noted above, LRA refuses to assign two output operands to the same register, so this was never going to work. The solution I'm proposing here is to collapse the alternatives to the CAS insn (allowing the two output register operands to be matched to different registers) and to ensure that the constraints for cbranchsi4_scratch are met in arm_split_compare_and_swap. We do this by inserting a move to ensure the source and destination registers match if necessary (i.e. in the case of large negative immediates). Another notable change here is that we only do: emit_move_insn (neg_bval, const1_rtx); for non-negative immediates. This is because the ADDS instruction used in the negative case suffices to leave a suitable value in neg_bval: if the operands compare equal, we don't take the branch (so neg_bval will be set by the load exclusive). Otherwise, the ADDS will leave a nonzero value in neg_bval, which will correctly signal that the CAS has failed when it is later negated. Co-Authored-By: Christophe Lyon gcc/ChangeLog: PR target/99977 * config/arm/arm.c (arm_split_compare_and_swap): Fix up codegen with negative immediates: ensure we expand cbranchsi4_scratch correctly and ensure we satisfy its constraints. * config/arm/sync.md (@atomic_compare_and_swap_1): Don't attempt to tie two output operands together with constraints; collapse two alternatives. (@atomic_compare_and_swap_1): Likewise. * config/arm/thumb1.md (cbranchsi4_neg_late): New. gcc/testsuite/ChangeLog: PR target/99977 * gcc.target/arm/pr99977.c: New test.
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 --- Comment #12 from CVS Commits --- The releases/gcc-11 branch has been updated by Joern Rennecke : https://gcc.gnu.org/g:5f772bd9847cdbf6a7a6d856de87cb65472d56f4 commit r11-8446-g5f772bd9847cdbf6a7a6d856de87cb65472d56f4 Author: Joern Rennecke Date: Thu May 20 13:21:41 2021 +0100 libstdc++: Disable floating_to_chars.cc on 16 bit targets This patch conditionally disables the compilation of floating_to_chars.cc on 16 bit targets, thus fixing a build failure for these targets as the POW10_SPLIT_2 array exceeds the maximum object size. libstdc++-v3/ PR libstdc++/100361 * include/std/charconv (to_chars): Hide the overloads for floating-point types for 16 bit targets. * src/c++17/floating_to_chars.cc: Don't compile for 16 bit targets. * testsuite/20_util/to_chars/double.cc: Run this test only on size32plus targets. * testsuite/20_util/to_chars/float.cc: Likewise. * testsuite/20_util/to_chars/long_double.cc: Likewise.
[Bug testsuite/100655] 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100655 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug target/100703] __vector_pair and __vector_quad cannot be passed by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100703
--- Comment #1 from Alexander Grund ---
It goes further: Even the usual conversion rules for pointer types don't apply:
void foo(__vector_pair*){}
void bar(const __vector_pair*){}
int main(){
__vector_pair p;
foo(p); // works
bar(p); // fails
}
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #218 from dave.anglin at bell dot net --- On 2021-05-20 5:19 a.m., jvb at cyberscience dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #217 from John Buddery --- > Thanks very much for adding the binutils patch. > > Sorry, I'm new to .md definitions, so I've probably got this wrong. Did you > mean something like: > > (define_insn "call_nogp_longcall" > [(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s")) > (const_int 0)) >(clobber (match_operand:DI 1 "register_operand" "=b,b"))] > "TARGET_HPUX && ia64_tune == PROCESSOR_ITANIUM2" > "@ >br.call%+.many %1 = %0 >brl.call%+.many %1 = %0" > [(set_attr "itanium_class" "br,scall")]) > > (define_insn "call_nogp" > [(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s")) > (const_int 0)) >(clobber (match_operand:DI 1 "register_operand" "=b,b"))] > "" > "br.call%+.many %1 = %0" > [(set_attr "itanium_class" "br,scall")]) > > I assume you need a second instruction to catch the case where the condition > doesn't match ? Yes. Note that the call_nogp pattern is output directly in a couple of places in ia64.c. These will need adjustment for hpux. I'm not a ia64 maintainer. I can only apply changes specific to hpux. I have limited knowledge of the ia64 instruction set. In the above, the "brl.call" alternative apples to the "s" constraint for operand 0. Is that what you want? The "br.call" form is used for the disparaged "b" constraint for operand 0. I'm not sure that the scall call attribute is correct for brl. > > Itanium 1 support seems to have been dropped at some point, so -mtune only > accepts options mapping to Itanium2. So, I couldn't test the br case on HP. Then, we don't need to check the ia64_tune in the above.
[Bug target/100701] [12 Regression] wrong code with -O -fschedule-insns2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100701 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com CC|uros at gcc dot gnu.org| --- Comment #2 from Uroš Bizjak --- (In reply to Richard Biener from comment #1) > orq %rdi, %rsi > pshuflw $0, %xmm3, %xmm0 > movq%xmm0, %rbp > and %rbx, %rbp > je .L4 > > Confirmed. Somehow the mmx_andv8qi3 doesn't clobber CC: Eh, stupid me. Let's remove integer regs from the insn patterns for now.
[Bug jit/100688] Add support for link section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688
--- Comment #6 from David Malcolm ---
Thanks for the patch; I like the idea; various nits below:
> diff --git a/gcc/jit/docs/topics/expressions.rst
> b/gcc/jit/docs/topics/expressions.rst
> index 396259ef07e..b39f6c02527 100644
> --- a/gcc/jit/docs/topics/expressions.rst
> +++ b/gcc/jit/docs/topics/expressions.rst
> @@ -539,6 +539,18 @@ where the rvalue is computed by reading from the storage
> area.
>
> in C.
>
> +.. function:: void
> + gcc_jit_lvalue_set_link_section (gcc_jit_lvalue *lvalue,
> + const char *name)
> +
> + Set the link section of a variable; analogous to:
> +
> + .. code-block:: c
> +
> + int variable __attribute__((section(".section")));
> +
> + in C.
Please rename param "name" to "section_name". Your implementation requires
that it be non-NULL (rather than having NULL unset the section), so please
specify that it must be non-NULL in the docs.
Please add the usual "This entrypoint was added in" text to state which API
version it was added in.
> +
> Global variables
>
>
> diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
> index 825a3e172e9..8b0f65e87e8 100644
> --- a/gcc/jit/jit-playback.h
> +++ b/gcc/jit/jit-playback.h
> @@ -650,6 +650,8 @@ public:
>
> private:
>context *m_ctxt;
> +
> +protected:
>tree m_inner;
> };
I think you only use this...
>
> @@ -670,6 +672,12 @@ public:
>rvalue *
>get_address (location *loc);
>
> + void
> + set_link_section (const char* name)
> + {
> +set_decl_section_name (m_inner, name);
> + }
...here, and you can get at rvalue::m_inner using as_tree (), so I don't think
we need to make m_inner protected.
> diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c
> index 117ff70114c..d54f878cc6b 100644
> --- a/gcc/jit/jit-recording.c
> +++ b/gcc/jit/jit-recording.c
> @@ -3713,6 +3713,11 @@ recording::lvalue::get_address (recording::location
> *loc)
>return result;
> }
>
> +void recording::lvalue::set_link_section (const char *name)
> +{
> + m_link_section = new_string (name);
> +}
> +
> /* The implementation of class gcc::jit::recording::param. */
>
> /* Implementation of pure virtual hook recording::memento::replay_into
> @@ -4547,8 +4552,7 @@ recording::block::dump_edges_to_dot (pretty_printer *pp)
> void
> recording::global::replay_into (replayer *r)
> {
> - set_playback_obj (
> -m_initializer
> + playback::lvalue *global = m_initializer
> ? r->new_global_initialized (playback_location (r, m_loc),
>m_kind,
>m_type->playback_type (),
> @@ -4560,7 +4564,12 @@ recording::global::replay_into (replayer *r)
> : r->new_global (playback_location (r, m_loc),
>m_kind,
>m_type->playback_type (),
> - playback_string (m_name)));
> + playback_string (m_name));
> + if (m_link_section != NULL)
> + {
> +global->set_link_section(m_link_section->c_str());
> + }
Coding convention nits: don't use {} when it's just one statement (which I
think is a bad convention, but it is the project's convention).
Missing spaces between function name and open-paren in both calls here.
> + set_playback_obj (global);
> }
>
[...snip]
> diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
> index 03fa1160cf0..0691fac579d 100644
> --- a/gcc/jit/jit-recording.h
> +++ b/gcc/jit/jit-recording.h
> @@ -1105,7 +1105,8 @@ public:
>lvalue (context *ctxt,
> location *loc,
> type *type_)
> -: rvalue (ctxt, loc, type_)
> +: rvalue (ctxt, loc, type_),
> + m_link_section(NULL)
> {}
>
>playback::lvalue *
> @@ -1127,6 +1128,10 @@ public:
>const char *access_as_rvalue (reproducer &r) OVERRIDE;
>virtual const char *access_as_lvalue (reproducer &r);
>virtual bool is_global () const { return false; }
> + void set_link_section (const char *name);
> +
> +protected:
> + string *m_link_section;
> };
Can it be private, rather than protected?
> diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c
> index 7fa948007ad..8cfa48aae24 100644
> --- a/gcc/jit/libgccjit.c
> +++ b/gcc/jit/libgccjit.c
> @@ -1953,6 +1953,18 @@ gcc_jit_lvalue_get_address (gcc_jit_lvalue *lvalue,
>return (gcc_jit_rvalue *)lvalue->get_address (loc);
> }
>
> +/* Public entrypoint. See description in libgccjit.h.
> +
> + After error-checking, the real work is done by the
> + gcc::jit::recording::lvalue::set_section method in jit-recording.c. */
^^^
set_link_section
Also, a newline here please for consistency with the other entrypoints.
> +void
> +gcc_jit_lvalue_set_link_section (gcc_jit_lvalue *lvalue,
> + const char *name)
> +{
> + RETURN_IF_FAIL (name, NULL, NULL, "NULL n
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #219 from John Buddery --- Great, thanks - I'll look at ia64.c and build and test with that change. Yes, "b" on ia64 seems to be a branch register, and the brl op only accepts immediate values not registers. Initially I hoped the assembler would patch this up and accept both, but it doesn't so the two variants are needed. I'll look into the scall attribute as well.
[Bug jit/100688] Add support for link section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688
--- Comment #7 from David Malcolm ---
One other thing: the docs should make it clear about the leading ".".
If I want to create the equivalent of:
__attribute__((section(".section")))
do I call it with:
gcc_jit_lvalue_set_link_section(foo, "section");
or with:
gcc_jit_lvalue_set_link_section(foo, ".section");
It's a bit unclear to me from just reading the patch. The example suggests
it's the former. In either case, the documentation should be clearer about
this.
[Bug gcov-profile/100145] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100145 --- Comment #3 from Richard Biener --- Note after inlining we still have a backedge into BB 3: [local count: 1073741824]: c = 0; b.1_7 = b; if (b.1_7 != 0) goto ; [34.00%] else goto ; [66.00%] [local count: 3318838410]: _9 = 1; _10 = 0; _11 = _9 & _10; if (_11 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 1659419208]: _12 = 0; _13 = _10 & _12; if (_13 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 829709603]: iftmp.0_14 = 1; [local count: 3318838410]: # iftmp.0_15 = PHI <0(3), 0(4), iftmp.0_14(5)> _19 = iftmp.0_15; _8 = _19; c = _8; if (_8 != 0) goto ; [11.00%] else goto ; [89.00%] [local count: 1073741824]: but that's quickly elided by CCP after inlining producing [local count: 1073741824]: c = 0; b.1_7 = b; if (b.1_7 != 0) goto ; [34.00%] else goto ; [66.00%] [local count: 3318838410]: if (0 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 1659419208]: if (0 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 829709603]: [local count: 3318838410]: c = 1; if (1 != 0) goto ; [11.00%] else goto ; [89.00%] [local count: 1073741824]: and the CFG cleanup ends up with the following: [local count: 1073741824]: c = 0; b.1_7 = b; if (b.1_7 != 0) goto ; [34.00%] else goto ; [66.00%] [local count: 3318838410]: c = 1; [local count: 1073741824]: d = 1; _1 = c; if (_1 > 100) goto ; [33.00%] else goto ; [67.00%] [local count: 354334800]: foo (); [local count: 1073741824]: return 0;
[Bug target/100704] New: Vector register isn't used to push BLKmode argument onto stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100704
Bug ID: 100704
Summary: Vector register isn't used to push BLKmode argument
onto stack
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, ubizjak at gmail dot com
Target Milestone: ---
Target: i386,x86-64
[hjl@gnu-cfl-2 gcc]$ cat /tmp/x.c
struct S
{
long long s1 __attribute__ ((aligned (8)));
unsigned s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, s13, s14;
};
extern struct S array[];
void bar (struct S x);
void
foo (void)
{
bar (array[0]);
}
[hjl@gnu-cfl-2 gcc]$ gcc -S -O2 /tmp/x.c
[hjl@gnu-cfl-2 gcc]$ cat x.s
.file "x.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
pushq array+56(%rip)
.cfi_def_cfa_offset 24
pushq array+48(%rip)
.cfi_def_cfa_offset 32
pushq array+40(%rip)
.cfi_def_cfa_offset 40
pushq array+32(%rip)
.cfi_def_cfa_offset 48
pushq array+24(%rip)
.cfi_def_cfa_offset 56
pushq array+16(%rip)
.cfi_def_cfa_offset 64
pushq array+8(%rip)
.cfi_def_cfa_offset 72
pushq array(%rip)
.cfi_def_cfa_offset 80
callbar
addq$72, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 11.1.1 20210428 (Red Hat 11.1.1-1)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 gcc]$
[hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S -O2 /tmp/x.c -mno-push-args
[hjl@gnu-cfl-2 gcc]$ cat x.s
.file "x.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
subq$72, %rsp
.cfi_def_cfa_offset 80
movdqu array(%rip), %xmm0
movdqu array+16(%rip), %xmm1
movdqu array+32(%rip), %xmm2
movdqu array+48(%rip), %xmm3
movups %xmm0, (%rsp)
movups %xmm1, 16(%rsp)
movups %xmm2, 32(%rsp)
movups %xmm3, 48(%rsp)
callbar
addq$72, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 12.0.0 20210519 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 gcc]$
There is
#define PUSH_ARGS (TARGET_PUSH_ARGS && !ACCUMULATE_OUTGOING_ARGS)
Can we update PUSH_ARGS to also check function arguments?
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #220 from dave.anglin at bell dot net --- On 2021-05-20 9:37 a.m., jvb at cyberscience dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #219 from John Buddery --- > Great, thanks - I'll look at ia64.c and build and test with that change. Instead of creating a separate HPUX pattern, another way might be to setup an instruction alternative table. See define_insn for prefetch.
[Bug analyzer/100705] New: warn about dead store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100705
Bug ID: 100705
Summary: warn about dead store
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: mail at milianw dot de
Target Milestone: ---
Hey there,
in a large code base I'm working on I stumbled over code in one area that
basically did the below, but in a more elaborate manner. It would have been
quite helpful to get a warning when `-fanalyzer` is passed, because in my
opinion, this code is bogus:
```
struct Properties
{
int foo = 0;
int bar = 0;
};
Properties asdf()
{
Properties ret;
ret.foo = 42; // warning: this has no effect
ret.bar = 1;
ret.foo = 12; // b/c it's unconditionally overwritten here
return ret;
}
```
Thanks
[Bug target/100704] Vector register isn't used to push BLKmode argument onto stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100704 --- Comment #1 from Richard Biener --- Hmm, I didn't realize we can't push %xmm regs... With loads+stores the pushes do not look less efficient for this particular example? I suppose a nice architectural enhancement would be a push-multiple - rep pushq anyone? ;)
[Bug c++/100675] std::string_view::find in constexpr function is not constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100675 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Patrick Palka --- Already fixed on trunk by r11-3295 (and also fixed for 10.4). This seems like ultimately a variant of PR97051, with the is_constant_evaluated() call instead deeply nested. *** This bug has been marked as a duplicate of bug 97051 ***
[Bug c++/97051] Evaluating is_constant_evaluated in requires clause fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97051 Patrick Palka changed: What|Removed |Added CC||hewillk at gmail dot com --- Comment #7 from Patrick Palka --- *** Bug 100675 has been marked as a duplicate of this bug. ***
[Bug libstdc++/100690] ranges::iota_view::_Sentinel cannot access _M_current of _Iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100690 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-20 CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #221 from John Buddery ---
Thanks - that is neater, as it avoids the need to change the calls in ia64.c,
which gets messy.
The simplest variant I have is:
(define_insn "call_nogp"
[(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s"))
(const_int 0))
(clobber (match_operand:DI 1 "register_operand" "=b,b"))]
""
{
if (TARGET_HPUX && which_alternative == 1 )
return "brl.call%+.many %1 = %0";
else
return "br.call%+.many %1 = %0";
}
[(set_attr "itanium_class" "br,scall")])
but I need to work out how to vary the attribute, as you were right: scall maps
to a "B" type attribute, but brl is an L+X instruction not a pure B unit
instruction, so I think it should be type "L".
Looks like cond and match-test are valid for attributes, so it should be
possible to get this right.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #222 from dave.anglin at bell dot net --- On 2021-05-20 10:02 a.m., dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #220 from dave.anglin at bell dot net --- > On 2021-05-20 9:37 a.m., jvb at cyberscience dot com wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 >> >> --- Comment #219 from John Buddery --- >> Great, thanks - I'll look at ia64.c and build and test with that change. > Instead of creating a separate HPUX pattern, another way might be to setup > an instruction alternative table. See define_insn for prefetch. There is a which_alternative variable that could be used to check for "s" constraint (e.g., "which_alternative == 1").
[Bug ada/60977] Float_IO.Put fails on large floats when 'digits exceeds 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60977 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |11.0 --- Comment #2 from Eric Botcazou --- Fixed in GCC 11 and later.
[Bug testsuite/96488] failures of gnat.dg/unchecked_convert[56].adb on PowerPC64 LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96488 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED Summary|failures of |failures of |gnat.dg/unchecked_convert5. |gnat.dg/unchecked_convert[5 |adb and |6].adb on PowerPC64 LE |gnat.dg/unchecked_convert6. | |adb | Component|ada |testsuite
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #223 from dave.anglin at bell dot net ---
On 2021-05-20 10:59 a.m., jvb at cyberscience dot com wrote:
> The simplest variant I have is:
>
> (define_insn "call_nogp"
> [(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s"))
> (const_int 0))
>(clobber (match_operand:DI 1 "register_operand" "=b,b"))]
> ""
> {
> if (TARGET_HPUX && which_alternative == 1 )
> return "brl.call%+.many %1 = %0";
> else
> return "br.call%+.many %1 = %0";
> }
This looks good.
I agree it should be possible to get the attribute right for brl.
[Bug testsuite/96488] failures of gnat.dg/unchecked_convert[56].adb on PowerPC64 LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96488 --- Comment #2 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:325bb080259d3a00c5f5a7378872f78a2b889dfb commit r12-943-g325bb080259d3a00c5f5a7378872f78a2b889dfb Author: Eric Botcazou Date: Thu May 20 17:12:11 2021 +0200 Fix gnat.dg spurious failures on PowerPC64 LE gcc/testsuite PR testsuite/96488 * gnat.dg/unchecked_convert5.adb: Do not run on PowerPC64 LE. * gnat.dg/unchecked_convert6.adb: Likewise.
[Bug testsuite/96488] failures of gnat.dg/unchecked_convert[56].adb on PowerPC64 LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96488 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:a470d058707bf3e555f30adc68237f422d0a7d47 commit r11-8447-ga470d058707bf3e555f30adc68237f422d0a7d47 Author: Eric Botcazou Date: Thu May 20 17:12:11 2021 +0200 Fix gnat.dg spurious failures on PowerPC64 LE gcc/testsuite PR testsuite/96488 * gnat.dg/unchecked_convert5.adb: Do not run on PowerPC64 LE. * gnat.dg/unchecked_convert6.adb: Likewise.
[Bug testsuite/96488] failures of gnat.dg/unchecked_convert[56].adb on PowerPC64 LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96488 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:a4b3683e3cb00459eb74d1a37be8936abd529865 commit r10-9839-ga4b3683e3cb00459eb74d1a37be8936abd529865 Author: Eric Botcazou Date: Thu May 20 17:12:11 2021 +0200 Fix gnat.dg spurious failures on PowerPC64 LE gcc/testsuite PR testsuite/96488 * gnat.dg/unchecked_convert5.adb: Do not run on PowerPC64 LE. * gnat.dg/unchecked_convert6.adb: Likewise.
[Bug c++/100281] ICE with SImode pointer assignment in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100281 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Andreas Krebbel : https://gcc.gnu.org/g:e43f47686980e9d0081aa765b619bdc89189b51a commit r11-8448-ge43f47686980e9d0081aa765b619bdc89189b51a Author: Andreas Krebbel Date: Tue Apr 27 10:09:06 2021 +0200 PR100281 C++: Fix SImode pointer handling The problem appears to be triggered by two locations in the front-end where non-POINTER_SIZE pointers aren't handled right now. 1. An assertion in strip_typedefs is triggered because the alignment of the types don't match. This in turn is caused by creating the new type with build_pointer_type instead of taking the type of the original pointer into account. 2. An assertion in cp_convert_to_pointer is triggered which expects the target type to always have POINTER_SIZE. gcc/cp/ChangeLog: PR c++/100281 * cvt.c (cp_convert_to_pointer): Use the size of the target pointer type. * tree.c (cp_build_reference_type): Call cp_build_reference_type_for_mode with VOIDmode. (cp_build_reference_type_for_mode): Rename from cp_build_reference_type. Add MODE argument and invoke build_reference_type_for_mode. (strip_typedefs): Use build_pointer_type_for_mode and cp_build_reference_type_for_mode for pointers and references. gcc/ChangeLog: PR c++/100281 * tree.c (build_reference_type_for_mode) (build_pointer_type_for_mode): Pick pointer mode if MODE argument is VOIDmode. (build_reference_type, build_pointer_type): Invoke build_*_type_for_mode with VOIDmode. gcc/testsuite/ChangeLog: PR c++/100281 * g++.target/s390/pr100281-1.C: New test. * g++.target/s390/pr100281-2.C: New test. (cherry picked from commit 720dff974ea0487c35c0a4bfa527f30df5066ce1)
[Bug testsuite/96488] failures of gnat.dg/unchecked_convert[56].adb on PowerPC64 LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96488 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:5bd98868260de9cfc44224cf3833eb86e95d7c47 commit r9-9544-g5bd98868260de9cfc44224cf3833eb86e95d7c47 Author: Eric Botcazou Date: Thu May 20 17:12:11 2021 +0200 Fix gnat.dg spurious failures on PowerPC64 LE gcc/testsuite PR testsuite/96488 * gnat.dg/unchecked_convert5.adb: Do not run on PowerPC64 LE. * gnat.dg/unchecked_convert6.adb: Likewise.
[Bug testsuite/96488] failures of gnat.dg/unchecked_convert[56].adb on PowerPC64 LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96488 Eric Botcazou changed: What|Removed |Added Target Milestone|--- |9.4 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Eric Botcazou --- .
[Bug target/100704] Vector register isn't used to push BLKmode argument onto stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100704 --- Comment #2 from H.J. Lu --- (In reply to Richard Biener from comment #1) > Hmm, I didn't realize we can't push %xmm regs... With loads+stores the > pushes do not look less efficient for this particular example? I suppose a > nice > architectural enhancement would be a push-multiple - rep pushq anyone? ;) YMM and ZMM load/store is much more efficient.
[Bug target/100706] New: Invalid instructions in plt calls on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100706
Bug ID: 100706
Summary: Invalid instructions in plt calls on PPC
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: alexander.gr...@tu-dresden.de
Target Milestone: ---
This turns up when compiling TensorFlow 2.5.0 on ppc9le. I wasn't yet able to
reduce the code to reproduce it with a small example, so only got the
following:
The relevant code is this:
mutex.h:
struct MuData {
void* space[2];
};
struct mutex{
mutex();
MuData m_;
};
--
mutex.cc:
#include "mutex.h"
#include "nsync_mu.h"
static inline nsync::nsync_mu *mu_cast(MuData *mu) {
return reinterpret_cast(mu);
}
mutex::mutex() { nsync::nsync_mu_init(mu_cast(&mu_)); }
--
This is compiled into a shared library with the following compile command: `gcc
-U_FORTIFY_SOURCE -fstack-protector -fno-omit-frame-pointer -g0
'-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections -fdata-sections -O3
'-mcpu=native' -fno-math-errno -fPIC '-std=c++14'
-fno-canonical-system-headers`
Linker flags used later are `-Wl,-no-as-needed -Wl,-z,relro,-z,now
-Wl,--gc-sections`
The nsync library is from https://github.com/google/nsync (version 1.24)
An instance of the mutex class is than later created by an application linked
against this shared library during init (i.e. in a static global context) and
that raises an SIGILL.
Doing that manually I see a plt_call being made which looks like this:
Dump of assembler code for function
.plt_call._ZN5nsync13nsync_mu_initEPNS_11nsync_mu_s_E:
0x20074900 <+0>: std r2,24(r1)
0x20074904 <+4>: ld r12,-32584(r2)
0x20074908 <+8>: mtctr r12
0x2007490c <+12>:bctr
0x20074910 <+16>:.long 0x0
0x20074914 <+20>:.long 0x0
0x20074918 <+24>:.long 0x0
0x2007491c <+28>:.long 0x0
This looks good and works (as mentioned my reduced example didn't run into the
problem)
The TF compiled version of this plt call looks like this:
Dump of assembler code for function
0003.plt_call._ZN5nsync13nsync_mu_initEPNS_11nsync_mu_s_E:
0x200b19851660 <+0>: std r2,24(r1)
0x200b19851664 <+4>: nop
=> 0x200b19851668 <+8>: .long 0x41004ce
0x200b1985166c <+12>:lfdpf12,264(0)
0x200b19851670 <+16>:mtctr r12
0x200b19851674 <+20>:bctr
0x200b19851678 <+24>:.long 0x0
0x200b1985167c <+28>:.long 0x0
As you can see something inserted a strange value into the asm code. I'm not
sure if gcc or the linker (gold linker used here) creates those plt calls, but
something is obviously wrong here.
I also checked another call into the nsync library: nsync::nsync_mu_lock
The plt call looks very similar:
Dump of assembler code for function
0003.plt_call._ZN5nsync13nsync_mu_lockEPNS_11nsync_mu_s_E:
0x200b19851680 <+0>: std r2,24(r1)
0x200b19851684 <+4>: nop
0x200b19851688 <+8>: .long 0x41004ce
0x200b1985168c <+12>:lfdpf12,240(0)
0x200b19851690 <+16>:mtctr r12
0x200b19851694 <+20>:bctr
0x200b19851698 <+24>:.long 0x0
0x200b1985169c <+28>:.long 0x0
As you can see the constant inserted and everything else but the lfdp offset is
the same.
I hope that is enough to find the problem. I'm happy to provide more insight or
do some further tests if required. However I'm not a PPC expert so I have no
idea where to go further with that.
[Bug c++/100646] [11 Regression] gcc -E -fdirectives-only causes "error: unterminated comment" when no new line at the end of file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100646 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|[11/12 Regression] gcc -E |[11 Regression] gcc -E |-fdirectives-only causes|-fdirectives-only causes |"error: unterminated|"error: unterminated |comment" when no new line |comment" when no new line |at the end of file |at the end of file --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/100707] New: [modules] ICE on nested namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100707
Bug ID: 100707
Summary: [modules] ICE on nested namespace
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amorvincitomnia.iw at gmail dot com
Target Milestone: ---
See it live: https://wandbox.org/permlink/HOMZ2A8ClOzIKXO1
Minimum code to reproduce ICE:
// m3.cc
export module m3;
export namespace A{
}
// m2.cc
export module m2;
import m3;
export namespace A::B{
}
// m1.cc
export module m1;
import m2;
export namespace A::B{
}
Compile it with:
$ g++ "-std=gnu++20" "-fmodules-ts" "m3.cc" "m2.cc" "m1.cc"
Produces the following ICE:
m1.cc:3:21: internal compiler error: in resume_scope, at cp/name-lookup.c:4417
3 | export namespace A::B{
| ^
0x5f4ed6 resume_scope
../../source/gcc/cp/name-lookup.c:4417
0x7328fb push_namespace(tree_node*, bool)
../../source/gcc/cp/name-lookup.c:8882
0x779b37 cp_parser_namespace_definition
../../source/gcc/cp/parser.c:20475
0x77a458 cp_parser_declaration
../../source/gcc/cp/parser.c:14141
0x77a153 cp_parser_module_export
../../source/gcc/cp/parser.c:13951
0x77a153 cp_parser_declaration
../../source/gcc/cp/parser.c:14104
0x77ac4e cp_parser_toplevel_declaration
../../source/gcc/cp/parser.c:14190
0x77ac4e cp_parser_translation_unit
../../source/gcc/cp/parser.c:4942
0x77ac4e c_parse_file()
../../source/gcc/cp/parser.c:45393
0x84b7dd c_common_parse_file()
../../source/gcc/c-family/c-opts.c:1218
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/100707] [modules] ICE on nested namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100707
--- Comment #1 from wang ivor ---
A quick workaround: https://wandbox.org/permlink/n8E5xJuJhq1CUA0e
Create a module that only contains the namespace declaration, and 'export
import' it whenever you declare a new namespace.
// namespace_decl.cc
export module namespace_decl;
export namespace A::B{
}
// m2.cc
export module m2;
export import namespace_decl;
import m3;
export namespace A::B{
}
[Bug c/100661] [11/12 Regression] ICE in omp-low.c / refs_may_alias_p_2, at tree-ssa-alias.c:2460
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100661
Jakub Jelinek changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org,
||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Slightly better testcase:
void
foo (char **x)
{
#pragma omp parallel for
for (int i = 0; i < 16; i++)
{
char c[50];
__builtin_strcpy (c, x[i]);
void bar (void)
{
__builtin_strcat (c, "foo");
}
}
}
This ICEs all the way back to GCC 4.2/4.3. And I'm not sure what can be done
about it. Nested functions are implemented by adding all the variables that
can be accessed from nested functions into a single large frame structure whose
address is passed in the chain argument to the nested function.
But, in the above case, the c array is such a variable, but each thread is
supposed to have a private copy of that variable.
For C, this is a GNU extension and we can do whatever we want, including sorry.
For Fortran, nested functions can be only defined outside of BLOCK and when one
explicitly privatizes some variable, access to them from the nested functions
could be considered UB (like would be e.g. if in C/C++ one privatizes a
variable, but passes (shared or firstprivate or in some global variable)
address of the variable before being privatized and accesses that var through
the pointer).
[Bug target/100701] [12 Regression] wrong code with -O -fschedule-insns2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100701 --- Comment #3 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:a71f55c482ada2c6c31d450ac22494b547512127 commit r12-945-ga71f55c482ada2c6c31d450ac22494b547512127 Author: Uros Bizjak Date: Thu May 20 18:48:16 2021 +0200 i386: Avoid integer logic insns for 32bit and 64bit vector modes [PR100701] Integer logic instructions clobber flags, do not use them for 32bit and 64bit vector modes. 2021-05-20 Uroš Bizjak gcc/ PR target/100701 * config/i386/i386.md (isa): Remove x64_bmi. (enabled): Remove x64_bmi. * config/i386/mmx.md (mmx_andnot3): Remove general register alternative. (*andnot3): Ditto. (*mmx_3): Ditto. (*3): Ditto. gcc/testsuite/ PR target/100701 * gcc.target/i386/pr100701.c: New test.
[Bug target/100701] [12 Regression] wrong code with -O -fschedule-insns2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100701 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Uroš Bizjak --- Fixed.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #224 from dave.anglin at bell dot net --- On 2021-05-20 10:59 a.m., jvb at cyberscience dot com wrote: > but I need to work out how to vary the attribute, as you were right: scall > maps > to a "B" type attribute, but brl is an L+X instruction not a pure B unit > instruction, so I think it should be type "L". I think brl needs its own class. Currently, long_i (for movl) and nop_x (for nop.x) map to type "L". The brl class should also map to type "L" but its bypass behavior should be similar to scall.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #225 from John Buddery --- Yes, I looked briefly at that - I added a new class, but then started hitting bundling errors because it wasn't being positioned correctly in the 3 instruction bundle. It will need more changes to itanium2.md, which looks at the actual itanium_class rather than just the derived type as I was expecting, and fixes the bundling for long_i only (rather than type L). For now I've reverted to scall to test the other changes - this seems to work, probably because the assembler is fixing up any bundling issues This isn't really right though, as you say it needs combined long_i and scall behaviour for a new type.
[Bug c/100702] Strict overflow warning regression in gcc 8 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100702 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Severity|normal |enhancement Last reconfirmed||2021-05-20 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Martin Sebor --- It should be possible to detect the wide-spread 'i < i + 1' anipattern in the front ends without too many false positives (with __builtin_warning it should even be able to avoid them in dead code). Let me confirm this request on that basis.
[Bug c++/100700] -Wreturn-type has many false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Severity|normal |enhancement
--- Comment #1 from Martin Sebor ---
[Please include the full command line and the full compiler output in bug
reports (as requested in https://gcc.gnu.org/bugs/#need). Links to third party
sites are not a substitute (they can go away and the compiler versions they use
can change).]
$ cat pr100700.c && gcc -S -xc++ pr100700.c
int f(unsigned i) {
if (i < unsigned(-1)) return i;
}
enum E { A, B };
int h (enum E e) {
switch (e) {
case A: return 0;
case B: return 0;
}
}
pr100700.c: In function ‘int f(unsigned int)’:
pr100700.c:4:1: warning: control reaches end of non-void function
[-Wreturn-type]
4 | }
| ^
pr100700.c: In function ‘int h(E)’:
pr100700.c:13:1: warning: control reaches end of non-void function
[-Wreturn-type]
13 | }
| ^
In both examples the warning is strictly correct: in a call to f(-1) the
function falls off the end, and ditto in a call to h ((enum E)2). I could see
value in relaxing the warning for the enum case and issuing it only under some
stricter setting (say with -Wextra or under a new level), similarly to
-Wswitch-default. I think there already is a request along these lines.
[Bug target/100706] Invalid instructions in plt calls on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100706 --- Comment #1 from Andrew Pinski --- GCC does not generate the PLTs directly normally. It is the linker. Does using BFD ld instead of gold fix the issue?
[Bug libstdc++/100639] reverse_iterator::reference erroneously uses iterator_traits::reference instead of iter_reference_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100639 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:d5cbe0f0d4b7bc11f80b2236521f90ec94e95767 commit r12-946-gd5cbe0f0d4b7bc11f80b2236521f90ec94e95767 Author: Patrick Palka Date: Thu May 20 14:08:17 2021 -0400 libstdc++: Implement missing P0896R4 changes to reverse_iterator [PR100639] This implements the P0896R4 changes to reverse_iterator's member types value_type, difference_type and reference in C++20 mode, which fixes taking the reverse_iterator of an iterator with a non-integral difference_type (such as iota_view). libstdc++-v3/ChangeLog: PR libstdc++/100639 * include/bits/stl_iterator.h (reverse_iterator::difference_type): In C++20 mode, define in terms of iter_difference_t as per P0896R4. (reverse_iterator::reference): Likewise, but with iter_reference_t. (reverse_iterator::value_type): Likewise, but with iter_value_t. * testsuite/std/ranges/adaptors/reverse.cc (test08): New test. * testsuite/24_iterators/reverse_iterator/100639.cc: New test.
[Bug tree-optimization/100696] mult_higpart is not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100696 Uroš Bizjak changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #2 from Uroš Bizjak --- Related: PR89386. CC added.
[Bug tree-optimization/88240] [9 Regression] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240 --- Comment #23 from Thomas De Schampheleire --- Thanks a lot!
[Bug testsuite/100655] 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100655 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #6 from Bernd Edlinger --- Jonathan, what was the problem why you wanted to add the dg-shouldfail ?
[Bug fortran/92065] [9/10/11/12 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #27 from anlauf at gcc dot gnu.org --- The code seems to compile with today's trunk, but still fails with 11-branch. Could one of Paul's recent commits have fixed this? If so, a backport might be nice.
[Bug c++/100700] -Wreturn-type has many false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700 --- Comment #2 from gnzlbg --- > in a call to f(-1) the function falls off the end, Indeed, thanks. Using <= in the condition removes the warning. > and ditto in a call to h ((enum E)2) Until C++17, creating an enum value that's out-of-range of the enum was unspecified behavior. In C++ standard >= 17 (e.g. -std=c++17), this became undefined behavior. So the warning should point at the place where this happens: (enum E)2. The only way in which "h(E e)" can fall of its end in C++>=17 is if the program already had undefined behavior.
[Bug middle-end/100684] spurious -Wnonnull with -O1 on a C++ lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100684 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:9480491a6447576e8e695b8ea3c4989cf72c9670 commit r12-948-g9480491a6447576e8e695b8ea3c4989cf72c9670 Author: Martin Sebor Date: Thu May 20 13:15:58 2021 -0600 PR middle-end/100684 - spurious -Wnonnull with -O1 on a C++ lambda gcc/ChangeLog: PR middle-end/100684 * tree-ssa-ccp.c (pass_post_ipa_warn::execute): Handle C++ lambda. gcc/testsuite/ChangeLog: PR middle-end/100684 * g++.dg/warn/Wnonnull13.C: New test. * g++.dg/warn/Wnonnull14.C: New test. * g++.dg/warn/Wnonnull15.C: New test.
[Bug middle-end/100684] [11 Regression] spurious -Wnonnull with -O1 on a C++ lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100684 Martin Sebor changed: What|Removed |Added Summary|spurious -Wnonnull with -O1 |[11 Regression] spurious |on a C++ lambda |-Wnonnull with -O1 on a C++ ||lambda Known to fail|12.0| --- Comment #4 from Martin Sebor --- Fixed on trunk. Will backport to 11.2.
[Bug c++/99611] Code compilation issue using templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99611 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- Thanks for the bug report. This looks like a dup of PR51577, which has recently been partially fixed on trunk. *** This bug has been marked as a duplicate of bug 51577 ***
[Bug c++/51577] dependent name lookup finds operator in global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 Patrick Palka changed: What|Removed |Added CC||asif_bahrainwala at hotmail dot co ||m --- Comment #21 from Patrick Palka --- *** Bug 99611 has been marked as a duplicate of this bug. ***
[Bug c++/100708] New: dynamic_cast can convert xvalue to lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100708
Bug ID: 100708
Summary: dynamic_cast can convert xvalue to lvalue
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
GCC accepts
struct A { virtual ~A() {}; };
struct B : A {} b;
void g ()
{
dynamic_cast(static_cast(b));
}
[expr.dynamic.cast]/2 says that for dynamic_cast(v):
If T is an lvalue reference type, v shall be an lvalue of a complete class
type, and the result is an lvalue of the type referred to by T.
[Bug c++/100700] -Wreturn-type has many false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700 --- Comment #3 from Jonathan Wakely --- (In reply to gnzlbg from comment #2) > Until C++17, creating an enum value that's out-of-range of the enum was > unspecified behavior. In C++ standard >= 17 (e.g. -std=c++17), this became > undefined behavior. With GCC it depends on the -fstrict-enums option. > The only way in which "h(E e)" can fall of its end in C++>=17 is if the > program already had undefined behavior. That's true if you use -fstrict-enums, and if you do that, there's no warning. Without that option GCC does not treat (E)2 as undefined, and so it considers it possible for the function to be called with that value.
[Bug c++/100709] New: Use of a function parameter pack in an expression expected to be constexpr in a deduction guide produces an unclear diagnostic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100709 Bug ID: 100709 Summary: Use of a function parameter pack in an expression expected to be constexpr in a deduction guide produces an unclear diagnostic. Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: brycelelbach at gmail dot com Target Milestone: --- Use of a function parameter pack in an expression expected to be `constexpr` in a deduction guide leads to an unclear diagnostic. Such code should be ill-formed, because a function parameter pack is not `constexpr` itself, so it can't be used in a `constexpr` context. Use a function parameter pack in an expression expected to be `constexpr` in other contexts, like in a function body, does produce a good diagnostic, which points to the problematic line of code and names the problematic function parameter pack (`i`) - or at least, names the expansion of it to its elements. I found this diagnostic sufficient to understand the issue. You can see both cases here: https://godbolt.org/z/4joWjejMn
[Bug c++/100708] dynamic_cast can convert xvalue to lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100708 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-20 Ever confirmed|0 |1
[Bug target/100694] PPC: initialization of __int128 is very inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100694 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2021-05-20 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Segher Boessenkool --- The important difference between powerpc64 and aarch64 is that the store is in TImode for powerpc64, but as two DImode stores for aarch64, right after expand already (and before expand the code was identical). Confirmed.
[Bug fortran/100656] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100656 --- Comment #2 from anlauf at gcc dot gnu.org --- Using a temporary may help: subroutine s(x) character(:), allocatable, optional :: x(:) character(:), allocatable :: y(:) if ( present(x) ) then if ( allocated(x) ) then y = 'a' // x // 'e' x = y end if end if end This does not ICE.
[Bug c++/100710] New: static_cast to derived* of base* pointing to non-static data member of base type not rejected in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100710
Bug ID: 100710
Summary: static_cast to derived* of base* pointing to
non-static data member of base type not rejected in
constant expression
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.e.cobb at gmail dot com
Target Milestone: ---
In the following code:
[code]
class B {};
class D : public B {
public:
B member;
};
constexpr bool test(bool do_ub = true) {
if (do_ub) {
D d;
return static_cast(&d.member) != nullptr;
}
return false;
}
static_assert(test());
[/code]
On Compiler Explorer: https://godbolt.org/z/eKEcT7bhb
GCC 11.1 accepts when it should reject due to the static_cast being UB during
the evaluation of a constant expression, as the pointer to B does not actually
point to a base class subobject of an object of type D.
>From [expr.static.cast]/11:
> If the prvalue of type “pointer to cv1 B” points to a B that is actually a
> subobject of an object of type D, the resulting pointer points to the
> enclosing object of type D. Otherwise, the behavior is undefined.
This wording is slightly broken because it says "actually a subobject" instead
of "actually a base class subobject", but there is an editorial PR to fix this:
https://github.com/cplusplus/draft/pull/4605
[Bug libstdc++/100676] Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100676 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:6b42b5a8a207de5e021a2916281f46bcd60b20d2 commit r12-952-g6b42b5a8a207de5e021a2916281f46bcd60b20d2 Author: Jonathan Wakely Date: Thu May 20 16:39:06 2021 +0100 libstdc++: Use __builtin_unreachable for constexpr assertions [PR 100676] The current implementation of compile-time precondition checks causes compilation to fail by calling a non-constexpr function declared at block scope. This breaks the CUDA compiler, which wraps some libstdc++ headers in a pragma that declares everything as a __host__ __device__ function, but others are not wrapped and so everything is a __host__ function. The local declaration thus gets redeclared as two different types of function, which doesn't work. Just use __builtin_unreachable to make constant evaluation fail, instead of the local function declaration. Also simplify the assertion macros, which has the side effect of giving simpler compilation errors when using Clang. libstdc++-v3/ChangeLog: PR libstdc++/100676 * include/bits/c++config (__glibcxx_assert_1): Rename to ... (__glibcxx_constexpr_assert): ... this. (__glibcxx_assert_impl): Use __glibcxx_constexpr_assert. (__glibcxx_assert): Define as either __glibcxx_constexpr_assert or __glibcxx_assert_impl. (__glibcxx_assert_2): Remove * include/debug/macros.h (_GLIBCXX_DEBUG_VERIFY_AT_F): Use __glibcxx_constexpr_assert instead of __glibcxx_assert_1. * testsuite/21_strings/basic_string_view/element_access/char/back_constexpr_neg.cc: Adjust expected error. * testsuite/21_strings/basic_string_view/element_access/char/constexpr_neg.cc: Likewise. * testsuite/21_strings/basic_string_view/element_access/char/front_constexpr_neg.cc: Likewise. Likewise. * testsuite/21_strings/basic_string_view/element_access/wchar_t/back_constexpr_neg.cc: Likewise. * testsuite/21_strings/basic_string_view/element_access/wchar_t/constexpr_neg.cc: Likewise. * testsuite/21_strings/basic_string_view/element_access/wchar_t/front_constexpr_neg.cc: Likewise. * testsuite/23_containers/span/back_neg.cc: Likewise. * testsuite/23_containers/span/front_neg.cc: Likewise. * testsuite/23_containers/span/index_op_neg.cc: Likewise.
