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
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
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
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
---
> Date: Wed, 7 Feb 2024 16:32:57 -0500
> From: Jason Merrill
> Incidentally, these testcases seem to require C++14; you can't have a
> switch in a constexpr function in C++11.
Update, v2 (from v1 that had a few requests from Marek
resolved from v0 that was posted together with my patch^Whack):
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
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
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...> (tuple<_Elements...> &__t) noexcept;
tuple data;
template
unsigned take_impl(unsigned idx) {
if constexpr
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).
> >
> >
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
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
On 2/8/24 1:03 PM, Harald Anlauf wrote:
Dear all,
the attached patch improves error recovery when we encounter an
array constructor where a unary operator (e.g. minus) is applied
and -frange-check is active. The solution is not to terminate
early in that case to avoid inconsistencies between
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113834
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment
On Feb 8, 2024, at 9:44 AM, Torbjörn SVENSSON
wrote:
>
> Changes since v1:
> - Replaced .* with [^\r\n]* to avoid matching newline.
>
> Ok for trunk and releases/gcc-13?
Ok.
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 .
Snapshot gcc-11-20240208 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20240208/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113843
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
Hello
Polite reminder of patch for review.
Thanks, Jonny
Forwarded Message
Subject: [PATCH] htdocs: correct spelling and use https in examples
Date: Wed, 6 Dec 2023 22:33:14 +
From: Jonny Grant
To: gcc-patches@gcc.gnu.org
CC: Joseph Myers
Revised version of this patch
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:
On Thu, Feb 08, 2024 at 04:53:45PM -0500, Jason Merrill wrote:
> On 2/8/24 11:51, Marek Polacek wrote:
> > On Thu, Feb 08, 2024 at 08:49:28AM -0500, Patrick Palka wrote:
> > > On Wed, 7 Feb 2024, Marek Polacek wrote:
> > >
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > >
Hi.
This patch fixes the bug 113842.
I cannot yet add a test with this patch since it requires using
try/catch which is not yet merged in master.
Thanks for the review.
From 71f5f5fa8e68594454d5511b6d0c795bc6a8c37a Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Fri, 26 Jan 2024 11:31:47
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:
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++
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
On 2/8/24 11:51, Marek Polacek wrote:
On Thu, Feb 08, 2024 at 08:49:28AM -0500, Patrick Palka wrote:
On Wed, 7 Feb 2024, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here the problem is that we give hard errors while substituting
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100147
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |14.0
Resolution|---
On 10/01/2024 21:26, Jonny Grant wrote:
>
>
> On 03/12/2023 17:55, David Malcolm wrote:
>> On Sun, 2023-12-03 at 11:59 +, Jonny Grant wrote:
>>>
>>>
>>> On 03/12/2023 04:03, Xi Ruoyao wrote:
On Sun, 2023-12-03 at 00:17 +, Jonny Grant wrote:
> @@ -733,7 +733,7 @@ To configure
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
Tested aarch64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/shared_ptr_atomic.h: Fix typo in comment.
---
libstdc++-v3/include/bits/shared_ptr_atomic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Tested aarch64-linux. Pushed to trunk.
-- >8 --
There's no need to check for self-assignment here, it would just add
extra code for an unlikely case. Add a comment saying so.
libstdc++-v3/ChangeLog:
PR libstdc++/100147
* include/bits/gslice.h (operator=): Add comment about lack
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
On 2/8/24 12:55, Paolo Bonzini wrote:
On 2/8/24 18:16, Jason Merrill wrote:
Hmm. In stage 1, when we build with the system gcc, I'd think we
want the just-built gnat1 to find the system libgcc.
In stage 2, when we build with the stage 1 gcc, we want the
just-built gnat1 to find the
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
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 @@
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
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
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
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
On Wed, Feb 07, 2024 at 05:19:56PM -0500, Jason Merrill wrote:
> On 2/5/24 22:11, Marek Polacek wrote:
> > On Mon, Feb 05, 2024 at 10:14:34AM -0500, Jason Merrill wrote:
> > > On 2/3/24 10:24, Marek Polacek wrote:
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > >
> > >
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
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
Dear all,
the attached patch improves error recovery when we encounter an
array constructor where a unary operator (e.g. minus) is applied
and -frange-check is active. The solution is not to terminate
early in that case to avoid inconsistencies between check_result
and reduce_unary when such a
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
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
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
On Fri, Jan 05, 2024 at 06:35:37PM -0500, Michael Meissner wrote:
> * config/rs6000/rs6000.opt (-mfuture): New undocumented debug switch.
No. Never ever use a flag that does what -mcpu= should do. We're
still trying to recover from previous such mistakes. Don't add more
please.
> +++
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
> On 8 Feb 2024, at 19:25, Jason Merrill wrote:
>
> On 2/8/24 12:51, Iain Sandoe wrote:
>>> On 8 Feb 2024, at 17:16, Jason Merrill wrote:
>>>
>>> On 2/8/24 12:12, Jason Merrill wrote:
On 2/8/24 10:04, Iain Sandoe wrote:
> Hi Jason,
>
> I have tested this on modern Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
---
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.
On 2/8/24 12:51, Iain Sandoe wrote:
On 8 Feb 2024, at 17:16, Jason Merrill wrote:
On 2/8/24 12:12, Jason Merrill wrote:
On 2/8/24 10:04, Iain Sandoe wrote:
Hi Jason,
I have tested this on modern Darwin (with libc++ as the system library) and on
older Darwin, where we do see the issue -
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
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
>
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
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
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
---
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
On Wed, Feb 07, 2024 at 05:21:10PM +0800, Kewen.Lin wrote:
> on 2024/2/6 14:01, Michael Meissner wrote:
> > It was more as a separation. The MPCCORE, CELL, PPCA2, and TITAN are rather
> > old processors.
I'll probably remove Titan soonish, btw. We have adjusted code around
it for what, fifteen
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
On Tue, Feb 06, 2024 at 01:01:52AM -0500, Michael Meissner wrote:
> > Nit: Named as "ISA_FUTURE_MASKS_SERVER" seems more accurate as it's
> > constituted
> > with ISA_3_1_MASKS_**SERVER** ...
>
> Well the _SERVER stuff was due to the power7 days when we still had to support
> the E500 in the
Hi!
On Fri, Jan 05, 2024 at 06:27:05PM -0500, Michael Meissner wrote:
> In the current MMA subsystem for Power10, there are 8 512-bit accumulator
> registers. These accumulators are each tied to sets of 4 FPR registers. When
Four VSX registers -- the FP registers are only a 64 bit part of each
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=edit
Preliminary patch
The attached patch fixes the stream I/O related tabbing. This regression tests
fine. There is
Committed
On 1/30/2024 9:51 AM, Palmer Dabbelt wrote:
On Mon, 29 Jan 2024 11:38:12 PST (-0800), e...@rivosinc.com wrote:
Adding rvv related flags (i.e. --param=riscv-autovec-preference) to
non vector targets bypassed the dejagnu skip test directive. Change the
target selector to skip if rvv is
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.
On 2/8/24 18:16, Jason Merrill wrote:
Hmm. In stage 1, when we build with the system gcc, I'd think we want
the just-built gnat1 to find the system libgcc.
In stage 2, when we build with the stage 1 gcc, we want the just-built
gnat1 to find the stage 1 libgcc.
In neither case do we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113415
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
> On 8 Feb 2024, at 17:16, Jason Merrill wrote:
>
> On 2/8/24 12:12, Jason Merrill wrote:
>> On 2/8/24 10:04, Iain Sandoe wrote:
>>> Hi Jason,
>>>
>>> I have tested this on modern Darwin (with libc++ as the system library) and
>>> on
>>> older Darwin, where we do see the issue - because the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113838
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
Changes since v1:
- Replaced .* with [^\r\n]* to avoid matching newline.
Ok for trunk and releases/gcc-13?
--
When running the testsuite for newlib nano, the --specs=nano.specs
option is used. This option prepends cpp_unique_options with
"-isystem =/include/newlib-nano" so that the newlib
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
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
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=edit
Proposed fix
Here is a proposed fix which implements: -fdump-lang-all, -fdump-lang-quad,
-fdump-lang-quad=,
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113832
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
---
1 - 100 of 240 matches
Mail list logo
