[Bug target/97102] [nvptx] PTX JIT compilation failed when using aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97102 --- Comment #9 from Tobias Burnus --- Regarding the commit: commit r12-7766-gf8b15e177155960017ac0c5daef8780d1127f91c Author: Tom de Vries Date: Fri Mar 11 13:41:01 2022 +0100 [nvptx] Use .alias directive for mptx >= 6.3
[Bug middle-end/104151] [10/11/12/13 Regression] x86: excessive code generated for 128-bit byteswap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104151
--- Comment #16 from Richard Biener ---
(In reply to Barnabás Pőcze from comment #15)
> Sorry, I haven't found a better issue. But I think the example below
> exhibits the same or a very similar issue.
>
> I would expect the following code
>
> void f(unsigned char *p, std::uint32_t x, std::uint32_t y)
> {
> p[0] = x >> 24;
> p[1] = x >> 16;
> p[2] = x >> 8;
> p[3] = x >> 0;
>
> p[4] = y >> 24;
> p[5] = y >> 16;
> p[6] = y >> 8;
> p[7] = y >> 0;
> }
>
> to be compiled to something along the lines of
>
> f(unsigned char*, unsigned int, unsigned int):
> bswap esi
> bswap edx
> mov DWORD PTR [rdi], esi
> mov DWORD PTR [rdi+4], edx
> ret
>
> however, I get scores of bitwise operations instead if `-fno-tree-vectorize`
> is not specified.
>
> https://gcc.godbolt.org/z/z51K6qorv
Yes, here we vectorize the store:
[local count: 1073741824]:
_1 = x_15(D) >> 24;
_2 = (unsigned char) _1;
_3 = x_15(D) >> 16;
_4 = (unsigned char) _3;
_5 = x_15(D) >> 8;
_6 = (unsigned char) _5;
_7 = (unsigned char) x_15(D);
_8 = y_22(D) >> 24;
_9 = (unsigned char) _8;
_10 = y_22(D) >> 16;
_11 = (unsigned char) _10;
_12 = y_22(D) >> 8;
_13 = (unsigned char) _12;
_14 = (unsigned char) y_22(D);
_35 = {_2, _4, _6, _7, _9, _11, _13, _14};
vectp.4_36 = p_17(D);
MEM [(unsigned char *)vectp.4_36] = _35;
but without vectorizing the store merging pass (which comes after
vectorization) is able to detect two SImode bswaps.
Basically we fail to consider "generic" vectorization as option here
and generic vectorization fails to consider using bswap for permutes
of "existing vectors". Likewise we fail to consider _1, _3, etc.
as element accesses of the existing "vectors" x and y. That would
work iff the shift + truncates were canonicalized as BIT_FIELD_REF,
but it's certainly possible to work with the existing IL here.
Note this issue is probably better tracked in a separate bugreport.
[Bug c++/106847] deprecated class data member makes the class generate diagnostics even when the member is not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106847 Richard Biener changed: What|Removed |Added Keywords||diagnostic --- Comment #2 from Richard Biener --- Well, you did use it by copying it? Specify a copy CTOR that does not copy 'x' and you'll be fine?
[Bug bootstrap/106855] [13 Regression] Removal of stabs/xcoff debugging broke bootstrap on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106855 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |13.0 Version|unknown |13.0
[Bug fortran/106856] [12/13 Regression] ICE in gfc_conv_expr_present, at fortran/trans-expr.cc:1977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106856 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.3 Priority|P3 |P4
[Bug fortran/106857] [10/11/12/13 Regression] ICE in gfc_simplify_pack, at fortran/simplify.cc:6438
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106857 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |10.5
[Bug c++/106858] [12/13 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'baselink' in cp_ubsan_maybe_instrument_member_access, at cp/cp-ubsan.cc:172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106858 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.3
[Bug debug/106859] [10/11/12/13 Regression] ICE in val_store, at var-tracking.cc:2532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106859 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.5
[Bug tree-optimization/106862] ice in compute_control_dep_chain, at gimple-predicate-analysis.cc:1105
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106862
--- Comment #3 from David Binderman ---
Another test case, this time in C is:
enum { GELB, VIOLETT } KABEL;
typedef playground_t[][4][2];
int ToPlayground_0_0_0, PlayGame_countdown, PlayGame_count_tick_len,
PlayGame_move_tick_len, ProcessCapsules_row;
playground_t CapsuleCountdown;
void PlayGame() {
int FinishTakeover = 0, prev_move_tick;
while (!FinishTakeover) {
if (KeyIsPressedR() && ModIsPressed() && ModIsPressed())
return;
if (PlayGame_count_tick_len) {
if (PlayGame_countdown)
EndCountdownSound();
FinishTakeover = 1;
}
if (prev_move_tick + PlayGame_move_tick_len)
prev_move_tick += ProcessCapsules();
}
}
void ProcessCapsules() {
int color = GELB;
for (; color <= VIOLETT; color++) {
ProcessCapsules_row = 0;
for (; ProcessCapsules_row < 12; ProcessCapsules_row++) {
if (CapsuleCountdown[color][0][ProcessCapsules_row])
CapsuleCountdown[color][0][ProcessCapsules_row]--;
if (CapsuleCountdown[color][0][ProcessCapsules_row])
ToPlayground_0_0_0 = KABEL;
}
}
}
$ /home/dcb/gcc/results/bin/gcc -c -fcommon -O3 -Wall bug842B.c
[Bug tree-optimization/106860] [12/13 Regression] ICE in single_pred_edge, at basic-block.h:347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106860
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
Last reconfirmed||2022-09-07
Target Milestone|--- |12.3
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Richard Biener ---
Confirmed.
static bool
split_loop (class loop *loop1)
{
...
/* Fix first loop's exit probability after scaling. */
edge exit_to_latch1 = single_pred_edge (loop1->latch);
I think it's a misconception that latches are guaranteed to have a single
predecessor. With LOOPS_HAVE_SIMPLE_LATCHES we have a single _successor_.
The CFG is also very different than expected, with a lot of code on the
"latch" (a whole subloop is there).
[Bug c/106868] New: Bogus -Wdangling-pointer warning with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106868
Bug ID: 106868
Summary: Bogus -Wdangling-pointer warning with -O1
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: medhefgo at web dot de
Target Milestone: ---
The following code gives me a (afaik) bogus dangling pointer warning:
# cat testcase.c
void alloc(void **p);
void false_dangling(char **p) {
{
void *q;
alloc(&q);
*p = q;
}
char *a = __builtin_memcpy(*p, "", 1);
*a = 0;
}
$ gcc -c -o/dev/null testcase.c -Wdangling-pointer -O1
testcase.c: In function ‘false_dangling’:
testcase.c:9:6: warning: using dangling pointer ‘a’ to ‘q’
[-Wdangling-pointer=]
9 | *a = 0;
| ~~~^~~
testcase.c:4:11: note: ‘q’ declared here
4 | void *q;
|
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC)
[Bug target/106861] [12/13 Regression] ICE in add_cfi_args_size, at dwarf2cfi.cc:501
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106861 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.3
[Bug tree-optimization/106862] ice in compute_control_dep_chain, at gimple-predicate-analysis.cc:1105
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106862 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Richard Biener --- r13-2493-g1a4e1425f84985 (PR106844) seems to fix this. *** This bug has been marked as a duplicate of bug 106844 ***
[Bug tree-optimization/106844] ICE in init_use_preds, at gimple-predicate-analysis.cc:1944 since r13-2436-ge9ea2688271bd0b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106844 Richard Biener changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #4 from Richard Biener --- *** Bug 106862 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/106866] [13 Regression] ICE in predicate::init_from_control_deps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106866 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |13.0 Last reconfirmed||2022-09-07 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Richard Biener --- Confirmed, mine.
[Bug tree-optimization/106867] [13 Regression] ICE in set, at value-range.cc:372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106867 Richard Biener changed: What|Removed |Added CC||aldyh at gcc dot gnu.org Target Milestone|--- |13.0
[Bug tree-optimization/106868] [12/13 Regression] Bogus -Wdangling-pointer warning with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106868
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords||diagnostic
Summary|Bogus -Wdangling-pointer|[12/13 Regression] Bogus
|warning with -O1|-Wdangling-pointer warning
||with -O1
Component|c |tree-optimization
Last reconfirmed||2022-09-07
Status|UNCONFIRMED |NEW
Priority|P3 |P2
CC||msebor at gcc dot gnu.org
Target Milestone|--- |12.3
--- Comment #1 from Richard Biener ---
Confirmed.
[local count: 1073741824]:
alloc (&q);
q.0_1 = q;
*p_4(D) = q.0_1;
q ={v} {CLOBBER(eol)};
a_8 = __builtin_memcpy (q.0_1, "", 1);
*a_8 = 0;
return;
(gdb) p debug_gimple_stmt (use_stmt)
# .MEM_9 = VDEF <.MEM_7>
*a_8 = 0;
(gdb) p debug_gimple_stmt (stmt)
# .MEM_6 = VDEF <.MEM_5>
q ={v} {CLOBBER(eol)};
we somehow confuse q.0_1 = q; as assigning the address of the object 'q'.
Some addr vs deref mismatch somewhere in the code.
A regression with -Wall.
[Bug target/106828] cc1plus: warning: '-fsanitize=address' not supported for this target for loongarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106828 --- Comment #2 from CVS Commits --- The master branch has been updated by LuluCheng : https://gcc.gnu.org/g:0067ba052b976431c49d6a86f2c9ede9938efcdf commit r13-2510-g0067ba052b976431c49d6a86f2c9ede9938efcdf Author: Lulu Cheng Date: Wed Sep 7 11:25:45 2022 +0800 LoongArch: Fix pr106828 by define hook TARGET_ASAN_SHADOW_OFFSET in loongarch backend [PR106828]. gcc/ChangeLog: PR target/106828 * config/loongarch/loongarch.cc (loongarch_asan_shadow_offset): New. (TARGET_ASAN_SHADOW_OFFSET): New. gcc/testsuite/ChangeLog: PR target/106828 * g++.target/loongarch/pr106828.C: New test.
[Bug tree-optimization/106866] [13 Regression] ICE in predicate::init_from_control_deps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106866 --- Comment #2 from Richard Biener --- Hm, we fail to purge abnormal edges somewhere. But I guess I can make uninit analysis more forgiving as well.
[Bug tree-optimization/106867] [13 Regression] ICE in set, at value-range.cc:372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106867 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Aldy Hernandez --- Looks like it got fixed in the last few patches in this area. Both the cited patch and the original fp-cmp-4.c test pass for -O2 -fno-tree-fre.
[Bug tree-optimization/106867] [13 Regression] ICE in set, at value-range.cc:372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106867 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Wouldn't hurt to add it as a compile time testcase though (with those options).
[Bug tree-optimization/106866] [13 Regression] ICE in predicate::init_from_control_deps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106866 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #3 from Richard Biener --- So somehow we late figure bar() doesn't return abnormally and thus DSE eliminates a call to it but doesn't trigger if (need_ab_cleanup && stmt_can_make_abnormal_goto (stmt)) bitmap_set_bit (need_ab_cleanup, bb->index); which means when we either set ECF_LEAF to the function or cleared cfun->calls_setjmp (the recursive invocation) we should have pruned abnormal edges but we failed to. That ends us with a block like ;; basic block 4, loop depth 0 ;;pred: 12 ;;5 # uninitialized_2(ab) = PHI goto ; [99.96%] ;;succ: 11 ;;5 where the 4->5 edge is abnormal but there's no stmt in this block that could be responsible for it. We also fail to verify ICE here.
[Bug bootstrap/106855] [13 Regression] Removal of stabs/xcoff debugging broke bootstrap on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106855 --- Comment #3 from Martin Liška --- Sorry for the breakage, working on that right now.
[Bug bootstrap/106855] [13 Regression] Removal of stabs/xcoff debugging broke bootstrap on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106855 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org
[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 --- Comment #15 from Eric Gallager --- (In reply to Andrew Pinski from comment #13) > Patient: Doctor it hurts when I do this. > Doctor: then don't do that and if you read the instructions I gave you I > told you I would hurt this way. > The problem I see with this analogy, is who exactly is the doctor in this situation? It seems that currently the doctor is the GCC devs, but I think the situation could be improved by having GCC itself be the doctor, by implementing a -Wfast-math warning flag or something to make the issues with -ffast-math more known. Having it documented in the instructions is just one place; it should be mentioned in all the relevant places that a user might check.
[Bug tree-optimization/106860] [12/13 Regression] ICE in single_pred_edge, at basic-block.h:347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106860 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:0386609923577e07354ee63754795b2f729e7e00 commit r13-2514-g0386609923577e07354ee63754795b2f729e7e00 Author: Richard Biener Date: Wed Sep 7 10:44:33 2022 +0200 tree-optimization/106860 - fix profile scaling in split_loop The following fixes a mistake in loop splitting which assumes loop latches have a single predecessor and that edge is from the exit test. Instead work from the single exit edge we have to find the edge towards the latch. PR tree-optimization/106860 * tree-ssa-loop-split.cc (split_loop): Find the exit to latch edge from the loop exit edge instead of from the latch. Verify we're going to find it. * g++.dg/opt/pr106860.C: New testcase.
[Bug tree-optimization/106860] [12 Regression] ICE in single_pred_edge, at basic-block.h:347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106860 Richard Biener changed: What|Removed |Added Summary|[12/13 Regression] ICE in |[12 Regression] ICE in |single_pred_edge, at|single_pred_edge, at |basic-block.h:347 |basic-block.h:347 Priority|P3 |P2 --- Comment #3 from Richard Biener --- Fixed on trunk sofar.
gcc cannot build correctly famous hello program, clang does it correctly
$ gcc -v
gcc version 10.2.1 20210110 (Debian 10.2.1-6)
$ clang -v
Debian clang version 11.0.1-2
$ cat hello.c
int i;main(){for(;i["]
[Bug c++/106869] New: ranges::unique does nothing unless ranges::sort called first or something else is wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106869
Bug ID: 106869
Summary: ranges::unique does nothing unless ranges::sort called
first or something else is wrong.
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: info at kemalakcam dot com
Target Milestone: ---
ka@localhost:~/projects/ka_projects/ka_examples_cpp20/ka_example_ranges_unique$
cat ka_example_ranges_unique.cpp
// 20220622T0300 : Kemal Akcam : i...@kemalakcam.com :
ka_example_ranges_unique.cpp
// compile below code with gcc -lstdc++ -std=c++20 ka_example_ranges_unique.cpp
-o ka_example_ranges_unique
#include
using namespace std;
class c
{
public:
vector v;
void printVectorContent(void)
{
cout << "vector v = ";
for(int i=0; i < v.size(); i++)
cout << v[i].c_str() << " ";
cout << endl;
};
};
int main(void)
{
c *k = new c();
k->v = {"aa", "ab", "ga", "ewr", "r42","rtwgh", "qwq","fasa", "ss","aa",
"awrq1", "aa"};
k->printVectorContent();
cout << "ranges::unique(v);" << endl;
ranges::unique(k->v);
k->printVectorContent();
cout << "20220622T0300 : Kemal Akcam : ranges::unique did not function, there
are still 3 x 'aa' in vector" << endl;
cout << "ranges::sort(v);" << endl;
ranges::sort(k->v);
k->printVectorContent();
cout << "ranges::unique(v);" << endl;
ranges::unique(k->v);
k->printVectorContent();
cout << "20220622T0300 : Kemal Akcam : ranges::unique did function after
running ranges::sort, there are not 3 x 'aa' in vector, only 1 x 'aa'" << endl;
}
ka@localhost:~/projects/ka_projects/ka_examples_cpp20/ka_example_ranges_unique$
gcc -lstdc++ -std=c++20 ka_example_ranges_unique.cpp -o
ka_example_ranges_unique
ka@localhost:~/projects/ka_projects/ka_examples_cpp20/ka_example_ranges_unique$
./ka_example_ranges_unique
vector v = aa ab ga ewr r42 rtwgh qwq fasa ss aa awrq1 aa
ranges::unique(v);
vector v = aa ab ga ewr r42 rtwgh qwq fasa ss aa awrq1 aa
20220622T0300 : Kemal Akcam : ranges::unique did not function, there are still
3 x 'aa' in vector
ranges::sort(v);
vector v = aa aa aa ab awrq1 ewr fasa ga qwq r42 rtwgh ss
ranges::unique(v);
vector v = aa ab awrq1 ewr fasa ga qwq r42 rtwgh ss
20220622T0300 : Kemal Akcam : ranges::unique did function after running
ranges::sort, there are not 3 x 'aa' in vector, only 1 x 'aa'
ka@localhost:~/projects/ka_projects/ka_examples_cpp20/ka_example_ranges_unique$
lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 10 (buster)
Release:10
Codename: buster
ka@localhost:~/projects/ka_projects/ka_examples_cpp20/ka_example_ranges_unique$
cat /proc/version
Linux version 4.19.0-13-amd64 (debian-ker...@lists.debian.org) (gcc version
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.160-2 (2020-11-28)
ka@localhost:~/projects/ka_projects/ka_examples_cpp20/ka_example_ranges_unique$
gcc --version
gcc (GCC) 12.1.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Adding below instead of #include gives same result.
#include
#include
#include
#include
Re: gcc cannot build correctly famous hello program, clang does it correctly
On Wed, Sep 07, 2022 at 12:36:22PM +0200, Alex Ernst via Gcc-bugs wrote:
> $ gcc -v
> gcc version 10.2.1 20210110 (Debian 10.2.1-6)
>
> $ clang -v
> Debian clang version 11.0.1-2
>
> $ cat hello.c
> int i;main(){for(;i["] o, world!\n",'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);}
Garbage in, garbage out. This invokes UB in several spots.
One is that read has the second argument implicitly int, you pass
a const char * argument to it and because write is also unprototyped,
the second argument to it is also int. Expecting that it passes
in the full pointer is wrong, it "happens to work" on most 32-bit
targets where pointers are the same size as integers and if they
are passed the same way.
This can be fixed by adding char*i; before {write,
but you need to change i/i to p/p or something similar because
you can't divide pointers.
But once you do that, there is another UB, i-- on the first iteration
is invalid pointer arithmetics - "Hello, world!\n"-1 .
Jakub
[Bug tree-optimization/106867] [13 Regression] ICE in set, at value-range.cc:372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106867 --- Comment #3 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:22cefe5c22a90d20e2d9f629402b0522c03fa59c commit r13-2516-g22cefe5c22a90d20e2d9f629402b0522c03fa59c Author: Aldy Hernandez Date: Wed Sep 7 12:58:49 2022 +0200 [PR106867] Add test for PR. PR tree-optimization/106867 gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr106867.c: New test.
[Bug libstdc++/106869] ranges::unique does nothing unless ranges::sort called first or something else is wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106869 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- Yes, that's correct. std::unique and std::ranges::unique only remove **consecutive** duplicates, they don't search the entire range again and again for duplicates. So you need to sort it first, or otherwise arrange for all duplicates to be adjacent to each other. https://en.cppreference.com/w/cpp/algorithm/unique
[Bug middle-end/106870] New: ctrl_altering flag is not set correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106870
Bug ID: 106870
Summary: ctrl_altering flag is not set correctly
Product: gcc
Version: 13.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: ---
When trying to add the following verification I run into various issues with
the gimple_ctrl_altering_p flag which stmt_ends_bb_p which sets found_ctrl_stmt
ultimatively relies on for the noreturn case.
diff --git a/gcc/tree-cfg.cc b/gcc/tree-cfg.cc
index bbe08357d6e..a939a11d8bb 100644
--- a/gcc/tree-cfg.cc
+++ b/gcc/tree-cfg.cc
@@ -5708,6 +5709,14 @@ gimple_verify_flow_info (void)
seen_nondebug_stmt = true;
}
+ if (!found_ctrl_stmt && EDGE_COUNT (bb->succs) != 1)
+ {
+ error ("basic block %d has no control altering stmt but %d "
+"outgoing edges",
+bb->index, EDGE_COUNT (bb->succs));
+ err = 1;
+ }
+
gsi = gsi_last_nondebug_bb (bb);
if (gsi_end_p (gsi))
continue;
[Bug bootstrap/106855] [13 Regression] Removal of stabs/xcoff debugging broke bootstrap on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106855 Martin Liška changed: What|Removed |Added Keywords||patch --- Comment #4 from Martin Liška --- Patch candidate: https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601216.html
[Bug libstdc++/106871] New: std::function should not check func ptr on each call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106871 Bug ID: 106871 Summary: std::function should not check func ptr on each call Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rockeet at gmail dot com Target Milestone: --- std::function should not check func ptr on each call, an optimization should be: define a 'default throw' function which just throws a std::bad_function_call. in std::function constructor, set the function ptr to this 'default throw' function. (assign nullptr also set this 'default throw' to std::function). in this way, it is not needed to check the function ptr in each std::function call. and the nullptr check can use any other 2 ptr-width fields of std::function.
[Bug libstdc++/56551] A faster implementation of std::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56551 Jonathan Wakely changed: What|Removed |Added CC||rockeet at gmail dot com --- Comment #3 from Jonathan Wakely --- *** Bug 106871 has been marked as a duplicate of this bug. ***
[Bug libstdc++/106871] std::function should not check func ptr on each call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106871 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- I've looked into this and I don't think it can be done without an ABI break. Objects constructed in old code compiled by an older GCC would still have a null pointer, so code compiled by a new GCC can't assume that the pointer is never null. We have another PR on the same subject anyway. *** This bug has been marked as a duplicate of bug 56551 ***
[Bug c++/106863] ICE in write_template_arg_literal, at cp/mangle.cc:3678 since r12-4782-geca767aa51d1f696
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106863 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Summary|internal compiler error: in |ICE in |write_template_arg_literal, |write_template_arg_literal, |at cp/mangle.cc:3678|at cp/mangle.cc:3678 since ||r12-4782-geca767aa51d1f696 Last reconfirmed||2022-09-07 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r12-4782-geca767aa51d1f696, rejected before.
[Bug libstdc++/56551] A faster implementation of std::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56551 --- Comment #4 from Jonathan Wakely --- As I just wrote on the duplicate bug: I've looked into this and I don't think it can be done without an ABI break. Objects constructed in old code compiled by an older GCC would still have a null pointer, so code compiled by a new GCC can't assume that the pointer is never null.
[Bug fortran/106856] [12/13 Regression] ICE in gfc_conv_expr_present, at fortran/trans-expr.cc:1977 since r12-4346-geb92cd57a1ebe7cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106856 Martin Liška changed: What|Removed |Added Summary|[12/13 Regression] ICE in |[12/13 Regression] ICE in |gfc_conv_expr_present, at |gfc_conv_expr_present, at |fortran/trans-expr.cc:1977 |fortran/trans-expr.cc:1977 ||since ||r12-4346-geb92cd57a1ebe7cd Last reconfirmed||2022-09-07 Status|UNCONFIRMED |NEW CC||burnus at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r12-4346-geb92cd57a1ebe7cd.
[Bug fortran/106857] [10/11/12/13 Regression] ICE in gfc_simplify_pack, at fortran/simplify.cc:6438 since r12-4278-g74ccca380cde5e79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106857 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression] |ICE in gfc_simplify_pack, |ICE in gfc_simplify_pack, |at fortran/simplify.cc:6438 |at fortran/simplify.cc:6438 ||since ||r12-4278-g74ccca380cde5e79 --- Comment #2 from Martin Liška --- Started with r12-4278-g74ccca380cde5e79.
[Bug c++/106858] [12/13 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'baselink' in cp_ubsan_maybe_instrument_member_access, at cp/cp-ubsan.cc:172 since r12-58
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106858 Martin Liška changed: What|Removed |Added CC||cltang at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|[12/13 Regression] ICE: |[12/13 Regression] ICE: |tree check: expected tree |tree check: expected tree |that contains 'decl common' |that contains 'decl common' |structure, have 'baselink' |structure, have 'baselink' |in |in |cp_ubsan_maybe_instrument_m |cp_ubsan_maybe_instrument_m |ember_access, at|ember_access, at |cp/cp-ubsan.cc:172 |cp/cp-ubsan.cc:172 since ||r12-5835-g0ab29cf0bb68960c Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-09-07 --- Comment #1 from Martin Liška --- Started with r12-5835-g0ab29cf0bb68960c.
[Bug debug/106859] [10/11/12/13 Regression] ICE in val_store, at var-tracking.cc:2532 since r7-3839-gde0a3fa38e2ad8f3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106859 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-09-07 Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression] |ICE in val_store, at|ICE in val_store, at |var-tracking.cc:2532|var-tracking.cc:2532 since ||r7-3839-gde0a3fa38e2ad8f3 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org, ||pthaugen at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r7-3839-gde0a3fa38e2ad8f3.
[Bug target/106861] [12/13 Regression] ICE in add_cfi_args_size, at dwarf2cfi.cc:501
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106861 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-09-07 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Adding -fexceptions, all binaries I have do ICE (4.9.0+).
[Bug tree-optimization/106866] [13 Regression] ICE in predicate::init_from_control_deps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106866 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:a262f969d6fd936f4fb5d9e1d5756b0dcbc925b2 commit r13-2518-ga262f969d6fd936f4fb5d9e1d5756b0dcbc925b2 Author: Richard Biener Date: Wed Sep 7 12:50:40 2022 +0200 tree-optimization/106866 - avoid dead abnormal edges from DCE When DCE clears cfun->calls_setjmp then suddenly we don't need any abnormal call edges anymore. The following makes sure to prune them which otherwise can confuse other passes. PR tree-optimization/106866 * tree-ssa-dce.cc (eliminate_unnecessary_stmts): When we changed cfun->calls_setjmp make sure to purge all abnormal call edges. * gcc.dg/uninit-pr106866.c: New testcase.
[Bug tree-optimization/106866] [13 Regression] ICE in predicate::init_from_control_deps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106866 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug bootstrap/106855] [13 Regression] Removal of stabs/xcoff debugging broke bootstrap on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106855 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:7abcdb06e31d82d4933cb6e0a626c3ccb28fa0c3 commit r13-2519-g7abcdb06e31d82d4933cb6e0a626c3ccb28fa0c3 Author: Martin Liska Date: Wed Sep 7 11:47:40 2022 +0200 Restore XCOFF for DWARF on AIX. PR bootstrap/106855 gcc/ChangeLog: * collect2.cc (scan_prog_file): Restore if XCOFF_DEBUGGING_INFO. * config/rs6000/rs6000.cc (rs6000_option_override_internal): Restore usage of XCOFF_DEBUGGING_INFO. * config/rs6000/xcoff.h (XCOFF_DEBUGGING_INFO): Restore. * dwarf2asm.cc (XCOFF_DEBUGGING_INFO): Restore support for XCOFF_DEBUGGING_INFO. (dw2_asm_output_nstring): Likewise. (USE_LINKONCE_INDIRECT): Likewise. * dwarf2out.cc (XCOFF_DEBUGGING_INFO): Likewise. (HAVE_XCOFF_DWARF_EXTRAS): Likewise. (output_fde): Likewise. (output_call_frame_info): Likewise. (have_macinfo): Likewise. (add_AT_loc_list): Likewise. (add_AT_view_list): Likewise. (output_compilation_unit_header): Likewise. (output_pubnames): Likewise. (output_aranges): Likewise. (output_line_info): Likewise. (output_macinfo): Likewise. (dwarf2out_finish): Likewise. (dwarf2out_early_finish): Likewise.
[Bug bootstrap/106855] [13 Regression] Removal of stabs/xcoff debugging broke bootstrap on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106855 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Martin Liška --- Fixed now.
[Bug libstdc++/88101] Implement P0528R3, C++20 cmpxchg and padding bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #13 from Jonathan Wakely --- Library patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601218.html
[Bug libstdc++/98978] Consider packing _M_Engaged in the tail padding of T in optional<>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98978
--- Comment #5 from Jonathan Wakely ---
(In reply to andysem from comment #3)
> Is there no way to improve standard components implementation? I'd imagine
> you could provide the new implementation in the new version inline namespace
> and still support the old ABI for backward compatibility.
To give a more complete answer: Inline namespaces don't help, that's a myth.
struct X { std::optional b; };
Now one translation unit has X using the old ABI and one has X using the new
ABI, but they're the same X. The fact that the two versions of optional are in
different namespaces is no help at all. You still have an ABI break.
We did it for std::string and it was a multi-year effort that caused disruption
across the industry. It's not worth doing that again to save a few bytes in
std::optional.
[Bug libstdc++/100824] ranges::size should treat the subexpression as an lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100824 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.2 --- Comment #13 from Jonathan Wakely --- I'm not going to backport this to gcc-10, so FIXED.
[Bug libstdc++/100824] ranges::size should treat the subexpression as an lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100824 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Jonathan Wakely --- .
[Bug analyzer/106854] [[gnu::malloc(deallocator)]] for non-pointer functions (e.g., fd)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106854 --- Comment #7 from David Malcolm --- (In reply to Alejandro Colomar from comment #6) > timerfd_create() might not be important if the timer is not correctly > deleted. pthread_mutex_init() is another one that is quite more important, > as leaking such a thing in a multithreaded program will be a pain to debug > for sure. This attribute could help detect that. FWIW I think we'll eventually want to model the pthreads API (e.g. for checking of locks; see PR 105897), so pthread_mutex_init seems like a function we'd be better off special-casing, rather than trying to express all of its semantics with attributes.
[Bug middle-end/106833] Miss to handle OPAQUE_TYPE specially in verify_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833 --- Comment #12 from Segher Boessenkool --- (In reply to Kewen Lin from comment #10) > (In reply to Segher Boessenkool from comment #9) > > Although, preferably we should not allow assigning one opaque type to > > another > > opaque type just because they will eventually use the same mode, not without > > warning anyway? Or is that unavoidable? Compare assigning a V4SI to a > > V4SF. > > IIUC, you meant the assignment happening for two different opaque types, > then it's a conversion? Yes exactly. > If so, I think we can check it in > rs6000_invalid_conversion, currently it just simply checks the modes. Yup. > If we > have two different opaque types mapping to one same mode, we can further > check if the things like TYPE_CANONICAL match. Like that. It isn't urgent -- we currently have only one type for each of our two opaque modes -- but if we allow too much here, we would need a separate mode for each opaque thing we want to distinguish, which is contrary to the point of having it :-) > > I don't know if your patch does this, btw, and it isn't so easy to test, we > > currently have only one type for each of our opaque modes. Maybe test by > > adding an extra builtin type :-) > > This patch doesn't handle that, the main issue here is that some > cv-qualified opaque type can cause ICE in type verification during LTO. > IMHO, opaque types conversion issue looks like a separated issue and it can > be handled in target hook invalid_conversion. But I guess you want a more > generic check? And as you pointed out, there is no such scenario that two > opaque types have the same mode, not sure if we really want to handle it for > now. :-) I think it can be handled generically, no target code is needed for it.
[Bug middle-end/106870] ctrl_altering flag is not set correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106870 --- Comment #1 from Richard Biener --- gcc.dg/torture/pr57036-2.c shows how inlining and non-local gotos come into play here. Note the flag was specifically invented to not make CFG verification ICE when a function in the middle of a block becomes noreturn, for example via IPA analysis. It wasn't necessarily required to have the flag set on stmts ending a BB. Still not having the flag set prevents nothing to put stmts after such call and we'd not complain. gcc.dg/torture/pr83055.c shows how the checking is confused as called from gimple_flow_call_edges_add after adding loads of fake edges.
[Bug libstdc++/106607] Regex integer overflow on large backreference value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106607 --- Comment #2 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:87da20c6e280925d885c5472de9189515f46880b commit r12-8746-g87da20c6e280925d885c5472de9189515f46880b Author: Jonathan Wakely Date: Mon Aug 22 15:16:16 2022 +0100 libstdc++: Check for overflow in regex back-reference [PR106607] Currently we fail to notice integer overflow when parsing a back-reference expression, or when converting the parsed result from long to int. This changes the result to be int, so no conversion is needed, and uses the overflow-checking built-ins to detect an out-of-range back-reference. libstdc++-v3/ChangeLog: PR libstdc++/106607 * include/bits/regex_compiler.tcc (_Compiler::_M_cur_int_value): Use built-ins to check for integer overflow in back-reference number. * testsuite/28_regex/basic_regex/106607.cc: New test. (cherry picked from commit 1b09eea33f2bf9d1eae73b25cc25efb05ea1dc3f)
[Bug libstdc++/106695] [11/12 Regression] Explicit copy constructor does not work for a parameter passed via std::async
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106695 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:47f0bd269403762ddb71b8c6165b30ace4f70a8b commit r12-8747-g47f0bd269403762ddb71b8c6165b30ace4f70a8b Author: Jonathan Wakely Date: Mon Aug 22 15:42:17 2022 +0100 libstdc++: Fix for explicit copy ctors in and [PR106695] When I changed std::thread and std::async to avoid unnecessary move construction of temporaries, I introduced a regression where types with an explicit copy constructor could not be passed to std::thread or std::async. The fix is to add a constructor instead of using aggregate initialization of an unnamed temporary. libstdc++-v3/ChangeLog: PR libstdc++/106695 * include/bits/std_thread.h (thread::_State_impl): Forward individual arguments to _Invoker constructor. (thread::_Invoker): Add constructor. Delete copies. * include/std/future (__future_base::_Deferred_state): Forward individual arguments to _Invoker constructor. (__future_base::_Async_state_impl): Likewise. * testsuite/30_threads/async/106695.cc: New test. * testsuite/30_threads/thread/106695.cc: New test. (cherry picked from commit 5abe0657553580bd1b7488dd84d55138a8d9f23c)
[Bug c++/106188] [coroutines] Incorrect frame layout after transforming conditional statement without top-level bind expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106188 --- Comment #1 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a961ad1b13b9c294d4565344912b8e35ba71b369 commit r13-2524-ga961ad1b13b9c294d4565344912b8e35ba71b369 Author: Arsen ArsenoviÄ Date: Sun Sep 4 21:04:23 2022 +0200 c++: top level bind when rewriting coroutines [PR106188] In the edge case of a coroutine not containing any locals, the ifcd/switch temporaries would get added to the coroutine frame, corrupting its layout. To prevent this, we can make sure there is always a BIND_EXPR at the top of the function body, and thus, always a place for our new temporaries to go without interfering with the coroutine frame. PR c++/106188 - Incorrect frame layout after transforming conditional statement without top-level bind expression PR c++/106713 - if (co_await ...) crashes with a jump to ud2 PR c++/106188 PR c++/106713 gcc/cp/ChangeLog: * coroutines.cc (coro_rewrite_function_body): Ensure we have a BIND_EXPR wrapping the function body. gcc/testsuite/ChangeLog: * g++.dg/coroutines/pr106188.C: New test. Signed-off-by: Arsen ArsenoviÄ
[Bug c++/106713] [11/12/13 Regression] Coroutine regression in GCC 11.3.0: if (co_await ...) crashes with a jump to ud2 since r12-3529-g70ee703c479081ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106713 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a961ad1b13b9c294d4565344912b8e35ba71b369 commit r13-2524-ga961ad1b13b9c294d4565344912b8e35ba71b369 Author: Arsen ArsenoviÄ Date: Sun Sep 4 21:04:23 2022 +0200 c++: top level bind when rewriting coroutines [PR106188] In the edge case of a coroutine not containing any locals, the ifcd/switch temporaries would get added to the coroutine frame, corrupting its layout. To prevent this, we can make sure there is always a BIND_EXPR at the top of the function body, and thus, always a place for our new temporaries to go without interfering with the coroutine frame. PR c++/106188 - Incorrect frame layout after transforming conditional statement without top-level bind expression PR c++/106713 - if (co_await ...) crashes with a jump to ud2 PR c++/106188 PR c++/106713 gcc/cp/ChangeLog: * coroutines.cc (coro_rewrite_function_body): Ensure we have a BIND_EXPR wrapping the function body. gcc/testsuite/ChangeLog: * g++.dg/coroutines/pr106188.C: New test. Signed-off-by: Arsen ArsenoviÄ
[Bug other/106872] New: [13 regression] gcc.dg/uninit-pred-12.c fails after r13-2500-g0a4a2667dc115c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106872 Bug ID: 106872 Summary: [13 regression] gcc.dg/uninit-pred-12.c fails after r13-2500-g0a4a2667dc115c Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:0a4a2667dc115ca73b552fcabf8570620dfbe55f, r13-2500-g0a4a2667dc115c make -k check-gcc RUNTESTFLAGS="dg.exp=gcc.dg/uninit-pred-12.c" FAIL: gcc.dg/uninit-pred-12.c scan-tree-dump uninit1 "AND \\(NOT \\(ivtmp" # of expected passes2 # of unexpected failures1 commit 0a4a2667dc115ca73b552fcabf8570620dfbe55f (HEAD, refs/bisect/bad) Author: Richard Biener Date: Tue Sep 6 13:46:00 2022 +0200 tree-optimization/106754 - fix compute_control_dep_chain defect
[Bug c++/106793] poor diagnostic for missing template argument list on function parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106793 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug rtl-optimization/105586] [11/12/13 Regression] -fcompare-debug failure (length) with -O2 -fno-if-conversion -mtune=power4 -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105586 --- Comment #5 from CVS Commits --- The master branch has been updated by Surya Kumari Jangala : https://gcc.gnu.org/g:bec35caafae8db0278e1d037a7ba00c3e6899bbd commit r13-2525-gbec35caafae8db0278e1d037a7ba00c3e6899bbd Author: Surya Kumari Jangala Date: Tue Aug 2 23:00:03 2022 -0500 sched1: Fix -fcompare-debug issue in schedule_region [PR105586] In schedule_region(), a basic block that does not contain any real insns is not scheduled and the dfa state at the entry of the bb is not copied to the fallthru basic block. However a DEBUG insn is treated as a real insn, and if a bb contains non-real insns and a DEBUG insn, it's dfa state is copied to the fallthru bb. This was resulting in -fcompare-debug failure as the incoming dfa state of the fallthru block is different with -g. We should always copy the dfa state of a bb to it's fallthru bb even if the bb does not contain real insns. 2022-08-22 Surya Kumari Jangala gcc/ PR rtl-optimization/105586 * sched-rgn.cc (save_state_for_fallthru_edge): New function. (schedule_region): Use it for all blocks. gcc/testsuite/ PR rtl-optimization/105586 * gcc.target/powerpc/pr105586.c: New test.
[Bug libstdc++/106873] New: unsigned short skips byte when used for memory mapping depending on position in structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106873
Bug ID: 106873
Summary: unsigned short skips byte when used for memory mapping
depending on position in structure
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: info at kemalakcam dot com
Target Milestone: ---
Please move to the correct component in reporting menu as this problem is not
necessarily c++
//
// File: ka_example_pointer.cpp
// Desc: Software programming example of pointers
// Date: 2020/12/25 Ali Kemal Akçam - ka_example_pointer.cpp created.
//
// source code shortened to report bug.
// memory mapping with unsigned short does not show intented result.
// both 'unsigned short' and 'unsigned short int' skips one byte depending on
position
// tested with
// gcc --version
// (Debian 4.9.2-10) 4.9.2
// (Debian 8.3.0-6) 8.3.0
// 12.1.0
// gcc version 4.9.2 compiled as
// gcc -lstdc++ -std=c++11 ka_example_pointer_very_brief.cpp -o
ka_example_pointer_very_brief.o
// gcc version 12.1.0 compiled as
// gcc -lstdc++ ka_example_pointer_very_brief.cpp -o
ka_example_pointer_very_brief.o
#include
typedef struct
{
unsigned char a; // 1 byte
unsigned char b; // 1 byte
unsigned char c; // 1 byte
unsigned char d; // 1 byte
unsigned char e; // 1 byte
unsigned char f; // 1 byte
unsigned char g; // 1 byte
unsigned char h; // 1 byte
} tsMMP_bytes; // 8 bytes
typedef struct
{
unsigned char a; // 1 byte
unsigned short b; // 2 bytes - skips one byte here
unsigned char c; // 1 byte
unsigned char d; // 1 byte
unsigned short e; // 2 bytes - does not skip one byte here
unsigned char f; // 1 byte
} tsMMP_mixed; // 8 bytes
typedef struct
{
unsigned char a; // 1 byte
unsigned char b; // 1 byte
unsigned short c; // 2 bytes - does not skip one byte here
unsigned char d; // 1 byte
unsigned short e; // 2 bytes - skips one byte here
unsigned char f; // 1 byte
} tsMMP_mixed2;// 8 bytes
typedef struct
{
unsigned char a; // 1 byte
unsigned short b; // 2 bytes - skips one byte here
unsigned char c; // 1 byte
unsigned short d; // 2 bytes - skips one byte here
unsigned char e; // 1 byte
unsigned char f; // 1 byte
} tsMMP_mixed3;// 8 bytes
typedef struct
{
unsigned char l;
char h;
} tsWord; // signed word DOES NOT WORK!
typedef struct
{
unsigned char a; // 1 byte
tsWord b; // 2 bytes - works properly
unsigned char c; // 1 byte
unsigned char d; // 1 byte
tsWord e; // 2 bytes - works properly
unsigned char f; // 1 byte
} tsMMP_mixed_struct_word; // 8 bytes - correctly maps to another linear
memory
// 20201225T0311 : Kemal Akcam : Mixed typedef struct works perfectly while
using as memory stencil for memory mapping.
typedef struct
{
unsigned char a;
unsigned char b;
} tsShort;
typedef struct
{
unsigned char a; // 1 byte
tsShortb; // 2 bytes - works properly
unsigned char c; // 1 byte
unsigned char d; // 1 byte
tsShorte; // 2 bytes - works properly
unsigned char f; // 1 byte
} tsMMP_mixed_struct; // 8 bytes - correctly maps to another linear memory
class c
{
public:
c(){};
~c(){};
unsigned char m[16] = { 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
0x18, 0x19, 0x20, 0x21, 0x22, 0x23, 0x24, 0x25 };
void printContent(void);
};
void c::printContent(void)
{
int i;
printf("Memory content ");
for(i=0; i<16; i++) printf("%X ", m[i]);
printf("\n");
printf("tsMMP_bytes");
tsMMP_bytes *pB;
pB = (tsMMP_bytes *)&m;
printf("%X %X %X %X %X %X %X %X ",
pB->a,
pB->b,
pB->c,
pB->d,
pB->e,
pB->f,
pB->g,
pB->h);
printf("\n");
{
printf("tsMMP_mixed");
tsMMP_mixed *pM;
pM = (tsMMP_mixed *)&m;
printf("%X %X %X %X %X %X <--- 11 is NOT there",
pM->a,
pM->b,
pM->c,
pM->d,
pM->e,
pM->f);
printf("\n");
}
{
printf("tsMMP_mixed2 ");
tsMMP_mixed2 *pM;
pM = (tsMMP_mixed2 *)&m;
printf("%X %X %X %X %X %X <--- 15 is NOT there",
pM->a,
pM->b,
pM->c,
pM->d,
pM->e,
pM->f);
printf("\n");
}
{
printf("tsMMP_mixed3 ");
tsMMP_mixed3 *pM;
pM = (tsMMP_mixed3 *)&m;
printf("%X %X %X %X %X %X <--- 11 and 15 is NOT there",
pM->a,
[Bug c++/106873] unsigned short skips byte when used for memory mapping depending on position in structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106873
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Andrew Pinski ---
I think you need to use bitfields to get this exact layout or use the attribute
packed.
With -Wpadded I get the following warnings:
:19:17: warning: padding struct to align '::b'
[-Wpadded]
19 | unsigned short b; // 2 bytes - skips one byte here
| ^
:17:1: warning: padding struct size to alignment boundary [-Wpadded]
17 | {
| ^
:32:17: warning: padding struct to align '::e'
[-Wpadded]
32 | unsigned short e; // 2 bytes - skips one byte here
| ^
:27:1: warning: padding struct size to alignment boundary [-Wpadded]
27 | {
| ^
:39:17: warning: padding struct to align '::b'
[-Wpadded]
39 | unsigned short b; // 2 bytes - skips one byte here
| ^
:41:17: warning: padding struct to align '::d'
[-Wpadded]
41 | unsigned short d; // 2 bytes - skips one byte here
| ^
Which I think is what you are missing is that the ABI is layed out this way.
[Bug c++/106873] unsigned short skips byte when used for memory mapping depending on position in structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106873 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Which I think is what you are missing is that the ABI is layed out this way. The reason why it is layout this way is for alignment reasons. In many ABIs, the alignment of short is 2 bytes; the natural alignment.
[Bug c++/106873] unsigned short skips byte when used for memory mapping depending on position in structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106873 --- Comment #3 from Kemal Akcam --- I did not report as if unsigned short was different than 2 bytes. Please check the output and explain 1. why output values changes? 2. why it reads/advances 10 bytes instead of 8 bytes?
[Bug c++/106873] unsigned short skips byte when used for memory mapping depending on position in structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106873 --- Comment #4 from Andrew Pinski --- (In reply to Kemal Akcam from comment #3) > I did not report as if unsigned short was different than 2 bytes. > > Please check the output and explain > 1. why output values changes? > 2. why it reads/advances 10 bytes instead of 8 bytes? Again you misunderstand everything. The ABI has a requirement for alignment of some fields and that is what is called padding. This is why I said you get a warning with -Wpadding . If you want to remove this padding, you either use a bitfield or you use the attribute packed.
[Bug c++/106873] unsigned short skips byte when used for memory mapping depending on position in structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106873 --- Comment #5 from Jonathan Wakely --- Read https://en.cppreference.com/w/c/language/object#Alignment (for C) and https://en.cppreference.com/w/cpp/language/object#Alignment (for C++). Instead of filing bugs like this and PR 106869, please find somewhere more suitable to learn how C++ works. Both your "bugs" would be appropriate as questions on StackOverflow (in fact they have probably already been answered there, and you could find the answers by searching). "I find GCC's behaviour surprising" is not a bug.
[Bug fortran/106500] ICE on function as an argument to c_sizeof()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106500 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #2 from G. Steinmetz --- The following examples are presumably valid code, don't use a function, nor alloc, but should be related : $ cat z1.f90 program p use iso_c_binding integer :: a(2) = 0 print *, c_sizeof((a)) print *, c_sizeof(2*a) end $ cat z2.f90 program p use iso_c_binding character(1) :: a(2) = '0' print *, c_sizeof((a)) print *, c_sizeof(a) end $ gfortran-13-20220904 -c z1.f90 f951: internal compiler error: gfc_find_array_ref(): No ref found 0x7f04f9 gfc_report_diagnostic ../../gcc/fortran/error.cc:883 0x7f2077 gfc_internal_error(char const*, ...) ../../gcc/fortran/error.cc:1503 0x7c029c gfc_find_array_ref(gfc_expr*, bool) ../../gcc/fortran/array.cc:2779 0x7c1cc2 is_c_interoperable ../../gcc/fortran/check.cc:5271 0x7c8e86 gfc_check_c_sizeof(gfc_expr*) ../../gcc/fortran/check.cc:5294 0x809459 do_check ../../gcc/fortran/intrinsic.cc:4792 0x809459 check_specific ../../gcc/fortran/intrinsic.cc:4805 0x8114e4 gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.cc:5042 0x866aa8 resolve_unknown_f ../../gcc/fortran/resolve.cc:2990 0x866aa8 resolve_function ../../gcc/fortran/resolve.cc:3347 0x866aa8 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:7194 0x86cdac gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:7161 0x86cdac gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:11973 0x86b83f gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:10972 0x86bb98 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:11963 0x86e927 resolve_codes ../../gcc/fortran/resolve.cc:17616 0x86e9ee gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.cc:17651 0x8567d4 resolve_all_program_units ../../gcc/fortran/parse.cc:6605 0x8567d4 gfc_parse_file() ../../gcc/fortran/parse.cc:6861 0x8a50df gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229
[Bug c/106874] New: [10/11/12/13 Regression] out of memory allocating 9223372036854453969 bytes after a total of 462848 bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106874 Bug ID: 106874 Summary: [10/11/12/13 Regression] out of memory allocating 9223372036854453969 bytes after a total of 462848 bytes Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r7, files are from catalog llvm-project-llvmorg-14.0.6/clang/test/Preprocessor : $ cat function_macro_file.h #define f() x f $ cat function_macro_file.c #include "function_macro_file.h" () $ gcc-13-20220904 -c function_macro_file.c -traditional-cpp cc1: out of memory allocating 9223372036854277185 bytes after a total of 593920 bytes
[Bug c++/106875] New: [11/12/13 Regression] ICE in ix86_emit_outlined_ms2sysv_save, at config/i386/i386.cc:8343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106875 Bug ID: 106875 Summary: [11/12/13 Regression] ICE in ix86_emit_outlined_ms2sysv_save, at config/i386/i386.cc:8343 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started between 2024 and 20211121, at -O0, with file g++.target/i386/pr101180.C : $ g++-13-20220904 -c pr101180.C -O0 -mabi=ms -fabi-version=3 -mcall-ms2sysv-xlogues during RTL pass: pro_and_epilogue pr101180.C: In function 'void f(T, FromT) [with T = A; FromT = int]': pr101180.C:19:1: internal compiler error: in ix86_emit_outlined_ms2sysv_save, at config/i386/i386.cc:8343 19 | } | ^ 0x116e58a ix86_emit_outlined_ms2sysv_save ../../gcc/config/i386/i386.cc:8343 0x1184d2c ix86_expand_prologue() ../../gcc/config/i386/i386.cc:8919 0x162266a gen_prologue() ../../gcc/config/i386/i386.md:16194 0x11749c8 target_gen_prologue ../../gcc/config/i386/i386.md:23608 0xb77279 make_prologue_seq ../../gcc/function.cc:5826 0xb77454 thread_prologue_and_epilogue_insns() ../../gcc/function.cc:6058 0xb77a32 rest_of_handle_thread_prologue_and_epilogue ../../gcc/function.cc:6549 0xb77a32 execute ../../gcc/function.cc:6625
[Bug c++/106876] New: [13 Regression] ICE in extract_insn, at recog.cc:2791
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106876
Bug ID: 106876
Summary: [13 Regression] ICE in extract_insn, at recog.cc:2791
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20220508 and 20220515, with file g++.dg/lookup/friend23.C :
$ cat friend23.C
template
struct base {
friend void bar(Derived& d) {
d.bar(); // access in inline friend of friend, ok?
}
};
class derived : base {
friend class base;
void bar() {}
};
int main() {
derived d;
bar(d);
}
$ g++-13-20220904 -c friend23.C -mforce-indirect-call -fPIC -fprofile-generate
friend23.C: In member function 'void derived::bar()':
friend23.C:10:15: error: unrecognizable insn:
10 | void bar() {}
| ^
(call_insn/u 6 3 7 2 (parallel [
(set (reg:DI 0 ax)
(call:DI (mem:QI (symbol_ref:DI ("__tls_get_addr")) [0 S1 A8])
(const_int 0 [0])))
(unspec:DI [
(symbol_ref:DI ("__gcov_indirect_call") [flags 0x50]
)
(reg/f:DI 7 sp)
] UNSPEC_TLS_GD)
]) -1
(expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
(nil))
(nil))
during RTL pass: vregs
friend23.C:10:15: internal compiler error: in extract_insn, at recog.cc:2791
0x6f0204 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.cc:108
0x6f0223 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/rtl-error.cc:116
0x110e617 extract_insn(rtx_insn*)
../../gcc/recog.cc:2791
0xe07089 instantiate_virtual_regs_in_insn
../../gcc/function.cc:1660
0xe07089 instantiate_virtual_regs
../../gcc/function.cc:1985
0xe07089 execute
../../gcc/function.cc:2034
[Bug c++/106877] New: [12/13 Regression] ICE in move_for_stack_reg, at reg-stack.cc:1076
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106877
Bug ID: 106877
Summary: [12/13 Regression] ICE in move_for_stack_reg, at
reg-stack.cc:1076
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with r12 before 20210502, at -O or -O1,
with file g++.dg/ext/pr84683.C or pr84828.C :
$ g++-13-20220904 -c pr84683.C -O1 -m16 -mtune=sandybridge
-flive-range-shrinkage -fno-dce
pr84683.C: In function 'void foo(float, double)':
pr84683.C:10:7: error: output constraint 0 must specify a single register
10 | asm volatile ("" : "+f" (c)); // { dg-error "must specify a
single register" }
| ^~~
during RTL pass: stack
pr84683.C:13:1: internal compiler error: in move_for_stack_reg, at
reg-stack.cc:1076
13 | }
| ^
0x11163b0 move_for_stack_reg
../../gcc/reg-stack.cc:1076
0x1117aca subst_stack_regs
../../gcc/reg-stack.cc:2457
0x1117c78 convert_regs_1
../../gcc/reg-stack.cc:3091
0x1117c78 convert_regs_2
../../gcc/reg-stack.cc:3225
0x1119b88 convert_regs
../../gcc/reg-stack.cc:3260
0x1119b88 reg_to_stack
../../gcc/reg-stack.cc:3385
0x1119b88 rest_of_handle_stack_regs
../../gcc/reg-stack.cc:3441
0x1119b88 execute
../../gcc/reg-stack.cc:3473
[Bug tree-optimization/106878] New: ICE: verify_gimple failed at -O2 on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106878
Bug ID: 106878
Summary: ICE: verify_gimple failed at -O2 on arm-none-eabi
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails for GCC 11 and above (indeed still on the trunk):
$ gcc/xgcc -B gcc -v
Reading specs from gcc/specs
COLLECT_GCC=gcc/xgcc
COLLECT_LTO_WRAPPER=gcc/lto-wrapper
Target: arm-none-eabi
Configured with: /home/alecop01/toolchain/src/gcc/configure
--prefix=/data_sdb/toolchain/cc1s/dbg-arm --enable-languages=c,c++
--disable-bootstrap --target=arm-none-eabi
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220907 (experimental) (GCC)
$ cat t.c
int a;
void b(const int *c) {
unsigned d = ((long)c | (long)&a) & 65535 << 16;
long e = (long)c;
if (d != (e & 65535 << 16))
return;
}
$ gcc/xgcc -B gcc -c t.c -O2 -S -o /dev/null
t.c: In function ‘b’:
t.c:7:1: error: invalid types for ‘bit_not_expr’
7 | }
| ^
const int *
const int *
_12 = ~c_7(D);
during GIMPLE pass: forwprop
t.c:7:1: internal compiler error: verify_gimple failed
0xe0c855 verify_gimple_in_cfg(function*, bool)
/home/alecop01/toolchain/src/gcc/gcc/tree-cfg.cc:5568
0xca78be execute_function_todo
/home/alecop01/toolchain/src/gcc/gcc/passes.cc:2091
0xca8342 execute_todo
/home/alecop01/toolchain/src/gcc/gcc/passes.cc:2145
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ gcc/xgcc -B gcc -c t.c -O2 -S -o /dev/null -fno-checking
during GIMPLE pass: evrp
t.c: In function ‘b’:
t.c:7:1: internal compiler error: Segmentation fault
7 | }
| ^
0xdb06ef crash_signal
/home/alecop01/toolchain/src/gcc/gcc/toplev.cc:314
0x1a70ca1 range_op_handler::fold_range(vrange&, tree_node*, vrange const&,
vrange const&, relation_kind_t) const
/home/alecop01/toolchain/src/gcc/gcc/range-op.cc:4217
0x1a755cb operator_bitwise_not::fold_range(irange&, tree_node*, irange const&,
irange const&, relation_kind_t) const
/home/alecop01/toolchain/src/gcc/gcc/range-op.cc:3507
0x1948cd7 fold_using_range::range_of_range_op(vrange&, gimple*, fur_source&)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range-fold.cc:611
0x194ae68 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range-fold.cc:555
0x19358ec gimple_ranger::fold_range_internal(vrange&, gimple*, tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range.cc:258
0x19371f0 gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/gimple-range.cc:319
0x113ec83 range_query::value_of_stmt(gimple*, tree_node*)
/home/alecop01/toolchain/src/gcc/gcc/value-query.cc:135
0xfcda70 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-propagate.cc:816
0x18f9e47 dom_walker::walk(basic_block_def*)
/home/alecop01/toolchain/src/gcc/gcc/domwalk.cc:311
0xfcc8b5 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-propagate.cc:987
0x10f3430 execute_ranger_vrp(function*, bool)
/home/alecop01/toolchain/src/gcc/gcc/tree-vrp.cc:4349
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug testsuite/106879] New: [13 regression] new test case gcc.dg/vect/bb-slp-layout-19.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106879 Bug ID: 106879 Summary: [13 regression] new test case gcc.dg/vect/bb-slp-layout-19.c fails Product: gcc Version: 13.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:eab511df13ca6abb24c3c2abb0f420a89c91e310, r13-2377-geab511df13ca6a make -k check-gcc RUNTESTFLAGS="vect.exp=gcc.dg/vect/bb-slp-layout-19.c" FAIL: gcc.dg/vect/bb-slp-layout-19.c -flto -ffat-lto-objects scan-tree-dump-times slp1 "add new stmt: [^\\n\\r]* = VEC_PERM_EXPR" 3 FAIL: gcc.dg/vect/bb-slp-layout-19.c -flto -ffat-lto-objects scan-tree-dump-times slp1 "add new stmt: [^\\n\\r]* = VEC_PERM_EXPR" 3 FAIL: gcc.dg/vect/bb-slp-layout-19.c scan-tree-dump-times slp1 "add new stmt: [^\\n\\r]* = VEC_PERM_EXPR" 3 FAIL: gcc.dg/vect/bb-slp-layout-19.c scan-tree-dump-times slp1 "add new stmt: [^\\n\\r]* = VEC_PERM_EXPR" 3 This is on powerpc64 BE. It works fine on LE. This one fails too. FAIL: gcc.dg/vect/bb-slp-layout-20.c -flto -ffat-lto-objects scan-tree-dump-times slp1 "add new stmt: [^\\n\\r]* = VEC_PERM_EXPR" 3 FAIL: gcc.dg/vect/bb-slp-layout-20.c -flto -ffat-lto-objects scan-tree-dump-times slp1 "add new stmt: [^\\n\\r]* = VEC_PERM_EXPR" 3 FAIL: gcc.dg/vect/bb-slp-layout-20.c scan-tree-dump-times slp1 "add new stmt: [^\\n\\r]* = VEC_PERM_EXPR" 3 FAIL: gcc.dg/vect/bb-slp-layout-20.c scan-tree-dump-times slp1 "add new stmt: [^\\n\\r]* = VEC_PERM_EXPR" 3 ESC[33mcommit eab511df13ca6abb24c3c2abb0f420a89c91e310ESC[m Author: Richard Sandiford Date: Fri Sep 2 14:00:14 2022 +0100 vect: Ensure SLP nodes don't end up in multiple BB partitions [PR106787]
[Bug c++/106793] poor diagnostic for missing template argument list on function parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106793 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |13.0 Status|ASSIGNED|RESOLVED --- Comment #6 from Jason Merrill --- Fixed.
[Bug c++/106793] poor diagnostic for missing template argument list on function parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106793 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b9cb441c98f265bff86a1c228932524c5fd37dd3 commit r13-2527-gb9cb441c98f265bff86a1c228932524c5fd37dd3 Author: Jason Merrill Date: Fri Sep 2 08:45:02 2022 -0400 c++: diagnostic for template placeholder in parm [PR106793] Talking about the declarator form doesn't help when fixing that would get you a different error about placeholders not being valid in a parameter. This also adds a <> fixit, which isn't enough for most templates, but is a start. PR c++/106793 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Improve placeholder diagnostics. * parser.cc (cp_parser_type_id_1): Add fixit. gcc/testsuite/ChangeLog: * g++.dg/cpp23/auto-array2.C: Adjust. * g++.dg/cpp1z/class-deduction113.C: New test.
[Bug tree-optimization/106878] [11/12/13 Regression] ICE: verify_gimple failed at -O2 on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106878 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.4 Summary|ICE: verify_gimple failed |[11/12/13 Regression] ICE: |at -O2 on arm-none-eabi |verify_gimple failed at -O2 ||on arm-none-eabi Known to work||10.1.0, 10.4.0 Ever confirmed|0 |1 Last reconfirmed||2022-09-07 Target|arm-*-* |arm-*-* x86_64-linux-gnu ||i?86-linux-gnu Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Fails on x86_64 with -m32. Also it worked in GCC 10.4.0 (I checked the IR to see there was no BIT_NOT_EXPR too).
[Bug c++/106863] ICE in write_template_arg_literal, at cp/mangle.cc:3678 since r12-4782-geca767aa51d1f696
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106863
--- Comment #2 from jehova at existiert dot net ---
I'm not sure if 'ice-on-valid-code' is appropriate here, since the example code
is *not* valid.
It is if 'void{}' is replaced by 'void()' (which is perfectly accepted by GCC).
[Bug libstdc++/104443] common_iterator::operator-> is not correctly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104443 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c5038b792525fedeb0297189516d0157ba98c1d1 commit r11-10240-gc5038b792525fedeb0297189516d0157ba98c1d1 Author: Jonathan Wakely Date: Thu Jul 28 20:55:51 2022 +0100 libstdc++: Tweak common_iterator::operator-> return type [PR104443] This adjusts the return type to match the resolution of LWG 3672. There is no functional difference, because decltype(auto) always deduced a value anyway, but this makes it simpler and consistent with the working draft. libstdc++-v3/ChangeLog: PR libstdc++/104443 * include/bits/stl_iterator.h (common_iterator::operator->): Change return type to just auto. (cherry picked from commit b5f5d1b36edbcd7d923f2e2653e54e52637c715b)
[Bug libstdc++/106695] [11/12 Regression] Explicit copy constructor does not work for a parameter passed via std::async
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106695 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:da67352690c8ed7f3045487e6e1ea391aeab7fc8 commit r11-10242-gda67352690c8ed7f3045487e6e1ea391aeab7fc8 Author: Jonathan Wakely Date: Mon Aug 22 15:42:17 2022 +0100 libstdc++: Fix for explicit copy ctors in and [PR106695] When I changed std::thread and std::async to avoid unnecessary move construction of temporaries, I introduced a regression where types with an explicit copy constructor could not be passed to std::thread or std::async. The fix is to add a constructor instead of using aggregate initialization of an unnamed temporary. libstdc++-v3/ChangeLog: PR libstdc++/106695 * include/bits/std_thread.h (thread::_State_impl): Forward individual arguments to _Invoker constructor. (thread::_Invoker): Add constructor. Delete copies. * include/std/future (__future_base::_Deferred_state): Forward individual arguments to _Invoker constructor. (__future_base::_Async_state_impl): Likewise. * testsuite/30_threads/async/106695.cc: New test. * testsuite/30_threads/thread/106695.cc: New test. (cherry picked from commit 5abe0657553580bd1b7488dd84d55138a8d9f23c)
[Bug libstdc++/106607] Regex integer overflow on large backreference value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106607 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d023d805d9e20c3f46654dc7ea96c9228d650ddb commit r11-10243-gd023d805d9e20c3f46654dc7ea96c9228d650ddb Author: Jonathan Wakely Date: Mon Aug 22 15:16:16 2022 +0100 libstdc++: Check for overflow in regex back-reference [PR106607] Currently we fail to notice integer overflow when parsing a back-reference expression, or when converting the parsed result from long to int. This changes the result to be int, so no conversion is needed, and uses the overflow-checking built-ins to detect an out-of-range back-reference. libstdc++-v3/ChangeLog: PR libstdc++/106607 * include/bits/regex_compiler.tcc (_Compiler::_M_cur_int_value): Use built-ins to check for integer overflow in back-reference number. * testsuite/28_regex/basic_regex/106607.cc: New test. (cherry picked from commit 1b09eea33f2bf9d1eae73b25cc25efb05ea1dc3f)
[Bug libstdc++/106248] [11 Regression] operator>>std::basic_istream at boundary condition behave differently in different opt levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106248 --- Comment #12 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3d17eaabb3e771472d7bfa1f654564a5db57f5ef commit r11-10241-g3d17eaabb3e771472d7bfa1f654564a5db57f5ef Author: Jonathan Wakely Date: Tue Jul 12 11:18:47 2022 +0100 libstdc++: Check for EOF if extraction avoids buffer overflow [PR106248] In r11-2581-g17abcc77341584 (for LWG 2499) I added overflow checks to the pre-C++20 operator>>(istream&, char*) overload. Those checks can cause extraction to stop after filling the buffer, where previously it would have tried to extract another character and stopped at EOF. When that happens we no longer set eofbit in the stream state, which is consistent with the behaviour of the new C++20 overload, but is an observable and unexpected change in the C++17 behaviour. What makes it worse is that the behaviour change is dependent on optimization, because __builtin_object_size is used to detect the buffer size and that only works when optimizing. To avoid the unexpected and optimization-dependent change in behaviour, set eofbit manually if we stopped extracting because of the buffer size check, but had reached EOF anyway. If the stream's rdstate() != goodbit or width() is non-zero and smaller than the buffer, there's nothing to do. Otherwise, we filled the buffer and need to check for EOF, and maybe set eofbit. The new check is guarded by #ifdef __OPTIMIZE__ because otherwise __builtin_object_size is useless. There's no point compiling and emitting dead code that can't be eliminated because we're not optimizing. We could add extra checks that the next character in the buffer is not whitespace, to detect the case where we stopped early and prevented a buffer overflow that would have happened otherwise. That would allow us to assert or set badbit in the stream state when undefined behaviour was prevented. However, those extra checks would increase the size of the function, potentially reducing the likelihood of it being inlined, and so making the buffer size detection less reliable. It seems preferable to prevent UB and silently truncate, rather than miss the UB and allow the overflow to happen. libstdc++-v3/ChangeLog: PR libstdc++/106248 * include/std/istream [C++17] (operator>>(istream&, char*)): Set eofbit if we stopped extracting at EOF. * testsuite/27_io/basic_istream/extractors_character/char/pr106248.cc: New test. * testsuite/27_io/basic_istream/extractors_character/wchar_t/pr106248.cc: New test. (cherry picked from commit 5ae74944af1de032d4a27fad4a2287bd3a2163fd)
[Bug libstdc++/104443] common_iterator::operator-> is not correctly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104443 Jonathan Wakely changed: What|Removed |Added Target Milestone|12.2|11.4 --- Comment #9 from Jonathan Wakely --- And for 11.4
[Bug libstdc++/106248] [11 Regression] operator>>std::basic_istream at boundary condition behave differently in different opt levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106248 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Jonathan Wakely --- Fixed for 11.4
[Bug libstdc++/106695] [11/12 Regression] Explicit copy constructor does not work for a parameter passed via std::async
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106695 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jonathan Wakely --- Fixed for 12.3 and 11.4
[Bug libstdc++/106607] Regex integer overflow on large backreference value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106607 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.4 --- Comment #4 from Jonathan Wakely --- Fixed for 12.3 and 11.4
[Bug c++/106880] New: [12/13 Regression] "error: use of deleted function" printed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106880
Bug ID: 106880
Summary: [12/13 Regression] "error: use of deleted function"
printed twice
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: ppalka at gcc dot gnu.org
Target Milestone: ---
Since r12-295 we print the error twice for this code:
namespace x {
void foo() = delete;
}
template
void f(T t)
{
using x::foo;
foo(t);
}
void g()
{
f(1);
}
dup.C: In instantiation of 'void f(T) [with T = int]':
dup.C:14:4: required from here
dup.C:9:6: error: use of deleted function 'void x::foo()'
9 | foo(t);
| ~~~^~~
dup.C:2:6: note: declared here
2 | void foo() = delete;
| ^~~
dup.C:9:6: error: use of deleted function 'void x::foo()'
9 | foo(t);
| ~~~^~~
dup.C:2:6: note: declared here
2 | void foo() = delete;
| ^~~
[Bug c++/106880] [12/13 Regression] "error: use of deleted function" printed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106880 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-09-07
[Bug c++/106880] [12/13 Regression] "error: use of deleted function" printed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106880 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.3
[Bug fortran/106500] ICE on function as an argument to c_sizeof()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106500
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Priority|P3 |P4
Last reconfirmed||2022-09-07
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #2)
> The following examples are presumably valid code,
> don't use a function, nor alloc, but should be related :
>
>
> $ cat z1.f90
> program p
>use iso_c_binding
>integer :: a(2) = 0
>print *, c_sizeof((a))
>print *, c_sizeof(2*a)
> end
>
>
> $ cat z2.f90
> program p
>use iso_c_binding
>character(1) :: a(2) = '0'
>print *, c_sizeof((a))
>print *, c_sizeof(a)
> end
>
The above testcases compile with this patch.
diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index bbdb5b392fc..f5fed223a23 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -2766,7 +2766,24 @@ gfc_find_array_ref (gfc_expr *e, bool allow_null)
{
gfc_ref *ref;
- for (ref = e->ref; ref; ref = ref->next)
+ if (e->expr_type == EXPR_OP && !e->ref)
+{
+ gfc_expr *op1, *op2;
+ op1 = e->value.op.op1;
+ op2 = e->value.op.op2;
+ if (!op2)
+ {
+ if (op1->rank == 0)
+ return NULL;
+ ref = op1->ref;
+ }
+ else
+ ref = op2->ref;
+}
+ else
+ref = e->ref;
+
+ for (; ref; ref = ref->next)
if (ref->type == REF_ARRAY
&& (ref->u.ar.type == AR_FULL || ref->u.ar.type == AR_SECTION))
break;
[Bug c/106881] New: ice in init_from_control_deps, at gimple-predicate-analysis.cc:1740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106881 Bug ID: 106881 Summary: ice in init_from_control_deps, at gimple-predicate-analysis.cc:1740 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 53546 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53546&action=edit C source code The attached C code does this: /home/dcb/gcc/results/bin/gcc -c -O1 -Wall -fexceptions bug843.c during GIMPLE pass: uninit src/eap-gtc.c: In function ‘eap_gtc_check_settings’: src/eap-gtc.c:74:12: internal compiler error: in init_from_control_deps, at gimple-predicate-analysis.cc:1740 0x1b161f5 predicate::init_from_control_deps(vec const*, unsigned int, bool) ../../trunk.git/gcc/gimple-predicate-analysis.cc:1740 0x1b16974 uninit_analysis::init_use_preds(predicate&, basic_block_def*, basic_block_def*) ../../trunk.git/gcc/gimple-predicate-analysis.cc:1996 I will have a go at producing a git range and a reduction.
[Bug c/106881] ice in init_from_control_deps, at gimple-predicate-analysis.cc:1740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106881 --- Comment #1 from David Binderman --- Git range seems to be d6582c662ca0da05..cdcc27c1ca9c485c, i.e. since yesterday.
[Bug c/106881] ice in init_from_control_deps, at gimple-predicate-analysis.cc:1740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106881
--- Comment #2 from David Binderman ---
Reduced C code seems to be:
inline auto_free(void *a) {
void **p = a;
l_free(*p);
}
eap_gtc_check_settings() {
char *identity __attribute__((cleanup(auto_free)));
char password __attribute__((cleanup(auto_free)));
identity = l_settings_get_string();
eap_append_secret();
}
[Bug tree-optimization/106881] [13 Regression] ice in init_from_control_deps, at gimple-predicate-analysis.cc:1740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106881 Andrew Pinski changed: What|Removed |Added Summary|ice in |[13 Regression] ice in |init_from_control_deps, at |init_from_control_deps, at |gimple-predicate-analysis.c |gimple-predicate-analysis.c |c:1740 |c:1740 Keywords||diagnostic, ||ice-on-valid-code Version|12.0|13.0 Target Milestone|--- |13.0 Component|c |tree-optimization
[Bug tree-optimization/106881] [13 Regression] ice in init_from_control_deps, at gimple-predicate-analysis.cc:1740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106881 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106866 --- Comment #3 from Andrew Pinski --- Are you sure this was not already fixed by r13-2518-ga262f969d6fd936f4fb5 (aka PR 106866)
[Bug tree-optimization/106878] [11/12/13 Regression] ICE: verify_gimple failed at -O2 with pointers and bitwise caluclation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106878 Alex Coplan changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Alex Coplan --- Started with r11-35-g496f4f884716ae061f771a62e44868a32dbd502f commit 496f4f884716ae061f771a62e44868a32dbd502f Author: Jakub Jelinek Date: Mon May 4 11:01:08 2020 +0200 match.pd: Decrease number of nop conversions around bitwise ops [PR94718]
[Bug tree-optimization/106878] [11/12/13 Regression] ICE: verify_gimple failed at -O2 with pointers and bitwise caluclation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106878 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug c++/106829] [12/13 Regression] OpenMP offload internal compiler error: in gimplify_expr, at gimplify.cc:16222 since r12-5835
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106829 Ye Luo changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Ye Luo --- Now all works well in my tests.
[Bug tree-optimization/106881] [13 Regression] ice in init_from_control_deps, at gimple-predicate-analysis.cc:1740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106881 --- Comment #4 from David Binderman --- (In reply to Andrew Pinski from comment #3) > Are you sure this was not already fixed by r13-2518-ga262f969d6fd936f4fb5 > (aka PR 106866) Pretty sure. The git range I gave includes this commit. Feel free to check. It is not unknown for me to make an error with git.
