https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119843
--- Comment #6 from Jakub Jelinek ---
rpm adds that in Fedora/RHEL and guess some distros based on that.
You need to actively remove it for building of gcc, or at least arrange it
doesn't apply to anything but what is built with the system gcc a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119843
Jakub Jelinek changed:
What|Removed |Added
CC||nickc at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119849
--- Comment #1 from Jakub Jelinek ---
Or perhaps easiest for now just add
#ifdef __gnu_linux__
and
#endif
around the gnu_pinned_mem cases?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119837
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119837
--- Comment #7 from Jakub Jelinek ---
I can reproduce with xterm, but the ) character is clearly there when I strace
it:
write(2, "\33[01m\33[Kpr119837.f90:2:9:\33[m\33[K\n\n2 | i =
6Habcdef\n |
\33[01;35m\33[K1\33[m\33[K\n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834
Jakub Jelinek changed:
What|Removed |Added
Attachment #61136|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834
--- Comment #23 from Jakub Jelinek ---
Thanks, confirmed it is late_combine that changes
(insn 1817 227 1735 42 (set (reg:DI 2 %r2 [orig:250 _176 ] [250])
(const_int 4 [0x4])) "../src/hb-algs.hh":996:17 1811 {*movdi_64}
(nil))
(note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110343
--- Comment #18 from Jakub Jelinek ---
Created attachment 61142
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61142&action=edit
gcc15-pr110343-c.patch
So far lightly tested patch for allowing those in C23/C2Y.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834
--- Comment #16 from Jakub Jelinek ---
Note, I'm afraid my bootstrap/regtest will take until tomorrow,
https://kojipkgs.fedoraproject.org//work/tasks/1218/131601218/build.log it is
only make -j3 (and eventhough I've disabled LTO bootstrap, it wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834
--- Comment #15 from Jakub Jelinek ---
If you can reproduce, could you please attach preprocessed source?
So that it can be bisected if it is indeed a 15 regression (then it might be a
P1) or not?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110343
--- Comment #16 from Jakub Jelinek ---
N3220 does have those 3 in there too, but dunno if that is a post C23 or pre
C23 draft.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110343
--- Comment #15 from Jakub Jelinek ---
I was looking at N3096 and that one doesn't have that. I see it in N3467.
Does official C23 have that change? Or is it C2Y?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834
--- Comment #11 from Jakub Jelinek ---
Though, if even that is too large, guess just
grep -C50 'clrmem_short' hb-subset.cc.*[0-9]r.*
might be good enough.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834
--- Comment #10 from Jakub Jelinek ---
Use xz -9e to compress it afterwards. And remove the vartrack one, there is
nothing interesting in there for this PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119211
Jakub Jelinek changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #10 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834
--- Comment #8 from Jakub Jelinek ---
(In reply to lfoldy from comment #7)
> (In reply to Jakub Jelinek from comment #6)
> > Created attachment 61136 [details]
> > gcc15-pr119834.patch
> >
> > Untested patch (except on a short testcase with mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834
--- Comment #6 from Jakub Jelinek ---
Created attachment 61136
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61136&action=edit
gcc15-pr119834.patch
Untested patch (except on a short testcase with memset (ptr, 0, 17); to verify
that *clrm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834
--- Comment #4 from Jakub Jelinek ---
Note, s390 is the only backend which does this, I see (clobber (scratch)) on
ia64 too, but it is there in the replacement of define_split, not in the
matching part.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #48 from Jakub Jelinek ---
Yeah, both #c40 and #c14 tests now work with your #c47 patch.
For the testcase, it seems that for some reason there is just one ltrans
partition, not two I was expecting, despite -flto-partition=max.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #45 from Jakub Jelinek ---
I'd say certainly
--- gcc/ipa-prop.cc.jj 2025-04-16 09:30:52.762558540 +0200
+++ gcc/ipa-prop.cc 2025-04-16 11:17:43.716154125 +0200
@@ -5518,8 +5518,8 @@ ipa_prop_write_jump_functions (void)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #43 from Jakub Jelinek ---
--- gcc/testsuite/g++.dg/lto/pr119614-1_0.C.jj 2025-04-16 10:37:44.584969998
+0200
+++ gcc/testsuite/g++.dg/lto/pr119614-1_0.C 2025-04-16 10:51:29.805679013
+0200
@@ -0,0 +1,41 @@
+// PR tree-optimizat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #42 from Jakub Jelinek ---
ipa_record_return_value_range is called on the Error FUNCTION_DECL, but during
ltrans time tailc pass is asking about Error.constprop.isra instead.
I think the reason why #c26 works and #c37 doesn't is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #41 from Jakub Jelinek ---
(In reply to Sam James from comment #38)
> The testcase from comment 14 fails for me still with Martin's last patch as
> well as Honza's.
Though it works with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119808
--- Comment #6 from Jakub Jelinek ---
Fixed on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119722
--- Comment #5 from Jakub Jelinek ---
*** Bug 116093 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116093
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119808
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119803
--- Comment #8 from Jakub Jelinek ---
So full patch would be
--- gcc/ipa-cp.cc.jj2025-04-15 14:56:26.861419422 +0200
+++ gcc/ipa-cp.cc 2025-04-15 15:10:05.270414498 +0200
@@ -933,13 +933,13 @@ ipcp_bits_lattice::meet_with_1 (widest_i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119801
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119808
--- Comment #3 from Jakub Jelinek ---
The clobber is emitted when processing
b.1_1 = (unsigned _BitInt(129)) b.0_6;
and the rules covering it are
if (m_first
&& m_single_use_names
&& m_vars[p] != m_lhs
&& m_af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119808
--- Comment #2 from Jakub Jelinek ---
The bug is in
bitint.4 ={v} {CLOBBER(eos)};
That shouldn't have been emitted after bitint.4 to bitint.4 copy for the
b.0_6 = b_5;
copy.
I guess for -O1 we should just omit any code for the copy when bot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119815
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119296
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |15.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119296
Bug 119296 depends on bug 119244, which changed state.
Bug 119244 Summary: cobol/libgcobol should allow libquadmath to provide 128b
floating support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |15.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #31 from Jakub Jelinek ---
baz actually isn't cloned at all, just IPA-VR should be able to find out that
it always returns NULL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119803
--- Comment #7 from Jakub Jelinek ---
Though guess ipcp_bits_lattice::meet_with needs similar treatment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119803
--- Comment #6 from Jakub Jelinek ---
--- gcc/ipa-cp.cc.jj2025-04-14 22:51:13.171434430 +0200
+++ gcc/ipa-cp.cc 2025-04-14 23:42:40.515006966 +0200
@@ -923,13 +923,13 @@ ipcp_bits_lattice::meet_with_1 (widest_i
m_mask = (m_mask | ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #30 from Jakub Jelinek ---
It doesn't work for me though on the testcase.
Breakpoint 5, ipa_return_value_range (range=..., decl=) at ../../gcc/ipa-prop.cc:6270
6290 if (info && info->m_return_vr)
(gdb) p info
$3 = (clone_info *)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #28 from Jakub Jelinek ---
Created attachment 61118
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61118&action=edit
gcc15-pr119614-inc.patch
Comments in the form of an incremental patch.
Mostly formatting + testcase, plus rem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119803
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119712
--- Comment #5 from Jakub Jelinek ---
Thanks.
Normally, tests timeout after a few minutes or something, and if this patch
fixes the problem, I think that is good enough, we don't lower time timeout
factor when we fix other compiler hangs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119785
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14 Regression] UBSAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119777
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119776
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |15.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119211
Bug 119211 depends on bug 119777, which changed state.
Bug 119777 Summary: [15 Regression] COBOL '-fsyntax-only', 'RejectNegative'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119777
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119211
Bug 119211 depends on bug 119776, which changed state.
Bug 119776 Summary: COBOL '-fmax-errors', 'Separate'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119776
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119801
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119801
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119801
Bug ID: 119801
Summary: [15 Regression] Rejects-valid with musttail attribute
and -fsanitize=thread
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119712
--- Comment #3 from Jakub Jelinek ---
Seems it hangs when doing range_of_stmt on if (_17 >= -1) in
[local count: 227695545]:
l:
_13 = _11 * 1958960196;
b.9_14 = b;
_15 = _13 + b.9_14;
_16 = _15 + -1016458303;
e = _16;
_17 = _16 * 20;
if (_17 >=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119796
--- Comment #7 from Jakub Jelinek ---
Created attachment 61110
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61110&action=edit
gcc15-pr119796.patch
So what about this untested patch?
Leaving aside whether we really need to lock more than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119796
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119785
Jakub Jelinek changed:
What|Removed |Added
Summary|UBSAN errors in machmode.h |[12/13/14/15 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119785
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2025-04-14
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119776
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119786
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119776
--- Comment #2 from Jakub Jelinek ---
Perhaps even better with
--- gcc/cobol/cobol1.cc.jj 2025-04-14 11:09:22.619126924 +0200
+++ gcc/cobol/cobol1.cc 2025-04-14 11:32:51.177896287 +0200
@@ -385,10 +385,6 @@ cobol_langhook_handle_option (siz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119777
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119777
--- Comment #4 from Jakub Jelinek ---
For -fsyntax-only I'd go with
2025-04-14 Jakub Jelinek
PR cobol/119777
* lang.opt (fsyntax-only): Remove.
* lang.opt.urls: Regenerate.
--- gcc/cobol/lang.opt.jj 2025-04-08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119777
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119778
--- Comment #13 from Jakub Jelinek ---
Perhaps both, making it also more robust?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119778
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119778
--- Comment #10 from Jakub Jelinek ---
Slightly cleaned up testcase:
struct jmp_buf { long l[16]; };
extern "C" void setjmp (jmp_buf *);
struct S {
void foo () { bar (); }
virtual char bar () { return 0; }
};
void baz ();
jmp_buf *a;
void
q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119780
--- Comment #4 from Jakub Jelinek ---
Slightly cleaned up & simplified:
int a = 1, b = -__INT_MAX__, c;
int
main ()
{
goto d;
e:
a = 0;
f:
if (a + c <= 0)
goto g;
h:
goto i;
d:
if (b >= 0)
goto e;
goto j;
i:
if (c - __INT_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119773
--- Comment #7 from Jakub Jelinek ---
Ok, so I've verified that before slsr pass stepping through the IL would
terminate and return 0 from main.
The slsr change is
@@ -64,8 +64,8 @@ int main ()
goto ; [73.64%]
[local count: 790703480]:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #26 from Jakub Jelinek ---
Created attachment 61100
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61100&action=edit
gcc15-pr119614-lto.patch
Even more hacky patch which actually works though. As I haven't figured out
how to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119773
--- Comment #5 from Jakub Jelinek ---
maybe_optimize_sub_cmp_0 doesn't change behavior on the testcase at all (at
least on the trunk) though.
Most likely SLSR bug, -fno-tree-slsr makes it go away, will verify in the
morning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
--- Comment #35 from Jakub Jelinek ---
The patch awaits review...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
--- Comment #32 from Jakub Jelinek ---
I think https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680622.html should
fix that (stop using libquadmath for COBOL altogether unless it is really
needed (which means long double is not IEEE quad (so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119733
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119722
--- Comment #4 from Jakub Jelinek ---
Fixed on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119729
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119727
--- Comment #3 from Jakub Jelinek ---
We need something that works on other OSes too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119727
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119727
Bug ID: 119727
Summary: -freport-bug vs. ASLR
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #23 from Jakub Jelinek ---
IMHO -fexcess-precision=16 (at least on x86_64 64-bit and with -mfpmath=sse
-msse2 32-bit too) are completely conformant modes, it is like 0 (where all of
float, _Float32, double, _Float64, long double, _Fl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
--- Comment #8 from Jakub Jelinek ---
I meant it the other way around, keep the getenv calls that should work for all
users, maintainers or not in the 15 release as is.
Rename all other getenv calls (those which are meant for maintainer debuggin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #20 from Jakub Jelinek ---
C23 documents it in detail, and so does float.h:
/* The floating-point expression evaluation method. The precise
definitions of these values are generalised to include support for
the interchange and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
--- Comment #6 from Jakub Jelinek ---
I'm not sure there is enough time before the branching for new options etc.
So, I just wondered about something that can be done quickly, whether it is
renaming
most of the getenv uses (except for those whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119722
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119723
--- Comment #2 from Jakub Jelinek ---
That commit to some extent restores the GCC 14 behavior. Arguably the
[0x8000ULL,0xULL] CONST_INTs better should have cost of
COST_N_INSNS (1)
but then we need to do something better for the uns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119722
--- Comment #1 from Jakub Jelinek ---
I think the problem is in the coalesce handling of
[local count: 1073741824]:
# b_17 = PHI
g.4_13 = g;
_14 = g.4_13 >> 50;
_15 = (unsigned int) _14;
_21 = b_17;
_16 = (unsigned int) _21;
s_22 = _15 + _16;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #18 from Jakub Jelinek ---
(In reply to Vincent Lefèvre from comment #17)
> > (for -fexcess-precision=fast arguably it should be IMHO -1).
>
> 2 is more accurate. Note that -1 would not make GCC conforming with
> -fexcess-precision=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #16 from Jakub Jelinek ---
2 is of course the right value for -fexcess-precision=standard -m32 on x86 (for
-fexcess-precision=fast arguably it should be IMHO -1).
Anyway, if you don't believe -fexcess-precision= affects the FLT_EVAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #14 from Jakub Jelinek ---
(In reply to Vincent Lefèvre from comment #13)
> -fexcess-precision is not meant to have an effect on __FLT_EVAL_METHOD__,
No, -fexcess-precision= is meant to have an effect on __FLT_EVAL_METHOD__, it
is w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119718
--- Comment #10 from Jakub Jelinek ---
Created attachment 61071
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61071&action=edit
gcc15-pr119718.patch
Untested patch which changes the -fdump-tree-tailc message wording and moves
it to just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119718
--- Comment #11 from Jakub Jelinek ---
Though, wonder if it wouldn't be more user-friendly to emit the GIMPLE or
GENERIC calls on the same line, incremental
--- gcc/tree-tailcall.cc.jj 2025-04-11 09:38:22.483257379 +0200
+++ gcc/tree-tailcal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119718
--- Comment #9 from Jakub Jelinek ---
You can get some of it already from vanilla trunk,
-fdump-tree-tailc=/dev/stderr 2>&1 | grep '^Cannot convert:'
That is for spots where for musttail calls the pass would error as well.
This doesn't cover the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119707
--- Comment #6 from Jakub Jelinek ---
Fixed on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
--- Comment #4 from Jakub Jelinek ---
Note, if SHOW_PARSE is something like dumping the semantic IL, then the usual
way is have a compiler option and dump the details into a file.
Either as messages into the -fdump-tree-original file or see e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119718
--- Comment #7 from Jakub Jelinek ---
(In reply to lucier from comment #6)
> If musttail is going to change which tail calls are optimized, I really
> think we need a warning flag that will have GCC give a warning when musttail
> is not used on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119718
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119716
--- Comment #4 from Jakub Jelinek ---
If the compiler compiles it and it misbehaves at runtime, that is valid
behavior for undefined behavior. ICE (as in the other PR) is something we
should fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119716
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119669
--- Comment #3 from Jakub Jelinek ---
Note, removing the ! character makes it work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119669
--- Comment #2 from Jakub Jelinek ---
I can:
/opt/notnfs/gcc-bisect/obj/gcc/f951.r15-9357 -quiet pr119669.f90
f951.r15-9357: internal compiler error: in compare_parameter, at
fortran/interface.cc:2537
0x2d42e37 internal_error(char const*, ...)
1 - 100 of 5793 matches
Mail list logo
