[Bug c/106843] gcc with -O2 corrupt data on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106843 --- Comment #7 from Dave A --- -fsanitize=address balked on the executable even without the -O2, even though it printed out the correct values. The stack must have been initialzed and the values persisted after the variable went out of scope. In retrospect I'm surprised this ever worked. I have a vague memory of copying this "trick" from libSDL source. Thanks for investigating.
[Bug c/106830] [13 Regression] ICE: in tree_to_uhwi, at tree.cc:6392 (from check_for_xor_used_as_pow) since r13-2386-gbedfca647a9e9c1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106830
--- Comment #3 from Zdenek Sojka ---
(In reply to Jakub Jelinek from comment #1)
> I certainly see a valgrind diagnostics on it:
> valgrind ./cc1 -quiet pr106830.c
> ==2461995== Memcheck, a memory error detector
> ==2461995== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
> ==2461995== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright
> info
> ==2461995== Command: ./cc1 -quiet pr106830.c
> ==2461995==
> pr106830.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
> 1 | foo0_u16_0() {
> | ^~
> pr106830.c: In function ‘foo0_u16_0’:
> pr106830.c:2:14: warning: integer constant is so large that it is unsigned
> 2 | (__int128)(18302628885633695743 << 4) ^ 0;
> | ^~~~
> ==2461995== Conditional jump or move depends on uninitialised value(s)
> ==2461995==at 0xAFCE3D: parser_build_binary_op(unsigned int, tree_code,
> c_expr, c_expr) (c-typeck.cc:3992)
> ==2461995==by 0xB4ABA2: c_parser_binary_expression(c_parser*, c_expr*,
> tree_node*) (c-parser.cc:8083)
> ==2461995==by 0xB486A3: c_parser_conditional_expression(c_parser*,
> c_expr*, tree_node*) (c-parser.cc:7651)
> ==2461995==by 0xB48308: c_parser_expr_no_commas(c_parser*, c_expr*,
> tree_node*) (c-parser.cc:7565)
>
> so pressumably arg1.m_decimal is uninitialized.
>
Ah right, my fault, I forgot to add --trace-children=yes, and run valgrind on
the gcc binary instead... thanks.
[Bug tree-optimization/106842] [12 Regression] misleading warning : iteration X invokes undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106842 --- Comment #3 from Andrew Pinski --- (In reply to Martin Liška from comment #2) > Fixed on master with r13-2076-g9594e04e4e2abeb4, started with > r12-5183-ga7753db4a7c071fe. Would make sense really but that might mean a latent bug in the code in pre for the comparing of duplicated bbs when the only difference is decl uids too
[Bug tree-optimization/106842] [12 Regression] misleading warning : iteration X invokes undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106842 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-09-06 CC||marxin at gcc dot gnu.org Keywords|needs-bisection | --- Comment #2 from Martin Liška --- Fixed on master with r13-2076-g9594e04e4e2abeb4, started with r12-5183-ga7753db4a7c071fe.
[Bug c++/106841] [12/13 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1509 since r12-2733-g31855ba6b16cd138
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106841
Martin Liška changed:
What|Removed |Added
Summary|ice in |[12/13 Regression] ICE in
|vect_get_vec_defs_for_opera |vect_get_vec_defs_for_opera
|nd, at |nd, at
|tree-vect-stmts.cc:1509 |tree-vect-stmts.cc:1509
||since
||r12-2733-g31855ba6b16cd138
Status|UNCONFIRMED |NEW
Target Milestone|--- |12.3
Last reconfirmed||2022-09-06
CC||marxin at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Martin Liška ---
Thanks for the report!
Reduced to:
$ cat pr106841.C
struct R3 {
double z;
R3(R3 A, R3 B) : z(B.z - A.z) {}
double norme() { return z; }
};
struct TBoundaryEdge {
int *vertices[2];
int &operator[](int i) { return *vertices[i]; }
};
struct Mesh {
int vertices;
TBoundaryEdge *bedges;
int operator()(int &vv) { return &vv - &vertices; }
TBoundaryEdge be(int i) { return bedges[i]; }
};
template struct GenericElement {
typedef typename Data::V Vertex;
static const int nv = Data::NbOfVertices;
Vertex *vertices[nv];
double mes;
void set(int *iv) {
Vertex *v0;
for (int i = 0; i < nv; ++i)
vertices[i] = v0 + iv[i];
mes = Data::mesure(vertices);
}
};
struct DataSeg3 {
static const int NbOfVertices = 2;
typedef R3 V;
static double mesure(V *pv[]) { return R3(*pv[0], *pv[1]).norme(); }
};
struct MeshS {
MeshS();
};
template struct Movemesh_Op { int operator()() const; };
template <> int Movemesh_Op::operator()() const {
Mesh pTh;
GenericElement *bS = new GenericElement;
for (int ibe; ibe; ibe++) {
TBoundaryEdge K(pTh.be(ibe));
int iv[2];
for (int i = 0; i < 2; i++) {
int &__trans_tmp_2 = K[i];
iv[i] = pTh(__trans_tmp_2);
}
bS[ibe].set(iv);
}
MeshS T_Th;
}
$ g++ pr106841.C -c -w -O3 -ffast-math -march=bdver2
during GIMPLE pass: vect
pr106841.C: In member function ‘int Movemesh_Op<
>::operator()() const [with = int]’:
pr106841.C:37:17: internal compiler error: in vect_get_vec_defs_for_operand, at
tree-vect-stmts.cc:1509
37 | template <> int Movemesh_Op::operator()() const {
| ^~~~
0x9ea8b8 vect_get_vec_defs_for_operand(vec_info*, _stmt_vec_info*, unsigned
int, tree_node*, vec*, tree_node*)
/home/marxin/Programming/gcc/gcc/tree-vect-stmts.cc:1509
0x2236ade vect_get_gather_scatter_ops
/home/marxin/Programming/gcc/gcc/tree-vect-stmts.cc:3066
0x2247d85 vectorizable_load
/home/marxin/Programming/gcc/gcc/tree-vect-stmts.cc:9627
0x2250120 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/home/marxin/Programming/gcc/gcc/tree-vect-stmts.cc:11344
0x15081f1 vect_transform_loop_stmt
/home/marxin/Programming/gcc/gcc/tree-vect-loop.cc:9606
0x1523202 vect_transform_loop(_loop_vec_info*, gimple*)
/home/marxin/Programming/gcc/gcc/tree-vect-loop.cc:10042
0x15649de vect_transform_loops
/home/marxin/Programming/gcc/gcc/tree-vectorizer.cc:1007
0x1564fbf try_vectorize_loop_1
/home/marxin/Programming/gcc/gcc/tree-vectorizer.cc:1153
0x1564fbf try_vectorize_loop
/home/marxin/Programming/gcc/gcc/tree-vectorizer.cc:1183
0x1565354 execute
/home/marxin/Programming/gcc/gcc/tree-vectorizer.cc:1299
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[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 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-09-06 Ever confirmed|0 |1 Target Milestone|--- |13.0
[Bug tree-optimization/106844] New: 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
Bug ID: 106844
Summary: ICE in init_use_preds, at
gimple-predicate-analysis.cc:1944 since
r13-2436-ge9ea2688271bd0b4
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
The following crashes:
$ cat ice.c
struct {
int count;
int array[];
} fde_merge_v1;
void
fde_merge_i2() {
unsigned i1;
do
while (i1 && fde_merge_v1.array[i1 - 1])
i1--;
while (fde_merge_i2);
}
$ gcc ice.c --param=uninit-control-dep-attempts=1 -O1 -c -Wmaybe-uninitialized
during GIMPLE pass: uninit
ice.c: In function ‘fde_merge_i2’:
ice.c:7:1: internal compiler error: in init_use_preds, at
gimple-predicate-analysis.cc:1924
7 | fde_merge_i2() {
| ^~~~
0x8a35ff uninit_analysis::init_use_preds(predicate&, basic_block_def*,
basic_block_def*)
/home/marxin/Programming/gcc/gcc/gimple-predicate-analysis.cc:1924
0x1d68f8b uninit_analysis::is_use_guarded(gimple*, basic_block_def*, gphi*,
unsigned int, hash_set >*)
/home/marxin/Programming/gcc/gcc/gimple-predicate-analysis.cc:2086
0x1d69573 uninit_analysis::is_use_guarded(gimple*, basic_block_def*, gphi*,
unsigned int)
/home/marxin/Programming/gcc/gcc/gimple-predicate-analysis.cc:2127
0x11b6614 find_uninit_use
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.cc:1238
0x11b6f55 warn_uninitialized_phi
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.cc:1308
0x11b6f55 execute_late_warn_uninitialized
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.cc:1429
0x11b6f55 execute
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.cc:1446
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug preprocessor/106840] glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106840 --- Comment #3 from Martin Liška --- (In reply to Jakub Jelinek from comment #1) > See https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600940.html I know it's caused by the revision, anything you wanted to point out in particular?
[Bug middle-end/106833] Handle OPAQUE_TYPE in gimple_canonical_types_compatible_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833 --- Comment #8 from Kewen Lin --- Created attachment 53542 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53542&action=edit Specially handle opaque type in verify_type (In reply to Segher Boessenkool from comment #7) > (In reply to rguent...@suse.de from comment #6) > > Ah, that special "mode". I think verify_types shouldn't do anything > > for OPAQUE_TYPES or alternatively trust the targets setup of > > TYPE_MAIN_VARIANT/TYPE_CANONICAL. Maybe verify TYPE_CANONICAL > > and TYPE_MAIN_VARIANT are also OPAQUE_TYPE. > > It's probably easiest to just test if the TYPE_MODEs match, for OPAQUE_TYPEs? Thanks for suggestions from both of you! Following your suggestions, I made a patch which also considers size and alignment information which is mentioned in the documentation, does it make sense to you?
[Bug c/106843] gcc with -O2 corrupt data on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106843 --- Comment #6 from Andrew Pinski --- -fsanitize=address would have told you you used the address after it went out of scope.
[Bug c/106843] gcc with -O2 corrupt data on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106843 --- Comment #5 from Andrew Pinski --- 6.5.2.5 Compound literals 5 The value of the compound literal is that of an unnamed object initialized by the initializer list. If the compound literal occurs outside the body of a function, the object has static storage duration; otherwise, it has automatic storage duration associated with the enclosing block.
[Bug c/106843] gcc with -O2 corrupt data on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106843 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- 6.8.4 Selection statements 3 A selection statement is a block whose scope is a strict subset of the scope of its enclosing block. Each associated substatement is also a block whose scope is a strict subset of the scope of the selection statement.
[Bug c/106843] gcc with -O2 corrupt data on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106843 --- Comment #3 from Andrew Pinski --- I mean compound literal not Designated initializers.
[Bug c/106843] gcc with -O2 corrupt data on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106843 --- Comment #2 from Andrew Pinski --- The temporary that stores the Designated initializer goes out of scope at the end of the statement that is inside the if statement.
[Bug c/106843] gcc with -O2 corrupt data on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106843 --- Comment #1 from Dave A --- gcc -dumpmachine x86_64-slackware-linux gcc -v Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/11.2.0/specs COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-slackware-linux/11.2.0/lto-wrapper Target: x86_64-slackware-linux Configured with: ../configure --prefix=/usr --libdir=/usr/lib64 --mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap --enable-languages=ada,brig,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-threads=posix --enable-checking=release --enable-objc-gc --with-system-zlib --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=new --disable-libstdcxx-pch --disable-libunwind-exceptions --enable-__cxa_atexit --disable-libssp --enable-gnu-unique-object --enable-plugin --enable-lto --disable-install-libiberty --disable-werror --with-gnu-ld --with-isl --verbose --with-arch-directory=amd64 --disable-gtktest --enable-clocale=gnu --disable-multilib --target=x86_64-slackware-linux --build=x86_64-slackware-linux --host=x86_64-slackware-linux Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.2.0 (GCC)
[Bug c/106843] New: gcc with -O2 corrupt data on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106843
Bug ID: 106843
Summary: gcc with -O2 corrupt data on stack
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at linuxmotors dot com
Target Milestone: ---
Compile the following file named t.c with
gcc -O2 t.c -o t
Then run with ./t
it will print out
0 0 401060 0
or some other unexpected data. Without -O2 it prints out the correct
1 2 3 4
gcc 7.5.0 also handles this code fine with or without -O2
#include
struct rect {
int x,y,w,h;
};
void test(struct rect *r) {
if(!r) r=&(struct rect){1,2,3,4};
printf("%x %x %x %x\n", r->x, r->y, r->w, r->h);
}
int main(int argc, char **argv) {
test(0);
}
I don't know if this is useful but an objdump of the code produced is this:
00401140 :
401140: 48 8d 44 24 e8 lea-0x18(%rsp),%rax
401145: 48 85 fftest %rdi,%rdi
401148: 48 0f 44 f8 cmove %rax,%rdi
40114c: 31 c0 xor%eax,%eax
40114e: 8b 4f 08mov0x8(%rdi),%ecx
401151: 8b 57 04mov0x4(%rdi),%edx
401154: 44 8b 47 0c mov0xc(%rdi),%r8d
401158: 8b 37 mov(%rdi),%esi
40115a: bf 04 20 40 00 mov$0x402004,%edi
40115f: e9 cc fe ff ff jmp401030
401164: 66 2e 0f 1f 84 00 00cs nopw 0x0(%rax,%rax,1)
40116b: 00 00 00
40116e: 66 90 xchg %ax,%ax
It looks like the structure is being referenced on the stack but the optimizer
removed the initialization or something.
It's a linux box.
/proc/cpuinfo starts with this:
processor : 6
vendor_id : GenuineIntel
cpu family : 6
model : 94
model name : Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
stepping: 3
/etc/os-release is this:
NAME=Slackware
VERSION="15.0"
ID=slackware
VERSION_ID=15.0
PRETTY_NAME="Slackware 15.0 x86_64"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:slackware:slackware_linux:15.0"
HOME_URL="http://slackware.com/";
SUPPORT_URL="http://www.linuxquestions.org/questions/slackware-14/";
BUG_REPORT_URL="http://www.linuxquestions.org/questions/slackware-14/";
VERSION_CODENAME=stable
[Bug c/106835] [i386] Taking an address of _GLOBAL_OFFSET_TABLE_ produces a wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835 --- Comment #6 from Rui Ueyama --- If it silently produces a value that doesn't make sense, shouldn't we ban the use of the variable or at least show a warning?
[Bug tree-optimization/106842] [12 Regression] misleading warning : iteration X invokes undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106842 --- Comment #1 from Andrew Pinski --- The IR difference comes from PRE. In the case where the warning happens: find_duplicates: duplicate of find_duplicates: duplicate of find_duplicates: duplicate of vs where it does not happen: find_duplicates: duplicate of find_duplicates: duplicate of
[Bug tree-optimization/106842] [12 Regression] misleading warning : iteration X invokes undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106842 Andrew Pinski changed: What|Removed |Added Known to work||11.3.0, 13.0 Target Milestone|--- |12.3 Summary|misleading warning :|[12 Regression] misleading |iteration X invokes |warning : iteration X |undefined behavior |invokes undefined behavior Known to fail||12.1.0, 12.2.0
[Bug c/106842] New: misleading warning : iteration X invokes undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106842 Bug ID: 106842 Summary: misleading warning : iteration X invokes undefined behavior Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: franckbehaghel_gcc at protonmail dot com Target Milestone: --- Hello, I get the following misleading warning with gcc 12.2 with -O2/-O3. 11.3 seems fine. gcc -O2 main.c main.c: In function ‘main’: main.c:16:38: warning: iteration 9 invokes undefined behavior [-Waggressive-loop-optimizations] 16 |for(int64_t k =0; k
[Bug c++/106838] Built-in traits have wrong preconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106838 --- Comment #4 from Jonathan Wakely --- All traits of kind C currently reject T[] and T[1], but should accept them. That applies to: __is_empty __is_polymorphic __is_abstract __has_virtual_destructor These should accept Incomplete[] and Incomplete[1] and just return false. It's possible that the non-standard "__has_xxx" traits should also be of kind C, e.g. __has_trivial_assign(Incomplete[]) could be false, because arrays aren't assignable. But I don't really care about those ones, because the library doesn't use them (only __has_trivial_destructor, which is used for std::is_trivially_destructible, but the library can ensure we never use it with arrays, if necessary).
[Bug c++/106841] ice in vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106841 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #2 from David Binderman --- Created attachment 53541 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53541&action=edit C++ source code After a couple of hours of reduction, I have the attached code.
[Bug target/106834] GCC creates R_X86_64_GOTOFF64 for 4-bytes immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834 --- Comment #10 from Alexander Monakov --- Okay, so this should have been reported against Binutils, but since we are having the conversation here: the current behavior is not good, gas is silently selecting a different relocation kind for no clear reason. Why is it not a warning or an error? Note that if you assemble such GOT reference via NASM: extern _GLOBAL_OFFSET_TABLE_ default rel f: mov rax, [_GLOBAL_OFFSET_TABLE_ wrt ..gotpc] ret then t.o has : 0: 48 8b 05 00 00 00 00mov0x0(%rip),%rax# 7 3: R_X86_64_GOTPCREL_GLOBAL_OFFSET_TABLE_-0x4 7: c3 ret and ld -shared --no-relax -o t.so t.o does not reject it and t.so has 1000 : 1000: 48 8b 05 f1 1f 00 00mov0x1ff1(%rip),%rax# 2ff8 <_DYNAMIC+0xe0> 1007: c3 ret and without --no-relax: 1000 : 1000: 48 8d 05 f9 1f 00 00lea0x1ff9(%rip),%rax# 3000 <_GLOBAL_OFFSET_TABLE_> 1007: c3 ret So I don't see the reason why it's special-cased in gas.
[Bug c++/106838] Built-in traits have wrong preconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106838 --- Comment #3 from Jonathan Wakely --- We have three main kinds of trait preconditions. A. "T shall be a complete type, (possibly cv-qualified) void, or an array of unknown bound." This only allows T[1] is T is complete, but always allows T[], even if incomplete. The rationale here is that we can always tell if T[] is constructible, destructible, assignable etc (the answer is always no), but to tell whether T[1] is constructible we need to know about T. B. "remove_all_extents_t shall be a complete type or cv void." This only allows T[] and T[1] when T is complete. The rationale is that we need to know properties of the array element, e.g. to tell whether T[1] is an aggregate, we need to know if T is an aggregate. C. "If T is a non-union class type, T shall be a complete type." This always allows T[] and T[1], even if T is incomplete, and allows incomplete T is T is a union type. The rationale is that these traits are always false for array types, e.g. T[] is not a polymorphic type, even if T is polymorphic. Currently it seems that check_trait_type only supports preconditions of kind A, and since r13-25 it allows all arrays, when it should only allow unbounded arrays. So e.g. it doesn't reject __is_constructible(Incomplete[1]) even though it can't know the answer. I think check_trait_type could be adjusted to handle kinds A and B, by adding a bool parameter, but maybe kind C should be checked by a separate function, as it is quite different.
[Bug fortran/104314] ICE in deferred_op_assign, at fortran/resolve.cc:11794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104314 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #1) > Untested patch. Yes, that works. Even shorter: diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc index ca114750f65..3834f9a3f06 100644 --- a/gcc/fortran/resolve.cc +++ b/gcc/fortran/resolve.cc @@ -11803,6 +11803,7 @@ deferred_op_assign (gfc_code **code, gfc_namespace *ns) if (!((*code)->expr1->ts.type == BT_CHARACTER && (*code)->expr1->ts.deferred && (*code)->expr1->rank +&& (*code)->expr2->ts.type == BT_CHARACTER && (*code)->expr2->expr_type == EXPR_OP)) return false;
[Bug preprocessor/106840] glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106840 --- Comment #2 from Segher Boessenkool --- This is inside #ifdef __ASSEMBLER__ . Running assembler code (or anything else that isn't C) through the C preprocessor is the subject of one of my "why would you ever do that" rants: the assembler macro processor is strictly more capable already, and has much saner semantics (for assembler code).
[Bug fortran/100136] [11/12/13 Regression] ICE, regression, using flag -fcheck=pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100136 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from anlauf at gcc dot gnu.org --- Thanks for the report and the patch! Closing.
[Bug fortran/100136] [11/12/13 Regression] ICE, regression, using flag -fcheck=pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100136 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:4cd0cc099cf6be818f4af1f88ce11dbfe4022dab commit r11-10237-g4cd0cc099cf6be818f4af1f88ce11dbfe4022dab Author: José Rui Faustino de Sousa Date: Sun Sep 4 21:53:09 2022 +0200 Fortran: Fix ICE with -fcheck=pointer [PR100136] gcc/fortran/ChangeLog: PR fortran/100136 * trans-expr.c (gfc_conv_procedure_call): Add handling of pointer expressions. gcc/testsuite/ChangeLog: PR fortran/100136 * gfortran.dg/PR100136.f90: New test. (cherry picked from commit 20d30e737ad79dc36817e59f1676aa8bc0c6b325)
[Bug middle-end/106831] [13 Regression] mpfr-4.1.0 started failing 2 tests: tget_set_d64 and tget_set_d128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831 --- Comment #12 from joseph at codesourcery dot com --- The difference with __ibm128 is that in that case there is no semantic significance to whether the low part is +0 or -0, or what the low part is at all when the high part is a NaN. At the C level, such __ibm128 representations should be considered different representations of the same value, not different values. Whereas different DFP quantum exponents for the same real number correspond to different values that compare equal. (Noncanonical DFP encodings might be more closely analogous to the __ibm128 variants, except that most operations aren't supposed to return a noncanonical encoding even if inputs have such an encoding.)
[Bug preprocessor/106840] glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106840 --- Comment #1 from Jakub Jelinek --- See https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600940.html
[Bug fortran/100136] [11/12/13 Regression] ICE, regression, using flag -fcheck=pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100136 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c1ba36ec779cccf6b54883d676d083df627f6d64 commit r12-8743-gc1ba36ec779cccf6b54883d676d083df627f6d64 Author: José Rui Faustino de Sousa Date: Sun Sep 4 21:53:09 2022 +0200 Fortran: Fix ICE with -fcheck=pointer [PR100136] gcc/fortran/ChangeLog: PR fortran/100136 * trans-expr.cc (gfc_conv_procedure_call): Add handling of pointer expressions. gcc/testsuite/ChangeLog: PR fortran/100136 * gfortran.dg/PR100136.f90: New test. (cherry picked from commit 20d30e737ad79dc36817e59f1676aa8bc0c6b325)
[Bug c++/106841] ice in vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106841 --- Comment #1 from David Binderman --- This bug looks to be at least a month old, since it started sometime before git hash 21c7aab09805d0c8, dated 20220808. I will have a go at a reduction.
[Bug c++/106841] New: ice in vect_get_vec_defs_for_operand, at tree-vect-stmts.cc:1509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106841
Bug ID: 106841
Summary: ice in vect_get_vec_defs_for_operand, at
tree-vect-stmts.cc:1509
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 53540
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53540&action=edit
gzipped C++ source code
The attached C++ code does this:
during GIMPLE pass: vect
msh3.cpp: In member function 'virtual AnyType Square_Op::operator()(Stack)
const':
msh3.cpp:8044:9: internal compiler error: in vect_get_vec_defs_for_operand, at
tree-vect-stmts.cc:1509
8044 | AnyType Square_Op::operator( )(Stack stack) const {
| ^
0x20af236 vect_get_vec_defs_for_operand(vec_info*, _stmt_vec_info*, unsigned
int, tree_node*, vec*, tree_node*)
../../trunk.git/gcc/tree-vect-stmts.cc:1509
0x20cf508 vect_get_gather_scatter_ops(_loop_vec_info*, loop*, _stmt_vec_info*,
_slp_tree*, gather_scatter_info*, tree_node**, vec*)
../../trunk.git/gcc/tree-vect-stmts.cc:3066
0x20bab42 vectorizable_load(vec_info*, _stmt_vec_info*, gimple_stmt_iterator*,
gimple**, _slp_tree*, vec*)
../../trunk.git/gcc/tree-vect-stmts.cc:9627
when compiled with -c -w -O3 -ffast-math -march=bdver2.
I will have a go at producing a git range.
[Bug c++/106826] [13 Regression] [modules] Variable template of type trait via importable header gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106826 Johel Ernesto Guerrero Peña changed: What|Removed |Added Known to work||12.2.0 Known to fail||13.0 Summary|[modules] Variable template |[13 Regression] [modules] |of type trait via |Variable template of type |importable header gives |trait via importable header |wrong result|gives wrong result --- Comment #1 from Johel Ernesto Guerrero Peña --- As mentioned, this works with GCC 12: https://godbolt.org/z/bnfzPc5M8.
[Bug target/106827] operator++ doesn't work for enum -O2 -mcpu=cortex-m0plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106827
--- Comment #7 from Kio ---
(In reply to Andreas Schwab from comment #5)
> The operator++ function is expected to modify the argument in place, and
> needs to take a reference to it.
Yes, that's my error! after modifying the operators to:
Foo operator++(Foo& n,int) { Foo v=n; n=Foo(int(n)+1); return v; }
Foo& operator++(Foo& n){ return n=Foo(int(n)+1); }
then the compiled code is as expected.
Obviously arg#1 must be a reference, because the argument must be modified.
Actually i think this code should not compile or at least produce a warning (i
compile with almost all warnings on, but that went silent). When passing a
value the operator can't do what is expected.
[Bug preprocessor/106840] glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106840 Martin Liška changed: What|Removed |Added CC||amodra at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-09-05 Status|UNCONFIRMED |NEW
[Bug preprocessor/106840] New: glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106840
Bug ID: 106840
Summary: glibc master build failure on ppc64le-linux-gnu since
r13-2212-geb4879ab905308
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: drepper at gcc dot gnu.org, jakub at gcc dot gnu.org,
segher at gcc dot gnu.org
Target Milestone: ---
Host: ppc64le-linux-gnu
Since the revision, I can't build glibc master on ppc64le-linux:
python3 -B ../scripts/gen-as-const.py --cc="gcc -std=gnu11 -fgnu89-inline -g
-O2 -Wall -Wwrite-strings -Wundef -Werror -fmerge-all-constants -frounding-math
-fno-stack-protector -fno-common -Wstrict-prototypes -Wold-style-definition
-fmath-errno -mabi=ieeelongdouble -Wno-psabi -mno-gnu-attribute
-mlong-double-128-ftls-model=initial-exec -I../include
-I/home/marxin/Programming/glibc/objdir/csu
-I/home/marxin/Programming/glibc/objdir
-I../sysdeps/unix/sysv/linux/powerpc/powerpc64/le/fpu
-I../sysdeps/unix/sysv/linux/powerpc/powerpc64/fpu
-I../sysdeps/unix/sysv/linux/powerpc/powerpc64/le
-I../sysdeps/unix/sysv/linux/powerpc/powerpc64
-I../sysdeps/unix/sysv/linux/wordsize-64 -I../sysdeps/unix/sysv/linux/powerpc
-I../sysdeps/powerpc/nptl -I../sysdeps/unix/sysv/linux/include
-I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread
-I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv
-I../sysdeps/unix/powerpc -I../sysdeps/unix -I../sysdeps/posix
-I../sysdeps/powerpc/powerpc64/le/power8/fpu/multiarch
-I../sysdeps/powerpc/powerpc64/le/power7/fpu/multiarch
-I../sysdeps/powerpc/powerpc64/le/fpu/multiarch
-I../sysdeps/powerpc/powerpc64/le/power8/fpu
-I../sysdeps/powerpc/powerpc64/le/power7/fpu
-I../sysdeps/powerpc/powerpc64/le/fpu -I../sysdeps/powerpc/powerpc64/fpu
-I../sysdeps/powerpc/powerpc64/le/power8/multiarch
-I../sysdeps/powerpc/powerpc64/le/power7/multiarch
-I../sysdeps/powerpc/powerpc64/le/multiarch
-I../sysdeps/powerpc/powerpc64/multiarch
-I../sysdeps/powerpc/powerpc64/le/power8 -I../sysdeps/powerpc/powerpc64/power8
-I../sysdeps/powerpc/powerpc64/le/power7
-I../sysdeps/powerpc/powerpc64/power7 -I../sysdeps/powerpc/powerpc64/power6
-I../sysdeps/powerpc/powerpc64/power4 -I../sysdeps/powerpc/power4
-I../sysdeps/powerpc/powerpc64/le -I../sysdeps/powerpc/powerpc64
-I../sysdeps/wordsize-64 -I../sysdeps/powerpc/fpu -I../sysdeps/powerpc
-I../sysdeps/ieee754/ldbl-128ibm-compat
-I../sysdeps/ieee754/ldbl-128ibm/include -I../sysdeps/ieee754/ldbl-128ibm
-I../sysdeps/ieee754/ldbl-opt -I../sysdeps/ieee754/dbl-64
-I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/float128
-I../sysdeps/ieee754 -I../sysdeps/generic -I.. -I../libio -I.
-D_LIBC_REENTRANT -include /home/marxin/Programming/glibc/objdir/libc-modules.h
-DMODULE_NAME=libc -include ../include/libc-symbols.h
-DTOP_NAMESPACE=glibc -DGEN_AS_CONST_HEADERS \
-MD -MP -MF
/home/marxin/Programming/glibc/objdir/rtld-sizes.h.dT \
-MT '/home/marxin/Programming/glibc/objdir/rtld-sizes.h.d
/home/marxin/Programming/glibc/objdir/rtld-sizes.h'" \
rtld-sizes.sym > /home/marxin/Programming/glibc/objdir/rtld-sizes.hT
In file included from ../sysdeps/unix/powerpc/sysdep.h:21,
from ../sysdeps/unix/sysv/linux/powerpc/sysdep.h:23,
from ../sysdeps/unix/sysv/linux/powerpc/powerpc64/sysdep.h:23,
from ../sysdeps/powerpc/nptl/tls.h:49,
from ../include/link.h:51,
from :1:
../sysdeps/powerpc/powerpc64/sysdep.h:42:13: error: '\N' not followed by '{'
42 | .if \NARG
| ^
../sysdeps/powerpc/powerpc64/sysdep.h:43:18: error: '\N' not followed by '{'
43 | SAVE_ARG \NARG-1
| ^
../sysdeps/powerpc/powerpc64/sysdep.h:44:19: error: '\N' not followed by '{'
44 | std
2+\NARG,-FRAME_MIN_SIZE_PARM+FRAME_PARM_SAVE-8+8*(\NARG)(1)
| ^
../sysdeps/powerpc/powerpc64/sysdep.h:44:67: error: '\N' not followed by '{'
44 | std
2+\NARG,-FRAME_MIN_SIZE_PARM+FRAME_PARM_SAVE-8+8*(\NARG)(1)
| ^
../sysdeps/powerpc/powerpc64/sysdep.h:49:13: error: '\N' not followed by '{'
49 | .if \NARG
| ^
[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720 Torbjörn SVENSSON changed: What|Removed |Added CC||torbjorn.svensson at foss dot st.c ||om --- Comment #16 from Torbjörn SVENSSON --- I think this ticket should be reopened as the change broke how linker scripts are handled in dejagnu. If your board file have the following statement: set_board_info ldscript "-T /path/to/foo.ld" Then, the commands will be issued like this: spawn -ignore SIGHUP .../build-native/gcc-final/gcc/xgcc -B.../build-native/gcc-final/gcc/ linker_plugin9341.c -mthumb -march=armv6s-m -mcpu=cortex-m0 -mfloat-abi=soft -fdiagnostics-plain-output -dumpbase -flto -fuse-linker-plugin -Wl,--start-group -lc -lm -Wl,--end-group --specs=nosys.specs -Wl,--allow-multiple-definition -Wl,-u,_isatty,-u,_fstat -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -Wl,gcc_tg.o -lm -T -Wl,/path/to/foo.ld -o linker_plugin9341.exe Note that the ldscript symbol has been replaced by "-T -Wl,/path/to/foo.ld". According to the manual, it's correct to have a white-space between -T and the path.
[Bug target/106453] Redundant zero extension after crc32q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106453 Alexander Monakov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Alexander Monakov --- Fixed for gcc-13.
[Bug target/106453] Redundant zero extension after crc32q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106453 --- Comment #3 from CVS Commits --- The master branch has been updated by Alexander Monakov : https://gcc.gnu.org/g:810d9815249451f477d4cbc67b8e4a0819c37faa commit r13-2448-g810d9815249451f477d4cbc67b8e4a0819c37faa Author: Alexander Monakov Date: Tue Aug 23 18:42:24 2022 +0300 i386: avoid zero extension for crc32q The crc32q instruction takes 64-bit operands, but ignores high 32 bits of the destination operand, and zero-extends the result from 32 bits. Let's model this in the RTL pattern to avoid zero-extension when the _mm_crc32_u64 intrinsic is used with a 32-bit type. PR target/106453 gcc/ChangeLog: * config/i386/i386.md (sse4_2_crc32di): Model that only low 32 bits of operand 0 are consumed, and the result is zero-extended to 64 bits. gcc/testsuite/ChangeLog: * gcc.target/i386/pr106453.c: New test.
[Bug libstdc++/106839] Library traits need to handle array of incomplete type with unknown bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106839 --- Comment #2 from Jonathan Wakely --- As noted in PR 106838 the library needs to guard use of __has_virtual_destructor so it's only used with non-union class types. This applies to trunk as well.
[Bug c++/106838] Built-in traits have wrong preconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106838 --- Comment #2 from Jonathan Wakely --- The documented preconditions for __is_literal_type, __is_pod, __is_standard_layout, and __is_trivial say: Requires: type shall be a complete type, (possibly cv-qualified) void, or an array of unknown bound. But the corresponding library trait says: "remove_all_extents_t shall be a complete type or cv void." I think r13-25 was right to allow arrays of unknown bound, but there should also be a check that the array element is complete. Looks like __is_aggregate has the same problem, but isn't documented in the manual.
[Bug libstdc++/106839] Library traits need to handle array of incomplete type with unknown bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106839 --- Comment #1 from Jonathan Wakely --- Actually is_pod_v really should be ill-formed, so r13-25 was wrong to allow that. But is_final_v should be valid, and is rejected by gcc-11 and gcc-12, so the library needs to handle that.
[Bug libstdc++/106839] New: Library traits need to handle array of incomplete type with unknown bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106839 Bug ID: 106839 Summary: Library traits need to handle array of incomplete type with unknown bound Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- This should be valid: #include struct Inc; static_assert( ! std::is_empty_v ); static_assert( ! std::is_pod_v ); static_assert( ! std::is_polymorphic_v ); static_assert( ! std::is_abstract_v ); However, before r13-25 the front-end rejected it. For the release branches, the library needs to workaround this.
[Bug ipa/105682] [12/13 Regression] Both `-Wsuggest-attribute=pure` and `-Wsuggest-attribute=const` on same function since r12-5177-g494bdadf28d0fb35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105682
--- Comment #8 from sagebar at web dot de ---
(In reply to Jan Hubicka from comment #6)
> I think the conlcusion here is correct. callee has pure attribute and that
> means that it has no side effects except for reading global memory. So
> whatever volatile assembly does has to satisfy this.
>
> Now since assembly is not declared as reading memory, GCC concludes that the
> function has no side effects and does not read global memory and this can be
> uprgraded to const.
This assumes that reading memory is the only thing inline assembly can do to
access (part of) the global state. But consider the following example where the
ARM FPU control word is read:
```
#include // HINT: this is arm assembly
//#define _FPU_GETCW(cw) __asm__ __volatile__("vmrs %0, fpscr" : "=r" (cw))
//#define _FPU_SETCW(cw) __asm__ __volatile__("vmsr fpscr, %0" : : "r" (cw))
__attribute__((pure))
fpu_control_t getcw() {
fpu_control_t result;
_FPU_GETCW(result);
return result;
}
int main() {
fpu_control_t before, after;
before = getcw();
_FPU_SETCW(0x1234);
after = getcw()
printf("oldcw: %d\n", before);
printf("newcw: %d\n", after);
}
```
If you're saying that a `__asm__ __volatile__` that doesn't access memory
should be considered as `const`, then gcc should be allowed to remove the first
`getcw()` and simply assign the same value to `before` and `after` (since a
`const` function's return value only depends on its arguments, meaning it calls
can be removed and re-ordered however gcc pleases).
I think you can see how that would be a problem in the above.
However: I would understand gcc doing this if `_FPU_GETCW` was implemented
using `__asm__` instead of `__asm__ __volatile__`.
(If I'm misunderstanding how `pure` is meant to work, please correct me. But as
far as I understand it, the above is a correct usage examle)
[Bug libstdc++/71579] type_traits miss checks for type completeness in some traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71579 --- Comment #24 from Jonathan Wakely --- See PR 106838 for the __has_virtual_destructor bug.
[Bug c++/106838] Built-in traits have wrong preconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106838 --- Comment #1 from Jonathan Wakely --- According to https://gcc.gnu.org/onlinedocs/gcc/Type-Traits.html the precondition for __is_trivial is: "Requires: type shall be a complete type, (possibly cv-qualified) void, or an array of unknown bound." That implies the following should be valid: struct Inc; bool b = __is_trivial(Inc[]); However, the implementation seems to match the requirement for the std::is_trivial trait, which is: "remove_all_extents_t shall be a complete type or cv void." This seems to be just a documentation bug.
[Bug c++/106838] New: Built-in traits have wrong preconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106838 Bug ID: 106838 Summary: Built-in traits have wrong preconditions Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- According to https://gcc.gnu.org/onlinedocs/gcc/Type-Traits.html the precondition for __has_virtual_destructor is: "Requires: type shall be a complete type, (possibly cv-qualified) void, or an array of unknown bound." This seems to be what the implementation actually requires: union Inc; static_assert( !__has_virtual_destructor(Inc)); struct Inc2; static_assert( !__has_virtual_destructor(Inc2[1]) ); inc.C:2:45: error: invalid use of incomplete type 'union Inc' 2 | static_assert( !__has_virtual_destructor(Inc)); | ^ inc.C:1:7: note: forward declaration of 'union Inc' 1 | union Inc; | ^~~ inc.C:4:49: error: invalid use of incomplete type 'struct Inc2' 4 | static_assert( !__has_virtual_destructor(Inc2[1]) ); | ^ inc.C:3:8: note: forward declaration of 'struct Inc2' 3 | struct Inc2; |^~~~ However, the precondition for the std::has_virtual_destructor trait is different: "If T is a non-union class type, T shall be a complete type." So std::has_virtual_destructor_v and std::has_virtual_destructor_v should both be false. But because the library trait just uses __has_virtual_destructor, those are ill-formed. Should the built-in (and its documentation) be adjusted to match the library's requirements? Clang gives the same errors as GCC. EDG rejects the incomplete union, but allows the array of incomplete type. This suggests that the library trait needs to avoid using the built-in for those types, even if GCC's built-in is changed to support it.
[Bug c/106835] [i386] Taking an address of _GLOBAL_OFFSET_TABLE_ produces a wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
--- Comment #5 from H.J. Lu ---
To access this special symbol:
[hjl@gnu-tgl-3 tmp]$ cat c.c
#include
extern char GLOBAL_OFFSET_TABLE[];
char *ptr = GLOBAL_OFFSET_TABLE;
int main() {
printf("%lx\n", (unsigned long)ptr);
}
[hjl@gnu-tgl-3 tmp]$ gcc -m32 c.c
/usr/local/bin/ld: /tmp/ccK14eSl.o:(.data+0x0): undefined reference to
`GLOBAL_OFFSET_TABLE'
collect2: error: ld returned 1 exit status
[hjl@gnu-tgl-3 tmp]$ gcc -m32 c.c
-Wl,--defsym,GLOBAL_OFFSET_TABLE=_GLOBAL_OFFSET_TABLE_
[hjl@gnu-tgl-3 tmp]$ ./a.out
804bff4
[hjl@gnu-tgl-3 tmp]$
[Bug ipa/92497] Aggregate IPA-CP and inlining do not play well together, transformation is lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92497 Martin Jambor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Martin Jambor --- I'm working on a fix along the lines of https://gcc.gnu.org/pipermail/gcc-patches/2022-April/592644.html
[Bug target/106834] GCC creates R_X86_64_GOTOFF64 for 4-bytes immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
--- Comment #9 from H.J. Lu ---
_GLOBAL_OFFSET_TABLE_ is a special symbol and can't be accessed like regular
symbols. To workaround it:
[hjl@gnu-tgl-3 tmp]$ cat x.c
#include
extern char GLOBAL_OFFSET_TABLE[];
int main() {
printf("%lx\n", (unsigned long)GLOBAL_OFFSET_TABLE);
}
[hjl@gnu-tgl-3 tmp]$ gcc -fPIC x.c
/usr/local/bin/ld: /tmp/cc4Lekj4.o: in function `main':
x.c:(.text+0x7): undefined reference to `GLOBAL_OFFSET_TABLE'
collect2: error: ld returned 1 exit status
[hjl@gnu-tgl-3 tmp]$ gcc -fPIC x.c
-Wl,--defsym,GLOBAL_OFFSET_TABLE=_GLOBAL_OFFSET_TABLE_
[hjl@gnu-tgl-3 tmp]$ ./a.out
403fe8
[hjl@gnu-tgl-3 tmp]$
[Bug middle-end/106833] Handle OPAQUE_TYPE in gimple_canonical_types_compatible_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833 --- Comment #7 from Segher Boessenkool --- (In reply to rguent...@suse.de from comment #6) > Ah, that special "mode". I think verify_types shouldn't do anything > for OPAQUE_TYPES or alternatively trust the targets setup of > TYPE_MAIN_VARIANT/TYPE_CANONICAL. Maybe verify TYPE_CANONICAL > and TYPE_MAIN_VARIANT are also OPAQUE_TYPE. It's probably easiest to just test if the TYPE_MODEs match, for OPAQUE_TYPEs? > So the solution should be fully inside verify_type. Yeah. OPAQUE might be a "hack" (or call it an "invention" :-) ), but the nice thing about is it is very self-contained, no interactions anywhere. That is the point even :-)
[Bug middle-end/106831] [13 Regression] mpfr-4.1.0 started failing 2 tests: tget_set_d64 and tget_set_d128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Aldy Hernandez --- Fixed in trunk. Verified by doing a make check-mpfr with in-tree libmpfr before and after patch. Thanks Jakub.
[Bug middle-end/106824] [13 Regression] ICE in set_nan, at value-range.cc:283 since r13-2266-g8bb1df032cc080b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824 --- Comment #12 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:ba0db24386107ffa237a2af0d1fdef9030460157 commit r13-2444-gba0db24386107ffa237a2af0d1fdef9030460157 Author: Aldy Hernandez Date: Mon Sep 5 15:28:55 2022 +0200 Do not ICE when updating a NAN to a non-NAN. Updating a definite NAN to a definitely not NAN was an assertion failure, but it turns out we can have such a scenario while attempting to thread an impossible path. This patch updates the range to undefined. What happens in the testcase is that we are trying to thread path that starts like this: [local count: 81335936906]: SR.30_3 = Nan; goto ; [100.00%] [local count: 108447915740]: # SR.30_25 = PHI plus_33 = SR.30_25; w1$value__13 = f_distance$D2421$value__1; w2$value__14 = plus_33; if (w1$value__13 == w2$value__14) goto ; [50.00%] else goto ; [50.00%] On the path, SR.30_25 is NAN, which ultimately makes w2$value__14 a NAN. This means that the 7->8 is impossible on the path. On the true arm (foperator_equal::op1_range) we are asserting that op1 (w1$value__13) is a !NAN because for the == conditional to succeed, neither operand can be a NAN. But...we know that operand 2 is a NAN. This is an impossible scenario. We are ICEing because frange::set_nan() sees the NAN and the desire to set the NAN flag to NO. The correct thing to do is to set the range to undefined, which is basically unreachable, and will cause all the right things to happen. For that matter, the threader will see that an UNDEFINED range was calculated in the path and abort trying to investigate paths in that direction. PR middle-end/106824 gcc/ChangeLog: * value-range.cc (frange::set_nan): Set undefined when updating a NAN to a non-NAN. gcc/testsuite/ChangeLog: * g++.dg/pr106824.C: New test.
[Bug middle-end/106824] [13 Regression] ICE in set_nan, at value-range.cc:283 since r13-2266-g8bb1df032cc080b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #13 from Aldy Hernandez --- fixed
[Bug middle-end/106831] [13 Regression] mpfr-4.1.0 started failing 2 tests: tget_set_d64 and tget_set_d128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831 --- Comment #10 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:b4d8a56a4c62ba8bca55469ae2b841fb4e1334a4 commit r13-2445-gb4d8a56a4c62ba8bca55469ae2b841fb4e1334a4 Author: Aldy Hernandez Date: Mon Sep 5 15:41:39 2022 +0200 Disable decimal floating point in frange. As Jakub mentioned in the PR, because many numbers have multiple possible representations, we can't reliably return true for singleton_p. For that matter, we may not be capable of modeling them just yet. Disabling them until someone with DFP knowledge can opine or extend frange. PR middle-end/106831 gcc/ChangeLog: * value-range.h (frange::supports_p): Disable decimal floats. * range-op-float.cc (frange_drop_inf): Remove DECIMAL_FLOAT_MODE_P check. (frange_drop_ninf): Same.
[Bug middle-end/106831] [13 Regression] mpfr-4.1.0 started failing 2 tests: tget_set_d64 and tget_set_d128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
--- Comment #9 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > I guess disabling them at least for now could be fine.
> > If somebody involved with dfp wants to extend it for dfp, it can be done
> > incrementally.
> >
> > BTW, thinking further about the singletons, I wonder if MODE_COMPOSITE_P
> > don't have similar problems. For the case where the values are exactly
> > equal
> > to their MSB (i.e. the __ibm128 value is equal to that value cast to double
> > and back), then the low part can be either +0.0 or -0.0. Ditto for +Inf and
> > -Inf.
> > So there can be quite a few non-singleton values.
> > libgcc/config/rs6000/ibm-ldouble-format describes it.
>
> Eeech, could you come up with a patch for that one? Consider it preapproved
> :-/. I'm afraid to mess it up.
I think it would be:
--- gcc/value-range.cc.jj 2022-09-05 16:50:51.443419082 +0200
+++ gcc/value-range.cc 2022-09-05 16:52:04.880434594 +0200
@@ -639,6 +639,19 @@ frange::singleton_p (tree *result) const
if (HONOR_NANS (m_type) && !get_nan ().no_p ())
return false;
+ if (MODE_COMPOSITE_P (TYPE_MODE (m_type)))
+ {
+ // In IBM extended format, if value is +-Inf or
+ // is exactly representable in double, the other
+ // double could be +0.0 or -0.0.
+ if (real_isinf (&m_min))
+ return false;
+ REAL_VALUE_TYPE v;
+ real_convert (&v, DFmode, &m_min);
+ if (real_identical (&v, &m_min))
+ return false;
+ }
+
// Return the appropriate zero if known.
if (HONOR_SIGNED_ZEROS (m_type) && zero_p ())
{
It changes when
long double foo (long double x)
{
if (x != 25.0L)
return 16.0L;
return x + 17.0L;
}
is simplified from evrp to dom2, but perhaps it is ok doing it in dom2 because
the result of the addition would at runtime go through libgcc which would most
likely use 0.0 as the other half.
But perhaps it could matter in other cases.
[Bug tree-optimization/106822] "Boolean-or" optimization opportunity not consistently used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106822 --- Comment #5 from Benjamin B. Meier --- Thx for the very quick reaction and also you additional example:)!
[Bug middle-end/106831] [13 Regression] mpfr-4.1.0 started failing 2 tests: tget_set_d64 and tget_set_d128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831 --- Comment #8 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #7) > I guess disabling them at least for now could be fine. > If somebody involved with dfp wants to extend it for dfp, it can be done > incrementally. > > BTW, thinking further about the singletons, I wonder if MODE_COMPOSITE_P > don't have similar problems. For the case where the values are exactly equal > to their MSB (i.e. the __ibm128 value is equal to that value cast to double > and back), then the low part can be either +0.0 or -0.0. Ditto for +Inf and > -Inf. > So there can be quite a few non-singleton values. > libgcc/config/rs6000/ibm-ldouble-format describes it. Eeech, could you come up with a patch for that one? Consider it preapproved :-/. I'm afraid to mess it up. In the meantime I think I'll disable decimal floats for frange.
[Bug middle-end/106831] [13 Regression] mpfr-4.1.0 started failing 2 tests: tget_set_d64 and tget_set_d128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831 --- Comment #7 from Jakub Jelinek --- I guess disabling them at least for now could be fine. If somebody involved with dfp wants to extend it for dfp, it can be done incrementally. BTW, thinking further about the singletons, I wonder if MODE_COMPOSITE_P don't have similar problems. For the case where the values are exactly equal to their MSB (i.e. the __ibm128 value is equal to that value cast to double and back), then the low part can be either +0.0 or -0.0. Ditto for +Inf and -Inf. So there can be quite a few non-singleton values. libgcc/config/rs6000/ibm-ldouble-format describes it.
[Bug middle-end/106824] [13 Regression] ICE in set_nan, at value-range.cc:283 since r13-2266-g8bb1df032cc080b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824 --- Comment #11 from Aldy Hernandez --- Created attachment 53539 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53539&action=edit untested patch
[Bug target/106831] [13 Regression] mpfr-4.1.0 started failing 2 tests: tget_set_d64 and tget_set_d128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
--- Comment #6 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #5)
> BTW, I admit I don't know much about decimal{32,64,128}, but
> https://en.wikipedia.org/wiki/Decimal32_floating-point_format
> says:
> Because the significand is not normalized (there is no implicit leading
> "1"), most values with less than 7 significant digits have multiple possible
> representations; 1 × 10^2=0.1 × 10^3=0.01 × 10^4, etc. Zero has 192 possible
> representations (384 when both signed zeros are included).
> So, I think singleton_p should just always return false for
> DECIMAL_FLOAT_TYPE_P (at least for now).
Interestingly, frange_drop_*inf() bails on DECIMAL_FLOAT_MODE_P because
build_real() will ultimately ICE when trying to make a tree out of the max/min
representable number for a type:
/* dconst{0,1,2,m1,half} are used in various places in
the middle-end and optimizers, allow them here
even for decimal floating point types as an exception
by converting them to decimal. */
if (DECIMAL_FLOAT_MODE_P (TYPE_MODE (type))
&& (d.cl == rvc_normal || d.cl == rvc_zero)
&& !d.decimal)
...
...
I know even less about decimal floats. Jakub, should we disable them
altogether from the frange infrastructure, or is that too big of a hammer? I'm
just afraid we'll keep running into limitations when we start implementing
floating operations in range-op-float.cc. Or worse, have to special case them
all over.
bool frange::supports_p (const_tree type)
{
return SCALAR_FLOAT_TYPE_P (type) && !DECIMAL_FLOAT_MODE_P (type);
}
??
[Bug c++/106837] False compilation error "inconsistent begin/end types in range-based 'for' statement"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106837 --- Comment #3 from Jakub Jelinek --- True. But in the end the operator!= will be called on __begin and __end vars which are lvalues. So I think the test needs to be called on some trees with types of the *begin and *end return values for which lvalue_kind will say it is an lvalue. Dunno if that means trying to create a dummy VAR_DECL, CONST_DECL, PLACEHOLDER_EXPR, COMPOUND_LITERAL_EXPR or what else (and whether to do that only if *begin or *end aren't lvalues already.
[Bug rtl-optimization/106041] [12/13 Regression] infinite loop in fast_dce at -O1 with aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106041 --- Comment #9 from Mathieu Malaterre --- (In reply to Andrew Pinski from comment #3) > If I get some time next weekend I might reduce this further to understand it. > There are only 38 BBs in this function too and they are not large either. Seems confirmed at least.
[Bug c++/106837] False compilation error "inconsistent begin/end types in range-based 'for' statement"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106837
--- Comment #2 from Ofek Shilon ---
(In reply to Andrew Pinski from comment #1)
> > In this case the begin/end iter types *are* comparable
> Not exactly as the operator!= requires a lvalue. And end() is not an lvalue.
Then enable comparison also via the other iterator type:
struct myDat {
myDat() {}
struct EndIter;
struct Iter {
Iter &operator++();
int operator*();
bool operator!=(EndIter& other);
};
Iter begin() ;
struct EndIter {
bool operator!=(Iter other);
};
EndIter end() ;
};
int main() {
for (int pos : myDat())
;
}
This still fails with the same message
[Bug c/100854] TS 18661-3 and backwards-incompatible setting of __FLT_EVAL_METHOD__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100854 --- Comment #6 from Andrea Corallo --- "jasonwucj at gcc dot gnu.org" writes: [...] > > I guess this issue has been resolved by newlib implementation. :) > > Refer to the discussions on: > https://sourceware.org/pipermail/newlib/2021/018471.html > https://sourceware.org/pipermail/newlib/2022/019522.html > > The patches have been committed into newlib code base and it should be > workable > now. Confirm Andrea
[Bug c++/106837] False compilation error "inconsistent begin/end types in range-based 'for' statement"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106837 --- Comment #1 from Andrew Pinski --- > In this case the begin/end iter types *are* comparable Not exactly as the operator!= requires a lvalue. And end() is not an lvalue.
[Bug c++/106837] New: False compilation error "inconsistent begin/end types in range-based 'for' statement"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106837
Bug ID: 106837
Summary: False compilation error "inconsistent begin/end types
in range-based 'for' statement"
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ofekshilon at gmail dot com
Target Milestone: ---
The following fails to build with all gcc versions at least since 6.1, when
built with "-std=c++17" or (for supporting versions) with "-std=c++20".
struct myDat {
myDat() {}
struct Iter {
Iter &operator++();
int operator*();
bool operator!=(int& other);
};
Iter begin() ;
int end() ;
};
int main() {
for (int pos : myDat())
;
}
Here's a godbolt link, with comparison to a successful build by clang:
https://godbolt.org/z/1fsfvxzb7
Note this patch by Jason Merrill:
https://gcc.gnu.org/legacy-ml/gcc-patches/2016-03/msg00792.html
+ {
+ if (cxx_dialect >= cxx1z
+ && (build_x_binary_op (input_location, NE_EXPR,
+*begin, ERROR_MARK,
+*end, ERROR_MARK,
+NULL, tf_none)
+ != error_mark_node))
+ /* P08184R0 allows __begin and __end to have different types,
+ but make sure they are comparable so we can give a better
+ diagnostic. */;
+ else
+ error ("inconsistent begin/end types in range-based % "
+ "statement: %qT and %qT",
+ TREE_TYPE (*begin), TREE_TYPE (*end));
+ }
In this case the begin/end iter types *are* comparable, but the
build_x_binary_op test fails.
[Bug c++/106824] [13 Regression] ICE in set_nan, at value-range.cc:283 since r13-2266-g8bb1df032cc080b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824 Aldy Hernandez changed: What|Removed |Added CC||amacleod at redhat dot com Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org --- Comment #10 from Aldy Hernandez --- This is interesting. We are trying to thread 5->7->8->9->3->??. The path starts like this: [local count: 81335936906]: SR.30_3 = Nan; goto ; [100.00%] [local count: 108447915740]: # SR.30_25 = PHI plus_33 = SR.30_25; w1$value__13 = f_distance$D2421$value__1; w2$value__14 = plus_33; if (w1$value__13 == w2$value__14) goto ; [50.00%] else goto ; [50.00%] On the path, SR.30_25 is NAN, which ultimately makes w2$value__14 a NAN. This means that the 7->8 is impossible on the path. On the true arm (foperator_equal::op1_range) we are asserting that op1 (w1$value__13) is a !NAN because for the == conditional to succeed, neither operand can be a NAN. But...we know that operand 2 is a NAN. However, op1 == op2 and op2 being a NAN is an impossible scenario. We are ICEing because frange::set_nan() sees the NAN and the desire to set the NAN flag to NO. I thought this would never happen, but alas it happens in threading. I think the correct thing to do is to set the range to undefined, which is basically unreachable, and will cause all the right things to happen. For that matter, the threader will see that an UNDEFINED range was calculated in the path and abort trying to investigate paths in that direction.
[Bug c/106836] [13 Regression] ICE in c_omp_split_clauses, at c-family/c-omp.cc:2636 since r13-2388-ga651e6d59188da89
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106836 --- Comment #2 from Jakub Jelinek --- Created attachment 53538 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53538&action=edit gcc13-pr106836.patch Untested fix.
[Bug target/106831] [13 Regression] mpfr-4.1.0 started failing 2 tests: tget_set_d64 and tget_set_d128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
--- Comment #5 from Jakub Jelinek ---
BTW, I admit I don't know much about decimal{32,64,128}, but
https://en.wikipedia.org/wiki/Decimal32_floating-point_format
says:
Because the significand is not normalized (there is no implicit leading "1"),
most values with less than 7 significant digits have multiple possible
representations; 1 × 10^2=0.1 × 10^3=0.01 × 10^4, etc. Zero has 192 possible
representations (384 when both signed zeros are included).
So, I think singleton_p should just always return false for
DECIMAL_FLOAT_TYPE_P (at least for now).
[Bug target/106831] [13 Regression] mpfr-4.1.0 started failing 2 tests: tget_set_d64 and tget_set_d128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831 Aldy Hernandez changed: What|Removed |Added Last reconfirmed||2022-09-05 Status|RESOLVED|NEW Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #4 from Aldy Hernandez --- reproduced on x86-64. Will take a look. Sorry for closing it prematurely.
[Bug target/106827] operator++ doesn't work for enum -O2 -mcpu=cortex-m0plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106827 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- I think C++ doesn't explicitly say that the argument has to be a reference: https://eel.is/c++draft/over.oper#over.inc but obviously if it isn't and it isn't a non-static method operator++, then it can only compute the return value and can't actually modify in place. For ++i just operator++(i) is called and for i++ operator++(i, 0). So, with your overloads you'd actually need to do i = ++i The other overload is just unusable because it does the wrong thing completely.
[Bug target/106827] operator++ doesn't work for enum -O2 -mcpu=cortex-m0plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106827 Andreas Schwab changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andreas Schwab --- The operator++ function is expected to modify the argument in place, and needs to take a reference to it.
[Bug target/106831] [13 Regression] mpfr-4.1.0 started failing 2 tests: tget_set_d64 and tget_set_d128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831 --- Comment #3 from Sergei Trofimovich --- Hm, mpfr-4.1.0 still fails these 2 tests for me from current gcc-master. Comparing -O2 build from last week and this week snapshot code generation changed seemingly only for `mpfr_get_decimal64()` at src/.libs/get_d64.o. I'll re-check current gcc-master, extract self-contained example from mpfr-4.1.0 and reopen the bug if I succeed.
[Bug c++/106834] GCC creates R_X86_64_GOTOFF64 for 4-bytes immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
--- Comment #8 from Alexander Monakov ---
Right, sorry, due to presence of 'main' I overlooked -fPIC in comment #0, and
then after my prompt it got dropped in comment #3.
If you modify the testcase as follows and compile it with -fPIC, it's evident
that GCC is treating both external symbols the same, but gas does not. Similar
to PR 106835, it seems Binutils is special-casing by symbol name. But here the
situation is worse, because GCC output is mentioning the intended relocation
kind:
movq_GLOBAL_OFFSET_TABLE_@GOTPCREL(%rip), %rax
so silently using R_X86_64_GOTOFF64 instead doesn't look right.
#include
extern char _GLOBAL_OFFSET_TABLE_[];
extern char xGLOBAL_OFFSET_TABLE_[];
int main() {
printf("%lx", (unsigned long)_GLOBAL_OFFSET_TABLE_);
printf("%lx", (unsigned long)xGLOBAL_OFFSET_TABLE_);
}
[Bug target/106827] operator++ doesn't work for enum -O2 -mcpu=cortex-m0plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106827 --- Comment #4 from Kio --- (In reply to Richard Earnshaw from comment #2) > Please put testcases in the bug report, godbolt links are not stable. test case was also attached as a file with the bug report.
[Bug c++/106834] GCC creates R_X86_64_GOTOFF64 for 4-bytes immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834 --- Comment #7 from Martin Liška --- Note I get 7: R_X86_64_GOTOFF64_GLOBAL_OFFSET_TABLE_-0x4 when I use both as 2.37 and 2.39 with the output provided by gcc-12 -fPIC: $ cat foo.s .file "pr106834.c" .text .section.rodata .LC0: .string "%lx" .text .globl main .type main, @function main: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq%rsp, %rbp .cfi_def_cfa_register 6 movq_GLOBAL_OFFSET_TABLE_@GOTPCREL(%rip), %rax movq%rax, %rsi leaq.LC0(%rip), %rax movq%rax, %rdi movl$0, %eax callprintf@PLT movl$0, %eax popq%rbp .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE0: .size main, .-main .ident "GCC: (SUSE Linux) 12.2.1 20220830 [revision e927d1cf141f221c5a32574bde0913307e140984]" .section.note.GNU-stack,"",@progbits while using the assembly from Comment 3 I get: b: R_X86_64_GOTPC32 _GLOBAL_OFFSET_TABLE_-0x4 for both as versions.
[Bug c/106835] [i386] Taking an address of _GLOBAL_OFFSET_TABLE_ produces a wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835 --- Comment #4 from Jakub Jelinek --- I think there are ways to get around it, adding an alias to _G_O_T_ and using that alias.
[Bug c++/106834] GCC creates R_X86_64_GOTOFF64 for 4-bytes immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834 --- Comment #6 from Alexander Monakov --- (In reply to Martin Liška from comment #5) > Do you mean gas or ld? gas > How did you get this output, please (from foo.o or final executable)? >From foo.o like in comment #0.
[Bug c/106835] [i386] Taking an address of _GLOBAL_OFFSET_TABLE_ produces a wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835 --- Comment #3 from Alexander Monakov --- It would be unfortunate if that makes it difficult or even impossible to make a R_386_32 relocation for the address of GOT in hand-written assembly. In any case, it seems GCC is not making the rules here, so this should be reported against Binutils so they can clarify the situation?
[Bug c++/106824] [13 Regression] ICE in set_nan, at value-range.cc:283 since r13-2266-g8bb1df032cc080b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824
--- Comment #9 from Martin Liška ---
BT:
g++ bug840.cc -c -O2 -march=bdver2
during GIMPLE pass: thread
bug840.cc: In function ‘void internal::ShortestPath()’:
bug840.cc:68:6: internal compiler error: in set_nan, at value-range.cc:283
68 | void ShortestPath() {
| ^~~~
0x91a2b3 frange::set_nan(fp_prop::kind)
/home/marxin/Programming/gcc/gcc/value-range.cc:283
0x21c1725 foperator_equal::op1_range(frange&, tree_node*, irange const&, frange
const&, relation_kind_t) const
/home/marxin/Programming/gcc/gcc/range-op-float.cc:364
0x20a3d46 gimple_range_calc_op1(vrange&, gimple const*, vrange const&, vrange
const&)
/home/marxin/Programming/gcc/gcc/gimple-range-gori.cc:80
0x20a6d3d gori_compute::compute_operand1_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&)
/home/marxin/Programming/gcc/gcc/gimple-range-gori.cc:1019
0x20a939b gori_compute::outgoing_edge_range_p(vrange&, edge_def*, tree_node*,
range_query&)
/home/marxin/Programming/gcc/gcc/gimple-range-gori.cc:1270
0x1443c95 path_range_query::compute_ranges_in_block(basic_block_def*)
/home/marxin/Programming/gcc/gcc/gimple-range-path.cc:454
0x1444132 path_range_query::compute_ranges(bitmap_head const*)
/home/marxin/Programming/gcc/gcc/gimple-range-path.cc:622
0x14cd837 back_threader::find_taken_edge_cond(vec const&, gcond*)
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.cc:333
0x14cd9e6 back_threader::maybe_register_path(back_threader_profitability&)
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.cc:248
0x14cdeb8 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.cc:380
0x14ce6b9 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.cc:502
0x14ce6b9 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.cc:502
0x14ce6b9 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.cc:502
0x14ce6b9 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.cc:502
0x14ceefc back_threader::maybe_thread_block(basic_block_def*)
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.cc:574
0x14cefa1 back_threader::thread_blocks()
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.cc:1002
0x14cf008 execute
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.cc:1104
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/106824] [13 Regression] ICE in set_nan, at value-range.cc:283 since r13-2266-g8bb1df032cc080b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824 Martin Liška changed: What|Removed |Added Summary|ice in set_nan, at |[13 Regression] ICE in |value-range.cc:283 |set_nan, at ||value-range.cc:283 since ||r13-2266-g8bb1df032cc080b7 --- Comment #8 from Martin Liška --- Started with r13-2266-g8bb1df032cc080b7.
[Bug c++/106824] ice in set_nan, at value-range.cc:283
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-09-05
Status|RESOLVED|REOPENED
CC||marxin at gcc dot gnu.org
Ever confirmed|0 |1
Resolution|FIXED |---
--- Comment #7 from Martin Liška ---
Note the issue is still present with the current master.
Newly reduced test-case:
cat bug840.cc
using int32 = int;
int ShortestPath_distance;
struct FloatWeightTpl {
FloatWeightTpl(float f) : value_(f) {}
float Value() { return value_; }
float value_;
};
template bool operator!=(FloatWeightTpl w1, T w2) {
bool __trans_tmp_2;
FloatWeightTpl __trans_tmp_3 = w1;
__trans_tmp_2 = __trans_tmp_3.Value() == w2.Value();
return __trans_tmp_2;
}
struct TropicalWeightTpl : FloatWeightTpl {
TropicalWeightTpl(float f) : FloatWeightTpl(f) {}
static TropicalWeightTpl Zero();
static TropicalWeightTpl NoWeight() {
float __trans_tmp_5 = __builtin_nanf("");
return __trans_tmp_5;
}
bool Member() { return value_; }
};
TropicalWeightTpl Plus(TropicalWeightTpl w1, TropicalWeightTpl &w2) {
return w1.Member() || w2.Member() ? TropicalWeightTpl::NoWeight() :
w2.Value() ? : w2;
}
TropicalWeightTpl Times();
struct ArcTpl {
using Weight = TropicalWeightTpl;
};
template struct ShortestPathOptions {
ShortestPathOptions(int, int, int32, bool, bool);
};
template
void SingleShortestPath(ShortestPathOptions) {
using Weight = typename Arc::Weight;
auto f_distance = Weight::Zero();
while (!0) {
TropicalWeightTpl __trans_tmp_1 = Times(),
plus = Plus(f_distance, __trans_tmp_1);
if (f_distance != plus)
f_distance = plus;
}
}
template
void ShortestPath(int, int *, int *,
ShortestPathOptions opts) {
SingleShortestPath(opts);
}
struct ShortestDistanceOptions {
float delta;
};
struct Trans_NS_script_ShortestPathOptions : ShortestDistanceOptions {
int32 nshortest;
bool unique;
};
namespace internal {
template
void ShortestPath(int ifst, int *ofst, int *distance,
Trans_NS_script_ShortestPathOptions opts) {
using ArcFilter = int;
ShortestPathOptions sopts(opts.nshortest,
opts.unique,
false, opts.delta, 0);
ShortestPath(ifst, ofst, distance, sopts);
}
int ShortestPath_ifst;
int ShortestPath_ofst;
Trans_NS_script_ShortestPathOptions ShortestPath_opts;
void ShortestPath() {
using StateId = int;
ShortestPath(ShortestPath_ifst, &ShortestPath_ofst,
&ShortestPath_distance, ShortestPath_opts);
}
} // namespace internal
[Bug c/106836] [13 Regression] ICE in c_omp_split_clauses, at c-family/c-omp.cc:2636 since r13-2388-ga651e6d59188da89
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106836 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
Jakub Jelinek changed:
What|Removed |Added
Summary|OpenMP offload internal |[12/13 Regression] OpenMP
|compiler error: in |offload internal compiler
|gimplify_expr, at |error: in gimplify_expr, at
|gimplify.cc:16222 |gimplify.cc:16222 since
||r12-5835
Ever confirmed|0 |1
CC||cltang at gcc dot gnu.org
Target Milestone|--- |12.3
Status|UNCONFIRMED |NEW
Priority|P3 |P2
Last reconfirmed||2022-09-05
--- Comment #2 from Jakub Jelinek ---
Started with r12-5835-g0ab29cf0bb68960c1f87
Reduced testcase:
template class complex;
template <> struct complex { complex(double); _Complex double d; };
struct S { void static foo (); };
void S::foo ()
{
#pragma omp target
complex c = 0.0;
}
[Bug c/106836] [13 Regression] ICE in c_omp_split_clauses, at c-family/c-omp.cc:2636 since r13-2388-ga651e6d59188da89
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106836 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Summary|[13 Regression] ICE in |[13 Regression] ICE in |c_omp_split_clauses, at |c_omp_split_clauses, at |c-family/c-omp.cc:2636 |c-family/c-omp.cc:2636 ||since ||r13-2388-ga651e6d59188da89 Last reconfirmed||2022-09-05 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r13-2388-ga651e6d59188da89.
[Bug c/106836] New: [13 Regression] ICE in c_omp_split_clauses, at c-family/c-omp.cc:2636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106836
Bug ID: 106836
Summary: [13 Regression] ICE in c_omp_split_clauses, at
c-family/c-omp.cc:2636
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc 13.0.0 20220904 snapshot (g:20d30e737ad79dc36817e59f1676aa8bc0c6b325) ICEs
when compiling the following testcase, reduced from
test/OpenMP/target_parallel_depend_messages.cpp (and a bunch of related ones)
from the clang 14.0 test suite, w/ -fopenmp:
void
foo (void)
{
#pragma omp target parallel depend (source)
}
% gcc-13.0.0 -fopenmp -c sf6jpufz.c
sf6jpufz.c: In function 'foo':
sf6jpufz.c:4:9: internal compiler error: in c_omp_split_clauses, at
c-family/c-omp.cc:2636
4 | #pragma omp target parallel depend (source)
| ^~~
0x6859f4 c_omp_split_clauses(unsigned int, tree_code, wide_int_bitmask,
tree_node*, tree_node**)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/c-family/c-omp.cc:2636
0x8d2ccf omp_split_clauses
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/c/c-parser.cc:19897
0x909d75 c_parser_omp_parallel
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/c/c-parser.cc:20589
0x90b2d3 c_parser_omp_target
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/c/c-parser.cc:21447
0x90189e c_parser_compound_statement_nostart
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/c/c-parser.cc:5798
0x902194 c_parser_compound_statement
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/c/c-parser.cc:5640
0x903ea3 c_parser_declaration_or_fndef
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/c/c-parser.cc:2554
0x90c273 c_parser_external_declaration
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/c/c-parser.cc:1789
0x90ccdb c_parser_translation_unit
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/c/c-parser.cc:1662
0x90ccdb c_parse_file()
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/c/c-parser.cc:23669
0x96f7a1 c_common_parse_file()
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220904/work/gcc-13-20220904/gcc/c-family/c-opts.cc:1255
[Bug target/106827] operator++ doesn't work for enum -O2 -mcpu=cortex-m0plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106827
Martin Liška changed:
What|Removed |Added
Status|WAITING |NEW
CC||marxin at gcc dot gnu.org
--- Comment #3 from Martin Liška ---
Copied test-case:
enum Foo{a,b,c,d,e,f};
Foo operator+(Foo n,int m) { return Foo(int(n)+m); }
Foo operator++(Foo n,int) { return Foo(int(n)+1); }
Foo operator++(Foo n) { return Foo(int(n)+1); }
void test1()
{
for (Foo i=a; i<=f; i++)
{
volatile Foo z=i;
}
}
void test2()
{
for (Foo i=a; i<=f; ++i)
{
volatile Foo z=i;
}
}
void test3()
{
for (Foo i=a; i<=f; i=i+1)
{
volatile Foo z=i;
}
}
[Bug c++/106834] GCC creates R_X86_64_GOTOFF64 for 4-bytes immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834 --- Comment #5 from Martin Liška --- (In reply to Alexander Monakov from comment #4) > Probably a Binutils bug then, with binutils-2.37 I get the correct Do you mean gas or ld? > >4: 48 8d 05 00 00 00 00lea0x0(%rip),%rax# b > 7: R_X86_64_GOTPC32 _GLOBAL_OFFSET_TABLE_-0x4 How did you get this output, please (from foo.o or final executable)?
[Bug middle-end/106823] #pragma GCC diagnostic ignored "-Wattribute-warning" doesn't work for -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106823 --- Comment #1 from Richard Biener --- I think we have a duplicate for this report.
[Bug tree-optimization/106822] "Boolean-or" optimization opportunity not consistently used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106822
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords||missed-optimization
Last reconfirmed||2022-09-05
Ever confirmed|0 |1
--- Comment #4 from Richard Biener ---
Confirmed. The alignment consideration shouldn't apply in this case - the
MyStruct object is either there or not. Note
typedef struct {
bool a[];
} MyStruct;
bool f(const MyStruct *s)
{
return s->a[0] || s->a[1];
}
would be a different story.
[Bug middle-end/106818] code is genereated differently with or without 'extern'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106818
--- Comment #9 from Richard Biener ---
(In reply to baoshan from comment #5)
> Per Andrew's request:
>
> For GCC built for RISC-V,
> With the following code:
> struct sss_t {
> int i;
> int j;
> } sss;
> extern char array[sizeof(struct sss_t )];
> void foo()
> {
> struct sss_t *p = (struct sss_t *)array;
> p->i = 10;
Note we should know here that p->i = 10 accesses memory aligned
according to the alignment of an 'int' (unless riscv is packed by
default and doesn't have 'sss' aligned to an 'int').
That's because C guarantees this.
We lose this fact because get_object_alignment_2 "knows better", aka
in some places GCC tries to work like a DWIM compiler, saving people
from mistakes. Here get_inner_reference sees we access 'array' and
adjusts alignment according to its alignment, ignoring what the language
standard guarantees.
[Bug c++/106829] OpenMP offload internal compiler error: in gimplify_expr, at gimplify.cc:16222
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106829 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Reducing and bisecting now.
[Bug libstdc++/106808] std::string_view range concept requirement causes compile error with Boost.Filesystem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.4 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Jonathan Wakely --- Backported as r11-10236-g9c6141bfec48c2 so I think this is now fixed on all branches, meaning the C++23 range constructor is explicit in 12.2 already, and will be explicit in 11.4 when that is released.
[Bug c/106830] [13 Regression] ICE: in tree_to_uhwi, at tree.cc:6392 (from check_for_xor_used_as_pow) since r13-2386-gbedfca647a9e9c1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106830 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Summary|[13 Regression] ICE: in |[13 Regression] ICE: in |tree_to_uhwi, at|tree_to_uhwi, at |tree.cc:6392 (from |tree.cc:6392 (from |check_for_xor_used_as_pow) |check_for_xor_used_as_pow) ||since ||r13-2386-gbedfca647a9e9c1a --- Comment #2 from Martin Liška --- Started with r13-2386-gbedfca647a9e9c1a.
[Bug ipa/106816] noreturn/pure attributes are not set correctly on multiversioned functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106816 --- Comment #5 from Richard Biener --- The function should probably inherit all of the IPA pure/const/modref analysis result, that is all "IPA" state should be copied. I think we want some helper here - IPA clone creation must have something, no?
[Bug target/106815] [13 Regression] ICE: in riscv_excess_precision, at config/riscv/riscv.cc:5967 with -fexcess-precision=16 on any input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106815 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug target/106827] operator++ doesn't work for enum -O2 -mcpu=cortex-m0plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106827 Richard Earnshaw changed: What|Removed |Added Last reconfirmed||2022-09-05 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #2 from Richard Earnshaw --- Please put testcases in the bug report, godbolt links are not stable.
[Bug middle-end/106833] Handle OPAQUE_TYPE in gimple_canonical_types_compatible_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #6 from rguenther at suse dot de ---
On Mon, 5 Sep 2022, linkw at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
>
> --- Comment #4 from Kewen Lin ---
> (In reply to Richard Biener from comment #2)
> > (In reply to Kewen Lin from comment #1)
> > > IMHO this is an omission when we were adding supports for opaque type,
> > > const
> > > __vector_quad and __vector_quad should be taken as
> > > canonical_types_compatible.
> > >
> > > I wonder if we can simply take it just like what it handles for
> > > "Non-aggregate types", for example:
> > >
> > > diff --git a/gcc/tree.cc b/gcc/tree.cc
> > > index 2f488e4467c..555e96c59d5 100644
> > > --- a/gcc/tree.cc
> > > +++ b/gcc/tree.cc
> > > @@ -13510,6 +13510,7 @@ gimple_canonical_types_compatible_p (const_tree
> > > t1,
> > > const_tree t2,
> > >|| TREE_CODE (t1) == VECTOR_TYPE
> > >|| TREE_CODE (t1) == COMPLEX_TYPE
> > >|| TREE_CODE (t1) == OFFSET_TYPE
> > > + || TREE_CODE (t1) == OPAQUE_TYPE
> > >|| POINTER_TYPE_P (t1))
> > > {
> > >/* Can't be the same type if they have different recision. */
> > >
> > > Or adding one default hook which does the similar thing, and then if one
> > > target needs some target specific checks on its opaque type, one specific
> > > hook can be provided.
> >
> > I'm quoting tree.def, emphasis mine:
> >
> > /* This is for types that will use MODE_OPAQUE in the back end. They are
> > meant
> >to be able to go in a register of some sort but are _EXPLICITLY NOT TO BE
> >CONVERTED_ or operated on like INTEGER_TYPE. They will have size and
> >alignment information only. */
> > DEFTREECODE (OPAQUE_TYPE, "opaque_type", tcc_type, 0)
> >
>
> Good point! My fault, I didn't read through this documentation. It seems to
> say
> no conversions are allowed on it? (either explicit or implicit?)
>
> > so why should we care about special-casing them? The target should have set
> > TYPE_CANONICAL appropriately if necessary, why didn't it? Btw, 'const'
> > qualification should go into the type variant chain (well, for "normal"
> > types), where TYPE_MAIN_VARIANT is the unqualified type variant.
> > TYPE_CANONICAL
> > shouldn't come into play here.
> >
>
> With flag_checking on, while doing lto_fixup_state, verify_type will check
> every tree type, it further checks with verify_type_variant, then fails with
> gimple_canonical_types_compatible_p (t, tv, false). (here
> trust_type_canonical
> is false).
Ah, that special "mode". I think verify_types shouldn't do anything
for OPAQUE_TYPES or alternatively trust the targets setup of
TYPE_MAIN_VARIANT/TYPE_CANONICAL. Maybe verify TYPE_CANONICAL
and TYPE_MAIN_VARIANT are also OPAQUE_TYPE.
So the solution should be fully inside verify_type.
> I think this is a common issue for any cv-qualified opaque type when lto
> checking is on.
>
> In this case,
> t1:
> const __vector_quad
>
>
> t2:
> __vector_quad
>
> Both TYPE_MAIN_VARIANT and both TYPE_CANONICAL is exactly the same here (all
> equivalent to t2).
>
> > Btw, the whole idea of "opaque" is a hack and it seems to backfire now?
>
> Not sure, it had some adjustments with r11-5222 before, I thought we need some
> similar for this issue.
