On 2022/06/11 9:12, Max Filippov wrote:
Hi Suwa-san,
hi!
This change results in a bunch of ICEs in tests that look like this:
gcc/gcc/testsuite/gcc.c-torture/compile/memtst.c: In function 'main':
gcc/gcc/testsuite/gcc.c-torture/compile/memtst.c:28:1: error:
unrecognizable insn:
(insn 7 6 8 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105923
Andrew Pinski changed:
What|Removed |Added
Component|target |c
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105923
Bug ID: 105923
Summary: unsupported return type ‘complex double’ for simd
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65328
--- Comment #11 from juchem at gmail dot com ---
great job
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105756
--- Comment #4 from Sam James ---
Thanks! Could you consider backporting to 12.x soonish, if possible? I ask
because with this, the 12.x branch is then in a pretty good state for more
widespread testing.
(Unfortunately, I got a bit unlucky and
> Hope this is helpful; please let me know if you see any mistakes, or if
> there's room for improvement
Nice work! In the "inside cc1" chapter, I think that IR is usually meant for
"Intermediate Representation" rather than "Internal Representation" in this
context.
--
Eric Botcazou
Hi Suwa-san,
On Thu, Jun 9, 2022 at 9:26 PM Takayuki 'January June' Suwa
wrote:
>
> Now apply to almost any size of aligned block under such circumstances.
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.cc (xtensa_expand_block_set_small_loop):
> Pass through the block length /
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105922
Bug ID: 105922
Summary: AArch64 SVE instruction generated with all SIMD lane
active and zero-divide exception flag raised
Product: gcc
Version: 12.1.1
Status:
On Fri, 10 Jun 2022, 22:29 Alejandro Colomar via Gcc,
wrote:
> [I reordered some of your answers, to better answer]
>
> Hi Jakub,
>
> On 6/10/22 23:16, Jakub Jelinek wrote:
> > On Fri, Jun 10, 2022 at 10:40:15PM +0200, Alejandro Colomar via Gcc
> wrote:
> >> So, could you please drop that from
Snapshot gcc-11-20220610 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20220610/
and on various mirrors, see http://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
I've written a large new chunk of documentation for my GCC newbies
guide, called "Diving into GCC internals", which can be seen at:
https://gcc-newbies-guide.readthedocs.io/en/latest/diving-into-gcc-internals.html
Hope this is helpful; please let me know if you see any mistakes, or if
there's
Thanks, Jonathan. I am, in fact, so certifying.
I do believe that bringing up support for new OS versions is in scope for
open branches, and it makes sense to merge, particularly for a trivial and
uncontentious patch like this one.
Jonathan Wakely wrote:
> On Fri, 10 Jun 2022 at 21:12, Mark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99858
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #3
Hi Joseph,
On 6/10/22 23:09, Joseph Myers wrote:
P.S.: The latest draft that I know of is N2731. I guess there are newer ones.
Could you please name the latest one?
It's N2912 (June 8 version - the version originally published on June 7
had various problems; there are still some issues,
[I reordered some of your answers, to better answer]
Hi Jakub,
On 6/10/22 23:16, Jakub Jelinek wrote:
On Fri, Jun 10, 2022 at 10:40:15PM +0200, Alejandro Colomar via Gcc wrote:
So, could you please drop that from C2x?
No!
[[attr0]] void foo (void), bar (void);
appertains to both
On Fri, 10 Jun 2022 at 21:12, Mark Mentovai wrote:
>
> The macOS 13 SDK (and equivalent-version iOS and other Apple OS SDKs)
> contain this definition in :
>
> 863 #define __null_terminated
>
> This collides with the use of __null_terminated in libstdc++'s
> experimental fs_path.h.
>
> As
On Fri, Jun 10, 2022 at 10:40:15PM +0200, Alejandro Colomar via Gcc wrote:
> So, could you please drop that from C2x?
No!
For one it diverges from C++, but also it means something different
at the different locations.
[[attr0]] void foo (void), bar (void);
appertains to both declarations, while
On Fri, 10 Jun 2022, Alejandro Colomar via Gcc wrote:
> I'd like to suggest a change in C2x regarding attributes.
The attribute syntax is supposed to accept attributes in exactly the
places they are accepted in C++ (and appertaining to the same entity, for
each such place), for constructs
Hi, Joseph!
I'd like to suggest a change in C2x regarding attributes.
Right now, the draft allows function attributes to go right at the
beginning of a function prototype, or just before the opening parenthesis:
[[attr]] type f(params);
type f [[attr]](params);
I'd argue against the second
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #16 from qinzhao at gcc dot gnu.org ---
additional work are needed in order to make this task complete:
1. add one more new gcc option:
-fstrict-flex-arrays
when it's on, only treat the following cases as flexing array:
trailing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #15 from qinzhao at gcc dot gnu.org ---
the following patch will fix the issue with this testing case:
[opc@qinzhao-ol8u3-x86 gcc]$ git diff
diff --git a/gcc/tree-object-size.cc b/gcc/tree-object-size.cc
index
The macOS 13 SDK (and equivalent-version iOS and other Apple OS SDKs)
contain this definition in :
863 #define __null_terminated
This collides with the use of __null_terminated in libstdc++'s
experimental fs_path.h.
As libstdc++'s use of this token is entirely internal to fs_path.h, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65328
--- Comment #10 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:343d83c7a89d0c7a78139e685395228115a28f6e
commit r13-1047-g343d83c7a89d0c7a78139e685395228115a28f6e
Author: Patrick Palka
Date:
On 6/10/2022 9:40 AM, Segher Boessenkool wrote:
Hi!
On Fri, Jun 10, 2022 at 07:52:57PM +0530, Surya Kumari Jangala wrote:
In check_new_reg_p, the nregs of a du chain is computed by obtaining the MODE
of the first element in the chain, and then calling hard_regno_nregs() with the
MODE. But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105921
--- Comment #1 from Yclept Nemo ---
AFAICT, the attachment includes everything needed in a bug report. Inlining the
code here for convenience:
#include
template
auto a = (struct A {
template
using Temp = T1;
template
auto
On Fri, Jun 10, 2022 at 01:27:28PM -0400, Jason Merrill wrote:
> > --- gcc/cp/constexpr.cc.jj 2022-06-08 08:21:02.973448193 +0200
> > +++ gcc/cp/constexpr.cc 2022-06-08 17:13:04.986040449 +0200
> > @@ -5707,6 +5707,20 @@ cxx_eval_store_expression (const constex
> > }
> > break;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105921
Bug ID: 105921
Summary: internal compiler error: in cp_parser_template_id, at
cp/parser.cc:18362
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104642
--- Comment #5 from Jason Merrill ---
The suggested -funreachable-traps seems to have a lot of overlap with
-fsanitize-undefined-trap-on-error; I wonder about combining them, and having
it by itself imply -fsanitize=unreachable.
To add a module initializer optimization, we need to defer finishing
writing out the module file until the end of determining the dynamic
initializers. This is achieved by passing some saved-state from the main
module writing to a new function that completes it.
This patch merely adds the
Hi!
Another regression caused by my recent patch.
This time because define_insn_and_split only requires that the
constant mask is const_int_operand. When it was only SImode,
that wasn't a problem, HImode neither, but for DImode if we need
to and the shift count we might run into a problem that
On Thu, Jun 09, 2022 at 01:57:52PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Jun 09, 2022 at 12:11:28PM +0200, Thomas Schwinge wrote:
> > On 2022-06-09T10:19:03+0200, Jakub Jelinek via Gcc-patches
> > wrote:
> > > This patch adds support for dlopening libmemkind.so
> >
> > Instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038
--- Comment #10 from Bill Long ---
The original issue seems fixed in 12.1. However, the wording of the ERROR
message (objecting that something is not a DATA entity when it really is) could
still be improved. Can we either convert this bug to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103902
--- Comment #3 from Lewis Hyatt ---
I can look into that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103902
Lewis Hyatt changed:
What|Removed |Added
CC||maik.urbannek at cattatech dot
de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104640
Lewis Hyatt changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
Hello,
I'd like to ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596065.html
Thanks,
Eugene
-Original Message-
From: Gcc-patches On
Behalf Of Eugene Rozenfeld via Gcc-patches
Sent: Thursday, June 02, 2022 12:22 AM
To: gcc-patches@gcc.gnu.org; Andi Kleen ; Jan
Since F16C and VAES are only usable with AVX, require AVX for F16C and
VAES.
OK for master and release branches?
Thanks.
H.J.
---
libgcc/105920
* common/config/i386/cpuinfo.h (get_available_features): Require
AVX for F16C and VAES.
---
gcc/common/config/i386/cpuinfo.h |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105920
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2022-06-10
Ever confirmed|0
On Fri, Jun 10, 2022 at 7:44 AM H.J. Lu wrote:
>
> On Fri, Jun 10, 2022 at 2:38 AM Florian Weimer wrote:
> >
> > * liuhongt via Libc-alpha:
> >
> > > +\subsubsection{Special Types}
> > > +
> > > +The \code{__Bfloat16} type uses a 8-bit exponent and 7-bit mantissa.
> > > +It is used for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732
--- Comment #19 from Jakub Jelinek ---
It hasn't been fixed on 11 and 10 branches yet, that is why it is kept open but
12/13 has been removed from the Summary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #18 from joseph at codesourcery dot com ---
libquadmath is essentially legacy code. People working directly in C
should be using the C23 _Float128 interfaces and *f128 functions, as in
current glibc, rather than libquadmath
Hi!
On Fri, Jun 10, 2022 at 11:27:40AM -0400, Michael Meissner wrote:
> Testing has found that using store vector pair for block copies can result
> in a slow down on power10. This patch disables using the vector pair
> instructions for block copies if we are tuning for power10.
Load paired
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732
--- Comment #18 from Loren Osborn ---
It appears this fix has already been merged into trunk. Is there a reason this
isn't marked "Resolved"? Is that usually not updated until the next release?
On 6/9/22 04:37, Jakub Jelinek wrote:
Hi!
We claim we support P0415R1 (constexpr complex), but e.g.
#include
constexpr bool
foo ()
{
std::complex a (1.0, 2.0);
a += 3.0;
a.real (6.0);
return a.real () == 6.0 && a.imag () == 2.0;
}
static_assert (foo ());
fails with
test.C:12:20:
On 6/10/22 12:00, Patrick Palka wrote:
On Fri, 10 Jun 2022, Patrick Palka wrote:
On Thu, 9 Jun 2022, Patrick Palka wrote:
On Thu, 9 Jun 2022, Jason Merrill wrote:
On 6/8/22 14:21, Patrick Palka wrote:
When substituting a class template specialization, tsubst_aggr_type
substitutes the
We special-case emitting the calls of module initializer functions.
It's simpler to just emit a static fn do do that, and add it onto the
front of the global init fn chain. We can also move the calculation of
the set of initializers to call to the point of use.
nathan
--
Nathan
On 6/9/22 15:37, Patrick Palka wrote:
On Thu, 9 Jun 2022, Jason Merrill wrote:
On 6/9/22 09:00, Patrick Palka wrote:
This performs one of the optimizations added by the previous
patch to lookup_template_class, to instantiate_template as well.
(For the libstdc++ ranges tests this optimization
On 6/10/22 09:40, Patrick Palka wrote:
The reason compiling the testcase in this PR is so slow is ultimately
due to our poor hashing of TYPENAME_TYPE causing a huge amount of hash
table collisions in the spec_hasher and typename_hasher tables.
In spec_hasher, we don't hash the components of a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #17 from Michael_S ---
(In reply to Jakub Jelinek from comment #15)
> From what I can see, it is mostly integral implementation and we already
> have one such in GCC, so the question is if we just shouldn't use it (most
> of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #16 from Michael_S ---
(In reply to Thomas Koenig from comment #14)
> @Michael: Now that gcc 12 is out of the door, I would suggest we try to get
> your code into the gcc tree for gcc 13.
>
> It should follow the gcc style
On Fri, 10 Jun 2022, Patrick Palka wrote:
> On Thu, 9 Jun 2022, Patrick Palka wrote:
>
> > On Thu, 9 Jun 2022, Jason Merrill wrote:
> >
> > > On 6/8/22 14:21, Patrick Palka wrote:
> > > > When substituting a class template specialization, tsubst_aggr_type
> > > > substitutes the TYPE_CONTEXT
libgomp/ChangeLog
2022-06-10 Mohamed Atef
* ompd-helper.h (DEREFERENCE, ACCESS_VALUE): New macros.
* ompd-helper.c (gompd_get_nthread, gompd_get_thread_limit,
gomp_get_run_shed, gompd_get_run_sched_chunk_size,
gompd_get_default_device, gompd_get_dynamic,
gompd_get_max_active_levels,
Hi!
On Fri, Jun 10, 2022 at 07:52:57PM +0530, Surya Kumari Jangala wrote:
> In check_new_reg_p, the nregs of a du chain is computed by obtaining the MODE
> of the first element in the chain, and then calling hard_regno_nregs() with
> the
> MODE. But the first element of the chain can be a
This patch revises the previous implementation of constant synthesis.
First, changed to use define_split machine description pattern and to run
after reload pass, in order not to interfere some optimizations such as
the loop invariant motion.
Second, not only integer but floating-point is
[PATCH, V2] Disable generating load/store vector pairs for block copies.
Testing has found that using store vector pair for block copies can result
in a slow down on power10. This patch disables using the vector pair
instructions for block copies if we are tuning for power10.
This is version 2
Hi Mark,
> On 10 Jun 2022, at 15:56, Mark Mentovai wrote:
>
> f18cbc1ee1f4 (2021-12-18) updated various parts of gcc to not impose a
> Darwin or macOS version maximum of the current known release. Different
> parts of gcc accept, variously, Darwin version numbers matching
> darwin2*, and macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105920
Bug ID: 105920
Summary: __builtin_cpu_supports ("f16c") should check AVX
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
f18cbc1ee1f4 (2021-12-18) updated various parts of gcc to not impose a
Darwin or macOS version maximum of the current known release. Different
parts of gcc accept, variously, Darwin version numbers matching
darwin2*, and macOS major version numbers up to 99. The current released
version is Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105919
Bug ID: 105919
Summary: Internal compiler error when using -fanalyzer on
php-src
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Severity: normal
On Fri, Jun 10, 2022 at 2:38 AM Florian Weimer wrote:
>
> * liuhongt via Libc-alpha:
>
> > +\subsubsection{Special Types}
> > +
> > +The \code{__Bfloat16} type uses a 8-bit exponent and 7-bit mantissa.
> > +It is used for \code{BF16} related intrinsics, it cannot be
Please mention that this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105690
--- Comment #3 from Franz Sirl ---
I managed to minimize the testcase a bit more:
unsigned int gvar1;
void fun1(int);
void fun2(unsigned int, char *);
int fun2_maxlen;
typedef struct {
int exist;
int mode;
} table_t;
table_t gtable[20];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105915
Jonathan Wakely changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105915
--- Comment #9 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:f2385d1fe9f9ee0b5940ba27b41b79c9db051104
commit r10-10824-gf2385d1fe9f9ee0b5940ba27b41b79c9db051104
Author: Jonathan
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
When I fixed PR libstdc++/92978 I introduced a regression whereby
std::lcm(INT_MIN, 1) and std::lcm(5, 4) would no longer produce
errors during constant evaluation. Those calls are undefined, because
they violate the preconditions that
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This ensures that the single-threaded fallback buffer eh_globals is not
destroyed during program termination, using the same immortalization
technique used for error category objects.
Also ensure that init._M_init can still be read after init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92978
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:671970a5621e18e7079b4ca113e56434c858db66
commit r13-1040-g671970a5621e18e7079b4ca113e56434c858db66
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105844
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:671970a5621e18e7079b4ca113e56434c858db66
commit r13-1040-g671970a5621e18e7079b4ca113e56434c858db66
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880
--- Comment #12 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:1e65f2ed99024f23c56f7b6a961898bcaa882a92
commit r13-1039-g1e65f2ed99024f23c56f7b6a961898bcaa882a92
Author: Jonathan Wakely
regrename: Fix -fcompare-debug issue in check_new_reg_p [PR105041]
In check_new_reg_p, the nregs of a du chain is computed by obtaining the MODE
of the first element in the chain, and then calling hard_regno_nregs() with the
MODE. But the first element of the chain can be a DEBUG_INSN whose mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7061
--- Comment #9 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:1753a7120109c1d3b682f9487d6cca64fb2f0929
commit r13-1038-g1753a7120109c1d3b682f9487d6cca64fb2f0929
Author: Roger Sayle
Date: Fri
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This new library issue was recently moved to Tentatively Ready by an LWG
poll, so I'm making the change on trunk.
As noted in PR libstc++/105907 the std::hash specializations for PMR
strings were not treated as slow hashes by the unordered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105907
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:b370ed0bf93ecf0ff51d29e7fc132c433b2aa1be
commit r13-1037-gb370ed0bf93ecf0ff51d29e7fc132c433b2aa1be
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105918
Bug ID: 105918
Summary: Spurious Warray-bounds in std::to_chars
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926
Bug 101926 depends on bug 95126, which changed state.
Bug 95126 Summary: [10/11/12/13 Regression] Missed opportunity to turn static
variables into immediates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95126
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95126
Roger Sayle changed:
What|Removed |Added
Target Milestone|10.4|13.0
Status|ASSIGNED
The reason compiling the testcase in this PR is so slow is ultimately
due to our poor hashing of TYPENAME_TYPE causing a huge amount of hash
table collisions in the spec_hasher and typename_hasher tables.
In spec_hasher, we don't hash the components of a TYPENAME_TYPE at all,
presumably because
Hi,
This patch adds support for the ACLE Data Intrinsics to the AArch64 port.
Bootstrapped and regression tested on aarch64-none-linux.
OK for trunk?
gcc/ChangeLog:
2022-06-10 Andre Vieira
* config/aarch64/aarch64.md (rbit2): Rename this ...
(@aarch64_rbit): ... this and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105915
Jonathan Wakely changed:
What|Removed |Added
Summary|[11 Regression] commit |[10 Regression] commit
I have done a partial revert on the gcc-11 branch to fix PR105915.
I'll also backport it to gcc-10 after testing finishes.
-- >8 --
The r11-9772-g6f8133689f4397 backport made two changes, but only one was
needed on the gcc-11 branch. The other should not have been backported,
and causes errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105915
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105915
--- Comment #6 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:60c84707034f025de3c8821cc5d6f27ff59143b0
commit r11-10058-g60c84707034f025de3c8821cc5d6f27ff59143b0
Author: Jonathan
On Thu, 9 Jun 2022, Patrick Palka wrote:
> On Thu, 9 Jun 2022, Jason Merrill wrote:
>
> > On 6/8/22 14:21, Patrick Palka wrote:
> > > When substituting a class template specialization, tsubst_aggr_type
> > > substitutes the TYPE_CONTEXT before passing it to lookup_template_class.
> > > This
Hi,
this patch prevents ipa-prop from propagating aggregates when load is
volatile. Martin, does this look OK? It seem to me that ipa-prop may
need some additional volatile flag checks.
Bootstrapped/regtested x86_64-linux, OK?
Honza
gcc/ChangeLog:
2022-06-10 Jan Hubicka
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105917
Jan Hubicka changed:
What|Removed |Added
Summary|Missed passthru jump|[10/11/12/13 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105915
--- Comment #5 from Benda Xu ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Benda Xu from comment #0)
> > 2. https://github.com/gentoo/gentoo/pull/25313
>
> N.B. I'm fixing it like this instead of backporting 42eff613d0, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105913
Thomas Schwinge changed:
What|Removed |Added
Version|13.0|rust/master
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105914
Thomas Schwinge changed:
What|Removed |Added
Version|13.0|rust/master
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105906
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105908
Patrick Palka changed:
What|Removed |Added
Keywords||rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105917
Bug ID: 105917
Summary: Missed passthru jump function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105915
--- Comment #4 from Jonathan Wakely ---
(In reply to Benda Xu from comment #0)
> 2. https://github.com/gentoo/gentoo/pull/25313
N.B. I'm fixing it like this instead of backporting 42eff613d0, so that pull
request might want to use the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105915
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-06-10
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105915
--- Comment #3 from Benda Xu ---
(In reply to Jonathan Wakely from comment #2)
>
> Only when compiling with clang, presumably.
Yes, that's true. To be specific, we meet it in the AMD ROCm on Gentoo, where
the HIP compiler is based on llvm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105916
Bug ID: 105916
Summary: gfortran -fdiagnostics-format=json yields incorrect
output
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105915
--- Comment #2 from Jonathan Wakely ---
(In reply to Benda Xu from comment #0)
> With a MWE of
>
> ```c++
> #include
>
> int main(){}
> ```
> would produce
> ```
> /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.1/include/g++-v11/experimental/bits/
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105915
--- Comment #1 from Benda Xu ---
Hi Jonathan, I am involving you in the Cc thinking that you will have a better
idea on this issue. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105915
Bug ID: 105915
Summary: commit 42eff613 should be backported to gcc-11 for
bits/fs_path.h consistency
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
On Fri, 2022-06-10 at 10:14 +0100, Richard Sandiford via Gcc-patches
wrote:
Several existing internal functions map directly to an instruction
defined in target-insns.def. This patch makes it easier to define
more such functions in future.
This should help to reduce cut-&-paste, but more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105913
--- Comment #1 from Rainer Orth ---
Also known as gccrs Issue #1229.
1 - 100 of 117 matches
Mail list logo
