[Bug target/87317] New: Missed optimisation: merging VMOVQ with operations that only use the low 8 bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87317
Bug ID: 87317
Summary: Missed optimisation: merging VMOVQ with operations
that only use the low 8 bytes
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Test:
#include
int f(void *ptr)
{
__m128i data = _mm_loadl_epi64((__m128i *)ptr);
data = _mm_cvtepu8_epi16(data);
return _mm_cvtsi128_si32(data);
}
GCC generates (-march=haswell or -march=skylake):
vmovq (%rdi), %xmm0
vpmovzxbw %xmm0, %xmm0
vmovd %xmm0, %eax
ret
Note that the VPMOVZXBW instruction only reads the low 8 bytes from the source,
including if it is a memory reference. Both Clang and ICC generate:
vpmovzxbw (%rdi), %xmm0
vmovd %xmm0, %eax
retq
Similarly for:
void f(void *dst, void *ptr)
{
__m128i data = _mm_cvtsi32_si128(*(int*)ptr);
data = _mm_cvtepu8_epi32(data);
_mm_storeu_si128((__m128i*)dst, data);
}
GCC:
vmovd (%rsi), %xmm0
vpmovzxbd %xmm0, %xmm0
vmovups %xmm0, (%rdi)
ret
Clang and ICC:
vpmovzxbd (%rsi), %xmm0
vmovdqu %xmm0, (%rdi)
retq
There are other instructions that might benefit from this.
AVX-512 memory instructions where the OpMask is a constant might be candidates
too.
[Bug middle-end/87188] Function pointer canonicalization optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87188 --- Comment #26 from John David Anglin --- Author: danglin Date: Fri Sep 14 23:30:32 2018 New Revision: 264337 URL: https://gcc.gnu.org/viewcvs?rev=264337=gcc=rev Log: PR middle-end/87188 * dojump.c (do_compare_and_jump): Canonicalize function pointers when one operand is a function pointer. Use POINTER_TYPE_P and FUNC_OR_METHOD_TYPE_P. * expr.c (do_store_flag): Use POINTER_TYPE_P and FUNC_OR_METHOD_TYPE_P. * fold-const.c (build_range_check): Likewise. * match.pd (simple_comparison): Likewise. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/dojump.c branches/gcc-8-branch/gcc/expr.c branches/gcc-8-branch/gcc/fold-const.c branches/gcc-8-branch/gcc/match.pd
[Bug middle-end/87188] Function pointer canonicalization optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87188 --- Comment #25 from John David Anglin --- Author: danglin Date: Fri Sep 14 23:26:12 2018 New Revision: 264336 URL: https://gcc.gnu.org/viewcvs?rev=264336=gcc=rev Log: PR middle-end/87188 * dojump.c (do_compare_and_jump): Canonicalize function pointers when one operand is a function pointer. Use POINTER_TYPE_P and FUNC_OR_METHOD_TYPE_P. * expr.c (do_store_flag): Use POINTER_TYPE_P and FUNC_OR_METHOD_TYPE_P. * fold-const.c (build_range_check): Likewise. * match.pd (simple_comparison): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/dojump.c trunk/gcc/expr.c trunk/gcc/fold-const.c trunk/gcc/match.pd
[Bug tree-optimization/87184] generic-match.c:55076:1: ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87184 John David Anglin changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #5 from John David Anglin --- Fixed by scc changes yesterday.
[Bug c/87316] gcc: internal compiler error: Killed (program cc1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87316 --- Comment #4 from David --- Hmm, yeah, increasing the memory a bit (4GB -> 5GB) leads to a successful compile. I guess it is expected that newer versions use more memory -- more features, etc. The interesting thing is that I was combining test units in a bid to save time. Each unit has to start a container, compile/link, and then run the test with gcov. What actually happened was that the one combined test on gcc 7 (once I got the memory bumped up) actually ran about 2.5 times slower than the three separate tests. That's compile/link + execution. Unfortunately the test scheduler does not allow me to separate those times but if I run the test manually it completes in < 1 second. That means the other 41 seconds are compile time. However, older compilers <= 4 showed no regression when dealing with the combined test file, which was overall more efficient than separate test runs. That advantage went away with the gcc 5: even though it is more memory efficient than gcc7 it is just about as slow. I had thought the gcc 7 compile/tests were slower because that's where we do our coverage testing. After disabling coverage I see little change in speed -- gcc7 is about six times slower than older compilers in my tests, aside from using a lot more memory. It could be that there's a variable that I'm missing here, but in general, is this expected behavior from newer versions of gcc?
[Bug c/82967] "did you mean" suggestions are way too suggestive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82967 --- Comment #11 from David Malcolm --- Fixed on trunk; keeping open until I backport it to gcc-8-branch.
[Bug c/82967] "did you mean" suggestions are way too suggestive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82967 --- Comment #10 from David Malcolm --- Author: dmalcolm Date: Fri Sep 14 22:02:58 2018 New Revision: 264335 URL: https://gcc.gnu.org/viewcvs?rev=264335=gcc=rev Log: Fix overeager spelling corrections (PR c/82967) This patch tunes class best_match's cutoff for rejecting meaningless spelling suggestions. Previously, we allowed an edit distance of up to half of the length of the longer of the goal string and closest candidate strings, rounded down. With this patch, we now allow only up to a third - with some tuning of rounding (and for very short strings), to ensure that: (a) everything that worked before still works (with the removal of a couple of cases that shouldn't), and that (b) the new threshold is always at least as conservative as the old threshold and thus shouldn't offer new nonsensical suggestions (with the possible exception of cases where transposition has helped; see r261521 aka Damerau-Levenshtein; PR other/69968). In particular, all of the bogus suggestions from PR c/82967 are now no longer offered. gcc/ChangeLog: PR c/82967 * spellcheck.c (get_edit_distance_cutoff): New function. (selftest::test_edit_distance_unit_test_oneway): Rename to... (selftest::test_get_edit_distance_one_way): ...this. (selftest::test_get_edit_distance_unit): Rename to... (selftest::test_get_edit_distance_both_ways): ...this. (selftest::test_edit_distances): Move tests to this new function, and test some more pairs of strings. Update for above renaming. (selftest::get_old_cutoff): New function. (selftest::test_get_edit_distance_cutoff): New function. (selftest::assert_suggested_for): New function. (ASSERT_SUGGESTED_FOR): New macro. (selftest::assert_not_suggested_for): New function. (ASSERT_NOT_SUGGESTED_FOR): New macro. (selftest::test_suggestions): New function. (selftest::spellcheck_c_tests): Move test_get_edit_distance_unit tests to selftest::test_edit_distances and call it. Add calls to selftest::test_get_edit_distance_cutoff and selftest::test_suggestions. * spellcheck.h (get_edit_distance_cutoff): New function declaration. (best_match::consider): Replace hard-coded cutoff calculation with a call to... (best_match::get_cutoff): New declaration. (best_match::get_best_meaningful_candidate): Likewise. gcc/testsuite/ChangeLog: PR c/82967 * c-c++-common/attributes-1.c: Remove bogus suggestion from dg-prune-output. * gcc.dg/diagnostic-token-ranges.c (undeclared_identifier): Remove bogus suggestion. * gcc.dg/spellcheck-identifiers-4.c: New test. Added: trunk/gcc/testsuite/gcc.dg/spellcheck-identifiers-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/spellcheck.c trunk/gcc/spellcheck.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/attributes-1.c trunk/gcc/testsuite/gcc.dg/diagnostic-token-ranges.c
[Bug other/69968] RFC: Use Damerau-Levenshtein within spellcheck.c, rather than Levenshtein
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69968 --- Comment #7 from David Malcolm --- Author: dmalcolm Date: Fri Sep 14 22:02:58 2018 New Revision: 264335 URL: https://gcc.gnu.org/viewcvs?rev=264335=gcc=rev Log: Fix overeager spelling corrections (PR c/82967) This patch tunes class best_match's cutoff for rejecting meaningless spelling suggestions. Previously, we allowed an edit distance of up to half of the length of the longer of the goal string and closest candidate strings, rounded down. With this patch, we now allow only up to a third - with some tuning of rounding (and for very short strings), to ensure that: (a) everything that worked before still works (with the removal of a couple of cases that shouldn't), and that (b) the new threshold is always at least as conservative as the old threshold and thus shouldn't offer new nonsensical suggestions (with the possible exception of cases where transposition has helped; see r261521 aka Damerau-Levenshtein; PR other/69968). In particular, all of the bogus suggestions from PR c/82967 are now no longer offered. gcc/ChangeLog: PR c/82967 * spellcheck.c (get_edit_distance_cutoff): New function. (selftest::test_edit_distance_unit_test_oneway): Rename to... (selftest::test_get_edit_distance_one_way): ...this. (selftest::test_get_edit_distance_unit): Rename to... (selftest::test_get_edit_distance_both_ways): ...this. (selftest::test_edit_distances): Move tests to this new function, and test some more pairs of strings. Update for above renaming. (selftest::get_old_cutoff): New function. (selftest::test_get_edit_distance_cutoff): New function. (selftest::assert_suggested_for): New function. (ASSERT_SUGGESTED_FOR): New macro. (selftest::assert_not_suggested_for): New function. (ASSERT_NOT_SUGGESTED_FOR): New macro. (selftest::test_suggestions): New function. (selftest::spellcheck_c_tests): Move test_get_edit_distance_unit tests to selftest::test_edit_distances and call it. Add calls to selftest::test_get_edit_distance_cutoff and selftest::test_suggestions. * spellcheck.h (get_edit_distance_cutoff): New function declaration. (best_match::consider): Replace hard-coded cutoff calculation with a call to... (best_match::get_cutoff): New declaration. (best_match::get_best_meaningful_candidate): Likewise. gcc/testsuite/ChangeLog: PR c/82967 * c-c++-common/attributes-1.c: Remove bogus suggestion from dg-prune-output. * gcc.dg/diagnostic-token-ranges.c (undeclared_identifier): Remove bogus suggestion. * gcc.dg/spellcheck-identifiers-4.c: New test. Added: trunk/gcc/testsuite/gcc.dg/spellcheck-identifiers-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/spellcheck.c trunk/gcc/spellcheck.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/attributes-1.c trunk/gcc/testsuite/gcc.dg/diagnostic-token-ranges.c
[Bug c/87316] gcc: internal compiler error: Killed (program cc1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87316 Andrew Pinski changed: What|Removed |Added Keywords||memory-hog --- Comment #3 from Andrew Pinski --- >gcc: internal compiler error: Killed (program cc1) This means GCC ran out of memory.
[Bug c/87316] gcc: internal compiler error: Killed (program cc1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87316 --- Comment #2 from David --- The test.i file was too large to attach directly so I was forced to gzip it.
[Bug c/87316] gcc: internal compiler error: Killed (program cc1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87316 --- Comment #1 from David --- Created attachment 44696 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44696=edit preprocessed output of test.c
[Bug c/87316] New: gcc: internal compiler error: Killed (program cc1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87316 Bug ID: 87316 Summary: gcc: internal compiler error: Killed (program cc1) Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: david at pgmasters dot net Target Milestone: --- Got this while compiling a unit test module. A bunch of .c files are directly included and there are a lot of test macros so it gets pretty big. If I remove some tests then it compiles and runs so the problem seems size related. However, it *does* work on 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5), 4.4.7 20120313 (Red Hat 4.4.7-23), 4.8.5 20150623 (Red Hat 4.8.5-28), and 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10) all running on various images in the same Docker environment. --- * gcc version and options: $ docker exec -it test-0 gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-16ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --with-as=/usr/bin/x86_64-linux-gnu-as --with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-7 --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 --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3) * system type: Ubuntu 18.04 (4GB memory) on Docker version 18.06.0-ce, build 0ffa825 on VirtualBox 5.2.16 on MacOS 10.13.6 iMac (Retina 5K, 27-inch, Late 2014, 4 GHz Intel Core i7) * gcc command line and error: vagrant@u18-test:~/test/gcov-u18-0$ gcc -save-temps -I. test.c gcc: internal compiler error: Killed (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See for instructions.
[Bug tree-optimization/87314] pointless comparison of malloc result to a string not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87314
--- Comment #1 from Martin Sebor ---
Same here (Clang doesn't eliminate the test here though):
void f (void)
{
void *p = __builtin_malloc (sizeof (void*));
if (p == f) // not folded
__builtin_abort ();
}
Here, GCC eliminates the equality test with a but not the one with b (Clang
eliminates neither):
char a[8] = "";
char b[8];
void f (void)
{
void *p = __builtin_malloc (sizeof (void*));
if (p == a) // folded to false
__builtin_abort ();
}
void g (void)
{
void *p = __builtin_malloc (sizeof (void*));
if (p == b) // not folded
__builtin_abort ();
}
[Bug tree-optimization/87315] New: uninitialized read from memory returned by malloc not eliminated, no warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87315
Bug ID: 87315
Summary: uninitialized read from memory returned by malloc not
eliminated, no warning
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The test case below is undefined because the memory returned by malloc is
uninitialized. The read access to the memory should be diagnosed. In
addition, GCC could (and arguably should) also eliminate the test since the
memory returned from malloc cannot contain valid pointers (as documented in the
attribute malloc section of GCC manual: "the pointer returned by the function
cannot alias any other pointer valid when the function returns").
As a data point, Clang folds the test to true and replaces the body of the
function with the call to abort().
$ cat x.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout x.c
void f (void)
{
void **p = __builtin_malloc (sizeof (void*));
if (*p == p)
__builtin_abort ();
}
;; Function f (f, funcdef_no=0, decl_uid=1906, cgraph_uid=1, symbol_order=0)
f ()
{
void * * p;
void * _1;
[local count: 1073741824]:
p_4 = __builtin_malloc (8);
_1 = *p_4;
if (_1 == p_4)
goto ; [0.00%]
else
goto ; [99.96%]
[count: 0]:
__builtin_abort ();
[local count: 1073312328]:
return;
}
[Bug tree-optimization/87314] New: pointless comparison of malloc result to a string not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87314
Bug ID: 87314
Summary: pointless comparison of malloc result to a string not
eliminated
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC fails to eliminate the impossible test in the test case below (despite the
warning). Clang eliminates it as expected.
$ cat x.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout x.c
void f (void)
{
char *p = __builtin_malloc (8);
if (p == "")
__builtin_abort ();
}
x.c: In function ‘f’:
x.c:5:9: warning: comparison with string literal results in unspecified
behavior [-Waddress]
5 | if (p == "")
| ^~
;; Function f (f, funcdef_no=0, decl_uid=1906, cgraph_uid=1, symbol_order=0)
f ()
{
char * p;
[local count: 1073741824]:
p_3 = __builtin_malloc (8);
if (p_3 == "")
goto ; [0.00%]
else
goto ; [99.96%]
[count: 0]:
__builtin_abort ();
[local count: 1073312328]:
return;
}
[Bug tree-optimization/87313] New: attribute malloc not used for alias analysis when it could be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87313
Bug ID: 87313
Summary: attribute malloc not used for alias analysis when it
could be
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Attribute malloc is documented as:
This tells the compiler that a function is malloc-like, i.e., that the
pointer P returned by the function cannot alias any other pointer valid when
the function returns, and moreover no pointers to valid objects occur in any
storage addressed by P.
The test case below shows that although GCC takes advantage of this property to
eliminate impossible tests when calling __builtin_malloc it doesn't do the same
when calling a user-defined function declared with the attribute.
$ cat x.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout x.c
void f (int **p)
{
int *x = *p;
int **q = __builtin_malloc (sizeof (int*));
*q = 0; // *q cannot be equal to *p prior to the assignment
if (x != *p) // folded to false
__builtin_abort ();
}
__attribute__ ((malloc)) void* g (int);
void h (int **p)
{
int *x = *p;
int **q = g (sizeof (int*));
*q = 0; // *q cannot be equal to *p prior to the assignment
if (x != *p) // not folded
__builtin_abort ();
}
;; Function f (f, funcdef_no=0, decl_uid=1906, cgraph_uid=1, symbol_order=0)
f (int * * p)
{
[local count: 1073741824]:
return;
}
;; Function h (h, funcdef_no=1, decl_uid=1913, cgraph_uid=2, symbol_order=1)
h (int * * p)
{
int * x;
int * _1;
[local count: 1073741824]:
x_4 = *p_3(D);
g (8);
_1 = *p_3(D);
if (_1 != x_4)
goto ; [0.00%]
else
goto ; [99.96%]
[count: 0]:
__builtin_abort ();
[local count: 1073312328]:
return;
}
[Bug c/65158] printf attribute error reporting assumes single-byte characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65158 Tom Tromey changed: What|Removed |Added Status|WAITING |REOPENED --- Comment #2 from Tom Tromey --- (In reply to Martin Sebor from comment #1) > There is no format specifier in C or POSIX that involves a multibyte > character. They're all single byte characters in the 7-bit ASCII range that > should convert to single byte characters in most (all?) encodings. It would > take an unusual character set to map a 7-bit character to a multibyte > sequence. Is it worth worrying about this corner case? I think this is just a bug I noticed by inspection. The issue is that if the user typo the source somehow, gcc will print something invalid. So, yes, minor; but nevertheless a bug. I'm reopening on that basis.
[Bug c/87311] missing integer overflow detection on negation of the minimum value with -ftrapv or UB sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87311 --- Comment #1 from Marc Glisse --- /* -A - 1 -> ~A */ (simplify (minus (convert? (negate @0)) integer_each_onep) (if (!TYPE_OVERFLOW_TRAPS (type) && tree_nop_conversion_p (type, TREE_TYPE (@0))) (bit_not (convert @0 I would have expected at least -ftrapv to disable this transformation, but I see "i = ~i" in the .original dump...
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #12 from Jeremy Huddleston Sequoia
---
(In reply to Francois-Xavier Coudert from comment #11)
> (In reply to Jeremy Huddleston Sequoia from comment #10)
> > Given those, gcc only builds if we have the DevSDK ("headers at /" package)
> > installed.
>
> I may be misunderstanding what you say: GCC builds and runs fine without the
> headers in /usr/include. At Homebrew, we are not recommending users to
> install the /usr/include headers package, and we build and run GCC fine. The
> configuration is the following
> (https://github.com/Homebrew/homebrew-core/blob/master/Formula/gcc.rb):
>
> --with-native-system-header-dir=/usr/include
> --with-sysroot=/path/to/sdk
>
> if the system headers are in /path/to/sdk/usr/include. Thus, on a Mojave
> installation with Xcode CLT installed, we set /path/to/sdk to
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Yeah, I documented the workaround of using --with-sysroot in the MacPorts port
when filing these bugs and passed on to Homebrew, but that ends up causing
gcc's search path to always look in that sysroot (ie, it becomes the default
sysroot). Thus, users will build executables that behave differently based on
where there SDK was located on their build system. That is certainly not what
is desired. If you have a build fleet that used an SDK that was located at
/Volumes/SDKs/AllMacSDKs/MacOSX10.14.sdk at build time, but your users have
/Applications/MyXcodesPath/Xcode-10.app/.../MacOSX.sdk, then that mismatch can
cause problems.
The point of --with-sysroot is to change the behavior of the built product (the
final gcc executable). The point of --with-build-sysroot is to change how we
build gcc.
[Bug c/80515] __attribute__ ((__noreturn__)) false alarm for 'main'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80515 Martin Sebor changed: What|Removed |Added Keywords||diagnostic CC||msebor at gcc dot gnu.org Host||52003 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=52003 --- Comment #12 from Martin Sebor --- See also bug 52003.
[Bug c++/77440] [[noreturn]] does not work at end of main().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77440 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Martin Sebor --- Bug 80515 is about the same thing and has a lengthy discussion so let me resolve this as duplicate of the former. *** This bug has been marked as a duplicate of bug 80515 ***
[Bug c/80515] __attribute__ ((__noreturn__)) false alarm for 'main'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80515 Martin Sebor changed: What|Removed |Added CC||kataoka-instructor at ka2 dot so-n ||et.ne.jp --- Comment #11 from Martin Sebor --- *** Bug 77440 has been marked as a duplicate of this bug. ***
[Bug c++/80495] attribute [[noreturn]] is accepted in function pointer declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80495 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-14 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||6.4.0, 7.3.0, 8.2.0, 9.0 --- Comment #2 from Martin Sebor --- Confirmed. Both Clang and ICC diagnose the test case. At the same time, I agree that attributes in the C++ standard are poorly specified.
[Bug c++/87312] New: statics in lambdas should be weak not local symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87312
Bug ID: 87312
Summary: statics in lambdas should be weak not local symbols
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/oSuiQO
// IN HEADER:
inline auto lambda = [] () -> int* {
static int foo;
return
};
inline int* func() {
static int foo;
return
};
// NOT IN HEADER:
int* lambda_addr() {
return lambda();
}
int* func_addr() {
return func();
}
Both of the "foo" objects should have exactly one address in the whole program.
The "foo" in func() will work correctly, but the "foo" in the lambda will
incorrectly have one address in each TU where it is used.
[Bug c/79586] missing -Wdeprecated depending on position of attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79586 Martin Sebor changed: What|Removed |Added Last reconfirmed|2017-07-31 00:00:00 |2018-9-14 Known to fail|7.0 |7.2.0, 8.2.0, 9.0 --- Comment #3 from Martin Sebor --- No improvement in recent GCC versions.
[Bug c++/79458] attributes on constructor between class name and parameter list not accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79458
Martin Sebor changed:
What|Removed |Added
Known to fail||7.3.0, 8.2.0, 9.0
--- Comment #4 from Martin Sebor ---
No improvement in GCC 8 or 9. The top of trunk prints:
$ cat t.C && gcc -O2 -S -Wall -std=c++1z t.C
class test {
test [[gnu::nonnull]] (char * arg);
};
test::test(char * arg) {
}
t.C:3:27: error: expected unqualified-id before ‘char’
3 | test [[gnu::nonnull]] (char * arg);
| ^~~~
t.C:3:27: error: expected ‘)’ before ‘char’
3 | test [[gnu::nonnull]] (char * arg);
| ~^~~~
| )
t.C:6:1: error: no declaration matches ‘test::test(char*)’
6 | test::test(char * arg) {
| ^~~~
t.C:2:7: note: candidates are: ‘constexpr test::test(test&&)’
2 | class test {
| ^~~~
t.C:2:7: note: ‘constexpr test::test(const test&)’
t.C:2:7: note: ‘constexpr test::test()’
t.C:2:7: note: ‘class test’ defined here
[Bug c++/79021] attribute noreturn on function template ignored in generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79021 Martin Sebor changed: What|Removed |Added Keywords||diagnostic CC||msebor at gcc dot gnu.org Known to fail||6.4.0, 7.3.0, 8.2.0, 9.0 --- Comment #2 from Martin Sebor --- Reconfirmed with the top of trunk (GCC 9).
[Bug c/87311] New: missing integer overflow detection on negation of the minimum value with -ftrapv or UB sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87311
Bug ID: 87311
Summary: missing integer overflow detection on negation of the
minimum value with -ftrapv or UB sanitizer
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
When using -ftrapv or -fsanitize=undefined, GCC sometimes misses integer
overflow detection on negation of the minimum value (e.g. LONG_MIN for type
long). For instance:
#include
#include
int main (void)
{
long i, j;
i = j = LONG_MIN;
i = -i - 1;
fprintf (stderr, "%ld\n", i);
j = -j;
fprintf (stderr, "%ld\n", j);
return 0;
}
$ gcc-snapshot tst.c -o tst -ftrapv
$ ./tst
9223372036854775807
zsh: abort (core dumped) ./tst
Integer overflow on -j is detected, but not the one on -i. With optimizations,
none is detected:
$ gcc-snapshot tst.c -o tst -ftrapv -O
$ ./tst
9223372036854775807
-9223372036854775808
which is particularly bad because the code may assume that negating a negative
value yields a positive value.
With -fsanitize=undefined, one gets the expected error "runtime error: negation
of -9223372036854775808 cannot be represented in type 'long int'; cast to an
unsigned type to negate this value to itself" only for -j (with or without
optimizations).
All GCC versions seem to be affected, including the trunk.
[Bug c++/78951] Attributes allowed in an incorrect position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78951 Martin Sebor changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-14 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||7.3.0, 8.2.0, 9.0 --- Comment #1 from Martin Sebor --- Confirmed. Clang and ICC both reject the code.
[Bug c++/77542] __attribute__((warn_unused_result)) ignored on function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77542
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||msebor at gcc dot gnu.org
Known to work||7.3.0, 8.2.0, 9.0
Resolution|--- |FIXED
Known to fail||5.3.0, 6.4.0
--- Comment #4 from Martin Sebor ---
After fixing the test in attachment 39608 I get the output below which I think
is what the reporter expected. Resolving as fixed.
$ cat t.C && xg++ -S -Wall t.C
#include
class Foo {
public:
void close() { }
private:
int foo;
};
struct FooDeleter
{
void operator()(Foo *foo) { foo->close(); }
};
class Test {
public:
typedef std::unique_ptr BindScope;
template
BindScope bind(Args&&... args) __attribute__((warn_unused_result));
BindScope checkWarningInt(int arg) __attribute__((warn_unused_result));
BindScope checkWarningFoo(int arg) __attribute__((warn_unused_result));
operator Foo*() { return m_ptr.get(); }
private:
std::unique_ptr m_ptr;
};
template
Test::BindScope Test::bind(Args&&... args) {
BindScope bindScope(*this);
return std::move(bindScope);
}
Test::BindScope Test::checkWarningFoo(int arg) {
BindScope bindScope(*this);
return std::move(bindScope);
}
Test::BindScope Test::checkWarningInt(int arg) {
return 0;
}
int main(int argc, char *argv[]) {
Test t;
t.bind(1, "foo"); // no warning <--- that's my bug
t.checkWarningFoo(1); // emits warning
t.checkWarningInt(1); // emits warning
}
t.C: In member function ‘Test::BindScope Test::checkWarningFoo(int)’:
t.C:38:19: warning: moving a local object in a return statement prevents copy
elision [-Wpessimizing-move]
38 | return std::move(bindScope);
| ~^~~
t.C:38:19: note: remove ‘std::move’ call
t.C: In function ‘int main(int, char**)’:
t.C:47:19: warning: ignoring return value of ‘Test::BindScope Test::bind(Args&&
...) [with Args = {int, const char (&)[4]}; Test::BindScope =
std::unique_ptr]’, declared with attribute warn_unused_result
[-Wunused-result]
47 | t.bind(1, "foo"); // no warning <--- that's my bug
| ^
t.C:31:17: note: declared here
31 | Test::BindScope Test::bind(Args&&... args) {
| ^~~~
t.C:48:23: warning: ignoring return value of ‘Test::BindScope
Test::checkWarningFoo(int)’, declared with attribute warn_unused_result
[-Wunused-result]
48 | t.checkWarningFoo(1); // emits warning
| ^
t.C:36:17: note: declared here
36 | Test::BindScope Test::checkWarningFoo(int arg) {
| ^~~~
t.C:49:23: warning: ignoring return value of ‘Test::BindScope
Test::checkWarningInt(int)’, declared with attribute warn_unused_result
[-Wunused-result]
49 | t.checkWarningInt(1); // emits warning
| ^
t.C:41:17: note: declared here
41 | Test::BindScope Test::checkWarningInt(int arg) {
| ^~~~
t.C: In instantiation of ‘Test::BindScope Test::bind(Args&& ...) [with Args =
{int, const char (&)[4]}; Test::BindScope = std::unique_ptr]’:
t.C:47:18: required from here
t.C:33:29: warning: moving a local object in a return statement prevents copy
elision [-Wpessimizing-move]
33 | return std::move(bindScope);
| ^
t.C:33:29: note: remove ‘std::move’ call
[Bug go/87260] [8/9 Regression] go fails to build a simple program on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87260 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ian Lance Taylor --- Should be fixed on trunk and GCC 8 branch.
[Bug go/87260] [8/9 Regression] go fails to build a simple program on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87260 --- Comment #3 from ian at gcc dot gnu.org --- Author: ian Date: Fri Sep 14 19:42:27 2018 New Revision: 264331 URL: https://gcc.gnu.org/viewcvs?rev=264331=gcc=rev Log: PR go/87260 cmd/go: correct gccgo buildid file on ARM Bring in https://golang.org/cl/135297 from the gc repository to fix a GCC bug report. Original CL description: The GNU assembler for ARM treats @ as a comment character, so section types must be written using % instead. Fixes https://gcc.gnu.org/PR87260. Reviewed-on: https://go-review.googlesource.com/135360 Modified: branches/gcc-8-branch/libgo/go/cmd/go/internal/work/buildid.go
[Bug c++/77440] [[noreturn]] does not work at end of main().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77440
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-09-14
CC||msebor at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=52003
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
Bug 52003 was closed as invalid so that would be a precedent for doing the same
with this report. But, the Intel compiler does avoid issuing the warning and
that seems reasonable and useful to me. Not warning on the test case (i.e.,
main) is also consistent with not issuing warning for the following:
[[noreturn]] int f () { while(true); }
With that I will confirm this request.
[Bug c++/77419] Inconsistent behavior with auto& and __attribute__((unused))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77419
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-09-14
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||6.4.0, 7.3.0, 8.2.0, 9.0
--- Comment #1 from Martin Sebor ---
Confirmed with the top of trunk (GCC 9):
$ cat t.C && gcc -O2 -S -Wall t.C
int main() {
int __attribute__((unused)) int_var_unused = 42;
int int_var = 42;
int& __attribute__((unused)) int_ref = int_var;
auto __attribute__((unused)) auto_var_unused = 42;
auto auto_var = 42;
auto& __attribute__((unused)) auto_ref = auto_var;
return 0;
}
t.C: In function ‘int main()’:
t.C:8:35: warning: unused variable ‘auto_ref’ [-Wunused-variable]
8 | auto& __attribute__((unused)) auto_ref = auto_var;
| ^~~~
[Bug c++/77306] Unable to specify visibility for explicit template instantiations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77306 Martin Sebor changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-14 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||7.3.0, 8.2.0, 9.0 --- Comment #2 from Martin Sebor --- Confirmed. Please post patches for review to gcc-patches.
[Bug c++/72865] Adding __may_alias__ attribute triggers a compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72865 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Known to work||7.3.0, 8.2.0, 9.0 Resolution|--- |FIXED Known to fail||5.2.0 --- Comment #5 from Martin Sebor --- Confirmed fixed.
[Bug middle-end/70678] Static function compilation behaviour changes with __attribute__((optimize("O2"))) even if already compiling with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70678 Martin Sebor changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Component|c |middle-end Resolution|--- |WONTFIX Known to fail||5.4.0, 6.3.0, 7.3.0, 8.2.0, ||9.0 --- Comment #3 from Martin Sebor --- Confirmed with the top of trunk but resolving as Won't Fix based on comment #2.
[Bug c++/87300] -Wredundant-move gives false positives in C++11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87300 --- Comment #4 from Steinar H. Gunderson --- Wait, can it elide the move even if it's a conversion? How could that work in the general case?
[Bug c++/87300] -Wredundant-move gives false positives in C++11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87300 --- Comment #3 from Jonathan Wakely --- Yes The first published standard to include the change was C++14 but it's a DR against the previous standard. That means it's fixing a bug in the previous standard. The -std=c++11 flag is documented to mean C++11 *plus amendments*. Also, the point of the warning is to alert you to pessimised code, which is definitely the case here. Without the std::move the code compiles and can elide the move construction. With the std::move a new object must be constructed.
[Bug c++/70435] section attribute of a function template is not honored.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70435 Martin Sebor changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-14 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||5.3.0, 6.4.0, 7.3.0, 8.2.0, ||9.0 --- Comment #4 from Martin Sebor --- Confirmed with the top of trunk.
[Bug c/68524] Please support attributes between function definition and opening brace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68524 --- Comment #2 from joseph at codesourcery dot com --- I believe the syntax in N2269 does allow [[]] attributes there (and disallows them as prefixes on old-style parameters to avoid ambiguity) - but they appertain to the function type (whereas the corresponding position for GNU attributes - after the full declarator and any following asm, before any initializer - appertains to the entity being declared).
[Bug c++/70382] Attribute not supported on bit-field declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70382 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Known to work||8.2.0, 9.0 Resolution|--- |FIXED Known to fail||5.3.0, 6.4.0, 7.3.0 --- Comment #1 from Martin Sebor --- This was fixed in GCC 8 via r253281: r253281 | jakub | 2017-09-29 03:49:15 -0400 (Fri, 29 Sep 2017) | 8 lines cp/ * parser.c (cp_parser_member_declaration): Parse attributes before colon of a bitfield in addition to after colon. testsuite/ * g++.dg/ext/bitfield7.C: New test. * g++.dg/ext/bitfield8.C: New test. * g++.dg/ext/bitfield9.C: New test.
[Bug c/70082] Attribute ifunc marked functions should not be allowed to call other functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70082 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-09-14 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Martin Sebor --- Carlos, do you still feel diagnosing some of the [mis]uses would be helpful, e.g., by a warning? (I ask because I've been doing some work in this area -- pr81824 -- and I might be able to take care of this at some point as well, perhaps for GCC 10).
[Bug c/45780] Warning for arithmetic operations involving C99 _Bool variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45780 Eric Gallager changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to Uroš Bizjak from comment #0) > Pasted from the thread that introduced _Bool in place of "GCC bool": > > > > > >> It can be done ultimately, but as a prerequisite, we should have > > >> warnings in -Wextra for all of > > >> > > >> ? boolvar++; ++boolvar; > > >> ? boolvar--; --boolvar; > > >> ? boolvar = nonbool; > > >> ? boolvar & nonbool; boolvar &= nonbool; > > >> ? boolvar | nonbool; boolvar |= nonbool; > > >> ? boolvar ^ nonbool; boolvar ^= nonbool; > > > > > > Fair enough. I have CCed Manuel, perhaps he is interested in this warning. > > cc-ing him on this, too
[Bug c/87310] -Wc90-c99-compat does not warn about bool usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87310 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- What do the contents of your look like?
[Bug c/68524] Please support attributes between function definition and opening brace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68524 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-14 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Clang also supports the syntax with a warning. Confirmed (I have no idea how challenging it might be to implement). There also is a proposal to add the standard C++ attribute syntax (e.g., [[gnu::const]]) to C. The C++ syntax doesn't allow attributes there.
[Bug c/68201] alloc_size attribute and memory pools
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68201
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Severity|normal |enhancement
--- Comment #3 from Martin Sebor ---
I'm also not sure I see how such an attribute/built-in could be used as
described. What might perhaps be useful is the ability to create an
association between a pointer and a size of the object it points to, e.g., like
so:
struct MemPool {
size_t block_size;
char pool[] __attribute__ ((alloc_size (block_size)));
};
This way, in cases when GCC could determine the (constant) value or range of
block_size it could use that value (or range) to detect buffer overflows.
I have no idea if this is something sufficiently common to justify the effort
it would take to add such an extension.
[Bug c/68039] Incorrect unused-result warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68039 Martin Sebor changed: What|Removed |Added Last reconfirmed|2015-10-22 00:00:00 |2018-9-14 CC||msebor at gcc dot gnu.org Known to fail||5.3.0, 6.4.0, 7.3.0, 8.2.0, ||9.0 --- Comment #3 from Martin Sebor --- Reconfirming. No change in GCC 8 or 9.
[Bug c/65158] printf attribute error reporting assumes single-byte characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65158 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |WAITING Last reconfirmed||2018-09-14 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- There is no format specifier in C or POSIX that involves a multibyte character. They're all single byte characters in the 7-bit ASCII range that should convert to single byte characters in most (all?) encodings. It would take an unusual character set to map a 7-bit character to a multibyte sequence. Is it worth worrying about this corner case? (-Wformat doesn't currently handle the -fexec-charset= option so that should presumably be a higher priority problem to fix.)
[Bug c/65115] default init_priority attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65115
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-09-14
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
Confirmed. The latest documentation reads:
@item init_priority (@var{priority})
@cindex @code{init_priority} variable attribute
In Standard C++, objects defined at namespace scope are guaranteed to be
initialized in an order in strict accordance with that of their definitions
@emph{in a given translation unit}. No guarantee is made for initializations
across translation units. However, GNU C++ allows users to control the
order of initialization of objects defined at namespace scope with the
@code{init_priority} attribute by specifying a relative @var{priority},
a constant integral expression currently bounded between 101 and 65535
inclusive. Lower numbers indicate a higher priority.
In the following example, @code{A} would normally be created before
@code{B}, but the @code{init_priority} attribute reverses that order:
@smallexample
Some_Class A __attribute__ ((init_priority (2000)));
Some_Class B __attribute__ ((init_priority (543)));
@end smallexample
[Bug middle-end/77696] Confusing wording for -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77696 --- Comment #17 from David Malcolm --- Prototype of a new approach posted here: "[PATCH 0/5] RFC: gimple-ssa-sprintf.c: a new approach (PR middle-end/77696)" https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00771.html
[Bug c++/65055] Types and variables differ in handling of multiple instances of attribute aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65055 Martin Sebor changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-14 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||6.4.0, 7.3.0, 8.2.0, 9.0 --- Comment #1 from Martin Sebor --- Confirmed with the top of trunk (GCC 9).
[Bug c/64862] printf attribute should accept other string types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #7 from Martin Sebor --- Any progress?
[Bug c++/63650] conflicting type attributes specified for ‘virtual..'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63650 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-09-14 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #9 from Martin Sebor --- Is this still a problem with recent versions of GCC? If so, can you please post your final test case and the compiler output and fill in the Target field (see the line starting with Target: in GCC's output with the -v option).
[Bug c/87310] -Wc90-c99-compat does not warn about bool usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87310 --- Comment #1 from Róbert Kohányi --- Created attachment 44695 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44695=edit a.c preprocessed version
[Bug c/87310] New: -Wc90-c99-compat does not warn about bool usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87310
Bug ID: 87310
Summary: -Wc90-c99-compat does not warn about bool usage
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kohanyi.robert at gmail dot com
Target Milestone: ---
Created attachment 44694
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44694=edit
gcc -v outputs
When compiling code that uses and bool declarations with
-Wc90-c99-compat (with or without -std=c90), no diagnostic is issued.
Something like this
#include
#include
main() {
bool ok = true;
printf("%u\n", ok);
}
when compiled with
gcc -std=c90 -Wc90-c99-compat a.c
there's no warning, but I expected a warn about bool usage.
When it looks like this
#include
main() {
_Bool ok = 1;
printf("%u\n", ok);
}
the warning `warning: ISO C90 does not support boolean types
[-Wc90-c99-compat]' is raised.
Tried with multiple version of gcc. Attached the output of different gcc -v
runs.
Try it here at tio.run: https://bit.ly/2CXnvXm
StackOverflow thread: https://stackoverflow.com/questions/52307780
[Bug c++/63459] operator new and returns_nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63459 Martin Sebor changed: What|Removed |Added Status|NEW |WAITING CC||msebor at gcc dot gnu.org --- Comment #8 from Martin Sebor --- With GCC 7 and later the null test is eliminated by EVRP. Is that early enough (and can this request be resolved)?
[Bug tree-optimization/87303] DFmode FP constants are not correctly truncated when promoted to XFmode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87303 --- Comment #2 from joseph at codesourcery dot com --- I don't see a bug here. Excess precision semantics mean that the comparison is effectively with 0.1e-100L (whereas the array initializer is (double) 0.1e-100L). If you use "!= (double) 0.1e-100" in the test - add a cast of the constant to double - then it should pass with -fexcess-precision=standard.
[Bug sanitizer/62307] -fsanitize=undefined doesn't pay attention to __attribute__((returns_nonnull))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62307 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-14 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Martin Sebor --- I would have expected to be able to suppress the null checks in the caller with the no_sanitize attribute on the declaration of the called function but it seems that the attribute applies to the function definition and doesn't affect its callers. (Whether that's how it's meant to work isn't clear from the manual.) So with that I'll confirm this request. It seems to me that it should be possible to avoid these checks, either with the no_sanitize attribute, or under some new option.
[Bug c/62194] Add deadfield attribute to ignore initializers for a structure field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62194 --- Comment #5 from Josh Triplett --- (In reply to Martin Sebor from comment #4) > (In reply to Josh Triplett from comment #0) > > > > I'm willing to work on a patch for this. > > If there still is interest in this feature are you still interested in > working on a patch? (If so, please assign the bug to yourself and post the > patch to gcc-patches.) I'm still interested in this; I was hoping to get some confirmation that the overall approach seems reasonable before starting on a patch. Does the concept of __attribute__((deadfield)) seem reasonable? If so, I'd be happy to develop a patch for this.
[Bug tree-optimization/87309] Spurious note: messages when building with -fopt-info-vec-optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87309 Ilya Leoshkevich changed: What|Removed |Added CC||iii at linux dot ibm.com --- Comment #1 from Ilya Leoshkevich --- Created attachment 44693 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44693=edit patch This fixes the problem for me, but I'm not sure if this is the right solution.
[Bug c/62194] Add deadfield attribute to ignore initializers for a structure field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62194 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-09-14 Ever confirmed|0 |1 --- Comment #4 from Martin Sebor --- (In reply to Josh Triplett from comment #0) > > I'm willing to work on a patch for this. If there still is interest in this feature are you still interested in working on a patch? (If so, please assign the bug to yourself and post the patch to gcc-patches.)
[Bug c++/61941] Mis-parsing of warn_unused_result function with ref-qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61941 Martin Sebor changed: What|Removed |Added Keywords||rejects-valid Status|NEW |RESOLVED CC||msebor at gcc dot gnu.org Known to work||7.3.0, 8.2.0, 9.0 Resolution|--- |FIXED --- Comment #3 from Martin Sebor --- This was fixed in GCC 7 by r241831: r241831 | jason | 2016-11-03 15:52:58 -0400 (Thu, 03 Nov 2016) | 12 lines Use type_hash_eq langhook in check_qualified_type. gcc/ * tree.c (check_lang_type): New. (check_qualified_type): Use it. (check_aligned_type): Use it. * tree.h: Declare it. gcc/cp/ * tree.c (cp_check_qualified_type): Call check_base_type instead of check_qualified_type. (cxx_type_hash_eq): Check ref-qualifiers. * typeck.c (apply_memfn_quals): No need to mess with TYPE_CANONICAL.
[Bug tree-optimization/87309] New: Spurious note: messages when building with -fopt-info-vec-optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87309
Bug ID: 87309
Summary: Spurious note: messages when building with
-fopt-info-vec-optimized
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
$ cat test.cpp
void a() {}
$ g++ -c test.cpp -fopt-info-vec-optimized -O3
test.cpp:1:6: note: test.cpp:1:11: note:
This is coming from DUMP_VECT_SCOPE ("vect_analyze_data_refs"); in
vect_analyze_data_refs(). I suspect that alt_flags check around dump_loc call
is missing in dump_context::begin_scope.
[Bug target/87224] ICE in extract_constrain_insn, at recog.c:2206
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87224 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.3 --- Comment #5 from Segher Boessenkool --- Patch committed, and backported to 8. Fixed.
[Bug target/87224] ICE in extract_constrain_insn, at recog.c:2206
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87224 --- Comment #4 from Segher Boessenkool --- Author: segher Date: Fri Sep 14 15:52:23 2018 New Revision: 264320 URL: https://gcc.gnu.org/viewcvs?rev=264320=gcc=rev Log: Backport PR87224 fix to 8 Backport from trunk 2018-09-14 Segher Boessenkool PR target/87224 * config/rs6000/rs6000.md (*mov_hardfloat64): Add Z to the Y alternatives. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/rs6000/rs6000.md
[Bug debug/87308] New: pretty printer for std::any fails with: Python Exception Unknown manager function in std::any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87308
Bug ID: 87308
Summary: pretty printer for std::any fails with: Python
Exception Unknown
manager function in std::any
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jeff at jgarrett dot org
Target Milestone: ---
Using g++-8.1 and gdb-8.2 both built from source on a CentOS 7.3 host, pretty
printing a std::any fails with an exception for unknown manager function.
$ gdb ./erased-lambda
GNU gdb (GDB) 8.2
(gdb) run
Starting program: .../erased-lambda
Program received signal SIGILL, Illegal instruction.
main () at erased-lambda.cpp:6
6 __builtin_trap();
(gdb) print a1
$1 = Python Exception Unknown manager
function in std::any:
Python Exception Unknown manager function in
std::any:
{
_M_manager = 0x4007b2
>::_S_manage(std::any::_Op, const std::any *, std::any::_Arg *)>, _M_storage =
{_M_ptr = 0x1, _M_buffer = {__data = "\001\000\000\000\000\000\000",
__align = {
It would appear that the printer attempts to match the manager function name
with the following regex:
rx = r"""({0}::_Manager_\w+<.*>)::_S_manage\({0}::_Op, {0} const\*,
{0}::_Arg\*\)""".format(typename)
Note that the second argument as printed by my gdb is 'const std::any *' versus
the regex 'std::any const*' (east vs west const and space before *) and the
third argument as printed by gdb is 'std::any::_Arg *' versus the regex
'std::any::_Arg*' (space before *). Applying the following patch "fixed" the
regex for my particular set of versions:
--- a/printers.py
+++ b/printers.py
@@ -1040,7 +1040,7 @@ class StdExpAnyPrinter(SingleObjContainerPrinter):
func =
gdb.block_for_pc(int(mgr.cast(gdb.lookup_type('intptr_t'
if not func:
raise ValueError("Invalid function pointer in %s" %
self.typename)
-rx = r"""({0}::_Manager_\w+<.*>)::_S_manage\({0}::_Op, {0}
const\*, {0}::_Arg\*\)""".format(typename)
+rx = r"""({0}::_Manager_\w+<.*>)::_S_manage\({0}::_Op, const
{0} \*, {0}::_Arg \*\)""".format(typename)
m = re.match(rx, func.function.name)
if not m:
raise ValueError("Unknown manager function in %s" %
self.typename)
However, even with that applied, pretty printing a lambda prints the wrong type
due to a bad type lookup:
(gdb) print a1
$1 = std::any containing = {[contained value] = {__j = 1, __k =
0}}
(gdb) print a2
$2 = std::any containing = {[contained value] = {__j = 2, __k =
3}}
Note that both a1 and a2 are interpreted as holding type main::{lambda()#2},
but a1 actually holds main::{lambda()#1}.
GCC version:
$ g++-8.1 -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-8.1.0/bin/g++-8.1
COLLECT_LTO_WRAPPER=/usr/local/gcc-8.1.0/libexec/gcc/x86_64-pc-linux-gnu/8.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-8.1.0/configure --program-suffix=-8.1
--prefix=/usr/local/gcc-8.1.0 --disable-multilib --enable-gold --enable-ld
--enable-lto
Thread model: posix
gcc version 8.1.0 (GCC)
Please let me know if I can provide anything else to help.
== erased-lambda.cpp ==
// g++-8.1 -g -std=c++17 erased-lambda.cpp -o erased-lambda
#include
int main() {
std::any a1 = [i=1] {};
std::any a2 = [j=2,k=3] {};
__builtin_trap();
}
[Bug c/87307] Implicit conversion from int to vector works, explicit is an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87307 --- Comment #2 from Andrew Pinski --- >However when you try to perform explicit conversion, you will gen an error. Right there is another reason why we don't want to support that is because we support bitwise conversion between vector types and integer types of the same size. For an example: uint64_t a; __attribute__((vector_size(sizeof(uint64_t) ) )) uint16_t b = (uint64_t)a;
[Bug c/87307] Implicit conversion from int to vector works, explicit is an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87307 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Andrew Pinski --- This is by design. https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Vector-Extensions.html#Vector-Extensions For convenience, it is allowed to use a binary vector operation where one operand is a scalar. In that case the compiler transforms the scalar operand into a vector where each element is the scalar from the operation. The transformation happens only if the scalar could be safely converted to the vector-element type. --- CUT ---
[Bug c/87307] New: Implicit conversion from int to vector works, explicit is an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87307
Bug ID: 87307
Summary: Implicit conversion from int to vector works, explicit
is an error
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
Vector types defined using __attribute((vector_size(N))) supports implicit
conversion from int to vector type for arithmetic operators. However when you
try to perform explicit conversion, you will gen an error. Please add support
for explicit conversion from int to vector type, it would be handy.
typedef int VInt __attribute((vector_size(32)));
VInt test1(VInt v)
{
return v + 2; // OK
}
VInt test2(VInt v)
{
return v + (VInt)2; // error: can't convert a value of type 'int' to vector
type 'VInt' {aka '__vector(8) int'} which has different size
}
VInt test3(VInt v)
{
VInt v2(2); // error: cannot convert 'int' to 'VInt' {aka '__vector(8)
int'} in initialization
return v + v2;
}
[Bug target/87224] ICE in extract_constrain_insn, at recog.c:2206
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87224 --- Comment #3 from Segher Boessenkool --- Author: segher Date: Fri Sep 14 15:24:47 2018 New Revision: 264316 URL: https://gcc.gnu.org/viewcvs?rev=264316=gcc=rev Log: rs6000: Add another Z to go with Y (PR87224) This is another case where we ICE because Y does not allow reg+reg, we need Z for that. PR target/87224 * config/rs6000/rs6000.md (*mov_hardfloat64): Add Z to the Y alternatives. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md
[Bug target/85628] Make better use of BFI (BFXIL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85628 --- Comment #3 from samtebbs at gcc dot gnu.org --- Author: samtebbs Date: Fri Sep 14 15:16:17 2018 New Revision: 264315 URL: https://gcc.gnu.org/viewcvs?rev=264315=gcc=rev Log: [Aarch64] Added pattern to match zero extended bfxil gcc/ 2018-07-31 Sam Tebbs PR target/85628 * config/aarch64/aarch64.md (*aarch64_bfxilsi_uxtw): Define. gcc/testsuite 2018-07-31 Sam Tebbs PR target/85628 * gcc.target/aarch64/combine_bfxil.c (combine_zero_extended_int, foo6): New functions. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/aarch64/combine_bfxil.c
[Bug testsuite/87306] New: test case gcc.dg/vect/bb-slp-pow-1.c fails with its introduction in r263290
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87306 Bug ID: 87306 Summary: test case gcc.dg/vect/bb-slp-pow-1.c fails with its introduction in r263290 Product: gcc Version: 9.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: --- Saw this on power7 BE targeting power7 testgcc: Tried 263290 testgcc: make -k check-gcc RUNTESTFLAGS=vect.exp=gcc.dg/vect/bb-slp-pow-1.c -- testgcc: 263290 had unexpected test case failures testgcc: results of test run: # of expected passes4 # of unexpected failures2 FAIL: gcc.dg/vect/bb-slp-pow-1.c scan-tree-dump-times slp2 "basic block vectorized" 1 FAIL: gcc.dg/vect/bb-slp-pow-1.c -flto -ffat-lto-objects scan-tree-dump-times slp2 "basic block vectorized" 1 Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/bb-slp-pow-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-slp-details -fno-math-errno -fdisable-tree-sincos -lm -o ./bb-slp-pow-1.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/bb-slp-pow-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-slp-details -fno-math-errno -fdisable-tree-sincos -lm -o ./bb-slp-pow-1.exe cc1: note: disable pass tree-sincos for functions in the range of [0, 4294967295] PASS: gcc.dg/vect/bb-slp-pow-1.c (test for excess errors) Setting LD_LIBRARY_PATH to :/home/seurer/gcc/build/gcc-test/gcc::/home/seurer/gcc/build/gcc-test/gcc:/home/seurer/gcc/build/gcc-test/./gmp/.libs:/home/seurer/gcc/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./isl/.libs:/home/seurer/gcc/build/gcc-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64 Execution timeout is: 300 spawn [open ...] PASS: gcc.dg/vect/bb-slp-pow-1.c execution test gcc.dg/vect/bb-slp-pow-1.c: pattern found 0 times FAIL: gcc.dg/vect/bb-slp-pow-1.c scan-tree-dump-times slp2 "basic block vectorized" 1 Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/bb-slp-pow-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -flto -ffat-lto-objects -maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-slp-details -fno-math-errno -fdisable-tree-sincos -lm -o ./bb-slp-pow-1.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/bb-slp-pow-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -flto -ffat-lto-objects -maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-slp-details -fno-math-errno -fdisable-tree-sincos -lm -o ./bb-slp-pow-1.exe cc1: note: disable pass tree-sincos for functions in the range of [0, 4294967295] lto1: note: disable pass tree-sincos for functions in the range of [0, 4294967295] lto1: note: disable pass tree-sincos for functions in the range of [0, 4294967295] PASS: gcc.dg/vect/bb-slp-pow-1.c -flto -ffat-lto-objects (test for excess errors) Setting LD_LIBRARY_PATH to :/home/seurer/gcc/build/gcc-test/gcc::/home/seurer/gcc/build/gcc-test/gcc:/home/seurer/gcc/build/gcc-test/./gmp/.libs:/home/seurer/gcc/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./isl/.libs:/home/seurer/gcc/build/gcc-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64 Execution timeout is: 300 spawn [open ...] PASS: gcc.dg/vect/bb-slp-pow-1.c -flto -ffat-lto-objects execution test gcc.dg/vect/bb-slp-pow-1.c -flto -ffat-lto-objects : pattern found 0 times FAIL: gcc.dg/vect/bb-slp-pow-1.c -flto -ffat-lto-objects scan-tree-dump-times slp2 "basic block vectorized" 1 testcase /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/vect.exp completed in 10 seconds === gcc Summary === # of expected passes4 # of unexpected failures2
[Bug c++/87300] -Wredundant-move gives false positives in C++11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87300 --- Comment #2 from Steinar H. Gunderson --- Hm, am I misunderstanding it? It said “Status: C++14”. Even so, does it apply to C++11?
[Bug c++/87300] -Wredundant-move gives false positives in C++11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87300 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- It's a DR, so it applies to previous standards too. That's the rule GCC always follows. We do not implement defective standards, we implement the fixes. A pedantic conformance to a specification known to be defective is not useful.
[Bug rtl-optimization/87305] [9 Regression] Segfault in end_hard_regno in setup_live_pseudos_and_spill_after_risky_transforms on aarch64 big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87305 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to work||8.2.1 Version|unknown |9.0 Target Milestone|--- |9.0 Known to fail||9.0
[Bug rtl-optimization/87305] New: [9 Regression] Segfault in end_hard_regno in setup_live_pseudos_and_spill_after_risky_transforms on aarch64 big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87305
Bug ID: 87305
Summary: [9 Regression] Segfault in end_hard_regno in
setup_live_pseudos_and_spill_after_risky_transforms on
aarch64 big-endian
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
Target Milestone: ---
The testcase:
int a;
int b[5];
int fn1() {
short c;
a = 0;
for (; a <= 4; a++) {
c = 3;
for (; c >= 0; c--) {
if (b[c + 1])
break;
--b[c];
}
}
return a;
}
ICEs with -Ofast -mbig-endian on aarch64
test.c:15:1: internal compiler error: Segmentation fault
15 | }
| ^
0xc310b1 crash_signal
$GCC/gcc/toplev.c:325
0xa87998 end_hard_regno
$GCC/gcc/regs.h:266
0xa87998 add_to_hard_reg_set
$GCC/gcc/regs.h:278
0xa87998 setup_live_pseudos_and_spill_after_risky_transforms
$GCC/gcc/lra-assigns.c:1219
0xa87998 lra_assign(bool&)
$GCC/gcc/lra-assigns.c:1617
0xa83da4 lra(_IO_FILE*)
$GCC/gcc/lra.c:2508
0xa3b3d6 do_reload
$GCC/gcc/ira.c:5469
0xa3b3d6 execute
$GCC/gcc/ira.c:5653
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug testsuite/87304] New: [9 regression] gcc.dg/vect/bb-slp-over-widen-1.c fails starting with r262371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87304 Bug ID: 87304 Summary: [9 regression] gcc.dg/vect/bb-slp-over-widen-1.c fails starting with r262371 Product: gcc Version: 9.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: --- Looks like the fix for pr86405 broke things on powerpc64 targeting power 6 and power 7. These were run on a power 7 BE machine: testgcc: Tried 262370 # of expected passes8 -- testgcc: Tried 262371 # of expected passes8 # of unexpected failures2 -- testgcc: make -k check-gcc RUNTESTFLAGS=vect.exp=gcc.dg/vect/bb-slp-over-widen-1.c FAIL: gcc.dg/vect/bb-slp-over-widen-1.c scan-tree-dump-times slp2 "basic block vectorized" 2 FAIL: gcc.dg/vect/bb-slp-over-widen-1.c -flto -ffat-lto-objects scan-tree-dump-times slp2 "basic block vectorized" 2 Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/bb-slp-over-widen-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-slp-details -lm -o ./bb-slp-over-widen-1.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/bb-slp-over-widen-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-slp-details -lm -o ./bb-slp-over-widen-1.exe PASS: gcc.dg/vect/bb-slp-over-widen-1.c (test for excess errors) Setting LD_LIBRARY_PATH to :/home/seurer/gcc/build/gcc-test/gcc::/home/seurer/gcc/build/gcc-test/gcc:/home/seurer/gcc/build/gcc-test/./gmp/.libs:/home/seurer/gcc/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./isl/.libs:/home/seurer/gcc/build/gcc-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64 Execution timeout is: 300 spawn [open ...] PASS: gcc.dg/vect/bb-slp-over-widen-1.c execution test PASS: gcc.dg/vect/bb-slp-over-widen-1.c scan-tree-dump slp2 "demoting int to signed short" PASS: gcc.dg/vect/bb-slp-over-widen-1.c scan-tree-dump slp2 "demoting int to unsigned short" gcc.dg/vect/bb-slp-over-widen-1.c: pattern found 0 times FAIL: gcc.dg/vect/bb-slp-over-widen-1.c scan-tree-dump-times slp2 "basic block vectorized" 2 Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/bb-slp-over-widen-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -flto -ffat-lto-objects -maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-slp-details -lm -o ./bb-slp-over-widen-1.exe (timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/bb-slp-over-widen-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -flto -ffat-lto-objects -maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-slp-details -lm -o ./bb-slp-over-widen-1.exe PASS: gcc.dg/vect/bb-slp-over-widen-1.c -flto -ffat-lto-objects (test for excess errors) Setting LD_LIBRARY_PATH to :/home/seurer/gcc/build/gcc-test/gcc::/home/seurer/gcc/build/gcc-test/gcc:/home/seurer/gcc/build/gcc-test/./gmp/.libs:/home/seurer/gcc/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./isl/.libs:/home/seurer/gcc/build/gcc-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64 Execution timeout is: 300 spawn [open ...] PASS: gcc.dg/vect/bb-slp-over-widen-1.c -flto -ffat-lto-objects execution test PASS: gcc.dg/vect/bb-slp-over-widen-1.c -flto -ffat-lto-objects scan-tree-dump slp2 "demoting int to signed short" PASS: gcc.dg/vect/bb-slp-over-widen-1.c -flto -ffat-lto-objects scan-tree-dump slp2 "demoting int to unsigned short" gcc.dg/vect/bb-slp-over-widen-1.c -flto -ffat-lto-objects : pattern found 0 times FAIL: gcc.dg/vect/bb-slp-over-widen-1.c -flto -ffat-lto-objects scan-tree-dump-times slp2 "basic block vectorized" 2 testcase
[Bug lto/87283] [9 Regression] internal compiler error: in remove, at alloc-pool.h:433
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87283 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from ktkachov at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/87259] [9 Regression] ICE: error: definition in block 3 does not dominate use in block 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87259 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from ktkachov at gcc dot gnu.org --- Fixed.
[Bug lto/87283] [9 Regression] internal compiler error: in remove, at alloc-pool.h:433
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87283 --- Comment #4 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Fri Sep 14 13:13:14 2018 New Revision: 264312 URL: https://gcc.gnu.org/viewcvs?rev=264312=gcc=rev Log: [tree-ssa-mathopts] PR tree-optimization/87259: Call execute_cse_reciprocals_1 before trying optimize_recip_sqrt PR tree-optimization/87259 PR lto/87283 (pass_cse_reciprocals::execute): Run optimize_recip_sqrt after execute_cse_reciprocals_1 has tried transforming. PR tree-optimization/87259 * gcc.dg/pr87259.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr87259.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug tree-optimization/87259] [9 Regression] ICE: error: definition in block 3 does not dominate use in block 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87259 --- Comment #3 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Fri Sep 14 13:13:14 2018 New Revision: 264312 URL: https://gcc.gnu.org/viewcvs?rev=264312=gcc=rev Log: [tree-ssa-mathopts] PR tree-optimization/87259: Call execute_cse_reciprocals_1 before trying optimize_recip_sqrt PR tree-optimization/87259 PR lto/87283 (pass_cse_reciprocals::execute): Run optimize_recip_sqrt after execute_cse_reciprocals_1 has tried transforming. PR tree-optimization/87259 * gcc.dg/pr87259.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr87259.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug tree-optimization/87301] [9 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87301 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-09-14 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug middle-end/87296] [8/9 Regression] -Wstringop-overflow false positive due to bogus MEM_REF type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87296
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.3
--- Comment #2 from Richard Biener ---
(In reply to Martin Sebor from comment #1)
> Confirmed with the simplified C test case below. The warning sees a MEM_REF
> (char[4], ...) as the destination of the strncpy call. Why the type is
> char[4] is a mystery to me. I guess the type in MEM_REF really can't be
> trusted.
>
>
> gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout pr87296.c
>
> ;; Function g (g, funcdef_no=0, decl_uid=1913, cgraph_uid=1, symbol_order=0)
>
> g (struct S * p, const char * s)
> {
> void * _1;
> char[4] * _2;
>
>[local count: 1073741824]:
> _1 = [(void *)p_3(D) + 4B];
> _2 = _3(D)->a;
> f (_2, _1);
> __builtin_strncpy (_1, s_6(D), 6); [tail call]
> return;
>
> }
>
>
> pr87296.c: In function ‘g’:
> pr87296.c:11:3: warning: ‘__builtin_strncpy’ writing 6 bytes into a region
> of size 4 overflows the destination [-Wstringop-overflow=]
> 11 | __builtin_strncpy (p->b, s, sizeof p->b);
>| ^~~~
quite likely because
char[4] * _1;
const char * _2;
...
_1 = _8->ids;
_2 = _1 + 4;
and forwprop combines the address calculation, re-using the type of _1.
For IL consistency if the ADDR_EXPR has type char[4] * then its operand
has to have type char[4]. [that's GENERIC constraints]
/* Technically there is no longer a need for matching types, but
gimple hygiene asks for this check. In LTO we can end up
combining incompatible units and thus end up with addresses
of globals that change their type to a common one. */
if (!in_lto_p
&& !types_compatible_p (TREE_TYPE (op),
TREE_TYPE (TREE_TYPE (rhs1)))
&& !one_pointer_to_useless_type_conversion_p (TREE_TYPE (rhs1),
TREE_TYPE (op)))
{
error ("type mismatch in address expression");
debug_generic_stmt (TREE_TYPE (rhs1));
debug_generic_stmt (TREE_TYPE (op));
return true;
}
other than that - types on addresses are random.
[Bug c/87297] [9 Regression] ICE on strncpy with an undeclared argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87297 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug middle-end/63155] [6/7/8/9 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 --- Comment #23 from Richard Biener --- (In reply to Richard Biener from comment #22) > Created attachment 44692 [details] > patch that does not help > > The attached patch changes the partition view so that members of bases are > adjacent. This should improve the locality of the initial conflict set > bits (we only record conflicts within same base variables). > > This doesn't help memory usage for either testcase. > > For the 2nd testcase we have 187988 partitions and 500 bases. > > The conflict bitmaps still end up very sparse (but large). There are also > a lot of duplicate bitmaps (if you'd add self-conflicts). > > Restricting anonymous coalesces to abnormal coalescing only increases the > number of bases to 747 and doesn't help memory use significantly. So doing this^^^ more conservatively somehow, choosing different bases for different set of final coalesced abnormal partitions, would shrink the size of the largest base significantly, reducing the quadraticness. So perform the abnormal part of coalesce_partitions implicitely, computing sets of coalesced partitions and pre-assigning a base to each of them. The only complication is in rejecting further coalescing to the base members (thus adjusting gimple_can_coalesce_p). > There may be cases where the patch helps since it should improve locality.
[Bug target/87302] -mfpu=auto -march=armv8-a does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87302 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Earnshaw --- (In reply to nsz from comment #0) > i think the following inconsistency is problematic: > > on a hard float toolchain (-mfloat-abi=hard): > > $ arm-none-linux-gnueabihf-gcc -mfpu=auto -march=armv7-a a.c ; echo $? > cc1: error: -mfloat-abi=hard: selected processor lacks an FPU > 1 This is the correct response, you haven't specified the expected floating point/simd extensions in the architecture. > $ arm-none-linux-gnueabihf-gcc -mfpu=auto -march=armv7-a+fp a.c ; echo $? > 0 correct response. > $ arm-none-linux-gnueabihf-gcc -mfpu=auto -march=armv8-a a.c ; echo $? > cc1: error: -mfloat-abi=hard: selected processor lacks an FPU > 1 Correct response, floating point/simd extension not enabled. > $ arm-none-linux-gnueabihf-gcc -mfpu=auto -march=armv8-a+fp a.c ; echo $? > arm-none-linux-gnueabihf-gcc: error: 'armv8-a' does not support feature 'fp' > arm-none-linux-gnueabihf-gcc: note: valid feature names are: crc simd crypto > nocrypto nofp; did you mean 'nofp'? > 1 Correct response. Fp without SIMD is not an option in Arm v8. > $ arm-none-linux-gnueabihf-gcc -mfpu=auto -march=armv8-a+simd a.c ; echo $? > 0 > > so it seems neither armv8-a nor armv8-a+fp work with -mfpu=auto, but > armv8-a+simd and armv7-a+fp do. this is all as it should be. The documentation describes which options are available for which architecture.
[Bug middle-end/63155] [6/7/8/9 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 --- Comment #22 from Richard Biener --- Created attachment 44692 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44692=edit patch that does not help The attached patch changes the partition view so that members of bases are adjacent. This should improve the locality of the initial conflict set bits (we only record conflicts within same base variables). This doesn't help memory usage for either testcase. For the 2nd testcase we have 187988 partitions and 500 bases. The conflict bitmaps still end up very sparse (but large). There are also a lot of duplicate bitmaps (if you'd add self-conflicts). Restricting anonymous coalesces to abnormal coalescing only increases the number of bases to 747 and doesn't help memory use significantly. There may be cases where the patch helps since it should improve locality.
[Bug tree-optimization/87303] DFmode FP constants are not correctly truncated when promoted to XFmode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87303 Uroš Bizjak changed: What|Removed |Added Target||x86 --- Comment #1 from Uroš Bizjak --- Also fails with -O2 -fexcess-precision=standard -mfpmath=387 on 64bit target.
[Bug tree-optimization/87303] New: DFmode FP constants are not correctly truncated when promoted to XFmode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87303
Bug ID: 87303
Summary: DFmode FP constants are not correctly truncated when
promoted to XFmode
Product: gcc
Version: 9.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: ---
I was looking at the following testsuite failure with
-fexcess-precision=standard on 32bit x86 target:
FAIL: gcc.c-torture/execute/ieee/acc1.c execution
--cut here--
double func (const double *array)
{
double d = *array;
if (d == 0.0)
return d;
else
return d + func (array + 1);
}
int main ()
{
double values[] = { 0.1e-100, 1.0, -1.0, 0.0 };
if (func (values) != 0.1e-100)
abort ();
exit (0);
}
--cut here--
gcc -O2 -fexcess-precision=standard -m32 creates following optimized tree dump:
--cut here--
[local count: 1073741824]:
values[0] = 1.5171617276904849891057306773641595375548e-101;
values[1] = 1.0e+0;
values[2] = -1.0e+0;
values[3] = 0.0;
_9 = func ([(void *) + 8B]);
_10 = (long double) _9;
_11 = _10 + 1.5171617276904849891057306773641595375548e-101;
_12 = (double) _11;
_1 = (long double) _12;
if (_1 != 9.997834478666160678572417847571029307194e-102)
goto ; [0.00%]
else
goto ; [99.96%]
[count: 0]:
abort ();
[local count: 1073312328]:
exit (0);
--cut here--
Please note that the last compare is with XFmode constant that is not correctly
truncated to DFmode. The comparison in extended to XFmode (due to
-fexcess-precision=standard option), but the constant is not truncated to
DFmode value, even if it is alter loaded via XFmode load instruction.
(gdb) disass
Dump of assembler code for function main:
0x08048350 <+0>: lea0x4(%esp),%ecx
...
0x08048384 <+52>:call 0x80484e0
0x08048389 <+57>:faddl 0x80485c0
0x0804838f <+63>:add$0x10,%esp
0x08048392 <+66>:fstpl -0x30(%ebp)
0x08048395 <+69>:fldt 0x80485d0
0x0804839b <+75>:fldl -0x30(%ebp)
=> 0x0804839e <+78>:fucompp
0x080483a0 <+80>:fnstsw %ax
0x080483a2 <+82>:sahf
0x080483a3 <+83>:jp 0x80483b1
0x080483a5 <+85>:jne0x80483b1
0x080483a7 <+87>:sub$0xc,%esp
0x080483aa <+90>:push $0x0
0x080483ac <+92>:call 0x8048320
0x080483b1 <+97>:call 0x8048340
End of assembler dump.
(gdb) i r flo
st01.5172e-101 (raw 0x3eafb32df8e9f3546800)
st19.9978e-102 (raw 0x3eafb32df8e9f3546564)
st20(raw 0x)
st30(raw 0x)
st40(raw 0x)
st50(raw 0x)
st60(raw 0x)
st70(raw 0x)
[Bug middle-end/87298] [9 Regression] FAIL: gcc.c-torture/execute/pr87053.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87298 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #1 from H.J. Lu --- r264301 works now.
[Bug target/87302] New: -mfpu=auto -march=armv8-a does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87302 Bug ID: 87302 Summary: -mfpu=auto -march=armv8-a does not work Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: nsz at gcc dot gnu.org Target Milestone: --- i think the following inconsistency is problematic: on a hard float toolchain (-mfloat-abi=hard): $ arm-none-linux-gnueabihf-gcc -mfpu=auto -march=armv7-a a.c ; echo $? cc1: error: -mfloat-abi=hard: selected processor lacks an FPU 1 $ arm-none-linux-gnueabihf-gcc -mfpu=auto -march=armv7-a+fp a.c ; echo $? 0 $ arm-none-linux-gnueabihf-gcc -mfpu=auto -march=armv8-a a.c ; echo $? cc1: error: -mfloat-abi=hard: selected processor lacks an FPU 1 $ arm-none-linux-gnueabihf-gcc -mfpu=auto -march=armv8-a+fp a.c ; echo $? arm-none-linux-gnueabihf-gcc: error: 'armv8-a' does not support feature 'fp' arm-none-linux-gnueabihf-gcc: note: valid feature names are: crc simd crypto nocrypto nofp; did you mean 'nofp'? 1 $ arm-none-linux-gnueabihf-gcc -mfpu=auto -march=armv8-a+simd a.c ; echo $? 0 so it seems neither armv8-a nor armv8-a+fp work with -mfpu=auto, but armv8-a+simd and armv7-a+fp do.
[Bug c++/83428] Static initialization and struct with constexpr ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83428 --- Comment #6 from Wolfgang Roehrl --- Hi Jonathan, I would like to draw your attention to my new comment on your answer to my bug report. Thank you, W. Roehrl (In reply to Jonathan Wakely from comment #4) > (In reply to Aliaksei Kandratsenka from comment #3) > > constructor is defined after variable in this example. I am not sure this > > real bug. > > Agreed. If we use Clang and add its require_constant_initialization > attribute to the variable definition it tells us: > > 83428.cc:20:54: error: variable does not have a constant initializer > __attribute__((require_constant_initialization)) S2 objX; > ^~~~ > 83428.cc:20:17: note: required by 'require_constant_initialization' > attribute here > __attribute__((require_constant_initialization)) S2 objX; > ^~~ > 83428.cc:12:7: note: undefined constructor 'S1' cannot be used in a constant > expression > : m_tabS1() > ^ > 83428.cc:20:54: note: in call to 'S2()' > __attribute__((require_constant_initialization)) S2 objX; > ^ > 83428.cc:3:15: note: declared here > constexpr S1 (); > ^ > 1 error generated. > > > If the S1::S1() constructor is defined before the definition of objX then > Clang doesn't warn and GCC doesn't use dynamic initialization.
[Bug tree-optimization/87301] New: [9 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87301
Bug ID: 87301
Summary: [9 Regression] ICE: verify_gimple failed (error:
statement marked for throw, but doesn't)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-9.0.0-alpha20180909 snapshot (r264185) ICEs when compiling the following
snippet w/ -O2 (-O3, -Ofast, -Os) -fexceptions -fnon-call-exceptions
-fno-tree-vrp:
void
bl (int *be)
{
int lo;
{
int **ny;
if (*be == 0)
{
int ***k8 =
int uj =
for (;;)
if (***k8 == 0)
{
uj = !!(1 / 0) ? !(lo = 0) : 0;
(void) uj;
if (*ny == 0)
for (;;)
if (***k8 == 0)
{
}
for (lo = 0; lo < 2; ++lo)
{
}
}
}
}
}
% gcc-9.0.0-alpha20180909 -O2 -fexceptions -fnon-call-exceptions -fno-tree-vrp
-w -c cuhhf6tv.c
cuhhf6tv.c: In function 'bl':
cuhhf6tv.c:2:1: error: statement marked for throw, but doesn't
2 | bl (int *be)
| ^~
_13 = _9;
during GIMPLE pass: cunrolli
cuhhf6tv.c:2:1: internal compiler error: verify_gimple failed
0xcff91d verify_gimple_in_cfg(function*, bool)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180909/work/gcc-9-20180909/gcc/tree-cfg.c:5422
0xbd715f execute_function_todo
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180909/work/gcc-9-20180909/gcc/passes.c:1943
0xbd804e execute_todo
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180909/work/gcc-9-20180909/gcc/passes.c:1997
[Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165 --- Comment #18 from Vincent Lefèvre --- OK, but then, this means that the first sentence of the -Wmaybe-uninitialized documentation is incorrect. That's probably the "there exists" that is problematic, because of the possible difference of what actually exists and what the compiler sees.
[Bug middle-end/86864] [9 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2025 since r261795
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86864 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou --- Fixing.
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #11 from Francois-Xavier Coudert ---
(In reply to Jeremy Huddleston Sequoia from comment #10)
> Given those, gcc only builds if we have the DevSDK ("headers at /" package)
> installed.
I may be misunderstanding what you say: GCC builds and runs fine without the
headers in /usr/include. At Homebrew, we are not recommending users to install
the /usr/include headers package, and we build and run GCC fine. The
configuration is the following
(https://github.com/Homebrew/homebrew-core/blob/master/Formula/gcc.rb):
--with-native-system-header-dir=/usr/include
--with-sysroot=/path/to/sdk
if the system headers are in /path/to/sdk/usr/include. Thus, on a Mojave
installation with Xcode CLT installed, we set /path/to/sdk to
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
[Bug other/79885] --with-build-sysroot= does not get honored throughout the build (fix-includes, CPP, CXXCPP, configure-stage2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
--- Comment #9 from Jeremy Huddleston Sequoia ---
Because of this issue, gcc only builds if we have the DevSDK ("headers at /"
package) installed. That package is being provided as a workaround for any
projects that fail to build without it (and note that GCC is the only project
we are aware of that falls into this category). In some future macOS version,
it will cease to be provided. I strongly encourage you to address this issue
as soon as possible to ensure that GCC continues to build with future versions.
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #10 from Jeremy Huddleston Sequoia
---
FWIW, I don't have much power other than nagging to move along the OSS drops.
Those are managed by a process, and prioritization is given to those making
explicit requests to the OSS mailing list. *PLEASE* email opensou...@apple.com
directly (and feel free to CC me).
I agree with pretty much all Iain has said here. There's nothing that should
be different about how gcc treats i386 on darwin vs how it treats i386 on
linux.
Note that for us, the far bigger concerns are the broken --with-build-sysroot
support:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80203
Given those, gcc only builds if we have the DevSDK ("headers at /" package)
installed. That package is being provided as a workaround for any projects
that fail to build without it (and note that GCC is the only project we are
aware of that falls into this category). In some future macOS version, it will
cease to be provided. I strongly encourage you to address those issues as soon
as possible to ensure that GCC continues to build with future versions.
[Bug c++/87300] New: -Wredundant-move gives false positives in C++11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87300
Bug ID: 87300
Summary: -Wredundant-move gives false positives in C++11 mode
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: steinar+gcc at gunderson dot no
Target Milestone: ---
Hi,
-Wredundant-move sometimes gives false positives in C++11 mode -- the std::move
calls are simply not redundant. Case in point:
atum17:~> cat test.cc
#include
#include
class B {};
class D : public B {};
std::unique_ptr foo() {
std::unique_ptr d;
return std::move(d);
}
atum17:~> /usr/lib/gcc-snapshot/bin/g++ -std=c++11 -Wall -Wextra -c test.cc
test.cc: In function 'std::unique_ptr foo()':
test.cc:9:19: warning: redundant move in return statement [-Wredundant-move]
9 | return std::move(d);
| ~^~~
test.cc:9:19: note: remove 'std::move' call
If you follow the warning and remove the std::move() call, GCC will still allow
the program, but that's an extension; it's malformed in C++11, and Solaris
Developer Studio rejects it. The rule that returns of NRVO-capable objects
should look for overloads as if the return value were an rvalue went into
effect only in C++14, from what I can see (DR1579,
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579).
gcc version 9.0.0 20180908 (experimental) [trunk revision 264170] (Debian
20180908-1)
