[Bug c++/77796] tautological compare warning emitted for inherited static method comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77796 --- Comment #4 from Eric Gallager --- (In reply to Jonathan Wakely from comment #3) > (In reply to Eric Gallager from comment #2) > > (In reply to Eric Gallager from comment #1) > > > Confirmed. Also, it seems weird that the warning underlines all of > > > B::destroy, but only the "A" in A::destroy: > > > > > > $ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 77796.cc > > > 77796.cc:11:12: warning: self-comparison always evaluates to true > > > [-Wtautological-compare] > > > B::destroy == A::destroy ? 0 : 1 > > > ~~~^~~~ > > > $ > > > > Diagnostics maintainers, do you know what's up with that? > > That was PR 87386, fixed on trunk. Ah, so it is; output is now: $ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 77796.cc 77796.cc:11:12: warning: self-comparison always evaluates to true [-Wtautological-compare] 11 | B::destroy == A::destroy ? 0 : 1 | ~~ ^~ ~~ $
[Bug c/66970] Add __has_builtin() macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970 --- Comment #16 from Martin Sebor --- No progress yet but I agree and I'm still planning to work on it for GCC 10.
[Bug target/91140] New: Regressions on trunk at revision 273226 vs revision 273190
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91140 Bug ID: 91140 Summary: Regressions on trunk at revision 273226 vs revision 273190 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: crazylht at gmail dot com Target Milestone: --- Target: i386, x86-64 New failures: FAIL: gcc.target/i386/avx512vl-vcvttpd2dq-2.c execution test FAIL: gcc.target/i386/avx512vl-vcvttpd2dq-2.c execution test FAIL: gcc.target/i386/avx512vl-vcvttpd2udq-2.c execution test FAIL: gcc.target/i386/avx512vl-vcvttpd2udq-2.c execution test FAIL: gcc.target/i386/avx512vl-vpshldvd-2.c (test for excess errors) FAIL: gcc.target/i386/avx512vl-vpshldvd-2.c (test for excess errors) FAIL: gcc.target/i386/avx512vl-vpshldvd-2.c (test for excess errors) FAIL: gcc.target/i386/avx512vl-vpshldvq-2.c (test for excess errors) FAIL: gcc.target/i386/avx512vl-vpshldvq-2.c (test for excess errors) FAIL: gcc.target/i386/avx512vl-vpshldvq-2.c (test for excess errors) FAIL: gcc.target/i386/avx512vl-vpshrdvd-2.c (test for excess errors) FAIL: gcc.target/i386/avx512vl-vpshrdvd-2.c (test for excess errors) FAIL: gcc.target/i386/avx512vl-vpshrdvd-2.c (test for excess errors) FAIL: gcc.target/i386/avx512vl-vpshrdvq-2.c (test for excess errors) FAIL: gcc.target/i386/avx512vl-vpshrdvq-2.c (test for excess errors) FAIL: gcc.target/i386/avx512vl-vpshrdvq-2.c (test for excess errors) FAIL: maintainers-verify.sh FAIL: maintainers-verify.sh FAIL: maintainers-verify.sh
[Bug other/91139] New: Attempts, fails to rebuild doc/gcc.info in tarball release build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91139
Bug ID: 91139
Summary: Attempts, fails to rebuild doc/gcc.info in tarball
release build
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: skunk at iskunk dot org
Target Milestone: ---
There may be one or two bugs in this report.
I am bootstrapping from a release tarball on a Solaris system. The system has
makeinfo 4.7 installed, which the GCC configure script finds.
At a certain point in the build, I get this error:
[...]
(echo "@set version-GCC 9.1.0"; \
if [ "" = "experimental" ]; \
then echo "@set DEVELOPMENT"; \
else echo "@clear DEVELOPMENT"; \
fi) > gcc-vers.texiT
echo @set srcdir /nfs/gnu/src/gcc/gcc--9.1.0/gcc >> gcc-vers.texiT
if [ -n "(GCC) " ]; then \
echo "@set VERSION_PACKAGE (GCC) " >> gcc-vers.texiT; \
fi
echo "@set BUGURL @uref{https://gcc.gnu.org/bugs/}; >> gcc-vers.texiT; \
mv -f gcc-vers.texiT gcc-vers.texi
if [ xinfo = xinfo ]; then \
/nfs/gnu/src/gcc/gcc--9.1.0/missing makeinfo --split-size=500
--split-size=500 --split-size=500 --no-split -I . -I
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc \
-I /nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc/include -o doc/cpp.info
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc/cpp.texi; \
fi
if [ xinfo = xinfo ]; then \
/nfs/gnu/src/gcc/gcc--9.1.0/missing makeinfo --split-size=500
--split-size=500 --split-size=500 --no-split -I . -I
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc \
-I /nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc/include -o doc/gcc.info
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc/gcc.texi; \
fi
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc//invoke.texi:1783: @include
`/nfs/gnu/src/gcc/gcc-9.1.0/gcc/../libiberty/at-file.texi': No such file or
directory.
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc//extend.texi:7097: warning: `.' or `,' must
follow @xref, not `f'.
/nfs/gnu/src/gcc/gcc--9.1.0/gcc/doc//extend.texi:8181: warning: `.' or `,' must
follow @xref, not `f'.
makeinfo: Removing output file `doc/gcc.info' due to errors; use --force to
preserve.
Makefile:3228: recipe for target 'doc/gcc.info' failed
gmake[3]: *** [doc/gcc.info] Error 1
gmake[3]: Leaving directory '/tmp/gcc--9.1.0.build/gcc'
Makefile:4661: recipe for target 'all-stage1-gcc' failed
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory '/tmp/gcc--9.1.0.build'
Makefile:22313: recipe for target 'stage1-bubble' failed
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory '/tmp/gcc--9.1.0.build'
Makefile:22660: recipe for target 'bootstrap-lean' failed
gmake: *** [bootstrap-lean] Error 2
Bug-1 is that the build is attempting to rebuild an info file, which should not
even be happening in the first place with an unmodified release tarball.
Bug-2 is the "No such file" error, which appears to be due to Texinfo syntax
processing erroneously being applied to the file path (note how "gcc--9.1.0"
becomes "gcc-9.1.0", despite only the former being valid for this build).
The second bug would be moot if not for the first.
[Bug rtl-optimization/91136] [MIPS] Incorrect move of instruction to delay slot causes application crash in exception handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91136 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-07-10 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Eric Botcazou --- Can you find out if this works with earlier compilers?
[Bug c++/91076] wrong class-key in mentioned in a diagnostic note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91076 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- The patch for pr61339 depends on this working so it includes a fix: https://gcc.gnu.org/ml/gcc-patches/2019-07/msg00622.html
[Bug c++/91110] [10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in cp_omp_mappable_type_1, at cp/decl2.c:1421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91110 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Yes.
[Bug c++/91110] [10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in cp_omp_mappable_type_1, at cp/decl2.c:1421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91110 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- So fixed?
[Bug c/91134] Confusing error message: error: ‘*server’ is a pointer; did you mean to use ‘->’? when -> is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91134 --- Comment #5 from Jonathan Wakely --- Bug 91138 created for the C++ case.
[Bug c++/91138] New: Confusing error message: "maybe you meant to use '->' ?" fix-it when -> is already used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91138
Bug ID: 91138
Summary: Confusing error message: "maybe you meant to use '->'
?" fix-it when -> is already used
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
+++ This bug was initially created as a clone of Bug #91134 +++
struct X { int member; } x;
X* p =
X** pp =
int i = *pp->member;
91134.cc:4:14: error: request for member 'member' in '* pp', which is of
pointer type 'X*' (maybe you meant to use '->' ?)
4 | int i = *pp->member;
| ^~
Suggesting -> isn't helpful when it already uses it. The right fix-it is to
suggest (*pp)->member
[Bug c/91134] Confusing error message: error: ‘*server’ is a pointer; did you mean to use ‘->’? when -> is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91134
Jonathan Wakely changed:
What|Removed |Added
Version|6.3.0 |10.0
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> struct X { int member; } x;
> X* p =
> X** pp =
> int i = *pp->member;
>
> 91134.cc:4:14: error: request for member 'member' in '* pp', which is of
> pointer type 'X*' (maybe you meant to use '->' ?)
> 4 | int i = *pp->member;
> | ^~
That's the equivalent error from the C++ front end (which should also be
fixed).
The C testcase and output is:
struct X { int member; } x;
struct X *p =
struct X **pp =
int i = *pp->member;
91134.c:4:12: error: ‘*pp’ is a pointer; did you mean to use ‘->’?
4 | int i = *pp->member;
|^~
|->
[Bug target/91060] [10 regression] gcc.c-torture/execute/scal-to-vec1.c fails on armeb-none-linux-gnueabihf since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91060 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from rsandifo at gcc dot gnu.org --- Fixed on trunk.
[Bug rtl-optimization/91136] [MIPS] Incorrect move of instruction to delay slot causes application crash in exception handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91136 --- Comment #4 from Andrew Pinski --- I don't think it is related to PR 89245 but they happen on MIPS.
[Bug target/91060] [10 regression] gcc.c-torture/execute/scal-to-vec1.c fails on armeb-none-linux-gnueabihf since r272843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91060 --- Comment #15 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Wed Jul 10 18:41:44 2019 New Revision: 273365 URL: https://gcc.gnu.org/viewcvs?rev=273365=gcc=rev Log: [arm] Fix BE index for single-var vector initialisers (PR91060) If a vector constructor has a single nonconstant element, neon_expand_vector_init loads the constant lanes and then inserts the nonconstant value. The problem was that it was doing the insertion using the arm_neon.h neon_vset_lane patterns, which use architectural lane numbering rather than GCC lane numbering. 2019-07-10 Richard Sandiford gcc/ PR target/91060 * config/arm/iterators.md (V2DI_ONLY): New mode iterator. * config/arm/neon.md (vec_set_internal): Add a '@' prefix. (vec_setv2di_internal): Reexpress as... (@vec_set_internal): ...this. * config/arm/arm.c (neon_expand_vector_init): Use gen_vec_set_internal rather than gen_neon_vset_lane. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/iterators.md trunk/gcc/config/arm/neon.md
[Bug target/91124] [10 regression] gcc.target/i386/avx512vl-vpshldvd-2.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91124
--- Comment #10 from Jakub Jelinek ---
The execution failures are a different bug.
Patterns like:
(define_insn "sse2_cvttpd2dq"
[(set (match_operand:V4SI 0 "register_operand" "=v")
(vec_concat:V4SI
(fix:V2SI (match_operand:V2DF 1 "vector_operand" "vBm"))
(const_vector:V2SI [(const_int 0) (const_int 0)])))]
"TARGET_SSE2 && "
{
if (TARGET_AVX)
return "vcvttpd2dq{x}\t{%1, %0|%0, %1}";
else
return "cvttpd2dq\t{%1, %0|%0, %1}";
}
are correct when not masked, but for masked the RTL representation is wrong:
(define_insn ("sse2_cvttpd2dq_mask")
[
(set (match_operand:V4SI 0 ("register_operand") ("=v"))
(vec_merge:V4SI (vec_concat:V4SI (fix:V2SI (match_operand:V2DF 1
("vector_operand") ("vBm")))
(const_vector:V2SI [
(const_int 0 [0])
(const_int 0 [0])
]))
(match_operand:V4SI 2 ("nonimm_or_0_operand") ("0C"))
(match_operand:QI 3 ("register_operand") ("Yk"
] ("(TARGET_AVX512F) && (TARGET_SSE2 && TARGET_AVX512VL)") ("*{
if (TARGET_AVX)
return "vcvttpd2dq{x}\t{%1, %0%{%3%}%N2|%0%{%3%}%N2, %1}";
else
return "cvttpd2dq\t{%1, %0|%0, %1}";
}")
because it doesn't for the _mask but not _maskz case actually represent what
the instruction does. The instruction zeros up bits 64 and up in the vector
(DEST[MAX_VL-1:VL/2] <- 0;, no matter what is in the upper bits of DEST before
when it is masked off.
Working on another patch.
[Bug sanitizer/91115] stack-buffer-overflow on memset local variable when creating thread on ARM Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91115 --- Comment #5 from Andrew Pinski --- >The actual SP and shadow byte location varies a bit between each run. You can disable address randomization before running the program to get the location less varied.
[Bug tree-optimization/91137] New: Wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91137
Bug ID: 91137
Summary: Wrong code with -O3
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskij at frtk dot ru
Target Milestone: ---
GCC produces wrong code with –O3.
Reproducer:
#include
long long a;
unsigned b;
int c[70];
int d[70][70];
int e;
void f(long long *g, int p2) { *g = p2; }
void fn2() {
for (int j = 0; j < 70; j++) {
for (int i = 0; i < 70; i++) {
if (b)
c[i] = 0;
for (int l = 0; l < 70; l++)
d[i][1] = d[l][i];
}
for (int k = 0; k < 70; k++)
e = c[0];
}
}
int main() {
b = 5;
for (int j = 0; j < 70; ++j)
c[j] = 2075593088;
fn2();
f(, e);
printf("%lld\n", a);
}
Error:
>$ gcc -O3 repr.c ; ./a.out
2075593088
>$ gcc -O0 repr.c ; ./a.out
0
GCC version:
gcc version 10.0.0 (Rev: 273261)
This error can also be reproduced with gcc version 7.3.1
[Bug c/66970] Add __has_builtin() macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970 --- Comment #15 from Nick Desaulniers --- Any progress Martin? Just to keep beating the dead horse... Forgetting other compilers for a minute, __has_builtin allows for feature detection which is much better than compiler version checks which are brittle and error prone. As new builtins get added over time, their existence can be checked in a cleaner way with __has_builtin.
[Bug rtl-optimization/91136] [MIPS] Incorrect move of instruction to delay slot causes application crash in exception handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91136 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code --- Comment #3 from Andrew Pinski --- The obvious workaround is -fno-delayed-branch . DBR is the delay slot scheduler. I am not shocked this bug has not happened before. The delay slot scheduler has not had major development in the last 10 years too :).
[Bug rtl-optimization/91136] [MIPS] Incorrect move of instruction to delay slot causes application crash in exception handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91136 --- Comment #2 from Artur Koniński --- Created attachment 46589 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46589=edit suplementary file, to allow linking and test of built program
[Bug rtl-optimization/91136] [MIPS] Incorrect move of instruction to delay slot causes application crash in exception handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91136 --- Comment #1 from Artur Koniński --- Created attachment 46588 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46588=edit Compiler output, collected with -v
[Bug rtl-optimization/91136] New: [MIPS] Incorrect move of instruction to delay slot causes application crash in exception handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91136 Bug ID: 91136 Summary: [MIPS] Incorrect move of instruction to delay slot causes application crash in exception handling Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: artur.koninski at nokia dot com Target Milestone: --- Target: mips64 Created attachment 46587 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46587=edit code that compiles wrong Content of $a0 register containing __builtin_eh_pointer to be passed to __cxa_begin_catch is overwritten by an incorrectly placed "ld $4,8($sp)" instruction in delay branch of exception catch body selecting conditional jump: .cfi_restore_state li $2,1# 0x1 beq $5,$2,.L4 move$16,$4 li $2,2# 0x2 bne $5,$2,.L22 ld $4,8($sp) <- in case of no jump, $4 == $a0 is not __builtin_eh_pointer anymore, but is still passed to __cxa_begin_catch ld $25,%call16(__cxa_begin_catch)($28) .reloc 1f,R_MIPS_JALR,__cxa_begin_catch 1: jalr$25 nop The issue (in much more complex code) caused application crashes. Original issue was found with g++ 6.4.1. Looking at RTL dump of dbr phase the issue is alredy visible. I couldn't recognize if anything is wrong in previous passes, but the issue seems to be easily hidden by changes to previous passes, e.g. by using -freorder-blocks-algorithm=simple. To compile executable application and see the crash additional simple file is needed with definitions of 3 functions (two empty and 1 throwing int)
Swim Collective Trade Show 2019
Hi, We are providing the Attendees list of Swim Collective Trade Show 2019 with 9,950 visitors. If you are interested, please let me know your thoughts, so that I can send you the pricing for it. Best Regards, Kathryn Watson Demand Generation To be removed from my emails, please reply STOP.
[Bug testsuite/91132] New test gcc.dg/strlenopt-67.c in r273317 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91132 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #1 from Martin Sebor --- Fixed in r273358.
[Bug testsuite/91132] New test gcc.dg/strlenopt-67.c in r273317 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91132 --- Comment #2 from Martin Sebor --- Author: msebor Date: Wed Jul 10 16:15:52 2019 New Revision: 273358 URL: https://gcc.gnu.org/viewcvs?rev=273358=gcc=rev Log: PR testsuite/91132 - test gcc.dg/strlenopt-67.c in r273317 fails gcc/testsuite/ChangeLog: * gcc.dg/strlenopt-67.c: Removed second copy of test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/strlenopt-67.c
[Bug target/91135] __linux__ not defined with -mcall-aixdesc on 9.x and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91135 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-10 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Confimed. Testcase: :|gcc -E -dM - -mcall-aixdesc|grep linux
[Bug target/91102] [9/10 Regression] aarch64 ICE on Linux kernel with -Os starting with r270266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91102 --- Comment #7 from Vladimir Makarov --- Author: vmakarov Date: Wed Jul 10 16:07:10 2019 New Revision: 273357 URL: https://gcc.gnu.org/viewcvs?rev=273357=gcc=rev Log: 2019-07-10 Vladimir Makarov PR target/91102 * lra-constraints.c (process_alt_operands): Don't match user defined regs only if they are early clobbers. 2019-07-10 Vladimir Makarov PR target/91102 * gcc.target/aarch64/pr91102.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr91102.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug c++/91127] Incorrect checking of nonnull attribute with argument to a constructor of class with a virtual base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91127 --- Comment #2 from Martin Sebor --- The function that validates attribute positional arguments doesn't consider the subtleties of C++ member functions so the diagnostic it gives in these cases is confusing. I agree that the nonnull attribute doesn't make sense for the this pointer. Clang gives an error when nonnull is applied to this, so changing GCC to issue a warning (if not error) would seem appropriate. Putting the implicit this argument in member functions at number 1 when in non-members it refers to the first explicit argument seems like an unfortunate design flaw. But it goes back many years so I also agree it wouldn't be safe to change today. I suspect the implicit int argument in ctors was never considered. I would think it should be possible to skip without breaking too much code. Clang handles the test case correctly and so should GCC. The change from error for attribute nonnull to warning was just the result of factoring the positional argument checking out of individual attribute handlers and into a common function. Attributes alloc_align and alloc_size issued a warning, and attribute nonnull an error, so I went with the former. Tightening it to an error in GCC 10 to match Clang sounds like a good change.
[Bug c/91134] Confusing error message: error: ‘*server’ is a pointer; did you mean to use ‘->’? when -> is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91134 --- Comment #3 from Jonathan Wakely --- (In reply to Emil Fihlman from comment #0) > fiesh on #gcc@Freenode gave these ideas regarding this: > > 2019-07-10 18:11:03 +0300 < fiesh> I think that `server->thing` is probably > replaced by `(*server.thing)` since they are semantically equivalent at some > stage before the error is produced > 2019-07-10 18:11:45 +0300 < fiesh> then the parser sees that *server is a > pointer type and you're trying to access its contents with ., so it tells > you that doesn't work > 2019-07-10 18:12:52 +0300 < fiesh> by ((*server).thing) No I don't think that's what happens. I think the error is given for any class member access expression where the object expression has pointer type, i.e. `server->thing` is a member access expression, and `server` is a pointer, so it gives that error. What needs to happen is to check whether -> is already used, and in that case suggest dereferencing the object expression first, i.e. `(*server)->thing`
[Bug target/91135] New: __linux__ not defined with -mcall-aixdesc on 9.x and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91135 Bug ID: 91135 Summary: __linux__ not defined with -mcall-aixdesc on 9.x and ppc64 Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gcc at octaforge dot org Target Milestone: --- Since 9.x, using the `-mcall-aixdesc` makes gcc undefine `__linux__`. This breaks compilation of the Linux kernel as it relies on the older behavior (`-mcall-aixdesc` is used on BE, without it the kernel does not link and there are several modules that check for `__linux__` being defined and break if it's not). The kernel claims it's a GCC bug: https://bugzilla.kernel.org/show_bug.cgi?id=204125 Could someone confirm whether it is, so that it is known if this needs to be fixed in gcc or in the kernel? Thanks
[Bug c/91134] Confusing error message: error: ‘*server’ is a pointer; did you mean to use ‘->’? when -> is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91134
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-07-10
Ever confirmed|0 |1
--- Comment #2 from Jonathan Wakely ---
struct X { int member; } x;
X* p =
X** pp =
int i = *pp->member;
91134.cc:4:14: error: request for member 'member' in '* pp', which is of
pointer type 'X*' (maybe you meant to use '->' ?)
4 | int i = *pp->member;
| ^~
[Bug c/91134] Confusing error message: error: ‘*server’ is a pointer; did you mean to use ‘->’? when -> is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91134 --- Comment #1 from Emil Fihlman --- The fix programming side is of course just wrapping *server in parentheses but the error message should still be amended imho.
[Bug c/91134] New: Confusing error message: error: ‘*server’ is a pointer; did you mean to use ‘->’? when -> is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91134 Bug ID: 91134 Summary: Confusing error message: error: ‘*server’ is a pointer; did you mean to use ‘->’? when -> is used Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: emil.fihlman at aalto dot fi Target Milestone: --- gcc -Wall -Werror -Wextra -O3 -flto -o program program.c -lm program.c: In function ‘setupFunction’: program.c:Y:X: error: ‘*server’ is a pointer; did you mean to use ‘->’? if(setupThing(&(*server->thing), MAX_THINGY)==~0UL) ^~ server is of type struct Server ** in this context The error message should probably change in this context to suggesting parentheses. fiesh on #gcc@Freenode gave these ideas regarding this: 2019-07-10 18:11:03 +0300 < fiesh> I think that `server->thing` is probably replaced by `(*server.thing)` since they are semantically equivalent at some stage before the error is produced 2019-07-10 18:11:45 +0300 < fiesh> then the parser sees that *server is a pointer type and you're trying to access its contents with ., so it tells you that doesn't work 2019-07-10 18:12:52 +0300 < fiesh> by ((*server).thing) Emil Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
[Bug target/91124] [10 regression] gcc.target/i386/avx512vl-vpshldvd-2.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91124 --- Comment #9 from Jakub Jelinek --- Created attachment 46586 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46586=edit gcc10-pr91124.patch Untested patch for the VBMI2/VNNI error: the last argument must be an 8-bit immediate etc. issues, but not for the execution failures.
[Bug sanitizer/91101] Possible performance regression in libasan with detect_stack_use_after_return=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91101 --- Comment #17 from Frantisek Sumsal --- Thanks a lot for the thorough debugging and explanation. I raised an issue on the systemd bug tracker[0] so it can be properly discussed and resolved there. [0] https://github.com/systemd/systemd/issues/12997
[Bug middle-end/91131] Bad bitfield coalescing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91131
--- Comment #5 from Per Dalgas Jakobsen ---
(In reply to Richard Biener from comment #2)
> So your complaint is that
>
> struct Reg_T {
> unsigned int a : 3;
> unsigned int b : 1;
> unsigned int c : 4;
> } __attribute__((packed));
>
> volatile struct Reg_T Reg_A;
> ...
> Reg_A = (struct Reg_T){ .a = 0, .b = 0, .c = 0 };
>
> does not yield a single store, correct?
Primary complaint, Yes.
Secondary complaint is the use of RAM-memory locations for constants, where an
immediate would be more efficient. Especially on a microcontroller with 32
bytes of RAM...
[Bug c++/91133] New: Wrong "partial specialization is not more specialized than" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91133
Bug ID: 91133
Summary: Wrong "partial specialization is not more specialized
than" error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: WisdomOfDarkness at gmail dot com
Target Milestone: ---
The code under fails to compile with GCC 7, 8 and 9, and produces the following
error:
partial specialization 'struct A' is not more specialized than
[-fpermissive] ...
template struct Id
{
using type = T;
};
template
struct A
{
};
//template
template::type X>
struct A
{
};
This is clearly wrong because the specialization is clearly specialized in its
second parameter.
godbolt: https://godbolt.org/z/wDp3B7
Works in GCC 6 and under. Also works in clang and MSVC.
[Bug middle-end/91131] Bad bitfield coalescing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91131 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- Mine.
[Bug middle-end/91131] Bad bitfield coalescing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91131
--- Comment #3 from Richard Biener ---
Index: gcc/gimplify.c
===
--- gcc/gimplify.c (revision 273355)
+++ gcc/gimplify.c (working copy)
@@ -5005,7 +5004,7 @@ gimplify_init_constructor (tree *expr_p,
one field to assign, initialize the target from a temporary. */
if (TREE_THIS_VOLATILE (object)
&& !TREE_ADDRESSABLE (type)
- && num_nonzero_elements > 0
+ && (num_nonzero_elements > 0 || !cleared)
&& vec_safe_length (elts) > 1)
{
tree temp = create_tmp_var (TYPE_MAIN_VARIANT (type));
note your use of packed might end up doing more than one store depending
on the architecture.
[Bug middle-end/91131] Bad bitfield coalescing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91131
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-07-10
Ever confirmed|0 |1
Known to fail||10.0, 8.3.0
--- Comment #2 from Richard Biener ---
So your complaint is that
struct Reg_T {
unsigned int a : 3;
unsigned int b : 1;
unsigned int c : 4;
} __attribute__((packed));
volatile struct Reg_T Reg_A;
...
Reg_A = (struct Reg_T){ .a = 0, .b = 0, .c = 0 };
does not yield a single store, correct?
The reason is how we gimplify this:
{
Reg_A.a = 0;
Reg_A.b = 0;
Reg_A.c = 0;
D.2005.a = 0;
D.2005.b = 1;
D.2005.c = 0;
Reg_B = D.2005;
D.2006.a = 7;
D.2006.b = 1;
D.2006.c = 15;
Reg_C = D.2006;
Reg_D = 0;
Reg_E = 255;
D.2007 = 0;
return D.2007;
}
see how for the zero-initializer we emit three volatile accesses.
[Bug debug/90231] ivopts causes iterator in the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231 Carlo B. changed: What|Removed |Added CC||castro8583bennett at gmx dot com --- Comment #6 from Carlo B. --- (In reply to Jakub Jelinek from comment #4) > The point is that ivopts knows better Hi Jakub so what do you suggest we should do about this? Castro B, https://voucher.co.id
[Bug tree-optimization/91126] [7/8/9 regression] Incorrect constant propagation of BIT_FIELD_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91126 --- Comment #9 from Richard Biener --- Author: rguenth Date: Wed Jul 10 13:40:12 2019 New Revision: 273355 URL: https://gcc.gnu.org/viewcvs?rev=273355=gcc=rev Log: 2019-07-10 Richard Biener PR tree-optimization/91126 * tree-ssa-sccvn.c (n_walk_cb_data::push_partial_def): Adjust native encoding offset for BYTES_BIG_ENDIAN. (vn_reference_lookup_3): Likewise. * gcc.dg/torture/pr91126.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr91126.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/91126] [7/8/9 regression] Incorrect constant propagation of BIT_FIELD_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91126 Richard Biener changed: What|Removed |Added Known to work||10.0 Summary|[7/8/9/10 regression] |[7/8/9 regression] |Incorrect constant |Incorrect constant |propagation of |propagation of |BIT_FIELD_REF |BIT_FIELD_REF --- Comment #8 from Richard Biener --- Fixed on trunk sofar.
[Bug testsuite/91132] New: New test gcc.dg/strlenopt-67.c in r273317 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91132 Bug ID: 91132 Summary: New test gcc.dg/strlenopt-67.c in r273317 fails Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/strlenopt-67.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 -Wall -fdump-tree-optimized -S -o strlenopt-67.s /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/strlenopt-67.c:62:5: error: redefinition of 'f4' /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/strlenopt-67.c:10:5: note: previous definition of 'f4' was here /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/strlenopt-67.c:76:5: error: redefinition of 'f6' /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/strlenopt-67.c:24:5: note: previous definition of 'f6' was here /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/strlenopt-67.c:90:5: error: redefinition of 'f8' /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/strlenopt-67.c:38:5: note: previous definition of 'f8' was here compiler exited with status 1 FAIL: gcc.dg/strlenopt-67.c (test for excess errors) Excess errors: /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/strlenopt-67.c:62:5: error: redefinition of 'f4' /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/strlenopt-67.c:76:5: error: redefinition of 'f6' /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/strlenopt-67.c:90:5: error: redefinition of 'f8' gcc.dg/strlenopt-67.c: dump file does not exist UNRESOLVED: gcc.dg/strlenopt-67.c scan-tree-dump-times optimized "abort|strlen" 0 gcc.dg/strlenopt-67.c: dump file does not exist UNRESOLVED: gcc.dg/strlenopt-67.c scan-tree-dump-times optimized "abort|strlen" 0 testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/dg.exp completed in 1 seconds === gcc Summary === # of unexpected failures1 # of unresolved testcases 2 r273317 | msebor | 2019-07-09 18:29:33 -0500 (Tue, 09 Jul 2019) | 14 lines gcc/ChangeLog: PR tree-optimization * tree-ssa-strlen.c (handle_char_store): Constrain a single character optimization to just single character stores. gcc/testsuite/ChangeLog: PR tree-optimization * gcc.dg/strlenopt-26.c: Exit with test result status. * gcc.dg/strlenopt-67.c: New test.
[Bug c++/91125] -frepo can't build tramp3d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91125 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|2019-07-09 00:00:00 |2019-07-10 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Lemme take it.
[Bug middle-end/91131] Bad bitfield coalescing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91131 --- Comment #1 from Per Dalgas Jakobsen --- Created attachment 46585 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46585=edit MWE: Preprocessed C-file
[Bug middle-end/91131] New: Bad bitfield coalescing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91131 Bug ID: 91131 Summary: Bad bitfield coalescing Product: gcc Version: 8.3.0 URL: http://knaldgas.dk/~pdj/bitfields/ Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pdj at knaldgas dot dk Target Milestone: --- In both C and Ada, bitfield coalescing does not work right, or at least not optimal. Since the issue manifests itself in the same way in both C and Ada front-ends, and on ARM, AVR and X86_64 back-ends, I presume that that the issue must lie somewhere in between. Please see past that C bitfields are defective by definition; Ada's definition is pretty well-defined. Seen on GCC version 4.9.3, 8.3.0 and reportedly also on 9.1. The key point below is that all assignments have a data-width of less or equal the machines data-width, and can be fully evaluated at compile time. Pseudo-code: type Rec_Type record A: 3 bits B: 1 bit C: 4 bits end (packed, 8-bit wide) volatile Rec_A : Rec_Type volatile Rec_B : Rec_Type volatile Rec_C : Rec_Type Rec_A := (A => 0, B => 1, C => 0) results in one pre-calculated constant byte being assigned directly. This is the way all such assignments should be. Rec_B := (A => 1, B => 1, C => 1) results in one pre-calculated value being stored in a memory location, which is then ĺoaded and assigned to Rec_B. Unnecessary memory consumption. Rec_C := (A => 0, B => 0, C => 0) results in Read, Modify, Write for each field (3 times). Horrible, and may cause defective execution if Reg_C is a peripheral register! Reading a register does not always give the last value written to it. Also Writing bits in "random" order may cause malfunction of the device. In Ada the Reg_C problem can be mitigated by using pragma Atomic instead, this still causes a memory location to be used for the evaluated constant that could just as well be loaded as an immediate. I've uploaded sources, preprocessed file and Makefile/GPR to this location: http://knaldgas.dk/~pdj/bitfields/ - The c-file is just compiled with gcc -O -c main.c Pretty odd that three similar assignments can give three different kinds of code generation...
[Bug sanitizer/91115] stack-buffer-overflow on memset local variable when creating thread on ARM Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91115 --- Comment #4 from Martin Liška --- (In reply to Fred Hsueh from comment #3) > The actual SP and shadow byte location varies a bit between each run. Other > than that, the signature looks very similar. Another thing to note is that > the program has a high thread count, perhaps ~140. That makes it very difficult to reproduce. Do you have any 2 runs that have the '[f2]' shadow memory at the same location. > > Any tips, preferences, or good starting points to look at for creating the > testcase? I can't find any in ASAN or ARM related pre-existing cases. > > thanks! Is the reproducer an open-source software? I would somehow reduce # of threads.
[Bug ipa/89330] IPA inliner touches released cgraph_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89330 Martin Jambor changed: What|Removed |Added Attachment #45730|0 |1 is obsolete|| Attachment #46544|0 |1 is obsolete|| --- Comment #12 from Martin Jambor --- Created attachment 46584 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46584=edit Another WIP patch Thanks for tracking that down, indeed we found that the speculation was undoing inlining decisions which is something that is generally unsupported by the inliner. This patch fixes that and it indeed survives LTO bootstrap of all languages (profiled LTO bootstrap is underway). Unfortunately, it causes the following tests to fail: FAIL: g++.dg/tree-prof/devirt.C scan-tree-dump-times tracer "folding virtual function call to virtual unsigned int mozPersonalDictionary::_ZThn16" 1 FAIL: g++.dg/tree-prof/devirt.C scan-tree-dump-times tracer "folding virtual function call to virtual unsigned int mozPersonalDictionary::AddRef" 1 So far all my attempts to quickly fix this without actually having to understand what is going on in the testcase have failed. I'm afraid I'll have to look deeper into it which will take time, so far I did not even manage to reproduce the problem manually.
[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130 Martin Liška changed: What|Removed |Added Keywords||needs-bisection Status|UNCONFIRMED |NEW Known to work||8.3.0 Ever confirmed|0 |1 Known to fail||9.1.0
[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130 Martin Liška changed: What|Removed |Added Target||aarch64-linux-gnu Last reconfirmed||2019-7-10 CC||ktkachov at gcc dot gnu.org Host||aarch64-linux-gnu Version|10.0|9.1.0 Target Milestone|--- |9.2 Build||aarch64-linux-gnu
[Bug target/91130] New: [9/10 Regression] -MF clashes with -flto on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
Bug ID: 91130
Summary: [9/10 Regression] -MF clashes with -flto on aarch64
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Starting from GCC 9.1.0 I see following problem:
$ gcc --version
gcc (SUSE Linux) 9.1.1 20190611 [gcc-9-branch revision 272147]
$ echo "int main() {}" > main.c && gcc -c -flto main.c && gcc -o a.out main.o
-flto -MMD -MF deps/a.d -MP
gcc: error: deps/a.d: No such file or directory
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/lib64/gcc/aarch64-suse-linux/9/../../../../aarch64-suse-linux/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
$ echo "int main() {}" > main.c && gcc-8 -c -flto main.c && gcc-8 -o a.out
main.o -flto -MMD -MF deps/a.d -MP && echo OK
OK
[Bug other/55930] [7/8/9/10 Regression] libatomic build failure if configured with --disable-dependency-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930
--- Comment #14 from Stephen Kitt ---
(In reply to Andrew Pinski from comment #5)
> But the bigger question is why are you passing --disable-dependency-tracking
> ?
I ran into this issue because Debian's debhelper's dh_auto_configure passes
--disable-dependency-tracking automatically. ("Know your build tools" is the
lesson here, I guess.)
[Bug target/91124] [10 regression] gcc.target/i386/avx512vl-vpshldvd-2.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91124 --- Comment #8 from Jakub Jelinek --- Yeah, but that is just one thing, the other is execution failure, but most likely bad expansion as well.
[Bug target/91124] [10 regression] gcc.target/i386/avx512vl-vpshldvd-2.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91124
--- Comment #7 from Richard Biener ---
Somehow the backend doesn't like to expand
__builtin_ia32_vpshldv_v4si_mask (_36, { 2, 3, 4, 5 }, { 1, 4, 7, 10 }, 185)
while it happily expands
__builtin_ia32_vpshldv_v4si_maskz (_24, _15, _14, 185);
and the error message is of course misleading (it complains about the
second vector constant).
leaving it to Jakub.
[Bug tree-optimization/91126] [7/8/9/10 regression] Incorrect constant propagation of BIT_FIELD_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91126 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||4.6.3 Target Milestone|10.0|7.5 Summary|[10 regression] Incorrect |[7/8/9/10 regression] |constant propagation of |Incorrect constant |BIT_FIELD_REF |propagation of ||BIT_FIELD_REF Known to fail||4.7.4 --- Comment #7 from Richard Biener --- So the new testcase should fail since GCC 4.7.
[Bug target/91124] [10 regression] gcc.target/i386/avx512vl-vpshldvd-2.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91124 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- I'll have a look.
[Bug tree-optimization/91126] [10 regression] Incorrect constant propagation of BIT_FIELD_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91126
--- Comment #6 from Richard Biener ---
Testcase that fails for a longer time already:
struct S
{
int a : 24;
int b : 8;
} s;
int
main()
{
s.a = 0xfefefe;
s.b = 0xfe;
unsigned char c;
c = ((unsigned char *))[0];
if (c != 0xfe)
__builtin_abort ();
c = ((unsigned char *))[1];
if (c != 0xfe)
__builtin_abort ();
c = ((unsigned char *))[2];
if (c != 0xfe)
__builtin_abort ();
c = ((unsigned char *))[3];
if (c != 0xfe)
__builtin_abort ();
return 0;
}
[Bug c++/91129] New: Implicit casts fail for modulo operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91129
Bug ID: 91129
Summary: Implicit casts fail for modulo operator
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Peter.Georg at physik dot uni-regensburg.de
Target Milestone: ---
Created attachment 46583
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46583=edit
Code to reproduce bug
GCC fails to compile the following code due to being unable to implicitely cast
Constant to int, despite the conversion operator being defined.
```
class Constant
{
public:
constexpr operator T() const { return v; }
constexpr auto operator()() const {return v;}
};
template
class Array
{
};
class Test
{
public:
template
using Cores = Array{}>;
};
int main()
{
}
```
The code is also attacged or see: https://godbolt.org/z/UJHdqb
Array and Constant can be replaced by std::array and std::integral_constant,
the error is the same.
It only fails when using the modulo operator, any other tested binary
arithmetic operator works. When adding an explicit cast, the code compiles
without any errors as well.
First version affected: GCC 9
[Bug c++/88907] Variadic template function deduction failure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88907 Peter Georg changed: What|Removed |Added Version|8.2.1 |10.0 --- Comment #1 from Peter Georg --- All versions tested (6-9, and trunk) are affected.
[Bug other/55930] [7/8/9/10 Regression] libatomic build failure if configured with --disable-dependency-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930 --- Comment #13 from Jonathan Wakely --- OK thanks for the update. I think your patch for this bug is trivial enough to not require any paperwork.
[Bug libstdc++/81806] Split in pbds works in O(n) instead of O(log n)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81806 --- Comment #2 from Jonathan Wakely --- Feedback was provided: https://gcc.gnu.org/ml/gcc/2019-07/msg00082.html
[Bug other/55930] [7/8/9/10 Regression] libatomic build failure if configured with --disable-dependency-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930 --- Comment #12 from Richard Purdie --- I started to look at sorting out Yocto Project/Openembedded's gcc patches in general and ran into a contribution agreement legal quagmire. I still haven't been able to resolve that.
[Bug c/91128] New: Incomplete fix of heap overflow in cp-demangle.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91128 Bug ID: 91128 Summary: Incomplete fix of heap overflow in cp-demangle.c Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: featherrain26 at gmail dot com Target Milestone: --- Created attachment 46582 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46582=edit Poc input Reference link: https://sourceware.org/bugzilla/show_bug.cgi?id=24791 Hi, there. There is a heap overflow caused by the incomplete fix of the cp-demangle.c This is the newest patch I have tried: https://gcc.gnu.org/viewcvs/gcc?view=revision=270258 System information: Description:Ubuntu 16.04.6 LTS Release:16.04 Codename: xenial gcc version:5.4 The Binutils version is release 2.32 or 2.33(HEAD) To reproduce the issue, the compile flag is: CFLAGS="-g -O0 -m32 -fsanitize=address,undefined" ./configure;make then, nm-new -C -a -l --synthetic input Here are the details reported by ASAN: ==178966==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf4e02883 at pc 0x085d6167 bp 0xffe086d8 sp 0xffe086c8 READ of size 1 at 0xf4e02883 thread T0 #0 0x85d6166 in d_expression_1 cp-demangle.c:3356 #1 0x85d4f12 in d_expression_1 cp-demangle.c:3449 #2 0x85d4f12 in d_expression_1 cp-demangle.c:3449 #3 0x85d4f12 in d_expression_1 cp-demangle.c:3449 #4 0x85d4f12 in d_expression_1 cp-demangle.c:3449 #5 0x85d4f12 in d_expression_1 cp-demangle.c:3449 #6 0x85d4f12 in d_expression_1 cp-demangle.c:3449 #7 0x85d4f12 in d_expression_1 cp-demangle.c:3449 #8 0x85d4f12 in d_expression_1 cp-demangle.c:3449 #9 0x85c8395 in d_expression cp-demangle.c:3531 #10 0x85c8395 in d_array_type cp-demangle.c:3011 #11 0x85c8395 in cplus_demangle_type cp-demangle.c:2463 #12 0x85ca143 in d_parmlist cp-demangle.c:2908 #13 0x85d907c in d_bare_function_type cp-demangle.c:2962 #14 0x85d907c in d_encoding cp-demangle.c:1343 #15 0x85dc451 in cplus_demangle_mangled_name cp-demangle.c:1234 #16 0x85e29ed in d_demangle_callback cp-demangle.c:6292 #17 0x85e29ed in d_demangle cp-demangle.c:6343 #18 0x85e29ed in cplus_demangle_v3 cp-demangle.c:6500 #19 0x858e46c in cplus_demangle cplus-dem.c:165 #20 0x808ea57 in bfd_demangle /mnt/data/playground/binutils-2.32-a/bfd/bfd.c:2254 #21 0x805f51f in print_symname /mnt/data/playground/binutils-2.32-a/binutils/nm.c:423 #22 0x805f51f in print_symbol_info_bsd /mnt/data/playground/binutils-2.32-a/binutils/nm.c:1565 #23 0x8053fcf in print_symbol /mnt/data/playground/binutils-2.32-a/binutils/nm.c:903 #24 0x80571b5 in print_symbols /mnt/data/playground/binutils-2.32-a/binutils/nm.c:1102 #25 0x80571b5 in display_rel_file /mnt/data/playground/binutils-2.32-a/binutils/nm.c:1215 #26 0x805adb1 in display_file /mnt/data/playground/binutils-2.32-a/binutils/nm.c:1335 #27 0x804f98a in main /mnt/data/playground/binutils-2.32-a/binutils/nm.c:1816 #28 0xf7000636 in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x18636) #29 0x805154b (/mnt/data/playground/binutils-2.32-a/binutils/nm-new+0x805154b) 0xf4e02883 is located 0 bytes to the right of 99-byte region [0xf4e02820,0xf4e02883) allocated by thread T0 here: #0 0xf7239dee in malloc (/usr/lib32/libasan.so.2+0x96dee) #1 0x80abadd in bfd_malloc /mnt/data/playground/binutils-2.32-a/bfd/libbfd.c:275 SUMMARY: AddressSanitizer: heap-buffer-overflow cp-demangle.c:3356 d_expression_1 Shadow bytes around the buggy address: 0x3e9c04c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x3e9c04d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x3e9c04e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x3e9c04f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x3e9c0500: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00 =>0x3e9c0510:[03]fa fa fa fa fa fa fa fa fa 00 00 00 00 00 00 0x3e9c0520: 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa fa 0x3e9c0530: 00 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa 0x3e9c0540: fa fa fa fa fa fa 00 00 00 00 00 00 00 00 00 00 0x3e9c0550: 00 00 00 fa fa fa fa fa fa fa fa fa 00 00 00 00 0x3e9c0560: 00 00 00 00 00 00 00 00 04 fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe
[Bug other/55930] [7/8/9/10 Regression] libatomic build failure if configured with --disable-dependency-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930 --- Comment #11 from Jonathan Wakely --- I still think the solution is "don't do that for gcc" but in any case, the patch still hasn't been sent to the mailing list so isn't going to get reviewed let alone applied.
[Bug target/89245] [MIPS] v1 is assigned in jalr delay slot for later use at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89245 --- Comment #2 from Dragan Mladjenovic --- Fixed by r273314. Sorry for the inconvenience. I did not put a proper back-reference to this issue in the change log.
[Bug c++/91127] Incorrect checking of nonnull attribute with argument to a constructor of class with a virtual base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91127 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2019-07-10 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- I hate hate hate the fact that the nonnull attribute counts implicit arguments. The 'this' pointer must always be nonnull, so there's no benefit to including it, and other implicit arguments (like the int here for an in-charge constructor?) just complicate things and require users to understand details of a leaky abstraction. This bug should just be fixed to ignore the int, but counting the 'this' pointer can't be fixed without introducing a new attribute with sensible behaviour for member functions and constructors. I'll let Martin comment on whether changing handle_nonnull_attribute from giving an error to a warning was intended.
