https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99811
Andrew Pinski changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99811
Andrew Pinski changed:
What|Removed |Added
Known to work||11.1.0
Keywords|ice-on-valid-c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103706
--- Comment #2 from Arseny Solokha ---
So it's a duplicate of PR99811.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103341
Andrew Pinski changed:
What|Removed |Added
Summary|ICE type of variable|[10/11 Regression] ICE type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103706
--- Comment #3 from Andrew Pinski ---
(In reply to Arseny Solokha from comment #2)
> So it's a duplicate of PR99811.
it is a dup of bug 103341.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103706
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103341
Andrew Pinski changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99811
Andrew Pinski changed:
What|Removed |Added
Target Milestone|11.3|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103341
--- Comment #3 from Andrew Pinski ---
Reduced with an extra testcase from PR 103706:
template concept C = sizeof(T) == sizeof(int);
template inline constexpr C auto trait_v{1};
decltype(trait_v) t = 1;
template void g5() {
[]() -> C auto{ retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103702
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94414
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-12-14
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103702
Kewen Lin changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860
--- Comment #71 from David Binderman ---
(In reply to Martin Liška from comment #57)
> (In reply to David Binderman from comment #56)
> > (In reply to Martin Liška from comment #55)
> > > >
> > > > with line numbers please :)
> > >
> > > cat -n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860
--- Comment #72 from Martin Liška ---
You will manage, it's not rocket science.
So please, add break point at the place it triggers the ICE and do:
(gdb) p &ptr1->x_help_flag
(gdb) p &ptr2->x_help_flag
and then watch for the addresses it print
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103690
Martin Liška changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103691
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |12.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103692
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103693
Martin Liška changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103694
Martin Liška changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103695
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2021-12-14
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103703
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103704
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Summary|[12 Regression] I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103705
Martin Liška changed:
What|Removed |Added
Summary|ICE: tree check: expected |ICE: tree check: expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98737
Jakub Jelinek changed:
What|Removed |Added
Attachment #50058|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707
Bug ID: 103707
Summary: Stray "Array operands are incommensurate"
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707
--- Comment #1 from Thomas Koenig ---
This is with gcc 11, no time to further reduce / try with trunk right now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103708
Bug ID: 103708
Summary: [OpenMP][OMP 5.0/5.x] use_device_addr - array sections
not supported
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: openmp, r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86717
--- Comment #3 from Jonathan Wakely ---
The regression appeared somewhere after r152040 and before r152438, so probably
at r152318 "merge in cxx0x-lambdas-branch@152308"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103587
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e163dbbc4433e598cad7e6011b255d1d6ad93a3b
commit r12-5947-ge163dbbc4433e598cad7e6011b255d1d6ad93a3b
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103709
Bug ID: 103709
Summary: ICE: 'global_options' are modified in local context
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860
--- Comment #73 from Arseny Solokha ---
(In reply to Martin Liška from comment #67)
> (In reply to Arseny Solokha from comment #66)
> > Should I file my commend 38 as a separate PR, then?
>
> Yes, please.
Filed as PR103709.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92944
--- Comment #1 from Ed Catmur ---
This becomes problematic when N::Q is std::hash; we are encouraged not to
reopen namespace std but to specialize std::hash from the root namespace.
Example:
#include
template constexpr bool P = false;
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687
--- Comment #5 from Jakub Jelinek ---
On gcc110 (which is BE), I certainly can't reproduce the 3.cc failures you see.
All I see is (both -m32 and -m64):
+FAIL: 22_locale/time_get/get_time/char/2.cc execution test
+FAIL: 22_locale/time_get/get_ti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687
--- Comment #6 from Jakub Jelinek ---
Note, using %I without %p (or %P) in formats certainly looks like a bug, then
one can't figure out if it is am or pm time, 08:31:26 is just ambiguous.
And my patch changed also the parsing of 12 with %I, pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103587
Jakub Jelinek changed:
What|Removed |Added
Summary|[10/11/12 Regression] ICE |[10/11 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103699
--- Comment #10 from Petr ---
Well, the problem is, that when you compile it with "-fsanitize=undefined" - it
won't report any undefined behavior, and the function would return the expected
value.
I even tried to make everything constexpr - and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103699
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103699
--- Comment #12 from Petr ---
Is there a way to diagnose this? To tell GCC to report transformations that
basically cause wrong results returned?
In my code base, I have unaligned memory loads/stores abstracted, so I can
implement whatever comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103688
--- Comment #2 from CVS Commits ---
The releases/gcc-11 branch has been updated by Joel Hutton :
https://gcc.gnu.org/g:9a5b3c50e26c24814ede693600fb24e4c7b6c60c
commit r11-9382-g9a5b3c50e26c24814ede693600fb24e4c7b6c60c
Author: Joel Hutton
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103699
--- Comment #13 from Jakub Jelinek ---
There is -Wstrict-aliasing warning, with 3 different levels from most to least
aggressive, see gcc documentation. But that warns mostly on the casts rather
than when performing the invalid access. There a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103699
--- Comment #14 from Jakub Jelinek ---
And, if you want those loads to be valid, gcc has may_alias attribute.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103699
--- Comment #15 from Petr ---
Unfortunately GCC doesn't report any issues even with `-Wstrict-aliasing=1`.
BTW now I know I must use the may_alias attribute to my satisfaction, and this
is what I'm gonna do, however, from user perspective I'm n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103408
--- Comment #7 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:561414cdf8ef0d3c1e2da80b3c8aae56de745b1e
commit r12-5952-g561414cdf8ef0d3c1e2da80b3c8aae56de745b1e
Author: Patrick Palka
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103709
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103699
--- Comment #16 from Andrew Pinski ---
You might want to read
https://blog.regehr.org/archives/1307
https://developers.redhat.com/blog/2020/06/03/the-joys-and-perils-of-aliasing-in-c-and-c-part-2
https://developers.redhat.com/blog/2020/06/02/the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687
--- Comment #7 from Jakub Jelinek ---
Yet another option would be a new dg- directive (ideally something usable in
effective target expressions) that would invoke (ideally remote)
LC_ALL=$second_arg locale -k $first_arg
and try to match it again
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103699
--- Comment #17 from Petr ---
Guys thanks a lot for your feedback.
Is the may_alias annotation guaranteed to behave as expected in the future
versions of GCC too, or it's just too much UB that it's better to do unaligned
reads with memcpy?
Wha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103699
--- Comment #18 from Jakub Jelinek ---
Using memcpy is the portable way, and most compilers will optimize it
reasonably well.
For alignment assertions, you can use e.g. __builtin_assume_aligned builtin to
tell the compiler about the alignment gu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860
--- Comment #74 from David Binderman ---
(In reply to Martin Liška from comment #72)
> You will manage, it's not rocket science.
>
> So please, add break point at the place it triggers the ICE and do:
>
> (gdb) p &ptr1->x_help_flag
> (gdb) p &p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103704
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |12.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #23 from Tamar Christina ---
(In reply to Jan Hubicka from comment #20)
> With g:r12-5872-gf157c5362b4844f7676cae2aba81a4cf75bd68d5 we should no
> longer need -fno-inline-functions-called-once
Awesome! thanks!
I wonder if we can get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #24 from hubicka at kam dot mff.cuni.cz ---
> Awesome! thanks!
>
> I wonder if we can get rid of the final magic parameter too, we run with
> --param ipa-cp-unit-growth=80 too which seems to have no more effect on
> exchange, though s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103704
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=103687
--- Comment #8 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #5)
> Another one would be to use the C APIs to query it (setlocale and
> nl_langinfo).
That's what I've done in some other tests, to workaround differences in loca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687
--- Comment #9 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #7)
> Yet another option would be a new dg- directive (ideally something usable in
> effective target expressions) that would invoke (ideally remote)
> LC_ALL=$secon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99188
Nick Clifton changed:
What|Removed |Added
CC||nickc at gcc dot gnu.org
--- Comment #8 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #25 from Tamar Christina ---
(In reply to hubicka from comment #24)
> > Awesome! thanks!
> >
> > I wonder if we can get rid of the final magic parameter too, we run with
> > --param ipa-cp-unit-growth=80 too which seems to have no mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687
--- Comment #10 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Jakub Jelinek from comment #5)
> > Another one would be to use the C APIs to query it (setlocale and
> > nl_langinfo).
>
> That's what I've do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #26 from hubicka at kam dot mff.cuni.cz ---
> It's with LTO, I'll see if non-LTO has the same benefit. In terms of
> code-size
> it looks like it accounts for a 20% increase for binary size, but the hot
> function shrinks approx 6x.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103604
--- Comment #14 from Iain Buclaw ---
(In reply to YunQiang Su from comment #13)
> And please have a wait, I need to make sure that this patch can work with
> N32.
So on gcc230, what I see is:
| C | D |
32 | 144 | 160 |
o64 | 160 | 148
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99531
--- Comment #6 from CVS Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:973f6aedeb6489a9fdc7aeceaed0514348ee1e1a
commit r12-5957-g973f6aedeb6489a9fdc7aeceaed0514348ee1e1a
Author: Vladimir N. Makarov
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103604
--- Comment #15 from Iain Buclaw ---
Created attachment 51999
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51999&action=edit
mips stat_t patch
Patch matches field declarations I can see in the headers, and it for sure
reigns it in.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #27 from Tamar Christina ---
(In reply to hubicka from comment #26)
> > It's with LTO, I'll see if non-LTO has the same benefit. In terms of
> > code-size
> > it looks like it accounts for a 20% increase for binary size, but the hot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #28 from Tamar Christina ---
(In reply to pthaugen from comment #19)
> I tried -fno-inline-functions-called-once and the patches on a Power9
> system. Following are the run times and spill counts (grep -c Spilling
> exchange2.fppized.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103604
--- Comment #16 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #15)
> Don't think it would fail now the statically allocated size is *at least*
> same as C. But some alias is still not matching up.
core.sys.posix.sys.types is implic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97220
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Resolu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103604
--- Comment #17 from YunQiang Su ---
(In reply to Iain Buclaw from comment #16)
> (In reply to Iain Buclaw from comment #15)
> > Don't think it would fail now the statically allocated size is *at least*
> > same as C. But some alias is still no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
--- Comment #26 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:f1215db08126fbd2d69d971d65611508cf83b4ae
commit r12-5958-gf1215db08126fbd2d69d971d65611508cf83b4ae
Author: Manfred Schwarb
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
--- Comment #27 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:44aa890d8fb4afa843cf6cb7452fd5d6f3dd61fe
commit r12-5959-g44aa890d8fb4afa843cf6cb7452fd5d6f3dd61fe
Author: Manfred Schwarb
Date:
=./xgcc
Target: x86_64-pc-linux-gnu
Configured with: ./configure --enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211214 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-B'
'/home/jengelh/repos/gcc/host-x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860
--- Comment #75 from Martin Liška ---
(In reply to David Binderman from comment #74)
> (In reply to Martin Liška from comment #72)
> > You will manage, it's not rocket science.
> >
> > So please, add break point at the place it triggers the ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103710
--- Comment #1 from Andrew Pinski ---
Attachment didn't go through?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103691
--- Comment #2 from Andrew Macleod ---
Its triggering an assert in the gimple folder when trying to process:
# DEBUG D.4293 => &a[0]
The constructor shows:
static real(kind=4) a[0] = {[0 ... -1]=2.0e+0};
is that a range of 0 to -1? its tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103711
Bug ID: 103711
Summary: Virtual base destroyed twice when an exception is
thrown in a derived class' constructor called from a
delegated constructor
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103686
--- Comment #2 from Peter Bergner ---
(In reply to Bill Schmidt from comment #1)
> I think that the MMA implementation is incompatible with -mno-fold-gimple.
> We'll need to prevent that flag combination, I think.
Does -mno-fold-gimple really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103662
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:3305135c29e1c3e988bd9bad40aefc01d138aaca
commit r12-5960-g3305135c29e1c3e988bd9bad40aefc01d138aaca
Author: Jan Hubicka
Date: Tue D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103585
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:3305135c29e1c3e988bd9bad40aefc01d138aaca
commit r12-5960-g3305135c29e1c3e988bd9bad40aefc01d138aaca
Author: Jan Hubicka
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103634
--- Comment #3 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:1c613165a55b212c59a83796b20a1d555e096504
commit r12-5961-g1c613165a55b212c59a83796b20a1d555e096504
Author: Harald Anlauf
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103711
--- Comment #1 from Andrew Pinski ---
ICC has the same behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103604
--- Comment #18 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #16)
> (In reply to Iain Buclaw from comment #15)
> > Don't think it would fail now the statically allocated size is *at least*
> > same as C. But some alias is still no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103604
--- Comment #19 from YunQiang Su ---
(In reply to Iain Buclaw from comment #18)
> (In reply to Iain Buclaw from comment #16)
> > (In reply to Iain Buclaw from comment #15)
> > > Don't think it would fail now the statically allocated size is *at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103686
--- Comment #3 from Peter Bergner ---
Maybe something like this untested patch:
diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index d9736eaf21c..c7babefa32d 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707
--- Comment #2 from anlauf at gcc dot gnu.org ---
Could it be the overflow simplifying fmax/fmin triggering this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103710
--- Comment #2 from Jan Engelhardt ---
Created attachment 52001
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52001&action=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103710
Andrew Pinski changed:
What|Removed |Added
Component|rtl-optimization|tree-optimization
Severity|no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687
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=103604
--- Comment #20 from Iain Buclaw ---
(In reply to YunQiang Su from comment #17)
> (In reply to Iain Buclaw from comment #16)
> > (In reply to Iain Buclaw from comment #15)
> > > Don't think it would fail now the statically allocated size is *at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103710
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103712
Bug ID: 103712
Summary: variable is not a constant expression because it is
used in its own initializer
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103712
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64989
Andrew Pinski changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64989
--- Comment #8 from Andrew Pinski ---
(In reply to Martin Liška from comment #4)
> Can the bug be marked as resolved?
No, it was the wrong bug #.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103686
--- Comment #4 from Bill Schmidt ---
Please don't make changes to the old builtin support, which has been disabled.
:-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90251
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103686
--- Comment #5 from Bill Schmidt ---
More properly, please don't rely on a bit that is being destroyed by the new
support. You need to look at built-in function attributes instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103713
Bug ID: 103713
Summary: warning_at's string is split in a word
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: trivial
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90251
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103696
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103686
--- Comment #6 from Bill Schmidt ---
if (bif_is_mmaint (rs6000_builtin_info_x[uns_fcode])
&& !rs6000_fold_gimple)
is what you're looking for. However, I would much rather see rejection of the
-mno-fold-gimple flag when MMA is enabled. Sil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103714
Bug ID: 103714
Summary: [11/12 Regression] name lookup in requires-clause
finds wrong thing
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Keywords: accepts-
1 - 100 of 199 matches
Mail list logo
