> On 11/16/20 1:44 PM, Jan Hubicka wrote:
> > Martin, we collected very many warnings when building with
> > configure --with-build-config=bootstrap-lto.mk
> > This patch fixes some of them, but there are many others, can you take a
> > look?
>
> Hello.
>
> I guess you mean Martin Jambor, or me?
On 11/16/20 1:44 PM, Jan Hubicka wrote:
Martin, we collected very many warnings when building with
configure --with-build-config=bootstrap-lto.mk
This patch fixes some of them, but there are many others, can you take a
look?
Hello.
I guess you mean Martin Jambor, or me? Please CC :)
Martin
> >
> > Richi, I think we can add "safe" parameter to gimple_call_arg_flags and
> > bypass this logic when we use it for warnings only (having body that
> > does not use the value is quite strong hint that it is unused by the
> > function).
>
> Eh, please not.
OK, I do not care that much as long
On Mon, 16 Nov 2020, Jan Hubicka wrote:
> > On Nov 15 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-
> On Nov 15 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
On Nov 15 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 someone wi
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
> 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
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."
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
> 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
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
> 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
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,
>
> >> 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,
>> 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 |
> 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 |
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 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.
>
> 2020-11-10 Jan Hubicka
>
> * gimple.c: Include ipa-modref-tree.h and ipa-modref.h.
> (gimple_call_arg
On Tue, 10 Nov 2020, Jan Hubicka wrote:
> > > + tree callee = gimple_call_fndecl (stmt);
> > > + if (callee)
> > > +{
> > > + cgraph_node *node = cgraph_node::get (callee);
> > > + modref_summary *summary = node ? get_modref_function_summary (node)
> > > + :
Hi,
here is updaed patch.
Honza
Bootstrapped/regtested x86_64-linux, OK (after the fnspec fixes)?
2020-11-10 Jan Hubicka
* gimple.c: Include ipa-modref-tree.h and ipa-modref.h.
(gimple_call_arg_flags): Use modref to determine flags.
* ipa-modref.c: Include gimple-ssa.
> > + tree callee = gimple_call_fndecl (stmt);
> > + if (callee)
> > +{
> > + cgraph_node *node = cgraph_node::get (callee);
> > + modref_summary *summary = node ? get_modref_function_summary (node)
> > + : NULL;
> > +
> > + if (summary && summary->arg
On Tue, 10 Nov 2020, Jan Hubicka wrote:
> Hi,
> this is updated patch for autodetection of EAF flags. Still the goal is
> to avoid fancy stuff and get besic logic in place (so no dataflow, no IPA
> propagation, no attempts to handle trickier cases). There is one new failure
>
> ./gcc/testsuite/
> > Bootstrapped/regtested x86_64-linux, OK?
> > (I will analyze more the t2.c failure)
>
> I have found independent reproducer that is now in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97775
... and with Jakub's fix the testcase works now.
Honza
>
> Honza
> Bootstrapped/regtested x86_64-linux, OK?
> (I will analyze more the t2.c failure)
I have found independent reproducer that is now in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97775
Honza
>
> Alias oracle query stats:
> refs_may_alias_p: 65808750 disambiguations, 75664890 queries
> ref_maybe_used_by_call_p: 153485 disambiguations, 66711204 queries
> call_may_clobber_ref_p: 22816 disambiguations, 28889 queries
> nonoverlapping_component_refs_p: 0 disambiguations, 36846 queri
Hi,
this is updated patch for autodetection of EAF flags. Still the goal is
to avoid fancy stuff and get besic logic in place (so no dataflow, no IPA
propagation, no attempts to handle trickier cases). There is one new failure
./gcc/testsuite/gcc/gcc.sum:FAIL: gcc.dg/sso/t2.c -Wno-scalar-stora
> >
> > Yep, i am not arguing for eliminating special case of memcpy (because we
> > have the additional info that it only copies pointers from *src to
> > *dest).
> >
> > However I find current definition of EAF_NOESCAPE bit hard to handle in
> > modref, since naturally it is quite reliable to t
28 matches
Mail list logo
