On Sun, 15 Nov 2020, Jan Hubicka wrote:
> > See PR97840.
> Thanks,
> this is a false positive where we fail to discover that pointed-to type
> is empty on non-x86_64 targets. This is triggered by better alias
> analysis caused by non-escape discovery.
>
> While this is not a full fix (I hope
On Sun, 15 Nov 2020, Jan Hubicka wrote:
> > See PR97840.
> Thanks,
> this is a false positive where we fail to discover that pointed-to type
> is empty on non-x86_64 targets. This is triggered by better alias
> analysis caused by non-escape discovery.
>
> While this is not a full fix (I hope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97848
Bug ID: 97848
Summary: [missed optimization] tls init function check emitted
for consinit thread_local variables (C++20)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97836
--- Comment #5 from Jan Hubicka ---
I forgot to attach the PR number, but I commited the quick fix (to prevent
wrong code) as g:26285af40f98dfdb809b98b08386073c63b65db1
I will discuss the EAF_UNUSED flag today after teaching.
On Fri, 13 Nov 2020, Jakub Jelinek wrote:
> Hi!
>
> Apparently older GDB versions didn't handle this test right and so while
> it has been properly printing 42 on line 14 (e.g. on x86_64), it issued
> a weird error on line 17 (and because it didn't print any value, guality
> testsuite wasn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97847
Bug ID: 97847
Summary: [11 Regression] ICE in insert_insn_on_edge, at
cfgrtl.c:1976
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97847
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
--- Comment #6 from Jan Hubicka ---
I remember that first_field was returning non-NULL (perhaps it is derived from
empty base)?
My patch touched nothing on the condition: it just improved the alias analysis.
So while previously we tought that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97845
Martin Liška changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97830
Martin Liška changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97835
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97845
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97834
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97822
--- Comment #2 from Vladimir Koković ---
(In reply to Richard Biener from comment #1)
> Please specify the exact target
inxi --machine --graphics --cpu --system
System:Host: vlada-kuci Kernel: 5.8.18-1-MANJARO x86_64 bits: 64 Desktop:
KDE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97838
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97836
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
On 11/16/20 12:17 AM, Maciej W. Rozycki wrote:
Hi Martin,
Hello.
I have decided to give your `contrib/mklog.py' script a hit and, well,
ahem, I guess I must be doing something utterly silly, but no matter what
kind of a diff I hand to the script it does not produce anything unless I
apply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97835
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97834
Richard Biener changed:
What|Removed |Added
CC||nathan at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97831
Richard Biener changed:
What|Removed |Added
Severity|normal |enhancement
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97830
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827
Richard Biener changed:
What|Removed |Added
Target||gcn
Version|10.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97825
--- Comment #1 from Richard Biener ---
Can you please make sure you do not run out of stack space on the host? What's
your host?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97824
--- Comment #1 from Richard Biener ---
please specify host and target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97823
Richard Biener changed:
What|Removed |Added
Version|unknown |10.2.0
--- Comment #1 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97822
Richard Biener changed:
What|Removed |Added
Component|testsuite |target
Version|unknown
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556236.html
Thanks.
Gui Haochen
On 6/11/2020 上午 9:02, HAO CHEN GUI wrote:
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556236.html
Thanks.
Gui Haochen
On 15/10/2020 下午 4:46,
On 11/14/20 12:29 PM, Liu Hao via Gcc-patches wrote:
This is the third revision of my patch:
1. Two typos in the commit message have been fixed.
2. Support for `%a` and `%A` has been added. Documentation can be
found on the same page in the commit message.
3. GCC will no longer warn about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97846
Bug ID: 97846
Summary: No diagnostic for identifier label in constexpr
gunction
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Power10: Add IEEE 128-bit fp conditional move.
This patch adds the support for power10 IEEE 128-bit floating point conditional
move and for automatically generating min/max. Unlike the previous patch, I
decided to keep two separate patterns for fpmask before splitting (one pattern
for normal
Power10: Add IEEE 128-bit xsmaxcqp and xsmincqp support.
This patch adds the support for the IEEE 128-bit floating point C minimum and
maximum instructions. The next patch will add the support for using the
compare and set mask instruction to implement conditional moves.
Originally, I tried to
These two patches add support for the XSMAXCQP, XSMINCQP, XSCMP{EQ,GT,GE}QP
instructions in the Power10. These instructions allow the compiler to generate
minimum, maxmimum, and conditional move support for IEEE 128-bit floating point
type.
I have posted versions of these patches before, going
[ This year's end-of-stage1 I'm working virtually from American Samoa. ]
This patch finishes the second half of -Wrange-loop-construct I promised
to implement: it warns when a loop variable in a range-based for-loop is
initialized with a value of a different type resulting in a copy. For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #37 from Kito Cheng ---
Maybe we could add a parameter to indicate the type of memory access,
plain_mem, zext_mem or sext_mem for pass_shorten_memrefs::get_si_mem_base_reg.
e.g.
for (int i = 0; i < 2; i++)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97845
Bug ID: 97845
Summary: [11 regression] ICE at gcc/toplev.c:330 after r11-4982
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97844
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97844
Bug ID: 97844
Summary: Unsigned Integer Overflow when comparing strings
(|s1|<|s2|)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
--- Comment #5 from Martin Sebor ---
The warning code considers more that just TYPE_EMPTY_P():
/* Avoid warning about empty types such as structs with no members.
The first_field() test is important for C++ where the predicate
alone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #36 from Levy ---
It seems get_si_mem_base_reg() were called repeatly FOR_BB_INSNS from both
pass_shorten_memrefs::analyze and pass_shorten_memrefs::transform
Correct me if I'm wrong:
It seems we need some data structure (a linked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97843
Bug ID: 97843
Summary: Bad code gen when concatenating to array
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97842
Bug ID: 97842
Summary: ice compiling dxml
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee:
Hi,
this patch implements the logic to drop base alias sets (and thus also access
paths) from memory operands when doing so helps merging. This is done
by extending func_checker::compare_operand to record mismatched pairs
and then processing this in sem_function::equals_private when comparsion
Hi Martin,
I have decided to give your `contrib/mklog.py' script a hit and, well,
ahem, I guess I must be doing something utterly silly, but no matter what
kind of a diff I hand to the script it does not produce anything unless I
apply a patch like below to it, in which case the output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #9 from Michael_S ---
Despite what I wrote above, I did took a look at the trunk on godbolt with same
old code from a year ago. Because it was so easy. And indeed a trunk looks ALOT
better.
But until it's released I wouldn't know if
This patch implements the long-desired -Wuninitialized warning for
member initializer lists, so that the front end can detect bugs like
struct A {
int a;
int b;
A() : b(1), a(b) { }
};
where the field 'b' is used uninitialized because the order of member
initializers in the
On Tue, 2020-09-29 at 15:56 +0200, Mark Wielaard wrote:
> On Thu, 2020-09-10 at 13:16 +0200, Jakub Jelinek wrote:
> > On Wed, Sep 09, 2020 at 09:57:54PM +0200, Mark Wielaard wrote:
> > > --- a/gcc/doc/invoke.texi
> > > +++ b/gcc/doc/invoke.texi
> > > @@ -9057,13 +9057,14 @@ possible.
> > >
Snapshot gcc-11-20201115 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20201115/
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
The naming scheme used by GCC to reference MSP430 hardware multiply
library functions is inconsistent.
Sometimes the "GCC" names (e.g. mulsi2) are used, other times the
"MSPABI" names (e.g. __mspabi_mpyl) are used. The __mspabi names should
always be used.
Also, sometimes an identifier for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #8 from Michael_S ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to Michael_S from comment #5)
> > I agree with regard to "other targets", first of all, aarch64, but x86_64
> > variant of gcc already provides requested
Rather than inferring 16-bit hwmult support from lack of
32-bit/f5series/none hwmult support, define a function which explicitly
checks for 16-bit hwmult support.
Successfully regtested for msp430-elf.
Committed as obvious.
>From 814949ddceaef59725c84fe8ef7c6c617fb5d049 Mon Sep 17 00:00:00 2001
The "persistent" attribute is used for variables that are initialized
by the program loader, but are not initialized by the runtime startup
code. "persistent" variables are placed in a non-volatile area of
memory, which allows their value to "persist" between processor resets.
Successfully
Attribute handlers may want to examine DECL_INITIAL for a decl, to
validate the attribute being applied. For C++, DECL_INITIAL is currently
not set until cp_finish_decl, by which time attribute validation has
already been performed.
For msp430-elf this causes the "persistent" attribute to always
This patch series is version 2 of
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557184.html
The implementation is now simplified so as to not use a symtab flag for
"noinit" variables, instead we just check whether the decl has the
attribute set.
This patch series fixes behavior related
Variables with the "noinit" attribute are ignored at -O0 because they
are treated like a regular bss variable and placed in the .bss section.
With -fdata-sections they are ignored because they are not handled in
resolve_unique_section.
Successfully regtested for arm-none-eabi.
Ok for trunk?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
Hi Harald,
Feedback, such as comments for improvement, are welcome.
It feels a bit strange to have a check for an allocatable
behind -fcheck=pointer, but I'm not sure that introducing
a special check option would really be worth it.
Regarding pointers: They are usually not nullified (unless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #6 from Michael_S ---
(In reply to Marc Glisse from comment #1)
> We could start with the simpler:
>
> void f(unsigned*__restrict__ r,unsigned*__restrict__ s,unsigned a,unsigned
> b,unsigned c, unsigned d){
> *r=a+b;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
Michael_S changed:
What|Removed |Added
CC||already5chosen at yahoo dot com
--- Comment
Hardware multipliers that support widening 32-bit multiplication can
be used to perform a 64-bit * 64-bit multiplication more efficiently
than a software implementation.
The following equation is used to perform 64-bit multiplication for
devices with "32bit" or "f5series" hardware multiply
GCC generates better code when multiplication operations, which require
library functions to perform, are caught in early in RTL, rather than
leaving the operation to be mapped to a library function later on.
When there is hardware multiply support, it is more efficient to perform
widening
The attached patch series improves MSP430 hardware multiply support, by
improving code generation when setting up the 16-bit and 32-bit hardware
multiply functions, and adding a 64-bit hardware multiply library
function for devices that have a 32-bit hardware multiplier.
Successfully regtested
On Tue, 10 Nov 2020, Jeff Law via Gcc-patches wrote:
> >>> This patch reduce reservation of model do not more than 10 cycles. The
> >>> memory of genautomata down to 1GB.
> >> How bad is the memory consumption before this change?
> >>
> > almost 2.4GB.
> > see bugzilla comment #4.
> >
Thomas,
I am seeing a number of new failures on AIX related to the OpenACC
kernels patches.
c-c++-common/goacc/kernels-decompose-1.c
c-c++-common/goacc/kernels-decompose-2.c
gfortran.dg/goacc/kernels-decompose-1.f95
gfortran.dg/goacc/kernels-decompose-2.f95
Am Montag, den 09.11.2020, 23:41 + schrieb Joseph Myers:
> On Sat, 7 Nov 2020, Uecker, Martin wrote:
> > t = (const T) { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } };
> > test ();
> > }
> >
> > Not sure what to do about it, maybe 'convert' is not
> > the right function to use.
>
> I think
Hi,
one of common cases why we lose track on SSA name in modref propagation
is the situation where name is passed to funtion call and we then thus
continue by propagating through return value.
This patch adds simple logic to track arguments that does not escape to
return value. On cc1plus the
> gcc/ada/
> * adaint.c (__gnat_number_of_cpus): Check for the presence of
> _SC_NPROCESSORS_ONLN before using it.
> ---
> NB we could probably replace the list of OS #ifdefs with just a check for
> _SC_NPROCESSORS_ONLN, making use of it automagically with any new OS that
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101
--- Comment #6 from Jakub Jelinek ---
Created attachment 49565
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49565=edit
gcc11-pr88101-wip.patch
Fixed/updated patch that includes first testcase and passes it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #11 from Toon Moene ---
Created attachment 49564
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49564=edit
The full program I am testing.
This is the full program I am testing.
I have compiled it as follows (after building
> See PR97840.
Thanks,
this is a false positive where we fail to discover that pointed-to type
is empty on non-x86_64 targets. This is triggered by better alias
analysis caused by non-escape discovery.
While this is not a full fix (I hope someone with more experience on
C++ types and warnings
> See PR97840.
Thanks,
this is a false positive where we fail to discover that pointed-to type
is empty on non-x86_64 targets. This is triggered by better alias
analysis caused by non-escape discovery.
While this is not a full fix (I hope someone with more experience on
C++ types and warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
--- Comment #4 from Jan Hubicka ---
And to explain why warning does not trigger without modref, it is because we
are not able to disambiguate the variable with another function call (since we
think it escapes)
(gdb) p debug_gimple_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
Jan Hubicka changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #3
Hello world,
this patch makes sure that we pass the correct fn decls for
some of our library functions. cshift and others still remain
to be implemented.
This is a step in our voyage to stop lying to the middle end :-)
Regression-tested. OK for trunk?
Best regards
Thomas
Generate
Use `enum rtx_code' rather than `int' to hold the the RTL expression
code in `vax_rtx_costs', matching the type these codes have been defined
with and making debugging just a tiny little bit easier.
gcc/
* config/vax/vax.c (vax_rtx_costs): Use `rtx_code' rather than
Correct a regression in `vax-netbsdelf' gcc testing:
.../gcc/testsuite/gcc.target/vax/bswapdi-1.c: In function '__bswapdi2':
.../gcc/testsuite/gcc.target/vax/bswapdi-1.c:5:19: error: use of C99 long long
integer constant [-Wlong-long]
.../gcc/testsuite/gcc.target/vax/bswapdi-1.c:6:14: error: use
Hi,
In the course of my recent VAX backend modernisation effort I originally
tried the initial version of the VAX/NetBSD port that provided ELF file
format support, specifically 1.6.2, which at least in theory we aim to
support with the `vax-netbsdelf' target. That indeed turned out to be a
Check for the presence of _SC_NPROCESSORS_ONLN rather than using it
unconditionally with `sysconf', fixing a compilation error:
adaint.c: In function '__gnat_number_of_cpus':
adaint.c:2398:26: error: '_SC_NPROCESSORS_ONLN' undeclared (first use in this
function)
2398 | cores = (int) sysconf
Disable USE_PT_GNU_EH_FRAME frame unwinder support for old OS versions,
fixing compilation errors:
.../libgcc/unwind-dw2-fde-dip.c:75:21: error: unknown type name 'Elf_Phdr'
75 | # define ElfW(type) Elf_##type
| ^~~~
.../libgcc/unwind-dw2-fde-dip.c:132:9: note: in
Fix a typo and check both SImode addition operands for being incorrectly
symbolic in PIC mode before issuing a diagnostic dump of the offending
RTL expression.
gcc/
* config/vax/vax.c (vax_output_int_add) : Also check
`operands[2]' for being symbolic with PIC rather than
Fix a typo in a NO_EXTERNAL_INDIRECT_ADDRESS macro check around an
assertion verifying DImode addition operands to be valid for PIC.
gcc/
* config/vax/vax.c (vax_output_int_add) : Fix a typo
in NO_EXTERNAL_INDIRECT_ADDRESS.
---
Hi,
No regressions in `vax-netbsdelf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #15 from Georg-Johann Lay ---
I built the tools by hand so I knew what I had...
Dunno about gcc/buildbot policies concerning avr. As avr as a 3ary target, that
BE's quality is of no consideration when releasing the compiler. Again,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
--- Comment #2 from Jan Hubicka ---
Ok, so the warning is triggering when uninitialized memory is passed to
function argument declared as const. This happens here but is false positive
since the parameter is not used at all. This may have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
PowerPC: Restrict long double test to use IBM long double.
I posted this patch previously as a set of 3 testsuite patches. I have
separated them into separate patches. This patch marks the convert-bfp-11.c
patch as needing IBM extended double. If you look at the code, it is
specifically
>From 698d9fd8a5701fa4ed9690ddf71d57765921778c Mon Sep 17 00:00:00 2001
From: Michael Meissner
Date: Sun, 15 Nov 2020 00:48:23 -0500
Subject: [PATCH] PowerPC Fix ibm128 defaults for pr70117.c test.
This patch was previously posted as a combined patch with 2 other testsuite
patches. I moved it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
Jan Hubicka changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Include math.h in nextafter-2.c test.
I previously posted this with two other patches. I've separated this into its
own patch. What happens is because the nextafter-2.c test uses -fno-builtin,
and it does not include math.h, the wrong nextafterl and nextforwardl gets
called when long double is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86252
Jason Merrill changed:
What|Removed |Added
Target Milestone|--- |11.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323
Bug 88323 depends on bug 86252, which changed state.
Bug 86252 Summary: Abstract class in function return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86252
What|Removed |Added
My last patch implementing output reloads in asm goto resulted in LRA
crash in compiling kernel on s390x. Jeff Law reported it recently. The
culprit was in incorrect emitting reload insns in last empty BB. The
emitted insns got null BB which is wrong. Actually in this case we do
not need to
Abstract checking has been problematic for a while; when I implemented an
earlier issue resolution to do more checking it led to undesirable
instantiations, and so backed some of it out. During the C++20 process we
decided with P0929R2 that we should go the other way, and only check
abstractness
Since Jeff says that the latest Fedora build went fine, we can safely
remove the duplicated code in vr_values.
Here is the original proposal rebased for latest trunk.
Tested on x86-64 Linux.
Pushed.
commit 82b6d25d289195d41e53fc91f63325864e3e28d0
Author: Aldy Hernandez
Date: Wed Oct 28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97841
Bug ID: 97841
Summary: [C++17] is_invocable handling of incomplete return
type is wrong
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
See PR97840.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
See PR97840.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
Bug ID: 97840
Summary: [11 regression] Bogus -Wmaybe-uninitialized
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Hi Jan,
>> > When I configure with ../configure --enable-languages=go my build
>> > eventually finishes fine on curren trunk:
>> [...]
>> > On Debian SLES machines. Having preprocessed go-diagnostics.cc and
>> > .uninit1 dump would probably help.
>>
>> apart from go/diagnostics.cc, I see the
Hi Jan,
>> > When I configure with ../configure --enable-languages=go my build
>> > eventually finishes fine on curren trunk:
>> [...]
>> > On Debian SLES machines. Having preprocessed go-diagnostics.cc and
>> > .uninit1 dump would probably help.
>>
>> apart from go/diagnostics.cc, I see the
1 - 100 of 138 matches
Mail list logo
