[Bug target/113133] [14 Regression] ICE: SIGSEGV in mark_label_nuses(rtx_def*) (emit-rtl.cc:3896) with -O -fno-tree-ter -mavx512f -march=barcelona
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133 --- Comment #11 from Haochen Jiang --- I just checked the code and pattern. I suppose the simple remove is reasonable here. We should only allow x/ymm16+ for scalar instructions, but not this pattern.
[Bug middle-end/113194] Hangup build ExtractAPIConsumer.cpp at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113194 --- Comment #3 from Andrew Pinski --- There seems to be some high memory usage in the front-end though: template instantiation : 12.13 ( 29%) 4.33 ( 35%) 16.72 ( 31%) 759M ( 44%) But other than that it works for me on x86_64.
[Bug middle-end/113194] Hangup build ExtractAPIConsumer.cpp at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113194 --- Comment #2 from Andrew Pinski --- Works for me with r14-6875-g3a7dd24eadeb91 on x86_64: ./cc1plus tmp/ExtractAPIConsumer.cpp.ii -quiet -Og -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -fno-lifetime-dse -ffunction-sections -fdata-sections -fno-common -fno-strict-aliasing -fno-exceptions -funwind-tables -fno-rtti -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -Wpedantic -Wno-long-long -Wimplicit-fallthrough=3 -Wno-maybe-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -Woverloaded-virtual=2 -std=c++17
[Bug c++/113194] Hangup build ExtractAPIConsumer.cpp at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113194 --- Comment #1 from Paul Hua --- Created attachment 56972 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56972=edit preprocessed file
[Bug ada/113195] New: gnat bug box when comparing access to subtype with access inside record
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113195 Bug ID: 113195 Summary: gnat bug box when comparing access to subtype with access inside record Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: nicolas at debian dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Hello. If the 'p.ads' file contains this: -- package P is subtype I is Integer; A : access I := null; type Rec is record Acc : access Integer; end record; R : Rec := (Acc => null); B : Boolean := A = R.Acc; end P; -- Then 'gnatmake p' triggers this bug box. x86_64-linux-gnu-gcc-13 -c p.ads +===GNAT BUG DETECTED==+ | 13.2.0 (x86_64-linux-gnu) GCC error: | | in build_binary_op, at ada/gcc-interface/utils2.cc:1142 | | Error detected at p.ads:10:23| | Compiling p.ads | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ I have found no shorter reproducer.
[Bug c++/113194] New: Hangup build ExtractAPIConsumer.cpp at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113194 Bug ID: 113194 Summary: Hangup build ExtractAPIConsumer.cpp at -Og Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: paul.hua.gm at gmail dot com Target Milestone: --- build cmd on LoongArch: cc1plus -fpreprocessed tools/clang/lib/ExtractAPI/CMakeFiles/obj.clangExtractAPI.dir/ExtractAPIConsumer.cpp.ii -quiet -dumpdir tools/clang/lib/ExtractAPI/CMakeFiles/obj.clangExtractAPI.dir/ -dumpbase ExtractAPIConsumer.cpp.cpp -dumpbase-ext .cpp -mabi=lp64d -march=loongarch64 -mfpu=64 -mcmodel=normal -mtune=la464 -g -Og -Og -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -Wpedantic -Wno-long-long -Wimplicit-fallthrough=3 -Wno-maybe-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -Woverloaded-virtual=2 -std=c++17 -version -fdiagnostics-color=always -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -fno-lifetime-dse -ffunction-sections -fdata-sections -fno-common -fno-strict-aliasing -fno-exceptions -funwind-tables -fno-rtti -o tools/clang/lib/ExtractAPI/CMakeFiles/obj.clangExtractAPI.dir/ExtractAPIConsumer.cpp.s Also Hangup on x86.
[Bug target/113193] New: [SH] ICE in gen_reg_rtx, at emit-rtl.cc:1177 with -mfcsa -funsafe-math-operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113193 Bug ID: 113193 Summary: [SH] ICE in gen_reg_rtx, at emit-rtl.cc:1177 with -mfcsa -funsafe-math-operations 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: zack+gcc at buhman dot org Target Milestone: --- Target: sh*-*-* Created attachment 56971 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56971=edit -freport-bug On the sh*-*-* target it is possible to generate an ICE at all optimization levels above -O0 with -mfcsa -funsafe-math-optimizations , for certain sequences of valid code that contain __builtin_cosf and/or __builtin_sinf. The attached -freport-bug output is one (500-line) example that only appears to trigger this ICE at -O3, but other (perhaps more convoluted) examples are possible. This affects all GCC versions between at least 9.5.0 and the current 14.0 master, inclusive. I did not test GCC versions older than 9.5.0.
[Bug target/113112] RISC-V: Dynamic LMUL feature stabilization for GCC-14 release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113112 --- Comment #4 from GCC Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:9a29b00365a07745c4ba2ed2af374e7c732aaeb3 commit r14-6877-g9a29b00365a07745c4ba2ed2af374e7c732aaeb3 Author: Juzhe-Zhong Date: Fri Dec 29 09:21:02 2023 +0800 RISC-V: Count pointer type SSA into RVV regs liveness for dynamic LMUL cost model This patch fixes the following choosing unexpected big LMUL which cause register spillings. Before this patch, choosing LMUL = 4: addisp,sp,-160 addiw t1,a2,-1 li a5,7 bleut1,a5,.L16 vsetivlizero,8,e64,m4,ta,ma vmv.v.x v4,a0 vs4r.v v4,0(sp)---> spill to the stack. vmv.v.x v4,a1 addia5,sp,64 vs4r.v v4,0(a5)---> spill to the stack. The root cause is the following codes: if (poly_int_tree_p (var) || (is_gimple_val (var) && !POINTER_TYPE_P (TREE_TYPE (var We count the variable as consuming a RVV reg group when it is not POINTER_TYPE. It is right for load/store STMT for example: _1 = (MEM)*addr --> addr won't be allocated an RVV vector group. However, we find it is not right for non-load/store STMT: _3 = _1 == x_8(D); _1 is pointer type too but we does allocate a RVV register group for it. So after this patch, we are choosing the perfect LMUL for the testcase in this patch: ble a2,zero,.L17 addiw a7,a2,-1 li a5,3 bleua7,a5,.L15 srliw a5,a7,2 sllia6,a5,1 add a6,a6,a5 lui a5,%hi(replacements) addit1,a5,%lo(replacements) sllia6,a6,5 lui t4,%hi(.LANCHOR0) lui t3,%hi(.LANCHOR0+8) lui a3,%hi(.LANCHOR0+16) lui a4,%hi(.LC1) vsetivlizero,4,e16,mf2,ta,ma addit4,t4,%lo(.LANCHOR0) addit3,t3,%lo(.LANCHOR0+8) addia3,a3,%lo(.LANCHOR0+16) addia4,a4,%lo(.LC1) add a6,t1,a6 addia5,a5,%lo(replacements) vle16.v v18,0(t4) vle16.v v17,0(t3) vle16.v v16,0(a3) vmsgeu.vi v25,v18,4 vadd.vi v24,v18,-4 vmsgeu.vi v23,v17,4 vadd.vi v22,v17,-4 vlm.v v21,0(a4) vmsgeu.vi v20,v16,4 vadd.vi v19,v16,-4 vsetvli zero,zero,e64,m2,ta,mu vmv.v.x v12,a0 vmv.v.x v14,a1 .L4: vlseg3e64.v v6,(a5) vmseq.vvv2,v6,v12 vmseq.vvv0,v8,v12 vmsne.vvv1,v8,v12 vmand.mmv1,v1,v2 vmerge.vvm v2,v8,v14,v0 vmv1r.v v0,v1 addia4,a5,24 vmerge.vvm v6,v6,v14,v0 vmerge.vim v2,v2,0,v0 vrgatherei16.vv v4,v6,v18 vmv1r.v v0,v25 vrgatherei16.vv v4,v2,v24,v0.t vs1r.v v4,0(a5) addia3,a5,48 vmv1r.v v0,v21 vmv2r.v v4,v2 vcompress.vmv4,v6,v0 vs1r.v v4,0(a4) vmv1r.v v0,v23 addia4,a5,72 vrgatherei16.vv v4,v6,v17 vrgatherei16.vv v4,v2,v22,v0.t vs1r.v v4,0(a3) vmv1r.v v0,v20 vrgatherei16.vv v4,v6,v16 addia5,a5,96 vrgatherei16.vv v4,v2,v19,v0.t vs1r.v v4,0(a4) bne a6,a5,.L4 No spillings, no "sp" register used. Tested on both RV32 and RV64, no regression. Ok for trunk ? PR target/113112 gcc/ChangeLog: * config/riscv/riscv-vector-costs.cc (compute_nregs_for_mode): Fix pointer type liveness count. gcc/testsuite/ChangeLog: * gcc.dg/vect/costmodel/riscv/rvv/pr113112-4.c: New test.
[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
--- Comment #5 from John David Anglin ---
The problem is TREE_SYMBOL_REFERENCED is not set for libfuncs. This fixes
problem on hppa64-hpux:
bash-5.1$ git diff gcc/varasm.cc
diff --git a/gcc/varasm.cc b/gcc/varasm.cc
index 69f8f8ee018..0a1cc022023 100644
--- a/gcc/varasm.cc
+++ b/gcc/varasm.cc
@@ -2527,9 +2527,7 @@ process_pending_assemble_externals (void)
for (rtx list = pending_libcall_symbols; list; list = XEXP (list, 1))
{
rtx symbol = XEXP (list, 0);
- tree id = get_identifier (XSTR (symbol, 0));
- if (TREE_SYMBOL_REFERENCED (id))
- targetm.asm_out.external_libcall (symbol);
+ targetm.asm_out.external_libcall (symbol);
}
pending_assemble_externals = 0;
If you don't care about libfuncs, you could move the TREE_SYMBOL_REFERENCED
check into the bpf target.
[Bug middle-end/88345] -Os overrides -falign-functions=N on the command line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345 --- Comment #23 from Jan Hubicka --- Created attachment 56970 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56970=edit Patch I am testing Hi, this adds -falign-all-functions parameter. It still look like more reasonable (and backward compatible) thing to do. I also poked about Richi's suggestion of extending the syntax of -falign-functions but I think it is less readable.
[Bug libgomp/113192] New: [14 Regression] ERROR: couldn't execute "../../../gcc/libgomp/testsuite/flock": no such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113192
Bug ID: 113192
Summary: [14 Regression] ERROR: couldn't execute
"../../../gcc/libgomp/testsuite/flock": no such file
or directory
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: danglin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, tschwinge at gcc dot gnu.org
Target Milestone: ---
Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
Build: hppa64-hp-hpux11.11
HP-UX doesn't have flock but it does have perl. configure tries to create
a fallback but a relative path to libgomp/testsuite/flock is generated.
It is wrong when the testsuite is run.
AC_MSG_NOTICE([checking for flock implementation])
AC_CHECK_PROGS(FLOCK, flock)
# Fallback if 'perl' is available.
if test -z "$FLOCK"; then
AC_CHECK_PROG(FLOCK, perl, $srcdir/testsuite/flock)
fi
configure: checking for flock implementation
checking for flock... no
checking for perl... ../../../gcc/libgomp/testsuite/flock
Running /home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.c/c.exp ...
ERROR: tcl error sourcing
/home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.c/c.exp.
ERROR: tcl error code NONE
ERROR: couldn't execute "../../../gcc/libgomp/testsuite/flock": no such file or
directory
while executing
"exec $FLOCK $lock_kind 1 >@ $lock_fd"
(procedure "saved_libgomp_load" line 10)
invoked from within
"saved_libgomp_load ./alloc-1.exe"
("eval" body line 1)
invoked from within
"eval [list saved_${tool}_load $program] $args"
(procedure "libgomp_load" line 13)
invoked from within
"${tool}_load $output_file"
(procedure "saved-dg-test" line 218)
invoked from within
"saved-dg-test
/home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.c/../libgomp.c-c++-common/alloc-1.c
{} -O2"
("eval" body line 1)
invoked from within
"eval saved-dg-test $args "
(procedure "dg-test" line 1)
invoked from within
"dg-test $testcase $options ${default-extra-options}"
(procedure "dg-runtest" line 10)
invoked from within
"dg-runtest $tests "" $DEFAULT_CFLAGS"
(file "/home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.c/c.exp" line 27)
invoked from within
"source /home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.c/c.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source /home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.c/c.exp"
invoked from within
"catch "uplevel #0 source $test_file_name" msg"
This problem was introduced by the following commit:
commit 04abe1944d30eb18a2060cfcd9695d085f7b4752
Author: Thomas Schwinge
Date: Mon May 15 20:00:07 2023 +0200
Support parallel testing in libgomp: fallback Perl 'flock' [PR66005]
It appears this problem can be worked around by exporting FLOCK.
[Bug target/109133] Error: operands mismatch -- statement `movec %d0,%cacr' ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109133 Andreas Schwab changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andreas Schwab --- The available control registers are dependent on the particular device, a generic setting like isac does not include any.
[Bug target/109133] Error: operands mismatch -- statement `movec %d0,%cacr' ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109133 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #1 from Mikael Pettersson --- Looks like either a problem in gas, or the gcc driver not passing appropriate options to gas. We need a standalone test case, and please indicate exactly what versions of gcc and binutils you're using and how they were configured and built.
[Bug c++/113191] New: [10.1/11/12/13/14 Regression] Incorrect overload resolution when base class function introduced with a using declaration is more constrained than a function declared in the deriv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113191
Bug ID: 113191
Summary: [10.1/11/12/13/14 Regression] Incorrect overload
resolution when base class function introduced with a
using declaration is more constrained than a function
declared in the derived class
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: waffl3x at protonmail dot com
Target Milestone: ---
https://godbolt.org/z/91esEGhj4
template
struct B {
constexpr int f() requires true { return 5; }
};
template
struct S : B<> {
using B::f;
constexpr int f() { return 10; }
};
static_assert(S<>{}.f() == 5);
The bug does not occur in this case:
https://godbolt.org/z/dPM1Gfc1c
We do the right thing in more_specialized_fn (which is why the second
case works fine), but that doesn't apply in this case. Perhaps we
should be lifting that work from more_specialized_fn to joust?
Unfortunately, the changes in more_specialized_fn do not properly
handle the following case.
struct B {
template
requires true
int g(T) { return 5; }
};
struct S : B {
using B::g;
template
int g(this S&, T) { return 10; }
};
int main()
{
S s{};
s.g(0);
}
This case is ambiguous, I believe the main issue is that
more_specialized_fn does not implement [over.match.funcs.general.4].
This is kind of a separate bug but they are connected, and it's
relevant to how we decide to fix it. I'm mildly of the opinion that we
should be rewriting iobj member functions that are introduced with a
using declaration to have an object parameter matching that of the
class it was introduced into. This might open a can of worms, but it
more closely matches the behavior specified by the standard.
[over.match.funcs.general.4]
For non-conversion functions that are implicit object member
functions nominated by a using-declaration in a derived class, the
function is considered to be a member of the derived class for the purpose
of defining the type of the implicit object parameter.
This wasn't really as relevant before, but it does become relevant now
because of the following case.
https://godbolt.org/z/MjP5nrd8q
template
struct S;
template
struct B {
constexpr int f(this S<> const&) { return 5; }
constexpr int g() const { return 5; }
};
template
struct S : B<> {
using B<>::f;
using B<>::g;
constexpr int f() const { return 10; }
constexpr int g(this S const&) { return 10; }
};
inline constexpr S<> s{};
static_assert(s.f() == 5);
static_assert(s.g() == 5);
I am not 100% sure what the correct behavior here is, but my
interpretation is that the constraints should be taken into account.
Again, this is slightly unrelated to this bug report, but it's more
evidence that we should just overhaul everything with iobj member
functions, and follow the standard to the letter. I think it's going to
be simpler in the long run, trying to hack it in this way or that is
just going to keep introducing problems. With that said, I recognize
theres potential implementation difficulties with doing it this way
too. Ultimately, it's a big decision so I don't mean to declare that we
need to do it this way, I merely intend to present it as food for
thought.
My implementation currently does not do either of these correct at all,
and as you can see in the godbolt link, clang does not exhibit the
behavior I believe to be correct either.
One last note, despite this being a regression, I don't believe that
the previous implementation will be ideal (not that I've found the
divergence yet.) Previous versions had the liberty of making different
assumptions, and as demonstrated in the examples with xobj member
functions, we have some new issues we need to work around here as well.
I've spent the better part of 6 hours investigating this issue and the
issues related to it, trying to figure out how to handle it for my
patch. I have concluded that I'm not going to try to fix this bug for
xobj member functions, and instead going to wait for this bug to be
fixed to try to handle it. So the behavior for xobj member functions
and iobj member functions will both be equally incorrect. Anyway, since
I have spent so much time staring at this I might have made some
mistakes in this report, or it will just be more confusing and
disjointed than I hoped. Hopefully not though!
[Bug target/80786] m68k: internal compiler error: in change_address_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80786
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Comment #4 from Mikael Pettersson ---
Reduced test case:
> cat /tmp/pr80786.c
extern long G[];
void dir_op(short op, short *dirs)
{
if (!op)
*dirs = G[1];
}
> gcc/xgcc -Bgcc -O2 -mpcrel -S /tmp/pr80786.c
during RTL pass: final
/tmp/pr80786.c: In function 'dir_op':
/tmp/pr80786.c:7:1: internal compiler error: in change_address_1, at
emit-rtl.cc:2299
7 | }
| ^
0x40dc15 change_address_1
/mnt/scratch/other/mikpe-gcc.git/gcc/emit-rtl.cc:2299
0x668fc9 adjust_address_1(rtx_def*, machine_mode, poly_int<1u, long>, int, int,
int, poly_int<1u, long>)
/mnt/scratch/other/mikpe-gcc.git/gcc/emit-rtl.cc:2433
0x10c2ea2 output_80
/mnt/scratch/other/mikpe-gcc.git/gcc/config/m68k/m68k.md:1678
...
This is gcc-14 from 2023-12-30, and output_80 is m68k.md's truncsihi2 insn.
The source operand is
(mem:SI (const:SI (plus:SI (symbol_ref:SI ("G") [flags 0x40] )
(const_int 4 [0x4]))) [1 G[1]+0 S4 A16])
which truncsihi2 wants to adjust by adding 2 to the offset, but
(const:SI (plus:SI (symbol_ref:SI ("G") [flags 0x40] )
(const_int 6 [0x6])))
is rejected by m68k_legitimate_constant_address_p, causing
m68k_decompose_address to fail, and the assert in change_address_1 to fire.
Disabling this insn for TARGET_PCREL seems to work, but I don't know what
negative side-effects that might have.
gcc-4.9 and older were ok, gcc-5 and above ICE, starting with
aea3d681ec784b1a44ee3b37b0df2b71bdfadfc3 is the first new commit
commit aea3d681ec784b1a44ee3b37b0df2b71bdfadfc3
Author: DJ Delorie
Date: Fri Aug 29 19:19:42 2014 -0400
expr.c (convert_move): If the target has an explicit converter, use it.
[Bug web/113190] Alert not to report bugs against EOL releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113190 Eyal Rozenberg changed: What|Removed |Added CC||eyalroz1 at gmx dot com --- Comment #1 from Eyal Rozenberg --- Fair enough, but - also add: 1. A link to some page with guidelines on configuring older GCC releases for maximum likelyhood of the build succeeding, on different OS distributions. 2. A link to the gcc-help mailing list page, or some other venue where one might ask about build trouble with such releases
[Bug web/113190] New: Alert not to report bugs against EOL releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113190 Bug ID: 113190 Summary: Alert not to report bugs against EOL releases Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at gcc dot gnu.org Target Milestone: --- Let's add something into the red banner of the "new bug" page like "Try to reproduce the bug with one of the supported releases listed on https://gcc.gnu.org/. If the bug only reproduces with releases no longer supported, it will be closed as WONTFIX."
[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208 --- Comment #9 from Segher Boessenkool --- (In reply to John Paul Adrian Glaubitz from comment #8) > (In reply to Segher Boessenkool from comment #7) > > This PR is for the sysv ABI, while most discussion was about the "ELFv1" > > ABI. > > Doesn't the subject clearly mention "powerpc-unknown-linux-gnu"? Yes. And most of the discussion (via the gentoo link) is about powerpc64-linux. So things were confusing, for me at least. > I am trying -O3 now. That almost always runs out of space easier, not less easily. O3 prioritises possible speed wins over anything else (*possible* speed wins). > > If you get an error at line 577996 of a source file, changes are your code > > is just > > completely unreasonably large, esp. on a smaller target like this :-) > > I understand. But it's not always possible to change the code size, > especially when the code is not mine but some random upstream code. > > What I don't understand is that other 32-bit architectures don't seem to be > affected. For example, hppa-unknown-linux-gnu is not affected. None of the HPPA ABIs are affected by peculiarities of a particular PowerPC ABI. The bug report does noty give enough information to see what is really going on, so I have no further advice.
[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208 --- Comment #8 from John Paul Adrian Glaubitz --- (In reply to Segher Boessenkool from comment #7) > This PR is for the sysv ABI, while most discussion was about the "ELFv1" ABI. Doesn't the subject clearly mention "powerpc-unknown-linux-gnu"? > Only the 64-bit ABIs have the code model ABI, for the powerpc*-*-* > configurations. > Some other architectures have it for more things, and some for fewer, or > even none. I am trying -O3 now. > If you get an error at line 577996 of a source file, changes are your code > is just > completely unreasonably large, esp. on a smaller target like this :-) I understand. But it's not always possible to change the code size, especially when the code is not mine but some random upstream code. What I don't understand is that other 32-bit architectures don't seem to be affected. For example, hppa-unknown-linux-gnu is not affected. And, secondly, using LLVM as the bootstrap compiler resolves the issue with LLVM for me.
[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208 --- Comment #7 from Segher Boessenkool --- This PR is for the sysv ABI, while most discussion was about the "ELFv1" ABI. Only the 64-bit ABIs have the code model ABI, for the powerpc*-*-* configurations. Some other architectures have it for more things, and some for fewer, or even none. If you get an error at line 577996 of a source file, changes are your code is just completely unreasonably large, esp. on a smaller target like this :-)
[Bug tree-optimization/113189] `(-X * Y) * -X` can be optimized to `(X * Y) * X`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113189 --- Comment #2 from Joseph S. Myers --- If Y is INT_MIN and X is -1, removing the negations introduces undefined behavior in the first example (-(-1) * INT_MIN * -(-1) is valid, -1 * INT_MIN * -1 has undefined behavior). For floating types, removing the negations isn't valid if flag_rounding_math.
[Bug tree-optimization/90693] Missing popcount simplifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90693 Piotr Siupa changed: What|Removed |Added CC||piotrsiupa at gmail dot com --- Comment #8 from Piotr Siupa --- I did a benchmark and (x & (x-1)) == 0 and it seems to be about 2x as fast as the currently generated code (at least on my AMD64 processor). Maybe it should be used if x is guaranteed to not be zero, e.g. if (x == 0) std::unreachable().
[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208 --- Comment #6 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #5) > (In reply to Segher Boessenkool from comment #4) > > See my previous comment? > > > > You can either write better code, or use -mcmodel=large or similar, > > accepting > > the not-so-stellar generated code you get then. > > I'm already testing -mcmodel=large now. I'm just surprised it just affects > GCC on PowerPC but not LLVM, for example. Doesn't seem to be supported, unfortunately, build fails with: '-mcmodel' not supported in this configuration
[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208 --- Comment #5 from John Paul Adrian Glaubitz --- (In reply to Segher Boessenkool from comment #4) > See my previous comment? > > You can either write better code, or use -mcmodel=large or similar, accepting > the not-so-stellar generated code you get then. I'm already testing -mcmodel=large now. I'm just surprised it just affects GCC on PowerPC but not LLVM, for example.
[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208 --- Comment #4 from Segher Boessenkool --- See my previous comment? You can either write better code, or use -mcmodel=large or similar, accepting the not-so-stellar generated code you get then.
[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208 John Paul Adrian Glaubitz changed: What|Removed |Added CC||glaubitz at physik dot fu-berlin.d ||e --- Comment #3 from John Paul Adrian Glaubitz --- I am seeing this when building LLVM and GHC on 32-bit PowerPC as well. It does not affect other 32-bit architectures and using LLVM as the bootstrap compiler resolves this issue. What's the proper way of addressing this?
[Bug tree-optimization/113189] `(-X * Y) * -X` can be optimized to `(X * Y) * X`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113189
--- Comment #1 from Andrew Pinski ---
Other examples where the negative can be removed:
```
int foo(int a) {
return -a * (-a * a);
}
int bar(int a) {
return (-a * -a) * a;
}
int foo1(int a, int b, int c) {
return -a * (-b * c);
}
```
bar is handled at the gimple level but foo and foo1 are not.
[Bug tree-optimization/113189] New: `(-X * Y) * -X` can be optimized to `(X * Y) * X`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113189
Bug ID: 113189
Summary: `(-X * Y) * -X` can be optimized to `(X * Y) * X`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization, TREE
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int f(int X, int Y)
{
return (-X * Y) * -X;
}
double fd(double X, double Y)
{
return (-X * Y) * -X;
}
int g(int X, int Y)
{
return ((-X) << Y) * -X;
}
```
The negative should be optimized away but currently is only optimized at the
RTL level.
[Bug other/113188] graphite-isl-ast-to-gimple.c: ‘isl_val_free’ was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113188 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Andrew Pinski --- The version of ISL that works with the version of GCC can be downloaded via contrib/download_prerequisites or you can use --without-isl configure option which will disable support to use ISL. Anyways GCC 6.5 is no longer supported so no patches are going to fix it. Also bugzilla is not correct location for getting support of building older versions of GCC which are no longer supported, the mailing list gcc-help@ is a better place for that.
[Bug other/113188] New: graphite-isl-ast-to-gimple.c: ‘isl_val_free’ was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113188 Bug ID: 113188 Summary: graphite-isl-ast-to-gimple.c: ‘isl_val_free’ was not declared in this scope Product: gcc Version: 6.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: eyalroz1 at gmx dot com Target Milestone: --- I'm struggling trying to build GCC 6.5.0 on a newer system: Devuan GNU/Linux Excalibur (~= Debian Trixie). I'm using the following configuration: ./configure --disable-libsanitizer --disable-bootstrap --enable-languages=c,c++ and at some point, I get a couple of compilation errors about undeclared identifiers; the error is quoted below. Is there some way I could circumvent these? e.g. by disabling another component or replacing a version of some tool/library? - g++ -fno-PIE -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid -I../libdecnumber -I../.././gcc/../libbacktrace -o graphite-isl-ast-to-gimple.o -MT graphite-isl-ast-to-gimple.o -MMD -MP -MF ./.deps/graphite-isl-ast-to-gimple.TPo ../.././gcc/graphite-isl-ast-to-gimple.c ../.././gcc/graphite-isl-ast-to-gimple.c: In member function ‘tree_node* translate_isl_ast_to_gimple::gcc_expression_from_isl_expr_int(tree, isl_ast_expr*)’: ../.././gcc/graphite-isl-ast-to-gimple.c:349:3: error: ‘isl_val_free’ was not declared in this scope; did you mean ‘isl_vec_free’? 349 | isl_val_free (val); | ^~~~ | isl_vec_free ../.././gcc/graphite-isl-ast-to-gimple.c: In function ‘isl_ast_expr* get_upper_bound(isl_ast_node*)’: ../.././gcc/graphite-isl-ast-to-gimple.c:752:11: error: ‘isl_val_int_from_si’ was not declared in this scope; did you mean ‘isl_val_int_from_gmp’? 752 | isl_val_int_from_si (isl_ast_expr_get_ctx (for_cond), 1); | ^~~ | isl_val_int_from_gmp
[Bug tree-optimization/113187] `(X & C1) | C2` Simplifies to `A & (C1 | C2)` iff `(A & C2) == C2`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113187 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/113187] New: `(X & C1) | C2` Simplifies to `A & (C1 | C2)` iff `(A & C2) == C2`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113187
Bug ID: 113187
Summary: `(X & C1) | C2` Simplifies to `A & (C1 | C2)` iff `(A
& C2) == C2`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int f(int X)
{
int C1 = 0x1;
int C2 = 0x2;
if ((X & C2) != C2)
__builtin_unreachable();
return (X & C1) | C2;
}
```
This should be optimized to just `return X & 3;` as `X&0x2` is known to be
already 0x2.
