Re: ICE building a libsupc++ file, pdp11 target
> On Jul 17, 2018, at 9:36 AM, Richard Biener
> wrote:
>
> On Tue, Jul 17, 2018 at 3:08 PM Paul Koning wrote:
>>
>>
>>> On Jul 17, 2018, at 5:46 AM, Richard Biener
>>> wrote:
>>>
...
>>>
>>> There is not enough information for anyone to help you without
>>> reproducing the issue which is maybe too much to ask for ;)
>>>
>>> Can you debug_tree () the offending decl in gdb?
>>
>> Yes, here it is. I don't know anything about debugging in this area, so
>> tools like debug_tree are good to learn about. How would I interpret its
>> output?
>>
>> pkoning:gcc pkoning$ lldb ./cc1plus -- new_opa.ii -fno-implicit-templates
>> -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
>> -fdiagnostics-show-location=once -frandom-seed=new_opa.lo -g -O2 -std=gnu++1z
>> (lldb) target create "./cc1plus"
>> Current executable set to './cc1plus' (x86_64).
>> ...
>> Process 10880 stopped
>> * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
>>frame #0: 0x000100c21378 cc1plus`internal_error(gmsgid="in %s, at
>> %s:%d") at diagnostic.c:1441 [opt]
>> 1438 internal_error (const char *gmsgid, ...)
>> 1439 {
>> 1440 va_list ap;
>> -> 1441 va_start (ap, gmsgid);
>> 1442 rich_location richloc (line_table, input_location);
>> 1443 diagnostic_impl (&richloc, -1, gmsgid, &ap, DK_ICE);
>> 1444 va_end (ap);
>> Target 0: (cc1plus) stopped.
>> (lldb) frame sel 2
>> frame #2: 0x000100074b36
>> cc1plus`import_export_decl(decl=0x00014269c750) at decl2.c:2877 [opt]
>> 2874 gcc_assert (VAR_OR_FUNCTION_DECL_P (decl));
>> 2875 /* Any code that creates entities with TREE_PUBLIC cleared should
>> 2876 also set DECL_INTERFACE_KNOWN. */
>> -> 2877 gcc_assert (TREE_PUBLIC (decl));
>> 2878 if (TREE_CODE (decl) == FUNCTION_DECL)
>> 2879 gcc_assert (DECL_IMPLICIT_INSTANTIATION (decl)
>> 2880 || DECL_FRIEND_PSEUDO_TEMPLATE_INSTANTIATION (decl)
>> (lldb) call debug_tree(decl)
>> >type >size
>>unit-size
>>align:8 warn_if_not_align:0 symtab:150 alias-set -1 canonical-type
>> 0x1426aa5e8 precision:1 min max > 0x142502a08 1>>
>>readonly constant used static tree_1 tree_2 tree_3 unsigned nonlocal
>> in_system_header read decl_1 QI
>> /Users/pkoning/Documents/svn/buildpdp/pdp11-aout/libstdc++-v3/include/type_traits:59:28
>> size unit-size
>>align:8 warn_if_not_align:0 context > integral_constant> initial
>>template-info 0x1426a64e0 chain >
>> (lldb)
>
> lldb? eh ... ;)
>
> anyhow, this is
>
> namespace std
> {
>
> # 56
> "/Users/pkoning/Documents/svn/buildpdp/pdp11-aout/libstdc++-v3/include/type_traits"
> 3
> template
>struct integral_constant
>{
> static constexpr _Tp value = __v;
> ^^^
>
> which should have TREE_PUBLIC set. My next step would be to watch how
> this flag changes (if it does...)
>
> break at ggc-page.c:1442 (the return stmt of ggc_internal_alloc)
> conditional on result == 0x14269c750
> and then watch *&the-decl->base.public_flag printing said flag when
> the watchpoint hits
> (because you're watching the whole integer containing the bitfield bit).
>
> If that doesn't go anywhere try reducing the source file using creduce
> or by other means.
>
> Maybe look at reset_decl_linkage () and visibility support in general.
I trimmed the file a bit.
Managed to find where public_flag is cleared. It is in cp/expr.c
maybe_commonize_var, line 5619, here:
else
{
/* While for initialized variables, we must use internal
linkage -- which means that multiple copies will not
be merged. */
TREE_PUBLIC (decl) = 0;
DECL_COMMON (decl) = 0;
Could it be related to the fact that I have an a.out (rather than ELF) target?
paul
Re: Building with old gcc
Hi,
On 09/10/18 15:33, Jonathan Wakely wrote:
On Tue, 9 Oct 2018 at 14:30, Paul Koning wrote:
I'm trying to build the current code on Linux with GCC 4.3.2 (stock compiler in
Fedora 10 which is my old test system). It fails like this:
In file included from
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/tree-data-ref.h:27,
from
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/gimple-loop-interchange.cc:44:
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h: In constructor
‘opt_result::opt_result(bool, opt_problem*)’:
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: class
‘opt_result’ does not have any field named ‘opt_wrapper’
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: no matching
function for call to ‘opt_wrapper::opt_wrapper()’
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:160: note: candidates are:
opt_wrapper::opt_wrapper(T, opt_problem*) [with T = bool]
/mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:147: note:
opt_wrapper::opt_wrapper(const opt_wrapper&)
make[3]: *** [gimple-loop-interchange.o] Error 1
Is 9.0 supposed to build with a build compiler this old?
Yes.
GCC 4.3 doesn't define the injected-class-name for the base, so this
patch is needed:
--- a/gcc/opt-problem.h
+++ b/gcc/opt-problem.h
@@ -214,7 +214,7 @@ class opt_result : public opt_wrapper
/* Private ctor. Instances should be created by the success and failure
static member functions. */
opt_result (wrapped_t result, opt_problem *problem)
- : opt_wrapper (result, problem)
+ : opt_wrapper (result, problem)
{}
};
At the end of August my colleague Jose Marchesi fixed another instance
of the same issue, affecting classes auto_edge_flag and auto_bb_flag. I
think we can commit this change too as obvious.
Paolo.
Re: Building with old gcc
On Tue, Oct 9, 2018 at 3:33 PM Jonathan Wakely wrote:
>
> On Tue, 9 Oct 2018 at 14:30, Paul Koning wrote:
> >
> > I'm trying to build the current code on Linux with GCC 4.3.2 (stock
> > compiler in Fedora 10 which is my old test system). It fails like this:
> >
> > In file included from
> > /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/tree-data-ref.h:27,
> > from
> > /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/gimple-loop-interchange.cc:44:
> > /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h: In constructor
> > ‘opt_result::opt_result(bool, opt_problem*)’:
> > /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: class
> > ‘opt_result’ does not have any field named ‘opt_wrapper’
> > /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: no
> > matching function for call to ‘opt_wrapper::opt_wrapper()’
> > /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:160: note: candidates
> > are: opt_wrapper::opt_wrapper(T, opt_problem*) [with T = bool]
> > /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:147: note:
> > opt_wrapper::opt_wrapper(const opt_wrapper&)
> > make[3]: *** [gimple-loop-interchange.o] Error 1
> >
> > Is 9.0 supposed to build with a build compiler this old?
>
> Yes.
>
> GCC 4.3 doesn't define the injected-class-name for the base, so this
> patch is needed:
OK.
> --- a/gcc/opt-problem.h
> +++ b/gcc/opt-problem.h
> @@ -214,7 +214,7 @@ class opt_result : public opt_wrapper
>/* Private ctor. Instances should be created by the success and failure
> static member functions. */
>opt_result (wrapped_t result, opt_problem *problem)
> - : opt_wrapper (result, problem)
> + : opt_wrapper (result, problem)
>{}
> };
Re: Building with old gcc
On Tue, 9 Oct 2018 at 14:30, Paul Koning wrote:
>
> I'm trying to build the current code on Linux with GCC 4.3.2 (stock compiler
> in Fedora 10 which is my old test system). It fails like this:
>
> In file included from
> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/tree-data-ref.h:27,
> from
> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/gimple-loop-interchange.cc:44:
> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h: In constructor
> ‘opt_result::opt_result(bool, opt_problem*)’:
> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: class
> ‘opt_result’ does not have any field named ‘opt_wrapper’
> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: no matching
> function for call to ‘opt_wrapper::opt_wrapper()’
> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:160: note: candidates
> are: opt_wrapper::opt_wrapper(T, opt_problem*) [with T = bool]
> /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:147: note:
>opt_wrapper::opt_wrapper(const opt_wrapper&)
> make[3]: *** [gimple-loop-interchange.o] Error 1
>
> Is 9.0 supposed to build with a build compiler this old?
Yes.
GCC 4.3 doesn't define the injected-class-name for the base, so this
patch is needed:
--- a/gcc/opt-problem.h
+++ b/gcc/opt-problem.h
@@ -214,7 +214,7 @@ class opt_result : public opt_wrapper
/* Private ctor. Instances should be created by the success and failure
static member functions. */
opt_result (wrapped_t result, opt_problem *problem)
- : opt_wrapper (result, problem)
+ : opt_wrapper (result, problem)
{}
};
Building with old gcc
I'm trying to build the current code on Linux with GCC 4.3.2 (stock compiler in Fedora 10 which is my old test system). It fails like this: In file included from /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/tree-data-ref.h:27, from /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/gimple-loop-interchange.cc:44: /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h: In constructor ‘opt_result::opt_result(bool, opt_problem*)’: /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: class ‘opt_result’ does not have any field named ‘opt_wrapper’ /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:217: error: no matching function for call to ‘opt_wrapper::opt_wrapper()’ /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:160: note: candidates are: opt_wrapper::opt_wrapper(T, opt_problem*) [with T = bool] /mnt/hgfs/pkoning/Documents/svn/gcc/gcc/opt-problem.h:147: note: opt_wrapper::opt_wrapper(const opt_wrapper&) make[3]: *** [gimple-loop-interchange.o] Error 1 Is 9.0 supposed to build with a build compiler this old? The documentation on the GCC web page says an ISO C++ compiler is required but it doesn't tell me whether the C++ compiler in GCC 4.3.2 is adequate. Since many people will be installing GCC using an older version of GCC, it would be good for the documentation to state what the minimum version of GCC is. paul
Re: movmem pattern and missed alignment
On Tue, Oct 9, 2018 at 1:53 PM Joseph Myers wrote: > > On Tue, 9 Oct 2018, Richard Biener wrote: > > > It was repeatedly suggested that we _could_ derive alignment info from > > function parameter types since we rely on precise typing there for example > > for points-to analysis (albeit only for restrict qualification processing > > and > > for DECL_BY_REFERENCE "pointers"). That would fix the simple testcase > > that was presented here. > > Even in that case you mustn't assume alignment for pointer comparisons, > only for dereferences. Assuming it for comparisons breaks e.g. glibc's > > # define LC_GLOBAL_LOCALE ((locale_t) -1L) > > (locale_t is a pointer-to-pointer-aligned-struct) and other similar > constructs involving magic constants (not dereferenced) of pointer type; > comparisons of a locale_t value against LC_GLOBAL_LOCALE need to work. Heh! That's non-conforming! But yes, looks like it won't fly after all. Richard. > -- > Joseph S. Myers > jos...@codesourcery.com
Re: movmem pattern and missed alignment
On Tue, 9 Oct 2018, Richard Biener wrote: > It was repeatedly suggested that we _could_ derive alignment info from > function parameter types since we rely on precise typing there for example > for points-to analysis (albeit only for restrict qualification processing and > for DECL_BY_REFERENCE "pointers"). That would fix the simple testcase > that was presented here. Even in that case you mustn't assume alignment for pointer comparisons, only for dereferences. Assuming it for comparisons breaks e.g. glibc's # define LC_GLOBAL_LOCALE ((locale_t) -1L) (locale_t is a pointer-to-pointer-aligned-struct) and other similar constructs involving magic constants (not dereferenced) of pointer type; comparisons of a locale_t value against LC_GLOBAL_LOCALE need to work. -- Joseph S. Myers jos...@codesourcery.com
Re: movmem pattern and missed alignment
On Tue, Oct 9, 2018 at 11:23 AM Jakub Jelinek wrote: > > On Tue, Oct 09, 2018 at 11:08:44AM +0200, Richard Biener wrote: > > On Tue, Oct 9, 2018 at 11:00 AM Alexander Monakov > > wrote: > > > > > > On Tue, 9 Oct 2018, Richard Biener wrote: > > > > > > > > then we cannot set the alignment of i_1 at/after k = *i_1 because doing > > > > so would > > > > affect the alignment test which we'd then optimize away. We'd need to > > > > introduce > > > > a SSA copy to get a new SSA name but that would be optimized away > > > > quickly. > > > > > > We preserve __builtin_assume_aligned up to pass-fold-all-builtins, so > > > would it > > > work to emit it just before the memcpy > > > > > > i_2 = __builtin_assume_aligned(i_1, 4); > > > __builtin_memcpy(j, i_2, 32); > > > > > > in theory? > > > > That's still before RTL expansion so I'm not sure that is enough. > > But we likely won't invalidate the computed SSA_NAME_INFO afterwards. But we've propagated out the i_2 = i_1 copy, no? Richard. > Jakub
Re: movmem pattern and missed alignment
On Tue, Oct 09, 2018 at 11:08:44AM +0200, Richard Biener wrote: > On Tue, Oct 9, 2018 at 11:00 AM Alexander Monakov wrote: > > > > On Tue, 9 Oct 2018, Richard Biener wrote: > > > > > > then we cannot set the alignment of i_1 at/after k = *i_1 because doing > > > so would > > > affect the alignment test which we'd then optimize away. We'd need to > > > introduce > > > a SSA copy to get a new SSA name but that would be optimized away quickly. > > > > We preserve __builtin_assume_aligned up to pass-fold-all-builtins, so would > > it > > work to emit it just before the memcpy > > > > i_2 = __builtin_assume_aligned(i_1, 4); > > __builtin_memcpy(j, i_2, 32); > > > > in theory? > > That's still before RTL expansion so I'm not sure that is enough. But we likely won't invalidate the computed SSA_NAME_INFO afterwards. Jakub
Re: movmem pattern and missed alignment
On Tue, Oct 9, 2018 at 11:00 AM Alexander Monakov wrote: > > On Tue, 9 Oct 2018, Richard Biener wrote: > > > > then we cannot set the alignment of i_1 at/after k = *i_1 because doing so > > would > > affect the alignment test which we'd then optimize away. We'd need to > > introduce > > a SSA copy to get a new SSA name but that would be optimized away quickly. > > We preserve __builtin_assume_aligned up to pass-fold-all-builtins, so would it > work to emit it just before the memcpy > > i_2 = __builtin_assume_aligned(i_1, 4); > __builtin_memcpy(j, i_2, 32); > > in theory? That's still before RTL expansion so I'm not sure that is enough. Richard. > > Alexander
Re: movmem pattern and missed alignment
On Tue, 9 Oct 2018, Richard Biener wrote: > > then we cannot set the alignment of i_1 at/after k = *i_1 because doing so > would > affect the alignment test which we'd then optimize away. We'd need to > introduce > a SSA copy to get a new SSA name but that would be optimized away quickly. We preserve __builtin_assume_aligned up to pass-fold-all-builtins, so would it work to emit it just before the memcpy i_2 = __builtin_assume_aligned(i_1, 4); __builtin_memcpy(j, i_2, 32); in theory? Alexander
Re: movmem pattern and missed alignment
> It was repeatedly suggested that we _could_ derive alignment info from > function parameter types since we rely on precise typing there for example > for points-to analysis (albeit only for restrict qualification processing > and for DECL_BY_REFERENCE "pointers"). That would fix the simple testcase > that was presented here. OK, I keep forgetting it and that would be a good compromise indeed. -- Eric Botcazou
Re: movmem pattern and missed alignment
On Tue, Oct 9, 2018 at 10:02 AM Andrew Haley wrote:
>
> On 10/08/2018 07:38 PM, Paul Koning wrote:
> >
> >
> >> On Oct 8, 2018, at 1:29 PM, Andrew Haley wrote:
> >>
> >> On 10/08/2018 06:20 PM, Michael Matz wrote:
> >>> Only if you somewhere visibly add accesses to *i and *j. Without them you
> >>> only have the "accesses" via memcpy, and as Richi says, those don't imply
> >>> any alignment requirements. The i and j pointers might validly be char*
> >>> pointers in disguise and hence be in fact only 1-aligned. I.e. there's
> >>> nothing in your small example program from which GCC can infer that those
> >>> two global pointers are in fact 2-aligned.
> >>
> >> So all you'd actually have to say is
> >>
> >> void f1(void)
> >> {
> >>*i; *j;
> >>__builtin_memcpy (i, j, 32);
> >> }
> >
> > No, that doesn't help.
>
> It could do.
>
> > Not even if I make it:
> >
> > void f1(void)
> > {
> > k = *i + *j;
> > __builtin_memcpy (i, j, 4);
> > }
> >
> > The first line does word aligned references to *i and *j, but the memcpy
> > stubbornly remains a byte move.
>
> Right, so that is a missed optimization.
Yes. Note that on GIMPLE alignment of pointers info is carried as
side-info for SSA names
which make the above cases difficult to deal with since the
dereference and the call argument
use the same SSA names. So if you consider
if (i_1 & 7 == 0)
{
k = *i_1;
__builtin_memcpy (i_1, j, 4);
}
then we cannot set the alignment of i_1 at/after k = *i_1 because doing so would
affect the alignment test which we'd then optimize away. We'd need to introduce
a SSA copy to get a new SSA name but that would be optimized away quickly.
So the option would be to change the representation of __builtin_memcpy
either by making it an aggregate assignment or by using a builtin with
explicit alignment or compute alignment at RTL expansion time.
Note the pass that "computes" alignment is currently SSA based (it's
the CCP pass).
Richard.
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd.
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
Re: movmem pattern and missed alignment
On Tue, Oct 9, 2018 at 8:41 AM Eric Botcazou wrote: > > > It's not quite obvious what SSE has to do with this - any hint please? > > SSE introduced alignment constraints into the non-strict-alignment target x86 > so people didn't really want to play by the rules of strict-alignment targets. Yeah. We've walked back and forth for that very issue though. We now require all targest to play by the same rules -- if you have a *(double *) access then that has to be aligned according to double. We couldn't realistically walk back and rely on alignment of addresses based on their type (like C would allow us to do) because we've thrown away types on addresses. See also the thread about string-length warning stuff where we've posted testcases that show you can get arbitrarily typed addresses into your strlen() calls for example by means of CSE. The middle-end is simply not prepared to preserve that information. It was repeatedly suggested that we _could_ derive alignment info from function parameter types since we rely on precise typing there for example for points-to analysis (albeit only for restrict qualification processing and for DECL_BY_REFERENCE "pointers"). That would fix the simple testcase that was presented here. > > (according to my quick check this changed between gcc-4.5 and gcc-4.6) > > Possibly indeed, I remembered GCC 4.5 as being the turning point. It was really changing over several releases, but yes. Richard. > > -- > Eric Botcazou
Re: movmem pattern and missed alignment
On 10/08/2018 07:38 PM, Paul Koning wrote:
>
>
>> On Oct 8, 2018, at 1:29 PM, Andrew Haley wrote:
>>
>> On 10/08/2018 06:20 PM, Michael Matz wrote:
>>> Only if you somewhere visibly add accesses to *i and *j. Without them you
>>> only have the "accesses" via memcpy, and as Richi says, those don't imply
>>> any alignment requirements. The i and j pointers might validly be char*
>>> pointers in disguise and hence be in fact only 1-aligned. I.e. there's
>>> nothing in your small example program from which GCC can infer that those
>>> two global pointers are in fact 2-aligned.
>>
>> So all you'd actually have to say is
>>
>> void f1(void)
>> {
>>*i; *j;
>>__builtin_memcpy (i, j, 32);
>> }
>
> No, that doesn't help.
It could do.
> Not even if I make it:
>
> void f1(void)
> {
> k = *i + *j;
> __builtin_memcpy (i, j, 4);
> }
>
> The first line does word aligned references to *i and *j, but the memcpy
> stubbornly remains a byte move.
Right, so that is a missed optimization.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd.
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
