https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113838
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #6 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205
--- Comment #10 from Richard Biener ---
Btw, I was hoping Richard would chime in here ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113834
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-02-09
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113833
--- Comment #3 from Richard Biener ---
I suspect the issue would pop up with -Ofast -fno-vect-cost-model for any
sub-architecture. The patch referenced just adjusts costs for doing BB
vectorization (and there's reductions there as well). It mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113827
--- Comment #3 from Andrew Pinski ---
(In reply to Robin Dapp from comment #0)
> A hot block in the MrBayes benchmark (as used in the Phoronix testsuite) has
> a redundant scalar load when vectorized.
>
> Minimal example, compiled with -march=r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65947
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113827
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
Peter Bergner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113838
--- Comment #5 from absoler at smail dot nju.edu.cn ---
(In reply to Andrew Pinski from comment #2)
> The difference from the gimple level IR:
> ```
> _14 = g_26[5][3][0];
> _15 = (int) _14;
> _16 = _13 ^ _15;
> g_51 = _16;
> if (_13 !=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113838
--- Comment #4 from absoler at smail dot nju.edu.cn ---
@(In reply to Jakub Jelinek from comment #1)
> Disabling optimizations and then wondering why optimizations didn't happen
> is too weird. Don't do that. Such options are intended for debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113838
--- Comment #3 from absoler at smail dot nju.edu.cn ---
The gimple ir has no problem, but `_13` is replaced with g_26[5][3][0] in the
follow-up process, this shouldn't be expected behavior.
We question this option because we found in an older ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113834
--- Comment #3 from Andrew Pinski ---
Reduced testcase:
```
template class tuple{};
template
__type_pack_element<__i, _Elements...> &get(tuple<_Elements...> &__t) noexcept;
tuple data;
template
unsigned take_impl(unsigned idx) {
if constexp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830
--- Comment #13 from Bo Wang ---
(In reply to Harald van Dijk from comment #12)
> (In reply to Bo Wang from comment #11)
> > I have read the working draft standard of C++20
> > (https://github.com/cplusplus/draft/tree/c%2B%2B20).
> >
> > Follow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113844
Bug ID: 113844
Summary: inline namespace lookup ambiguity for using
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205
--- Comment #9 from Sérgio Basto ---
Thank you it worked , MLT was built successfully on Fedora Rawhide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113838
Andrew Pinski changed:
What|Removed |Added
Target||x86_64
Component|tree-optimiza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113833
--- Comment #2 from Andrew Pinski ---
Looking at the past issues (which we "fixed"), makes me wonder about the spec
verification testing for gromacs and the use of -Ofast ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113833
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113834
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100326
--- Comment #3 from Andrew Pinski ---
I even tried:
```
template void f(T v) {
#pragma GCC unroll v()
for (int i = 0; i < 10; i++) {
}
}
int main() {
f(0);
}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100326
--- Comment #2 from Andrew Pinski ---
This seems to be fixed on the trunk.
I think by r14-6193-g59be79fd596ec8 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113843
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113843
Bug ID: 113843
Summary: FAIL: libgomp.c/alloc-pinned-1.c execution test
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113841
--- Comment #1 from Viktor Ostashevskyi ---
Issue is visible with -std=c++20, works fine for -std=c++17 (for both GCC12 and
Clang).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113841
--- Comment #2 from Viktor Ostashevskyi ---
Compiler exporer link: https://godbolt.org/z/cPqsKq6nM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113842
Bug ID: 113842
Summary: Assertion failure in assemble_external_libcall due to
a missing finalizer
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113841
Bug ID: 113841
Summary: Can't swap two std::hash
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113673
--- Comment #5 from Andrew Pinski ---
(In reply to Roger Sayle from comment #4)
> The identified patch implements += the same way as |=. Presumably a version
> of the test case replacing "m += *data++;" with "m |= *data++;" would be
> more usef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100147
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |14.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
Bug 89863 depends on bug 100147, which changed state.
Bug 100147 Summary: libstdc++-v3/include/bits/gslice.h:170: missing check for
assignment to self ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100147
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100147
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:4e5dc6d9686a34d446147b923fe838389758a512
commit r14-8890-g4e5dc6d9686a34d446147b923fe838389758a512
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466
Jonathan Wakely changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113673
--- Comment #4 from Roger Sayle ---
The identified patch implements += the same way as |=. Presumably a version of
the test case replacing "m += *data++;" with "m |= *data++;" would be more
useful at identifying a patch that actually changed EH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #22 from Jonathan Wakely ---
Instead of adding yet another __valarray_copy overload, we can just not use it:
--- a/libstdc++-v3/include/std/valarray
+++ b/libstdc++-v3/include/std/valarray
@@ -840,7 +840,13 @@ _GLIBCXX_BEGIN_NAMESPAC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113836
--- Comment #4 from Gaius Mulley ---
Bootstrap completed and no extra failures seen in C, C++, Fortan or Modula-2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113811
--- Comment #3 from Jonathan Wakely ---
It seems fairly easy to do:
commit 12a028d76bbdf26d34d4d90a2ecdc39c6c0a4bd4 (HEAD -> master)
Author: Jonathan Wakely
Date: Thu Feb 8 15:40:32 2024
libstdc++: Use unsigned division in std::rotate [P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276
--- Comment #15 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:39d37ffbf890334b16ffb56da9fe00f0daa87f16
commit r12-10145-g39d37ffbf890334b16ffb56da9fe00f0daa87f16
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #28 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:b255ab901dd0d13ad7f0dc1a823749a5e5f62570
commit r12-10142-gb255ab901dd0d13ad7f0dc1a823749a5e5f62570
Author: Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466
--- Comment #12 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:f2af87b9705d5a7e37b65bf342146ff25f025e49
commit r12-10143-gf2af87b9705d5a7e37b65bf342146ff25f025e49
Author: Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113823
--- Comment #7 from Steve Kargl ---
On Thu, Feb 08, 2024 at 08:43:08PM +, dcb314 at hotmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113823
>
> --- Comment #6 from David Binderman ---
> (In reply to Steve Kargl from co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113823
--- Comment #6 from David Binderman ---
(In reply to Steve Kargl from comment #5)
> That's not what I meant. There is no bug1006.f90 in
> the llvm-project repo. What is the actual URL to the
> actual testcase? It should look something like
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113839
--- Comment #5 from Jonathan Wakely ---
(In reply to Frank Heckenbach from comment #0)
> While I appreciate gcc trying to by helpful, it seems it goes wrong rather
> often.
That doesn't match my experience. The errors that mention a specific gr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113836
Gaius Mulley changed:
What|Removed |Added
Attachment #57363|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113839
--- Comment #4 from Jonathan Wakely ---
(In reply to Marek Polacek from comment #2)
> Confirmed; we should say that we expect an id there.
$ clang++ s.cc
s.cc:3:14: error: expected unqualified-id
static int { };
^
1 error generat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113840
Bug ID: 113840
Summary: [OpenACC] !$acc loop seq – bogus rejection of
Fortran's EXIT/CYCLE + C/C++ break/continue
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799
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=113823
--- Comment #5 from Steve Kargl ---
On Thu, Feb 08, 2024 at 07:38:59PM +, dcb314 at hotmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113823
>
> --- Comment #4 from David Binderman ---
> (In reply to kargl from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837
--- Comment #9 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to H.J. Lu from comment #5)
> > (In reply to Jakub Jelinek from comment #1)
> > > Ugh no, please don't.
> > > This is significant ABI change.
> > > First of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113823
--- Comment #4 from David Binderman ---
(In reply to kargl from comment #3)
> If you do post the others, is it possible to include a URL to LLVM
> repository? This will allow us to give proper credit for the code.
https://github.com/llvm/llvm-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113839
--- Comment #3 from Frank Heckenbach ---
> Except C++ parsing does not allow for that because C++ parsing requires
> unlimited look ahead.
While that's true in general, I think in specific cases (including most
real-world cases), the look-ahead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830
--- Comment #11 from Bo Wang ---
(In reply to Jakub Jelinek from comment #10)
> But again, T::unknown isn't used except in a template which is not
> instantiated.
> It can't be checked during parsing because T::unknown is dependent and could
> v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113839
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2024-02-08
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113839
--- Comment #1 from Andrew Pinski ---
> I'd prefer if gcc (by default, or at least optional) would limit itself to
> reporting actual errors if and when they occur.
Except C++ parsing does not allow for that because C++ parsing requires
unlimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113839
Bug ID: 113839
Summary: misleading syntax error message
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109967
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Known to work||7.5.0, 8.5.0, 9.5.0
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837
--- Comment #8 from Jakub Jelinek ---
BTW, I guess we should have some RTL optimization (possibly backend combiner
pattern)
to be able to optimize stuff like
sall$7, y(%rip), %eax
sall$7, %edi
cmpl%eax, %edi
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837
--- Comment #7 from Jakub Jelinek ---
(In reply to H.J. Lu from comment #5)
> (In reply to Jakub Jelinek from comment #1)
> > Ugh no, please don't.
> > This is significant ABI change.
> > First of all, zeroing even for signed _BitInt is very wei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
--- Comment #10 from Jerry DeLisle ---
To clarify. The following is the remaining issue that is not related to stream
I/O:
> program tabs
> implicit none
> integer :: fd
> open(newunit=fd, file="test.txt", form="formatted")
> write(fd,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
--- Comment #9 from Jerry DeLisle ---
Created attachment 57365
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57365&action=edit
Preliminary patch
The attached patch fixes the stream I/O related tabbing. This regression tests
fine. There
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837
--- Comment #6 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to H.J. Lu from comment #3)
> > (In reply to Jakub Jelinek from comment #2)
> > > OT, what is the state of the ia32 _BitInt ABI? I'd really like to enable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837
--- Comment #5 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #1)
> Ugh no, please don't.
> This is significant ABI change.
> First of all, zeroing even for signed _BitInt is very weird, sign extension
> for that case is more natural,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113823
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to David Binderman from comment #2)
> (In reply to kargl from comment #1)
> > (In reply to David Binderman from comment #0)
> > >
> > > This is the second ice from the flang test suite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113415
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113838
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837
--- Comment #4 from Jakub Jelinek ---
(In reply to H.J. Lu from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > OT, what is the state of the ia32 _BitInt ABI? I'd really like to enable it
> > in GCC 14 even for ia32 (and perhaps -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113838
Bug ID: 113838
Summary: regression of redundant load operation introduced by
-fno-tree-forwprop introduce
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837
--- Comment #3 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #2)
> OT, what is the state of the ia32 _BitInt ABI? I'd really like to enable it
> in GCC 14 even for ia32 (and perhaps -mx32 if you care about that case).
I think we sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113836
--- Comment #2 from Gaius Mulley ---
Created attachment 57363
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57363&action=edit
Proposed fix
Here is a proposed fix which implements: -fdump-lang-all, -fdump-lang-quad,
-fdump-lang-quad=, -fd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837
--- Comment #2 from Jakub Jelinek ---
OT, what is the state of the ia32 _BitInt ABI? I'd really like to enable it in
GCC 14 even for ia32 (and perhaps -mx32 if you care about that case).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837
Bug ID: 113837
Summary: Zeroing unused bits in _BitInt can improve codegen
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113832
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113836
Gaius Mulley changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113836
Bug ID: 113836
Summary: gm2 does not dump gimple or quadruples to a file
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
Bug ID: 113835
Summary: compiling std::vector with const size in C++20 is slow
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113673
Michal Jireš changed:
What|Removed |Added
Last reconfirmed|2024-01-30 00:00:00 |2024-2-8
Keywords|needs-bisect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113834
--- Comment #1 from Ivan Lazaric ---
Created attachment 57362
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57362&action=edit
Preprocessed file generated by `-freport-bug`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113834
Bug ID: 113834
Summary: internal compiler error: in tree_to_shwi, at
tree.cc:6461
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113818
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113825
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113833
Bug ID: 113833
Summary: 435.gromacs fails verification on with -Ofast
-march={cascadelake,icelake-server} and PGO after
r14-7272-g57f611604e8bab
Product: gcc
Ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113519
Michal Jireš changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113390
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113390
Michal Jireš changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102580
--- Comment #7 from Jakub Jelinek ---
(In reply to Andrew Macleod from comment #6)
> My other question. so is the issue that unsigned divides are cheaper than
> signed divides?
The middle-end doesn't really know. On some targets unsigned divid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102580
--- Comment #6 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #5)
> To be precise, expand_expr_divmod uses get_range_pos_neg for that during
> expansion (unless we'd e.g. somehow noted it in some very late pass before
> expansio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113832
--- Comment #1 from Andrew Pinski ---
Maybe
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2f14c0dbb789852947cb58fdf7d3162413f053fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #27 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:c5e12bbb45313df876ee2b81e418851822bed694
commit r13-8307-gc5e12bbb45313df876ee2b81e418851822bed694
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466
--- Comment #11 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:3bdd80d56aa07d5975f551e0026f3cf9411124bf
commit r13-8306-g3bdd80d56aa07d5975f551e0026f3cf9411124bf
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276
--- Comment #14 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:3c04a1533b32362c7c28fc32b05623dda45a1b44
commit r13-8304-g3c04a1533b32362c7c28fc32b05623dda45a1b44
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113823
--- Comment #2 from David Binderman ---
(In reply to kargl from comment #1)
> (In reply to David Binderman from comment #0)
> >
> > This is the second ice from the flang test suite.
>
> If you're keep score
> https://discourse.llvm.org/t/propo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113832
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Target Mil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113832
Bug ID: 113832
Summary: [14 Regression] 6% exec time regression of 464.h264ref
on aarch64
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: needs-bisect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830
--- Comment #10 from Jakub Jelinek ---
But again, T::unknown isn't used except in a template which is not
instantiated.
It can't be checked during parsing because T::unknown is dependent and could
very well be well formed if it was instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113823
kargl at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113085
--- Comment #7 from seurer at gcc dot gnu.org ---
I posted the LE stuff already but here it is again:
spawn [open ...]^M
unsufficient lockable memory; please increase ulimit
FAIL: libgomp.c/alloc-pinned-1.c execution test
seurer@ltcden2-lp1:~/g
1 - 100 of 176 matches
Mail list logo
