[Bug libstdc++/104395] alignof is a C++11 feature. src/c++98/bitmap_allocator.cc???
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104395 --- Comment #5 from Andrew Pinski --- GCC's option is -faligned-new -fsized-deallocation -std=c++98
[Bug c++/92385] extremely long and memory intensive compilation for brace construction of array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92385 --- Comment #14 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:119cea98f664764cce04963243c39c8f6d797d33 commit r12-7069-g119cea98f664764cce04963243c39c8f6d797d33 Author: Jason Merrill Date: Wed Feb 2 18:36:41 2022 -0500 c++: assignment, aggregate, array [PR104300] The PR92385 fix meant that we see more VEC_INIT_EXPR outside of INIT_EXPR; in such cases, we need to wrap them in TARGET_EXPR. I previously fixed that in build_array_copy; we also need it in process_init_constructor. After fixing that, I needed to adjust a few places to recognize the VEC_INIT_EXPR even inside a TARGET_EXPR. And prevent cp_fully_fold_init from lowering VEC_INIT_EXPR too soon. And handle COMPOUND_EXPR inside TARGET_EXPR better. PR c++/104300 PR c++/92385 gcc/cp/ChangeLog: * cp-tree.h (get_vec_init_expr): New. (target_expr_needs_replace): New. * cp-gimplify.cc (cp_gimplify_init_expr): Use it. (struct cp_fold_data): New. (cp_fold_r): Only genericize inits at end of fn. (cp_fold_function): Here. (cp_fully_fold_init): Not here. * init.cc (build_vec_init): Use get_vec_init_expr. * tree.cc (build_vec_init_expr): Likewise. * typeck2.cc (split_nonconstant_init_1): Likewise. (process_init_constructor): Wrap VEC_INIT_EXPR in TARGET_EXPR. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-array14.C: New test.
[Bug c++/104300] [12 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2977 since r12-6326-ge948436eab818c52
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104300 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:119cea98f664764cce04963243c39c8f6d797d33 commit r12-7069-g119cea98f664764cce04963243c39c8f6d797d33 Author: Jason Merrill Date: Wed Feb 2 18:36:41 2022 -0500 c++: assignment, aggregate, array [PR104300] The PR92385 fix meant that we see more VEC_INIT_EXPR outside of INIT_EXPR; in such cases, we need to wrap them in TARGET_EXPR. I previously fixed that in build_array_copy; we also need it in process_init_constructor. After fixing that, I needed to adjust a few places to recognize the VEC_INIT_EXPR even inside a TARGET_EXPR. And prevent cp_fully_fold_init from lowering VEC_INIT_EXPR too soon. And handle COMPOUND_EXPR inside TARGET_EXPR better. PR c++/104300 PR c++/92385 gcc/cp/ChangeLog: * cp-tree.h (get_vec_init_expr): New. (target_expr_needs_replace): New. * cp-gimplify.cc (cp_gimplify_init_expr): Use it. (struct cp_fold_data): New. (cp_fold_r): Only genericize inits at end of fn. (cp_fold_function): Here. (cp_fully_fold_init): Not here. * init.cc (build_vec_init): Use get_vec_init_expr. * tree.cc (build_vec_init_expr): Likewise. * typeck2.cc (split_nonconstant_init_1): Likewise. (process_init_constructor): Wrap VEC_INIT_EXPR in TARGET_EXPR. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-array14.C: New test.
[Bug libstdc++/104395] alignof is a C++11 feature. src/c++98/bitmap_allocator.cc???
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104395 --- Comment #4 from cqwrteur --- also in all xxx_allocator.h including mt_allocator.h pool_allocator.h
[Bug libstdc++/104395] alignof is a C++11 feature. src/c++98/bitmap_allocator.cc???
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104395
cqwrteur changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #3 from cqwrteur ---
#include
#include
int main()
{
__gnu_cxx::new_allocator n;
n.allocate(3);
}
clang++ -o a a.cc -faligned-allocation -fsized-deallocation -s -flto
-fuse-ld=lld -std=c++98
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/12.0.1/../../../../include/c++/12.0.1/bits/new_allocator.h:55:21:
note: de
clared here
template
^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/12.0.1/../../../../include/c++/12.0.1/bits/new_allocator.h:132:55:
error: '_Tp' does not refer to a value
std::align_val_t __al = std::align_val_t(alignof(_Tp));
Sounds like a C++98 issue.
[Bug libstdc++/104395] alignof is a C++11 feature. src/c++98/bitmap_allocator.cc???
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104395 cqwrteur changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from cqwrteur --- It seems to be other issues rather than this one. close.
[Bug libstdc++/104395] alignof is a C++11 feature. src/c++98/bitmap_allocator.cc???
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104395 --- Comment #1 from cqwrteur --- /home/cqwrteur/myhome/gcc_build/native/wasm32-wasi/libstdc++-v3/include/ext/pool_allocator.h:274:16: error: '_Tp' does not refer to a value if (alignof(_Tp) > __STDCPP_DEFAULT_NEW_ALIGNMENT__) ^ Sounds like a weird issue in clang 15.
[Bug libstdc++/104395] New: alignof is a C++11 feature. src/c++98/bitmap_allocator.cc???
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104395 Bug ID: 104395 Summary: alignof is a C++11 feature. src/c++98/bitmap_allocator.cc??? Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/src/c%2B%2B98/bitmap_allocator.cc https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/ext/bitmap_allocator.h clang provides the option -faligned-allocation. It would define that macro even in C++98 mode. Probably we need to detect whether __cplusplus >= 201103L? /home/cqwrteur/myhome/gcc_build/native/wasm32-wasi/libstdc++-v3/include/ext/bitmap_allocator.h:1047:18: error: unexpected type name 'value_type': expected expression if (alignof(value_type) > __STDCPP_DEFAULT_NEW_ALIGNMENT__) ^
[Bug fortran/104391] [9/10/11 Regression] bind(C) and allocatable or pointer attribute don't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104391 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=92189 --- Comment #1 from Andrew Pinski --- Maybe PR 92189.
[Bug ipa/102059] Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059 --- Comment #30 from Kewen Lin --- (In reply to pc from comment #27) > There was a commit related to this bug, but it is still in ASSIGNED state, > so I'm not sure if this was to be considered "fixed", but... > > Chip discovered that, with a build of today's trunk, the original test case, > and at least gcc.target/powerpc/pr102059-1.c still fail (I didn't try > others), and it seems to be related to the presence of "-flto": > -- > $ gcc -c gcc/testsuite/gcc.target/powerpc/pr102059-1.c -O2 -mcpu=power8 > -Wno-attributes -flto > gcc/testsuite/gcc.target/powerpc/pr102059-1.c: In function 'bar': > gcc/testsuite/gcc.target/powerpc/pr102059-1.c:8:1: error: inlining failed in > call to 'always_inline' 'foo': target specific option mismatch > 8 | foo (int *b) > | ^~~ > gcc/testsuite/gcc.target/powerpc/pr102059-1.c:18:8: note: called from here >18 | *a = foo (a); > |^~~ > > $ gcc -c gcc/testsuite/gcc.target/powerpc/pr102059-1.c -O2 -mcpu=power8 > -Wno-attributes > $ > -- > > The testcases included with the commit do not use "-flto", so these tests > are PASSing. Your spotted failure is expected, as comment 25 there are two patches for this issue, the pushed commit was just for the 2nd issue. The first issue is pending on review. Please see the link: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587635.html, I just ping-ed it before my vacation, will ping it again later.
[Bug libgomp/104385] Segmentation fault when using nested dependent tasks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104385 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-02-05 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Known to fail||9.1.0 Target|x86_64-apple-darwin21 | --- Comment #6 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/104394] Failure to optimize vector pattern for x < 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104394
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Severity|normal |enhancement
Last reconfirmed||2022-02-05
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
We are missing a lot of vector vs scalar optimizations really.
This is a 2 optimizations we are missing here really.
First is:
#define bit 1u<<3
typedef int32_t v4i32 __attribute__((vector_size(16)));
v4i32 get_cmpmask(v4i32 mask)
{
v4i32 signmask{(int32_t)bit, (int32_t)bit, (int32_t)bit, (int32_t)bit};
return ((signmask & mask) == signmask);
}
This is not optimized to -(signmask>>log2(bit))&1) which is similar to:
pslld xmm0, 28
psrad xmm0, 31
on x86_64.
Here is a full example which shows what needs to be done:
#define bit 3
typedef int32_t v4i32 __attribute__((vector_size(16)));
v4i32 get_cmpmask(v4i32 mask)
{
v4i32 signmask{(int32_t)1u<>= bit;
mask &= 1;
mask = -mask;
return mask;
}
v4i32 get_cmpmask2(v4i32 mask)
{
mask <<= 31-bit;
mask >>= 31;
return mask;
}
CUT ---
Note clang does not even optimize get_cmpmask1 either.
GCC does get the scalar version correct though (but not at the gimple level):
int get_cmpmasks(int mask)
{
mask >>= bit;
mask &= 1;
mask = -mask;
return mask;
}
[Bug tree-optimization/104394] New: Failure to optimize vector pattern for x < 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104394
Bug ID: 104394
Summary: Failure to optimize vector pattern for x < 0
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
typedef int32_t v4i32 __attribute__((vector_size(16)));
v4i32 get_cmpmask(v4i32 mask)
{
v4i32 signmask{(int32_t)0x8000, (int32_t)0x8000,
(int32_t)0x8000, (int32_t)0x8000};
return ((signmask & mask) == signmask);
}
This can be optimized to `return mask < 0;`. This transformation is done by
LLVM, but not by GCC.
[Bug libgomp/104385] Segmentation fault when using nested dependent tasks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104385
Jakub Jelinek changed:
What|Removed |Added
Keywords||openmp
--- Comment #5 from Jakub Jelinek ---
With
#include
int
main ()
{
int j = 0;
#pragma omp parallel master shared(j)
{
#pragma omp task shared(j)
{
#pragma omp task depend(out: j) shared(j)
{
sleep (1);
j = 1;
}
#pragma omp task depend(inout: j) shared(j)
j += 1;
}
}
return j - 2;
}
it segfaults fairly reliably.
[Bug libstdc++/104161] Potential Security Vulnerability: remove_all and symbolic link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104161
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:ebf6175464768983a2d8c82c2d47771ee89192b8
commit r12-7062-gebf6175464768983a2d8c82c2d47771ee89192b8
Author: Jonathan Wakely
Date: Tue Feb 1 22:04:46 2022 +
libstdc++: Fix filesystem::remove_all races [PR104161]
This fixes the remaining filesystem::remove_all race condition by using
POSIX openat to recurse into sub-directories and using POSIX unlinkat to
remove files. This avoids the remaining race where the directory being
removed is replaced with a symlink after the directory has been opened,
so that the filesystem::remove("subdir/file") resolves to "target/file"
instead, because "subdir" has been removed and replaced with a symlink.
The previous patch only fixed the case where the directory was replaced
with a symlink before we tried to open it, but it still used the full
(potentially compromised) path as an argument to filesystem::remove.
The first part of the fix is to use openat when recursing into a
sub-directory with recursive_directory_iterator. This means that opening
"dir/subdir" uses the file descriptor for "dir", and so is sure to open
"dir/subdir" and not "symlink/subdir". (The previous patch to use
O_NOFOLLOW already ensured we won't open "dir/symlink/" here.)
The second part of the fix is to use unlinkat for the remove_all
operation. Previously we used a directory_iterator to get the name of
each file in a directory and then used filesystem::remove(iter->path())
on that name. This meant that any checks (e.g. O_NOFOLLOW) done by the
iterator could be invalidated before the remove operation on that
pathname. The directory iterator contains an open DIR stream, which we
can use to obtain a file descriptor to pass to unlinkat. This ensures
that the file being deleted really is contained within the directory
we're iterating over, rather than using a pathname that could resolve to
some other file.
The filesystem::remove_all function previously used a (non-recursive)
filesystem::directory_iterator for each directory, and called itself
recursively for sub-directories. The new implementation uses a single
filesystem::recursive_directory_iterator object, and calls a new __erase
member function on that iterator. That new __erase member function does
the actual work of removing a file (or a directory after its contents
have been iterated over and removed) using unlinkat. That means we don't
need to expose the DIR stream or its file descriptor to the remove_all
function, it's still encapuslated by the iterator class.
It would be possible to add a __rewind member to directory iterators
too, to call rewinddir after each modification to the directory. That
would make it more likely for filesystem::remove_all to successfully
remove everything even if files are being written to the directory tree
while removing it. It's unclear if that is actually prefereable, or if
it's better to fail and report an error at the first opportunity.
The necessary APIs (openat, unlinkat, fdopendir, dirfd) are defined in
POSIX.1-2008, and in Glibc since 2.10. But if the target doesn't provide
them, the original code (with race conditions) is still used.
This also reduces the number of small memory allocations needed for
std::filesystem::remove_all, because we do not store the full path to
every directory entry that is iterated over. The new filename_only
option means we only store the filename in the directory entry, as that
is all we need in order to use openat or unlinkat.
Finally, rather than duplicating everything for the Filesystem TS, the
std::experimental::filesystem::remove_all implementation now just calls
std::filesystem::remove_all to do the work.
libstdc++-v3/ChangeLog:
PR libstdc++/104161
* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check for dirfd
and unlinkat.
* config.h.in: Regenerate.
* configure: Regenerate.
* include/bits/fs_dir.h (recursive_directory_iterator): Declare
remove_all overloads as friends.
(recursive_directory_iterator::__erase): Declare new member
function.
* include/bits/fs_fwd.h (remove, remove_all): Declare.
* src/c++17/fs_dir.cc (_Dir): Add filename_only parameter to
constructor. Pass file descriptor argument to base constructor.
(_Dir::dir_and_pathname, _Dir::open_subdir, _Dir::do_unlink)
(_Dir::unlink, _Dir::rmdir): Define new member functions.
(directory_iterator): Pass filename_only argument to _Dir
constructor.
(recursive_directory_iterator::_Dir_stack): Adjust constructor
parameters to
[Bug libgomp/104385] Segmentation fault when using nested dependent tasks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104385 --- Comment #4 from Andrew Pinski --- I can't get it to fail for me on x86_64-linux-gnu.
[Bug libgomp/104385] Segmentation fault when using nested dependent tasks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104385
--- Comment #3 from P.A. Wacrenier ---
gdb output (x86_64 linux)
Thread 22 "a.out" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffedd10700 (LWP 1363311)]
priority_list_downgrade_task (child_task=0x7fffecc0, list=0x7fffe8d0,
type=PQ_CHILDREN) at ../.././libgomp/task.c:991
991 ../.././libgomp/task.c: Aucun fichier ou dossier de ce type.
(gdb) thread 22
[Switching to thread 22 (Thread 0x7fffedd10700 (LWP 1363311))]
#0 priority_list_downgrade_task (child_task=0x7fffecc0,
list=0x7fffe8d0, type=PQ_CHILDREN) at ../.././libgomp/task.c:991
991 in ../.././libgomp/task.c
(gdb) bt full
#0 priority_list_downgrade_task (child_task=0x7fffecc0,
list=0x7fffe8d0, type=PQ_CHILDREN) at ../.././libgomp/task.c:991
next_task = 0xff90
node = 0x7fffed30
node =
next_task =
prev_child =
#1 priority_queue_downgrade_task (task=0x7fffecc0, head=,
type=PQ_CHILDREN) at ../.././libgomp/task.c:1047
list = 0x7fffe8d0
#2 priority_queue_downgrade_task (task=0x7fffecc0, head=,
type=PQ_CHILDREN) at ../.././libgomp/task.c:1035
list =
#3 gomp_task_run_pre (child_task=child_task@entry=0x7fffecc0,
parent=, team=team@entry=0x405350)
at ../.././libgomp/task.c:1077
taskgroup =
#4 0x77fa315c in gomp_barrier_handle_tasks (state=state@entry=0) at
../.././libgomp/task.c:1335
ignored = true
cancelled = false
thr =
team = 0x405350
task =
child_task = 0x7fffecc0
to_free = 0x7fffeb20
do_wake = 0
#5 0x77faa7f8 in gomp_team_barrier_wait_end (bar=,
state=0) at ../.././libgomp/config/linux/bar.c:116
generation = 0
gen =
#6 0x77faa8da in gomp_team_barrier_wait_final (bar=bar@entry=0x4053d0)
at ../.././libgomp/config/linux/bar.c:136
state =
#7 0x77fa7e12 in gomp_thread_start (xdata=) at
../.././libgomp/team.c:124
team = 0x405350
task = 0x4069a0
data =
thr =
pool = 0x405280
local_fn = 0x401201
local_data = 0x7fffdec8
--Type for more, q to quit, c to continue without paging--
#8 0x77ef4fa3 in start_thread (arg=) at
pthread_create.c:486
ret =
pd =
now =
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737183287040,
-8592581161367667977, 140737488341950, 140737488341951,
140737183287040, -120, 8592550692851776247,
8592563709294246647}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0,
0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call =
#9 0x77e254cf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
[Bug libgomp/104385] Segmentation fault when using nested dependent tasks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104385 --- Comment #2 from P.A. Wacrenier --- Sorry, as a matter of fact it does not (always) work on x86_64-pc-linux-gnu. Utilisation des specs internes. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper Cible : x86_64-pc-linux-gnu Configuré avec: ./configure --prefix=/net/ens/gcc/gcc_10.2.0 --exec-prefix=/net/ens/gcc/gcc_10.2.0 Modèle de thread: posix Algorithmes de compression LTO supportés: zlib zstd gcc version 10.2.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mtune=generic' '-march=x86-64' '-pthread' /autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.2.0/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu -iprefix /autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/ -D_REENTRANT ici.c -mtune=generic -march=x86-64 -fopenmp -fpch-preprocess -o ici.i le répertoire « /autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/include » est ignoré car inexistant le répertoire « /autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/10.2.0/include » est ignoré car présent deux fois le répertoire « /usr/local/include/x86_64-linux-gnu » est ignoré car inexistant le répertoire « /autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/10.2.0/include-fixed » est ignoré car présent deux fois le répertoire « /autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/include » est ignoré car inexistant la recherche pour #include "..." débute ici : la recherche pour #include <...> débute ici: /autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/include /autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/include-fixed /usr/local/include /autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/../../include /usr/include/x86_64-linux-gnu /usr/include Fin de la liste de recherche. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mtune=generic' '-march=x86-64' '-pthread' /autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.2.0/cc1 -fpreprocessed ici.i -quiet -dumpbase ici.c -mtune=generic -march=x86-64 -auxbase ici -version -fopenmp -o ici.s GNU C17 (GCC) version 10.2.0 (x86_64-pc-linux-gnu) compilé par GNU C version 10.2.0, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.20-GMP heuristiques GGC: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C17 (GCC) version 10.2.0 (x86_64-pc-linux-gnu) compilé par GNU C version 10.2.0, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.20-GMP heuristiques GGC: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 64cac5b5eb450f2b66ce9b43c80e8788 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mtune=generic' '-march=x86-64' '-pthread' as -v --64 -o ici.o ici.s Version de l'assembleur GNU 2.31.1 (x86_64-linux-gnu) utilisant la version BFD (GNU Binutils for Debian) 2.31.1 COMPILER_PATH=/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.2.0/:/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../libexec/gcc/ LIBRARY_PATH=/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/:/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/:/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../:/lib/:/usr/lib/ Lecture des spécifications à partir de /autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/libgomp.spec COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mtune=generic' '-march=x86-64' '-pthread' /autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.2.0/collect2 -plugin /autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.2.0/liblto_plugin.so -plugin-opt=/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper -plugin-opt=-fresolution=ici.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /lib/x86_64-linux-gnu/crt1.o /lib/x86_64-linux-gnu/crti.o /autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/crtbegin.o -L/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0
[Bug fortran/104393] incorrect results with elemental functions of scalar derived types with allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104393 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-02-04 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Known to fail||9.1.0 Keywords||wrong-code --- Comment #1 from Andrew Pinski --- In GCC before 9, the program would seg fault at runtime. Confirmed.
[Bug fortran/104393] New: incorrect results with elemental functions of scalar derived types with allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104393
Bug ID: 104393
Summary: incorrect results with elemental functions of scalar
derived types with allocatable components
Product: gcc
Version: og11 (devel/omp/gcc-11)
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: a.shahmoradi at gmail dot com
Target Milestone: ---
Created attachment 52354
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52354=edit
main program to reproduce the bug
The elemental attribute for functions that take derived-type scalar containers
with allocatable components does not yield the correct result.
The following is the output of the test program supplied, compiled with
gfortran-11 elementalBugGfortran10.f90
on Microsoft Subsystem for Linux (WSL-2).
! This result is incorrect
ismore([Container('A'), Container('B'), Container('C')], Container('B'))
F T T
! This result is the expected answer and is correct
['A', 'B', 'C'] > 'B'
F F T
[Bug libgomp/104385] Segmentation fault when using nested dependent tasks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104385 Andrew Pinski changed: What|Removed |Added Target||x86_64-apple-darwin21 --- Comment #1 from Andrew Pinski --- Works on x86_64-linux-gnu. Maybe related to TLS emulation?
[Bug c++/83264] std::initializer_list with a single element selects the wrong overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83264 Andrew Pinski changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 99273 has been marked as a duplicate of this bug. ***
[Bug c++/99273] List initialization prefers initializer_list a little too strongly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99273 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 83264. *** This bug has been marked as a duplicate of bug 83264 ***
[Bug tree-optimization/104389] [10/11/12 Regression] HUGE_VAL * 0.0 is no longer a NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389 --- Comment #6 from Marc Glisse --- Not this bug, but note that the comment and the code don't match in this transformation: "a negative value" becomes !tree_expr_maybe_real_minus_zero_p (@0) which is quite different. I am not sure the path with a negative @0 for which tree_expr_maybe_real_minus_zero_p returns false can be reached though.
[Bug c++/90816] -finstrument-functions-exclude-function-list improperly handles namespace/class definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90816 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |10.0 Status|ASSIGNED|RESOLVED --- Comment #4 from Andrew Pinski --- Fixed in GCC by r10-2093.
[Bug c++/90809] -finstrument-functions-exclude-function-list mishandles comma escaping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90809 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |10.0 --- Comment #4 from Andrew Pinski --- Fixed in GCC 10 by r10-2093.
[Bug c++/104388] Request: A builtin to mark an object as invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104388 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117
--- Comment #13 from Vladimir Makarov ---
I think there are two code spots whose pitfalls resulted in the PR.
The first one is in rs6000.cc::legitimate_lo_sum_address_p which permits wrong
pic low-sum address.
Another one is in lra-constraints.cc::process_address_1 which permits put wrong
low-sum address in reg and use the reg in memory.
The following patch solves the problem:
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 5404fb18755..306f67f26c4 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -8202,7 +8202,7 @@ legitimate_lo_sum_address_p (machine_mode mode, rtx x,
int strict)
{
bool large_toc_ok;
- if (DEFAULT_ABI == ABI_V4 && flag_pic)
+ if ((DEFAULT_ABI == ABI_V4 || DEFAULT_ABI == ABI_DARWIN) && flag_pic)
return false;
/* LRA doesn't use LEGITIMIZE_RELOAD_ADDRESS as it usually calls
push_reload from reload pass code. LEGITIMIZE_RELOAD_ADDRESS
diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index 30d088afbca..998e82be54f 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -3517,21 +3517,8 @@ process_address_1 (int nop, bool check_only_p,
*ad.inner = gen_rtx_LO_SUM (Pmode, new_reg, addr);
if (!valid_address_p (op, , cn))
{
- /* Try to put lo_sum into register. */
- insn = emit_insn (gen_rtx_SET
- (new_reg,
-gen_rtx_LO_SUM (Pmode, new_reg,
addr)));
- code = recog_memoized (insn);
- if (code >= 0)
- {
- *ad.inner = new_reg;
- if (!valid_address_p (op, , cn))
- {
- *ad.inner = addr;
- code = -1;
- }
- }
-
+ *ad.inner = addr;
+ code = -1;
}
}
if (code < 0)
The patch was successfully tested on x86-64/ppc64 under Linux.
[Bug c++/104392] Unexpected Narrowing Warning when spaceship comparison of unsigned bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104392 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=94058 --- Comment #2 from Andrew Pinski --- Very much related to PR 94058.
[Bug c++/104392] Unexpected Narrowing Warning when spaceship comparison of unsigned bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104392 --- Comment #1 from Andrew Pinski --- clang rejects this too: :9:12: error: argument to 'operator<=>' cannot be narrowed from type 'unsigned int' to 'int' return left.a <=> right.a; ^ :9:23: error: argument to 'operator<=>' cannot be narrowed from type 'unsigned int' to 'int' return left.a <=> right.a; ^
[Bug c++/104386] no_unique_address causes invalid member alignment of pod struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104386 --- Comment #1 from Andrew Pinski --- Hmm: https://github.com/itanium-cxx-abi/cxx-abi/issues/108
[Bug tree-optimization/101515] [11/12 Regression] ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128 since r11-6729-gadb520606ce3e1e1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101515 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #4 from qinzhao at gcc dot gnu.org --- the latest gcc12 failed with the same issue.
[Bug fortran/104391] [9/10/11 Regression] bind(C) and allocatable or pointer attribute don't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104391 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5 Keywords||needs-bisection, wrong-code Summary|Gfortran [9,10,11] |[9/10/11 Regression] |regression with bind(C) and |bind(C) and allocatable or |allocatable or pointer |pointer attribute don't |attribute |work
[Bug rtl-optimization/104387] aarch64: Redundant SXTH for “bag of bits” moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104387 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-02-04 Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81357, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=95650, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=96031 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed, I thought I had saw an dup of this bug before.
[Bug tree-optimization/97747] [9/10/11/12 Regression] missed combine opt with logical ops after zero extended load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97747 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug tree-optimization/97747] [9/10/11/12 Regression] missed combine opt with logical ops after zero extended load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97747 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-02-04 Ever confirmed|0 |1 Known to fail||8.2.0 Summary|missed combine opt with |[9/10/11/12 Regression] |logical ops after zero |missed combine opt with |extended load |logical ops after zero ||extended load Known to work||7.5.0 Status|UNCONFIRMED |ASSIGNED Component|rtl-optimization|tree-optimization --- Comment #1 from Andrew Pinski --- Mine for GCC 13, bitfield lowering. Note the store merging pass also messes up and creates: _5 = _4 & 250; _6 = _5 | 5; Which can be optimized to just: _6 = _4 | 5; I might look at store merging first. Note I think this might be a regression in code generation (store merging caused the regressions). GCC 7.5.0 produced: ldr r2, .L3 ldrbr3, [r2]@ zero_extendqisi2 orr r3, r3, #5 strbr3, [r2] bx lr While GCC 8.2.0 produced: ldr r2, .L3 ldrbr3, [r2]@ zero_extendqisi2 bic r3, r3, #5 orr r3, r3, #5 strbr3, [r2] bx lr
[Bug rtl-optimization/60749] combine is overly cautious when operating on volatile memory references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60749 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-02-04 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/104392] New: Unexpected Narrowing Warning when spaceship comparison of unsigned bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104392
Bug ID: 104392
Summary: Unexpected Narrowing Warning when spaceship comparison
of unsigned bit field
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bieri.hp at gmail dot com
Target Milestone: ---
struct A
{
unsigned int a:5;
};
constexpr std::strong_ordering operator<=>(const A & left, const A & right )
{
return left.a <=> right.a;
}
results in the unexpected warnings
: In function 'constexpr std::strong_ordering operator<=>(const A&,
const A&)':
:15:21: warning: narrowing conversion of 'left.A::a' from 'const
unsigned int' to 'int' [-Wnarrowing]
15 | return left.a <=> right.a;
|~^
:15:33: warning: narrowing conversion of 'right.A::a' from 'const
unsigned int' to 'int' [-Wnarrowing]
15 | return left.a <=> right.a;
| ~~^
it seems to choose the int comparison operator although the type is unsigned
[Bug fortran/104391] New: Gfortran 9 regression with bind(C) and allocatable or pointer attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104391 Bug ID: 104391 Summary: Gfortran 9 regression with bind(C) and allocatable or pointer attribute Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: michael at scivision dot dev Target Milestone: --- The `bind(C)` on a procedure appears to break `pointer` and `allocatable` attributes of a variable with regard to index start. Specifically, on exiting a procedure with `bind(c)`, the variable(s) have their indices shifted to zero-based. example that works with GCC <= 8.5 and GCC 12 (broken for GCC 9, 10, 11). ``` program test_bounds use iso_fortran_env, only : error_unit implicit none real, allocatable :: a(:) integer :: L1,L2, U1,U2 allocate(a(1:2)) L1 = lbound(a,1) U1 = ubound(a,1) call c_bounder(a) L2 = lbound(a,1) U2 = ubound(a,1) if (L1 /= L2 .or. U1 /= U2) then write(error_unit, '(a,2i2,a,2i2)') 'FAIL: bounds changed before/after lower:', L1,L2, " upper: ", U1,U2 error stop endif print '(a)', "bounds check OK" contains subroutine c_bounder(a) bind(c) real, intent(inout) :: a(:) end subroutine c_bounder end program ```
[Bug ipa/102059] Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059 Peter Bergner changed: What|Removed |Added Known to fail||12.0 Known to work|12.0| --- Comment #29 from Peter Bergner --- Since this is still broken when using trunk, I'm moving GCC 12.0 from Known to Work back to Known to Fail.
[Bug tree-optimization/104389] [10/11/12 Regression] HUGE_VAL * 0.0 is no longer a NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Jakub Jelinek --- Created attachment 52353 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52353=edit gcc12-pr104389.patch Untested fix.
[Bug target/100808] PPC: ISA 3.1 builtin documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808 Bill Schmidt changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Bill Schmidt --- Ugh, bad commit message... but fixed.
[Bug ipa/102059] Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059 --- Comment #28 from Dan Horák --- comment #27 matches our experience in Fedora, still a build issue in Eigen with gcc12 and LTO
[Bug target/100808] PPC: ISA 3.1 builtin documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808 --- Comment #5 from CVS Commits --- The master branch has been updated by William Schmidt : https://gcc.gnu.org/g:8cb748a31cd8c7ac9c88b6abc38ce077dd462a7a commit r12-7060-g8cb748a31cd8c7ac9c88b6abc38ce077dd462a7a Author: Bill Schmidt Date: Fri Feb 4 13:26:44 2022 -0600 rs6000: Clean up ISA 3.1 documentation [PR100808] Due to a pasto error in the documentation, vec_replace_unaligned was implemented with the same function prototypes as vec_replace_elt. It was intended that vec_replace_unaligned always specify output vectors as having type vector unsigned char, to emphasize that elements are potentially misaligned by this built-in function. This patch corrects the misimplementation. 2022-02-04 Bill Schmidt gcc/ PR target/100808 * doc/extend.texi (Basic PowerPC Built-in Functions Available on ISA 3.1): Provide consistent type names. Remove unnecessary semicolons. Fix bad line breaks.
[Bug c++/104390] New: Tree check ICE for valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104390
Bug ID: 104390
Summary: Tree check ICE for valid code
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: colavitam at gmail dot com
Target Milestone: ---
The following code produces an ICE (-std=c++17):
template
struct A {};
struct B {
long v;
};
template
struct C {
template
static void f(const A& src) {}
};
void g() {
C::f<::v>({});
}
---
: In function 'void g()':
:15:25: internal compiler error: tree check: accessed elt 2 of
'tree_vec' with 0 elts in tsubst_pack_expansion, at cp/pt.cc:13125
15 | C::f<::v>({});
| ^~~~
[Bug c/104389] [10/11/12 Regression] HUGE_VAL * 0.0 is no longer a NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389 --- Comment #4 from Jakub Jelinek --- Ah, of course it isn't NAN, it is infinity, but +-Inf * 0 is still NAN.
[Bug c/104389] [10/11/12 Regression] HUGE_VAL * 0.0 is no longer a NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389
--- Comment #3 from Jakub Jelinek ---
Changing it to
double
foo (void)
{
double a = __builtin_huge_val ();
return a * 0.0;
}
shows ccp1 applies
/* Maybe fold x * 0 to 0. The expressions aren't the same
when x is NaN, since x * 0 is also NaN. Nor are they the
same in modes with signed zeros, since multiplying a
negative value by 0 gives -0, not +0. */
(simplify
(mult @0 real_zerop@1)
(if (!tree_expr_maybe_nan_p (@0)
&& !tree_expr_maybe_real_minus_zero_p (@0)
&& !tree_expr_maybe_real_minus_zero_p (@1))
@1))
So the question is why tree_expr_maybe_nan_p isn't true.
[Bug fortran/104311] [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104311 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug target/104371] [x86] Failure to use optimize pxor+pcmpeqb+pmovmskb+cmp 0xFFFF pattern to ptest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104371 --- Comment #2 from Gabriel Ravier --- Although I agree the pattern doesn't seem that useful at first, I've seen it crop up in several places, such as: - in pixman: https://github.com/servo/pixman/blob/master/pixman/pixman-sse2.c on line 181 - in an simd mandelbrot implementation: https://github.com/huonw/mandel-simd/blob/master/mandel_sse2.c on line 47 - in this article: http://0x80.pl/notesen/2021-02-02-all-bytes-in-reg-are-equal.html - in boost::uuid (although this one will detect if compiling on a platform with SSE4.1): https://github.com/boostorg/uuid/blob/develop/include/boost/uuid/detail/uuid_x86.ipp - in this other article: https://mischasan.wordpress.com/2011/11/09/the-generic-sse2-loop/ - in a research paper's accompanying github repo: https://github.com/GameTechDev/MaskedOcclusionCulling/blob/master/MaskedOcclusionCulling.cpp on line 333 - in ClickHouse: https://clickhouse.com/codebrowser/html_report/ClickHouse/src/Common/memcmpSmall.h.html on line 241 And this is just what I found in a few minutes, so I would personally think there are many more occurences of that pattern.
[Bug fortran/104311] [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104311 --- Comment #12 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2953e3d1b9b36b441f5a33d696760ed56742ee1e commit r9-9939-g2953e3d1b9b36b441f5a33d696760ed56742ee1e Author: Harald Anlauf Date: Tue Feb 1 23:33:24 2022 +0100 Fortran: reject simplifying TRANSFER for MOLD with storage size 0 gcc/fortran/ChangeLog: PR fortran/104311 * check.c (gfc_calculate_transfer_sizes): Checks for case when storage size of SOURCE is greater than zero while the storage size of MOLD is zero and MOLD is an array shall not depend on SIZE. gcc/testsuite/ChangeLog: PR fortran/104311 * gfortran.dg/transfer_simplify_15.f90: New test. (cherry picked from commit 4e4252db0348a7274663a892c3a96d3ed7702aff)
[Bug c/104389] [10/11/12 Regression] HUGE_VAL * 0.0 is no longer a NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2022-02-04
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek ---
double foo (void) { return __builtin_huge_val () * 0.0; }
folds since r12-6959 to return 0.0 instead of return NAN; already in original
dump.
[Bug fortran/104311] [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104311 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:837ad03ad4a95629a0d17108f5258568bebbf13f commit r10-10437-g837ad03ad4a95629a0d17108f5258568bebbf13f Author: Harald Anlauf Date: Tue Feb 1 23:33:24 2022 +0100 Fortran: reject simplifying TRANSFER for MOLD with storage size 0 gcc/fortran/ChangeLog: PR fortran/104311 * check.c (gfc_calculate_transfer_sizes): Checks for case when storage size of SOURCE is greater than zero while the storage size of MOLD is zero and MOLD is an array shall not depend on SIZE. gcc/testsuite/ChangeLog: PR fortran/104311 * gfortran.dg/transfer_simplify_15.f90: New test. (cherry picked from commit 4e4252db0348a7274663a892c3a96d3ed7702aff)
[Bug fortran/104311] [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104311 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:7a0fab4bddce549380b2713a910127332a091e19 commit r11-9539-g7a0fab4bddce549380b2713a910127332a091e19 Author: Harald Anlauf Date: Tue Feb 1 23:33:24 2022 +0100 Fortran: reject simplifying TRANSFER for MOLD with storage size 0 gcc/fortran/ChangeLog: PR fortran/104311 * check.c (gfc_calculate_transfer_sizes): Checks for case when storage size of SOURCE is greater than zero while the storage size of MOLD is zero and MOLD is an array shall not depend on SIZE. gcc/testsuite/ChangeLog: PR fortran/104311 * gfortran.dg/transfer_simplify_15.f90: New test. (cherry picked from commit 4e4252db0348a7274663a892c3a96d3ed7702aff)
[Bug c/104389] [10/11/12 Regression] HUGE_VAL * 0.0 is no longer a NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Priority|P3 |P1 Target Milestone|--- |10.4 Summary|HUGE_VAL * 0.0 is no longer |[10/11/12 Regression] |a NaN |HUGE_VAL * 0.0 is no longer ||a NaN --- Comment #1 from Jakub Jelinek --- Started with r12-6959-g34afa19d29c5bf0b0f504e4d0aca4e9a8bc82c5c which has been backported to 10/11 as well.
[Bug c/104389] New: HUGE_VAL * 0.0 is no longer a NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389
Bug ID: 104389
Summary: HUGE_VAL * 0.0 is no longer a NaN
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vstinner at redhat dot com
Target Milestone: ---
Created attachment 52352
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52352=edit
Reproducer: huge_val_0_nan.c
The Python project uses "HUGE_VAL * 0" to get a Not-a-Number (NaN) double
value. Pseudo-code:
#define Py_NAN (Py_HUGE_VAL * 0.)
double my_nan(void)
{ return Py_NAN; }
Until Fedora gcc-12.0.1-0.4.fc36.x86_64
(03182470d2d2b272f06500184acab6b8ed78d8ad), it worked well.
With Fedora gcc-12.0.1-0.5.fc36.x86_64
(fb6057a2be99e071993fb54a5d338ab0febba8ff), my_nan() now returns zero (0.0).
Try attached huge_val_0_nan.c.
gcc-12.0.1-0.5.fc36.x86_64 output:
---
(1) Compute HUGE_VAL * 0 in the C compiler
isnan? 0
bytes: [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]
(2) Compute HUGE_VAL * 0 at runtime
isnan? 1
bytes: [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xfff8, 0x]
---
gcc-11.2.1-7.fc35.x86_64 output:
---
(1) Compute HUGE_VAL * 0 in the C compiler
isnan? 1
bytes: [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xfff8, 0x7f]
(2) Compute HUGE_VAL * 0 at runtime
isnan? 1
bytes: [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xfff8, 0x]
---
In Python, Py_NAN is defined as "#define Py_NAN (Py_HUGE_VAL * 0.)" at:
https://github.com/python/cpython/blob/bf95ff91f2c1fc5a57190491f9ccdc63458b089e/Include/pymath.h#L60
FYI diff of the Fedora package between -4 and -5, the most important part if
the Git commit which changed ;-)
https://src.fedoraproject.org/rpms/gcc/c/398138b5f3809856b98eb4241b3c9f70da3fce9b?branch=rawhide
[Bug ipa/102059] Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059 pc at gcc dot gnu.org changed: What|Removed |Added CC||pc at gcc dot gnu.org --- Comment #27 from pc at gcc dot gnu.org --- There was a commit related to this bug, but it is still in ASSIGNED state, so I'm not sure if this was to be considered "fixed", but... Chip discovered that, with a build of today's trunk, the original test case, and at least gcc.target/powerpc/pr102059-1.c still fail (I didn't try others), and it seems to be related to the presence of "-flto": -- $ gcc -c gcc/testsuite/gcc.target/powerpc/pr102059-1.c -O2 -mcpu=power8 -Wno-attributes -flto gcc/testsuite/gcc.target/powerpc/pr102059-1.c: In function 'bar': gcc/testsuite/gcc.target/powerpc/pr102059-1.c:8:1: error: inlining failed in call to 'always_inline' 'foo': target specific option mismatch 8 | foo (int *b) | ^~~ gcc/testsuite/gcc.target/powerpc/pr102059-1.c:18:8: note: called from here 18 | *a = foo (a); |^~~ $ gcc -c gcc/testsuite/gcc.target/powerpc/pr102059-1.c -O2 -mcpu=power8 -Wno-attributes $ -- The testcases included with the commit do not use "-flto", so these tests are PASSing.
[Bug c++/104388] New: Request: A builtin to mark an object as invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104388 Bug ID: 104388 Summary: Request: A builtin to mark an object as invalid Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: Darrell.Wright at gmail dot com Target Milestone: --- Would it be possible to get a builtin that marks an object as invalid until it is overwritten and make it IF if the object is used other than destruction, assignment or taking its address/ref. I am naive on the compiler internals here, but this could allow for the safety of destructive moves without the changes to the object model around destruction ordering.
[Bug fortran/103828] Type generated for CHARACTER(C_CHAR), VALUE arguments is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103828 --- Comment #8 from Francois-Xavier Coudert --- I'm not sure if it really counts as an ABI change, given that I know no existing target where this resulted in an actual change in the argument passing convention. (i.e., where that test actually failed).
[Bug rtl-optimization/104387] New: aarch64: Redundant SXTH for “bag of bits” moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104387
Bug ID: 104387
Summary: aarch64: Redundant SXTH for “bag of bits” moves
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
This PR is about another case in which we generate a redundant SXTH.
Specifically:
void f(short *x, short y)
{
x[0] = y;
x[1] = y;
}
generates:
sxthw1, w1
strhw1, [x0]
strhw1, [x0, 2]
even though the RTL makes it clear that the upper 16 bits of the
promoted “y” are unused.
This is related to PR64537, but I think it's worth keeping as a
separate PR since the fix isn't necessarily the same.
[Bug c++/104386] New: no_unique_address causes invalid member alignment of pod struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104386
Bug ID: 104386
Summary: no_unique_address causes invalid member alignment of
pod struct
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at ebasoft dot com.pl
Target Milestone: ---
struct base
{ [[no_unique_address]]
uint32_t x; std::byte v;
};
struct foo : public base
{ std::byte z; };
gcc sizeof(foo) == 8 https://godbolt.org/z/G4Mo3PdKT
clang sizeof(foo) == 12 https://godbolt.org/z/bdzvaMn9c
As I was told it is gcc bug
https://www.reddit.com/r/cpp/comments/sjx2mk/no_unique_addres_where_can_in_c_standard_instead/
[orbital1337]"Your class base is a POD but its not a POD for the purpose of
layout (since it has potentially overlapping data members). Thus the Itanium
ABI specifies that it's size without padding (dsize) should be set to its size
with padding (sizeof). The first datamember of your class foo is put at
dsize(base). clang does the right thing and puts it at an offset of 8 bytes
whereas gcc ignores that one line of the specification and puts it at an offset
of 5 bytes instead."
[Bug target/104380] -D_FORTIFY_SOURCE -mabi=ieeelongdouble -std=c* wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104380 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug target/104380] -D_FORTIFY_SOURCE -mabi=ieeelongdouble -std=c* wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104380 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8d6fffc4bcd4afa0beb0efad4f3b95394aa15618 commit r12-7059-g8d6fffc4bcd4afa0beb0efad4f3b95394aa15618 Author: Jakub Jelinek Date: Fri Feb 4 18:30:59 2022 +0100 rs6000: Fix up -D_FORTIFY_SOURCE* with -mabi=ieeelongdouble [PR104380] The following testcase FAILs when configured with --with-long-double-format=ieee . Only happens in the -std=c* modes, not the GNU modes; while the glibc headers have __asm redirects of vsnprintf and __vsnprinf_chk to __vsnprintfieee128 and __vsnprintf_chkieee128, the vsnprintf fortification extern inline gnu_inline always_inline wrapper calls __builtin_vsnprintf_chk and we actually emit a call to __vsnprinf_chk (i.e. with IBM extended long double) instead of __vsnprintf_chkieee128. rs6000_mangle_decl_assembler_name already had cases for *printf and *scanf, so this just adds another case for *printf_chk. *scanf_chk doesn't exist. __ prefixing isn't done because *printf_chk already starts with __. 2022-02-04 Jakub Jelinek PR target/104380 * config/rs6000/rs6000.cc (rs6000_mangle_decl_assembler_name): Also adjust mangling of __builtin*printf_chk. * gcc.dg/pr104380.c: New test.
[Bug target/100808] PPC: ISA 3.1 builtin documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808 Bill Schmidt changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-02-04 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot gnu.org --- Comment #4 from Bill Schmidt --- Confirmed, I'll clean it up.
[Bug tree-optimization/104356] [12 Regression] divide by zero trap incorrectly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356 --- Comment #47 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:1f722e35ab3805de6eeace770508a9085944e93e commit r12-7058-g1f722e35ab3805de6eeace770508a9085944e93e Author: Eric Botcazou Date: Fri Feb 4 17:41:55 2022 +0100 Add optmization testcase for incorrect optimization in Ada gcc/testsuite/ PR tree-optimization/104356 * gnat.dg/opt97.adb: New test.
[Bug analyzer/101081] analyzer testsuite failures seen with new glibc due to malloc attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101081 Joel Teichroeb changed: What|Removed |Added CC||joel at teichroeb dot net --- Comment #1 from Joel Teichroeb --- I've submitted a patch to the mailing list which fixes this issue. https://gcc.gnu.org/pipermail/gcc-patches/2022-February/589886.html
[Bug libgomp/104385] New: Segmentation fault when using nested dependent tasks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104385 Bug ID: 104385 Summary: Segmentation fault when using nested dependent tasks Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: wacrenier at labri dot fr CC: jakub at gcc dot gnu.org Target Milestone: --- Created attachment 52351 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52351=edit simple openmp code that leads to a segfault Hello, The attached code leads to SIGSEV when executing. Best regards, P.A. Wacrenier Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin21/11.2.0/lto-wrapper Target: x86_64-apple-darwin21 Configured with: /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc11/gcc11/work/gcc-11.2.0/configure --prefix=/opt/local --build=x86_64-apple-darwin21 --enable-languages=c,c++,objc,obj-c++,lto,fortran,jit --libdir=/opt/local/lib/gcc11 --includedir=/opt/local/include/gcc11 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-11 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-11 --with-gxx-include-dir=/opt/local/include/gcc11/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-build-config=bootstrap-debug --with-bugurl=https://trac.macports.org/newticket --enable-host-shared --disable-tls --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-pkgversion='MacPorts gcc11 11.2.0_3' --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.2.0 (MacPorts gcc11 11.2.0_3) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mmacosx-version-min=12.1.0' '-asm_macosx_version_min=12.1' '-mtune=core2' '-dumpdir' 'a-' /opt/local/libexec/gcc/x86_64-apple-darwin21/11.2.0/cc1 -E -quiet -v -D__DYNAMIC__ ici.c -fPIC -mmacosx-version-min=12.1.0 -mtune=core2 -fopenmp -fpch-preprocess -o a-ici.i ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/opt/local/include" ignoring nonexistent directory "/opt/local/lib/gcc11/gcc/x86_64-apple-darwin21/11.2.0/../../../../../x86_64-apple-darwin21/include" ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/Library/Frameworks" #include "..." search starts here: #include <...> search starts here: /opt/local/lib/gcc11/gcc/x86_64-apple-darwin21/11.2.0/include /opt/local/lib/gcc11/gcc/x86_64-apple-darwin21/11.2.0/include-fixed /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mmacosx-version-min=12.1.0' '-asm_macosx_version_min=12.1' '-mtune=core2' '-dumpdir' 'a-' /opt/local/libexec/gcc/x86_64-apple-darwin21/11.2.0/cc1 -fpreprocessed a-ici.i -fPIC -quiet -dumpdir a- -dumpbase ici.c -dumpbase-ext .c -mmacosx-version-min=12.1.0 -mtune=core2 -version -fopenmp -o a-ici.s GNU C17 (MacPorts gcc11 11.2.0_3) version 11.2.0 (x86_64-apple-darwin21) compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C17 (MacPorts gcc11 11.2.0_3) version 11.2.0 (x86_64-apple-darwin21) compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: f32d7bc7d3a774eacf5c9650a419dd5f COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mmacosx-version-min=12.1.0' '-mtune=core2' '-dumpdir' 'a-' /opt/local/bin/as -arch x86_64 -v -force_cpusubtype_ALL -mmacosx-version-min=12.1 -o a-ici.o a-ici.s Apple clang version 13.0.0 (clang-1300.0.29.30) Target: x86_64-apple-darwin21.2.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1as -triple x86_64-apple-macosx12.1.0 -filetype obj -main-file-name a-ici.s -target-cpu penryn -fdebug-compilation-dir /tmp -dwarf-debug-producer "Apple clang version 13.0.0 (clang-1300.0.29.30)" -dwarf-version=4 -mrelocation-model pic --mrelax-relocations -mllvm -disable-aligned-alloc-awareness=1 -mllvm -enable-dse-memoryssa=0 -o a-ici.o a-ici.s
[Bug tree-optimization/104356] [12 Regression] divide by zero trap incorrectly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356 --- Comment #46 from Eric Botcazou --- > I meant something like: > with System.Unsigned_Types; use System.Unsigned_Types; > > function F (X, Y : Unsigned) return Unsigned is > Z : Unsigned; > begin > if X >=2 then > return 0; > end if; > Z := Y; > if X = 1 then > Z := Y + 4; > end if; > return Z / X; > end; > and there evrp does with -O2 -gnatp optimize away the division. My bad. I forgot that -gnatp now disables -fnon-call-exceptions too (in order to make the mode mimic C++) so the testcase must be written: with System.Unsigned_Types; use System.Unsigned_Types; function Opt97 (X, Y : Unsigned) return Unsigned is pragma Suppress (All_Checks); Z : Unsigned; begin if X >= 2 then return 0; end if; Z := Y; if X = 1 then Z := Y + 4; end if; return Z / X; end; and there is still the divide at -O2 and above on mainline.
[Bug target/50883] [ARM] Suboptimal optimization for small structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883
--- Comment #18 from Sebastian Huber ---
clang 11 produces this code for the attached test case:
clang -O2 -S -o - pr50883.c -target arm
clang-11.0: warning: unknown platform, assuming -mfloat-abi=soft
clang-11.0: warning: unknown platform, assuming -mfloat-abi=soft
.text
.syntax unified
.eabi_attribute 67, "2.09" @ Tag_conformance
.cpuarm7tdmi
.eabi_attribute 6, 2@ Tag_CPU_arch
.eabi_attribute 8, 1@ Tag_ARM_ISA_use
.eabi_attribute 9, 1@ Tag_THUMB_ISA_use
.eabi_attribute 34, 0 @ Tag_CPU_unaligned_access
.eabi_attribute 17, 1 @ Tag_ABI_PCS_GOT_use
.eabi_attribute 20, 1 @ Tag_ABI_FP_denormal
.eabi_attribute 21, 0 @ Tag_ABI_FP_exceptions
.eabi_attribute 23, 3 @ Tag_ABI_FP_number_model
.eabi_attribute 24, 1 @ Tag_ABI_align_needed
.eabi_attribute 25, 1 @ Tag_ABI_align_preserved
.eabi_attribute 38, 1 @ Tag_ABI_FP_16bit_format
.eabi_attribute 18, 4 @ Tag_ABI_PCS_wchar_t
.eabi_attribute 26, 2 @ Tag_ABI_enum_size
.eabi_attribute 14, 0 @ Tag_ABI_PCS_R9_use
.file "pr50883.c"
.globl f @ -- Begin function f
.p2align2
.type f,%function
.code 32 @ @f
f:
.fnstart
@ %bb.0:
mov r0, r1
bx lr
.Lfunc_end0:
.size f, .Lfunc_end0-f
.cantunwind
.fnend
@ -- End function
.globl g @ -- Begin function g
.p2align2
.type g,%function
.code 32 @ @g
g:
.fnstart
@ %bb.0:
mov r0, r1
bx lr
.Lfunc_end1:
.size g, .Lfunc_end1-g
.cantunwind
.fnend
@ -- End function
.globl h @ -- Begin function h
.p2align2
.type h,%function
.code 32 @ @h
h:
.fnstart
@ %bb.0:
ldr r1, .LCPI2_0
ldm r1, {r0, r1}
b j
.p2align2
@ %bb.1:
.LCPI2_0:
.long ss
.Lfunc_end2:
.size h, .Lfunc_end2-h
.cantunwind
.fnend
@ -- End function
.globl i @ -- Begin function i
.p2align2
.type i,%function
.code 32 @ @i
i:
.fnstart
@ %bb.0:
ldr r1, .LCPI3_0
ldm r1, {r0, r1}
b k
.p2align2
@ %bb.1:
.LCPI3_0:
.long tt
.Lfunc_end3:
.size i, .Lfunc_end3-i
.cantunwind
.fnend
@ -- End function
.ident "clang version 11.0.1"
.section".note.GNU-stack","",%progbits
.addrsig
[Bug c++/104384] New: Heap corruption when initializing struct with co_await
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104384
Bug ID: 104384
Summary: Heap corruption when initializing struct with co_await
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: max at duempel dot org
Target Milestone: ---
Created attachment 52350
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52350=edit
Crashing demo program
When initializing struct members, and one struct member gets initialized with a
co_awaited values, the following struct members can be corrupted.
Tested with:
- gcc version 10.2.1 20210110 (Debian 10.2.1-6)
- gcc version 11.2.0 (Debian 11.2.0-16)
- gcc version 12.0.1 20220126 (experimental) [master r12-6872-gf3e6ef7d873]
(Debian 12-20220126-1)
clang ("Debian clang version 11.0.1-2") is fine.
My demo program crashes like this:
$ g++ -o cocrash2 cocrash2.cxx -fcoroutines -std=c++20 && valgrind ./cocrash2
==1947496== Memcheck, a memory error detector
==1947496== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1947496== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==1947496== Command: ./cocrash2
==1947496==
==1947496== Invalid free() / delete / delete[] / realloc()
==1947496==at 0x484008B: operator delete(void*, unsigned long) (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==1947496==by 0x10C438: __gnu_cxx::new_allocator::deallocate(char*,
unsigned long) (in /tmp/cocrash2)
==1947496==by 0x10C0EC: std::allocator_traits
>::deallocate(std::allocator&, char*, unsigned long) (in /tmp/cocrash2)
==1947496==by 0x10BE29: std::__cxx11::basic_string, std::allocator >::_M_destroy(unsigned long) (in
/tmp/cocrash2)
==1947496==by 0x10B973: std::__cxx11::basic_string, std::allocator >::_M_dispose() (in /tmp/cocrash2)
==1947496==by 0x10B167: std::__cxx11::basic_string, std::allocator >::~basic_string() (in
/tmp/cocrash2)
==1947496==by 0x10AE5F: Foo::~Foo() (in /tmp/cocrash2)
==1947496==by 0x10AA61: main (in /tmp/cocrash2)
==1947496== Address 0x4db6d20 is 160 bytes inside a block of size 200 alloc'd
==1947496==at 0x483EDEF: operator new(unsigned long) (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==1947496==by 0x10A593: MakeFoo(bool) (in /tmp/cocrash2)
==1947496==by 0x10A9F3: main (in /tmp/cocrash2)
==1947496==
[Bug c++/90809] -finstrument-functions-exclude-function-list mishandles comma escaping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90809 Thomas De Schampheleire changed: What|Removed |Added CC||patrickdepinguin at gmail dot com --- Comment #3 from Thomas De Schampheleire --- A fix for this issue seems to have been applied as (git) commit efab3e3a7326ad503532955ccd31f953851e388a. This bug can thus be closed.
[Bug c++/90816] -finstrument-functions-exclude-function-list improperly handles namespace/class definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90816 Thomas De Schampheleire changed: What|Removed |Added CC||patrickdepinguin at gmail dot com --- Comment #3 from Thomas De Schampheleire --- A fix for this issue seems to have been applied as (git) commit efab3e3a7326ad503532955ccd31f953851e388a. This bug can thus be closed.
[Bug c++/101783] unnecessary error when top level cv qualifier is dropped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101783 Patrick Palka changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #12 from Patrick Palka --- *** Bug 69778 has been marked as a duplicate of this bug. ***
[Bug c++/69778] Bogus "qualifiers cannot be applied" error with redundant (but legal) 'typename'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69778 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Patrick Palka --- Fixed for GCC 12 by r12-4051 *** This bug has been marked as a duplicate of bug 101783 ***
[Bug c++/80951] Deducing noexcept only works when also deducing something else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80951 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug middle-end/103642] [12 Regression] ICE in lower_omp_target: omp-low.c:12977 (fold_convert_loc) for omp target map(from: t.s->a[:N]) since r12-5835-g0ab29cf0bb68960c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103642 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Tobias Burnus --- In my understanding, this patch is now FIXED. In particular, also the longer testcases works. Thanks ChungLin for fixing it!
[Bug c++/99273] List initialization prefers initializer_list a little too strongly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99273 Patrick Palka changed: What|Removed |Added CC||fchelnokov at gmail dot com --- Comment #2 from Patrick Palka --- *** Bug 104383 has been marked as a duplicate of this bug. ***
[Bug c++/104383] User-defined conversion is preferred over standard-one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104383 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- dup, I think *** This bug has been marked as a duplicate of bug 99273 ***
[Bug c++/104383] New: User-defined conversion is preferred over standard-one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104383
Bug ID: 104383
Summary: User-defined conversion is preferred over standard-one
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This example
```
#include
struct IntSimilar { constexpr IntSimilar(int) {} };
constexpr int f(int) { return 1; }
constexpr int f(std::initializer_list) { return 2; }
int main() {
static_assert( f({0}) == 1 );
}
```
is accepted by Clang and MSVC. It looks right according to the standard saying
"a standard conversion sequence is a better conversion sequence than a
user-defined conversion sequence"
https://timsong-cpp.github.io/cppwp/n4861/over.ics.rank#2.1
But GCC selects the other overload. Demo: https://gcc.godbolt.org/z/3Ghvn98xr
[Bug tree-optimization/104356] [12 Regression] divide by zero trap incorrectly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356 --- Comment #45 from Andrew Macleod --- > > That said, range-ops, from say > > [0,1] = [0,2] / y; > > may _not_ reason that 'y' is not 0 when non-call EH. That is, you need to be > careful on the reverse ops but I think not on the forward ops. We do not currently try to figure anything via reverse ops for general divide operations. For exact_divide we try if Y is a non-zero singleton, but that's about it.
[Bug tree-optimization/100499] [9/10/11 Regression] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 Richard Biener changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10/11 Regression] |Different results with |Different results with |-fpeel-loops|-fpeel-loops |-ftree-loop-vectorize |-ftree-loop-vectorize |options |options Known to work||12.0 --- Comment #41 from Richard Biener --- This series, also g:24c72fb0eedfe7c67f9b15aa31b474a999cc4723, fixes the known cases of miscompiles. Thanks for reporting!
[Bug tree-optimization/100499] [9/10/11/12 Regression] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #40 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:0898049ad9bf6c46e510b18aaafca4946802749f commit r12-7052-g0898049ad9bf6c46e510b18aaafca4946802749f Author: Richard Biener Date: Wed Jan 26 09:35:57 2022 +0100 tree-optimization/100499 - niter analysis and multiple_of_p niter analysis uses multiple_of_p which currently assumes operations like MULT_EXPR do not wrap. We've got to rely on this for optimizing size expressions like those in DECL_SIZE and those generally use unsigned arithmetic with no indication that they are not expected to wrap. To preserve that the following adds a parameter to multiple_of_p, defaulted to true, indicating that the TOP expression is not expected to wrap for outer computations in TYPE. This mostly follows a patch proposed by Bin last year with the conversion behavior added. Applying to all users the new effect is that upon type conversions in the TOP expression the behavior will switch to honor TYPE_OVERFLOW_UNDEFINED for the converted sub-expressions. The patch also changes the occurance in niter analysis that we know is problematic and we have testcases for to pass false to multiple_of_p. The patch also contains a change to the PR72817 fix from Bin to avoid regressing gcc.dg/tree-ssa/loop-42.c. The intent for stage1 is to introduce a size_multiple_of_p and internalize the added parameter so all multiple_of_p users will honor TYPE_OVERFLOW_UNDEFINED and users dealing with size expressions need to be switched to size_multiple_of_p. 2022-01-26 Richard Biener PR tree-optimization/100499 * fold-const.h (multiple_of_p): Add nowrap parameter, defaulted to true. * fold-const.cc (multiple_of_p): Likewise. Honor it for MULT_EXPR, PLUS_EXPR and MINUS_EXPR and pass it along, switching to false for conversions. * tree-ssa-loop-niter.cc (number_of_iterations_ne): Do not claim the outermost expression does not wrap when calling multiple_of_p. Refactor the check done to check the original IV, avoiding a bias that might wrap. * gcc.dg/torture/pr100499-1.c: New testcase. * gcc.dg/torture/pr100499-2.c: Likewise. * gcc.dg/torture/pr100499-3.c: Likewise. Co-authored-by: Bin Cheng
[Bug c++/104379] [9/10/11/12 Regression] -Wshadow warning given three times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379 --- Comment #6 from Richard Biener --- Oh, btw - we'd also warn N times for an uninitialized variable use for example unless the location-based diagnostic suppression gets this right now - tree or GIMPLE no-warning flags definitely don't.
[Bug c++/104379] [9/10/11/12 Regression] -Wshadow warning given three times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379
--- Comment #5 from rguenther at suse dot de ---
On Fri, 4 Feb 2022, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379
>
> --- Comment #4 from Jonathan Wakely ---
> So you can imagine what happens if you combine constructor clones with
> templates! :-D
>
> template
> struct S
> {
> int i;
> S(int i) { (void) i; }
> };
>
> S i(1);
> S j(1);
>
> whe!
It's just really insisting on you to fix it! ;) Somehow it feels
the shadow stuff runs at the wrong place - it should run at _parsing_,
not at instantiation [of ctor/dtor clones].
[Bug rtl-optimization/103006] [9/10/11/12 Regression] wrong code at -O1 or -O2 on x86_64-linux-gnu by r7-7101
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103006 --- Comment #14 from Richard Biener --- There's an interesting case, a = BIRTH loop: b = DEATH a = DEATH b = BIRTH goto loop; where we end up having both a and b in the live-in set at the loop label but a is removed before we see the BIRTH of b which is where we add conflicts based on the current set of active vars. In the case I'm running into this I have tail-recursion do a = BIRTH b = BIRTH ... a = DEATH b = DEATH into loop: a = BIRTH b = BIRTH goto loop; a = DEATH b = DEATH leading to a similar issue. The issue above can for example arise from loop rotation. In all cases live from backedges confuse the "optimization" done to only record conflicts when we add a var to the live set (and it is not already set). The previous code had /* If this is the first real instruction in this BB we need to add conflicts for everything live at this point now. Unlike classical liveness for named objects we can't rely on seeing a def/use of the names we're interested in. There might merely be indirect loads/stores. We'd not add any conflicts for such partitions. */ and the easiest is to do the same here (we don't see the backedge "use"), but we could possibly improve by noting which vars are only live from a backedge here.
[Bug middle-end/104381] [12 Regression] -gtoggle no longer applied when using optimize attribute since r12-4608-gb4702276615ff8d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104381 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-02-04 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Summary|[12 Regression] -gtoggle no |[12 Regression] -gtoggle no |longer applied when using |longer applied when using |optimize attribute |optimize attribute since ||r12-4608-gb4702276615ff8d4 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Started with r12-4608-gb4702276615ff8d4, working on that.
[Bug target/50883] [ARM] Suboptimal optimization for small structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883 --- Comment #17 from Eric Botcazou --- > Even if the performance impact is low, it does matter when optimizing for > size. Worth addressing for sure, but IMO not at expense of exposing calling conventions and other low-level stuff in GIMPLE.
[Bug fortran/104382] New: Finalization of parent components not compliant with standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104382 Bug ID: 104382 Summary: Finalization of parent components not compliant with standard Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- Created attachment 52349 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52349=edit Testcase for the problems With all branches that feature finalization, the attached testcase outputs: final_count after assignment =0 destructor4(complicated) 4. 5. destructor5 (simple2) -1 destructor5 (simple2) -2 destructor2(simple) 3 4 final_count after deallocation =4 Ifort, on the other hand, outputs: destructor4(complicated) 2.00 2.00 destructor5 (simple2) 5 destructor5 (simple2) 6 destructor1(simple) 1 destructor1(simple) 1 final_count after assignment =5 destructor4(complicated) 4.00 5.00 destructor5 (simple2) -1 destructor5 (simple2) -2 destructor1(simple) 3 destructor1(simple) 4 final_count after deallocation = 10 There are two problems: (i) The finalization of 'var' prior to reallocation is not ocurring. This is fixed by the patch that I posted to the list yesterday. (ii) The parent component is not being treated as a component, as mandated by F2018 7.5.6.2/1(3). Ifort is behaving correctly. Paul
[Bug middle-end/104381] [12 Regression] -gtoggle no longer applied when using optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104381
--- Comment #1 from Richard Biener ---
Err, it's worse(?)
> ./xgcc -B. t.c -O2 -fdump-tree-optimized -c
;; Function foo (foo, funcdef_no=0, decl_uid=1979, cgraph_uid=1,
symbol_order=0)
int foo (int x)
{
[local count: 1073741824]:
return x_1(D);
}
;; Function bar (bar, funcdef_no=1, decl_uid=1984, cgraph_uid=2,
symbol_order=1)
__attribute__((optimize ("no-tree-pre")))
int bar (int x)
{
[local count: 1073741824]:
# DEBUG tem => x_1(D) + 1
# DEBUG tem2 => x_1(D)
return x_1(D);
}
so it either applies -gtoggle or somehow enables at least
var-tracking-assignments (no .debug_info generated).
[Bug middle-end/104381] [12 Regression] -gtoggle no longer applied when using optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104381 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 CC||marxin at gcc dot gnu.org
[Bug middle-end/104381] New: [12 Regression] -gtoggle no longer applied when using optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104381
Bug ID: 104381
Summary: [12 Regression] -gtoggle no longer applied when using
optimize attribute
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
int foo (int x)
{
int tem = x + 1;
int tem2 = tem - 1;
return tem2;
}
int __attribute__((optimize("no-tree-pre"))) bar (int x)
{
int tem = x + 1;
int tem2 = tem - 1;
return tem2;
}
with
> ./xgcc -B. t.c -O2 -g -gtoggle -fdump-tree-optimized -c
I get
;; Function foo (foo, funcdef_no=0, decl_uid=1979, cgraph_uid=1,
symbol_order=0)
int foo (int x)
{
[local count: 1073741824]:
return x_1(D);
}
;; Function bar (bar, funcdef_no=1, decl_uid=1984, cgraph_uid=2,
symbol_order=1)
__attribute__((optimize ("no-tree-pre")))
int bar (int x)
{
[local count: 1073741824]:
# DEBUG tem => x_1(D) + 1
# DEBUG tem2 => x_1(D)
return x_1(D);
}
so -gtoggle is not applied to 'bar'. This works fine with GCC 11.
[Bug target/50883] [ARM] Suboptimal optimization for small structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883 --- Comment #16 from Richard Earnshaw --- And there are also cases where we end up with dead stack slots which can't be removed, so there's a stack size impact as well.
[Bug target/50883] [ARM] Suboptimal optimization for small structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883 --- Comment #15 from Richard Earnshaw --- Even if the performance impact is low, it does matter when optimizing for size.
[Bug target/50883] [ARM] Suboptimal optimization for small structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883 --- Comment #14 from Eric Botcazou --- > But no, I don't remember any case from SPEC where it makes a difference > in the end. Judging from the amount of duplicates we get around > parameter / return issues people do run into this. Yes, but I'd think on smallish/toy examples with e.g. Compiler Explorer.
[Bug ipa/104377] Unreachable code in create_specialized_node of ipa-prop.c?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104377 --- Comment #1 from Feng Xue --- (In reply to Feng Xue from comment #0) > For function create_specialized_node(), the "node" to operated on seems > always to be an original cgraph node, never a clone node. From call graph > related to the function, we know that ipcp_decision_stage () only passes raw > cgraph node downwards to its callees. Then, "node" reaching > create_specialized_node() would not be a clone, so the code enclosed by "if > (old_adjustments)" might be of no use. But I am not sure sure if there is > some thing that I missed. > > ipcp_driver > | > '--> ipcp_decision_stage >| >'--> decide_whether_version_node > | > |--> decide_about_value > | | > '-'--> create_specialized_node OK. I does missed something. Here we could not hold assumption that ipcp_decision_stage() only sees raw cgraph node, since sometime in the future some new ipa pass may be added prior to ipa-cp, and this pass introduces clone node. However, there is a questionable point about the code snippet if (!node->can_change_signature || old_adj->op != IPA_PARAM_OP_COPY || (!known_csts[old_adj->base_index] && ipa_is_param_used (info, old_adj->base_index))) In ipa-cp, known_csts is for the node, has no relation to the node's origin node, but here it is accessed via index of the latter (old_adj->base_index), will this cause out-of-bound error?
[Bug c++/104379] [9/10/11/12 Regression] -Wshadow warning given three times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379
--- Comment #4 from Jonathan Wakely ---
So you can imagine what happens if you combine constructor clones with
templates! :-D
template
struct S
{
int i;
S(int i) { (void) i; }
};
S i(1);
S j(1);
whe!
shad2.C: In constructor ‘S::S(int)’:
shad2.C:5:9: warning: declaration of ‘i’ shadows a member of ‘S’ [-Wshadow]
5 | S(int i) { (void) i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
shad2.C: In instantiation of ‘S::S(int) [with T = int]’:
shad2.C:8:11: required from here
shad2.C:5:9: warning: declaration of ‘i’ shadows a member of ‘S’
[-Wshadow]
5 | S(int i) { (void) i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
shad2.C:5:9: warning: declaration of ‘i’ shadows a member of ‘S’
[-Wshadow]
5 | S(int i) { (void) i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
shad2.C:5:9: warning: declaration of ‘i’ shadows a member of ‘S’
[-Wshadow]
5 | S(int i) { (void) i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
shad2.C: In instantiation of ‘S::S(int) [with T = long int]’:
shad2.C:9:12: required from here
shad2.C:5:9: warning: declaration of ‘i’ shadows a member of ‘S’
[-Wshadow]
5 | S(int i) { (void) i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
shad2.C:5:9: warning: declaration of ‘i’ shadows a member of ‘S’
[-Wshadow]
5 | S(int i) { (void) i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
shad2.C:5:9: warning: declaration of ‘i’ shadows a member of ‘S’
[-Wshadow]
5 | S(int i) { (void) i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
[Bug fortran/102330] [12 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3932 since r12-980-g29a2f51806c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102330 --- Comment #10 from Jakub Jelinek --- Of course exceptions would be vars that certainly don't appear in the IL yet, what I wrote about are vars that may appear there already. Generally, vars should be marked as addressable before gimplification and gimplification will then take the addressability into consideration, it is wrong to mark vars as addressable in the middle of gimplification if they could be already referenced earlier in the IL. And similarly in omp-low.cc we perform regimplifications and so stuff is fixable there too, but it needs to know it should fix it up.
[Bug c++/104379] [9/10/11/12 Regression] -Wshadow warning given three times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379
--- Comment #3 from Jonathan Wakely ---
(In reply to Richard Biener from comment #2)
> I suppose the same issue might happen with templates where we'd warn
> once per instantiation?
Yes indeed. Once for the primary template, and then again for each
specialization generated from it:
template
struct S
{
int i;
int f(int i) { return i; }
};
int i = S().f(1);
int j = S().f(1);
shad2.C: In member function ‘int S::f(int)’:
shad2.C:5:13: warning: declaration of ‘i’ shadows a member of ‘S’ [-Wshadow]
5 | int f(int i) { return i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
shad2.C: In instantiation of ‘int S::f(int) [with T = int]’:
shad2.C:8:19: required from here
shad2.C:5:13: warning: declaration of ‘i’ shadows a member of ‘S’
[-Wshadow]
5 | int f(int i) { return i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
shad2.C: In instantiation of ‘int S::f(int) [with T = long int]’:
shad2.C:9:20: required from here
shad2.C:5:13: warning: declaration of ‘i’ shadows a member of ‘S’
[-Wshadow]
5 | int f(int i) { return i; }
| ^
shad2.C:4:7: note: shadowed declaration is here
4 | int i;
| ^
[Bug fortran/102330] [12 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3932 since r12-980-g29a2f51806c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102330
--- Comment #9 from Jakub Jelinek ---
If you need to mark some var as addressable during omp lowering, then you need
to treat it similarly to the task shared case, so during scan phase of that
pass
do something like:
/* Taking address of OUTER in lower_send_shared_vars
might need regimplification of everything that uses the
variable. */
if (!task_shared_vars)
task_shared_vars = BITMAP_ALLOC (NULL);
bitmap_set_bit (task_shared_vars, DECL_UID (outer));
TREE_ADDRESSABLE (outer) = 1;
which will then make sure that the lowering phase of the pass will try to
regimplify all statements refering to such vars. Note, this should be only
done if the var isn't already TREE_ADDRESSABLE.
We then do:
static tree
lower_omp_regimplify_p (tree *tp, int *walk_subtrees,
void *data)
{
tree t = *tp;
...
if (task_shared_vars
&& DECL_P (t)
&& bitmap_bit_p (task_shared_vars, DECL_UID (t)))
return t;
Whether you can use the same bitmap or need to add another bitmap next to
task_shared_vars is something hard to guess without diving into it deeply.
[Bug target/50883] [ARM] Suboptimal optimization for small structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883 --- Comment #13 from rguenther at suse dot de --- On Fri, 4 Feb 2022, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883 > > Eric Botcazou changed: > >What|Removed |Added > > CC||ebotcazou at gcc dot gnu.org > > --- Comment #12 from Eric Botcazou --- > > Btw, I thought about this issue quite extensively together with Michael Matz > > and it's going to be a mess, in particular on the call side. Representing > > things on GIMPLE will also be fun. > > Is it really worth the hassle though for real-world code, i.e. as opposed to > toy examples, now that we have IPA-SRA and the like? I've looked at this in the context of BB vectorization which can cause awful code when parameters / return vars are participating and GIMPLE represents things as memory but RTL not. But no, I don't remember any case from SPEC where it makes a difference in the end. Judging from the amount of duplicates we get around parameter / return issues people do run into this.
[Bug c++/104379] [9/10/11/12 Regression] -Wshadow warning given three times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379 --- Comment #2 from Richard Biener --- I suspect we warn once for each CTOR clone, whilst with checking DECL_FROM_INLINE we excluded all but the master clone. "from inline" is of course misleading here. I suppose the same issue might happen with templates where we'd warn once per instantiation? There's for sure a better way to exclude the CTOR/DTOR clones than checking DECL_ABSTRACT_ORIGIN. DECL_FROM_INLINE is nearly dead, it should probably be removed.
