https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106811
Bug ID: 106811
Summary: GENERIC and GIMPLE IL undefined behavior needs
documenting
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106809
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106810
Bug ID: 106810
Summary: Unexpected constraint recursion
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106806
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77928
--- Comment #2 from Tobias Burnus ---
Submitted patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600840.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106804
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #7 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106627
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:0b0a3cdbff64d97e7de3e0e2c26e965708064193
commit r13-2360-g0b0a3cdbff64d97e7de3e0e2c26e965708064193
Author: Simon Rainer
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71579
--- Comment #22 from Antony Polukhin ---
> Maybe we should consider dropping all the static assertions from traits that
> are implemented using a compiler built-in.
Sounds like the right thing to do.
> Our type trait and the __has_virtual_dest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
Yury Gribov changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
Yury Gribov changed:
What|Removed |Added
Attachment #53458|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #8 from H.J. Lu ---
(In reply to H.J. Lu from comment #3)
> This debug INSN:
>
> (debug_insn 29 28 30 2 (var_location:BLK D#2 (concatn:BLK [
> (mem/j:SI (plus:DI (plus:DI (ashift:DI (zero_extend:DI (and:SI
> (mem:SI (pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106809
Bug ID: 106809
Summary: [12 regression] large bison grammars compilation got a
lot slower, mainly due to -Wuninitialized
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100245
--- Comment #4 from José Rui Faustino de Sousa ---
On 01/09/22 19:30, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100245
>
Hi Anlauf,
Sorry for the very late answer, but at the moment I am far too busy to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99349
--- Comment #7 from Steve Kargl ---
On Thu, Sep 01, 2022 at 06:45:25PM +, anlauf at gcc dot gnu.org wrote:
>
> Alternatively, simply catching the NULL pointer dereference by
>
> diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
> index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
--- Comment #2 from James Hilliard ---
Testing with this patch:
diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 37ec662c190..ff08d0c5024 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -345,6 +345,8 @@ btf_collect_datasec (ctf_container_ref c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106707
--- Comment #8 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:6761d362c3efe5f4ca3b0c66e6854015acf162a1
commit r13-2358-g6761d362c3efe5f4ca3b0c66e6854015acf162a1
Author: H.J. Lu
Date: Thu Sep 1 15:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #6 from andysem at mail dot ru ---
So do you think this is a problem in Boost.Filesystem?
I would say this is a regression in string_view as the code is valid in
pre-C++23, and I would expect it to stay valid in C++23 onwards. Should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #5 from Jonathan Wakely ---
Looks related to the problem I fixed in
g:1e690757d30775ed340a368b9a9463b2ad68de01
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99349
--- Comment #6 from Steve Kargl ---
On Thu, Sep 01, 2022 at 07:57:56PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99349
>
> --- Comment #5 from anlauf at gcc dot gnu.org ---
> (In reply to Steve Kargl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71579
--- Comment #21 from Jonathan Wakely ---
The precondition for has_virtual_destructor is: "If T is a non-union class
type, T shall be a complete type." Our type trait and the
__has_virtual_destructor built-in both seem to get this wrong, rejecting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71579
--- Comment #20 from Jonathan Wakely ---
template
struct is_standard_layout
: public integral_constant
{
static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),
"template argument must be a complete clas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106782
--- Comment #8 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:b98c5262d02c13cdbbf3b985859b436adec94d90
commit r13-2357-gb98c5262d02c13cdbbf3b985859b436adec94d90
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #4 from andysem at mail dot ru ---
It fails the same way with 12.2 and trunk on godbolt:
https://gcc.godbolt.org/z/rT6TWhhvP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #3 from andysem at mail dot ru ---
I don't have the environment to build gcc locally, so I can't readily test
trunk. But I have been told the same issue reproduces with gcc-12
20220319-1ubuntu1 from Ubuntu 22.04:
https://github.com/b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #1 from Andrew Pinski ---
C++23 mode in gcc 11 is still in progress due it not even being 2023 yet. Can
you try the trunk?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
Bug ID: 106808
Summary: std::string_view range concept requirement causes
compile error with Boost.Filesystem
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
--- Comment #1 from James Hilliard ---
Getting a different error when running with:
https://patchwork.ozlabs.org/project/gcc/patch/20220901195340.10653-1-david.fa...@oracle.com/
GCC gen object failure:
$ /home/buildroot/bpf-next-test/tools/test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99349
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #4)
> The function is match_data_constant(), so we're looking for a
> constant. My patch simply removes the type checking as it is
> unimportant here, and a t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106807
--- Comment #3 from palmer at gcc dot gnu.org ---
(In reply to Andreas Schwab from comment #1)
> That happens if you use a modified compiler that automatically adds
> -latomic, so that configure in libatomic thinks that the builtins are
> availab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99349
--- Comment #4 from Steve Kargl ---
On Thu, Sep 01, 2022 at 06:45:25PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99349
>
> anlauf at gcc dot gnu.org changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106807
--- Comment #2 from Andreas Schwab ---
For example, if configure says:
checking for __atomic_fetch_add for size 1... yes
but __atomic_fetch_add isn't expanded inline you will get this recursive call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100245
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=106793
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-09-01
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106807
--- Comment #1 from Andreas Schwab ---
That happens if you use a modified compiler that automatically adds -latomic,
so that configure in libatomic thinks that the builtins are available and
expanded inline.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #19 from George Pee ---
Thank you for all of your thoughts and details, it has been tremendously
helpful!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106807
Bug ID: 106807
Summary: RISC-V: libatomic routines are infinate loops
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99349
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=106805
--- Comment #2 from Marc Glisse ---
A problematic optimization pointed in the discussion:
(simplify
(cmp @0 REAL_CST@1)
[...]
(if (REAL_VALUE_ISNAN (TREE_REAL_CST (@1))
&& !tree_expr_signaling_nan_p (@1)
&& !tree_expr_mayb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106707
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106707
--- Comment #6 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:5205f5b54ad769969ffd89978ba1bcee41380bf8
commit r13-2347-g5205f5b54ad769969ffd89978ba1bcee41380bf8
Author: Uros Bizjak
Date: Thu S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106806
Bug ID: 106806
Summary: [13 regression] gcc.dg/tree-ssa/gen-vect-34.c fails
after r13-2333-gca8f4e8af14869
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
Bug ID: 106805
Summary: Undue optimisation of floating-point comparisons
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106804
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106804
--- Comment #6 from Andrew Pinski ---
I think there is another bug report about:
if (_1 > _2)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
_3 = _1 + 1;
*a_7(D) = _3;
goto ; [100.00%]
[local count: 5368
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106804
--- Comment #5 from Andrew Pinski ---
Reference case:
[local count: 1073741824]:
_1 = *a_7(D);
_2 = *b_8(D);
if (_1 > _2)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
_3 = _1 + 1;
*a_7(D) = _3;
goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106804
--- Comment #4 from Andrew Pinski ---
(In reply to anthony.mikh from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > Clang use of cmov also might produce worse code
>
> That's exactly why I wrote "seemingly worse". However, the ap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106804
--- Comment #3 from anthony.mikh at yandex dot ru ---
(In reply to Andrew Pinski from comment #2)
> Clang use of cmov also might produce worse code
That's exactly why I wrote "seemingly worse". However, the approach used by
clang uses less regis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #7 from H.J. Lu ---
Specifically,
/* We can canonicalize SIGN_EXTEND (op) as ZERO_EXTEND (op) when
we know the sign bit of OP must be clear. */
if (val_signbit_known_clear_p (GET_MODE (op),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106804
--- Comment #2 from Andrew Pinski ---
Clang use of cmov also might produce worse code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106804
--- Comment #1 from Andrew Pinski ---
Note this code gen is a microbenchmarking and might not make a real difference
if the function is inlined or even part of some bigger code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106804
Bug ID: 106804
Summary: Poor codegen for selecting and incrementing value
behind a reference
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106803
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Ever conf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
H.J. Lu changed:
What|Removed |Added
CC||richard.sandiford at arm dot
com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106803
--- Comment #1 from 康桓瑋 ---
Another issue is that views::zip_transform returns
views::empty>> when N == 0, which is not strictly
true, the standard requires that the return is the result of the *lvalue* F
being invoked, that is, views::empty&>>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106803
Bug ID: 106803
Summary: views::adjacent_transform should not return
views::empty> when N == 0
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106802
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106802
--- Comment #1 from Jonathan Wakely ---
(In reply to Aaron Graham from comment #0)
> Even though `std::strong_ordering::less < 0` is perfectly legal and
> well-formed.
I disagree.
[cmp.categories.pre] p3 says:
The relational and equality op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106784
--- Comment #1 from Jonathan Wakely ---
To be clear, I'd like __is_nothrow_convertible too. But if I only get
__is_convertible first, that would still be great.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106802
Bug ID: 106802
Summary: Comparators in don't work with orderings
in
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #18 from Richard Earnshaw ---
(In reply to George Pee from comment #17)
> Any idea on why the issue is intermittent?
For SMP not really, because I think that path doesn't use lazy context
switching; but perhaps the kernel is smart e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #17 from George Pee ---
Any idea on why the issue is intermittent?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #16 from Richard Earnshaw ---
(In reply to George Pee from comment #15)
> Funny that you mention that...
> https://lore.kernel.org/linux-arm-kernel/20220901141307.2361752-1-
> george...@gmail.com/T/#u
:)
Don't forget that the arm64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #15 from George Pee ---
Funny that you mention that...
https://lore.kernel.org/linux-arm-kernel/20220901141307.2361752-1-george...@gmail.com/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #5 from H.J. Lu ---
(In reply to H.J. Lu from comment #4)
> This simple change:
>
> diff --git a/gcc/config/i386/i386-modes.def b/gcc/config/i386/i386-modes.def
> index e2e1e18d24d..b49daaef253 100644
> --- a/gcc/config/i386/i386-mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99968
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:37ff51a98583e63fb9afe83cf9f4351760149028
commit r13-2344-g37ff51a98583e63fb9afe83cf9f4351760149028
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #14 from Richard Earnshaw ---
Also beware that I don't think Russel King (Arm Linux kernel maintainer) would
accept this patch on its own. You'd likely need to add some boot time
detection of the additional feature and expose that t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #13 from Richard Earnshaw ---
I don't think it would hurt. With this change, a float-16 instruction that was
encountered on older cores would enable the VFP unit if it wasn't previously
enabled and then fault again when the retried
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106793
--- Comment #3 from Jonathan Wakely ---
GCC's error is not helpful, but clang clearly explains what's wrong:
error: use of class template 'barrier' requires template arguments; argument
deduction not allowed in function prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106798
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2022-09-01
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106801
Bug ID: 106801
Summary: ICE: in get, at cp/constraint.cc:2621
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #12 from George Pee ---
SMP is enabled. The opcode thing was an experiment only.
Your suggestion seems to work great, but is it safe to make the change across
all ARM cpus ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106279
--- Comment #5 from Richard Earnshaw ---
Technical note: the compiler is missing pattern alternatives to move iwmmxt
register values to VFP registers. There's no way to do this directly, so we'd
need to allow copying via core registers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106279
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2022-09-01
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101674
--- Comment #10 from Richard Biener ---
For the remaining superset_of path we now have
((m_16(D) != 0) AND (r_18(D) <= 19) AND (m_16(D) != 100) AND (n_15(D)
<= 9))
OR ((l_22(D) > 100) AND (NOT (m_16(D) != 0)) AND (r_18(D) <= 19)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93242
--- Comment #11 from Ilya Leoshkevich ---
I see. It would be good to update https://gcc.gnu.org/gcc-9/ then - e.g.
https://gcc.gnu.org/gcc-8/ says "This release series is no longer supported".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77928
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93242
--- Comment #10 from Mikael Pettersson ---
(In reply to Ilya Leoshkevich from comment #9)
> Would it be possible to backport this to gcc-9?
...
> There is a workaround for now, but it would be good to have this fixed in
> all the maintained gccs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99968
--- Comment #9 from Jonathan Wakely ---
Should we close this as fixed since 12.1?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106787
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=106798
--- Comment #1 from 康桓瑋 ---
(In reply to 康桓瑋 from comment #0)
> __i[__j] requires random_access_iterator, which is unnecessary.
In fact it's just a typo, it should be _M_current[__j] =
std::move(__i._M_current[__j]);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106799
--- Comment #2 from michal at sawicz dot net ---
@Richard correct, if you skip the precompilation, it compiles fine:
```
$ rm cmake_pch.hxx.gch
$ /usr/bin/g++-12 -I/usr/src/googletest/googlemock/include -O2 -std=c++20
-include cmake_pch.hxx -c t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #11 from Richard Earnshaw ---
(In reply to George Pee from comment #9)
> Using this works around the issue by treating it via a neon path and
> enabling the vfp bit and retrying the instruction.
>
> @@ -824,6 +824,9 @@ call_fpe:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #10 from Richard Earnshaw ---
If you don't have CONFIG_SMP enabled, it looks like the kernel will do lazy
context switching of the FP registers (it can save time if a process doesn't do
any FP). So another work around might be to en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106782
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940
Bug 98940 depends on bug 106655, which changed state.
Bug 106655 Summary: [C++23] P2295 - Support for UTF-8 as a portable source file
encoding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106655
What|Removed |A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106655
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106782
--- Comment #6 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:f9593025a290c68c0916dc6fa569eb38eda00535
commit r12-8734-gf9593025a290c68c0916dc6fa569eb38eda00535
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106799
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106800
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106800
Bug ID: 106800
Summary: Expose more vector extensions in C
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106782
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:953e08fde44a596e4ec2491efd15cd645e1ddc48
commit r13-2336-g953e08fde44a596e4ec2491efd15cd645e1ddc48
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106682
Kewen Lin changed:
What|Removed |Added
Component|target |testsuite
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93242
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106799
Bug ID: 106799
Summary: `forming offset [32, 36] is out of the bounds` error
with precompiled headers
Product: gcc
Version: 12.2.0
URL: https://bugs.launchpad.net/ubu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106785
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106785
--- Comment #9 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:bdfe0d1ce0aebdb68b77e2c04a0f45956c56b449
commit r13-2334-gbdfe0d1ce0aebdb68b77e2c04a0f45956c56b449
Author: Aldy Hernandez
Date:
99 matches
Mail list logo
