[Bug target/98495] New: X86 _mm_extract_pi16 incorrectly sign extends result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98495
Bug ID: 98495
Summary: X86 _mm_extract_pi16 incorrectly sign extends result
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: foom at fuhm dot net
Target Milestone: ---
#include
int test(__m64 a) {
return _mm_extract_pi16 (a, 0);
}
Compiles to (x86_64 gcc, -O2):
pextrw $0, %xmm0, %eax
cwtl
ret
Which results in the value being sign-extended from 16-bits to 32-bits.
The intel docs for PEXTRW state that the upper bits are zeroed, and state that
_mm_extract_pi16 is supposed to implement PEXTRW.
So, the expected result is no sign extension:
pextrw $0, %xmm0, %eax
ret
I'd note that this is not a regression due to the new MMX with SSE2 changes --
GCC has had this bug as far back as I can see. It is currently present on trunk
both for the MMX and SSE2 implementations.
Both clang and MSVC zero-extend rather than sign-extend. And, for that matter,
GCC's _mm_extract_epi16 function _also_ zero-extends -- it was fixed in PR45336
for GCC 4.6.
[Bug d/98494] New: libphobos: std.process Config.stderrPassThrough missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98494
Bug ID: 98494
Summary: libphobos: std.process Config.stderrPassThrough
missing
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: witold.baryluk+gcc at gmail dot com
Target Milestone: ---
It appears that gdc version of libphobos is somehow lagging in some aspects
behind upstream.
One of the things I see missing, is `Config.stderrPassThrough` in std.process.
I see it was added upstream about 12 months ago:
enum Config {
...
/**
By default, the $(LREF execute) and $(LREF executeShell) functions
will capture child processes' both stdout and stderr. This can be
undesirable if the standard output is to be processed or otherwise
used by the invoking program, as `execute`'s result would then
contain a mix of output and warning/error messages.
Specify this flag when calling `execute` or `executeShell` to
cause invoked processes' stderr stream to be sent to $(REF stderr,
std,stdio), and only capture and return standard output.
This flag has no effect on $(LREF spawnProcess) or $(LREF spawnShell).
*/
stderrPassThrough = 128,
}
The implementation usage of this is relatively small and easy to backport:
in executeImpl:
-auto p = pipeFunc(commandLine, Redirect.stdout | Redirect.stderrToStdout,
- env, config, workDir, extraArgs);
+auto redirect = (config & Config.stderrPassThrough)
+? Redirect.stdout
+: Redirect.stdout | Redirect.stderrToStdout;
+
+auto p = pipeFunc(commandLine, redirect,
+ env, config, workDir, extraArgs);
There are some other minor changes there, but nothing functionally significant.
Mostly unittests and minor signature changes (adding `scope` to many input
parameters).
Thank you.
[Bug tree-optimization/98474] [8/9/10 Regression] incorrect results using __uint128_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98474 --- Comment #7 from Jeff Hurchalla --- Thanks for the info. After reading your comment and after reading the description of wide_int at the top of wide-int.h, the newly patched function wi::to_mpz() makes sense to me and it looks correct. I'm curious though why the particular constant from the original test case (_uint128_t a = ((__uint128_t) 1) << 65;) would have caused any trouble for wi::to_mpz prior to patching. My understanding of wide_int is that this particular constant in wide_int representation would not be sign-extended/compressed - i.e. len times HOST_BITS_PER_WIDE_INT would be greater than precision for this constant. During this test case, does niter analysis receive some other wide_int that was being incorrectly converted to mpz? It's not that important I expect, but it's all that's unclear to me.
[Bug bootstrap/98493] New: [11 regression] bootstrap build fails in go part of build after r11-6371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98493 Bug ID: 98493 Summary: [11 regression] bootstrap build fails in go part of build after r11-6371 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:cfcbb4227fb20191e04eb8d7766ae6202f526afd, r11-6371 make[4]: Entering directory '/home/gccbuild/build-gcc-trunk/powerpc64le-unknown-linux-gnu/libgo' /bin/mkdir -p internal; files=`echo /home/gccbuild/gcc_trunk_git/gcc/libgo/go/internal/cpu/cpu.go /home/gccbuild/gcc_trunk_git/gcc/libgo/go/internal/cpu/cpu_no_name.go /home/gccbuild/gcc_trunk_git/gcc/libgo/go/internal/cpu/cpu_ppc64x_linux.go /home/gccbuild/gcc_trunk_git/gcc/libgo/go/internal/cpu/cpu_ppcx.go cpugen.go | sed -e 's/[^ ]*\.gox//g' -e 's/[^ ]*\.dep//'`; /bin/sh ./libtool --tag GO --mode=compile /home/gccbuild/build-gcc-trunk/./gcc/gccgo -B/home/gccbuild/build-gcc-trunk/./gcc/ -B/opt/gcc-nightly/trunk/powerpc64le-unknown-linux-gnu/bin/ -B/opt/gcc-nightly/trunk/powerpc64le-unknown-linux-gnu/lib/ -isystem /opt/gcc-nightly/trunk/powerpc64le-unknown-linux-gnu/include -isystem /opt/gcc-nightly/trunk/powerpc64le-unknown-linux-gnu/sys-include -fchecking=1 -O2 -g -I . -c -fgo-pkgpath=`echo internal/cpu.lo | sed -e 's/.lo$//'` -o internal/cpu.lo $files libtool: compile: /home/gccbuild/build-gcc-trunk/./gcc/gccgo -B/home/gccbuild/build-gcc-trunk/./gcc/ -B/opt/gcc-nightly/trunk/powerpc64le-unknown-linux-gnu/bin/ -B/opt/gcc-nightly/trunk/powerpc64le-unknown-linux-gnu/lib/ -isystem /opt/gcc-nightly/trunk/powerpc64le-unknown-linux-gnu/include -isystem /opt/gcc-nightly/trunk/powerpc64le-unknown-linux-gnu/sys-include -fchecking=1 -O2 -g -I . -c -fgo-pkgpath=internal/cpu /home/gccbuild/gcc_trunk_git/gcc/libgo/go/internal/cpu/cpu.go /home/gccbuild/gcc_trunk_git/gcc/libgo/go/internal/cpu/cpu_no_name.go /home/gccbuild/gcc_trunk_git/gcc/libgo/go/internal/cpu/cpu_ppc64x_linux.go /home/gccbuild/gcc_trunk_git/gcc/libgo/go/internal/cpu/cpu_ppcx.go cpugen.go -fPIC -o internal/.libs/cpu.o /home/gccbuild/gcc_trunk_git/gcc/libgo/go/internal/cpu/cpu_ppcx.go:13:5: error: redefinition of ‘HWCap’ 13 | var HWCap uint | ^ /home/gccbuild/gcc_trunk_git/gcc/libgo/go/internal/cpu/cpu_ppc64x_linux.go:12:5: note: previous definition of ‘HWCap’ was here 12 | var HWCap uint | ^ /home/gccbuild/gcc_trunk_git/gcc/libgo/go/internal/cpu/cpu_ppcx.go:14:5: error: redefinition of ‘HWCap2’ 14 | var HWCap2 uint | ^ /home/gccbuild/gcc_trunk_git/gcc/libgo/go/internal/cpu/cpu_ppc64x_linux.go:13:5: note: previous definition of ‘HWCap2’ was here 13 | var HWCap2 uint | ^ make[4]: *** [Makefile:2962: internal/cpu.lo] Error 1 commit cfcbb4227fb20191e04eb8d7766ae6202f526afd (HEAD) Author: Ian Lance Taylor Date: Wed Dec 23 09:57:37 2020 -0800 libgo: update to Go1.16beta1 release This does not yet include support for the //go:embed directive added in this release. * Makefile.am (check-runtime): Don't create check-runtime-dir. (mostlyclean-local): Don't remove check-runtime-dir. (check-go-tool, check-vet): Copy in go.mod and modules.txt. (check-cgo-test, check-carchive-test): Add go.mod file. * Makefile.in: Regenerate. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/280172
[Bug target/98438] Rather bad optimization of midpoint implementation for __int128 (and other types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98438 --- Comment #5 from Gabriel Ravier --- If you're wondering, the `using x = y;` syntax is roughly equivalent to `typedef y x;`, and the code just expects _Up to be the unsigned counterpart of _Tp, but here are the details as demanded by https://gcc.gnu.org/bugs/#need (sorry if the preprocessed file is a bit large, I usually use a template for examining GCC bugs): Exact version of GCC: gcc version 11.0.0 20201230 (experimental) (Compiler-Explorer-Build) System type: Assuming that's the target, x86_64-linux-gnu Options given when GCC was configured/built: ../gcc-trunk-20201231/configure --prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap --enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran,ada,d --enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix --with-pkgversion=Compiler-Explorer-Build Complete command line that triggers the bug: g++ -g -o /tmp/compiler-explorer-compiler202101-4546-1y1nk07.gl18/output.s -masm=intel -S -fdiagnostics-color=always -O3 -std=gnu++2a -DNDEBUG -g0 /tmp/compiler-explorer-compiler202101-4546-1y1nk07.gl18/example.cpp Compiler output (error messages, warnings, etc.): (nothing) Preprocessed file (*.i*) that triggers the bug: Would have been sent as an attachment to this message but was accidentally previously sent as an attachment to a blank message, so you can find it there.
[Bug target/98438] Rather bad optimization of midpoint implementation for __int128 (and other types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98438 --- Comment #4 from Gabriel Ravier --- Created attachment 49865 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49865=edit Pre-processed source of a file reproducing the bug
[Bug target/98491] [MIPS] ICE: in mode_size_inline, with -mmsa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98491 --- Comment #2 from Xi Ruoyao --- Patch proposed: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562629.html
[Bug c++/98492] New: C++ pp_gimple_stmt_1 doesn't output function call arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98492 Bug ID: 98492 Summary: C++ pp_gimple_stmt_1 doesn't output function call arguments Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- When called for a call statement in a C program, the pp_gimple_stmt_1() function outputs the full call statement, including its arguments (and the variable to which the result is assigned). But when called for a call statement in the same program compiled as C++, the pp_gimple_stmt_1() function only outputs the name of the called function. I tracked this down to the C++ front end reinitializing the pretty-printer (by calling reinit_cxx_pp()) from lang_decl_name(), which ends up called from lang_hooks.decl_printable_name(). The following is the sequence of calls: print_call_name () in tree-pretty-print.c +- calls -> dump_function_name() +-> pp_string (pp, lang_hooks.decl_printable_name (node, 1)) C++ lang_hooks.decl_printable_name () points to cxx_printable_name() in cp/tree.c +- calls -> cxx_printable_name_internal() +-> lang_decl_name() +-> reinit_cxx_pp() (This is a problem when the pretty printer is used to format diagnostics.)
[Bug middle-end/56719] missed optimization: i > 0xffff || i*4 > 0xffff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56719 --- Comment #11 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3ab7a91f36c898b9da665e5e36318a1d9ff12946 commit r11-6382-g3ab7a91f36c898b9da665e5e36318a1d9ff12946 Author: Jakub Jelinek Date: Fri Jan 1 00:03:35 2021 +0100 testsuite: Fix up pr56719.c testcase [PR98489] On some targets, there are no < 8191; and >= 8191; strings, but < 8191) and >= 8191), so just remove the ; from the regexps. 2021-01-01 Jakub Jelinek PR testsuite/98489 PR tree-optimization/56719 * gcc.dg/tree-ssa/pr56719.c: Remove semicolon from scan-tree-dump-times regexps.
[Bug testsuite/98489] New test case gcc.dg/tree-ssa/pr56719.c in r11-6374 has two failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98489 --- Comment #1 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3ab7a91f36c898b9da665e5e36318a1d9ff12946 commit r11-6382-g3ab7a91f36c898b9da665e5e36318a1d9ff12946 Author: Jakub Jelinek Date: Fri Jan 1 00:03:35 2021 +0100 testsuite: Fix up pr56719.c testcase [PR98489] On some targets, there are no < 8191; and >= 8191; strings, but < 8191) and >= 8191), so just remove the ; from the regexps. 2021-01-01 Jakub Jelinek PR testsuite/98489 PR tree-optimization/56719 * gcc.dg/tree-ssa/pr56719.c: Remove semicolon from scan-tree-dump-times regexps.
[Bug target/98491] [MIPS] ICE: in mode_size_inline, with -mmsa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98491
--- Comment #1 from Xi Ruoyao ---
It can be reproduced with a cross build on x86_64-linux, with asan:
$ ../gcc/configure --target=mips64el-unknown-linux-gnuabi64 --with-abi=64
--enable-languages=c,c++ --with-system-zlib
(build log skipped)
$ ASAN_OPTIONS=detect_leaks=0:use_odr_indicator=1 make all-gcc
{C,CXX,LD}FLAGS="-O0 -g3 -ggdb -fsanitize=address -static-libasan" -j 4
(build log skipped)
$ gcc/cc1 ~/bug.c -nostdinc -mmsa
f
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> {heap 0 } {heap 0 } {heap 0
} {heap 0 } {heap 0 } {heap 0
} {heap 0 }Streaming LTO
{heap 0 } {heap 0 } {heap 0 }
{heap 0 } {heap 0 } {heap 0 } {heap 0
}Assembling functions:
f=
==257274==ERROR: AddressSanitizer: global-buffer-overflow on address
0x0521e70a at pc 0x02c535c1 bp 0x7ffc1ac50930 sp 0x7ffc1ac50928
READ of size 2 at 0x0521e70a thread T0
#0 0x2c535c0 in mode_to_bytes(machine_mode) ../../gcc/gcc/machmode.h:550
#1 0x2c535c0 in mips_symbol_insns ../../gcc/gcc/config/mips/mips.c:2384
#2 0x2c591fc in mips_const_insns(rtx_def*)
../../gcc/gcc/config/mips/mips.c:2895
(more asan output skipped)
[Bug target/98491] New: [MIPS] ICE: in mode_size_inline, with -mmsa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98491
Bug ID: 98491
Summary: [MIPS] ICE: in mode_size_inline, with -mmsa
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: xry111 at mengyan1223 dot wang
Target Milestone: ---
I'm building a system with Linux From Scratch approach on a Loongson-3A4000
(mips64el, with MSA support). I tried to build GCC-10.2.0 but it crashes
building other packages, with `-mmsa`.
I investigated a little and it shown a simple program could trigger the ICE:
$ cat bug.c
void foo()
{
double x = 1.0;
}
$ cc bug.c -c
bug.c:3:10: internal compiler error: in mode_size_inline, at
./insn-modes-inline.h:18
The problem is pinpointed at gcc/config/mips/mips.c line 2895:
return mips_symbol_insns (symbol_type, MAX_MACHINE_MODE);
In mips_symbol_insns:
if (MSA_SUPPORTED_MODE_P (mode))
return 0;
MSA_SUPPORTED_MODE_P is defined as:
#define MSA_SUPPORTED_MODE_P(MODE) \
(ISA_HAS_MSA \
&& GET_MODE_SIZE (MODE) == UNITS_PER_MSA_REG \
&& (GET_MODE_CLASS (MODE) == MODE_VECTOR_INT \
|| GET_MODE_CLASS (MODE) == MODE_VECTOR_FLOAT))
When -mmsa is used, ISA_HAS_MSA is expanded to `true`. And GET_MODE_SIZE is
expanded to a call to mode_to_bytes, which is defined:
ALWAYS_INLINE poly_uint16
mode_to_bytes (machine_mode mode)
{
#if GCC_VERSION >= 4001
return (__builtin_constant_p (mode)
? mode_size_inline (mode) : mode_size[mode]);
#else
return mode_size[mode];
#endif
}
Here `mode` is MAX_MACHINE_MODE, which equals to NUM_MACHINE_MODES, the size of
array `mode_size`. And, there is an assertion in mode_size_inline:
gcc_assert (mode >= 0 && mode < NUM_MACHINE_MODES);
So, if __builtin_constant_p is evaluated `true`, the assertion will be
triggered. Otherwise, we have an out-of-bound array access. Anyway it is
wrong.
[Bug fortran/93794] [8/9/10/11 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2497
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93794 --- Comment #5 from anlauf at gcc dot gnu.org --- > Paul, > > are you still working on this? Paul, this is still one of yours...
[Bug fortran/96381] gfc_find_vtab can use a character type typespec as a derived type (causing invalid access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96381 --- Comment #2 from anlauf at gcc dot gnu.org --- The following patch fixes the invalid read: diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c index 5677d920239..783e4c7354b 100644 --- a/gcc/fortran/class.c +++ b/gcc/fortran/class.c @@ -2906,7 +2906,9 @@ gfc_find_vtab (gfc_typespec *ts) case BT_DERIVED: return gfc_find_derived_vtab (ts->u.derived); case BT_CLASS: - if (ts->u.derived->components && ts->u.derived->components->ts.u.derived) + if (ts->u.derived->attr.is_class + && ts->u.derived->components + && ts->u.derived->components->ts.u.derived) return gfc_find_derived_vtab (ts->u.derived->components->ts.u.derived); else return NULL; Not regtested yet.
[Bug fortran/96418] Test coarray_alloc_comp_4.f08 ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96418 --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Andre Vehreschild from comment #5) > Patch submitted as: > https://gcc.gnu.org/pipermail/fortran/2020-August/054943.html > Waiting for review. Hi Andre, any progress here? To me, the patch looks fairly simple / simple enough so that you could apply it if it still solves the issue. Or ping on the ML.
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|WAITING |NEW
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #3 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 1050250)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -2374,7 +2374,8 @@ gfc_conv_substring (gfc_se * se, gfc_ref * ref, int ki
if (!CONSTANT_CLASS_P (tmp) && !DECL_P (tmp))
end.expr = gfc_evaluate_now (end.expr, >pre);
- if (gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
+ if ((gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
+ && !ref->u.ss.start->symtree->n.sym->attr.implied_index)
{
tree nonempty = fold_build2_loc (input_location, LE_EXPR,
logical_type_node, start.expr,
[Bug target/98438] Rather bad optimization of midpoint implementation for __int128 (and other types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98438 --- Comment #3 from Thomas Koenig --- Could you simply post the complete C++ source code that you used in the original example? This has the advantages of a) making it easier to modify (for a non-C++-person such as me) and b) of conforming to the gcc bug reporting guidelines at https://gcc.gnu.org/bugs/#need . Thanks!
[Bug c++/98441] [11 Regression] member function pointer incorrectly parsed as having trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98441 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Priority|P3 |P1 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #7 from Marek Polacek --- Mine.
[Bug c++/97745] [10 Regression] ICE in tsubst_decl, at cp/pt.c:14666
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97745 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Marek Polacek --- Fixed thus.
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490 --- Comment #2 from Fran Martinez Fadrique --- I am not sure to understand the question The gfortran version is gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) It also appear with gcc version 11.0.0 20201220 (experimental) (GCC) also in Ubuntu In case it was not clear in my initial statement, it only appears when the flag -fbound-check is used. Otherwise the behaviour seems fine.
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2020-12-31 --- Comment #1 from Dominique d'Humieres --- WORKSFORME fron 7 up to 11. Which revision are you using?
[Bug fortran/98490] New: Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490 Bug ID: 98490 Summary: Unexpected out of bounds in array constructor with implied do loop Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ffadrique at gmail dot com Target Milestone: --- The followinng code, when compiled with -fbounds-check produces a runtime exception program test implicit none call sub( 'Lorem ipsum' ) contains subroutine sub( text ) character(len=*), intent(in) :: text integer :: i write(*,*) [ ( text(i:i), i = 1, len(text) ) ] end subroutine sub end program test Run time error: At line 18 of file test.f90 Fortran runtime error: Substring out of bounds: lower bound (-2147483648) of 'text' is less than one Error termination. Backtrace: #0 0x7f01d0965d3a #1 0x7f01d0966849 #2 0x7f01d0966ec6 #3 0x5567acbd1269 #4 0x5567acbd14e6 #5 0x5567acbd151e #6 0x7f01d077a0b2 #7 0x5567acbd10fd #8 0x It is clear to me that the automatic variable i is not initialised before invoking the implied do loop. However, the loop should run between 1 and the length of the input text as given in the loop controls; not evaluate at the uninitialised value. The behaviour is as expected when not compiled with the bound check flag. Also valgrind is not reporting any invalid memory access. The issue may be associated to the compilation with the bound check flag (that I need to have enabled in general). The workaround is straightforward. I have also checked that if there were several statements like the write one in the example, I would have to control the initial value of i before each implied loop to make sure that the initial value is not out of the array in the loop. i = 1 ! Prevents the exception write(*,*) [ ( text1(i:i), i = 1, len(text1) ) ] ! text1 of length 20 ! Next statement triggers the exception unless i is reset again write(*,*) [ ( text2(i:i), i = 1, len(text2) ) ] ! text2 of length 10
[Bug target/98438] Rather bad optimization of midpoint implementation for __int128 (and other types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98438
--- Comment #2 from Gabriel Ravier ---
Directly based off the emitted GIMPLE, here's a self-contained example that
emits the same assembly I was observing before :
using _Tp = int;
using _Up = unsigned;
_Tp f(_Tp __a, _Tp __b)
{
_Up __sign_bit_12;
_Up __diff_11;
unsigned int __b_0_1;
unsigned int __a_1_2;
bool _3;
unsigned int _4;
unsigned int _5;
unsigned int _7;
unsigned int _8;
unsigned int _13;
_Tp _14;
unsigned int _17;
__b_0_1 = (unsigned int) __b;
__a_1_2 = (unsigned int) __a;
__diff_11 = __b_0_1 - __a_1_2;
_3 = __b < __a;
__sign_bit_12 = (_Up) _3;
_4 = __diff_11 >> 1;
_5 = __sign_bit_12 << 31;
_13 = _4 + _5;
_7 = __diff_11 & __sign_bit_12;
_17 = __a_1_2 + _7;
_8 = _13 + _17;
_14 = (_Tp) _8;
return _14;
}
[Bug fortran/88624] [Coarray] Rejects allocatable coarray passed as a dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88624 Thomas Koenig changed: What|Removed |Added Keywords|rejects-valid |ice-on-valid-code CC||tkoenig at gcc dot gnu.org --- Comment #3 from Thomas Koenig --- At least something that works on the shared coarray branch :-)
[Bug target/98438] Rather bad optimization of midpoint implementation for __int128 (and other types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98438 Thomas Koenig changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2020-12-31 --- Comment #1 from Thomas Koenig --- Could you make this into a self-contained example that compiles cleanly?
[Bug testsuite/98489] New: New test case gcc.dg/tree-ssa/pr56719.c in r11-6374 has two failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98489 Bug ID: 98489 Summary: New test case gcc.dg/tree-ssa/pr56719.c in r11-6374 has two failures Product: gcc Version: 11.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: --- g:d96b8556e569a1ccce36ef990e167031d07a661a, r11-6374 make -k check-gcc RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/pr56719.c" FAIL: gcc.dg/tree-ssa/pr56719.c scan-tree-dump-times optimized " > 8191;" 1 FAIL: gcc.dg/tree-ssa/pr56719.c scan-tree-dump-times optimized " <= 8191;" 1 # of expected passes5 # of unexpected failures2
[Bug target/98302] [?? Regression] Wrong code on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98302 rsandifo at gcc dot gnu.org changed: What|Removed |Added Summary|[11 Regression] Wrong code |[?? Regression] Wrong code |on aarch64 |on aarch64 --- Comment #14 from rsandifo at gcc dot gnu.org --- FIxed on trunk so far. The code goes back to GCC 9 and the patch seems safe, so keeping open for now to see whether we should backport.
[Bug middle-end/94994] [10 Regression] possible miscompilation of word-at-a-time copy via packed structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94994 rsandifo at gcc dot gnu.org changed: What|Removed |Added Summary|[10/11 Regression] possible |[10 Regression] possible |miscompilation of |miscompilation of |word-at-a-time copy via |word-at-a-time copy via |packed structs |packed structs --- Comment #6 from rsandifo at gcc dot gnu.org --- Fixed on trunk so far, will backport in a week or so.
[Bug target/98302] [11 Regression] Wrong code on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98302 --- Comment #13 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:58a12b0eadac62e691fcf7325ab2bc2c93d46b61 commit r11-6381-g58a12b0eadac62e691fcf7325ab2bc2c93d46b61 Author: Richard Sandiford Date: Thu Dec 31 16:51:34 2020 + vect: Avoid generating out-of-range shifts [PR98302] In this testcase we end up with: unsigned long long x = ...; char y = (char) (x << 37); The overwidening pattern realised that only the low 8 bits of x << 37 are needed, but then tried to turn that into: unsigned long long x = ...; char y = (char) x << 37; which gives an out-of-range shift. In this case y can simply be replaced by zero, but as the comment in the patch says, it's kind-of awkward to do that in the middle of vectorisation. Most of the overwidening stuff is about keeping operations as narrow as possible, which is important for vectorisation but could be counter-productive for scalars (especially on RISC targets). In contrast, optimising y to zero in the above feels like an independent optimisation that would benefit scalar code and that should happen before vectorisation. gcc/ PR tree-optimization/98302 * tree-vect-patterns.c (vect_determine_precisions_from_users): Make sure that the precision remains greater than the shift count. gcc/testsuite/ PR tree-optimization/98302 * gcc.dg/vect/pr98302.c: New test.
[Bug middle-end/94994] [10/11 Regression] possible miscompilation of word-at-a-time copy via packed structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94994 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:9fa5b473b5b8e289b6542adfd5cfaddfb3036048 commit r11-6380-g9fa5b473b5b8e289b6542adfd5cfaddfb3036048 Author: Richard Sandiford Date: Thu Dec 31 16:51:33 2020 + vect: Fix bogus alignment assumption in alias checks [PR94994] This PR is about a case in which the vectoriser was feeding incorrect alignment information to tree-data-ref.c, leading to incorrect runtime alias checks. The alignment was taken from the TREE_TYPE of the DR_REF, which in this case was a COMPONENT_REF with a normally-aligned type. However, the underlying MEM_REF was only byte-aligned. This patch uses dr_alignment to calculate the (byte) alignment instead, just like we do when creating vector MEM_REFs. gcc/ PR tree-optimization/94994 * tree-vect-data-refs.c (vect_vfa_align): Use dr_alignment. gcc/testsuite/ PR tree-optimization/94994 * gcc.dg/vect/pr94994.c: New test.
[Bug target/98214] [10 Regression] SVE: Wrong code with -O3 -msve-vector-bits=512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98214 rsandifo at gcc dot gnu.org changed: What|Removed |Added Summary|[10/11 Regression] SVE: |[10 Regression] SVE: Wrong |Wrong code with -O3 |code with -O3 |-msve-vector-bits=512 |-msve-vector-bits=512 --- Comment #5 from rsandifo at gcc dot gnu.org --- Fixed on trunk so far.
[Bug target/98214] [10/11 Regression] SVE: Wrong code with -O3 -msve-vector-bits=512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98214 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:0411210fddbd3ec27c8dc1183f40f662712a2232 commit r11-6379-g0411210fddbd3ec27c8dc1183f40f662712a2232 Author: Richard Sandiford Date: Thu Dec 31 16:10:47 2020 + genmodes: Update GET_MODE_MASK when changing NUNITS [PR98214] The static GET_MODE_MASKs for SVE vectors are based on the static precisions, which in turn are based on 128-bit SVE. The precisions are later updated based on -msve-vector-bits (usually to become variable length), but the GET_MODE_MASK stayed the same. This caused combine to fold: (*_extract:DI (subreg:DI (reg:VNxMM R) 0) ...) to zero because the extracted bits appeared to be insignificant. gcc/ PR rtl-optimization/98214 * genmodes.c (emit_insn_modes_h): Emit a definition of CONST_MODE_MASK. (emit_mode_mask): Treat mode_mask_array as non-constant if adj_nunits. (emit_mode_adjustments): Update GET_MODE_MASK when updating GET_MODE_NUNITS. * machmode.h (mode_mask_array): Use CONST_MODE_MASK.
[Bug target/53929] [meta-bug] -masm=intel with global symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929 H.J. Lu changed: What|Removed |Added CC||teo.samarzija at gmail dot com --- Comment #10 from H.J. Lu --- *** Bug 95652 has been marked as a duplicate of this bug. ***
[Bug target/95652] GCC 8.3.1 generates syntactically incorrect assembly code with -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95652 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from H.J. Lu --- dup. *** This bug has been marked as a duplicate of bug 53929 ***
[Bug target/95652] GCC 8.3.1 generates syntactically incorrect assembly code with -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95652 Bug 95652 depends on bug 87986, which changed state. Bug 87986 Summary: Assembler errors w/ -masm=intel https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87986 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug target/53929] [meta-bug] -masm=intel with global symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929 --- Comment #9 from H.J. Lu --- *** Bug 87986 has been marked as a duplicate of this bug. ***
[Bug target/87986] Assembler errors w/ -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87986 H.J. Lu changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from H.J. Lu --- dup *** This bug has been marked as a duplicate of bug 53929 ***
[Bug inline-asm/98488] name conflict using -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98488 H.J. Lu changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from H.J. Lu --- dup. *** This bug has been marked as a duplicate of bug 53929 ***
[Bug target/53929] [meta-bug] -masm=intel with global symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929 H.J. Lu changed: What|Removed |Added CC||umrihinva123 at gmail dot com --- Comment #8 from H.J. Lu --- *** Bug 98488 has been marked as a duplicate of this bug. ***
[Bug target/53929] [meta-bug] -masm=intel with global symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929 H.J. Lu changed: What|Removed |Added Last reconfirmed||2020-12-31 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Summary|Bug in the use of Intel asm |[meta-bug] -masm=intel with |syntax when a global is |global symbol |named "and" |
[Bug inline-asm/98488] New: name conflict using -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98488
Bug ID: 98488
Summary: name conflict using -masm=intel
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: umrihinva123 at gmail dot com
Target Milestone: ---
1. The exact version of GCC: gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
2. The system type: x86_64-linux-gnu
3. The options given when GCC was configured/built: ../src/configure -v
--with-pkgversion='Ubuntu 9.3.0-17ubuntu1~20.04'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2
--prefix=/usr
--with-gcc-major-version-only
--program-suffix=-9
--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
--enable-clocale=gnu
--enable-libstdcxx-debug
--enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new
--enable-gnu-unique-object
--disable-vtable-verify
--enable-plugin
--enable-default-pie
--with-system-zlib
--with-target-system-zlib=auto
--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=/build/gcc-9-HskZEa/gcc-9-9.3.0/debian/tmp-nvptx/usr,hsa
--without-cuda-driver
--enable-checking=release
--build=x86_64-linux-gnu
--host=x86_64-linux-gnu
--target=x86_64-linux-gnu
4. The complete command line that triggers the bug: gcc -masm=intel shl.c
5. The compiler output:
/tmp/ccSSHuDh.s: Assembler messages:
/tmp/ccSSHuDh.s:17: Error: invalid use of operator "shl"
/tmp/ccSSHuDh.s:18: Error: invalid use of operator "shr"
6. The preprocessed file:
# 1 "shl.c"
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 "shl.c"
int shl, shr;
int main(void)
{
shl = 0;
shr = 0;
return 0;
}
[Bug libstdc++/98473] std::vector::insert(pos, first, last) doesn't compile for T which has a deleted assignment operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98473
--- Comment #1 from Jonathan Wakely ---
Complete example:
#include
struct X {
X();
X(const X&);
X& operator=(const X&) = delete; // !!
X(X&&) noexcept;
X& operator=(X&&) noexcept;
int data = 54;
};
void add_to_front(std::vector& a, const std::vector& b) {
a.insert(a.begin(), b.begin(), b.end());
}
(In reply to Borislav Stanimirov from comment #0)
> It doesn't compile. My guess is that code which will never get invoked,
> still needs to compile (or, worse yet, copy assignment does get invoked?!)
When a.capacity() > a.b.size() the elements from b are copied over existing
elements of a using std::copy, which uses copy assignment.
To meet the requirements of the standard we would need to insert them at the
end and then use std::rotate to reposition them.
I see that libc++ has the same behaviour as libstdc++, which does make me think
the standard is wrong to require this (since it doesn't reflect reality). I'll
have to check the history of the standard.
> This does compile and work on msvc, so a compile-time check for the
> copy-assignment code is possible.
No, you can't check that at compile time. It's a dynamic condition. Presumably
MSVC uses std::rotate instead so no check is needed.
[Bug c++/98485] Symbols for identical constrained specializations have different linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98485 --- Comment #3 from Braden Obrzut --- Created attachment 49864 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49864=edit More well defined variant Added a variant of the code which has all specializations visible at all uses. Only thing hidden is the S1::f1 definition itself which should be valid to do given explicit instantiations. Same behavior of the second specialization having different linkage for some reason. Although in this case a compiler warning is produced on main.cpp. main.h:25:28: warning: ‘static void S1::f1() [with T = S3]’ used but never defined Interestingly despite presumably being more well defined Clang 11 doesn't like this version at all.
[Bug tree-optimization/94802] Failure to recognize identities with __builtin_clz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94802 --- Comment #4 from Jakub Jelinek --- Not fixed completely yet, (a - b) < 0 is not optimized into a < b yet. The following patch does that, but it regresses --- gcc/match.pd.jj 2020-12-30 17:04:27.340815135 +0100 +++ gcc/match.pd2020-12-30 17:41:44.393443188 +0100 @@ -3966,6 +3966,16 @@ (define_operator_list COND_TERNARY (cmp (sub@2 @0 @1) integer_zerop) (if (single_use (@2)) (cmp @0 @1) +#if GIMPLE +(for cmp (lt le gt ge) + (for sub (minus pointer_diff) + (simplify + (cmp (sub@2 @0 @1) integer_zerop) + (if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0)) + && !TYPE_OVERFLOW_SANITIZED (TREE_TYPE (@0)) + && single_use (@2)) +(cmp @0 @1) +#endif /* Transform comparisons of the form X * C1 CMP 0 to X CMP 0 in the signed arithmetic case. That form is created by the compiler the following test: +FAIL: gcc.dg/tree-ssa/pr45397.c scan-tree-dump-not evrp " & 255;" +FAIL: gcc.dg/tree-ssa/pr45397.c scan-tree-dump-not phiopt2 "if " +FAIL: gcc.dg/tree-ssa/pr45397.c scan-tree-dump-times phiopt2 "MAX_EXPR" 3 +FAIL: gcc.dg/tree-ssa/pr45397.c scan-tree-dump-times phiopt2 "MIN_EXPR" 3 so some more work will be needed.
[Bug c++/98485] Symbols for identical constrained specializations have different linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98485 --- Comment #2 from Braden Obrzut --- I'm actually not certain if I'm playing fast and loose with ODR. While I can definitely agree that this construct is fragile, if a specialization has the same sequence of tokens as the base template is it actually considered a different definition? Thinking of C++20 6.3 paragraph 13.8 here. While same sequence of tokens isn't strictly true in the provided example, one could easily hoist the definitions of f1 out of the structure definition to make each specialization exactly the same as the base template and GCC still wants to use internal linkage for the second specialization. Not that it technically would matter if it's indeed an ODR violation, but Clang does seem to work as expected for this scenario.
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 94785, which changed state. Bug 94785 Summary: Failure to detect abs pattern using multiplication https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94785 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/94785] Failure to detect abs pattern using multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94785 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed for GCC 11.
[Bug tree-optimization/98474] [8/9/10 Regression] incorrect results using __uint128_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98474 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9/10 Regression] |incorrect results using |incorrect results using |__uint128_t |__uint128_t --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/94802] Failure to recognize identities with __builtin_clz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94802 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d2eb616a0f7bea78164912aa438c29fe1ef5774a commit r11-6378-gd2eb616a0f7bea78164912aa438c29fe1ef5774a Author: Jakub Jelinek Date: Thu Dec 31 11:09:26 2020 +0100 match.pd: Add clz(X) == 0 -> (int)X < 0 etc. simpifications [PR94802] The following patch adds some clz simplifications. If clz is 0, then the MSB of the argument is set, and if clz is prec-1, then the argument is 1. 2020-12-31 Jakub Jelinek PR tree-optimization/94802 * match.pd (clz(X) == 0 -> (int)X < 0): New simplification. (clz(X) == (prec-1) -> X == 1): Likewise. * gcc.dg/tree-ssa/pr94802-1.c: New test.
[Bug middle-end/94785] Failure to detect abs pattern using multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94785 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8f12ce2ea3be12de4f83d3c419bdb1dc5036b202 commit r11-6377-g8f12ce2ea3be12de4f83d3c419bdb1dc5036b202 Author: Jakub Jelinek Date: Thu Dec 31 11:08:15 2020 +0100 match.pd: Add (-(X < 0) | 1) * X -> abs (X) etc. simplifications [PR94785] The following patch adds two simplifications to recognize idioms for ABS_EXPR resp. ABSU_EXPR. 2020-12-31 Jakub Jelinek PR tree-optimization/94785 * match.pd ((-(X < 0) | 1) * X -> abs (X)): New simplification. ((-(X < 0) | 1U) * X -> absu (X)): Likewise. * gcc.dg/tree-ssa/pr94785.c: New test.
[Bug tree-optimization/98474] [8/9/10/11 Regression] incorrect results using __uint128_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98474 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9e603837f7ad886df62e02ac0cd395ec17b7d587 commit r11-6376-g9e603837f7ad886df62e02ac0cd395ec17b7d587 Author: Jakub Jelinek Date: Thu Dec 31 11:06:56 2020 +0100 wide-int: Fix wi::to_mpz [PR98474] The following testcase is miscompiled, because niter analysis miscomputes the number of iterations to 0. The problem is that niter analysis uses mpz_t (wonder why, wouldn't widest_int do the same job?) and when wi::to_mpz is called e.g. on the TYPE_MAX_VALUE of __uint128_t, it initializes the mpz_t result with wrong value. wi::to_mpz has code to handle negative wide_ints in signed types by inverting all bits, importing to mpz and complementing it, which is fine, but doesn't handle correctly the case when the wide_int's len (times HOST_BITS_PER_WIDE_INT) is smaller than precision when wi::neg_p. E.g. the 0x TYPE_MAX_VALUE is represented in wide_int as 0x len 1, and wi::to_mpz would create 0x mpz_t value from that. This patch handles it by adding the needed -1 host wide int words (and has also code to deal with precision that aren't multiple of HOST_BITS_PER_WIDE_INT). 2020-12-31 Jakub Jelinek PR tree-optimization/98474 * wide-int.cc (wi::to_mpz): If wide_int has MSB set, but type is unsigned and excess negative, append set bits after len until precision. * gcc.c-torture/execute/pr98474.c: New test.
[Bug sanitizer/98206] UBSan: Casting from multiple inheritance base to derived class triggers undefined behavior sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98206 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a9ec9902d7f1a9bf7a2778c3fb8fc75bc2df2cef commit r11-6375-ga9ec9902d7f1a9bf7a2778c3fb8fc75bc2df2cef Author: Jakub Jelinek Date: Thu Dec 31 10:20:39 2020 +0100 fold-const: Avoid (cast) ((cast2) x p+ y) folding for -fsanitize=alignment [PR98206] The following testcase is diagnosed by UBSan as invalid, even when it is valid. We have a derived type Base2 at offset 1 with alignment 1 and do: (const Derived &) ((const Base2 *) this + -1) but the folder before ubsan in the FE gets a chance to instrument it optimizes that into: (const Derived &) this + -1 and so we require that this has 8-byte alignment which Derived class needs. Fixed by avoiding such an optimization when -fsanitize=alignment is in effect if it would affect the alignments (and guarded with !in_gimple_form because we don't really care during GIMPLE, though pointer conversions are useless then and so such folding isn't needed very much during GIMPLE). 2020-12-31 Jakub Jelinek PR c++/98206 * fold-const.c: Include asan.h. (fold_unary_loc): Don't optimize (ptr_type) (((ptr_type2) x) p+ y) into ((ptr_type) x) p+ y if sanitizing alignment in GENERIC and ptr_type points to type with higher alignment than ptr_type2. * g++.dg/ubsan/align-4.C: New test.
[Bug c/98487] ICE: tree check: expected identifier_node, have tree_list in is_attribute_p, at attribs.h:155 [C2X attribute syntax, gnu::format and -Wsuggest-attribute=format]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98487 --- Comment #1 from Pekka S --- Created attachment 49863 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49863=edit Possible patch Uses get_attribute_name instead of TREE_PURPOSE.
[Bug c/98487] New: ICE: tree check: expected identifier_node, have tree_list in is_attribute_p, at attribs.h:155 [C2X attribute syntax, gnu::format and -Wsuggest-attribute=format]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98487
Bug ID: 98487
Summary: ICE: tree check: expected identifier_node, have
tree_list in is_attribute_p, at attribs.h:155 [C2X
attribute syntax, gnu::format and
-Wsuggest-attribute=format]
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: p...@gcc-bugzilla.mail.kapsi.fi
Target Milestone: ---
Created attachment 49862
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49862=edit
Triggers the ICE.
Hi.
Combining C2X attribute syntax ``[[]]'', gnu::format and
-Wsuggest-attribute=format seems to ICE.
This problem does not occur if a) ``__attribute__'' syntax is used instead, b)
-Wsuggest-attribute=format is not used. Does not happen when processing
function declarations or if the corresponding library call is not present.
Only ``format(printf, ...)'' and ``format(scanf, ...)'' seem to be affected.
Attached test case. Using GCC 11.0.0 20201231, aarch64-*-* on
x86_64-w64-mingw32 but I presume this is not host or target related.
Given e.g. PR90953 and PR94733 I presume the problematic line is at:
gcc/c-family/c-format.c:1216:
1216 if (is_attribute_p ("format", TREE_PURPOSE (c))
and it should use` get_attribute_name' instead. Attached a patch that does
just that. Seems to fix the problem, but I'm no expert on GCC internals.
$ cat attribute__format.c [excerpt]
#define ATTR(...) [[gnu::__VA_ARGS__]]
// ...
ATTR(__format__(__printf__, 1, 2))
void
do_printf(const char * const a0, ...) { /* ... */ }
$ gcc -c -std=c2x -Wall -Wextra -Wpedantic -Wsuggest-attribute=format
attribute__format.c
attribute__format.c: In function 'do_printf':
attribute__format.c:17:3: internal compiler error: tree check: expected
identifier_node, have tree_list in is_attribute_p, at attribs.h:155
17 | vprintf(a0, ap);
| ^~~
$ gcc -c -std=c2x -Wall -Wextra -Wpedantic -Wsuggest-attribute=format -wrapper
gdb,--args
(gdb) b internal_error
(gdb) run
Thread 1 hit Breakpoint 1, internal_error (
gmsgid=0x1cc3f90 <(anonymous namespace)::pass_data_vrp+2000> "tree check:
%s, have %s in %s, at %s:%d")
at <...>/gcc/gcc/diagnostic.c:1764
(gdb) bt
#0 internal_error (
gmsgid=0x1cc3f90 <(anonymous namespace)::pass_data_vrp+2000> "tree check:
%s, have %s in %s, at %s:%d")
at <...>/gcc/gcc/diagnostic.c:1764
#1 0x01a9adf2 in tree_check_failed (node=,
file=0x1bc8580
"<...>/gcc/gcc/attribs.h",
line=, function=0x1bc856d
"is_attribute_p")
at <...>/gcc/gcc/tree.c:13438
#2 0x01921e1a in tree_check (__c=, __g=,
__l=,
__f=, __t=) at <...>/gcc/gcc/tree.h:3594
#3 is_attribute_p (ident=0x1cc3f90 <(anonymous
namespace)::pass_data_vrp+2000>,
attr_name=0x1bc90fd "format")
at <...>/gcc/gcc/attribs.h:155
#4 0x019228d6 in is_attribute_p (attr_name=0x1bc90fd
"format",
ident=) at <...>/gcc/gcc/tree.h:3452
#5 check_function_format (fntype=fntype@entry=0x1eea39d8, attrs=, nargs=nargs@entry=2,
argarray=argarray@entry=0x1edf9e40, arglocs=arglocs@entry=0x1ad0e878)
at <...>/gcc/gcc/c-family/c-format.c:1216
#6 0x004cbea6 in check_function_arguments (loc=loc@entry=34268454,
fndecl=fndecl@entry=0x1ec0b900,
fntype=fntype@entry=0x1eea39d8, nargs=, nargs@entry=2,
argarray=argarray@entry=0x1edf9e40,
arglocs=arglocs@entry=0x1ad0e878) at <...>/gcc/gcc/tree.h:3718
#7 0x0044c701 in build_function_call_vec (loc=,
loc@entry=34268454, arg_loc=arg_loc@entry=...,
function=, function@entry=0x1ec0b900, params=, origtypes=,
origtypes@entry=0x1eeddb90, orig_fundecl=0x1ec0b900,
orig_fundecl@entry=0x0)
at <...>/gcc/gcc/c/c-typeck.c:3144
#8 0x0044d4fa in c_build_function_call_vec (loc=loc@entry=34268454,
arg_loc=...,
function=function@entry=0x1ec0b900, params=,
params@entry=0x1edf9e38, origtypes=0x1eeddb90)
at <...>/gcc/gcc/c/c-typeck.c:3210
#9 0x0046ea76 in c_parser_postfix_expression_after_primary
(parser=parser@entry=0x1ead4240,
expr_loc=expr_loc@entry=34268454, expr=...) at
<...>/gcc/gcc/c/c-parser.c:10469
#10 0x00465724 in c_parser_postfix_expression (parser=,
parser@entry=0x1ead4240)
at <...>/gcc/gcc/../libcpp/include/line-map.h:577
#11 0x00469fdb in c_parser_unary_expression
(parser=parser@entry=0x1ead4240)
at <...>/gcc/gcc/c/c-parser.c:8230
#12 0x0046ba20 in c_parser_cast_expression
(parser=parser@entry=0x1ead4240, after=after@entry=0x0)
at <...>/gcc/gcc/c/c-parser.c:8072
#13 0x0046bcf6 in c_parser_binary_expression
(parser=parser@ent
[Bug middle-end/56719] missed optimization: i > 0xffff || i*4 > 0xffff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56719 --- Comment #10 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d96b8556e569a1ccce36ef990e167031d07a661a commit r11-6374-gd96b8556e569a1ccce36ef990e167031d07a661a Author: Jakub Jelinek Date: Thu Dec 31 10:19:06 2020 +0100 reassoc: Optimize x > 0x1fff || y > 0x1fff into (x | y) > 0x1fff [PR56719] The following patch adds an optimization mentioned in PR56719 #c8. We already have the x != 0 && y != 0 && z != 0 into (x | y | z) != 0 and x != -1 && y != -1 && y != -1 into (x & y & z) != -1 optimizations, this patch just extends that to x < C && y < C && z < C for power of two constants C into (x | y | z) < C (for unsigned comparisons). I didn't want to create too many buckets (there can be TYPE_PRECISION such constants), so the patch instead just uses one buckets for all such constants and loops over that bucket up to TYPE_PRECISION times. 2020-12-31 Jakub Jelinek PR tree-optimization/56719 * tree-ssa-reassoc.c (optimize_range_tests_cmp_bitwise): Also optimize x < C && y < C && z < C when C is a power of two constant into (x | y | z) < C. * gcc.dg/tree-ssa/pr56719.c: New test.
[Bug c++/98485] Symbols for identical constrained specializations have different linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98485 --- Comment #1 from Andrew Pinski --- I thought the C++ rule was all specializations has to be seen when you use one or the other. Otherwise this becomes an ODR issue and therefor invalid code (not have to be diagnostic at compile time).
