> 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?
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
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
> >
> > 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
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
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
> 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
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
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
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
> 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
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."
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
> 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
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:
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:
> 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
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
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
> 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
> 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
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]
>> 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 |
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
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
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.
>
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.
>
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)
> > > +
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
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
> > + 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 &&
> > + 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 &&
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
>
>
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
>
>
> > 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
... 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
> 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
>
> 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
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
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
> >
> > 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
> >
> > 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
56 matches
Mail list logo
