[Bug target/114679] New: .file directive missing on MIPS ports when debug symbols are enabled.

2024-04-10 Thread jan.smets at nokia dot com via Gcc-bugs
: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jan.smets at nokia dot com Target Milestone: --- I noticed that the .file directive prints differently on targets (mips vs x86) when (dwarf) debug symbols are enabled

[Bug sanitizer/103730] ubsan: store with insufficient space for an object of type

2021-12-15 Thread jan.smets at nokia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103730 --- Comment #2 from Jan Smets --- PEBKAC. Thanks for clarifying.

[Bug sanitizer/103730] New: ubsan: store with insufficient space for an object of type

2021-12-15 Thread jan.smets at nokia dot com via Gcc-bugs
Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: jan.smets at nokia dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc

[Bug middle-end/70871] questionable optimisation in fold-const.c

2021-07-20 Thread jan.smets at nokia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70871 --- Comment #6 from Jan Smets --- Sounds good. I appreciate the follow-up, thanks you for that.

[Bug tree-optimization/100653] usage of scalar_storage_order produces incorrect result

2021-05-26 Thread jan.smets at nokia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100653 --- Comment #3 from Jan Smets --- Is there some way there can be warned against such invalid usages? Because these things are really hard to see on a 'macro' level.

[Bug c/100671] override-init suppressed in 'two shot' compilation when initializer macro/value is defined in system header file

2021-05-19 Thread jan.smets at nokia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100671 --- Comment #1 from Jan Smets --- Another one we've had problems with is quite similar. The example below is a void function trying to return a value. #if 1 /* NULL defined in a system header file => warning in "one shot" compilation.

[Bug c/100671] New: override-init suppressed in 'two shot' compilation when initializer macro/value is defined in system header file

2021-05-19 Thread jan.smets at nokia dot com via Gcc-bugs
: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jan.smets at nokia dot com Target Milestone: --- This test case reports a override-init error when doing a "one

[Bug tree-optimization/100653] New: usage of scalar_storage_order produces incorrect result

2021-05-18 Thread jan.smets at nokia dot com via Gcc-bugs
Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jan.smets at nokia dot com Target Milestone: --- Created attachment 50840 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50840=edit scalar_storage_order test case Attac

[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359

2021-02-08 Thread jan.smets at nokia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 --- Comment #10 from Jan Smets --- I have a couple of changes in my own tree. I had a couple of different issues and I don't recall exactly what change was for what specifically. I locally have a revert of

[Bug target/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

2020-11-26 Thread jan.smets at nokia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97902 --- Comment #15 from Jan Smets --- Thanks. See 98018.

[Bug target/98018] New: Option to force frame pointer

2020-11-26 Thread jan.smets at nokia dot com via Gcc-bugs
Assignee: unassigned at gcc dot gnu.org Reporter: jan.smets at nokia dot com Target Milestone: --- As discussed in PR 97902 we'd need an option that disables all optimizations that may affect the generation of a frame pointer.

[Bug target/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

2020-11-26 Thread jan.smets at nokia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97902 --- Comment #13 from Jan Smets --- H.J, There are still some very basic backtrace implementations that rely on frame pointers. (No DWARF based things or any other forms of 'assistance'). A missing stack frame means the "previous" function is not

[Bug target/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

2020-11-19 Thread jan.smets at nokia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97902 Jan Smets changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #6 from Jan Smets ---

[Bug middle-end/97902] x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

2020-11-19 Thread jan.smets at nokia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97902 --- Comment #2 from Jan Smets --- Apologies, I omitted the -O1 / -O2 $ docker run --privileged --rm -it -v /tmp:/tmp gcc:10.2 bash -c "gcc -c /tmp/test4.c -S -o - -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer | grep rbp" $ docker

[Bug middle-end/97902] New: x86 frame pointer missing with -fno-omit-frame-pointer (-mno-omit-leaf-frame-pointer)

2020-11-19 Thread jan.smets at nokia dot com via Gcc-bugs
Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jan.smets at nokia dot com Target Milestone: --- int strcmpTEST( const char * s1, const char * s2) { while (*s1++ == *s2++) if (*(s1-1

[Bug middle-end/97617] missing aggressive loop optimization warning in C++

2020-10-28 Thread jan.smets at nokia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97617 --- Comment #3 from Jan Smets --- Sorry, I was too quickly in my wording to "skip single_exit()", of course that edge is still required.

[Bug middle-end/97617] missing aggressive loop optimization warning in C++

2020-10-28 Thread jan.smets at nokia dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97617 --- Comment #2 from Jan Smets --- Is it maybe a possibility to report the (possible) false positives with something like -Waggressive-loop-optimizations=2 ? Would that only require a skip of single_exit() in

[Bug middle-end/97617] New: missing aggressive loop optimization warning in C++

2020-10-28 Thread jan.smets at nokia dot com via Gcc-bugs
Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jan.smets at nokia dot com Target Milestone: --- Created attachment 49458 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49458=edit testcase Following testcase produces a compile warning in C, but no

[Bug tree-optimization/97164] [8/9/10/11 Regression] incorrect offset on structure member where type of that member has aligned attribute

2020-09-23 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164 --- Comment #9 from Jan Smets --- Thanks for the quick resolution everyone. Our codebase apparenty has a handful of these issues.

[Bug tree-optimization/97164] New: incorrect offset on structure member where type of that member has aligned attribute

2020-09-22 Thread jan.smets at nokia dot com
Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jan.smets at nokia dot com Target Milestone: --- Created attachment 49256 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49256=edit testc

[Bug preprocessor/96935] [9 Regression] ICE in subspan, at input.h:69

2020-09-17 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96935 --- Comment #11 from Jan Smets --- Thanks. Fix verified.

[Bug tree-optimization/96993] [10/11 Regression] invalid code

2020-09-10 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96993 --- Comment #5 from Jan Smets --- Hi Andrew I agree that __builtin_offsetof would of good use here. However, I believe this code predates the availability of the builtin (was written around the time we were using gcc3.4)

[Bug rtl-optimization/96993] [10/11 Regression] invalid code

2020-09-09 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96993 --- Comment #3 from Jan Smets --- The testcase has a sign-compare warning that we've traditionally been ignoring given the ancient codebase. warning: operand of ‘?:’ changes signedness from ‘int’ to ‘long unsigned int’ due to unsignedness of

[Bug rtl-optimization/96993] New: invalid code

2020-09-09 Thread jan.smets at nokia dot com
Assignee: unassigned at gcc dot gnu.org Reporter: jan.smets at nokia dot com Target Milestone: --- Created attachment 49203 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49203=edit testcase Following testcase produces invalid code in 10.1, 10.2. Works with 9.3. %rdi is someti

[Bug preprocessor/96940] ICE in linemap_compare_locations, at libcpp/line-map.c:1359

2020-09-04 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96940 --- Comment #2 from Jan Smets --- This is the workaround I currently have. It avoids calling min_location(). diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c index 90111e4c786..f49019e81d0 100644 --- a/gcc/cp/decl.c +++ b/gcc/cp/decl.c @@ -11005,8

[Bug preprocessor/96940] ICE in linemap_compare_locations, at libcpp/line-map.c:1359

2020-09-04 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96940 --- Comment #1 from Jan Smets --- Likely duplicate of Bug 96391 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391) That one has a testcase for i686-w64-mingw32

[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359

2020-09-04 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 Jan Smets changed: What|Removed |Added CC||jan.smets at nokia dot com --- Comment #5

[Bug preprocessor/96940] New: ICE in linemap_compare_locations, at libcpp/line-map.c:1359

2020-09-04 Thread jan.smets at nokia dot com
Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: jan.smets at nokia dot com Target Milestone: --- Target: x86_64-linux-gnu Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu --disable-multilib --enable-languages=c,c

[Bug preprocessor/96935] ICE in subspan, at input.h:69

2020-09-04 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96935 --- Comment #3 from Jan Smets --- A bisect resulted in this commit : commit 0d48e8779c6a9ac88f5efd1b4a2d40f43ef75faf Author: David Malcolm Date: Fri Oct 5 19:02:17 2018 + Support string locations for C++ in -Wformat (PR c++/56856)

[Bug preprocessor/96935] ICE in subspan, at input.h:69

2020-09-04 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96935 --- Comment #1 from Jan Smets --- Proper backtrace (10.2) x.cpp: In function ‘void a()’: x.cpp:3: internal compiler error: in subspan, at input.h:69 3 | #define DB_PRINTF(str, fmt, args...) db_printf(indent_len, 50, fmt, str, ##args)

[Bug preprocessor/96935] New: ICE in subspan, at input.h:69

2020-09-04 Thread jan.smets at nokia dot com
Assignee: unassigned at gcc dot gnu.org Reporter: jan.smets at nokia dot com Target Milestone: --- Following ICE is seen : x.cpp: In function 'void a()': x.cpp:3: internal compiler error: in subspan, at input.h:69 3 | #define DB_PRINTF(str, fmt, args...) db_printf(indent_len

[Bug other/81712] gcc does not compile when using glib 2.26 (everything works fine with 2.25)

2017-11-07 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81712 Jan Smets changed: What|Removed |Added CC||jan.smets at nokia dot com --- Comment #7

[Bug middle-end/82810] New: missed uninitialized variable warning in for/while loop

2017-11-02 Thread jan.smets at nokia dot com
Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jan.smets at nokia dot com Target Milestone: --- In the following code x clearly is used uninitialized #include int main(void) { while (1) { int x; printf

[Bug rtl-optimization/80474] [6 regression] ipa-cp wrongly adding LO(symbol) twice

2017-06-19 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80474 --- Comment #17 from Jan Smets --- Patch confirmed to work on the original code. Thanks.

[Bug rtl-optimization/80474] [6 regression] ipa-cp wrongly adding LO(symbol) twice

2017-06-07 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80474 --- Comment #11 from Jan Smets --- Thanks Eric

[Bug rtl-optimization/80474] ipa-cp wrongly adding LO(symbol) twice

2017-05-22 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80474 --- Comment #7 from Jan Smets --- My apologies, somehow I dropped the -mno-abicalls along the road. $ git status HEAD detached at gcc-6_3_0-release configure --target=mips64-linux-gnuabi64 --enable-languages=c (with binutils/gmp/etc all alread

[Bug rtl-optimization/80474] ipa-cp wrongly adding LO(symbol) twice

2017-05-10 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80474 --- Comment #5 from Jan Smets --- We get 'good' code on 7.1/trunk since 2016-04-29 Patrick Palka tree-ssa-threadedge.c (simplify_control_stmt_condition): Split out into ...

[Bug rtl-optimization/80474] ipa-cp wrongly adding LO(symbol) twice

2017-04-25 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80474 --- Comment #4 from Jan Smets --- For the reduced testcase : $ mips64-linux-gnuabi64-gcc --version mips64-linux-gnuabi64-gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406 mips64-linux-gnuabi64-gcc -O2 -fno-reorder-blocks -march=mips2

[Bug rtl-optimization/80474] ipa-cp wrongly adding LO(symbol) twice

2017-04-22 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80474 --- Comment #2 from Jan Smets --- Created attachment 41245 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41245=edit testcase pr80474 -O2 -fno-reorder-blocks -march=mips2 -fno-inline-small-functions MIPS O32

[Bug rtl-optimization/80474] New: ipa-cp wrongly adding LO(symbol) twice

2017-04-20 Thread jan.smets at nokia dot com
-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jan.smets at nokia dot com Target Milestone: --- On MIPS, O32 GCC 6.3.1 (does not happen on GCC5, but there it's not similarly optimized by ipa-cp) I wasn't yet successful at producing a minimized testcase. A function

[Bug tree-optimization/80032] [6 Regression] C++ excessive stack usage (no stack reuse)

2017-03-21 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80032 --- Comment #12 from Jan Smets --- Thanks. I've also been using the patch on the 6 branch and it seems to work fine as well.

[Bug tree-optimization/80032] [6/7 Regression] C++ excessive stack usage (no stack reuse)

2017-03-17 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80032 --- Comment #9 from Jan Smets --- The alternative patch to gimplify.c seems to run fine. Thanks

[Bug preprocessor/80070] New: -Wmisleading-indentation disabled on -E (or when using distcc)

2017-03-16 Thread jan.smets at nokia dot com
Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: jan.smets at nokia dot com Target Milestone: --- -Wmisleading-indentation is basically disabled when compile jobs are distributed using distcc

[Bug tree-optimization/80032] [6/7 Regression] C++ excessive stack usage (no stack reuse)

2017-03-16 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80032 --- Comment #5 from Jan Smets --- I think suggested patch might generate bad code. (but hard to track down on my embedded target, it's stuck at a point where I don't have exceptions/backtraces available yet).

[Bug c++/80032] New: C++ excessive stack usage (no stack reuse)

2017-03-13 Thread jan.smets at nokia dot com
++ Assignee: unassigned at gcc dot gnu.org Reporter: jan.smets at nokia dot com Target Milestone: --- Created attachment 40959 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40959=edit testcase I have a unlucky code pattern that resulted in 10592 bytes stack usage w

[Bug middle-end/79915] ICE in final_scan_insn, at final.c:2982 (could not split insn) on mips* when compiling libstdc++ with -mlong-calls -mno-abicalls

2017-03-07 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79915 --- Comment #4 from Jan Smets --- Created attachment 40910 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40910=edit testcase pr79951 mips64-linux-gnuabi64-gcc -xc++ pr79951.i -o /dev/null -S -mlong-calls -mno-abicalls

[Bug middle-end/79915] ICE in final_scan_insn, at final.c:2982 (could not split insn) on mips* when compiling libstdc++ with -mlong-calls -mno-abicalls

2017-03-07 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79915 Jan Smets changed: What|Removed |Added Target|mips|mips64-linux-gnuabi64

[Bug middle-end/79915] ICE in final_scan_insn, at final.c:2982 on mips when compiling libstdc++ with -mlong-calls

2017-03-07 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79915 --- Comment #2 from Jan Smets --- Reduced test case, only occurs on the vxworks port, not on linux. namespace a { template class c; class d { public: virtual ~d(); }; template class e : d {}; template class c : virtual

[Bug middle-end/79915] ICE in final_scan_insn, at final.c:2982 on mips with -mlong-calls

2017-03-06 Thread jan.smets at nokia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79915 --- Comment #1 from Jan Smets --- Sorry, copy/pasted incorrect libtool compile, it's the one of libstdc++-v3/src/c++98/strstream.cc Also, occurs at any optimisation level. libtool: compile:

[Bug middle-end/79915] New: ICE in final_scan_insn, at final.c:2982 on mips with -mlong-calls

2017-03-06 Thread jan.smets at nokia dot com
Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jan.smets at nokia dot com Target Milestone: --- During compilation of libstdc++-v3 with -mlong-calls Occurs on mips O32, N32, 64. In both GCC5 and 6. Target I used