[Bug c++/99599] [11/12/13 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599 catsith at me dot com changed: What|Removed |Added CC||catsith at me dot com --- Comment #12 from catsith at me dot com --- *** Bug 109397 has been marked as a duplicate of this bug. ***
[Bug c++/109397] [concepts] Unexpected "satisfaction of atomic constraint ... depends on itself"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109397 catsith at me dot com changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from catsith at me dot com --- Allow me to resolve this as duplicate. As per other comments, the workaround is to use type traits and std::enable_if_t instead of concept/requires, or to include another constraint, e.g. template _type_c, typename _arg> requires streamable<_arg, type_b> friend type_c <<(_type_c &, _arg &&) *** This bug has been marked as a duplicate of bug 99599 ***
[Bug target/108699] gcc.c-torture/execute/builtin-bitops-1.c fails on power 9 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108699 --- Comment #4 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:cdd2d6643f7fef40e335a7027edfea7276cde608 commit r13-6993-gcdd2d6643f7fef40e335a7027edfea7276cde608 Author: Kewen Lin Date: Mon Apr 3 21:47:44 2023 -0500 rs6000: Fix vector parity support [PR108699] The failures on the original failed case builtin-bitops-1.c and the associated test case pr108699.c here show that the current support of parity vector mode is wrong on Power. The hardware insns vprtyb[wdq] which operate on the least significant bit of each byte per element, they doesn't match what RTL opcode parity needs, but the current implementation expands it with them wrongly. This patch is to fix the handling with one more insn vpopcntb. PR target/108699 gcc/ChangeLog: * config/rs6000/altivec.md (*p9v_parity2): Rename to ... (rs6000_vprtyb2): ... this. * config/rs6000/rs6000-builtins.def (VPRTYBD): Replace parityv2di2 with rs6000_vprtybv2di2. (VPRTYBW): Replace parityv4si2 with rs6000_vprtybv4si2. (VPRTYBQ): Replace parityv1ti2 with rs6000_vprtybv1ti2. * config/rs6000/vector.md (parity2 with VEC_IP): Expand with popcountv16qi2 and the corresponding rs6000_vprtyb2. gcc/testsuite/ChangeLog: * gcc.target/powerpc/p9-vparity.c: Add scan-assembler-not for vpopcntb to distinguish parity byte from parity. * gcc.target/powerpc/pr108699.c: New test.
[Bug target/108807] [11/12/13 regression] gcc.target/powerpc/vsx-builtin-10d.c fails after r11-6857-gb29225597584b6 on power 9 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108807 --- Comment #4 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:d634e6088f139ee700d79ec73b1ad6436096a6ff commit r13-6994-gd634e6088f139ee700d79ec73b1ad6436096a6ff Author: Kewen Lin Date: Mon Apr 3 21:47:54 2023 -0500 rs6000: Fix vector_set_var_p9 by considering BE [PR108807] As PR108807 exposes, the current handling in function rs6000_expand_vector_set_var_p9 doesn't take care of big endianness. Currently the function is to rotate the target vector by moving element to-be-set to element 0, set element 0 with the given val, then rotate back. To get the permutation control vector for the rotation, it makes use of lvsr and lvsl, but the element ordering is different for BE and LE (like element 0 is the most significant one on BE while the least significant one on LE), this patch is to add consideration for BE and make sure permutation control vectors for rotations are expected. As tested, it helped to fix the below failures: FAIL: gcc.target/powerpc/pr79251-run.p9.c execution test FAIL: gcc.target/powerpc/pr89765-mc.c execution test FAIL: gcc.target/powerpc/vsx-builtin-10d.c execution test FAIL: gcc.target/powerpc/vsx-builtin-11d.c execution test FAIL: gcc.target/powerpc/vsx-builtin-14d.c execution test FAIL: gcc.target/powerpc/vsx-builtin-16d.c execution test FAIL: gcc.target/powerpc/vsx-builtin-18d.c execution test FAIL: gcc.target/powerpc/vsx-builtin-9d.c execution test PR target/108807 gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_expand_vector_set_var_p9): Fix gen function for permutation control vector by considering big endianness.
[Bug c++/109397] [concepts] Unexpected "satisfaction of atomic constraint ... depends on itself"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109397 --- Comment #2 from catsith at me dot com --- Thank you. Looks like this is a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599 then. I believe I can workaround my problem by using std::enable_if_t instead of concepts.
[Bug c++/109277] [13 Regression] type_traits:1417:30: error: invalid use of incomplete type ‘class v8::internal::WasmArray’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109277 --- Comment #12 from Jason Merrill --- Created attachment 54806 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54806=edit patch to allow with -fpermissive Here's an (untested) possible approach to that. I'm about to be away for a week, so I won't be following up in that time.
[Bug c++/107484] [13 Regression] ICE: Segmentation fault (in decls_match)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107484 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed.
[Bug c++/107484] [13 Regression] ICE: Segmentation fault (in decls_match)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107484 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:0dfbb28a9549c2503204b0338bf550f1bff9c681 commit r13-6992-g0dfbb28a9549c2503204b0338bf550f1bff9c681 Author: Jason Merrill Date: Mon Apr 3 18:23:58 2023 -0400 c++: friend template matching [PR107484] Here friend matching tries to find a matching non-template friend and fails, so we mark the friend as a template specialization to be determined later. Then cplus_decl_attributes tries again to find a matching function and gets confused by DECL_TEMPLATE_INSTANTIATION without DECL_TEMPLATE_INFO. But it doesn't make sense for find_last_decl to be trying to match anything with DECL_USE_TEMPLATE set; those are matched elsewhere. PR c++/107484 gcc/cp/ChangeLog: * decl2.cc (find_last_decl): Return early if DECL_USE_TEMPLATE. gcc/testsuite/ChangeLog: * g++.dg/lookup/friend25.C: New test.
[Bug c++/109397] [concepts] Unexpected "satisfaction of atomic constraint ... depends on itself"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109397 --- Comment #1 from Andrew Pinski --- See http://wg21.link/cwg2369 also
[Bug c++/109397] New: [concepts] Unexpected "satisfaction of atomic constraint ... depends on itself"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109397
Bug ID: 109397
Summary: [concepts] Unexpected "satisfaction of atomic
constraint ... depends on itself"
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: catsith at me dot com
Target Milestone: ---
Created attachment 54805
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54805=edit
.ii file from -save-temps
Please help me understand if it's a bug in GCC or my code (which Clang
accepts).
bug.ii attached; bug.cpp and compiler output follows:
template
concept streamable = requires(_stream , _type &) {
s << static_cast<_type &&>(v);
};
struct type_a {
template
type_a <<(_arg &&) {
// std::clog << "type_a" << std::endl;
return *this;
}
};
struct type_b {
type_b <<(type_a const &) {
// std::clog << "type_b" << std::endl;
return *this;
}
};
struct type_c {
type_b b;
template
requires streamable<_arg, type_b>
friend type_c <<(type_c , _arg &) {
// std::clog << "type_c" << std::endl;
c.b << static_cast<_arg &&>(a);
return c;
}
};
int main() {
type_a a;
type_c c;
a << c; // "type_a\n" (gcc gives error here)
c << a; // "type_c\ntype_b\n"
}
$ docker run --rm -ti -v $(pwd):/root gcc g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu
--disable-multilib --enable-languages=c,c++,fortran,go
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (GCC)
$ docker run --rm -ti -v $(pwd):/root gcc g++ -std=c++2b -Wall -Wextra
-save-temps /root/bug.cpp -o /root/bug
/root/bug.cpp: In substitution of 'template requires
streamable<_arg, type_b> type_c& operator<<(type_c&, _arg&&) [with _arg =
type_c&]':
/root/bug.cpp:3:5: required by substitution of 'template
requires streamable<_arg, type_b> type_c& operator<<(type_c&, _arg&&) [with
_arg = type_c&]'
/root/bug.cpp:35:8: required from here
/root/bug.cpp:2:9: required for the satisfaction of 'streamable<_arg,
type_b>' [with _arg = type_c&]
/root/bug.cpp:2:22: in requirements with '_stream& s', '_type&& v' [with
_type = type_c&; _stream = type_b]
/root/bug.cpp:2:22: error: satisfaction of atomic constraint 'requires(_stream&
s, _type&& v) {s << static_cast<_type&&>(v);} [with _type = _arg; _stream =
type_b]' depends on itself
2 | concept streamable = requires(_stream , _type &) {
| ^
3 | s << static_cast<_type &&>(v);
| ~~
4 | };
| ~
Thank you.
[Bug analyzer/108767] O2 optimization has side effects on static analysis.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108767 --- Comment #1 from Geoffrey --- Hi, David, do you have any idea about why -O2 can lead to a FP?
[Bug analyzer/108100] GCC Static Analyzer does not know "(a || b) == true" in the true branch of "if (a || b) "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108100 --- Comment #1 from Geoffrey --- Hi, David. Could you spare some time to explain why GSA cannot handle `||`? Will you fix this? I'd like to contribute. Thanks a lot!
[Bug c++/109390] Does not reject specialized non-type argument of dependent type in class template partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109390 --- Comment #2 from Andrew Pinski --- https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2127
[Bug c++/109390] Does not reject specialized non-type argument of dependent type in class template partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109390 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102158 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-04-04 Keywords||accepts-invalid --- Comment #1 from Andrew Pinski --- Confirmed. at least related to PR 102158 .
[Bug c++/109387] "definition of explicitly-defaulted" error with explicit template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109387 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-04-04 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/88245] Wrong location for "explicitly defaulted here"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88245 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=67574 --- Comment #4 from Andrew Pinski --- I think this is a dup of bug 67574 ...
[Bug c++/109396] Winit-self doesn't warn when std::move()-d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109396 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug libstdc++/109383] [QoI] std::type_index::operator<=> should not call __builtin_strcmp twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109383 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/109392] [12/13 Regression] ICE in tree_vec_extract, at tree-vect-generic.cc:177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109392
--- Comment #2 from Andrew Pinski ---
here is a better testcase which does not use vfork which is implicit
returns_twice:
```
typedef short __attribute__ ((__vector_size__ (64))) V;
V v, w;
void g(void) __attribute__((returns_twice));
V foo (V a, V b)
{
g();
b &= v < b;
return (V){foo (b, w)[3], (V){}[3]};
}
```
[Bug tree-optimization/109392] [12/13 Regression] ICE in tree_vec_extract, at tree-vect-generic.cc:177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109392 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-04-04 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed. Most likely caused by r12-117-gb972e036f40c . I think the assert happens because the argument t is abnormal SSA_NAME and resimplify/maybe_push_res_to_seq decides it can't do anything on it so returns null.
[Bug c++/109300] [13 Regression] ICE in cp_finish_decl, at cp/decl.cc:8279 since r13-6380-gd3d205ab44088616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109300 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Patrick Palka --- Fixed.
[Bug c++/109300] [13 Regression] ICE in cp_finish_decl, at cp/decl.cc:8279 since r13-6380-gd3d205ab44088616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109300 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c37ed38ada788ae410c48ec6d8c9b5d9f32ab8cf commit r13-6989-gc37ed38ada788ae410c48ec6d8c9b5d9f32ab8cf Author: Patrick Palka Date: Mon Apr 3 18:49:37 2023 -0400 c++: ICE with loopy var tmpl auto deduction [PR109300] Now that we resolve non-dependent variable template-ids ahead of time, cp_finish_decl needs to handle a new invalid situation: we can end up trying to instantiate a variable template with deduced type before we fully parsed its initializer. PR c++/109300 gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Diagnose ordinary auto deduction with no initializer, instead of asserting. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/var-templ79.C: New test.
[Bug c++/109396] New: Winit-self doesn't warn when std::move()-d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109396
Bug ID: 109396
Summary: Winit-self doesn't warn when std::move()-d
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
In this example:
#include
struct A {
int i_;
A(int i) : i_(i_) { }
};
struct B {
int i_;
B(int i) : i_(std::move(i_)) { }
};
Compiling on gcc trunk with -Wall -Wextra gives me these warnings:
:6:5: warning: 'A::i_' is initialized with itself [-Winit-self]
6 | A(int i) : i_(i_) { }
| ^
:6:11: warning: unused parameter 'i' [-Wunused-parameter]
6 | A(int i) : i_(i_) { }
| ^
: In constructor 'B::B(int)':
:12:11: warning: unused parameter 'i' [-Wunused-parameter]
12 | B(int i) : i_(std::move(i_)) { }
| ^
-Winit-self warns on the self-initialization of A::i_ but not of B::i_ (which
is just as much a self-initialization, but via std::move).
It would be nice if -Winit-self caught the std::move (or other explicit rvalue
cast) case as well.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #36 from Martin Uecker ---
Am Montag, dem 03.04.2023 um 20:29 + schrieb qinzhao at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #35 from qinzhao at gcc dot gnu.org ---
> (In reply to Martin Uecker from comment #34)
> > Created attachment 54787 [details]
> > patch for C FE to add size expressions to VM types in structs
>
> thanks a lot for the patch.
>
> could you please provide a small testing case that works with this patch that
> I
> can take a further look?
I considered pointers to arrays:
struct P {
int n;
char (*buf)[.n];
};
the FAM case needs more work and I guess there are
still many other problems with the patch.
> I tried very simple one, didn't compile:
>
> struct P {
> int k;
> int x[.k];
> };
>
> void
> foo (int n)
> {
> struct P p;
> p.k = n;
> return;
> }
>
> >
> > It works with UBSan, but it isn't clear how this could pass the
> > information to the object size pass. This also does not work for
> > parameters: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109334
>
> From your change, I can see that you put the ".k" info to the index of the
> array type for x[.k], so I guess that other passes can refer the index of the
> array type to get the max size of this array.
>
The comments in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
imply that the size information does not survive long enough
> >
> > So it seems for an attribute it might make sense to implement
> > it differently.
> implement should be different. but the functionality of the user interface is
> better to be kept consistent between attribute and language extension. i.e
>
> in addition to the basic:
>
> struct P {
> int k;
> int x[.k];
> };
>
> will you support expressions:
>
> struct P {
> int k;
> int x[.k * 4];
> }
> ?
> or other more complicated syntax?
I am not sure. I am still experimenting with this to gain experience.
It is easy to move the parser code elsehwere and then
complicated expressions can be used.
But the size expression is evaluated each time when the member is
accessed. Do we really want to run arbitrary code at this point?
Maybe the size expressions should be limited to very simple
expressions without side effects.
Martin
>
[Bug middle-end/109395] -Wvla-larger-than has no effect when compiling without optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109395 --- Comment #9 from Jakub Łukasiewicz --- (In reply to Andrew Pinski from comment #7) > Yes and that is still a VLA in terms of C99 definition ... Indeed, but we only want to prevent automatic VLA, all other instances of VM types are even encouraged. (In reply to Andrew Pinski from comment #8) > Note GCC's C++ front-end even rejects VLA definitions like that for > parameters so I don't know how useful they are really. The project is pure C and we really don't plan to convert it to C++ any time. At the same time, (recently added) diagnostics for size checking array parameter (https://godbolt.org/z/fdbheM8G9) could be really beneficial. Also, allocating on heap multidimensional arrays of unknown size is really convenient: int (*arr)[n][m] = malloc(sizeof *arr);
[Bug middle-end/109395] -Wvla-larger-than has no effect when compiling without optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109395 --- Comment #8 from Andrew Pinski --- Note GCC's C++ front-end even rejects VLA definitions like that for parameters so I don't know how useful they are really.
[Bug middle-end/109395] -Wvla-larger-than has no effect when compiling without optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109395 --- Comment #7 from Andrew Pinski --- Yes and that is still a VLA in terms of C99 definition ...
[Bug fortran/100607] ICE with SELECT RANK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100607
--- Comment #5 from Steve Kargl ---
On Mon, Apr 03, 2023 at 08:16:20PM +, anlauf at gcc dot gnu.org wrote:
> --- Comment #3 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #2)
> > Remove ice-on-invalid-code as I don't get an ICE.
> >
> > The following patch suppresses the error message with the temporary variable
> > and removes duplicated code. Please commit.
> >
> > diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> > index 46585879ddc..3462d43f346 100644
> > --- a/gcc/fortran/resolve.cc
> > +++ b/gcc/fortran/resolve.cc
> > @@ -9909,11 +9909,6 @@ resolve_select_rank (gfc_code *code, gfc_namespace
> > *old_ns)
> >|| gfc_expr_attr (code->expr1).pointer))
> > gfc_error ("RANK (*) at %L cannot be used with the pointer or "
> >"allocatable selector at %L", >where,
> > >expr1->where);
> > -
> > - if (case_value == -1 && (gfc_expr_attr (code->expr1).allocatable
> > - || gfc_expr_attr (code->expr1).pointer))
> > - gfc_error ("RANK (*) at %L cannot be used with the pointer or "
> > - "allocatable selector at %L", >where,
> > >expr1->where);
> > }
> >
> >/* Add EXEC_SELECT to switch on rank. */
>
> This is a gem: not dead code, but un-dead code ... ;-)
>
What I haven't concluded yet is if the code was copied
with the intention to edit for another error condition,
e.g., "case_value == -2" or check on code->expr2.
[Bug middle-end/109395] -Wvla-larger-than has no effect when compiling without optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109395 --- Comment #6 from Jakub Łukasiewicz --- (In reply to Andrew Pinski from comment #5) > (In reply to Jakub Łukasiewicz from comment #4) > > So there is not way of detecting automatic VLA in "debug release"? > > -Wvla works. > > https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wvla But also marks desired VLA (like in function parameters) $ gcc -std=c99 -Wvla -c foo.c foo.c:1:1: warning: ISO C90 forbids variable length array [-Wvla] 1 | int bar(int n, int[n]); | ^~~ foo.c: In function ‘foo’: foo.c:5:5: warning: ISO C90 forbids variable length array ‘arr’ [-Wvla] 5 | int arr[n]; | ^~~
[Bug middle-end/109395] -Wvla-larger-than has no effect when compiling without optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109395 --- Comment #5 from Andrew Pinski --- (In reply to Jakub Łukasiewicz from comment #4) > So there is not way of detecting automatic VLA in "debug release"? -Wvla works. https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wvla
[Bug sanitizer/108497] UBsan at -O1 failed to report an integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108497 --- Comment #4 from Li Shaohua --- (In reply to Jakub Jelinek from comment #3) > Not now nor in the near future. After all, it isn't a regression, so > couldn't be fixed during stage4 anyway. This bug affects GCC>=8. GCC<=7 work fine on this case.
[Bug middle-end/109395] -Wvla-larger-than has no effect when compiling without optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109395 --- Comment #4 from Jakub Łukasiewicz --- (In reply to Andrew Pinski from comment #3) > (In reply to Jakub Łukasiewicz from comment #2) > > Passing `-ftree-vrp` doesn't activate it either > > Because of another part of the documentation: > https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options > > Most optimizations are completely disabled at -O0 or if an -O level is not > set on the command line, even if individual optimization flags are > specified. Similarly, -Og suppresses many optimization passes. So there is not way of detecting automatic VLA in "debug release"?
[Bug middle-end/109395] -Wvla-larger-than has no effect when compiling without optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109395 --- Comment #3 from Andrew Pinski --- (In reply to Jakub Łukasiewicz from comment #2) > Passing `-ftree-vrp` doesn't activate it either Because of another part of the documentation: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options Most optimizations are completely disabled at -O0 or if an -O level is not set on the command line, even if individual optimization flags are specified. Similarly, -Og suppresses many optimization passes.
[Bug middle-end/109395] -Wvla-larger-than has no effect when compiling without optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109395 --- Comment #2 from Jakub Łukasiewicz --- (In reply to Andrew Pinski from comment #1) > This is by designed and is even documented: > https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index- > Wvla-larger-than_003d > > -Wvla-larger-than=‘PTRDIFF_MAX’ is enabled by default but is typically only > effective when -ftree-vrp is active (default for -O2 and above). Passing `-ftree-vrp` doesn't activate it either
[Bug middle-end/109395] -Wvla-larger-than has no effect when compiling without optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109395 Andrew Pinski changed: What|Removed |Added Component|c |middle-end Keywords||diagnostic Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- This is by designed and is even documented: https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wvla-larger-than_003d -Wvla-larger-than=‘PTRDIFF_MAX’ is enabled by default but is typically only effective when -ftree-vrp is active (default for -O2 and above).
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 --- Comment #8 from Eric Botcazou --- > No. Then the unwinder cannot unwind through it and the test cannot pass.
[Bug c/109395] New: -Wvla-larger-than has no effect when compiling without optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109395
Bug ID: 109395
Summary: -Wvla-larger-than has no effect when compiling without
optimizations
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dev at joren dot ga
Target Milestone: ---
Let's take the following for an example:
int bar(int n, int[n]);
void foo(int n)
{
int arr[n];
for (int i = 0; i < n; ++i) {
arr[i] = i;
}
bar(n, arr);
}
When compiled with
$ gcc -O -Wvla-larger-than=0 -c foo.c
a warning is shown as expected:
foo.c: In function ‘foo’:
foo.c:5:9: warning: argument to variable-length array may be too large
[-Wvla-larger-than=]
5 | int arr[n];
| ^~~
It works with -O, -O1, -O2, -O3, -Os, -Oz, -Ofast
On the other hand, when compiling with -O0, -Og or no -O flag, no warning is
triggered (https://godbolt.org/z/Penjbqojh).
I've tried to find if only a flag implied by optimization is required, but to
no avail.
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 --- Comment #7 from dave.anglin at bell dot net --- On 2023-04-03 4:46 p.m., ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 > > --- Comment #6 from Eric Botcazou --- >> As far as I can tell, this test has always failed on both 32-bit linux and >> hpux. > Does libgcc/config/pa/milli64.S contain CFI directives or EH tables? No.
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 --- Comment #6 from Eric Botcazou --- > As far as I can tell, this test has always failed on both 32-bit linux and > hpux. Does libgcc/config/pa/milli64.S contain CFI directives or EH tables?
[Bug fortran/100607] ICE with SELECT RANK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100607 --- Comment #4 from anlauf at gcc dot gnu.org --- BTW: the "un-dead code" was introduced with r10-2912-g70570ec1927450 .
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #35 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #34)
> Created attachment 54787 [details]
> patch for C FE to add size expressions to VM types in structs
thanks a lot for the patch.
could you please provide a small testing case that works with this patch that I
can take a further look?
I tried very simple one, didn't compile:
struct P {
int k;
int x[.k];
};
void
foo (int n)
{
struct P p;
p.k = n;
return;
}
>
> It works with UBSan, but it isn't clear how this could pass the
> information to the object size pass. This also does not work for
> parameters: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109334
>From your change, I can see that you put the ".k" info to the index of the
array type for x[.k], so I guess that other passes can refer the index of the
array type to get the max size of this array.
>
> So it seems for an attribute it might make sense to implement
> it differently.
implement should be different. but the functionality of the user interface is
better to be kept consistent between attribute and language extension. i.e
in addition to the basic:
struct P {
int k;
int x[.k];
};
will you support expressions:
struct P {
int k;
int x[.k * 4];
}
?
or other more complicated syntax?
[Bug target/109374] FAIL: gnat.dg/div_zero.adb execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109374 --- Comment #5 from John David Anglin --- I'm not sure what is expected here: (gdb) r Starting program: /home/dave/gnu/gcc/objdir/gcc/testsuite/gnat/div_zero.exe warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. Program received signal SIGFPE, Arithmetic exception. $$divoI () at ../../../gcc/libgcc/config/pa/milli64.S:448 448 addit,= 0,arg1,r0 /* trap if divisor == 0 */ (gdb) c Continuing. Breakpoint 1, __gnat_error_handler (sig=8, si=0xf8f02488, ucontext=0xf8f02508) at init.c:538 538 now, before we possibly trigger a recursive fault below. */ (gdb) p/x ((ucontext_t *) ucontext)->uc_mcontext.sc_iaoq[0] $2 = 0x1d1bf (gdb) bt #0 __gnat_error_handler (sig=8, si=0xf8f02488, ucontext=0xf8f02508) at init.c:538 #1 #2 $$divoI () at ../../../gcc/libgcc/config/pa/milli64.S:448 #3 0x0001a124 in div_zero () (gdb) frame 2 #2 $$divoI () at ../../../gcc/libgcc/config/pa/milli64.S:448 448 addit,= 0,arg1,r0 /* trap if divisor == 0 */ (gdb) disass $pc-16,$pc+16 Dump of assembler code from 0x1d1ac to 0x1d1cc: 0x0001d1ac <$$divoI+428>:bv,n r0(r31) 0x0001d1b0 <$$divoI+432>:nop 0x0001d1b4 <$$divoI+436>:blr,n r25,r0 0x0001d1b8 <$$divoI+440>:nop => 0x0001d1bc <$$divoI+444>:addi,tc,= 0,r25,r0 0x0001d1c0 <$$divoI+448>:nop 0x0001d1c4 <$$divoI+452>:bv r0(r31) 0x0001d1c8 <$$divoI+456>:copy r26,ret1 End of assembler dump. (gdb) frame 0 #0 __gnat_error_handler (sig=8, si=0xf8f02488, ucontext=0xf8f02508) at init.c:538 538 now, before we possibly trigger a recursive fault below. */ (gdb) ptype ((ucontext_t *) ucontext)->uc_mcontext.sc_iaoq[0] type = unsigned long As things stands, the pc (head iaoq value) points at the nop after the addi,tc,= which caused the trap. As far as I can tell, this test has always failed on both 32-bit linux and hpux.
[Bug fortran/100607] ICE with SELECT RANK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100607
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
CC||anlauf at gcc dot gnu.org
Keywords||diagnostic
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> Remove ice-on-invalid-code as I don't get an ICE.
>
> The following patch suppresses the error message with the temporary variable
> and removes duplicated code. Please commit.
>
> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> index 46585879ddc..3462d43f346 100644
> --- a/gcc/fortran/resolve.cc
> +++ b/gcc/fortran/resolve.cc
> @@ -9909,11 +9909,6 @@ resolve_select_rank (gfc_code *code, gfc_namespace
> *old_ns)
> || gfc_expr_attr (code->expr1).pointer))
> gfc_error ("RANK (*) at %L cannot be used with the pointer or "
> "allocatable selector at %L", >where,
> >expr1->where);
> -
> - if (case_value == -1 && (gfc_expr_attr (code->expr1).allocatable
> -|| gfc_expr_attr (code->expr1).pointer))
> - gfc_error ("RANK (*) at %L cannot be used with the pointer or "
> -"allocatable selector at %L", >where,
> >expr1->where);
> }
>
>/* Add EXEC_SELECT to switch on rank. */
This is a gem: not dead code, but un-dead code ... ;-)
> @@ -12948,7 +12943,9 @@ resolve_fl_var_and_proc (gfc_symbol *sym, int
> mp_flag)
>
>if (allocatable)
> {
> - if (dimension && as->type != AS_ASSUMED_RANK)
> + if (dimension
> + && as->type != AS_ASSUMED_RANK
> + && !sym->attr.select_rank_temporary)
> {
> gfc_error ("Allocatable array %qs at %L must have a deferred "
>"shape or assumed rank", sym->name, >declared_at);
I remember that spot of code as it was hit by one of Gerhard's testcases
with as == NULL ...
I'll have a look. The diagnostic indeed was bogus.
[Bug fortran/104349] ICE in (tree_to_uhwi) gfc_conv_array_initializer, at fortran/trans-array.cc:6337
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104349 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-April/059140.html
[Bug fortran/104349] ICE in (tree_to_uhwi) gfc_conv_array_initializer, at fortran/trans-array.cc:6337
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104349
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-04-03
CC||anlauf at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from anlauf at gcc dot gnu.org ---
The following removal of two very old lines of code remove the ICE and
fix an accepts-invalid:
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 7fb33f81788..4b5529d7136 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -3504,8 +3509,8 @@ check_restricted (gfc_expr *e)
|| sym->attr.implied_index
|| sym->attr.flavor == FL_PARAMETER
|| is_parent_of_current_ns (sym->ns)
- || (sym->ns->proc_name != NULL
- && sym->ns->proc_name->attr.flavor == FL_MODULE)
+ // || (sym->ns->proc_name != NULL
+ //&& sym->ns->proc_name->attr.flavor == FL_MODULE)
|| (gfc_is_formal_arg () && (sym->ns == gfc_current_ns)))
{
t = true;
Before, we would have silently accepted
module m
character(n), parameter :: c= 'b' ! accepts invalid
end
This change needs adjustment of the diagnostics for testcase
gfortran.dg/der_charlen_1.f90
[Bug debug/78212] Fortran allocatable strings in derived type elements debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78212 John DelSignore changed: What|Removed |Added CC||jdelsignore at perforce dot com --- Comment #2 from John DelSignore --- A user recently reported that TotalView could not print the value of Fortran variable length character strings in user defined types. Here is the test program they submitted, which is similar to the one contained in this bug report: program test implicit none type my_type character(:), allocatable :: str end type my_type type (my_type) a character(:), allocatable :: t allocate (character(10):: t) t = 'abc' a%str = 'xyz' print *, 't="', t, '", a%str="', a%str, '"' end program test The DWARF for "t" is OK, but the DWARF for field "str" in "my_type" is not. The GNU Fortran (gfortran) compiler does not generate a DWARF string length attribute for the string type. Dumping the DWARF for gfortran 10.2.0, we see: <1><2e>: Abbrev Number: 2 (DW_TAG_structure_type) <2f> DW_AT_name: (indirect string, offset: 0x0): my_type <33> DW_AT_byte_size : 16 <34> DW_AT_decl_file : 1 <35> DW_AT_decl_line : 4 <36> DW_AT_sibling : <0x55> <2><3a>: Abbrev Number: 3 (DW_TAG_member) <3b> DW_AT_name: str <3f> DW_AT_decl_file : 1 <40> DW_AT_decl_line : 7 <41> DW_AT_decl_column : 37 <42> DW_AT_type: <0x57> <46> DW_AT_data_member_location: 0 <2><47>: Abbrev Number: 4 (DW_TAG_member) <48> DW_AT_name: (indirect string, offset: 0x188): _str_length <4c> DW_AT_decl_file : 1 <4d> DW_AT_decl_line : 4 <4e> DW_AT_decl_column : 12 <4f> DW_AT_type: <0x5d> <53> DW_AT_data_member_location: 8 <1><57>: Abbrev Number: 6 (DW_TAG_pointer_type) <58> DW_AT_byte_size : 8 <59> DW_AT_type: <0x55> <1><55>: Abbrev Number: 5 (DW_TAG_string_type) Member "str" is at offset 0 in the structure and has a type that references DIE <57>. DIE <57> is a pointer type, which isn't the correct way of handling Fortran, but TotalView is smart enough to automatically dereference pointer types in Fortran codes. The target of the pointer type is a reference to DIE <55>. DIE <55> is a string type, but it does not contain an attribute that provides the string length, which I think is a compiler bug. The compiler DOES generate the correct DWARF string type DIE for "t", which is: <2>: Abbrev Number: 12 (DW_TAG_variable) DW_AT_name: t DW_AT_decl_file : 1 DW_AT_decl_line : 10 DW_AT_decl_column : 32 DW_AT_type: <0x10e> <103> DW_AT_location: 2 byte block: 91 68 (DW_OP_fbreg: -24) <1><10e>: Abbrev Number: 6 (DW_TAG_pointer_type) <10f> DW_AT_byte_size : 8 <110> DW_AT_type: <0x107> <1><107>: Abbrev Number: 14 (DW_TAG_string_type) <108> DW_AT_string_length: 5 byte block: 99 ee 0 0 0 (DW_OP_call4: <0xee>) <2>: Abbrev Number: 13 (DW_TAG_variable) DW_AT_name: .t DW_AT_type: <0x5d> DW_AT_artificial : 1 DW_AT_location: 2 byte block: 91 60 (DW_OP_fbreg: -32) Notice that the compiler generates a string type with a string length attribute, which is a reference to an artificial variable that holds the length of the string. I think that DWARF 5 can support this by generating an string length attribute that is an exprloc containing an operation that pushes the object address and adds the offset to the length field.
[Bug fortran/109394] list-directed read of character from complex number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109394 kargl at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Please see "13.10 List-directed formatting" in the Fortran standard. For the program you posted, a comma, blank, and semicolon are value separators. If you look at each token with do i = 1, mxtoks print *, trim(tokens(i)) end do you a b c a b c (1.0 2.0) 1 2 3 1.0 2.0 3.0 where the comma is the end of the character string "(1.0"
[Bug fortran/109394] New: list-directed read of character from complex number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109394 Bug ID: 109394 Summary: list-directed read of character from complex number Product: gcc Version: og11 (devel/omp/gcc-11) Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: snavece at hotmail dot com Target Milestone: --- My question is how should a complex number be parsed when using a list-directed read to a string? Currently complex numbers are parsed to two tokens in gfortran. An alternative is to parse complex numbers to one token. See examples below. I recognize that it is a judgment call. I would argue the second technique makes the handling of complex numbers easier, although it may raise a number of unintended consequences that I have not considered. Using the following file, test.f: PROGRAM MAIN C IMPLICIT NONE C INTEGER, PARAMETER :: MXTOKS = 10 INTEGER IERR C CHARACTER * 20 TOKENS(MXTOKS) CHARACTER * 132 LINE C LINE = '''A B C'' "A B C" (1.0, 2.0) 1 2 3 1.0 2.0 3.0' print *, 'Line: /', TRIM(LINE), '/' READ (LINE, *, IOSTAT=IERR) TOKENS print *, TOKENS print *, 'Ierr:', IERR STOP END and the commands in a Cygwin mksh shell: $ gfortarn -o test.exe test.f $ ./test.exe The result is: Line: /'A B C' "A B C" (1.0, 2.0) 1 2 3 1.0 2.0 3.0/ A B C A B C (1.02.0) 1 2 3 1.0 2.0 3.0 Ierr: 0 An alternate parsing could be: 'A B C' "A B C" (1.0, 2.0) 1 2 3 1.0 2.0 3.0 Ierr: -1 The IERR = -1 indicating that end of line was encountered before reading 10 tokens. My environment is mksh in a Cygwin 64 delivery running on Windows 10 Version 12H2 (OS Build 19044.2728) $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/11/lto-wrapper.exe Target: x86_64-pc-cygwin Configured with: /mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-11.3.0/configure --srcdir=/mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-11.3.0 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib --with-gcc-major-version-only --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=c,c++,fortran,lto,objc,obj-c++,jit --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --enable-libquadmath --enable-libquadmath-support --disable-libssp --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.3.0 (GCC)
[Bug tree-optimization/109392] [12/13 Regression] ICE in tree_vec_extract, at tree-vect-generic.cc:177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109392 Andrew Pinski changed: What|Removed |Added Component|c |tree-optimization Target Milestone|--- |12.3
[Bug tree-optimization/109393] Very trivial address calculation does not fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393 --- Comment #1 from Andrew Pinski --- Note sometimes -fwrapv will optimize things because it can assume that overflow is defined as wrapping and this is one case that is true. Yes it sounds counter intuitive but it is true. Even re-association happens more with -fwrapv :).
[Bug tree-optimization/109393] New: Very trivial address calculation does not fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393
Bug ID: 109393
Summary: Very trivial address calculation does not fold
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: manolis.tsamis at vrull dot eu
Target Milestone: ---
The following function
int func(int *a, int j) {
int k = j - 1;
return a[j - 1] == a[k];
}
surprisingly does not fold to `return 1;` at -O2 or higher (with any GCC
version). It can also be seen here: https://godbolt.org/z/cqr43q7fq
There are a lot of variants for this behaviour but this is the most apparent.
As can be seen in the godbolt link, the issue seems to be a combination of:
1) The -1 in a[j - 1] is turned into GIMPLE equivalent with *((a + (ulong) j)
+ (ulong) -1) but a[k] is turned into *(a + (ulong) (j - 1)).
2) The -1 is never propagated outside of the (long unsigned int) casts even
if it's completely legal/possible.
I feel that I'm missing something here about pointer rules / historical context
of these choices and I would appreciate if someone more knowlegable could
explain this combination to me.
There are a lot of cases where this can lead to inefficient codegen but most
prominently this is the reason for a additional redundant load in a hot loop of
SPEC2017's nab in the function downheap_pairs and similar missed optimizations
in omnetpp's shiftup function.
Hence this issue can both cause very unexpected missed optimization (as in the
example) and also decreases the performance of important benchmarks.
Note: The testcase is not optimized even with -fno-wrapv or -fstrict-overflow,
but does optimize with -fwrapv which is the reverse of what I would expect
since -fno-wrapv should be more permissive?
[Bug c/109392] New: [12/13 Regression] ICE in tree_vec_extract, at tree-vect-generic.cc:177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109392
Bug ID: 109392
Summary: [12/13 Regression] ICE in tree_vec_extract, at
tree-vect-generic.cc:177
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 :
$ cat z1.c
typedef short __attribute__ ((__vector_size__ (64))) V;
V v, w;
inline V foo (V a, V b);
V
foo (V a, V b)
{
vfork();
b &= v < b;
return (V){foo (b, w)[3], (V){}[3]};
}
$ gcc-13-20230402 -c z1.c
z1.c: In function 'foo':
z1.c:6:1: warning: AVX512F vector return without AVX512F enabled changes the
ABI [-Wpsabi]
6 | {
| ^
z1.c:7:3: warning: implicit declaration of function 'vfork'
[-Wimplicit-function-declaration]
7 | vfork();
| ^
z1.c:5:1: note: the ABI for passing parameters with 64-byte alignment has
changed in GCC 4.6
5 | foo (V a, V b)
| ^~~
during GIMPLE pass: veclower
z1.c:5:1: internal compiler error: in tree_vec_extract, at
tree-vect-generic.cc:177
0x111bdd6 tree_vec_extract(gimple_stmt_iterator*, tree_node*, tree_node*,
tree_node*, tree_node*)
../../gcc/tree-vect-generic.cc:177
0x111f8fb expand_vector_condition
../../gcc/tree-vect-generic.cc:1140
0x6cac8d expand_vector_comparison
../../gcc/tree-vect-generic.cc:453
0x11229c1 expand_vector_operation
../../gcc/tree-vect-generic.cc:1239
0x11229c1 expand_vector_operations_1
../../gcc/tree-vect-generic.cc:2357
0x11229c1 expand_vector_operations
../../gcc/tree-vect-generic.cc:2391
0x11229c1 execute
../../gcc/tree-vect-generic.cc:2445
[Bug fortran/104272] finalizer gets called during allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272
--- Comment #3 from Paul Thomas ---
Following the allocation itself, we get:
solver._data.dim[0].lbound = 1;
solver._data.dim[0].ubound = 2;
solver._data.dim[0].stride = 1;
solver._data.offset = -1;
solver._data.span = 64;
{
integer(kind=8) D.4532;
integer(kind=8) D.4533;
integer(kind=8) D.4534;
struct solver_sparse_gpu_t * D.4535;
D.4532 = solver._data.offset;
D.4533 = solver._data.dim[0].lbound;
D.4534 = solver._data.dim[0].ubound;
D.4535 =
{
integer(kind=8) S.20;
S.20 = D.4533;
while (1)
{
if (S.20 > D.4534) goto L.28;
{
struct __vtype_solver_m_Solver_base_t * {ref-all} D.4537;
solver._vptr = (struct __vtype_solver_m_Solver_base_t *
{ref-all}) &__vtab_solver_m_Solver_sparse_gpu_t;
D.4537 = solver._vptr;
solver._vptr->_copy (D.4535, (struct solver_base_t *)
solver._data.data + (sizetype) ((S.20 + D.4532) * solver._vptr->_size));
}
S.20 = S.20 + 1;
}
L.28:;
}
}
desc.17.dtype = {.elem_len=64, .rank=0, .type=5};
desc.17.data = (void * restrict) _gpu_t;
desc.17.span = (integer(kind=8)) desc.17.dtype.elem_len;
__final_solver_m_Solver_gpu_t (, 64, 1);
if ((complex(kind=4)[0:] * restrict) source.16.solver_gpu_t.x.data !=
0B)
{
__builtin_free ((void *) source.16.solver_gpu_t.x.data);
(complex(kind=4)[0:] * restrict) source.16.solver_gpu_t.x.data =
0B;
}
So there it is, writ large at the end. For some reason, gfc_trans_allocate
applies a default initializer and the finalizes and nulls the component.
Paul
[Bug target/109384] [13 Regression] unquoted keyword 'float' in format [-Werror=format-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109384 --- Comment #3 from Damian --- Hello Jakub, withe the change "%<-march=%s%>: z*inx conflicts with floating-point extensions ?" the build works again Best regards Damian
[Bug fortran/104272] finalizer gets called during allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |NEW Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Last reconfirmed||2023-04-03 Ever confirmed|0 |1 --- Comment #2 from Paul Thomas --- Hi Kai, Thanks for the report. nagfor agrees that the finalization shouldn't occur. From the work that I did on finalization, nagfor was the most compliant of all the compilers that I have access to. I am currently working on ASSOCIATE bugs but will come back to tidy up some of the finalization nits in a few weeks time. Confirming and taking the bug. Cheers Paul
[Bug analyzer/109361] RFE: SARIF output could contain timing/profile information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109361 --- Comment #3 from David Malcolm --- Created attachment 54804 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54804=edit v1 of patch for this This patch works, but it also enables the output on stderr, and I see significant differences in output with this. Hence I'm working on a v2 patch that adds a separate command-line option for enabling this.
[Bug ipa/108007] [10/11/12/13 Regression] wrong code at -Os and above with "-fno-dce -fno-tree-dce" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108007 --- Comment #8 from Jakub Jelinek --- E.g. PR93385.
[Bug ipa/108007] [10/11/12/13 Regression] wrong code at -Os and above with "-fno-dce -fno-tree-dce" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108007 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Martin, any progress on this? Feels like PRs we've discussed in the past (and some of them have been fixed), where IPA passes assume something isn't really needed to be computed because all its uses will be dead, but doesn't actually DCE them and because DCE is disabled, it is still needed?
[Bug target/108910] [12/13 Regression] Further ICE in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #13 from Jakub Jelinek --- Jason, any thoughts on why we for build_type_attribute_qual_variant call build_distinct_type_copy rather than build_variant_type_copy, which is e.g. what all spots in c-family/c-attribs.cc that need a separate type use? Or could we use build_variant_type_copy say for a subset of types (perhaps integral/pointer/reference/vector/complex types or something similar) and use distinct copies of the rest (function/method types, aggregates)?
[Bug modula2/109388] clang warnings related to Modula-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109388 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Gaius Mulley --- Closing as the patch has been applied - thanks for reporting the bug.
[Bug modula2/109388] clang warnings related to Modula-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109388 --- Comment #2 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:9a75f0a02e5006e081b335acd36300a85bef8eb8 commit r13-6987-g9a75f0a02e5006e081b335acd36300a85bef8eb8 Author: Gaius Mulley Date: Mon Apr 3 15:04:06 2023 +0100 PR modula2/109388 clang warnings related to Modula-2 This patch removes an unused parameter 'module' from DoVariableDeclaration in M2GCCDeclare.mod. It also removes unused procedures from PHBuild.bnf. gcc/m2/ChangeLog: PR modula2/109388 * gm2-compiler/M2GCCDeclare.mod (DoVariableDeclaration): Remove second parameter module. Adjust all callers to remove the second parameter. * gm2-compiler/PHBuild.bnf (CheckAndInsert): Remove. (InStopSet): Remove. (PeepToken): Remove. (PushQualident): Remove. (SimpleDes): Remove. (ActualParameters): Remove. Signed-off-by: Gaius Mulley
[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303 --- Comment #10 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:da3fd01757297c1d20cf3dcd76046488da737569 commit r13-6986-gda3fd01757297c1d20cf3dcd76046488da737569 Author: Martin Jambor Date: Mon Apr 3 15:53:36 2023 +0200 ipa: Avoid constructing aggregate jump functions with huge offsets (PR 109303) We are in the process of changing data structures holding information about constants passed by reference and in aggregates to use unsigned int offsets rather than HOST_WIDE_INT (which was selected simply because that is what fell out of get_ref_base_and_extent at that time) in order to conserve memory, especially at WPA time. PR 109303 testcase discovers that we do not properly check that we only create jump functions with offsets (plus sizes) that fit into the smaller type. This patch adds the necessary check. gcc/ChangeLog: 2023-03-30 Martin Jambor PR ipa/109303 * ipa-prop.cc (determine_known_aggregate_parts): Check that the offset + size will be representable in unsigned int. gcc/testsuite/ChangeLog: 2023-03-30 Jakub Jelinek Martin Jambor PR ipa/109303 * gcc.dg/pr109303.c: New test.
[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303 Martin Jambor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Martin Jambor --- Fixed.
[Bug c++/109389] g++ file.cpp -lgmp (option only works after filename)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109389 --- Comment #6 from Andrew Pinski --- Note Debian (and Ubuntu) has a patch to their GCC which does cause the default arguments to ld to include --as-needed . That is why you are seeing a difference between gcc and clang. Note if you build GCC from source, you would not have seen a difference here. Also note this is not a bug in GCC nor in debian's gcc; just you misunderstanding the how linking works too.
[Bug c++/109389] g++ file.cpp -lgmp (option only works after filename)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109389 --- Comment #5 from Andrew Pinski --- Note for shared libraries it might the case the gcc you using defaults to passing --as-needed to the linker and the clang driver does not.
[Bug c++/109389] g++ file.cpp -lgmp (option only works after filename)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109389 --- Comment #4 from Jonathan Wakely --- Clang is not a linker either. Both Clang and GCC just pass the options to the linker. Any difference in behaviour is a difference in the linker, not a difference between Clang and GCC.
[Bug c++/109389] g++ file.cpp -lgmp (option only works after filename)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109389 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- It accepts it, but it does something different from when it is after the objects.
[Bug analyzer/109190] GCC Static Analyzer cannot handle the initialization of an array with a for loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109190 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #2 from Xi Ruoyao --- With -O0 GCC does not attempt to analyze any loops. I doubt if "-O0 -fanalyzer" really makes sense. Maybe we should just emit a warning when -fanalyzer is used with -O0.
[Bug c++/109389] g++ file.cpp -lgmp (option only works after filename)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109389 --- Comment #2 from Bernd --- @ Jonathan Wakely Thank you for correcting me and setting the issue solved. Sorry for the wrong report. For a long time g++ accepted the -lgmp before the filename, clang++ still does. That's why I thought that this must a bug.
[Bug c++/109381] [10/11/12/13 Regression] Ambiguous member lookup with this-> accepted when it should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109381 Patrick Palka changed: What|Removed |Added Keywords|needs-bisection | CC||ppalka at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=15272 --- Comment #2 from Patrick Palka --- (In reply to Andrew Pinski from comment #1) > Confirmed. most likely caused by the way which got it right without this-> Yep, started with r8-5270-g2b031ef48e365e.
[Bug target/109254] Bug in gcc (13.0.1) support for ARM SVE, which randomly modifies the prediction register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109254 --- Comment #8 from Jakub Jelinek --- Should be fixed on the trunk so far.
[Bug c++/109319] [12 Regression] ICE in build_min_non_dep_op_overload, at cp/tree.cc:3793 since r12-5510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109319 Jakub Jelinek changed: What|Removed |Added Summary|[12/13 Regression] ICE in |[12 Regression] ICE in |build_min_non_dep_op_overlo |build_min_non_dep_op_overlo |ad, at cp/tree.cc:3793 |ad, at cp/tree.cc:3793 |since r12-5510 |since r12-5510 --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/109384] [13 Regression] unquoted keyword 'float' in format [-Werror=format-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109384 --- Comment #2 from Jakub Jelinek --- And something is conflict with something_else is incorrect grammar, so %<-march=%s%>: z*inx conflicts with floating-point extensions ?
[Bug target/109384] [13 Regression] unquoted keyword 'float' in format [-Werror=format-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109384 Jakub Jelinek changed: What|Removed |Added Summary|unquoted keyword 'float' in |[13 Regression] unquoted |format |keyword 'float' in format |[-Werror=format-diag] |[-Werror=format-diag] Target Milestone|--- |13.0
[Bug target/109384] unquoted keyword 'float' in format [-Werror=format-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109384 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jiawei at iscas dot ac.cn, ||kito at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The formatting of the r13-6930-gb2f327b9be81326c9e59 patch is also incorrect (missing spaces before (, wrong indentation. The wording should probably use floating-point extensions because that is how the RISCV extensions are called. The point of the warning is make sure float which is typically a keyword is quoted, e.g. % .
[Bug tree-optimization/108888] [13 Regression] error: definition in block 26 follows the use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10 avieira at gcc dot gnu.org changed: What|Removed |Added CC||avieira at gcc dot gnu.org --- Comment #6 from avieira at gcc dot gnu.org --- After this patch Andrew Stubbs patch (https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3da77f217c8b2089ecba3eb201e727c3fcdcd19d) to use in-branch simd-clones for cases like in gcc/testsuite/gcc.dg/vect/vect-simd-clone-16.c no longer work. I believe this is because this patch changes the 'if (gimple_call ..)' into a else 'if (...is_gimple_call (stmt))' which doesn't work because stmt will be 0 (it's a dyn_cast of gassign). I'm testing a patch locally to fix this.
[Bug analyzer/109190] GCC Static Analyzer cannot handle the initialization of an array with a for loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109190 --- Comment #1 from Geoffrey --- Hi, David! Could you spare a little time to explain this case to me? Thanks a lt!
[Bug analyzer/108428] -Wanalyzer-null-dereference false negative with *f = 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108428 --- Comment #2 from Geoffrey --- Hi, David! Could you spare a little time to explain this case for me? Please ^v^
[Bug rtl-optimization/109391] New: Inefficient codegen on AArch64 when structure types are returned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109391
Bug ID: 109391
Summary: Inefficient codegen on AArch64 when structure types
are returned
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization, ra
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*
This example https://godbolt.org/z/Pe3f3ozGf
---
#include
int16x8x3_t bsl(const uint16x8x3_t *check, const int16x8x3_t *in1,
const int16x8x3_t *in2) {
int16x8x3_t out;
for (uint32_t j = 0; j < 3; j++) {
out.val[j] = vbslq_s16(check->val[j], in1->val[j], in2->val[j]);
}
return out;
}
---
Generates:
bsl:
ldp q6, q16, [x1]
ldp q0, q4, [x2]
ldp q5, q7, [x0]
bsl v5.16b, v6.16b, v0.16b
ldr q0, [x2, 32]
bsl v7.16b, v16.16b, v4.16b
ldr q6, [x1, 32]
mov v1.16b, v5.16b
ldr q5, [x0, 32]
bsl v5.16b, v6.16b, v0.16b
mov v0.16b, v1.16b
mov v1.16b, v7.16b
mov v2.16b, v5.16b
ret
with 3 superfluous moves. It looks like reload is having trouble dealing
with the new compound types as return arguments.
So in RTL We have:
(insn 17 20 22 2 (set (subreg:V8HI (reg/v:V3x8HI 105 [ out ]) 16)
(xor:V8HI (and:V8HI (xor:V8HI (reg:V8HI 115 [ in2_11(D)->val[1] ])
(reg:V8HI 114 [ in1_10(D)->val[1] ]))
(reg:V8HI 113 [ check_9(D)->val[1] ]))
(reg:V8HI 115 [ in2_11(D)->val[1] ]))) "/app/example.c":7:16
discrim 1 2558 {aarch64_simd_bslv8hi_internal}
(expr_list:REG_DEAD (reg:V8HI 115 [ in2_11(D)->val[1] ])
(expr_list:REG_DEAD (reg:V8HI 114 [ in1_10(D)->val[1] ])
(expr_list:REG_DEAD (reg:V8HI 113 [ check_9(D)->val[1] ])
(nil)
(insn 22 17 29 2 (set (subreg:V8HI (reg/v:V3x8HI 105 [ out ]) 32)
(xor:V8HI (and:V8HI (xor:V8HI (reg:V8HI 118 [ in2_11(D)->val[2] ])
(reg:V8HI 117 [ in1_10(D)->val[2] ]))
(reg:V8HI 116 [ check_9(D)->val[2] ]))
(reg:V8HI 118 [ in2_11(D)->val[2] ]))) "/app/example.c":7:16
discrim 1 2558 {aarch64_simd_bslv8hi_internal}
(expr_list:REG_DEAD (reg:V8HI 118 [ in2_11(D)->val[2] ])
(expr_list:REG_DEAD (reg:V8HI 117 [ in1_10(D)->val[2] ])
(expr_list:REG_DEAD (reg:V8HI 116 [ check_9(D)->val[2] ])
(nil)
(insn 29 22 30 2 (set (reg/i:V3x8HI 32 v0)
(reg/v:V3x8HI 105 [ out ])) "/app/example.c":10:1 3964
{*aarch64_movv3x8hi}
(expr_list:REG_DEAD (reg/v:V3x8HI 105 [ out ])
(nil)))
(insn 30 29 37 2 (use (reg/i:V3x8HI 32 v0)) "/app/example.c":10:1 -1
(nil))
Reload then decides to insert a bunch of reloads:
Choosing alt 0 in insn 17: (0) =w (1) 0 (2) w (3) w
{aarch64_simd_bslv8hi_internal}
Creating newreg=126 from oldreg=113, assigning class FP_REGS to r126
17: r126:V8HI=r115:V8HI^r114:V8HI:V8HI^r115:V8HI
REG_DEAD r115:V8HI
REG_DEAD r114:V8HI
REG_DEAD r113:V8HI
Inserting insn reload before:
43: r126:V8HI=r113:V8HI
Inserting insn reload after:
44: r105:V3x8HI#16=r126:V8HI
which introduces these moves. The problem existed with the previous structure
types as well (OImode etc) so it's not new but costs us lots of perf.
I don't think I can fix this with the same pass as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106106 can I? It looks like in
this case the RTL looks fine.
[Bug c++/109389] g++ file.cpp -lgmp (option only works after filename)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109389 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- Firstly, this is a proeprty of your linker, which is not part of GCC. GCC just passes the arguments to the linker in the order you give them. Secondly, this is not a bug, it's the expected behaviour for the linker. https://c-faq.com/lib/libsearch.html
[Bug analyzer/107733] -Wanalyzer-null-dereference false positive with wrong path note "(3) 'e' is NULL" and inconsistent behaviors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107733 --- Comment #4 from Geoffrey --- (In reply to David Malcolm from comment #2) > ...and also, as you note: > * deleting the unrelated code ` int *d = 0;` should not affect the result > (but does) > > > > the path note `(3) 'e' is NULL` is wrong, this may suggest some problems. > > Note (3) seems correct to me; (1) says "following 'true' branch (when 'e' is > NULL)..." so we're on the "e is NULL" branch. Hi. David. Could you spare some time to explain this phenomenon to me ?
[Bug tree-optimization/109386] [13 Regression] Frange value relation related miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109386 --- Comment #3 from Jakub Jelinek --- Created attachment 54803 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54803=edit gcc13-pr109386.patch Untested fix. When LT/LE/GT/GE have lhs [0, 0] or UNLT/UNLE/UNGT/UNGE have lhs [1, 1], we don't know anything (VARYING) about one operand if the other operand may be a NAN, not just is known to be a NAN, because if it happens to be NAN at runtime, the comparison is false (resp. true) regardless of the finite/infinite comparison results.
[Bug c++/109390] New: Does not reject specialized non-type argument of dependent type in class template partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109390
Bug ID: 109390
Summary: Does not reject specialized non-type argument of
dependent type in class template partial
specialization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
As seen with e.g. gcc-c++-12.2.1-4.fc37.x86_64, it does not reject
> $ cat test.cc
> template struct S {};
> template struct S {};
> $ g++ -fsyntax-only test.cc
even though I think it should per (e.g. C++20) [temp.class.spec]/9.1 "The type
of a template parameter corresponding to a specialized non-type argument shall
not be dependent on a parameter of the specialization."
(I'm not sure whether or not this should be considered a duplicate of bug
102158 "[C++20] Specialized non-type template argument violates
[temp.spec.partial#general-9] but accepted by GCC".)
[Bug c++/109389] New: g++ file.cpp -lgmp (option only works after filename)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109389
Bug ID: 109389
Summary: g++ file.cpp -lgmp (option only works after filename)
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frechbengel at gmx dot de
Target Milestone: ---
Hello,
1. »g++ --version« outputs:
g++ (Debian 10.2.1-6) 10.2.1 20210110
2. »g++ --help« says:
Usage: g++ [options] file...
3. But if I try to compile:
#include
int main(){
mpz_t n;
mpz_init(n);
mpz_clear(n);
return 0;}
4. with »g++ -lgmp file.cpp« the error is:
/usr/bin/ld: /tmp/cc8lgHAc.o: in function `main':
guard_driver.cpp:(.text+0x10): undefined reference to `__gmpz_init'
/usr/bin/ld: guard_driver.cpp:(.text+0x21): undefined reference to
`__gmpz_set_ui'
/usr/bin/ld: guard_driver.cpp:(.text+0x34): undefined reference to
`operator<<(std::ostream&, __mpz_struct const*)'
/usr/bin/ld: guard_driver.cpp:(.text+0x55): undefined reference to
`__gmpz_clear'
collect2: error: ld returned 1 exit status
5. There is no error if I compile with:
»g++ file.cpp -lgmp«
6. As the --help says the options should be given BEFORE the filename it is a
feature if it works with options given after the filename, too. But I is
propably a bug that compilation only works with the option given after the
filename.
Regards and thank you for you valuable work
Bernd
[Bug target/109380] inline member function symbol not exported with explicit template instantiation declaration on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109380 LIU Hao changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #4 from LIU Hao --- Looks like GCC doesn't generate `-export:` after `.section .drectve`. The functions are generated in `.linkonce` sections correctly; they are just not exported.
[Bug tree-optimization/109386] [13 Regression] Frange value relation related miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109386 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-04-03
[Bug libstdc++/109383] [QoI] std::type_index::operator<=> should not call __builtin_strcmp twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109383 --- Comment #3 from Jonathan Wakely --- For !__GXX_TYPEINFO_EQUALITY_INLINE we need to export a new symbol from the library, so the patch above doesn't optimize that case.
[Bug libstdc++/109383] [QoI] std::type_index::operator<=> should not call __builtin_strcmp twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109383
--- Comment #2 from Jonathan Wakely ---
--- a/libstdc++-v3/include/std/typeindex
+++ b/libstdc++-v3/include/std/typeindex
@@ -87,13 +87,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
strong_ordering
operator<=>(const type_index& __rhs) const noexcept
{
+#if __GXX_TYPEINFO_EQUALITY_INLINE
+# if __GXX_MERGED_TYPEINFO_NAMES
+ return _M_target->name() <=> __rhs._M_target->name();
+# else
+ return __builtin_strcmp(_M_target->name(), __rhs._M_target->name()) <=>
0;
+# endif
+#else // __GXX_TYPEINFO_EQUALITY_INLINE
if (*_M_target == *__rhs._M_target)
return strong_ordering::equal;
if (_M_target->before(*__rhs._M_target))
return strong_ordering::less;
return strong_ordering::greater;
+#endif // __GXX_TYPEINFO_EQUALITY_INLINE
}
-#endif
+#endif // __cpp_lib_three_way_comparison
size_t
hash_code() const noexcept
[Bug tree-optimization/109386] [13 Regression] Frange value relation related miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109386
--- Comment #2 from Jakub Jelinek ---
The swapping isn't really needed, the testcase can be simplified to:
static inline float
foo (float x, float y)
{
float u = __builtin_fabsf (x);
float v = __builtin_fabsf (y);
if (!(u >= v))
{
if (__builtin_isinf (v)) return v;
if (__builtin_isinf (u)) return u;
}
return 42.0f;
}
int
main ()
{
if (!__builtin_isinf (foo (__builtin_inff (), __builtin_nanf (""
__builtin_abort ();
}
[Bug libstdc++/109383] [QoI] std::type_index::operator<=> should not call __builtin_strcmp twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109383 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-04-03 --- Comment #1 from Jonathan Wakely --- I guess we've all just implemented exactly what the standard says, without thinking about optimizing it. It's a good idea though, thanks!
[Bug modula2/109388] clang warnings related to Modula-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109388 Gaius Mulley changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-04-03 --- Comment #1 from Gaius Mulley --- Indeed thanks for reporting this - will fix.
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug rtl-optimization/108681] [12 Regression] gcc hangs compiling opencv/channels_combine.cpp for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108681 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #16 from rsandifo at gcc dot gnu.org --- Fixed for GCC 12 too.
[Bug tree-optimization/101301] Improving sparse switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug target/109072] [12 Regression] SLP costs for vec duplicate too high since g:4963079769c99c4073adfd799885410ad484cbbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug gcov-profile/105063] [GCOV] Ability to map .gcda paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063 Martin Liška changed: What|Removed |Added Target Milestone|--- |14.0
[Bug tree-optimization/103429] Optimization of Auto-generated condition chain is not giving good lookup tables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103429 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105238 Martin Liška changed: What|Removed |Added Target Milestone|--- |14.0
[Bug tree-optimization/108608] [12 Regression] AArch64 vectorizer ICE in vect_transform_reduction and __builtin_fmax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108608 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from rsandifo at gcc dot gnu.org --- FIxed.
[Bug ipa/106816] noreturn/pure attributes are not set correctly on multiversioned functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106816 Martin Liška changed: What|Removed |Added Target Milestone|--- |13.0 Keywords||patch --- Comment #11 from Martin Liška --- Patch candidate: https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615049.html
