[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 Oleg Endo changed: What|Removed |Added Attachment #28207|0 |1 is obsolete|| Attachment #28633|0 |1 is obsolete|| --- Comment #99 from Oleg Endo --- Created attachment 55506 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55506=edit proposed patch (In reply to Alexander Klepikov from comment #98) > Created attachment 55503 [details] > Testcase for SH specific loop optimization pass > Thanks. I'll check it out. Meanwhile, here's my iteration on your patch.
[Bug c++/110580] [14 Regression] gcc fails to typecheck nix-2.16.1 source: error: invalid initialization of reference of type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110580
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2023-07-09
Status|UNCONFIRMED |NEW
--- Comment #2 from Andrew Pinski ---
Reduced un-preprocessed source:
```
#include
#include
#include
struct NarMember {
std::map children;
};
std::stack parents;
std::string_view g();
void createMember(NarMember member) {
parents.top()->children.emplace(g(),
std::move(member));
}
```
[Bug target/110588] btl (on x86_64) not always generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110588 Uroš Bizjak changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=107671 --- Comment #2 from Uroš Bizjak --- Similar missed optimization is reported in PR107671.
[Bug driver/110607] New: Makefile.in build broken build-tools when CXXFLAGS is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110607 Bug ID: 110607 Summary: Makefile.in build broken build-tools when CXXFLAGS is defined Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: sagebar at web dot de Target Milestone: --- This part in the main makefile: > 177 # These variables must be set on the make command line for directories > 178 # built for the build system to override those in BASE_FLAGS_TO_PASS. > 179 EXTRA_BUILD_FLAGS = \ > 180 CFLAGS="$(CFLAGS_FOR_BUILD)" \ > 181 LDFLAGS="$(LDFLAGS_FOR_BUILD)" Should instead be: > 177 # These variables must be set on the make command line for directories > 178 # built for the build system to override those in BASE_FLAGS_TO_PASS. > 179 EXTRA_BUILD_FLAGS = \ > 180 CFLAGS="$(CFLAGS_FOR_BUILD)" \ > 181 CXXFLAGS="$(CXXFLAGS_FOR_BUILD)" \ > 182 LDFLAGS="$(LDFLAGS_FOR_BUILD)" Since some components of the build system are compiled as c++, if one wants to define custom CXX-flags in cross-compilation situations, these flags then also get used when building build-tools (which causes breakage)
[Bug c++/110580] [14 Regression] gcc fails to typecheck nix-2.16.1 source: error: invalid initialization of reference of type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110580 --- Comment #1 from Andrew Pinski --- Reducing ...
[Bug lto/110605] Possible lack of error checking in lto-common.cc ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110605 --- Comment #2 from David Binderman --- Created attachment 55507 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55507=edit object module
[Bug c++/110580] [14 Regression] gcc fails to typecheck nix-2.16.1 source: error: invalid initialization of reference of type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110580
--- Comment #3 from Andrew Pinski ---
Reduced all the way:
```
template struct remove_reference {
using type = __remove_reference(_Tp);
};
template
using remove_reference_t = typename remove_reference<_Tp>::type;
template
inline constexpr bool is_same_v = __is_same(_Tp, _Up);
template class s3 {
public:
template >
static constexpr bool __usable_key = is_same_v;
template void f(_Args __args, int t) {
if constexpr (__usable_key<_Args>) {
const _Key &__k = __args;
}
}
};
struct s0 {};
struct s1 {};
s1 g();
void createMember(int member, s3 ) { children.f(g(), member); }
```
Or if using the internal type_traits is bad idea here is better testcase:
```
#include
using namespace std;
template class s3 {
public:
template >
static constexpr bool __usable_key = is_same_v;
template void f(_Args __args, int t) {
if constexpr (__usable_key<_Args>) {
const _Key &__k = __args;
}
}
};
struct s0 {};
struct s1 {};
s1 g();
void createMember(int member, s3 ) { children.f(g(), member); }
```
Here is a testcase using static assert rather than if constexpr:
```
#include
using namespace std;
template class s3 {
public:
template >
static constexpr bool __usable_key = is_same_v;
template void f(_Args __args, int t) {
static_assert(!__usable_key<_Args>);
}
};
struct s0 {};
struct s1 {};
s1 g();
void createMember(int member, s3 ) { children.f(g(), member); }
```
[Bug libgcc/109712] [13 Regression] Segmentation fault in linear_search_fdes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 --- Comment #32 from Andrew Pinski --- (In reply to Florian Weimer from comment #31) > Will propose a backport to 13 in ~2 weeks. Any news on the backport? There is aim to release GCC 13.2.0 at the end of July.
[Bug target/110592] [SPARC] GCC should default to TSO memory model when compiling for sparc32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110592 Martin Husemann changed: What|Removed |Added CC||martin at netbsd dot org --- Comment #3 from Martin Husemann --- Note that this makes it impossible for distributions to default to sparc v7 with an unmodified gcc. Only options are - locally patch (fix) gcc - provide separate distribution binaries for v7 and v8 - drop support for v7 completely ... which all three sound bad to me.
[Bug libstdc++/58338] Add noexcept to functions with a narrow contract
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338 Giuseppe D'Angelo changed: What|Removed |Added CC||dangelog at gmail dot com --- Comment #17 from Giuseppe D'Angelo --- Hi, How does all of this intersect with the Lakos' Rule (cf. the very recent P2837 and P2861)? I get that implementations have the freedom of strenghtening the noexcept contract; but is this patch following some specific libstdc++ policy (documented somewhere) -- such as, if a precondition violation is detected, libstdc++ just abort()s the process, so technically speaking, it never throws?
[Bug c++/110580] [14 Regression] gcc fails to typecheck nix-2.16.1 source: error: invalid initialization of reference of type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110580
--- Comment #4 from Andrew Pinski ---
Slightly more reduced:
```
#include
using std::is_same_v;
struct s0 {};
struct s1 {};
template
struct s3 {
template
static constexpr bool __usable_key = is_same_v<_Vp, _Key>;
static_assert(!__usable_key);
};
s3 t;
```
If I remove _Vp or remove it from being type dependent, it works.
[Bug tree-optimization/110603] [14 Regression] GCC, ICE: internal compiler error: in verify_range, at value-range.cc:1104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110603 Andrew Pinski changed: What|Removed |Added Summary|GCC, ICE: internal compiler |[14 Regression] GCC, ICE: |error: in verify_range, at |internal compiler error: in |value-range.cc:1104 |verify_range, at ||value-range.cc:1104 Keywords||ice-on-valid-code Target Milestone|--- |14.0 Component|c |tree-optimization
[Bug fortran/104649] ICE in gfc_match_formal_arglist, at fortran/decl.cc:6733 since r6-1958-g4668d6f9c00d4767
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104649
--- Comment #3 from Paul Thomas ---
(In reply to kargl from comment #2)
> Null pointer dereference.
>
>
> diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
> index bd586e75008..8e2cd511c4d 100644
> --- a/gcc/fortran/decl.cc
> +++ b/gcc/fortran/decl.cc
> @@ -6730,12 +6730,20 @@ ok:
> || (p->next == NULL && q->next != NULL))
> arg_count_mismatch = true;
> else if ((p->sym == NULL && q->sym == NULL)
> - || strcmp (p->sym->name, q->sym->name) == 0)
> + || (p->sym && q->sym
> + && strcmp (p->sym->name, q->sym->name) == 0))
> continue;
> else
> - gfc_error_now ("Mismatch in MODULE PROCEDURE formal "
> -"argument names (%s/%s) at %C",
> -p->sym->name, q->sym->name);
> + {
> + if (q->sym)
> + gfc_error_now ("Mismatch in MODULE PROCEDURE formal "
> + "argument names (%qs/%qs) at %C",
> + p->sym->name, q->sym->name);
> + else
> + gfc_error_now ("Mismatch in MODULE PROCEDURE formal argument "
> + "name, %qs, and alternate return at %C",
> + p->sym->name);
> + }
> }
>
>if (arg_count_mismatch)
The second testcase still segfaults and everything is so optimised away that I
cannot figure out why.
Paul
[Bug c++/110604] New: template argument deduction failed with decltype(lambda)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110604
Bug ID: 110604
Summary: template argument deduction failed with
decltype(lambda)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ted at lyncon dot se
Target Milestone: ---
Compiling this in C++20 mode on trunk (https://godbolt.org/z/dW5cf3WrK):
```
template
struct foo {
template
void bar() {}
};
int main() {
[[maybe_unused]] auto v = foo();
v.bar<>();
v.bar();
}
```
Results in the following error:
```
: In function 'int main()':
:10:12: error: no matching function for call to 'foo::bar<>()'
10 | v.bar<>();
| ~~~^~
:4:10: note: candidate: 'template void foo<
>::bar() [with = void]'
4 | void bar() {}
| ^~~
:4:10: note: template argument deduction/substitution failed:
:11:10: error: no matching function for call to 'foo::bar()'
11 | v.bar();
| ~^~
:4:10: note: candidate: 'template void foo<
>::bar() [with = void]'
4 | void bar() {}
| ^~~
:4:10: note: template argument deduction/substitution failed:
```
Possibly a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102721,
but I'm not 100% sure.
[Bug target/110606] New: [10/11/12/13/14] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606
Bug ID: 110606
Summary: [10/11/12/13/14] ICE output_operand: '%&' used without
any local dynamic TLS references on
powerpc64le-linux-gnu
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
[forwarded from https://bugs.debian.org/1040444]
seen with 10, 11, 12, 13 and trunk, building firefox.
$ cat Unified_cpp_gfx_skia17.ii
struct SkSTArray {
int *begin();
int *end();
};
static void *AllocMemory();
struct IRNode {
void *operator new(unsigned long) { return AllocMemory(); }
};
struct SwitchCase : IRNode {
static void MakeDefault() { new SwitchCase(true, 0); }
SwitchCase(bool, int);
};
SkSTArray __trans_tmp_3;
void inlineStatement() {
for (int switchCaseStmt : __trans_tmp_3)
SwitchCase::MakeDefault();
}
static thread_local int *sMemPool;
int set_thread_local_memory_pool_memPool;
void detachFromThread() { sMemPool = _thread_local_memory_pool_memPool; }
long AllocMemory_size;
void *AllocMemory() {
void *__trans_tmp_2;
if (sMemPool) {
__trans_tmp_2 = operator new(AllocMemory_size);
return __trans_tmp_2;
}
void *ptr = operator new(AllocMemory_size);
return ptr;
}
$ powerpc64le-linux-gnu-g++-13 -c Unified_cpp_gfx_skia17.ii -fno-exceptions
-fno-strict-aliasing -fPIC -O2
during RTL pass: final
Unified_cpp_gfx_skia17.ii: In function ‘void inlineStatement()’:
Unified_cpp_gfx_skia17.ii:17:1: internal compiler error: output_operand: '%&'
used without any local dynamic TLS references
17 | }
| ^
0xa06ff3 output_operand_lossage(char const*, ...)
../../src/gcc/final.cc:3190
0xa07373 output_operand(rtx_def*, int)
../../src/gcc/final.cc:3632
0xa07c5c output_asm_insn(char const*, rtx_def**)
../../src/gcc/final.cc:3557
0xa09517 final_scan_insn_1
../../src/gcc/final.cc:2841
0xa09a08 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../src/gcc/final.cc:2887
0xa09c95 final_1
../../src/gcc/final.cc:1979
0xa0a4a6 rest_of_handle_final
../../src/gcc/final.cc:4240
0xa0a4a6 execute
../../src/gcc/final.cc:4318
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
Configured with: ../src/configure -v --with-pkgversion='Debian 13.1.0-6'
--with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13 --enable-shared
--enable-linker-build-id --libexecdir=/usr/libexec --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--without-target-system-zlib --with-libphobos-druntime-only=yes
--enable-secureplt --enable-targets=powerpcle-linux --disable-multilib
--enable-multiarch --disable-werror --with-long-double-128
--enable-offload-targets=nvptx-none=/build/gcc-13-cross-pG4N37/gcc-13-cross-6/gcc/debian/tmp-nvptx/usr
--enable-offload-defaulted --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=powerpc64le-linux-gnu
--program-prefix=powerpc64le-linux-gnu-
--includedir=/usr/powerpc64le-linux-gnu/include
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
[Bug lto/110605] Possible lack of error checking in lto-common.cc ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110605 --- Comment #3 from David Binderman --- Given the command line: /home/dcb38/gcc/results.20230706.valgrind/bin/gcc cpgarro.o libpgplot.a then I get the valgrind error. I have attached cpgarro.o, but libpgplot.a, even with compression from xz, is 2,248,588 bytes long, so still too large. Any hints to avoid this file size limit would be most welcome.
[Bug target/110592] [SPARC] GCC should default to TSO memory model when compiling for sparc32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110592 --- Comment #4 from Eric Botcazou --- > Note that this makes it impossible for distributions to default to sparc v7 > with an unmodified gcc. > > Only options are > - locally patch (fix) gcc > - provide separate distribution binaries for v7 and v8 > - drop support for v7 completely > > ... which all three sound bad to me. Well, you need to elaborate a bit here, because the current configuration has been there for a quarter of century and everybody had apparently survived it until a couple of days ago.
[Bug bootstrap/90543] Build failure on MINGW for gcc-9.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90543 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.2
[Bug c++/110580] [14 Regression] gcc fails to typecheck nix-2.16.1 source: error: invalid initialization of reference of type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110580
Andrew Pinski changed:
What|Removed |Added
Keywords||accepts-invalid
--- Comment #6 from Andrew Pinski ---
yes my theory is correct and becomes obvious with the error message for:
```
struct s0 {};
struct s1 {};
struct s2 {};
template
struct t;
template
struct s3 {
template
static constexpr bool __usable_key = t<_Vp>::v;
static_assert(__usable_key);
static_assert(__usable_key);
};
s3 t2;
```
Error message:
```
: In instantiation of 'constexpr const bool s3::__usable_key':
...
: In instantiation of 'constexpr const bool s3::__usable_key':
```
s2 there is definitely incorrect
[Bug target/97585] Improve documentation for -march=x86-64 to say MMX, SSE, SSE2 are implied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97585 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-07-10 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/99717] ICE in finish_expr_stmt, at cp/semantics.c:681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99717 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2023-07-10 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Without a testcase, it is going to be hard to reproduce and figure out what was going on.
[Bug bootstrap/90543] Build failure on MINGW for gcc-9.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90543 Andrew Pinski changed: What|Removed |Added CC||p...@gcc-bugzilla.mail.kaps ||i.fi --- Comment #19 from Andrew Pinski --- *** Bug 3 has been marked as a duplicate of this bug. ***
[Bug bootstrap/88883] [AArch64] gcc/config/aarch64/aarch64.opt: aarch64_branch_protection_string type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Oh this was fixed already. a dup of bug 90543. *** This bug has been marked as a duplicate of bug 90543 ***
[Bug rtl-optimization/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110206 Uroš Bizjak changed: What|Removed |Added Keywords|needs-bisection | Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Status|NEW |ASSIGNED --- Comment #11 from Uroš Bizjak --- Patch at [1]. [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623933.html
[Bug libstdc++/110602] std::format and friends are accessible without std::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110602 --- Comment #4 from Jonathan Wakely --- (In reply to kefu chai from comment #0) > i also tested clang + libstdc++ and clang + libc++. all of these > combinations compiles. That's usually a sign the code is valid.
[Bug c/110603] New: GCC, ICE: internal compiler error: in verify_range, at value-range.cc:1104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110603
Bug ID: 110603
Summary: GCC, ICE: internal compiler error: in verify_range, at
value-range.cc:1104
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: 141242068 at smail dot nju.edu.cn
Target Milestone: ---
The testing program:
```
typedef long unsigned int size_t;
void *memcpy(void *, const void *, size_t);
int snprintf(char *restrict, size_t, const char *restrict, ...);
extern char a[2];
void test_func_on_line_62(void) {
memcpy(a, "12", sizeof("12") - 1);
const int res = snprintf(0, 0, "%s", a);
if (res <= 3)
do {
extern void f(void);
f();
} while (0);
}
```
When attempting to compile it with `gcc-14 -O2 small.c`, gcc-14 crashes:
```
during GIMPLE pass: strlen
: In function 'test_func_on_line_62':
:6:6: internal compiler error: in verify_range, at value-range.cc:1104
6 | void test_func_on_line_62(void) {
| ^~~~
0x213b0ee internal_error(char const*, ...)
???:0
0x9ca9f8 fancy_abort(char const*, int, char const*)
???:0
0x13df0f7 irange::set(tree_node*, generic_wide_int const&,
generic_wide_int const&, value_range_kind)
???:0
0x1e24a5d handle_printf_call(gimple_stmt_iterator*, pointer_query&)
???:0
0x12d3d86 strlen_pass::check_and_optimize_call(bool*)
???:0
0x12d4109 strlen_pass::check_and_optimize_stmt(bool*)
???:0
0x12d4494 strlen_pass::before_dom_children(basic_block_def*)
???:0
0x1d98997 dom_walker::walk(basic_block_def*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug lto/110605] New: Possible lack of error checking in lto-common.cc ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110605 Bug ID: 110605 Summary: Possible lack of error checking in lto-common.cc ? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- I am investigating a valgrind error in the lto code: ==910546== Conditional jump or move depends on uninitialised value(s) ==910546==at 0x71DF70: lto_resolution_read (lto-common.cc:2126) ==910546==by 0x71DF70: lto_file_read (lto-common.cc:2351) ==910546==by 0x71DF70: read_cgraph_and_symbols(unsigned int, char const**) (lto-common.cc:2805) ==910546==by 0x706FA9: lto_main() (lto.cc:654) ==910546==by 0xCE0F39: compile_file() (toplev.cc:444) ==910546==by 0x6C26F9: do_compile (toplev.cc:2126) ==910546==by 0x6C26F9: toplev::main(int, char**) (toplev.cc:2282) ==910546==by 0x6C3FDA: main (main.cc:39) The line 2126 is ^d4ba3b369 (Jonathan Wakely 2022-11-01 09:48:41 + 2126) if (strcmp (lto_resolution_str[j], r_str) == 0) I had a look around and I noticed just before this is: ^d4ba3b369 (Jonathan Wakely 2022-11-01 09:48:41 + 2106) fscanf (resolution, "%u", _symbols); It has no error checking. I think this will produce a warning with -D_FORTIFY_SOURCE=1. I can't prove the lack of error checking on the fscanf line is related to my valgrind problem, but it does look suspicious. Suggest fix.
[Bug lto/110605] Possible lack of error checking in lto-common.cc ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110605 --- Comment #1 from Andrew Pinski --- most likely not a big issue of not checking the return value here as the next fscanf that is the first thing inside the loop around num_symbols .
[Bug c++/110608] error on evaluation of concept three_way_comparable on recursive variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110608 --- Comment #1 from Andrew Pinski --- I think GCC is correct here ... GCC is the only compiler which implements the `satisfaction of atomic constraint not depending on itself` part of the C++ standard (there are a few open bugs dealing with that but just left open because maybe the C++ standard will change).
[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 --- Comment #6 from Andrew Pinski --- >The address 2001 1548 exist not in my map file as variable. It is a stack address. Since UnitDelay_DSTATE is defined on the stack. Comment #2 applies here. The code that GCC compiles seems to be corresponding to the assembly code that GCC is producing too. rtu_AngleMecIn will contain the address of UnitDelay_DSTATE which is a variable on stack inside MotorControlLib_step .
[Bug libstdc++/109891] Null pointer special handling in ostream's operator << for C-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #10 from Andrew Pinski --- Dup of bug 86130. *** This bug has been marked as a duplicate of bug 86130 ***
[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130 Andrew Pinski changed: What|Removed |Added CC||mimomorin at gmail dot com --- Comment #17 from Andrew Pinski --- *** Bug 109891 has been marked as a duplicate of this bug. ***
[Bug bootstrap/88883] [AArch64] gcc/config/aarch64/aarch64.opt: aarch64_branch_protection_string type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3 Andrew Pinski changed: What|Removed |Added Component|driver |bootstrap --- Comment #1 from Andrew Pinski --- It should have been recorded as string type in optc-save-gen.awk.
[Bug c/110609] Bogus -Wmismatched-dealloc when allocator defined & used in same TU w/ -fPIC -fno-semantic-interposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110609 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 110546 ***
[Bug tree-optimization/110546] Function clone not treated as valid allocator with -Wmismatched-dealloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110546 Andrew Pinski changed: What|Removed |Added CC||andres at anarazel dot de --- Comment #2 from Andrew Pinski --- *** Bug 110609 has been marked as a duplicate of this bug. ***
[Bug target/110591] [i386] (Maybe) Missed optimisation: _cmpccxadd sets flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110591 --- Comment #1 from Hongtao.liu --- I guess we can add a peephole for this, middle-end optimizer doesn't know cmpccxadd set EFLAGS same as cmp.
[Bug target/101469] wrong code with "-O2 -fPIE" for SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469 --- Comment #9 from Oleg Endo --- (In reply to Rin Okuyama from comment #8) > (In reply to Oleg Endo from comment #7) > > Hi Oleg. Thank you very much for your great work! > > I've tested your patch with GCC 10.4.0 in this weekend, and it perfectly > worked: > - testcase attached to comment #0 compiled correctly > - full regression tests on NetBSD/shle-current built by patched GCC > successfully completed without any regression (compared with system built by > GCC with that peephole optimization removed) > - some 3rd party softwares (including perl 5.36.0, ruby 3.10.10, zsh 5.9, > ...) self-built on shle host by GCC of same code base > > Let me thank you again, Oleg! > > rin Thanks you so much for getting back! Sorry for being late for 2 years with this. I will commit the patch to all open GCC versions. Unfortunately GCC 10.5 has just been released recently and that was the last version 10. So the patch will be included from GCC version 11.
[Bug target/101469] wrong code with "-O2 -fPIE" for SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469 --- Comment #10 from Rin Okuyama --- (In reply to Oleg Endo from comment #9) > Sorry for being late for 2 years with this. ... > Unfortunately GCC 10.5 has just been released recently and that was the last > version 10. > So the patch will be included from GCC version 11. No problem at all! We will probably ship GCC 10.5 with your fix for NetBSD 10. And we will switch to GCC 12 for NetBSD-current soon. > I will commit the patch to all open GCC versions. I'm looking forward to it :) I'm really excited to know that we have active GCC developer working on SH! Thanks, rin
[Bug target/95661] Code built with -m32 uses SSE2 instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95661 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #5 from Andrew Pinski --- This is a dup of bug 109954 in the end which was fixed. *** This bug has been marked as a duplicate of bug 109954 ***
[Bug target/109954] x86-64's -m32 does not conform to documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954 Andrew Pinski changed: What|Removed |Added CC||memmerto at ca dot ibm.com --- Comment #21 from Andrew Pinski --- *** Bug 95661 has been marked as a duplicate of this bug. ***
[Bug bootstrap/88883] [AArch64] gcc/config/aarch64/aarch64.opt: aarch64_branch_protection_string type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3 --- Comment #2 from Andrew Pinski --- For a cross from x86_64-linux-gnu to aarch64-linux-gnu produces: if (ptr->x_aarch64_branch_protection_string) fprintf (file, "%*s%s (%s)\n", indent, "", "aarch64_branch_protection_string", ptr->x_aarch64_branch_protection_string);
[Bug bootstrap/88623] gcc build uses CXX_FOR_BUILD but files have .c extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88623 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |12.0 --- Comment #6 from Andrew Pinski --- All c++ files were renamed at r12-6650-5c69acb32329d49e58c26f .
[Bug c++/110580] [14 Regression] gcc fails to typecheck nix-2.16.1 source: error: invalid initialization of reference of type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110580
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #5 from Andrew Pinski ---
Here is another testcase:
```
struct s0 {};
struct s1 {};
template
struct t
{
static constexpr bool v = false;
};
template<>
struct t
{
static constexpr bool v = true;
};
template
struct s3 {
template
static constexpr bool __usable_key = t<_Vp>::v;
static_assert(__usable_key);
static_assert(!__usable_key);
};
s3 t2;
```
I get the feeling _Up in the default template argument of __usable_key is
being replaced with _Key template argument for some reason.
[Bug rtl-optimization/67226] Incorrect code generated for tail call, where parameters are structs passed by value, -O2 is used, and target is ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67226 Andrew Pinski changed: What|Removed |Added CC||alexandre.nunes at gmail dot com --- Comment #11 from Andrew Pinski --- *** Bug 63206 has been marked as a duplicate of this bug. ***
[Bug target/63206] Gcc 4.9.1 Generated code needlessly stacks r3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63206 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- Dup of bug 67226. *** This bug has been marked as a duplicate of bug 67226 ***
[Bug c/110609] New: Bogus -Wmismatched-dealloc when allocator defined & used in same TU w/ -fPIC -fno-semantic-interposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110609
Bug ID: 110609
Summary: Bogus -Wmismatched-dealloc when allocator defined &
used in same TU w/ -fPIC -fno-semantic-interposition
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andres at anarazel dot de
Target Milestone: ---
Hi,
Whenever an allocator function annotated with attribute((malloc(freelike)) is
defined and used in the same translation unit and -fno-semantic-interposition
-fPIC are used, bogus mismatched alloc/free warnings ensue.
void somefree(int *);
__attribute__((__malloc__(somefree, 1)))
int *somealloc(void) {
return 0;
}
void other(void) {
int *v = somealloc();
somefree(v);
}
---
gcc -Wmismatched-dealloc -fno-semantic-interposition -fPIC -o a.out -c fd.c.i
fd.c.i: In function ‘other’:
fd.c.i:10:3: warning: ‘somefree’ called on pointer returned from a mismatched
allocation function [-Wmismatched-dealloc]
10 | somefree(v);
| ^~~
fd.c.i:9:12: note: returned from ‘somealloc.localalias’
9 | int *v = somealloc();
|^~~
This appears to happen with all versions supporting -Wmismatched-dealloc,
including today's git head at 3b007164b3e.
Regards,
Andres
[Bug tree-optimization/89996] [avr] ICE in expand_expr_real_2 with -O3 and address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89996
Andrew Pinski changed:
What|Removed |Added
Component|target |tree-optimization
Summary|[avr] ICE in|[avr] ICE in
|expand_expr_real_2 with -O3 |expand_expr_real_2 with -O3
||and address spaces
Known to fail||9.2.0
--- Comment #2 from Andrew Pinski ---
With -fchecking we get:
:23:13: error: type mismatch in 'pointer_plus_expr'
23 | static void send_document(DESC *d, short err, const char __flash
*err_string,
| ^
const char[5] *
const struct
{
char ext[5];
const char * desc;
_Bool subst;
}[3] *
sizetype
_5 = _types + _9;
:23: confused by earlier errors, bailing out
This is from laddress.
[Bug debug/88094] ICE: add add_dwarf_attr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88094 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.5 Last reconfirmed||2023-07-10 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. This is a dup of bug 100530. I am going to mark this as a dup of the newer bug just because it might/will get more attention because it is filed against x86_64 and is marked as a regression already.
[Bug fortran/110288] [11/12/13/14] Regression: segfault in findloc with allocatable array of allocatable characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110288
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #2 from anlauf at gcc dot gnu.org ---
Interesting bug.
Modified testcase:
program test
character(len=:), allocatable, dimension(:) :: array
array = ["bb", "aa"]
print *, findloc (array, "aa", dim=1, kind=8)
contains
subroutine sub (str)
character(*), intent(in) :: str(:)
! print *, findloc (str, "bb", dim=1, kind=8) ! (un-)comment this line!
end
end program test
The tree-dump shows for the findloc call:
D.4354 = _gfortran_findloc2_s1 (, &"aa"[1]{lb: 1 sz: 1}, 0, &.array, 2);
Note that we pass an address where we should pass the dereferenced length.
Uncommenting the marked line, we get instead (for the same source line!):
D.4374 = _gfortran_findloc2_s1 (, &"aa"[1]{lb: 1 sz: 1}, 0, .array, 2);
Indeed this variant is fine and runs fine.
[Bug driver/87769] GCC build from source uses headers and libraries from directories host machine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87769 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #12 from Andrew Pinski --- Because pc as the vendor for x86_64-* is the default. >From config.sub: # We use `pc' rather than `unknown' # because (1) that's what they normally are, and # (2) the word "unknown" tends to confuse beginning users. i*86 | x86_64) cpu=$basic_machine vendor=pc ;;
[Bug target/101469] wrong code with "-O2 -fPIE" for SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469 --- Comment #8 from Rin Okuyama --- (In reply to Oleg Endo from comment #7) Hi Oleg. Thank you very much for your great work! I've tested your patch with GCC 10.4.0 in this weekend, and it perfectly worked: - testcase attached to comment #0 compiled correctly - full regression tests on NetBSD/shle-current built by patched GCC successfully completed without any regression (compared with system built by GCC with that peephole optimization removed) - some 3rd party softwares (including perl 5.36.0, ruby 3.10.10, zsh 5.9, ...) self-built on shle host by GCC of same code base Let me thank you again, Oleg! rin
[Bug target/110591] [i386] (Maybe) Missed optimisation: _cmpccxadd sets flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110591 --- Comment #2 from Hongtao.liu --- (In reply to Hongtao.liu from comment #1) > I guess we can add a peephole for this, middle-end optimizer doesn't know > cmpccxadd set EFLAGS same as cmp. We already have a peephole for cmpxchg, for cmpxchg it's only valid for CCZmode, but for cmpccxadd, it should be ok for all CCmode since it sets EFLAGS exactly the same as CMP. The _CMPCCX_Z in the intrinsic is used as condition of updating memory.
[Bug tree-optimization/89996] ICE in expand_expr_real_2 with -O3 and address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89996 Andrew Pinski changed: What|Removed |Added Known to fail||6.1.0 Status|UNCONFIRMED |NEW Last reconfirmed||2023-07-10 Ever confirmed|0 |1 --- Comment #5 from Andrew Pinski --- Confirmed. At least for x86_64, it is not a regression.
[Bug c++/110608] New: error on evaluation of concept three_way_comparable on recursive variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110608 Bug ID: 110608 Summary: error on evaluation of concept three_way_comparable on recursive variant Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: walim at gmx dot net Target Milestone: --- Created attachment 55508 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55508=edit reduced demo of the error situation (-std=c++20 or higher must be active to reproduce the error) A recursiv variant type with its data type as base will not compile in g++ with -std=c++20 or higher, because of problems evaluating the concept three_way_comparable Found on g++ 13.2 on some linux installations and reproduced in compiler explorer. (No such error in clang++ and vc)
[Bug bootstrap/110607] Makefile.in builds broken build-tools when CXXFLAGS is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110607 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-07-09 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Looks like this has been posted a few times. Feb this year: https://inbox.sourceware.org/gcc-patches/20230222123411.419584-1-yash.shi...@windriver.com/ September last year: https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601344.html With an approval in November: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606922.html
[Bug tree-optimization/110600] [14 Regregression] ICE on valid code at -O1 and above on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110600 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- Fixed.
[Bug bootstrap/110607] Makefile.in builds broken build-tools when CXXFLAGS is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110607 --- Comment #2 from sagebar at web dot de --- @Andrew Pinski Sorry if this is a known bug. I simply checked the current gcc master (https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=Makefile.tpl;h=d0fe7e2fb778b3c3fa2cc8742e06cf1f78fdc5f2;hb=HEAD#l183), which is still affected. I was not aware that a fix was already pending but not yet merged.
[Bug target/110170] Sub-optimal conditional jumps in conditional-swap with floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110170 --- Comment #12 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:d41a57c46df6f8f7dae0c0a8b349e734806a837b commit r14-2403-gd41a57c46df6f8f7dae0c0a8b349e734806a837b Author: liuhongt Date: Mon Jul 3 18:19:19 2023 +0800 Add pre_reload splitter to detect fp min/max pattern. We have ix86_expand_sse_fp_minmax to detect min/max sematics, but it requires rtx_equal_p for cmp_op0/cmp_op1 and if_true/if_false, for the testcase in the PR, there's an extra move from cmp_op0 to if_true, and it failed ix86_expand_sse_fp_minmax. This patch adds pre_reload splitter to detect the min/max pattern. Operands order in MINSS matters for signed zero and NANs, since the instruction always returns second operand when any operand is NAN or both operands are zero. gcc/ChangeLog: PR target/110170 * config/i386/i386.md (*ieee_max3_1): New pre_reload splitter to detect fp max pattern. (*ieee_min3_1): Ditto, but for fp min pattern. gcc/testsuite/ChangeLog: * g++.target/i386/pr110170.C: New test. * gcc.target/i386/pr110170.c: New test.
[Bug tree-optimization/89996] ICE in expand_expr_real_2 with -O3 and address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89996 Andrew Pinski changed: What|Removed |Added Target|avr |avr x86_64 Summary|[avr] ICE in|ICE in expand_expr_real_2 |expand_expr_real_2 with -O3 |with -O3 and address spaces |and address spaces | --- Comment #3 from Andrew Pinski --- Can reproduce on x86_64 with __seg_gs will attach the code in a second.
[Bug tree-optimization/89996] ICE in expand_expr_real_2 with -O3 and address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89996 --- Comment #4 from Andrew Pinski --- Created attachment 55509 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55509=edit x86_64 testcase
[Bug target/69692] STV is disabled even when stack is aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69692 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Andrew Pinski --- Fixed in GCC 12.
[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 --- Comment #7 from Nikos Tosis --- thank you for the info, I will try tomorrow to see if I made a mistake in simulink or its a bug from simulink.
[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 --- Comment #5 from Nikos Tosis --- Hi, I opened this bug report in January and until today I didn't see any reaction. do you need more information about the bug or has been fixed?
[Bug target/110598] [14 Regression] wrong code on llvm-14.0.6 due to memcmp being miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110598
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
Status|NEW |ASSIGNED
--- Comment #4 from Roger Sayle ---
Mine. The new peephole2 is misbehaving with the (odd) RTL sequence:
(insn 62 61 63 2 (set (reg:DI 1 dx [111])
(const_int 0 [0])) "pr110598.c":10:10 90 {*movdi_internal}
(insn 63 62 64 2 (parallel [
(set (reg:DI 1 dx [110])
(xor:DI (reg:DI 1 dx [111])
(reg:DI 1 dx)))
(clobber (reg:CC 17 flags))
]) "pr110598.c":10:10 626 {*xordi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
Doh! I need to confirm/check that rega != regb. Interesting that DF doesn't
consider insn 62 as REG_UNUSED (i.e. dead), a classic false dependency.
[Bug c++/89793] Implicit conversion to std::string is ambiguous on GCC 8.2 but not GCC 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89793 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection, ||rejects-valid --- Comment #10 from Andrew Pinski --- I suspect r9-6526-gdcfa8518868d9e (r8-10080-g32988aac5be4fa4728 on the branch) fixed this .
[Bug target/106966] [12/13/14 Regression] alpha cross build crashes gcc-12 "internal compiler error: in emit_move_insn"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106966 matoro changed: What|Removed |Added CC||matoro_gcc_bugzilla@matoro. ||tk --- Comment #9 from matoro --- (In reply to Uroš Bizjak from comment #8) > Created attachment 55504 [details] > Proposed patch. > > Can someone please bootstrap and test the attached patch? I can queue this up to test on real hardware. By bootstrap, do you mean with --enable-bootstrap, and by test do you mean a full testsuite run or just checking that it doesn't ICE on the reproducer here?
[Bug target/88083] ICE in find_constant_pool_ref_1, at config/s390/s390.c:8231
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88083 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- fixed.
[Bug target/89233] [9 Regression] ICE in change_address_1, at emit-rtl.c:2286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89233 --- Comment #6 from Andrew Pinski --- *** Bug 88615 has been marked as a duplicate of this bug. ***
[Bug target/88615] ICE in change_address_1, at emit-rtl.c:2286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88615 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 89233 which was fixed in GCC 9 already. *** This bug has been marked as a duplicate of bug 89233 ***
