[Bug other/105819] GCC 12.1.0 Make failed - Compiled with GCC 4.9.4 and under Mac OS X lion - I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105819 --- Comment #14 from bug-reports.delphin at laposte dot net --- Ok but where ? I didn't find it. What file shows me this coma, and what line/lines, where ? config.log ? my-configure.log ? my-make.log ? Besides, when one looks the my-make.log file it, seems that python issues an error (en d of the file). Maybe should I need to change the python compiler/path, in using, for example, PYTHON=path_to_a_python_compiler_elsewhere, or change to python3 ? But PYTHON seems not to be a parameter for configure (NB Not see the configure.ac to check this). Thank you. Kind regards, L.D.
[Bug c++/106654] [C++23] P1774 - Portable assumptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654 --- Comment #7 from Aldy Hernandez --- You could provide an API to access the different relations that hold in either the outline function, or the .IFN_ASSUME construct. Then ranger could use that API to access and record the different assertions. I'd hate for ranger to have to deconstruct some functions for clues. Silly question, why can't you expand the [[assume]] construct into: if (x > 5) __builtin_unreachable (); ...like we always have. Then no changes are needed to ranger :). Or does this have to do with the whole side-effect thing?
[Bug c++/106654] [C++23] P1774 - Portable assumptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654 Jason Merrill changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-09-17 Status|UNCONFIRMED |NEW --- Comment #8 from Jason Merrill --- (In reply to Aldy Hernandez from comment #7) > Silly question, why can't you expand the [[assume]] construct into: > > if (x > 5) > __builtin_unreachable (); > > ...like we always have. Then no changes are needed to ranger :). Or does > this have to do with the whole side-effect thing? Exactly. For expressions with no side-effects, we can do that. For, say, a call to a non-const function, we need to avoid actually emitting the call.
[Bug tree-optimization/68097] We should track ranges for floating-point values too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #6 from Aldy Hernandez --- (In reply to Richard Biener from comment #3) > Confirmed. > > Note the main part will be to make the FP "range info" available on SSA > names. > > Other useful queries would include "cannot be Inf/NaN/signed zero". > > Note that transforms based on this (and also nonnegative!) need to be careful > as there are no data dependences on conditions. Thus with > > if (x > 0.) >foo (x); > > we may not optimize foo based on 'nonnegative' as code motion has no barrier > that prevents it from hoisting it before the if. > > Yes, vectors could also be handled (and yes, please one "value range" per > SSA name only). Likewise complex (integer) types. Is this PR already solved? FP range info is available on SSA names currently. We can also query inf/NAN/signed zeros/etc. And regarding PR24021 which pinskia mentioned, there is support for VRP-FP now. We just don't understand the PLUS_EXPR. I have a patch for that as well, and should contribute it early next week.
[Bug c++/106654] [C++23] P1774 - Portable assumptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654 --- Comment #9 from Aldy Hernandez --- (In reply to Jason Merrill from comment #8) > (In reply to Aldy Hernandez from comment #7) > > Silly question, why can't you expand the [[assume]] construct into: > > > > if (x > 5) > > __builtin_unreachable (); > > > > ...like we always have. Then no changes are needed to ranger :). Or does > > this have to do with the whole side-effect thing? > > Exactly. For expressions with no side-effects, we can do that. For, say, a > call to a non-const function, we need to avoid actually emitting the call. So...could we keep doing what we're doing for non side-effect code, and only do the outline function for side-effect stuff? Or is that too much to ask? But wait a minute, is calling a non-const function from [[assume]] even allowed?
[Bug c++/106654] [C++23] P1774 - Portable assumptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654 --- Comment #10 from Jason Merrill --- (In reply to Aldy Hernandez from comment #9) > So...could we keep doing what we're doing for non side-effect code, and only > do the outline function for side-effect stuff? Or is that too much to ask? Yes, that's what Jakub proposed in comment #4. > But wait a minute, is calling a non-const function from [[assume]] even > allowed? Yep, that's the tricky part. Of course, as functions get more complicated, the compiler being able to do anything useful with it gets less likely. It seems entirely reasonable to start with calls to functions that the compiler knows are const even if they aren't declared with the attribute.
[Bug tree-optimization/106960] New: [12/13 Regression] Incorrect optimization of signed integer comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106960
Bug ID: 106960
Summary: [12/13 Regression] Incorrect optimization of signed
integer comparisons
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: danglin at gcc dot gnu.org
CC: deller at gmx dot de
Target Milestone: ---
Host: hppa*-*-linux*
Target: hppa*-*-linux*
Build: hppa*-*-linux*
This problem was noticed in the Debian flint 2.9.0-5 testsuite. The
fmpq/cmp_si.c testcase fails with a segmentation fault becaused of an
incorrect optimization.
Here is a reduced testcase:
dave@atlas:~/gnu/gcc/objdir$ cat foo.c
int bar (long);
int _fmpq_cmp_si (long c)
{
long d;
d = -c;
if (d != c) /* Check for LONG_MIN */
{
d = c < 0 ? -c : c;
return bar (d);
}
return 0;
}
When compiled at -O1 and above, the comparison only checks for 0 and not
for LONG_MIN (see movb instruction):
dave@atlas:~/gnu/gcc/objdir$ cat foo.s
.LEVEL 1.1
.text
.align 4
.globl _fmpq_cmp_si
.type _fmpq_cmp_si, @function
_fmpq_cmp_si:
.PROC
.CALLINFO FRAME=64,CALLS,SAVE_RP
.ENTRY
stw %r2,-20(%r30)
ldo 64(%r30),%r30
movb,<>,n %r26,%r28,.L3
ldw -84(%r30),%r2
.L4:
bv %r0(%r2)
ldo -64(%r30),%r30
.L3:
or,>= %r0,%r28,%r26
subi 0,%r26,%r26
bl bar,%r2
nop
b .L4
ldw -84(%r30),%r2
.EXIT
.PROCEND
.size _fmpq_cmp_si, .-_fmpq_cmp_si
.ident "GCC: (Debian 12.2.0-2) 12.2.0"
The movb instruction copies %r26 (c) to %r28 (the return value) and
branches to .L3 if the register value is nonzero.
We have in foo.c.253r.expand:
;;
;; Full RTL generated for this function:
;;
(note 1 0 4 NOTE_INSN_DELETED)
;; basic block 2, loop depth 0, count 1073741824 (estimated locally), maybe hot
;; prev block 0, next block 4, flags: (NEW, REACHABLE, RTL, VISITED)
;; pred: ENTRY [always] count:1073741824 (estimated locally) (FALLTHRU)
(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 4 3 2 (set (reg/v:SI 98 [ c ])
(reg:SI 26 %r26 [ c ])) "foo.c":3:1 -1
(expr_list:REG_EQUIV (mem/c:SI (plus:SI (reg/f:SI 90
virtual-incoming-args)
(const_int -4 [0xfffc])) [1 c+0 S4 A32])
(nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(jump_insn 6 3 7 2 (set (pc)
(if_then_else (eq (reg/v:SI 98 [ c ])
(const_int 0 [0]))
(label_ref 12)
(pc))) "foo.c":7:6 -1
(int_list:REG_BR_PROB 856416484 (nil))
-> 12)
;; succ: 4 [20.2% (guessed)] count:217325344 (estimated locally)
(FALLTHRU)
;; 5 [79.8% (guessed)] count:856416480 (estimated locally)
;; basic block 4, loop depth 0, count 217325344 (estimated locally), maybe hot
;; prev block 2, next block 5, flags: (NEW, REACHABLE, RTL, VISITED)
;; pred: 2 [20.2% (guessed)] count:217325344 (estimated locally)
(FALLTHRU)
(note 7 6 8 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 8 7 9 4 (set (reg:SI 99 [ d ])
(abs:SI (reg/v:SI 98 [ c ]))) "foo.c":9:9 -1
(nil))
(insn 9 8 10 4 (set (reg:SI 26 %r26)
(reg:SI 99 [ d ])) "foo.c":10:14 -1
(nil))
(call_insn 10 9 11 4 (parallel [
(set (reg:SI 28 %r28)
(call (mem:SI (symbol_ref/v:SI ("@bar") [flags 0x41]
) [0 bar S4 A32])
(const_int 16 [0x10])))
(clobber (reg:SI 1 %r1))
(clobber (reg:SI 2 %r2))
(use (const_int 0 [0]))
]) "foo.c":10:14 -1
(nil)
(expr_list:SI (use (reg:SI 26 %r26))
(nil)))
(insn 11 10 12 4 (set (reg/v:SI 98 [ c ])
(reg:SI 28 %r28)) "foo.c":10:14 -1
(nil))
;; succ: 5 [always] count:217325344 (estimated locally) (FALLTHRU)
foo.c:10:14
;; basic block 5, loop depth 0, count 1073741824 (estimated locally), maybe hot
;; prev block 4, next block 1, flags: (NEW, REACHABLE, RTL, VISITED)
;; pred: 4 [always] count:217325344 (estimated locally) (FALLTHRU)
foo.c:10:14
;; 2 [79.8% (guessed)] count:856416480 (estimated locally)
(code_label 12 11 13 5 2 (nil) [1 uses])
(note 13 12 14 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 14 13 18 5 (set (reg:SI 97 [ ])
(reg/v:SI 98 [ c ])) "foo.c":13:1 -1
(nil))
(insn 18 14 19 5 (set (reg/i:SI 28 %r28)
(reg:SI 97 [ ])) "foo.c":13:1 -1
(nil))
(insn 19 18 0 5 (use (reg/i:SI 28 %r28)) "foo.c":13:1 -1
(nil))
;; succ: EXIT [always] count:1073741824 (estimated locally) (FALLTHRU)
So, this appears to be a tree optimization bug.
This occurs with Debian 12.2.0-2 and trunk. Debian 11.3.0-6 is okay.
[Bug target/106961] New: Testsuite failures after Command Line Tools update to v14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106961 Bug ID: 106961 Summary: Testsuite failures after Command Line Tools update to v14 Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- On re-running 'make check-acats', I got 37 fails (can’t remember what the count was before the change that triggered this, think it was zero) of which 19 included this text, sometimes once, sometimes multiple times: libunwind: _Unwind_GetTextRelBase - _Unwind_GetTextRelBase() not implemented This appears to have been caused by Apple’s release of the Command Line Tools version 14. I get very similar results on aarch64-apple-darwin21. On that architecture, the log for 'make check-g++` contains the text listed above.
[Bug tree-optimization/106960] [12/13 Regression] Incorrect optimization of signed integer comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106960 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Signed integer overflow is undefined behavior. That is -INT_MIN is undefined behavior. You need to either use -fwrapv or change the code to use unsigned types to get defined behavior.
[Bug target/106961] Testsuite failures after Command Line Tools update to v14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106961 --- Comment #1 from Andrew Pinski --- Sounds like you should report this to Apple ...
[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 Lawrence Lee changed: What|Removed |Added Attachment #53560|0 |1 is obsolete|| --- Comment #8 from Lawrence Lee --- Created attachment 53588 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53588&action=edit Updated Sample Program
[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 --- Comment #9 from Lawrence Lee --- Thank you Alexander for the recommendation. I don't know if this helps, but I updated the sample code to make the issue reproducible with the GCC trunk build available on godbolt.org. I just introduced an unused function parameter.
[Bug c++/106654] [C++23] P1774 - Portable assumptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654 --- Comment #11 from Aldy Hernandez --- (In reply to Jason Merrill from comment #10) > > But wait a minute, is calling a non-const function from [[assume]] even > > allowed? > > Yep, that's the tricky part. Of course, as functions get more complicated, > the compiler being able to do anything useful with it gets less likely. It > seems entirely reasonable to start with calls to functions that the compiler > knows are const even if they aren't declared with the attribute. I see. Ok, so yeah...I'm sure we can work something out. When y'all have a prototype representable in the IL, we'd be happy to enhance ranger to handle it. Sounds like something very useful, particularly for floats-- without exposing signaling whathaveyous. Maybe Andrew has some further thoughts here?
[Bug libstdc++/103626] _GLIBCXX_HOSTED should respect -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103626
--- Comment #2 from Arsen Arsenović ---
I started work on marking headers, and I already marked 162 headers (all of
include/{std,bits,backward}, where appropriate) as part of my work on P1642.
This set also lines up with the set of all installed installed headers for
P1642. I already have a list of remaining headers that need to be marked, I'll
be handling these, and maybe reverting the change on (to make it
freestanding).
The progress can be tracked here: https://github.com/ArsenArsen/gcc/tree/p16412
This branch includes the titular changes, in order to support switching between
freestanding and hosted, a rework of how freestanding headers are handled and
installed (though, I would like to exclude even more targets and files, so that
stuff doesn't get stamped needlessly, probably by constraining allstamped,
unsure so far), , and the aforementioned marking.
Next on my agenda is checking whether this version still produces equivalent
results in hosting to the unpatched version of GCC, and updating the testsuite
after that, then I can resume marking headers if this approach is deemed
acceptable (which I'd like to get a greenlight on before editing 400-some
headers by hand)
[Bug libstdc++/103626] _GLIBCXX_HOSTED should respect -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103626 --- Comment #3 from Jonathan Wakely --- I don't think we need to add the #error to every header. For a start, users never include the bits/* headers directly, and if they do, it's their problem. So we only need to mark the standard headers as hosted-only. And if we add it to , that already covers a large number of them, because they include that.
[Bug libstdc++/103626] _GLIBCXX_HOSTED should respect -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103626 --- Comment #4 from Arsen Arsenović --- (In reply to Jonathan Wakely from comment #3) > I don't think we need to add the #error to every header. For a start, users > never include the bits/* headers directly, and if they do, it's their > problem. So we only need to mark the standard headers as hosted-only. And if > we add it to , that already covers a large number of them, because > they include that. My thinking behind doing that was that it'd make includes transitively carry a requirement on hosted, so that if some header is meant to be freestanding, but depends on a hosted header, that could be detected (and that could probably be a testcase).
[Bug c/106962] New: How to create AOM codec in GCC 12.2 and newer under Windows 64bit?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106962 Bug ID: 106962 Summary: How to create AOM codec in GCC 12.2 and newer under Windows 64bit? Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: lukaszcz18 at wp dot pl Target Milestone: --- I want to produce codec without SIMD and assembler. I'm using basic functions `-std=gnu++11 -ftree-vectorize -g0 -O3 -DWINVER=0x0602 -D_WIN32_WINNT=0x0602 -DWIN32_LEAN_AND_MEAN=/"/" -DNOMINMAX`. The problem is that when I create AOM codecs in GCC 11.3.1 they work. On newer compilers GCC 12.2 and gcc13.0 aren't working. In GCC 11.3 codec creates photos. GCC 12.2 and above go straight to DOS. At first I thought they were GCC bugs. Now I know that there are newer versions of GCC and the effect has been the same for year. What have new features been added to these compilers? Strange thing. Other libraries have no problem: libjpeg-turbo, libpng, libtiff, dav1d, libgav1, avif, svt-av1, openhtj2k, openjph, openjpeg2000, ... http://msystem.waw.pl/x265/mingw-gcc113-20220819.7z http://msystem.waw.pl/x265/mingw-gcc1221-20220911.7z Codec gcc1131 https://www.sendspace.com/file/nwfozk
[Bug middle-end/106962] How to create AOM codec in GCC 12.2 and newer under Windows 64bit?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106962 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-09-18 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- Please read https://gcc.gnu.org/bugs/ and provide more information as requested in that page. It could be a bug in the code too and not in gcc.
[Bug tree-optimization/106963] New: [13 Regression] ICE in vect_gen_perm_mask_checked, at tree-vect-stmts.cc:8606
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106963
Bug ID: 106963
Summary: [13 Regression] ICE in vect_gen_perm_mask_checked, at
tree-vect-stmts.cc:8606
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: liuhongt at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc 13.0.0 20220911 snapshot (g:0ea5e3f4542832b8da016b152695e64a2a386309) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/i386/pr103144-neg-1.c, w/ -mavx -O2:
void
foo_neg_const (int *a)
{
int i, b = 1;
for (i = 0; i < 1000; i++)
{
a[i] = b;
b = -b;
}
}
% x86_64-unknown-linux-gnu-gcc-13.0.0 -mavx -O2 -c l9k774zu.c
during GIMPLE pass: vect
l9k774zu.c: In function 'foo_neg_const':
l9k774zu.c:2:1: internal compiler error: in vect_gen_perm_mask_checked, at
tree-vect-stmts.cc:8606
2 | foo_neg_const (int *a)
| ^
0x86e97b vect_gen_perm_mask_checked(tree_node*, vec_perm_indices const&)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/tree-vect-stmts.cc:8606
0x1177c4b vect_create_nonlinear_iv_init
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/tree-vect-loop.cc:8360
0x1177c4b vectorizable_nonlinear_induction
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/tree-vect-loop.cc:8803
0x1179a67 vectorizable_induction(_loop_vec_info*, _stmt_vec_info*, gimple**,
_slp_tree*, vec*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/tree-vect-loop.cc:8943
0x1ef3690 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/tree-vect-stmts.cc:11319
0x1186e81 vect_transform_loop(_loop_vec_info*, gimple*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/tree-vect-loop.cc:10643
0x11c99c1 vect_transform_loops
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/tree-vectorizer.cc:1007
0x11c9fff try_vectorize_loop_1
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/tree-vectorizer.cc:1153
0x11c9fff try_vectorize_loop
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/tree-vectorizer.cc:1183
0x11ca3b4 execute
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/tree-vectorizer.cc:1299
[Bug middle-end/106962] How to create AOM codec in GCC 12.2 and newer under Windows 64bit?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106962 --- Comment #2 from Jamaika --- For the inquisitive. I am adding open source. GCC 1X.X.0 displays no errors. Can check. Copy include files to gcc 1X.X.0 and run with webp2_nosimd.bat https://www.sendspace.com/file/jqx6ol
[Bug libstdc++/103626] _GLIBCXX_HOSTED should respect -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103626 --- Comment #5 from Jonathan Wakely --- If a header doesn't depend on any of , etc and could work for freestanding, do we want to explicitly disable out with #error, or make it available as an extension? Since the direction in the standard is to enable anything that can work freestanding, we could be liberal in freestanding extensions. That was my thinking anyway.
