This breaks bootstrap with go.
../../gcc/go/gofrontend/go-diagnostics.cc: In function 'std::string
expand_message(const char*, va_list)':
../../gcc/go/gofrontend/go-diagnostics.cc:110:61: error: '' may be
used uninitialized [-Werror=maybe-uninitialized]
110 | "memory alloc
> On Wed, Nov 04, 2020 at 07:31:42PM +0100, Uros Bizjak wrote:
> > Hello!
> >
> > I was looking at the recent linux patch series [1] where segment
> > qualifiers (named address spaces) were introduced to handle percpu
> > variables. In the patch [2], the author mentions that:
> >
> > --q--
> > U
> This breaks bootstrap with go.
>
> ../../gcc/go/gofrontend/go-diagnostics.cc: In function 'std::string
> expand_message(const char*, va_list)':
> ../../gcc/go/gofrontend/go-diagnostics.cc:110:61: error: '' may be
> used uninitialized [-Werror=maybe-uninitialized]
> 110 |
Hi Jan,
>> This breaks bootstrap with go.
>>
>> ../../gcc/go/gofrontend/go-diagnostics.cc: In function 'std::string
>> expand_message(const char*, va_list)':
>> ../../gcc/go/gofrontend/go-diagnostics.cc:110:61: error: '' may
>> be used uninitialized [-Werror=maybe-uninitialized]
>> 110 |
> Hi Jan,
>
> >> This breaks bootstrap with go.
> >>
> >> ../../gcc/go/gofrontend/go-diagnostics.cc: In function 'std::string
> >> expand_message(const char*, va_list)':
> >> ../../gcc/go/gofrontend/go-diagnostics.cc:110:61: error: '' may
> >> be used uninitialized [-Werror=maybe-uninitialized]
Hi Jan,
>> I'm seeing the same on both i386-pc-solaris2.11 and
>> sparc-sun-solaris2.11, so I don't think there are special configure
>> flags involved.
>
> When I configure with ../configure --enable-languages=go my build
> eventually finishes fine on curren trunk:
[...]
> On Debian SLES machines
> Hi Jan,
>
> >> I'm seeing the same on both i386-pc-solaris2.11 and
> >> sparc-sun-solaris2.11, so I don't think there are special configure
> >> flags involved.
> >
> > When I configure with ../configure --enable-languages=go my build
> > eventually finishes fine on curren trunk:
> [...]
> > On
On Fri, Nov 13, 2020 at 12:07 AM Richard Biener wrote:
>
> On Tue, 10 Nov 2020, Jan Hubicka wrote:
>
> > Hi,
> > here is updaed patch.
> >
> > Honza
> >
> > Bootstrapped/regtested x86_64-linux, OK (after the fnspec fixes)?
>
> OK.
>
> Thanks,
> Richard.
>
This caused:
https://gcc.gnu.org/bugzill
> On Fri, Nov 13, 2020 at 12:07 AM Richard Biener wrote:
> >
> > On Tue, 10 Nov 2020, Jan Hubicka wrote:
> >
> > > Hi,
> > > here is updaed patch.
> > >
> > > Honza
> > >
> > > Bootstrapped/regtested x86_64-linux, OK (after the fnspec fixes)?
> >
> > OK.
> >
> > Thanks,
> > Richard.
> >
>
> This
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 war
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.
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 wil
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
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 produce
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
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 som
16 matches
Mail list logo