https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114767
Bug ID: 114767
Summary: gfortran AVX2 complex multiplication by (0d0,1d0)
suboptimal
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114767
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #30 from Martin Uecker ---
Am Donnerstag, dem 18.04.2024 um 11:57 + schrieb jakub at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
>
> --- Comment #29 from Jakub Jelinek ---
> (In reply to uecker from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113706
--- Comment #11 from GCC Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:cc02ebfcfd0755b330c50a840ab713fedd6d8887
commit r14-10023-gcc02ebfcfd0755b330c50a840ab713fedd6d8887
Author: Alexandre Oliva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768
Bug ID: 114768
Summary: Volatile reads can be optimized away
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
--- Comment #9 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:a2f4be3dae04fa8606d1cc8451f0b9d450f7e6e6
commit r14-10014-ga2f4be3dae04fa8606d1cc8451f0b9d450f7e6e6
Author: Tamar Christina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768
--- Comment #2 from Jakub Jelinek ---
--- gcc/rtlanal.cc.jj 2024-02-24 12:45:28.674249100 +0100
+++ gcc/rtlanal.cc 2024-04-18 15:09:55.199499083 +0200
@@ -1637,12 +1637,15 @@ set_noop_p (const_rtx set)
return true;
if (MEM_P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114762
--- Comment #1 from Zdenek Sojka ---
Created attachment 57981
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57981=edit
testcase trying reasonable input for division (and multiplication)
This can be used to test various input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-04-18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114769
Bug ID: 114769
Summary: Suspicious code in vect_recog_sad_pattern()
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291
Jeffrey A. Law changed:
What|Removed |Added
Priority|P1 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768
--- Comment #6 from Segher Boessenkool ---
Heh, crossed :-) I can confirm my patch works (tested and everything). I have
no idea about zero_extract, which is a blight that should be eradicated tooth
and
nail!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114761
--- Comment #5 from Alexander Zaitsev ---
> Is this based on real code or you just was looking at the differences between
> gcc and clang here?
Really, not on a real code. I came up with this example when I found that GCC
for this example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #29 from Jakub Jelinek ---
(In reply to uecker from comment #28)
> I do not fully understand yet what happens for may_alias, but it if we later
> complete the struct with the may_alias attribute it seems we would also need
> to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114766
Bug ID: 114766
Summary: ^ constraint modifier unexpectedly affects register
class selection.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768
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=114767
--- Comment #2 from mjr19 at cam dot ac.uk ---
Ah, I see. An inability to alternate negation with noop also means that
conjugation is treated suboptimally.
do i=1,n
c(i)=conjg(c(i))
enddo
Here gfortran-13 and -14 are differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #15 from Aleksei Nikiforov
---
I think fixing compiled code should be possible. I'm not sure if this bug
should be just closed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114765
--- Comment #2 from Stijn De Weirdt ---
hi jakub,
apologies for my ignorance, but how is working as expected? i can't make this
up from the description of the variable; and it's unexpected since there is no
openmp code being run (naively then;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768
--- Comment #1 from Richard Biener ---
It's the combine pass that removes the seemingly noop-move.
For QOI reasons GCC preserves volatile accesses elsewhere even when
inconsistency is directly visible like here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114765
--- Comment #6 from Jakub Jelinek ---
(In reply to Alexander Monakov from comment #5)
> Can libgomp defer changing affinity of the initial thread to the launch of
> the first parallel region (i.e. change it only at thread pool
> initialization,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764
Bug ID: 114764
Summary: noexcept on a friend complains about incomplete type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114762
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114765
--- Comment #1 from Jakub Jelinek ---
That is how it should behave. Don't use OMP_PROC_BIND=true unless that is what
you want...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #11 from Jeffrey A. Law ---
Yup. -fsched-verbose=99 is *very* verbose. But that's the point, to see all
the gory details. It can be dialed down, but I've never done so myself.
What stands out to me is this:
;;| Pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114513
Bug 114513 depends on bug 114741, which changed state.
Bug 114741 Summary: [14 regression] aarch64 sve: unnecessary fmov for scalar
int bit operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114765
Bug ID: 114765
Summary: linking to libgomp and setting CPU_PROC_BIND causes
affinity reset
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114765
--- Comment #3 from Jakub Jelinek ---
(In reply to Stijn De Weirdt from comment #2)
> apologies for my ignorance, but how is working as expected? i can't make
> this up from the description of the variable; and it's unexpected since
> there is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114765
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114765
--- Comment #4 from Stijn De Weirdt ---
hi jakub,
thanks for the explanation. so if i understand this, the main thread/process of
any binary linked with libgomp becomes an OpenMP thread, because of the libgomp
constructor doing something. and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114765
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764
--- Comment #1 from Andrew Pinski ---
EDG also accepts it ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114774
Bug ID: 114774
Summary: Missed DSE in simple code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764
--- Comment #3 from Giuseppe D'Angelo ---
I guess you're referring to https://lists.isocpp.org/core/2019/07/6785.php ?
I'm really not sure why a friend function declaration is different from a free
function, where multiple equivalent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114774
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114773
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114772
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114770
Bug ID: 114770
Summary: std::chrono::locate_zone("Asia/Chungking") fails on
Debian Sid
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114772
Bug ID: 114772
Summary: pragma GCC target applied to earlier template function
with __attribute__((warn_unused_result))
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113625
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114739
--- Comment #7 from GCC Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:e243d0feafa533141ef7e23820d5cc60cf33204a
commit r14-10030-ge243d0feafa533141ef7e23820d5cc60cf33204a
Author: Paul Thomas
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114767
--- Comment #5 from Roger Sayle ---
Another interesting (simpler) case of -ffast-math pessimization is:
void foo(_Complex double *c)
{
for (int i=0; i<16; i++)
c[i] += __builtin_complex(1.0,0.0);
}
Again without -ffast-math we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114773
--- Comment #2 from Sirraide ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113317
Thomas Schwinge changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #58 from GCC Commits ---
The releases/gcc-12 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:ab4ff3e9fe881ef85a8156f2be528872c6a2fdfc
commit r12-10336-gab4ff3e9fe881ef85a8156f2be528872c6a2fdfc
Author: Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114770
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114767
--- Comment #4 from mjr19 at cam dot ac.uk ---
An issue which I suspect is related is shown by
subroutine zradd(c,n)
integer :: i,n
complex(kind(1d0)) :: c(*)
do i=1,n
c(i)=c(i)+1d0
enddo
end subroutine
If compiled with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114771
Bug ID: 114771
Summary: GCC accepts invalid overloading of member function
differing only in ref qualifier
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114773
--- Comment #4 from Sirraide ---
Yeah, we figured that that was why they’re not supported in `-gnu89` mode, but
I thought I’d ask just to be sure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114738
Jakub Jelinek changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #6 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114771
--- Comment #1 from Andrew Pinski ---
EDG also accepts this. so 3 out of 4 compilers out accept it. Maybe there is a
defect report ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114767
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114773
Bug ID: 114773
Summary: Raw string literals are not supported in C89 mode
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114773
--- Comment #1 from Andrew Pinski ---
https://gcc.gnu.org/gcc-4.5/changes.html
Looks like it is on purpose:
C++0x raw strings are supported for C++ and for C with -std=gnu99.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114774
Jan Hubicka changed:
What|Removed |Added
Summary|Missed DSE in simple code |Missed DSE in simple code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775
--- Comment #7 from Nikita Kniazev ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Nikita Kniazev from comment #5)
> > > So there is mingw_printf and gnu_printf attributes for mingw because at
> > > one point %ll didn't exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775
--- Comment #10 from Andrew Pinski ---
(In reply to Nikita Kniazev from comment #9)
> Ok, is there at least an option to build GCC so it defaults __printf__ to
> gnu_printf? Defaulting __printf__ to ms_printf on UCRT is wrong (every OS
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114776
--- Comment #2 from Andrew Pinski ---
As far as I can tell g_assertion_message does not have noreturn on it which
means this invalid.
It only has G_ANALYZER_NORETURN on it.
which is only defined to analyzer_noreturn if running under clang's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114777
Bug ID: 114777
Summary: inconsistent warning for pure functions on
deconstructors/constructors on arm compared to other
targets
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114777
--- Comment #1 from Andrew Pinski ---
Note we only started to warn about pure/const on functions returning void in
GCC 8 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> So there is mingw_printf and gnu_printf attributes for mingw because at one
> point %ll didn't exist for mingw and nobody has updated it since then.
Sorry I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290
--- Comment #33 from Andrew Pinski ---
(In reply to Marc Glisse from comment #6)
> I assume it would help with this?
Note that was fixed outside of phiopt in GCC 11 by r11-6609-g13d47c37a2c043 (PR
95731).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775
--- Comment #3 from Andrew Pinski ---
If anything gnu_printf should be used instead for _bfd_error_handler and that
would be a binutils issue and reported there ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775
--- Comment #6 from Andrew Pinski ---
(In reply to Nikita Kniazev from comment #5)
> > So there is mingw_printf and gnu_printf attributes for mingw because at one
> > point %ll didn't exist for mingw and nobody has updated it since then.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775
--- Comment #9 from Nikita Kniazev ---
Ok, is there at least an option to build GCC so it defaults __printf__ to
gnu_printf? Defaulting __printf__ to ms_printf on UCRT is wrong (every OS
without UCRT is already EOL).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101345
--- Comment #2 from Peter Bergner ---
(In reply to Peter Bergner from comment #1)
> Jeevitha, can you please do a git bisect from the two commits above to
> identify the commit that fixes this for posterity sake? Thanks.
I'll note I used -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775
Bug ID: 114775
Summary: on mingw __attribute__ ((__format__ (__printf__,
...))) doesn't recognize C99 specifiers
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775
--- Comment #8 from Andrew Pinski ---
(In reply to Nikita Kniazev from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > (In reply to Nikita Kniazev from comment #5)
> > > > So there is mingw_printf and gnu_printf attributes for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114776
--- Comment #3 from Andrew Pinski ---
Seems like g_assertion_message should have _Noreturn on it if you are compiling
for C11-C17 and [[noreturn]] for C++11+ (and C23+).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764
--- Comment #4 from Marek Polacek ---
I don't think so, it's the same problem. You could have
struct S {
friend void f() noexcept(noexcept(a));
friend void f() noexcept(noexcept(b)) { }
int a;
int b;
};
and we'd have to track if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775
--- Comment #5 from Nikita Kniazev ---
> So there is mingw_printf and gnu_printf attributes for mingw because at one
> point %ll didn't exist for mingw and nobody has updated it since then.
Do you mean that binutils and [other code out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114776
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075
Bug 104075 depends on bug 114776, which changed state.
Bug 114776 Summary: -Wuse-after-free analysis believes assert() but not
g_assert_null()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114776
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114776
--- Comment #6 from Alan Coopersmith ---
Thanks, I didn't realize there was a test_nonfatal_assertions path through
the g_assert that could return here.
I'll update the wording on my proposed workaround to reflect that:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19661
--- Comment #19 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #18)
> Created attachment 57987 [details]
> Patch which I will be submitting once GCC 15 stage 1 opens up
I forgot to add the testcase from comment #12. the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103471
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=101345
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114776
Bug ID: 114776
Summary: -Wuse-after-free analysis believes assert() but not
g_assert_null()
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114776
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114776
--- Comment #5 from Alan Coopersmith ---
Created attachment 57986
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57986=edit
Preproccessed test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19661
--- Comment #18 from Andrew Pinski ---
Created attachment 57987
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57987=edit
Patch which I will be submitting once GCC 15 stage 1 opens up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114778
Bug ID: 114778
Summary: ICE: internal compiler error: in get_region_for_local,
at analyzer/region.cc:1366
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775
--- Comment #12 from Andrew Pinski ---
(In reply to Nikita Kniazev from comment #11)
> -mcrtdll=ucrt should make __printf__ be gnu_printf instead of ms_printf.
> Should I file separate issue or this one can be reopened?
The reality is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #24 from LIU Hao ---
(In reply to Andrew Pinski from comment #23)
> Note since MSVC 2015 runtime, printf has support %ll so ms_printf should be
> fixed to incldue that.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114735
--- Comment #7 from Gejoe ---
Thanks Andrew.
It would be better to document this change post gcc11 apart from a sample
example as generally it is understood that --coverage flag is enough for gcc to
get coverage enabled build done and then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775
Nikita Kniazev changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #23 from Andrew Pinski ---
Note since MSVC 2015 runtime, printf has support %ll so ms_printf should be
fixed to incldue that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114735
--- Comment #8 from Andrew Pinski ---
I will try to add something to https://gcc.gnu.org/gcc-11/porting_to.html in
the next few weeks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114769
Richard Biener changed:
What|Removed |Added
Summary|Suspicious code in |[14 Regression] Suspicious
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775
--- Comment #13 from Nikita Kniazev ---
(In reply to Andrew Pinski from comment #12)
> The reality is ms_printf most likely should just include z and ll support
> instead since they are supported now:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114735
--- Comment #9 from Gejoe ---
Thank you Andrew.
Meanwhile any idea if the support person is on leave for this query :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751;
Thanks again.
-Gejoe
From: pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114763
--- Comment #1 from Andrew Pinski ---
Note only the second case has if's 2 sides which are the same;
it is basically `a ? b : (c ? d : d)`.
While the first case you have `a ? b : (c ? d : b)` which is not supposed to
warn about at all because
1 - 100 of 112 matches
Mail list logo
