https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108738
Bug ID: 108738
Summary: compile-time and memory-hog in mdreorg
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108739
Bug ID: 108739
Summary: GCC Static Analyzer evaluates `a > b `to be TRUE but
evaluates `b < a` to be UNKNOWN
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108734
--- Comment #4 from Jonathan Wakely ---
What are you actually trying to do here?
If you're trying to provide your own definitions for the atomic built-ins then
obviously you need to know platform-specific details, including whether that
operati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108698
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b1ed0c9671b99c6b06cbb8c61be14cdec0998de8
commit r13-5751-gb1ed0c9671b99c6b06cbb8c61be14cdec0998de8
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108698
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #149 from Richard Biener ---
(In reply to Richard Biener from comment #148)
> (In reply to lucier from comment #145)
> > Created attachment 54424 [details]
> > CPU and Memory usage reports for mainline 13.0.1 (mainline)
> >
> > Thank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108738
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
--- Comment #1 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77760
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77760
--- Comment #4 from Jakub Jelinek ---
(In reply to Alexandre Oliva from comment #3)
> I'm looking at a case in which __clang__ is defined, despite compiling with
> GCC, and "%I...%p" parsing fails because the hack to pass state around
> doesn't w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108738
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-02-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108738
--- Comment #3 from Richard Biener ---
That brings it down to
machine dep reorg : 87.09 ( 28%)
let me see if there's something else obvious to do.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108724
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108430
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
--- Comment #8 from Martin Liška ---
(In reply to Richard Biener from comment #7)
> -fno-move-loop-stores disables the store motion.
Ok, so I can confirm both -fno-move-loop-stores or -fprofile-update=atomic lead
to properly collected numbers w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108603
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-02-09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
--- Comment #13 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:1189d1b38e2b9507488ea294cda771c79e972c1d
commit r13-5755-g1189d1b38e2b9507488ea294cda771c79e972c1d
Author: Martin Liska
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108740
Bug ID: 108740
Summary: two identical functions but the code generated
differs. Why?
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105383
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108740
--- Comment #1 from Piotr ---
-fno-ipa-icf makes it identical.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105438
--- Comment #11 from Martin Liška ---
(In reply to Bernie Innocenti from comment #10)
> Still present on GCC 12.2.
>
> Could someone look into it please, or point me at the point in ipa-icf.cc
> where the array-bounds analysis information shoul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108470
--- Comment #2 from Martin Liška ---
Apparently, we support 'noipa' attribute for more than 5 years and so it should
be used rather than noiline attribute. Or do you need to support an older
toolchain as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
--- Comment #15 from Martin Liška ---
Your patch might work.
> In fact, I wonder why get_available_features isn't called unconditionally
Yes, I would also expect that, but it was not the case even before the big
refactoring in g:1890f2f0e210ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554
--- Comment #11 from Martin Liška ---
>
> Well, most definitely the new decls target options need to be
> instantiated?
Then it must be a tree pass that will properly call set_current_function :/ The
multiple_target pass is an IPA pass. Can w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108470
--- Comment #3 from Richard Earnshaw ---
The manual entry for this says "This attribute is supported mainly for the
purpose
of testing the compiler." which suggests a lack of long-term commitment to the
option. Perhaps it would be better to rem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108599
--- Comment #10 from Henning Baldersheim ---
Will this be backported to gcc-12, or do we need to wait for gcc-13 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108599
--- Comment #11 from Jakub Jelinek ---
At some point yes, don't know when exactly. Will need to collect several
dozens of backports and test them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
--- Comment #16 from Jakub Jelinek ---
(In reply to Erich Eckner from comment #4)
> Created attachment 50871 [details]
> cpuid probing
>
> Does the attached program yield, what you need? (Sry, I'm quite unfamiliar
> with asm in gcc)
>
> It giv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108741
Bug ID: 108741
Summary: [OpenMP] Wrong code for lastprivate with pointer
iteration variable
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108741
--- Comment #1 from Jakub Jelinek ---
#pragma omp simd collapse(2) lastprivate(a0,a1,j)
for (a0 = 1; a0 <= 10; a0++)
for (j = 1; j <= 20; j++)
**a1 = a0;/// Segfaults here as *a0 points to invalid memory
You mean *a1. That tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108470
--- Comment #4 from Martin Liška ---
Yes, noipa attribute is there for some time and I think we commit to support it
in the future.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108738
--- Comment #4 from Richard Biener ---
The odd thing is that DF_REF_CHAIN of a USE ref contains _all_ definitions of
the pseudo while DF_REF_CHAIN of a DEF ref contains only reaching uses!?
Probably an artifact of how df_chain_create_bb_process
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554
--- Comment #12 from Richard Biener ---
(In reply to Martin Liška from comment #11)
> >
> > Well, most definitely the new decls target options need to be
> > instantiated?
>
> Then it must be a tree pass that will properly call set_current_fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108679
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108481
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108705
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108707
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108723
Richard Biener changed:
What|Removed |Added
Target||riscv
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108724
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108705
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108737
Richard Biener changed:
What|Removed |Added
Summary|Apparent miscompile of |[13 Regression] Apparent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108740
Richard Biener changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108741
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108741
Tobias Burnus changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101073
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108679
--- Comment #3 from Martin Jambor ---
What happens is that ipa_param_body_adjustments::modify_call_stmt
is confused by the IPA-CP produced scalar constant where it expects a
structure containing just one field of the corresponding type.
It is e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108737
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108737
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107424
--- Comment #11 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:ac2949574da9a668daad421d7edb79f172f73c6f
commit r13-5756-gac2949574da9a668daad421d7edb79f172f73c6f
Author: Tobias Burnus
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107424
--- Comment #12 from Tobias Burnus ---
Still to be done:
Handle loop steps other than ±1. For a suggestion how it could be handled, see
thread ending with the following email, which is possibly sufficient
https://gcc.gnu.org/pipermail/gcc-pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108631
Arthur Cohen changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #64 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:44f308e59bfa0f93ae05b17e257d8563c12399fd
commit r13-5757-g44f308e59bfa0f93ae05b17e257d8563c12399fd
Author: Andrew Pinski
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108688
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:44f308e59bfa0f93ae05b17e257d8563c12399fd
commit r13-5757-g44f308e59bfa0f93ae05b17e257d8563c12399fd
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718
--- Comment #4 from David Binderman ---
(In reply to Andrew Pinski from comment #3)
> This also changes with -fno-strict-aliasing ...
So does that mean that csmith is producing C code with UB and so
this bug isn't valid ?
It might also mean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108688
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:bcca64d70ce91e29717fb70cff252639df6902be
commit r13-5758-gbcca64d70ce91e29717fb70cff252639df6902be
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108688
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108631
--- Comment #3 from Martin Liška ---
(In reply to Arthur Cohen from comment #2)
> Patch looks good to me Martin, thank you. Will you push it directly?
Do you see reasonable allocations when you run -fmem-report w/
--enable-gather-detailed-mem-s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108684
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #12 from Andrew
c/gfortran -Bgcc/ -v -O2 -ftime-report -c hog.f90
Reading specs from gcc/specs
COLLECT_GCC=./gcc/gfortran
Target: x86_64-pc-linux-gnu
Configured with: /zzz/gg/configure --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230209 (experime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
Bug ID: 108742
Summary: Incorrect constant folding with (or exposed by)
-fexcess-precision=standard
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108687
--- Comment #5 from Andrew Macleod ---
My cross compiler doesn't seem to exhibit this behaviour. It simply compiles
this as a quite short program.
It looks like it in the DOM pass.. could you try it with:
-fdump-tree-all-detail --param=ranger
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108705
--- Comment #5 from Andrew Macleod ---
Whats even odder... https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108687
Thats a s390 bug that is spending forever in one of the DOM passes as well...
and I cannot seem to reproduce it either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
--- Comment #2 from Jakub Jelinek ---
Note, internally in standard excess precision, 4.2 seen by the lexer is
actually
EXCESS_PRECISION , when it is assigned to a double variable or
cast
to double (i.e. in places where C/C++ require the excess p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108740
--- Comment #3 from Piotr ---
(In reply to Richard Biener from comment #2)
> Hmm, ICF + re-inlining makes it ignore some of the pointless volatile dance?
why the code is different abstracting form the sense of the assignment?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
--- Comment #3 from Michael Matz ---
(In reply to Jakub Jelinek from comment #2)
> Note, internally in standard excess precision, 4.2 seen by the lexer is
> actually
> EXCESS_PRECISION ,
Then _that_ is the problem. The literal "4.2" simply is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
--- Comment #17 from Erich Eckner ---
With that, I get a segfault in cpuid():
(gdb) run
Starting program: /tmp/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
Program received sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
--- Comment #4 from Jakub Jelinek ---
See https://gcc.gnu.org/legacy-ml/gcc-patches/2008-11/msg00105.html for
details.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
--- Comment #5 from Jakub Jelinek ---
https://eel.is/c++draft/cfloat.syn points to the C standard for FLT_EVAL_METHOD
(plus https://eel.is/c++draft/expr#pre-6 talks about excess precision too) and
e.g. C17
5.2.4.2.2/9):
"2 evaluate all operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
--- Comment #6 from Jakub Jelinek ---
(In reply to Michael Matz from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > Note, internally in standard excess precision, 4.2 seen by the lexer is
> > actually
> > EXCESS_PRECISION ,
>
> T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743
Bug ID: 108743
Summary: -fconstant-cfstrings not supported
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
--- Comment #18 from Jakub Jelinek ---
(In reply to Erich Eckner from comment #17)
> With that, I get a segfault in cpuid():
>
> (gdb) run
> Starting program: /tmp/a.out
> [Thread debugging using libthread_db enabled]
> Using host libthread_db
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743
--- Comment #1 from Andrew Pinski ---
The option is -mconstant-cfstrings, the documentation is slightly wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743
--- Comment #2 from Pierre Ossman ---
Great news. And that is the same thing as clang's -fconstant-cfstrings?
Unfortunately, I couldn't see -mconstant-cfstrings in gcc's documentation, but
I may be looking in the wrong place.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
--- Comment #19 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b24e9c083093a9e1b1007933a184c02f7ff058db
commit r13-5759-gb24e9c083093a9e1b1007933a184c02f7ff058db
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743
--- Comment #3 from Andrew Pinski ---
(In reply to Pierre Ossman from comment #2)
> Great news. And that is the same thing as clang's -fconstant-cfstrings?
yes
>
> Unfortunately, I couldn't see -mconstant-cfstrings in gcc's documentation,
> b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
--- Comment #7 from Michael Matz ---
(In reply to Jakub Jelinek from comment #5)
> https://eel.is/c++draft/cfloat.syn points to the C standard for
> FLT_EVAL_METHOD
> (plus https://eel.is/c++draft/expr#pre-6 talks about excess precision too)
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
--- Comment #8 from Michael Matz ---
(In reply to Michael Matz from comment #7)
> So, my interpretation is that unsuffixed "4.2" has to be the double constant
> 4.2 (in IEEE double aka 0x1.0cccdp+2), which is then, because of
> FLT_EVAL_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
--- Comment #9 from Jakub Jelinek ---
(In reply to Michael Matz from comment #7)
> (In reply to Jakub Jelinek from comment #5)
> > https://eel.is/c++draft/cfloat.syn points to the C standard for
> > FLT_EVAL_METHOD
> > (plus https://eel.is/c++dr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
--- Comment #10 from Michael Matz ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to Michael Matz from comment #7)
> > (In reply to Jakub Jelinek from comment #5)
> > > https://eel.is/c++draft/cfloat.syn points to the C standard for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
--- Comment #11 from joseph at codesourcery dot com ---
As discussed, FLT_EVAL_METHOD applies to constants as well as to
operations. See the example in C17 F.8.5, for example; it shows
float y = 1.1e75f; // may raise exceptions
since 1.1e75f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108744
Bug ID: 108744
Summary: error message when trying to use structured bindings
in static member declaration could be cleaner
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108744
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108734
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108744
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108740
--- Comment #4 from Andrew Pinski ---
(In reply to Piotr from comment #3)
> (In reply to Richard Biener from comment #2)
> > Hmm, ICF + re-inlining makes it ignore some of the pointless volatile dance?
>
> why the code is different abstracting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50677
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
Andrew Pinski changed:
What|Removed |Added
CC||marc.glisse at normalesup dot
org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105661
Bug 105661 depends on bug 50677, which changed state.
Bug 50677 Summary: volatile forces load into register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50677
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |---
Summary|weird behaviour wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108687
--- Comment #6 from Stefan Schulze Frielinghaus
---
Just to be sure: in the initial commit I missed adding -march=z13 and only
mentioned it in commit 2
I will come up with those logs and mail them to you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108744
--- Comment #3 from Barry Revzin ---
Yeah, they're banned in non-static data members also. But there, we just can't
have any "auto" non-static data members, whereas you can have "auto" static
data members (just not structured bindings).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108687
--- Comment #7 from Andrew Macleod ---
(In reply to Stefan Schulze Frielinghaus from comment #6)
> Just to be sure: in the initial commit I missed adding -march=z13 and only
> mentioned it in commit 2
>
> I will come up with those logs and mail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108736
Andrew Pinski changed:
What|Removed |Added
Summary|[concepts] multidimensional |[concepts] multidimensional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70817
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103779
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108745
Bug ID: 108745
Summary: -Wanalyzer-deref-before-check false positives seen in
ImageMagick due to checks in macros
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108687
--- Comment #8 from Stefan Schulze Frielinghaus
---
I came up with a cross compiler where I can reproduce it:
FROM fedora:37
RUN dnf -y upgrade \
&& dnf -y install 'dnf-command(builddep)' \
&& dnf -y builddep gcc \
&& dnf -y install binu
1 - 100 of 142 matches
Mail list logo
