[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 --- Comment #4 from Jan Hubicka --- > Rather, because store-motion out of a loop that might iterate zero times would > create a data race. Good point. If we did copy loop headers all the way to the store the problem will go away. Also I assume we can still add a flag which is set to true if loops iterates and then make store conditional...
[Bug libgcc/109852] New: Making of gcc13 stops at libcpp/charset.cc with Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109852 Bug ID: 109852 Summary: Making of gcc13 stops at libcpp/charset.cc with Error Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: ferdasi at opentrash dot com Target Milestone: --- After git pull make configure: configure --prefix=/home//software/gccinstall --disable-multilib Processor Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz uname -a Linux fedora 6.2.13-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Apr 26 20:15:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux the production of gcc stoped after errors: ehome//software/gcc13/host-x86_64-pc-linux-gnu/prev-gcc/xg++ -B/home//software/gcc13/host-x86_64-pc-linux-gnu/prev-gcc/ -B/home//software/gcccinstall/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/home//software/gcc13/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/home//software/gcc13/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home//software/gcc13/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/home//software/gcc13/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/home//software/gcc13/libstdc++-v3/libsupc++ -L/home//software/gcc13/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home//software/gcc13/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I../.././libcpp -I. -I../.././libcpp/../include -I../.././libcpp/include -march=native -O3 -Wall -Wextra -g -O2 -fno-checking -gtoggle -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -fno-exceptions -fno-rtti -I../.././libcpp -I. -I../.././libcpp/../include -I../.././libcpp/include -march=native -O3 -Wall -Wextra-c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo ../.././libcpp/charset.cc In function ‘int one_cppchar_to_utf8(cppchar_t, uchar**, size_t*)’, inlined from ‘const uchar* convert_ucn(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, source_range, cpp_string_location_reader*, cpp_substring_ranges*)’ at ../.././libcpp/charset.cc:1764:30, inlined from ‘const uchar* convert_escape(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, cpp_string_location_reader*, cpp_substring_ranges*)’ at ../.././libcpp/charset.cc:2175:26: ../.././libcpp/charset.cc:255:15: error: writing 16 bytes into a region of size 6 [-Werror=stringop-overflow=] 255 | *outbuf++ = *p++; | ~~^~ ../.././libcpp/charset.cc: In function ‘const uchar* convert_escape(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, cpp_string_location_reader*, cpp_substring_ranges*)’: ../.././libcpp/charset.cc:1747:9: note: at offset [3, 6] into destination object ‘buf’ of size 6 ../.././libcpp/charset.cc:1747:9: note: at offset 35 into destination object ‘buf’ of size 6 In function ‘int one_cppchar_to_utf8(cppchar_t, uchar**, size_t*)’, inlined from ‘const uchar* convert_ucn(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, source_range, cpp_string_location_reader*, cpp_substring_ranges*)’ at ../.././libcpp/charset.cc:1764:30, inlined from ‘const uchar* convert_escape(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, cpp_string_location_reader*, cpp_substring_ranges*)’ at ../.././libcpp/charset.cc:2175:26: ../.././libcpp/charset.cc:255:15: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] 255 | *outbuf++ = *p++; | ~~^~ ../.././libcpp/charset.cc: In function ‘const uchar* convert_escape(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, cpp_string_location_reader*, cpp_substring_ranges*)’: ../.././libcpp/charset.cc:1747:9: note: at offset 36 into destination object ‘buf’ of size 6 1747 | uchar buf[6]; | ^~~ ../.././libcpp/charset.cc:1747:9: note: at offset [4, 6] into destination object ‘buf’ of size 6 ../.././libcpp/charset.cc:1747:9: note: at offset 36 into destination object ‘buf’ of size 6 In function ‘int one_cppchar_to_utf8(cppchar_t, uchar**, size_t*)’, inlined from ‘const uchar* convert_ucn(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, source_range, cpp_string_location_reader*, cpp_substring_ranges*)’ at ../.././libcpp/charset.cc:1764:30, inlined from ‘const uchar* convert_escape(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, cpp_string_location_reader*, cpp_substring_ranges*)’ at ../.././libcpp/charset.cc:2175:26: ../.././libcpp/charset.cc:255:15: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] 255 | *outbuf++ = *p++; | ~~^~ ../.././libcpp/charset.cc: In function ‘const uchar* convert_escape(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, cpp_s
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 --- Comment #5 from Jan Hubicka --- > Actually why didn't we copy the loop header in the first place? Because it is considered to be do-while loop already (thanks to the in-loop conitional, do_while_loop_p is happy).
[Bug c/88088] -Wtrampolines should be enabled by -Wall (or -Wextra)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #26 from Martin Uecker --- I would be nice to have a way to avoid executable code while still being able to use this feature (which is useful!).
[Bug ipa/108250] [12/13/14 regression] llvm-tblgen miscompiled on powerpc-unknown-linux-gnu since r12-5383-g22c242342e38eb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108250
--- Comment #13 from Arsen Arsenović ---
as an update, we've recently gotten valgrind working on a ppc32 machine, and we
get the following:
==2738== Conditional jump or move depends on uninitialised value(s)
==2738==at 0x17E55C: __eq (tuple:1472)
==2738==by 0x17E55C: operator== (tuple:1504)
==2738==by 0x17E55C: operator!= (tuple:1553)
==2738==by 0x17E55C:
llvm::TypeInfer::EnforceSmallerThan(llvm::TypeSetByHwMode&,
llvm::TypeSetByHwMode&, bool)::{lambda(llvm::MVT,
llvm::MVT)#4}::operator()(llvm::MVT, llvm::MVT) const [clone .constprop.0]
(CodeGenDAGPatterns.cpp:556)
==2738==by 0x180E9F: __invoke_impl&, llvm::MVT&,
llvm::MVT&> (invoke.h:61)
==2738==by 0x180E9F:
__invoke&, llvm::MVT&,
llvm::MVT&> (invoke.h:96)
==2738==by 0x180E9F: __call (functional:495)
==2738==by 0x180E9F: operator() (functional:580)
==2738==by 0x180E9F: bool
berase_if, llvm::MVT)> >(llvm::MachineValueTypeSet&,
std::_Bind, llvm::MVT)>) (CodeGenDAGPatterns.cpp:59)
==2738==by 0x199113:
llvm::TypeInfer::EnforceSmallerThan(llvm::TypeSetByHwMode&,
llvm::TypeSetByHwMode&, bool) [clone .part.0] (CodeGenDAGPatterns.cpp:573)
==2738==by 0x1A4013: ApplyTypeConstraint (CodeGenDAGPatterns.cpp:1641)
==2738==by 0x1A4013: ApplyTypeConstraints (CodeGenDAGPatterns.h:1269)
==2738==by 0x1A4013:
llvm::TreePatternNode::ApplyTypeConstraints(llvm::TreePattern&, bool)
(CodeGenDAGPatterns.cpp:2564)
==2738==by 0x1A4DFB:
llvm::TreePattern::InferAllTypes(llvm::StringMap, llvm::MallocAllocator> const*) (CodeGenDAGPatterns.cpp:3094)
==2738==by 0x1AE02F: llvm::CodeGenDAGPatterns::ParsePatternFragments(bool)
(CodeGenDAGPatterns.cpp:3352)
==2738==by 0x1AE893:
llvm::CodeGenDAGPatterns::CodeGenDAGPatterns(llvm::RecordKeeper&,
std::function) (CodeGenDAGPatterns.cpp:3195)
==2738==by 0x2CF00B: GlobalISelEmitter (GlobalISelEmitter.cpp:3809)
==2738==by 0x2CF00B: llvm::EmitGlobalISel(llvm::RecordKeeper&,
llvm::raw_ostream&) (GlobalISelEmitter.cpp:6312)
==2738==by 0x352E1F: (anonymous
namespace)::LLVMTableGenMain(llvm::raw_ostream&, llvm::RecordKeeper&)
(TableGen.cpp:251)
==2738==by 0x3E8447: llvm::TableGenMain(char const*, bool
(*)(llvm::raw_ostream&, llvm::RecordKeeper&)) (Main.cpp:122)
==2738==by 0x134BD7: main (TableGen.cpp:296)
==2738==
==2738== Conditional jump or move depends on uninitialised value(s)
==2738==at 0x17E55C: __eq (tuple:1472)
==2738==by 0x17E55C: operator== (tuple:1504)
==2738==by 0x17E55C: operator!= (tuple:1553)
==2738==by 0x17E55C:
llvm::TypeInfer::EnforceSmallerThan(llvm::TypeSetByHwMode&,
llvm::TypeSetByHwMode&, bool)::{lambda(llvm::MVT,
llvm::MVT)#4}::operator()(llvm::MVT, llvm::MVT) const [clone .constprop.0]
(CodeGenDAGPatterns.cpp:556)
==2738==by 0x1810FF: __invoke_impl&, llvm::MVT&,
llvm::MVT&> (invoke.h:61)
==2738==by 0x1810FF:
__invoke&, llvm::MVT&,
llvm::MVT&> (invoke.h:96)
==2738==by 0x1810FF: __call (functional:495)
==2738==by 0x1810FF: operator() (functional:580)
==2738==by 0x1810FF: bool
berase_if)> >(llvm::MachineValueTypeSet&,
std::_Bind)>) (CodeGenDAGPatterns.cpp:59)
==2738==by 0x19919B:
llvm::TypeInfer::EnforceSmallerThan(llvm::TypeSetByHwMode&,
llvm::TypeSetByHwMode&, bool) [clone .part.0] (CodeGenDAGPatterns.cpp:580)
==2738==by 0x1A4013: ApplyTypeConstraint (CodeGenDAGPatterns.cpp:1641)
==2738==by 0x1A4013: ApplyTypeConstraints (CodeGenDAGPatterns.h:1269)
==2738==by 0x1A4013:
llvm::TreePatternNode::ApplyTypeConstraints(llvm::TreePattern&, bool)
(CodeGenDAGPatterns.cpp:2564)
==2738==by 0x1A4DFB:
llvm::TreePattern::InferAllTypes(llvm::StringMap, llvm::MallocAllocator> const*) (CodeGenDAGPatterns.cpp:3094)
==2738==by 0x1AE02F: llvm::CodeGenDAGPatterns::ParsePatternFragments(bool)
(CodeGenDAGPatterns.cpp:3352)
==2738==by 0x1AE893:
llvm::CodeGenDAGPatterns::CodeGenDAGPatterns(llvm::RecordKeeper&,
std::function) (CodeGenDAGPatterns.cpp:3195)
==2738==by 0x2CF00B: GlobalISelEmitter (GlobalISelEmitter.cpp:3809)
==2738==by 0x2CF00B: llvm::EmitGlobalISel(llvm::RecordKeeper&,
llvm::raw_ostream&) (GlobalISelEmitter.cpp:6312)
==2738==by 0x352E1F: (anonymous
namespace)::LLVMTableGenMain(llvm::raw_ostream&, llvm::RecordKeeper&)
(TableGen.cpp:251)
==2738==by 0x3E8447: llvm::TableGenMain(char const*, bool
(*)(llvm::raw_ostream&, llvm::RecordKeeper&)) (Main.cpp:122)
==2738==by 0x134BD7: main (TableGen.cpp:296)
(and a few similar diagnostics)
these do not happen on x86 and there seems to be no conditional compilation.
I'll try to finish up a reduction soon, but I've been swamped as of late. I
have a reduction that deoptimized most code, leaving us with just a few
functions still being optimized, while still reproducing the bug, so that might
shed some light too.
presuming that some bit of GCC decided to remove a store that'd initialize
those values, any hint on how to see what?
[Bug rust/109853] New: WIN64 is a predefined constant on GCC MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109853
Bug ID: 109853
Summary: WIN64 is a predefined constant on GCC MinGW-w64
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rust
Assignee: unassigned at gcc dot gnu.org
Reporter: mehdi.chinoune at hotmail dot com
CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org
Target Milestone: ---
Building rust on MinGW-w64 fails because rust uses WIN64 as member of ABI enum
in gcc/rust/util/rust-abi.h
```
...
enum ABI
{
UNKNOWN,
RUST,
INTRINSIC,
C,
CDECL,
STDCALL,
FASTCALL,
WIN64,
SYSV64
};
...
```
WIN64 is a defined to 1 on MinGW-w64
```
$ echo | gcc -dM -E - | grep WIN64
#define _WIN64 1
#define __WIN64 1
#define __WIN64__ 1
#define WIN64 1
```
So, Please consider choosing a different name for Windows ABI.
[Bug libstdc++/109818] std::trunc() requires a hack after building DJGPP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818 --- Comment #27 from Janez Zemva --- forcing glibcxx_cv_c99_math_tr1=yes solved this issue for me. The C99 compliance test is really strict, even openlibm fails the test (it fails to define float_t and double_t, but this can be hacked around).
[Bug tree-optimization/109852] Making of gcc13 errors out compiling libcpp/charset.cc with Error with "-march=native -O3 "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109852 Andrew Pinski changed: What|Removed |Added Component|libgcc |tree-optimization Last reconfirmed||2023-05-14 Keywords||build, diagnostic Status|UNCONFIRMED |WAITING Target||x86_64-linux-gnu Summary|Making of gcc13 stops at|Making of gcc13 errors out |libcpp/charset.cc with |compiling libcpp/charset.cc |Error |with Error with ||"-march=native -O3 " Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- You must have CXXFLAGS set to be "-march=native -O3 ". If so you should be using --disable-werror too. Can you attach the preprocessed source for charset.cc ? Also Please provide the output with -v while compiling charset.cc since -march=native will expand to something different depending on what machine you run gcc on.
[Bug lto/109854] New: Error: junk `(%rip)' after expression when using -flto on files compiled with and without -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109854
Bug ID: 109854
Summary: Error: junk `(%rip)' after expression when using -flto
on files compiled with and without -masm=intel
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: bouanto at zoho dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hi.
With those two source files:
a.c:
#include
void a(void) {
puts("A");
}
main.c:
void a(void);
int main(void) {
a();
return 0;
}
and by running the following commands:
gcc -c -flto a.c # Note the absence of -masm=intel
gcc -masm=intel -O3 -flto a.o main.c -o main
I get the following error:
/tmp/cca9LQNs.s: Assembler messages:
/tmp/cca9LQNs.s:17: Error: junk `(%rip)' after expression
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
Compiling the a.c file with -masm=intel solves the issue.
(Doing the opposite, that is compiling a.c with -masm=intel and main.c without
gives a different error: /usr/bin/ld: /tmp/ccMwJTwN.ltrans0.ltrans.o:
relocation R_X86_64_32S against undefined symbol `$8' can not be used when
making a PIE object; recompile with -fPIE
Please tell me if you want me to open a different issue for this case.)
Thanks to fix this issue.
[Bug libstdc++/69388] Allow functexcept.cc definitions to be replaced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69388 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |14.0
[Bug target/109855] New: [14 Regression] ICE: in curr_insn_transform, at lra-constraints.cc:4231 unable to generate reloads for {aarch64_mlav4hi_vec_concatz_le} at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109855
Bug ID: 109855
Summary: [14 Regression] ICE: in curr_insn_transform, at
lra-constraints.cc:4231 unable to generate reloads for
{aarch64_mlav4hi_vec_concatz_le} at -O1
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu
Created attachment 55082
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55082&action=edit
reduced testcase
Compiler output:
$ aarch64-unknown-linux-gnu-gcc -O testcase.c
testcase.c: In function 'foo':
testcase.c:8:1: error: unable to generate reloads for:
8 | }
| ^
(insn 9 8 10 2 (set (reg:V8HI 102)
(vec_concat:V8HI (plus:V4HI (mult:V4HI (reg:V4HI 103)
(reg:V4HI 103))
(reg:V4HI 103))
(const_vector:V4HI [
(const_int 0 [0]) repeated x4
]))) "testcase.c":7:10 2022 {aarch64_mlav4hi_vec_concatz_le}
(expr_list:REG_DEAD (reg:V4HI 103)
(nil)))
during RTL pass: reload
testcase.c:8:1: internal compiler error: in curr_insn_transform, at
lra-constraints.cc:4231
0x8098df _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x7c6f0a curr_insn_transform
/repo/gcc-trunk/gcc/lra-constraints.cc:4231
0x101b67f lra_constraints(bool)
/repo/gcc-trunk/gcc/lra-constraints.cc:5396
0x1002c44 lra(_IO_FILE*)
/repo/gcc-trunk/gcc/lra.cc:2375
0xfb22a9 do_reload
/repo/gcc-trunk/gcc/ira.cc:5967
0xfb22a9 execute
/repo/gcc-trunk/gcc/ira.cc:6153
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-810-20230514170325-g1871740c780-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-810-20230514170325-g1871740c780-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230514 (experimental) (GCC)
[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577 Chinoune changed: What|Removed |Added Resolution|INVALID |WONTFIX
[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577 Thomas Koenig changed: What|Removed |Added Resolution|WONTFIX |INVALID
[Bug tree-optimization/109848] [14 Regression] Recent change causing testsuite ICE on csky port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109848 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||testsuite-fail
[Bug target/109855] [14 Regression] ICE: in curr_insn_transform, at lra-constraints.cc:4231 unable to generate reloads for {aarch64_mlav4hi_vec_concatz_le} at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109855 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Host|x86_64-pc-linux-gnu |
[Bug target/109855] [14 Regression] ICE: in curr_insn_transform, at lra-constraints.cc:4231 unable to generate reloads for {aarch64_mlav4hi_vec_concatz_le} at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109855 --- Comment #1 from Andrew Pinski --- Most likely caused by r14-473-g93c26deab98fc8 .
[Bug middle-end/109856] New: -Wnull-dereference false positive in Emacs itree.c (regression from GCC 12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109856 Bug ID: 109856 Summary: -Wnull-dereference false positive in Emacs itree.c (regression from GCC 12) Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: eggert at cs dot ucla.edu Target Milestone: --- Created attachment 55083 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55083&action=edit compile with 'gcc -O2 -Wnull-dereference' to reproduce the bug This is GCC 13.1.1 20230426 (Red Hat 13.1.1-1) on x86-64, and this is a regression from GCC (Ubuntu 12.2.0-17ubuntu1) 12.2.0. I ran into this problem when compiling GNU Emacs src/itree.c. This is a stripped-down version of the original problem (the code makes no sense by itself). Compile the attached program with: gcc -O2 -S -Wnull-dereference v2.i The output is: v2.i: In function ‘itree_remove_fix’: v2.i:28:16: warning: potential null pointer dereference [-Wnull-dereference] 28 | if (other->left) | ~^~ First, the diagnostic is confusing, because it highlights an entire expression, which cannot itself be a null pointer dereference. Second, there's no possible null pointer dereference here. The previous two lines are "if (!other)__builtin_unreachable ();" so OTHER itself cannot be null.
[Bug middle-end/109840] [14 Regression] internal compiler error: in expand_fn_using_insn, at internal-fn.cc:153 when building graphite2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109840 Roger Sayle changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com --- Comment #4 from Roger Sayle --- Doh! The recent popcount(bswap(x)) optimizations shouldn't be changing the width of the popcount, i.e. the convert? extension needs to be re-inserted, it's only the bswap that gets eliminated. I'll investigate a fix.
[Bug tree-optimization/109852] Making of gcc13 errors out compiling libcpp/charset.cc with Wstringop-overflow Error with "-march=native -O3 "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109852 --- Comment #2 from Andrew Pinski --- I cannot reproduce this with "../configure --with-build-config=bootstrap-O3" .
[Bug fortran/109846] Pointer-valued function reference rejected as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Keywords||rejects-valid
CC||anlauf at gcc dot gnu.org
Last reconfirmed||2023-05-14
Summary|[rejects valid] |Pointer-valued function
|Pointer-valued function |reference rejected as
|reference rejected as |actual argument
|actual argument |
--- Comment #3 from anlauf at gcc dot gnu.org ---
Tentative patch to fix the CLASS pointer case:
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index d91722e6ac6..1955c8471a4 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -6256,7 +6265,7 @@ gfc_check_vardef_context (gfc_expr* e, bool pointer, bool
alloc_obj,
&& !(sym->attr.flavor == FL_PROCEDURE && sym == sym->result)
&& !(sym->attr.flavor == FL_PROCEDURE && sym->attr.proc_pointer)
&& !(sym->attr.flavor == FL_PROCEDURE
- && sym->attr.function && sym->attr.pointer))
+ && sym->attr.function && attr.pointer))
{
if (context)
gfc_error ("%qs in variable definition context (%s) at %L is not"
Regtesting now.
Another workaround is to not specify an INTENT for dummy argument plist, i.e.
type(parameter_list) :: plist
[Bug fortran/109846] Pointer-valued function reference rejected as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- Looks like an extension of pr100218. Regtested ok. Taking.
[Bug target/105719] RFE: fixincludes should handle Frameworks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105719 --- Comment #4 from Iain Sandoe --- Created attachment 55084 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55084&action=edit Implement the use of fixed framework headers this was a proof-of-principle exercise while looking into issues caused by implementing __has_feature () [PR60512]. This does not have any of the mechanism to *create* or *install* the fixed headers (for my testing I just built a CoreFoundation.framework/Headers/CFBase.h and edited bye hand to fix the problems found). So, still plenty to do ;)
[Bug target/109807] [14 Regression] sse2-mmx-pmaddwd.c met ICE after commit r14-666-g608e7f3ab47 with march=cascadelake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807 --- Comment #12 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:aed51e2051b24a6a2127c6626f451641557a571a commit r14-812-gaed51e2051b24a6a2127c6626f451641557a571a Author: Uros Bizjak Date: Sun May 14 21:53:17 2023 +0200 i386: Handle unsupported modes from ix86_widen_mult_cost [PR109807] Revert my previous change that faked handling of V4HI and V2SImodes in ix86_widen_mult_cost and rather return arbitrary high value for unsupported modes. This should prevent cost estimator from selecting non-existent vector widen multiply operation. gcc/ChangeLog: PR target/109807 * config/i386/i386.cc: Revert the 2023-05-11 change. (ix86_widen_mult_cost): Return high value instead of ICEing for unsupported modes. gcc/testsuite/ChangeLog: PR target/109807 * gcc.target/i386/pr109825.c: New test.
[Bug target/109807] [14 Regression] sse2-mmx-pmaddwd.c met ICE after commit r14-666-g608e7f3ab47 with march=cascadelake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807 Uroš Bizjak changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #13 from Uroš Bizjak --- Fixed.
[Bug libstdc++/109818] std::trunc() requires a hack after building DJGPP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818 --- Comment #28 from Jonathan Wakely --- (In reply to Janez Zemva from comment #26) > I am a c++ user, so I don't like using c header files if at all possible. is a C++ header file, if you doubt that, you can check the path where it's included from. You'll see that libstdc++ installs its own in the same location as . If you prefer, include , you'll get the same contents. What I'm saying is to use ::trunc not std::trunc, because that is present whether or not libstdc++ adds the math functions to namespace std.
[Bug middle-end/109838] [14 Regression] ICE on libaom-3.6.0: in ix86_widen_mult_cost, at config/i386/i386.cc:20444
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109838 --- Comment #2 from Uroš Bizjak --- *** This bug has been marked as a duplicate of bug 109807 ***
[Bug target/109807] [14 Regression] sse2-mmx-pmaddwd.c met ICE after commit r14-666-g608e7f3ab47 with march=cascadelake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807 Uroš Bizjak changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #14 from Uroš Bizjak --- *** Bug 109838 has been marked as a duplicate of this bug. ***
[Bug target/109825] [14 Regression] ICE in ix86_widen_mult_cost, at config/i386/i386.cc:20442 since r14-666-g608e7f3ab47fe7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109825 Uroš Bizjak changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #8 from Uroš Bizjak --- Dup. *** This bug has been marked as a duplicate of bug 109807 ***
[Bug target/109807] [14 Regression] sse2-mmx-pmaddwd.c met ICE after commit r14-666-g608e7f3ab47 with march=cascadelake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807 Uroš Bizjak changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #15 from Uroš Bizjak --- *** Bug 109825 has been marked as a duplicate of this bug. ***
[Bug libstdc++/109818] std::trunc() requires a hack after building DJGPP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818 --- Comment #29 from Jonathan Wakely --- (In reply to Janez Zemva from comment #27) > forcing glibcxx_cv_c99_math_tr1=yes solved this issue for me. The C99 > compliance test is really strict, even openlibm fails the test (it fails to > define float_t and double_t, but this can be hacked around). It's precisely as strict as it needs to be: it checks that every name that will be subject to a using-declaration is present. Because otherwise compiling will give errors. But supporting openlibm would be nice, so I'll separate the checks for those typedefs.
[Bug fortran/109846] Pointer-valued function reference rejected as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846 --- Comment #5 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-May/059297.html
[Bug middle-end/85614] Documentation: -fdump-tree should mention "original"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85614 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-05-14 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #4 from Andrew Pinski --- Confirmed.
[Bug libstdc++/109857] New: tzdata 2021a has bad data that cannot be parsed by libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109857
Bug ID: 109857
Summary: tzdata 2021a has bad data that cannot be parsed by
libstdc++
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
On debian stable the tzdata.zi file is from version 2021a of the IANA time zone
database and contains this line:
R K 2023 Max - O lastTh 24 0 -
This is invalid, because the fourth field should be "max" not "Max". This
causes libstdc++ to fail to parse the tzdata file and use a UTC-only fallback.
Maybe we should do:
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -345,8 +345,9 @@ namespace std::chrono
friend istream& operator>>(istream& in, minmax_year&& y)
{
- if (ws(in).peek() == 'm') // keywords "minimum" or "maximum"
+ if (unsigned char c = ws(in).peek(); std::tolower(c) == 'm')
{
+ // keywords "minimum" or "maximum"
string s;
in >> s; // extract the rest of the word, but only look at s[1]
if (s[1] == 'a')
We should also consider ignoring the system tzdata files if the bundled copy
(currently 2023c) is newer. Or at least try using the bundled one if the
parsing the system file fails, as in this case.
[Bug libstdc++/109857] tzdata 2021a has bad data that cannot be parsed by libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109857 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2023-05-14 Target Milestone|--- |13.2 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- This is the cause of the libstdc++ failures at https://builder.sourceware.org/buildbot/#/builders/215/builds/3026
[Bug tree-optimization/94675] [10/11/12/13/14 regression] -Warray-bounds false positive with -O2 since r9-1948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2020-04-21 00:00:00 |2023-5-14 --- Comment #25 from Andrew Pinski --- Hmm, At VRP, we have: _6 = &c + _2; We know after that statement, _2 should have a range of [0,1] because we know the size of _6 is 1 byte. If we use that information afterwards, VRP should be able to optimize the rest.
[Bug ipa/97551] [11 Regression] ICE: verify_cgraph_node failed with "-O2 -fno-toplevel-reorder -fno-tree-dce -fno-tree-forwprop -fno-tree-fre -fipa-cp-clone"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97551 Andrew Pinski changed: What|Removed |Added Summary|ICE: verify_cgraph_node |[11 Regression] ICE: |failed with "-O2|verify_cgraph_node failed |-fno-toplevel-reorder |with "-O2 |-fno-tree-dce |-fno-toplevel-reorder |-fno-tree-forwprop |-fno-tree-dce |-fno-tree-fre |-fno-tree-forwprop |-fipa-cp-clone" |-fno-tree-fre ||-fipa-cp-clone" Resolution|--- |FIXED Status|NEW |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97576 Target Milestone|--- |11.0 --- Comment #3 from Andrew Pinski --- Been fixed for a few years now even in GCC 11. So closing as such. I suspect it was fixed by the same patch as PR 97576.
[Bug rtl-optimization/105686] [10/11/12/13/14 Regression] ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 8 with -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105686 Andrew Pinski changed: What|Removed |Added Known to fail|13.0| Keywords||needs-bisection --- Comment #5 from Andrew Pinski --- This seems like it has gone latent again in GCC 13. I noticed something in the pro_and_epilogue pass that merges the basic blocks at that point even.
[Bug rtl-optimization/105686] [10/11/12/13/14 Regression] ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 8 with -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105686 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE Keywords|needs-bisection | --- Comment #6 from Andrew Pinski --- Nope it was fully fixed, via PR 90259. See bug 90259 comment #7 which makes this an exact duplicate of that bug so closing as such. *** This bug has been marked as a duplicate of bug 90259 ***
[Bug rtl-optimization/90259] ICE: verify_flow_info failed (error: missing REG_EH_REGION note at the end of bb 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90259 Andrew Pinski changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #10 from Andrew Pinski --- *** Bug 105686 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/109829] Optimizing __builtin_signbit(x) ? -x : x or abs for FP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829 --- Comment #10 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:82502b5c3463bde98d4b7ffb9ecef9b123799ed1 commit r14-813-g82502b5c3463bde98d4b7ffb9ecef9b123799ed1 Author: Andrew Pinski Date: Sat May 13 22:25:21 2023 + MATCH: Add pattern for `signbit(x) ? x : -x` into abs (and swapped) This adds a simple pattern to match.pd for `signbit(x) ? x : -x` into abs. This can be done for all types even ones that honor signed zeros and NaNs because both signbit and - are considered only looking at/touching the sign bit of those types and does not trap either. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/109829 gcc/ChangeLog: * match.pd: Add pattern for `signbit(x) !=/== 0 ? x : -x`. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/abs-3.c: New test. * gcc.dg/tree-ssa/abs-4.c: New test.
[Bug tree-optimization/109829] Optimizing __builtin_signbit(x) ? -x : x or abs for FP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED --- Comment #11 from Andrew Pinski --- Fixed.
[Bug tree-optimization/64450] Optimize 0>=p-q to q>=p for char*p,*q;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64450 --- Comment #3 from Andrew Pinski --- (for cmp (tcc_comparison) (simplify (cmp (pointer_diff @0 @1) integer_zero_p) (cmp @0 @1))) Maybe But we might also need handle the match patterns for too: A CMP B ? A - B : -(A - B) A CMP B ? A - B : B - A (which is also on my todo list anyways).
[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68855 --- Comment #2 from Andrew Pinski --- Maybe: (simplify (paren (complex_expr @0 @1)) (complex_expr (paren @0) (paren @1)) (simplify (paren (real_expr @0)) (real_expr (paren @0)) (simplify (paren (imag_expr @0)) (real_expr (paren @0)) Is enough.
[Bug tree-optimization/89332] Missed detection of dead stores to array in a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89332 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2019-02-18 00:00:00 |2023-5-14 Severity|normal |enhancement
[Bug target/40730] redundant memory load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40730 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=33315 Known to fail||10.1.0, 11.1.0, 5.1.0 Known to work||12.1.0, 13.1.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #14 from Andrew Pinski --- Fixed for GCC 12 by r12-897-gde56f95afaaa22 (and r11-408-g84935c9822183c).
[Bug target/40730] redundant memory load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40730 --- Comment #15 from Andrew Pinski --- (In reply to Andrew Pinski from comment #14) > Fixed for GCC 12 by r12-897-gde56f95afaaa22 (and r11-408-g84935c9822183c). The first redundant load was fixed by r11-408-g84935c9822183c. The extra store was fixed was fixed by r12-897-gde56f95afaaa22 . But it is still fixed fully.
[Bug tree-optimization/64700] Sink common code through PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64700 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=33315 --- Comment #7 from Andrew Pinski --- I should note store sinking is handled by the sinking pass by r11-408-g84935c9822183c .
[Bug rtl-optimization/109858] New: r14-172 caused some SPEC2017 bmk to degrade on Power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858 Bug ID: 109858 Summary: r14-172 caused some SPEC2017 bmk to degrade on Power Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: linkw at gcc dot gnu.org Target Milestone: --- On Power9, - at option -Ofast, 557.xz_r degraded -1.06%. - at option -Ofast, 511.povray_r degraded -1.24%. On Power10, - at option -O2, 520.omnetpp_r degraded -1.84%. I tried to run them in a few times, the gaps are stable. I've excluded those one in +-1% as noises. The full data is listed below: P9 O2: 500.perlbench_r 0.00% 502.gcc_r -0.20% 505.mcf_r 0.00% 520.omnetpp_r -0.30% 523.xalancbmk_r 0.00% 525.x264_r 0.00% 531.deepsjeng_r 0.00% 541.leela_r 0.00% 548.exchange2_r 0.00% 557.xz_r0.00% 503.bwaves_r0.00% 507.cactuBSSN_r 0.00% 508.namd_r -0.32% 510.parest_r0.00% 511.povray_r0.32% 519.lbm_r -0.16% 521.wrf_r 0.00% 526.blender_r 0.27% 527.cam4_r 0.00% 538.imagick_r 0.00% 544.nab_r 0.00% 549.fotonik3d_r 0.00% 554.roms_r 0.00% P9 Ofast: 500.perlbench_r 0.00% 502.gcc_r 0.00% 505.mcf_r 0.00% 520.omnetpp_r 0.00% 523.xalancbmk_r 0.00% 525.x264_r 0.17% 531.deepsjeng_r 0.00% 541.leela_r 0.00% 548.exchange2_r 2.15% 557.xz_r-1.06% 503.bwaves_r2.21% 507.cactuBSSN_r -0.20% 508.namd_r -0.33% 510.parest_r0.00% 511.povray_r-1.24% 519.lbm_r 0.00% 521.wrf_r 0.19% 526.blender_r 0.00% 527.cam4_r 0.28% 538.imagick_r 0.32% 544.nab_r 0.00% 549.fotonik3d_r -0.83% 554.roms_r 1.33% Power10 O2: 500.perlbench_r 0.00% 502.gcc_r 0.33% 505.mcf_r 0.55% 520.omnetpp_r -1.84% 523.xalancbmk_r 0.00% 525.x264_r 0.36% 531.deepsjeng_r 0.00% 541.leela_r 0.00% 548.exchange2_r 0.00% 557.xz_r0.31% 503.bwaves_r0.00% 507.cactuBSSN_r -0.31% 508.namd_r -0.22% 510.parest_r-0.64% 511.povray_r-0.86% 519.lbm_r -0.75% 521.wrf_r 0.20% 526.blender_r 0.20% 527.cam4_r 0.00% 538.imagick_r -0.15% 544.nab_r -0.18% 549.fotonik3d_r 0.00% 554.roms_r 0.00% Power10 Ofast: 502.gcc_r 0.16% 505.mcf_r 0.00% 520.omnetpp_r 0.00% 523.xalancbmk_r 0.22% 525.x264_r 0.30% 531.deepsjeng_r 0.00% 541.leela_r 0.00% 548.exchange2_r 0.00% 557.xz_r0.31% 503.bwaves_r-0.18% 507.cactuBSSN_r 0.00% 508.namd_r 0.22% 510.parest_r-0.52% 511.povray_r0.00% 519.lbm_r 0.50% 521.wrf_r 0.00% 526.blender_r -0.80% 527.cam4_r 0.18% 538.imagick_r -0.11% 544.nab_r 0.17% 549.fotonik3d_r 0.63% 554.roms_r -0.63%
[Bug rtl-optimization/109858] r14-172 caused some SPEC2017 bmk to degrade on Power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |14.0 CC||pinskia at gcc dot gnu.org
[Bug rtl-optimization/109858] r14-172 caused some SPEC2017 bmk to degrade on Power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=109610 --- Comment #1 from Andrew Pinski --- Maybe once PR 109610 is fixed this also is fixed.
[Bug tree-optimization/51781] Missed optimization for ==/!= comparison type-sinking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51781 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- No longer working on this one.
[Bug target/33716] gcc generates suboptimal code for long long shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33716 --- Comment #1 from Andrew Pinski --- 32bit x86 is not as important any more. With -msse2 these days, GCC produces: movq4(%esp), %xmm0 psrlq $4, %xmm0 movd%xmm0, %eax psrlq $32, %xmm0 movd%xmm0, %edx Which is faster anyways.
[Bug tree-optimization/39052] writing arrays twice not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39052
--- Comment #3 from Andrew Pinski ---
even for:
void foo(char *a, int n)
{
int i;
for (i=0; i
[Bug target/36539] Poor register allocation from IRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36539 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.8.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Andrew Pinski --- GCC 4.8+ for -m32 -O2 -fno-pic -fomit-frame-pointer: get_cabac: pushl %ebp pushl %edi pushl %esi pushl %ebx movl20(%esp), %esi movl24(%esp), %ebp movl4(%esi), %ebx movl(%esi), %eax #APP # 16 "/app/example.cpp" 1 #%edi %ebx %ax 16(%esi) %ebp # 0 "" 2 #NO_APP movl%eax, (%esi) movl%edi, %eax movl%ebx, 4(%esi) andl$1, %eax popl%ebx popl%esi popl%edi popl%ebp ret Which most likely means it was fixed when LRA came in, aka r0-119686-g55a2c3226a3e90 so closing as fixed for GCC 4.8.
[Bug target/45252] unnecessary register move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45252
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #1 from Andrew Pinski ---
GCC 8+ does:
ts:
push{r0, r1, r2, r3, r4, lr}
mov r0, sp
movsr3, #0
str r3, [sp]
bl foo
add sp, sp, #20
ldr pc, [sp], #4
Which is exactly what you want.
[Bug target/45980] Use not in stead of add to generate new constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45980 --- Comment #2 from Andrew Pinski --- For the original testcase on the trunk we get: ldr r3, .L2 str r3, [r0] add r3, r3, #-2004318072 str r3, [r0, #4] add r3, r3, #-1459617792 sub r3, r3, #1228800 subwr3, r3, #3723 str r3, [r0, #8] sub r3, r3, #-2004318072 str r3, [r0, #12] ldr r3, .L2+4 str r3, [r0, #16] movsr3, #0 strdr3, r3, [r0, #20] bx lr .L3: .align 2 .L2: .word 1732584193 .word -1009589776
[Bug target/46127] Use 16bit add instead of 32bit in thumb2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46127 Andrew Pinski changed: What|Removed |Added Severity|minor |enhancement Last reconfirmed|2010-10-27 16:18:15 |2023-5-14
[Bug target/46975] Replace 32 bit instructions with 16 bit instructions in thumb2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46975 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |4.7.0 Resolution|--- |FIXED --- Comment #1 from Andrew Pinski --- The fix was committed as r0-109399-g527e82c2679a4b but since the commit log didn't have the bug # in it, it didn't reach here. The bug # is in the changelog though.
[Bug rtl-optimization/15792] missed subreg optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15792
Andrew Pinski changed:
What|Removed |Added
Known to fail||
--- Comment #12 from Andrew Pinski ---
(In reply to Gabriel Ravier from comment #11)
> Seems like the issue is present again, except it's test1 that gets the
> better asm now. Perhaps this should be re-opened ?
This bug was about 32bit x86 and the code looks good in GCC 9, 10, 11, and 12
and the trunk.
If you were testing on x86_64, you need to use __int128_t to see what the
original issue was about:
void gh();
void test(__int128_t x) {
long g = (long)x|((long)(x>>64));
if (g) gh();
}
void test1(__int128_t x) {
if (x) gh();
}
GCC 4.8+ produces:
test1:
.cfi_startproc
orq %rdi, %rsi
jne .L7
rep ret
For both. There was an extra mov in GCC 4.5.0-4.7.0 for test though. In GCC
4.4.0, test1 was two compare and jumps (ok). GCC 4.1.2 had the bad code
generation which was mentioned in comment #0.
[Bug libgcc/109712] Segmentation fault in linear_search_fdes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 --- Comment #7 from Richard Biener --- (In reply to Carlos Galvez from comment #6) > Hi again! > > I realized there is still one more problem missing, so I suspect the linker > was not the only culprit. It does not segfault, but it gets stuck in an > infinite loop, once again when mixing exceptions and libcudart_static.a. > > @Richard you mentioned: > > > Does libcudart_static.a by chance contain any symbols from the libgcc > > runtime (of an old toolchain)? > > Do you know how I could verify this? I'm pretty new when it comes to > troubleshooting these things. > > My understanding is that libstdc++.so and libgcc_s.so are always backwards > compatible so using "the latest" ensures you can use the newest features and > also run older built code. Is there a flaw/pitfall in that reasoning? There were changes to the internal data structures of the unwinder so I wondered if you somehow managed to mix unwinder parts of different versions. You probably have a libgcc_eh.a file as part of your GCC install, you could look for symbols this library provides in the NVIDIA static archives. > Thanks!
[Bug tree-optimization/46284] Lack of proper optimization for certain SSE operations, and weird behavior with similar source codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46284 Andrew Pinski changed: What|Removed |Added Known to work||10.1.0, 11.3.0, 12.1.0, ||13.1.0 Target Milestone|--- |10.0 Status|UNCONFIRMED |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=28367, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=83518 Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fully fixed in GCC 10 (by r10-1692-g38988cbf9ebaa9): main: subq$8, %rsp movl$.LC1, %edi movl$4, %eax movsd .LC0(%rip), %xmm0 movapd %xmm0, %xmm3 movapd %xmm0, %xmm2 movapd %xmm0, %xmm1 callprintf Just loading the constants to call printf. In GCC 7-9 (improved most likely by PR 28367), GCC produces: movl$.LC0, %edi movl$4, %eax movdqa .LC2(%rip), %xmm1 movdqa .LC1(%rip), %xmm0 addps %xmm1, %xmm0 movaps %xmm0, %xmm3 movaps %xmm0, %xmm2 movaps %xmm0, %xmm1 shufps $255, %xmm0, %xmm3 unpckhps%xmm0, %xmm2 shufps $85, %xmm0, %xmm1 cvtss2sd%xmm0, %xmm0 cvtss2sd%xmm3, %xmm3 cvtss2sd%xmm2, %xmm2 cvtss2sd%xmm1, %xmm1 callprintf Which is not bad and much better than before in GCC 6 (comment #0's code is listed there).
[Bug tree-optimization/109852] Making of gcc13 errors out compiling libcpp/charset.cc with Wstringop-overflow Error with "-march=native -O3 "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109852 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #3 from Xi Ruoyao --- AFAIK building any package (not only GCC) with `--enable-werror` and some random CFLAGS is not supported.
[Bug tree-optimization/109848] [14 Regression] Recent change causing testsuite ICE on csky port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109848 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-05-15 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Richard Biener --- I will have a look.
[Bug tree-optimization/14753] [tree-ssa] some missed forward propagation opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14753 --- Comment #12 from Andrew Pinski --- Summary of the ones still need to be done: comment #0: * foo comment #3: * rshift_gt * rshift_eq * mask_gt * neg_eq_cst * neg_eq_var comment #4: * minus_cst
[Bug debug/109805] LTO affecting -fdebug-prefix-map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #10 from Richard Biener ---
(In reply to Sergio Durigan Junior from comment #9)
> at(In reply to Richard Biener from comment #8)
> > This works for me. The consistency check is not fully implemented and
> > instead
> > of passing down no -fdebug-prefix-map the patch passes the first but warns:
> >
> > > ./xgcc -B. t.o t2.o -o t
> > lto-wrapper: warning: option
> > -fdebug-prefix-map=/home/rguenther/obj-trunk-g/gcc=/bbb with different
> > values, using /home/rguenther/obj-trunk-g/gcc=/aaa
> >
> > to make consistency checking work we need to record -fcanon-prefix-map
> > and the full set of -f{file,debug}-prefix-map options in order (I think
> > file and debug variants can be considered the same) of the first TU and
> > compare that to each of the following TUs.
>
> Thanks a lot for the patch. I tried it locally, and it indeed works for the
> simple example I posted in the description of this bug. However, for some
> reason it doesn't seem to make a difference for the vim compilation. I'm
> still seeing a directory table like the following:
>
> Directory table:
> [path(line_strp)]
> 0 /home/ubuntu/vim/vim-9.0.1378/src/vim-basic (0)
> 1 /usr/include/x86_64-linux-gnu/bits (57)
> 2 /usr/include (92)
>
> whereas if I pass -fdebug-prefix-map to LDFLAGS, the directory table becomes:
>
> Directory table:
> [path(line_strp)]
> 0 /usr/src/vim-2:9.0.1378-2ubuntu2~ppa1/src/vim-basic (0)
> 1 /usr/include/x86_64-linux-gnu/bits (65)
> 2 /usr/include (100)
>
> which is what I expected to see.
Odd.
> > Note a link-time specified option will simply ignore all options from the
> > compile-time (but only for the link-time unit, the compile-time debug info
> > has already been generated with the originally specified options).
>
> FWIW, I think this bug is related to #108534 (and the related discussion at
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606205.html).
Yes, that looks related. Note we do remap the file part of locations
but indeed not the streamed PWD.
When I remap PWD as well I get
The Directory Table (offset 0x10a, lines 2, columns 1):
Entry Name
0 (indirect line string, offset: 0x18): /aaa
1 (indirect line string, offset: 0xd): ../../../../aaa
The File Name Table (offset 0x118, lines 2, columns 2):
Entry Dir Name
0 0 (indirect line string, offset: 0x0):
1 1 (indirect line string, offset: 0x1d): t.c
for the toy example. That's quite odd, but possibly the behavior of the
original intent of the patch you quoted - but it also shows that the
remapping of the streamed PWD is likely wrong?
For the record the above is with just
diff --git a/gcc/lto-streamer-out.cc b/gcc/lto-streamer-out.cc
index 0bca530313c..89b602f080b 100644
--- a/gcc/lto-streamer-out.cc
+++ b/gcc/lto-streamer-out.cc
@@ -231,7 +231,8 @@ lto_output_location_1 (struct output_block *ob, struct
bitpack_d *bp,
}
bp_pack_value (bp, stream_pwd, 1);
if (stream_pwd)
- bp_pack_string (ob, bp, get_src_pwd (), true);
+ bp_pack_string (ob, bp, remap_debug_filename (get_src_pwd ()),
+ true);
bp_pack_string (ob, bp, remapped, true);
bp_pack_value (bp, xloc.sysp, 1);
}
r10-6887-gd12153046816f9 did the original bits of remapping and shows we
originally passed through the remapping options. r11-3096-g3d0af0c997fe42
was Jakubs fix for .debug_line and relative paths vs. changing CWD.
[Bug middle-end/68855] PAREN_EXPR not "ignored" where possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68855 --- Comment #3 from Richard Biener --- (In reply to Andrew Pinski from comment #2) > Maybe: > (simplify > (paren (complex_expr @0 @1)) > (complex_expr (paren @0) (paren @1)) That makes the tree larger though ... But yes, if we have (complex (real (complex@0)) (imag (complex@0)) and the inner complex are wrapped that would help. > (simplify > (paren (real_expr @0)) > (real_expr (paren @0)) > (simplify > (paren (imag_expr @0)) > (real_expr (paren @0)) > > Is enough. Maybe it's a task for backprop instead? It at least "feels" similar ...
[Bug c/109828] [13/14 Regression] static compound literal with flexible array in initializer leads to invalid size and ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.2
[Bug middle-end/109845] Addition overflow/carry flag unnecessarily put in a temporary register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109845 --- Comment #3 from Richard Biener --- Yup, bad luck for later RTL optimization. It might help to perform jump expansions decision to go for jump or straight-line code earlier on GIMPLE (and stick to that).
[Bug target/48701] [missed optimization] GCC fails to use aliasing of ymm and xmm registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48701
--- Comment #4 from Andrew Pinski ---
Better testcase without inline-asm (because sometimes inline-asm gets in the
way of other optimizations):
```
#include
__m256i blackhole;
void testStore(__m128i xmm0, __m128i xmm1)
{
__m256i ymm;
__m128i *xmm = (__m128i *)&ymm;
xmm[0] = xmm0;
xmm[1] = xmm1;
blackhole = ymm;
}
void f(__m128i, __m128i);
void testLoad()
{
__m256i ymm = blackhole;
__m128i *xmm = (__m128i *)&ymm;
f(xmm[0], xmm[1]);
}
```
testStore still needs some help:
ymm_6 = BIT_INSERT_EXPR ;
ymm_7 = BIT_INSERT_EXPR ;
blackhole = ymm_7;
Which gives:
```
...
vpxor %xmm2, %xmm2, %xmm2
movq%rsp, %rbp
.cfi_def_cfa_register 6
andq$-32, %rsp
vmovdqa %ymm2, -32(%rsp)
vmovdqa %xmm0, -32(%rsp)
vmovdqa %xmm1, -16(%rsp)
vmovdqa -32(%rsp), %ymm4
vmovdqa %ymm4, blackhole(%rip)
...
```
while testLoad is fine/correct:
testLoad:
vmovdqa blackhole+16(%rip), %xmm1
vmovdqa blackhole(%rip), %xmm0
jmp f
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-05-15 Keywords||missed-optimization Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug rust/109853] WIN64 is a predefined constant by GCC on MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109853 Richard Biener changed: What|Removed |Added Target||mingw-w64 --- Comment #1 from Richard Biener --- Eh. It's of course equally bad to have a predefined macro in the non-implementation namespace (but possibly it's required for MSVC compatibility).
