https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #33 from Jakub Jelinek ---
It regresses
g++.dg/coroutines/torture/co-await-16-template-traits.C
g++.dg/cpp0x/pr89403.C
g++.dg/tree-ssa/pr46228.C
g++.dg/torture/pr104601.C
g++.dg/torture/pr89303.C
g++.dg/torture/pr91606.C
on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #32 from Jakub Jelinek ---
Created attachment 57963
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57963=edit
gcc14-pr113208.patch
Ah, I shouldn't call expand_or_defer* in that function, that has been called
already earlier
dot gnu.org |jakub at gcc dot gnu.org
Last reconfirmed||2024-04-16
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Jakub Jelinek ---
Created attachment 57962
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57962=edit
gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #31 from Jakub Jelinek ---
Created attachment 57960
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57960=edit
gcc14-pr113208.patch
Here is my attempt to optimize it in the C++ FE.
The ICE is gone and for pr113208_0.C compiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114740
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114738
Jakub Jelinek changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
Target
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
gcc/configure.ac uses DOCUMENTATION_ROOT_URL="https://gcc.gnu.org/onlinedocs/;
as the default documentation root. That is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #29 from Jakub Jelinek ---
Looking at t1 (i.e. the reduced testcase with constexpr), the difference with
-std=c++20 -O1 -fkeep-inline-functions is that in r14-5978 we used to emit
_ZN6vectorI12QualityValueEC2ERKS1_ in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114706
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114706
--- Comment #4 from Jakub Jelinek ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:79ff53453e88e40c4f2ecf6f7f7409afc41b46fc
commit r14-9987-g79ff53453e88e40c4f2ecf6f7f7409afc41b46fc
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
Bug 89863 depends on bug 114689, which changed state.
Bug 114689 Summary: [14 Regression] libgcc/config/m68k/fpgnulib.c:305:
Suspicious coding ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114689
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114689
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114706
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=114635
--- Comment #16 from Jakub Jelinek ---
(In reply to Richard Biener from comment #14)
> I think
>
> if (safelen)
> {
> poly_uint64 val;
> safelen = OMP_CLAUSE_SAFELEN_EXPR (safelen);
> if (!poly_int_tree_p (safelen, ))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #13 from Jakub Jelinek ---
(In reply to kugan from comment #12)
> > Why?
> > Then it just is INT_MAX value, which is a magic value that says that it is
> > infinity.
> > No need to say it is a poly_int infinity.
>
> For this test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #11 from Jakub Jelinek ---
(In reply to kugan from comment #9)
> Looking at the options, looks to me that making loop->safelen a poly_in is
> the way to go. (In reply to Jakub Jelinek from comment #4)
> > The OpenMP safelen clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #18 from Jakub Jelinek ---
(In reply to Hu Lin from comment #17)
> (In reply to Jakub Jelinek from comment #16)
> > (In reply to Hu Lin from comment #11)
> > > I think it doesn't mean that's not a bug with -ftrapv, it should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114689
--- Comment #5 from Jakub Jelinek ---
And does
extern void g( int);
void f( int mant, int sticky)
{
mant = mant >> 1 ;
mant = mant >> 1 | (mant & 1);
mant = mant >> 1 | (mant & 1) | (!!sticky);
mant = !!sticky;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114691
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression] Bogus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
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=114574
--- Comment #27 from Jakub Jelinek ---
(In reply to uecker from comment #26)
> Note that not updating the types seems wrong also pre C23. PR114493 could be
> an example of this:
>
> typedef struct a a;
> int c;
> int f(a **);
> struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114634
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=114574
--- Comment #25 from Jakub Jelinek ---
Created attachment 57935
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57935=edit
gcc14-pr114574.patch
What about this patch then? So far just make check-gcc -j32 checked (though in
a version that
||jakub at gcc dot gnu.org
Priority|P1 |P2
--- Comment #3 from Jakub Jelinek ---
Started with r9-1745-gbffc62707f731f20ded6993e734a361945684955
I don't think 5+ years old ice-on-invalid-code should be P1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621
Jakub Jelinek changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #6 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #16 from Jakub Jelinek ---
(In reply to Hu Lin from comment #11)
> I think it doesn't mean that's not a bug with -ftrapv, it should preserve
> all overflow traps. Because it doesn't work, we use -fsanitize=undefined
> instead of it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114689
--- Comment #3 from Jakub Jelinek ---
But guess that won't shut up cppcheck, I'd think it wants | (!!sticky) instead
of
| !!sticky. Haven't tried though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
--- Comment #11 from Jakub Jelinek ---
Actually I had another look.
Jason said in the c++: fix in-charge parm in constexpr mail back in December
(as well as in the r14-6507 commit message):
"Since a class with vbases can't have constexpr 'tors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114687
Jakub Jelinek changed:
What|Removed |Added
Summary|[13/14 Regression] ICE: in |[13 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114689
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Created attachment 57929
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57929=edit
gcc14-pr114687.patch
Untested fix. The tree-cfg.cc verification that ECF_RETURNS_TWICE call is
the first in bb app
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114687
--- Comment #2 from Jakub Jelinek ---
Saying a function is valid code in this case is difficult, claiming that a
noreturn function is pure or returns_twice is wrong, it isn't pure, nor
returns_twice, as it never returns.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #10 from Jakub Jelinek ---
I admit I haven't studied what exactly pytorch does there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #9 from Jakub Jelinek ---
It depends on what the vec_xl*/vec_xst* documentation requires/user expect.
If the expectation is that the loads/stores should alias the scalar pointee of
the pointer type passed to those intrinsics, then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #8 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to Jonathan Wakely from comment #4)
> > This were added by r13-7320-g0d5a359140503d which is in 13.2 :-(
>
> Oops, guess too late then for those.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #7 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #4)
> This were added by r13-7320-g0d5a359140503d which is in 13.2 :-(
Oops, guess too late then for those. We'll need to consider 13.2 as a fuzzy
snapshot in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #3 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #1)
> --- a/libstdc++-v3/config/abi/pre/gnu.ver
> +++ b/libstdc++-v3/config/abi/pre/gnu.ver
> @@ -2521,9 +2521,12 @@ GLIBCXX_3.4.31 {
> GLIBCXX_3.4.32 {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #2 from Jakub Jelinek ---
Created attachment 57927
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57927=edit
gcc14-libstdc++-baseline-updates.patch
This was what I've been preparing before noticing this issue. If we change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |14.0
CC|
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
I was just updating libstdc++ baseline_symbols.txt files from latest Fedora,
but seems we have a major issue.
While
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114691
Bug 114691 depends on bug 114409, which changed state.
Bug 114409 Summary: [14 Regression] ICE after adding novector pragmas (internal
compiler error: in tsubst_expr, at cp/pt.cc:21794) since
r14-4229-g9c62af101e11e1cce573c2b3d2e18b403412dbc8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
--- Comment #18 from Jakub Jelinek ---
The P1 bug has been fixed, I've moved the rest to PR114691.
|P2
Ever confirmed|0 |1
Last reconfirmed||2024-04-11
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Target Milestone|--- |11.5
--- Comment #1 from Jakub
-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jason at gcc dot gnu.org,
pinskia at gcc dot gnu.org, ppalka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #20 from Jakub Jelinek ---
(In reply to Hongtao Liu from comment #19)
> (In reply to Jakub Jelinek from comment #17)
> > Both of the posted patches are incorrect, this needs to be fixed in
> > asan_emit_stack_protection, account for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #28 from Jakub Jelinek ---
As long as the scale is a power of two or 1.0 / power of two, I don't see why
any version wouldn't be inaccurate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #58 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #57)
> (In reply to Richard Biener from comment #56)
> > The fix was reverted but will be re-instantiated for GCC 15 by me.
>
> And I still protest.
>
>
,
||jakub at gcc dot gnu.org,
||krebbel at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #1)
> /* Build a vector type with the alignment of the tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #24 from Jakub Jelinek ---
As documented in
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-special-ctor-dtor
C2 is base object constructor (C1 is complete object constructor, C3 is
allocating complete constructor).
C5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
--- Comment #16 from Jakub Jelinek ---
Created attachment 57918
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57918=edit
gcc14-pr114409-2.patch
Another possible untested fix.
at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #15 from Jakub Jelinek ---
Created attachment 57917
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57917=edit
gcc14-pr114409-1.patch
One possible untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
--- Comment #14 from Jakub Jelinek ---
I had another look at this.
The reason why this works without the pragmas (i.e. without ANNOTATE_EXPRs) is
that
the WHILE_COND/FOR_COND are handled not by tsubst_expr but tsubst_stmt:
case FOR_STMT:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #18 from Jakub Jelinek ---
Created attachment 57915
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57915=edit
gcc14-pr110027.patch
So far lightly tested patch (make check-gcc check-g++ RUNTESTFLAGS=asan.exp on
x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
Bug 94404 depends on bug 114462, which changed state.
Bug 114462 Summary: [C++26] P2809R3 - Trivial infinite loops are not undefined
behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114462
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114462
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338
Bug 110338 depends on bug 114462, which changed state.
Bug 114462 Summary: [C++26] P2809R3 - Trivial infinite loops are not undefined
behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114462
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
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=114660
--- Comment #4 from Jakub Jelinek ---
I think we've been discussing an idea of turning on flag_wrapv very late among
the GIMPLE passes and reassociate again. Because RTL also kind of assumes
flag_wrapv, there is no difference between
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114658
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114656
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114657
--- Comment #2 from Jakub Jelinek ---
In particular, 6.5.1.1/2 says
"The type of the controlling expression is the type of the expression as if it
had undergone an lvalue conversion, array to pointer conversion, or function to
pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114657
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114472
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52534
--- Comment #5 from Jakub Jelinek ---
Note, if we warn, we shouldn't warn for C23 or later, because one can pass
anything there, like 3 arguments, or that (unsigned int)n_args, or just one,
etc. And __builtin_va_start (ap, 0) is what is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114576
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114580
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114628
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621
--- Comment #5 from Jakub Jelinek ---
While for the local exec we happily use something like
movq%fs:0, %rax
movabsq $b@tpoff+34359738367, %rdx
addq%rdx, %rax
movzbl (%rax), %eax
we normally use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621
--- Comment #4 from Jakub Jelinek ---
char a;
__thread char b[0x8L];
int
foo (void)
{
return b[0x7L];
}
ICEs similarly with -O0 -fpie.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
Jakub Jelinek changed:
What|Removed |Added
Summary|[13/14 Regression] LTO |[13 Regression] LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114605
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114628
--- Comment #3 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #1)
> Note we get 2 difference ICEs depending on if `#if ` is 1 or 0.
> It seems like it would be useful if some more torture tests for _BitInt were
> included so
at gcc dot gnu.org |jakub at gcc dot gnu.org
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Created attachment 57903
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57903=edit
gcc14-pr114628.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #5 from Jakub Jelinek ---
(In reply to Richard Biener from comment #3)
> As for the dependence analysis itself - the issue is that the D.5606[_33]
> style accesses have no access functions - I'm not sure how they evolve,
> but I see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #4 from Jakub Jelinek ---
The OpenMP safelen clause argument is a scalar integer, so using poly_int for
something that must be an int doesn't make sense.
Though, the above testcase actually doesn't use safelen clause, so safelen is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114623
--- Comment #7 from Jakub Jelinek ---
Created attachment 57900
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57900=edit
gcc14-pr114623.patch
Anyway, here is an untested patch to use soft-fp implementation for sqrtq for
the positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114623
--- Comment #6 from Jakub Jelinek ---
(In reply to g.peterhoff from comment #4)
> That is precisely the design error of C/C++/etc. There should be no
> float/double/long double/__float128/etc, but *only* floatN_t.
If you don't want to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114623
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621
Jakub Jelinek changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87299
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112723
--- Comment #7 from Jakub Jelinek ---
Ah, with -fwrapv. Without -fwrapv the testcase invokes UB always, either the
first c + c overflows or the second one, or the c += -2147483647 - 1;
overflows.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112723
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114605
--- Comment #2 from Jakub Jelinek ---
Created attachment 57889
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57889=edit
gcc14-pr114605.patch
Untested fix.
|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
This is a clear bug in s390_const_int_pool_entry_p. It just uses
get_pool_constant but ignores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114605
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |14.0
Priority|P3
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Since r14-5831-gaae723d360ca26cd9fd0b039fb0a616bd0eae363 we miscompile the
following testcase on s390x-linux with -O0 -march=z13:
typedef
|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #16 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #15)
> (In reply to Jakub Jelinek from comment #14)
> > Marking for 14 as well because I believe the trunk commit just made it
> > latent there rather than fixed.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #22 from Jakub Jelinek ---
BTW, wonder if it wouldn't be desirable to revert the PR114361 patch until this
is sorted out, or at least limit the effects of that patch to flag_isoc23 and
using multiple types with the same tag and same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #21 from Jakub Jelinek ---
Why? That is already set by
TYPE_CANONICAL (t) = *e;
else
{
TYPE_CANONICAL (t) = t;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #19 from Jakub Jelinek ---
(In reply to Martin Uecker from comment #18)
> I am just looking at a version that would have changed the condition to:
>
> if (TYPE_MODE (t) == mode && TYPE_REF_CAN_ALIAS_ALL (t) == can_alias_all
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #17 from Jakub Jelinek ---
Some comments:
+ else
+{
+ TYPE_CANONICAL (t) = t;
+}
The formatting here is wrong, TYPE_CANONICAL is indented too much, but we also
don't put a single statement between {}s, so just
else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
Jakub Jelinek changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
1 - 100 of 42459 matches
Mail list logo
