https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103066
--- Comment #1 from Hongyu Wang ---
__sync_val_compare_and_swap will be expanded to atomic_compare_exchange_strong
by default, should we restrict the check and return under
atomic_compare_exchange_weak which is allowed to fail spuriously?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102991
--- Comment #7 from luoxhu at gcc dot gnu.org ---
Fixed, will backport to gcc-11 in a week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102991
--- Comment #6 from CVS Commits ---
The master branch has been updated by Xiong Hu Luo :
https://gcc.gnu.org/g:614b39757b8b61f70ac1c666edb7a01a5fc19cd4
commit r12-4930-g614b39757b8b61f70ac1c666edb7a01a5fc19cd4
Author: Xionghu Luo
Date: Wed
a, b, c are same type as truncation type and has less precision than
extend type, the optimization is guarded under
flag_unsafe_math_optimizations.
Bootstrapped and regtested under x86_64-pc-linux-gnu{-m32,}
Ok for trunk?
gcc/ChangeLog:
PR target/102464
* match.pd: Simplify
a and b are same type as trunc type and has less precision than
extend type, the transformation is guarded by flag_finite_math_only.
Bootstrapped and regtested under x86_64-pc-linux-gnu{-m32,}
Ok for trunk?
gcc/ChangeLog:
PR target/102464
* match.pd: Simplify
Generate XXSPLTIDP for scalars on power10.
This patch implements XXSPLTIDP support for SF, and DF scalar constants.
The previous patch added support for vector constants. This patch adds
the support for SFmode and DFmode scalar constants.
I added 2 new tests to test loading up SF and DF scalar
Generate XXSPLTIDP for vectors on power10.
This patch implements XXSPLTIDP support for all vector constants. The
XXSPLTIDP instruction is given a 32-bit immediate that is converted to a vector
of two DFmode constants. The immediate is in SFmode format, so only constants
that fit as SFmode
Generate XXSPLTIW on power10.
This patch adds support to automatically generate the ISA 3.1 XXSPLTIW
instruction for V8HImode, V4SImode, and V4SFmode vectors. It does this by
adding support for vector constants that can be used, and adding a
VEC_DUPLICATE pattern to generate the actual XXSPLTIW
Add LXVKQ support.
This patch adds support to generate the LXVKQ instruction to load specific
IEEE-128 floating point constants.
Compared to the last time I submitted this patch, I modified it so that it
uses the bit pattern of the vector to see if it can generate the LXVKQ
instruction. This
Add new constant data structure.
This patch provides the data structure and function to convert a
CONST_INT, CONST_DOUBLE, CONST_VECTOR, or VEC_DUPLICATE of a constant) to
an array of bytes, half-words, words, and double words that can be loaded
into a 128-bit vector register.
The next patches
These patches are a refinement of the patches to add XXSPLTIDP support on
September 13th. These patches generate instructions that load up a VSX
register with certain constants instead of using PLXV to load the constant.
On the Power10:
* XXSPLTIDP is a prefixed instruction that takes a value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101337
sandra at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot
This is an expanded version of the patch for PR 101337 that Bernhard
sent out a few days ago with a request for me to finish it. Bernhard
did the part for operands and I added the pieces for procedure arguments
and intrinsics, along with fixing up the test cases that were previously
full of
> Note that this is not safe with -fsignaling-nans, so needs to be disabled
> for that option (if there isn't already logic somewhere with that effect),
> because the extend will convert a signaling NaN to quiet (raising
> "invalid"), but copysign won't, so this transformation could result in a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102714
--- Comment #10 from Bo Duan ---
(In reply to Richard Biener from comment #7)
> (In reply to Bo Duan from comment #6)
> > Hello, should we backport this patch to gcc-10?
>
> It's scheduled for a backport to GCC 11, I'm not aware that GCC 10 is
Hi Qing,
on 2021/11/5 上午4:37, Qing Zhao via Gcc-patches wrote:
> Hi,
>
> I noticed that the macro “WIDE_INT_MAX_ELTS” has different values in GCC11
> and GCC12 (on the same X86 machine)
>
> For gcc11:
>
> wide int max elts =3
>
> For gcc12:
>
> wide int max elts =9
>
> Does anyone know
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103090
--- Comment #1 from Thiago Macieira ---
One more:
bool tsign3(std::atomic )
{
// any two or more bits, so long as the sign bit is one of them
// (or the compiler doesn't know what's in the variable)
int bits = 1 | signbit;
Version: GCC 11.2 (msys2 mingw-w64 X86_64)
When a macro have more than one arguments, and u call it with no argument,
gcc will compliant with " only 1 given" instead of " 0 given"
Demo code:
#define TEST(x,y) test(x,y)
int main() {
int x=TEST();
}:
Error message:
F:/test.cpp:4:20: error: macro
On Thu, Nov 4, 2021 at 8:50 PM Xionghu Luo wrote:
> [PATCH] rs6000: Fix incorrect fusion constraint [PR102991]
>
> gcc/ChangeLog:
>
> * config/rs6000/fusion.md: Regenerate.
> * config/rs6000/genfusion.pl: Fix incorrect clobber constraint.
Okay.
Thanks, David
On 2021/11/4 09:59, David Edelsohn wrote:
> On Wed, Nov 3, 2021 at 9:46 PM Xionghu Luo wrote:
>>
>> On 2021/11/3 23:13, David Edelsohn wrote:
>>> Did you manually change fusion.md or did you regenerate it after
>>> fixing genfusion.pl?
>>>
>>> If you regenerated it, the ChangeLog entry should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967
--- Comment #7 from Martin Sebor ---
Both for the purposes of the warning (which can be more restrictive than what
the language considers valid), and in the C language, the semantics of the ->
expression depend on the first operand designating
On 10/31/21 8:13 AM, Daniil Stas wrote:
On Sun, 10 Oct 2021 23:10:20 +
Daniil Stas wrote:
This option is enabled by default when -Wformat option is enabled. A
user can specify -Wno-format-int-precision to disable emitting
warnings when passing an argument of an incompatible integer type
On Thu, 4 Nov 2021, Jeff Law wrote:
> Sometimes the language we're using in email is not as crisp as it should be.
> So
> just to be clear, the canonicalization I'm referring to is only in effect
> within
> a MEM. It does not apply to address calculations that happen outside a MEM.
> I
>
On 11/4/2021 3:04 PM, Maciej W. Rozycki wrote:
On Thu, 4 Nov 2021, Jeff Law wrote:
On 11/3/2021 7:53 AM, Maciej W. Rozycki wrote:
Correct a `vax-netbsdelf' target regression ultimately caused by commit
c605a8bf9270 ("VAX: Accept ASHIFT in address expressions") (needed for
LRA) and as of
On Thu, 4 Nov 2021 at 11:30, Jonathan Wakely wrote:
>
>
> On Wed, 27 Oct 2021 at 09:27, Jay Feldblum via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> From: yfeldblum
>>
>> The stdout stream is reserved for output intentionally produced by the
>> application. Assertion failures and other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55227
--- Comment #11 from Will Wray ---
Created attachment 51737
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51737=edit
Proposed patch Nov 4
Sent to gcc-patches for review
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583379.html
This patch aims to fix PR 55227; two underlying bugs that have caused:
(1) Rejection of valid designated initialization of char array fields by
string literals (a) when enclosed in optional braces or (b) unbraced
when the string literal is shorter than the target char array field.
(2) Acceptance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086
--- Comment #3 from Jonathan Wakely ---
Fixed on trunk so far.
The fix needs to be backported to gcc-11 because std::tuple uses
[[no_unique_address]] there, so the bug is present.
I think it's also present on older branches, but would only
Tested x86_64-linux, committed to trunk. Backport to gcc-11 to follow,
and maybe to other branches too.
Since std::tuple started using [[no_unique_address]] the tuple
member of std::unique_ptr has two _M_head_impl subobjects, in
different base classes. That means this printer code is ambiguous:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:a634928f5c8a281442ac8f5fb1636aed048ed72c
commit r12-4928-ga634928f5c8a281442ac8f5fb1636aed048ed72c
Author: Jonathan Wakely
On Linux/x86_64,
d70720c2382e687e192a9d666e80acb41bfda856 is the first bad commit
commit d70720c2382e687e192a9d666e80acb41bfda856
Author: Tamar Christina
Date: Thu Nov 4 17:32:09 2021 +
middle-end: convert negate + right shift into compare greater.
caused
FAIL: gcc.dg/signbit-2.c
Snapshot gcc-9-20211104 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20211104/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086
--- Comment #1 from Jonathan Wakely ---
This affects the filesystem::path printer too:
impl = self.val['_M_cmpts']['_M_impl']['_M_t']['_M_t']['_M_head_impl']
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103069
--- Comment #2 from Thiago Macieira ---
See also bug 103090 for a few more (restricted) possibilities to replace a
cmpxchg loop with a LOCK RMW operation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #29 from Thiago Macieira ---
New suggestion in bug 103090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103090
Bug ID: 103090
Summary: [i386] GCC should use the SF and ZF flags in some
atomic_fetch_op sequences
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103089
xantares09 at hotmail dot com changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103089
--- Comment #2 from xantares09 at hotmail dot com ---
indeed, I assumed both were positive, I guess there's no bug then
On Thu, 4 Nov 2021, Jeff Law wrote:
> On 11/3/2021 7:53 AM, Maciej W. Rozycki wrote:
> > Correct a `vax-netbsdelf' target regression ultimately caused by commit
> > c605a8bf9270 ("VAX: Accept ASHIFT in address expressions") (needed for
> > LRA) and as of commit 4a960d548b7d ("Avoid invalid loop
On Wed, 3 Nov 2021 at 00:20, Jonathan Wakely via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> These functions have been deprecated since C++11, and were removed in
> C++17. The proposal P0323 wants to reuse the name std::unexpected for a
> class template, so we will need to stop defining the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103089
--- Comment #1 from Andrew Pinski ---
If I add:
if (n <= 0 || m <= 0) __builtin_unreachable();
before the malloc, I get no warning.
I think the warning is correct if either n or m is negative.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97121
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103089
Bug ID: 103089
Summary: -Wmaybe-uninitialized -O2 false positive
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
For at least one target (Darwin) the platform convention is to
register static destructors (i.e. __attribute__((destructor)))
with __cxa_atexit rather than placing them into a list that is
run by some other mechanism.
This patch provides a target hook that allows a target to opt
into this and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
Bug ID: 103088
Summary: [12 regression] 500.perlbench from spec 2017 fails
since r12-4698
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
For posterity: This was discussed briefly on IRC, and Segher approved with
some
simplifications and a request to implement a fail/retry check.
Thanks,
Bill
On 11/3/21 10:02 AM, Jonathan Wakely wrote:
> On Wed, 3 Nov 2021 at 15:01, Jonathan Wakely wrote: Any feedback from POWER
> maintainers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
seurer at gcc dot gnu.org changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
Hi,
I noticed that the macro “WIDE_INT_MAX_ELTS” has different values in GCC11 and
GCC12 (on the same X86 machine)
For gcc11:
wide int max elts =3
For gcc12:
wide int max elts =9
Does anyone know what’s the reason for this difference?
Thanks a lot for any help.
Qing
On Thu, Nov 04, 2021 at 11:52:34AM -0400, Jason Merrill via Gcc-patches wrote:
> It's been inconvenient that pretty-printing of PTRMEM_CST didn't display
> what member the constant refers to.
>
> Adding that is complicated by the absence of a langhook for CONSTANT_CLASS_P
> nodes; the simplest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103073
--- Comment #6 from Martin Liška ---
> BTW, should I add new bugs to the meta-bug before or after they were
> confirmed?
Right after you create it I would say.
This patch implements P0849R8 which allows auto in a functional cast,
the result of which is a prvalue.
[expr.type.conv]/1 says that the type is determined by placeholder type
deduction. We only accept 'auto', not 'decltype(auto)' -- that the
type shall be auto comes from [dcl.type.auto.deduct].
On Thu, Nov 4, 2021 at 1:08 PM Uros Bizjak wrote:
>
> On Thu, Nov 4, 2021 at 3:44 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > Check leal and addl for x32 to fix:
> >
> > FAIL: gcc.target/i386/amxtile-3.c scan-assembler addq[ \\t]+\\$12
> > FAIL: gcc.target/i386/amxtile-3.c scan-assembler leaq[
On Thu, Nov 4, 2021 at 3:44 PM H.J. Lu via Gcc-patches
wrote:
>
> Check leal and addl for x32 to fix:
>
> FAIL: gcc.target/i386/amxtile-3.c scan-assembler addq[ \\t]+\\$12
> FAIL: gcc.target/i386/amxtile-3.c scan-assembler leaq[ \\t]+4
> FAIL: gcc.target/i386/amxtile-3.c scan-assembler leaq[
This accepts --disable-host-pch-support (or equivalent) and
disables the step that finds PCH files in the pre-processor.
It also stubs-out the PCH code (since it's never called).
Signed-off-by: Iain Sandoe
libcpp/ChangeLog:
* config.in: Regenerate.
* configure: Regenerate.
This provides a --disable-host-pch-support configure flag
that is passed down to libcpp, gcc and libstdc++ where the
support for PCH is enacted.
Signed-off-by: Iain Sandoe
ChangeLog:
* Makefile.def: Pass host PCH support configuration
to libcpp, gcc and libstdc++.
*
This takes account of the overall configuration for host PCH support
when deciding if we should build the libstdc++ PCH files.
We now require both the support is configured and that we are hosted.
A non-fatal configure warning is given if the user attempts to
--disable-host-pch-support
Some hosts cannot (or do not wish to) support PCH with the
current constraint that the executables must disable ASLR.
This allows the configuration to disable support for PCH
while still accepting the command lines (to avoid existing
build recipes failing).
Signed-off-by: Iain Sandoe
GCC (currently) has an implementation of pre-compiled-headers, that relies
on being able to launch the compiler executable at the same address each
time. This constraint is not permitted by some system security models.
The facility is an optimisation; saving the output of parsing a covering
Hi Bernhard,
Am 04.11.21 um 10:06 schrieb Bernhard Reutner-Fischer via Fortran:
On Wed, 3 Nov 2021 21:00:41 +0100
Harald Anlauf via Fortran wrote:
*PING*
Am 27.10.21 um 21:09 schrieb Harald Anlauf via Fortran:
Dear Fortranners,
when debugging the testcase, I noticed that a coarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103082
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103085
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
On Thu, Nov 04, 2021 at 01:22:24PM +0100, Martin Liška wrote:
> On 11/4/21 12:55, Segher Boessenkool wrote:
> >On Fri, Oct 29, 2021 at 09:32:21AM +0200, Richard Biener via Gcc-patches
> >wrote:
> >>On Fri, Oct 29, 2021 at 2:42 AM Bernhard Reutner-Fischer via
> >>Gcc-patches wrote:
> >>>
>
On Thu, Nov 04, 2021 at 01:22:24PM +0100, Martin Liška wrote:
> On 11/4/21 12:55, Segher Boessenkool wrote:
> >On Fri, Oct 29, 2021 at 09:32:21AM +0200, Richard Biener via Gcc-patches
> >wrote:
> >>On Fri, Oct 29, 2021 at 2:42 AM Bernhard Reutner-Fischer via
> >>Gcc-patches wrote:
> >>>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103058
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #6)
> Looking at the particular ICE, this looks like a fortran frond-end issue -
> this is during compilation and not during link and I do not see why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102869
Patrick Palka changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #8 from Aaron Ballman ---
(In reply to M Welinder from comment #6)
> elaborated-enum-specifier can be a elaborated-type-specifier. It is in the
> "enum Hog H;" case.
>
> But elaborated-enum-specifier is NOT an
On 10/31/2021 5:05 PM, Bernhard Reutner-Fischer via Gcc-patches wrote:
From: Bernhard Reutner-Fischer
contrib/ChangeLog:
* testsuite-management/validate_failures.py: 2to3
Please update the comments at the top of the file WRT Python 2.4. :-)
With those comments fixed, OK.
jeff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #7 from M Welinder ---
Maybe kick it up to the C++ people?
Note, that if the code is not allowed then a type alias is no longer as
powerful as the original type. I really doubt that was intended.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102981
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #4 from Jeffrey A. Law
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #6 from M Welinder ---
elaborated-enum-specifier can be a elaborated-type-specifier. It is in the
"enum Hog H;" case.
But elaborated-enum-specifier is NOT an elaborated-type-specifier in the "using
enum Hog;" case,
See
With -fstack-check the stack probes emitted access memory below the
stack pointer.
Bootstrapped and regression tested on s390x.
Committed to mainline
gcc/ChangeLog:
* config/s390/s390.h (STACK_CHECK_MOVING_SP): New macro
definition.
---
gcc/config/s390/s390.h | 5 +
1 file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #5 from Aaron Ballman ---
(In reply to Marek Polacek from comment #4)
> But elaborated-enum-specifier is an elaborated-type-specifier, so
> [dcl.type.elab]#6 should still apply, right?
That is my understanding. Otherwise p6 doesn't
Tested powerpc64le-linux, committed to trunk.
Currently std::variant uses __index_of to find the first
occurence of a type in a pack, and __exactly_once to check
that there is no other occurrence.
We can reuse the __find_uniq_type_in_pack() function for
both tasks, and remove the recursive
Tested powerpc64le-linux, committed to trunk.
This reduces the number of class template instantiations needed for code
using tuples, by reusing _Nth_type in tuple_element and specializing
tuple_size_v for tuple, pair and array (and const-qualified versions of
them).
Also define the _Nth_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #4 from Marek Polacek ---
But elaborated-enum-specifier is an elaborated-type-specifier, so
[dcl.type.elab]#6 should still apply, right?
On Thu, 4 Nov 2021, liuhongt via Gcc-patches wrote:
> a and b are same type as the truncation type and has less precision
> than extend type.
Note that this is not safe with -fsignaling-nans, so needs to be disabled
for that option (if there isn't already logic somewhere with that effect),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028
--- Comment #3 from Andreas Krebbel ---
So I think what is needed is something like this:
diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index 017944f4f79a..1f5b9476ac2e 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -4341,7 +4341,8 @@ find_if_header
Wilco Dijkstra writes:
> ping
Can you fold in the rtx costs part of the original GOT relaxation patch?
I don't think there's enough information here for me to be able to review
the patch though. I'll need to find testcases, look in detail at what
the rtl passes are doing, and try to work out
On 11/3/2021 7:53 AM, Maciej W. Rozycki wrote:
Correct a `vax-netbsdelf' target regression ultimately caused by commit
c605a8bf9270 ("VAX: Accept ASHIFT in address expressions") (needed for
LRA) and as of commit 4a960d548b7d ("Avoid invalid loop transformations
in jump threading registry.")
> On Thu, Nov 04, 2021 at 05:13:41PM +0100, Jan Hubicka via Gcc-patches wrote:
> > this patch workarounds ICE in gimple_static_chain_flags. I added a
> > sanity check that the nested function is never considered interposable
> > because such situation makes no sense: nested functions have no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #3 from M Welinder ---
I actually think gcc is right there.
http://eel.is/c++draft/dcl.type.elab#nt:elaborated-enum-specifier
There are requirements for elaborated-type-specifier, but none for
elaborated-enum-specifier. It's a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103073
Jan Hubicka changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment #5
Richard Biener writes:
>> > [...]
>> > @@ -2898,43 +2899,63 @@ vect_joust_loop_vinfos (loop_vec_info
>> > new_loop_vinfo,
>> >return true;
>> > }
>> >
>> > -/* If LOOP_VINFO is already a main loop, return it unmodified. Otherwise
>> > - try to reanalyze it as a main loop. Return the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103070
Jan Hubicka changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
Marek Polacek changed:
What|Removed |Added
CC||terra at gnome dot org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103087
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
"Andre Vieira (lists)" writes:
> Hi,
>
> This should address the ubsan bootstrap build and big-endian testisms
> reported against the last NEON load/store gimple lowering patch. I also
> fixed a follow-up issue where the alias information was leading to a bad
> codegen transformation. The NEON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103087
Bug ID: 103087
Summary: "using enum" possibly incorrectly accepted
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086
Jonathan Wakely changed:
What|Removed |Added
Known to fail||11.2.1, 12.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086
Bug ID: 103086
Summary: [11/12 Regression] std::unique_ptr printer gets
confused by [[no_unique_address]] in tuple
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Outgoing range calculations were assuming an undefined operand produces
an undefined result. This is not true, as in the testcxase:
[0, 0] = UNDEFINED | b_9 tells us that b_9 is [0,0] and the rest
of the time, we only know its varying. Returning UNDEFINED for b_9 is
clearly wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
--- Comment #11 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:004afb984beb6efbe25f44a5857b1c27ebc2ec82
commit r12-4921-g004afb984beb6efbe25f44a5857b1c27ebc2ec82
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103085
Bug ID: 103085
Summary: [12 Regression] -fPIC and -fstack-protector-strong
broken AArch64
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #48 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:1ece90ffa9ce63b416296bd662b8117d9b538913
commit r12-4920-g1ece90ffa9ce63b416296bd662b8117d9b538913
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
Bug ID: 103084
Summary: Accepts invalid using enum declaration with an invalid
elaborated-type-specifier
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103073
--- Comment #4 from Vsevolod Livinskiy ---
(In reply to Martin Liška from comment #2)
> Started with r12-4401-gfecd145359fc981b.
>
> @Vsevolod: Is it a yarpgen test-case?
Yes. I've added stencil support recently, but it was a surprise to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103058
Jan Hubicka changed:
What|Removed |Added
Component|ipa |fortran
--- Comment #6 from Jan Hubicka
Hello All,
I am badly stuck at custom float encode and decode, I humbly request your
assistance.
I am trying to incorporate in custom floats in RISCV-32 elf, I am encoding
and assigning to image at line 2985 in
1 - 100 of 268 matches
Mail list logo
