named address space problem

[Marc Poulhies]

Hi !

While porting a GCC 4.9 private port to GCC 7, I've encountered an issue with 
named address space support.

I have defined the following target macros:

#define K1_ADDR_SPACE_UNCACHED 1
#define K1_ADDR_SPACE_CONVERT 2

 TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P (returns false for CONVERT, regular 
legitimate hook for other as)
 TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS (raises an error if using CONVERT as or 
calls regular legitimize_address hook)
 TARGET_ADDR_SPACE_SUBSET_P (always true)
 TARGET_ADDR_SPACE_CONVERT (emits a warning if not to/from CONVERT as and 
always returns first operand)

#define REGISTER_TARGET_PRAGMAS() do {   \
   c_register_addr_space ("__uncached", K1_ADDR_SPACE_UNCACHED); \
   c_register_addr_space ("__convert", K1_ADDR_SPACE_CONVERT); \
 } while (0)

The usage is very basic and is used to drive the insn selection to use 
cached/uncached variants for load/store.
Pointers are declared with `__uncached` to use uncached variants and 
`__convert` is used when converting pointers to/from this uncached space.
It works as expected on GCC 4.9.

On our current port on GCC 7 (using latest gcc-7-branch branch), we have an 
issue with simple code:

```
typedef struct {
 unsigned long count;
} foo_t;  

unsigned long foobar(foo_t *cond, int bar)
{
  if (bar == 1 ) {
  }
  __uncached foo_t *ucond = cond;
  return ucond->count;
}
```

Raises the following error:

```
: In function 'foobar':
:9:3: error: unknown type name '__uncached'
   __uncached foo_t *ucond = cond;
   ^~

:9:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 
'*' token
   __uncached foo_t *ucond = cond;
^
:10:10: error: 'ucond' undeclared (first use in this function); did you 
mean 'cond'?
   return ucond->count;
  ^
  cond
:10:10: note: each undeclared identifier is reported only once for each 
function it appears in
Compiler returned: 1
```

The following changes make the code compile as expected:

 - moving the variable declaration at the beginning of the block
 - opening a block before the declaration and closing it after the return stmt.

I could not find a matching PR in bugzilla.
Do you know of any issue with this ? Maybe this has been fixed in later 
versions.

Thanks,
Marc

Re: Warning: unpredictable: identical transfer and status registers --`stxr w4,x5,[x4] using aarch64 poky gcc 8.3

[Segher Boessenkool]

OneWed, Feb 13, 2019 at 07:13:21AM +, Peng Fan wrote:
> We met an issue when building a piece jailhouse hypervisor code, "stxr   %w0, 
> %3, %2\n\t" is 
> compiled as "stxr w4,x5,[x4]" which triggers the warning 
> "Warning: unpredictable: identical transfer and status registers"

This is not a GCC question.

The three registers, in order, are status, transfer, and base.  The warning
claims transfer and status are identical, but in fact base and status are.
The code (in binutils, gas/config/tc-aarch64.c) is

case ldstexcl:
  /* It is unpredictable if the destination and status registers are the
 same.  */
  if ((aarch64_get_operand_class (opnds[0].type)
   == AARCH64_OPND_CLASS_INT_REG)
  && (aarch64_get_operand_class (opnds[1].type)
  == AARCH64_OPND_CLASS_INT_REG)
  && (opnds[0].reg.regno == opnds[1].reg.regno
  || opnds[0].reg.regno == opnds[2].reg.regno))
as_warn (_("unpredictable: identical transfer and status registers"
   " --`%s'"),
 str);

so either that op0 == op2 test is spurious, or the warning message is
misleading.

Please ask on binut...@sourceware.org and/or file a bug at
https://sourceware.org/bugzilla/ ?


Segher

Re: question about inlining long call sequence

[Bin.Cheng]

On Tue, Feb 12, 2019 at 6:16 PM Martin Jambor  wrote:
>
> On Tue, Feb 12 2019, Bin.Cheng wrote:
> > Hi,
> > When reading inlining code in GCC, I wonder if we have size heuristics
> > to limit inlining long call sequence?  For example, for call sequence
> > A -> B -> C -> D -> ... -> X -> Y -> Z
> > if each function call grows size by a very small amount, inlining Z
> > all the way up to the outermost function could result in a big
> > function which may hurt icache.  Is this case handled in inliner? if
> > yes, which code handles this?  Thanks in advance.
> >
> > BTW, I am using GCC 6, not sure if trunk has different behavior.
>
> I believe it is done in caller_growth_limits() in ipa-inline.c in both
> trunk and GCC 6.  The following comment in the function might shed a bit
> more light on the behavior regarding big functions:
>
>   /* Look for function e->caller is inlined to.  While doing
>  so work out the largest function body on the way.  As
>  described above, we want to base our function growth
>  limits based on that.  Not on the self size of the
>  outer function, not on the self size of inline code
>  we immediately inline to.  This is the most relaxed
>  interpretation of the rule "do not grow large functions
>  too much in order to prevent compiler from exploding".  */
Thanks, assume it's below code collecting maximum code size limit
along call stack:

  while (true)
{
  info = inline_summaries->get (to);
  if (limit < info->self_size)
limit = info->self_size;
  if (stack_size_limit < info->estimated_self_stack_size)
stack_size_limit = info->estimated_self_stack_size;
  if (to->global.inlined_to)
to = to->callers->caller;

Question is it only collects the maximum self_size of outer callers,
since we are inlining from outer function to inner, only check
self_size of caller means we can still get bloated size for some
cases? Or what piece of code I have missed?

Another question is in want_inline_small_function_p:

  /* Apply MAX_INLINE_INSNS_AUTO limit for functions not declared inline
 Upgrade it to MAX_INLINE_INSNS_SINGLE when hints suggests that
 inlining given function is very profitable.  */
  else if (!DECL_DECLARED_INLINE_P (callee->decl)
   && !big_speedup
   && !(hints & INLINE_HINT_known_hot)
   && growth >= ((hints & (INLINE_HINT_indirect_call
   | INLINE_HINT_loop_iterations
   | INLINE_HINT_array_index
   | INLINE_HINT_loop_stride))
 ? MAX (MAX_INLINE_INSNS_AUTO,
MAX_INLINE_INSNS_SINGLE)
 : MAX_INLINE_INSNS_AUTO))
So for function not declared as inline, if it's considered as
known_hot, there will be no size restriction at all.  This looks like
an issue to me, given we do restrict size even for know_hot function
which is declared as inline:

  /* Apply MAX_INLINE_INSNS_SINGLE limit.  Do not do so when
 hints suggests that inlining given function is very profitable.  */
  else if (DECL_DECLARED_INLINE_P (callee->decl)
   && growth >= MAX_INLINE_INSNS_SINGLE
   && ((!big_speedup
&& !(hints & (INLINE_HINT_indirect_call
  | INLINE_HINT_known_hot
  | INLINE_HINT_loop_iterations
  | INLINE_HINT_array_index
  | INLINE_HINT_loop_stride)))
   || growth >= MAX_INLINE_INSNS_SINGLE * 16))

Again, this is on GCC6.

Thanks,
bin
>
> HTH
>
> Martin

RE: Warning: unpredictable: identical transfer and status registers --`stxr w4,x5,[x4] using aarch64 poky gcc 8.3

[Peng Fan]

> -Original Message-
> From: jailhouse-...@googlegroups.com
> [mailto:jailhouse-...@googlegroups.com] On Behalf Of Segher Boessenkool
> Sent: 2019年2月13日 17:11
> To: Peng Fan 
> Cc: gcc@gcc.gnu.org; james.greenha...@arm.com; n...@arm.com;
> jailhouse-...@googlegroups.com; will.dea...@arm.com; Catalin Marinas
> 
> Subject: Re: Warning: unpredictable: identical transfer and status registers
> --`stxr w4,x5,[x4] using aarch64 poky gcc 8.3
> 
> OneWed, Feb 13, 2019 at 07:13:21AM +, Peng Fan wrote:
> > We met an issue when building a piece jailhouse hypervisor code,
> "stxr   %w0, %3, %2\n\t" is
> > compiled as "stxr w4,x5,[x4]" which triggers the warning
> > "Warning: unpredictable: identical transfer and status registers"
> 
> This is not a GCC question.
> 
> The three registers, in order, are status, transfer, and base.  The warning
> claims transfer and status are identical, but in fact base and status are.
> The code (in binutils, gas/config/tc-aarch64.c) is
> 
> case ldstexcl:
>   /* It is unpredictable if the destination and status registers are the
>  same.  */
>   if ((aarch64_get_operand_class (opnds[0].type)
>== AARCH64_OPND_CLASS_INT_REG)
>   && (aarch64_get_operand_class (opnds[1].type)
>   == AARCH64_OPND_CLASS_INT_REG)
>   && (opnds[0].reg.regno == opnds[1].reg.regno
>   || opnds[0].reg.regno == opnds[2].reg.regno))
> as_warn (_("unpredictable: identical transfer and status registers"
>" --`%s'"),
>  str);
> 
> so either that op0 == op2 test is spurious, or the warning message is
> misleading.

From aarch64 spec, "stxr w4,x5,[x4]"'s behavior is chip implementation defined,
so I think the warning is correct.

> 
> Please ask on binut...@sourceware.org and/or file a bug at
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsour
> ceware.org%2Fbugzilla%2F&data=02%7C01%7Cpeng.fan%40nxp.com%
> 7C2463376de5aa417d3d6508d69197e4df%7C686ea1d3bc2b4c6fa92cd99c5c
> 301635%7C0%7C0%7C636856478900947075&sdata=pg%2FZmo91Cxfji
> ESlBiR5shmsdxoYWslpfZeAXk5TV30%3D&reserved=0 ?

Ok. I'll post questions to binut...@sourceware.org

Thanks,
Peng.

> 
> 
> Segher
> 
> --
> You received this message because you are subscribed to the Google Groups
> "Jailhouse" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jailhouse-dev+unsubscr...@googlegroups.com.
> For more options, visit
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrou
> ps.google.com%2Fd%2Foptout&data=02%7C01%7Cpeng.fan%40nxp.co
> m%7C2463376de5aa417d3d6508d69197e4df%7C686ea1d3bc2b4c6fa92cd9
> 9c5c301635%7C0%7C0%7C636856478900947075&sdata=oiNHshxQvku
> OjuTiRKlK%2F3em5DIGNysm1UbZZKuHcjg%3D&reserved=0.

Re: Warning: unpredictable: identical transfer and status registers --`stxr w4,x5,[x4] using aarch64 poky gcc 8.3

[Andreas Schwab]

On Feb 13 2019, Peng Fan  wrote:

> static inline int test_and_set_bit(int nr, volatile unsigned long *addr)
> {
> u32 ret;
> u64 test, tmp;
>
> BITOPT_ALIGN(nr, addr);
>
> /* AARCH64_TODO: using Inner Shareable DMB at the moment,
>  * revisit when we will deal with shareability domains */
>
> do {
> asm volatile (
> "ldxr   %3, %2\n\t"
> "ands   %1, %3, %4\n\t"
> "b.ne   1f\n\t"
> "orr%3, %3, %4\n\t"
> "1:\n\t"
> "stxr   %w0, %3, %2\n\t"
> "dmbish\n\t"
> : "=r" (ret), "=&r" (test),
>   "+Q" (*(volatile unsigned long *)addr),
>   "=r" (tmp)
> : "r" (1ul << nr));

%3 is modified early, but not marked earlyclobber.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Warning: unpredictable: identical transfer and status registers --`stxr w4,x5,[x4] using aarch64 poky gcc 8.3

[Michael Matz]

Hi,

On Wed, 13 Feb 2019, Peng Fan wrote:

> asm volatile (
> "ldxr   %3, %2\n\t"
> "ands   %1, %3, %4\n\t"
> "b.ne   1f\n\t"
> "orr%3, %3, %4\n\t"
> "1:\n\t"
> "stxr   %w0, %3, %2\n\t"
> "dmbish\n\t"
> : "=r" (ret), "=&r" (test),
>   "+Q" (*(volatile unsigned long *)addr),
>   "=r" (tmp)
> : "r" (1ul << nr));

As Andreas says, you need to add an early-clobber for op3 for correctness 
(to force it into a different register from op4).  And you also need an 
early-clobber on op0 to force it into a different register from op2 (which 
for purposes of register assignment is an input operand holding an 
address).


Ciao,
Michael.

RE: Warning: unpredictable: identical transfer and status registers --`stxr w4,x5,[x4] using aarch64 poky gcc 8.3

[Peng Fan]

> -Original Message-
> From: Andreas Schwab [mailto:sch...@suse.de]
> Sent: 2019年2月13日 21:59
> To: Peng Fan 
> Cc: gcc@gcc.gnu.org; james.greenha...@arm.com; n...@arm.com;
> jailhouse-...@googlegroups.com; will.dea...@arm.com; Catalin Marinas
> 
> Subject: Re: Warning: unpredictable: identical transfer and status registers
> --`stxr w4,x5,[x4] using aarch64 poky gcc 8.3
> 
> On Feb 13 2019, Peng Fan  wrote:
> 
> > static inline int test_and_set_bit(int nr, volatile unsigned long
> > *addr) {
> > u32 ret;
> > u64 test, tmp;
> >
> > BITOPT_ALIGN(nr, addr);
> >
> > /* AARCH64_TODO: using Inner Shareable DMB at the moment,
> >  * revisit when we will deal with shareability domains */
> >
> > do {
> > asm volatile (
> > "ldxr   %3, %2\n\t"
> > "ands   %1, %3, %4\n\t"
> > "b.ne   1f\n\t"
> > "orr%3, %3, %4\n\t"
> > "1:\n\t"
> > "stxr   %w0, %3, %2\n\t"
> > "dmbish\n\t"
> > : "=r" (ret), "=&r" (test),
> >   "+Q" (*(volatile unsigned long *)addr),
> >   "=r" (tmp)
> > : "r" (1ul << nr));
> 
> %3 is modified early, but not marked earlyclobber.

Thanks, I'll try add earlyclobber.

Peng

> 
> Andreas.
> 
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196
> BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7 "And now for something
> completely different."

RE: Warning: unpredictable: identical transfer and status registers --`stxr w4,x5,[x4] using aarch64 poky gcc 8.3

[Peng Fan]

Hi Michael,

> -Original Message-
> From: Michael Matz [mailto:m...@suse.de]
> Sent: 2019年2月13日 22:28
> To: Peng Fan 
> Cc: gcc@gcc.gnu.org; james.greenha...@arm.com; n...@arm.com;
> jailhouse-...@googlegroups.com; will.dea...@arm.com; Catalin Marinas
> 
> Subject: Re: Warning: unpredictable: identical transfer and status registers
> --`stxr w4,x5,[x4] using aarch64 poky gcc 8.3
> 
> Hi,
> 
> On Wed, 13 Feb 2019, Peng Fan wrote:
> 
> > asm volatile (
> > "ldxr   %3, %2\n\t"
> > "ands   %1, %3, %4\n\t"
> > "b.ne   1f\n\t"
> > "orr%3, %3, %4\n\t"
> > "1:\n\t"
> > "stxr   %w0, %3, %2\n\t"
> > "dmbish\n\t"
> > : "=r" (ret), "=&r" (test),
> >   "+Q" (*(volatile unsigned long *)addr),
> >   "=r" (tmp)
> > : "r" (1ul << nr));
> 
> As Andreas says, you need to add an early-clobber for op3 for correctness (to
> force it into a different register from op4).  And you also need an
> early-clobber on op0 to force it into a different register from op2 (which for
> purposes of register assignment is an input operand holding an address).

So the fix should be the following, right?
do {
asm volatile (
"ldxr   %3, %2\n\t"
"ands   %1, %3, %4\n\t"
"b.ne   1f\n\t"
"orr%3, %3, %4\n\t"
"1:\n\t"
"stxr   %w0, %3, %2\n\t"
"dmbish\n\t"
: "=&r" (ret), "=&r" (test),
  "+Q" (*(volatile unsigned long *)addr),
  "=&r" (tmp)
: "r" (1ul << nr));
} while (ret);

Thanks,
Peng.

> 
> 
> Ciao,
> Michael.

RE: Warning: unpredictable: identical transfer and status registers --`stxr w4,x5,[x4] using aarch64 poky gcc 8.3

[Michael Matz]

Hi,

On Wed, 13 Feb 2019, Peng Fan wrote:

> So the fix should be the following, right?

Yup.


Ciao,
Michael.

Question: after gcc intallation

[Chang-Hsin Daniel Chen]

Hi GCC,

This is Daniel. I use fedora 29 and have install gcc-8.2.0 into the system. 
However, I still cannot see GCC on the list what I do "module av".

I have added the path of the gcc directory into .bashrc. However, nothing 
changes.
"export PATH=$PATH:/..."
"export LD_LIBRARY_PATH=$PATH:/..."

Could you tell me what should I do after installation to link gcc to the system?

Thanks,
Daniel

Re: Question: after gcc intallation

[Jonathan Wakely]

On Wed, 13 Feb 2019 at 16:18, Chang-Hsin Daniel Chen
 wrote:
>
> Hi GCC,
>
> This is Daniel. I use fedora 29 and have install gcc-8.2.0 into the system.

Why? Fedora 29 already has GCC 8.2.1

How did you install it? What commands did you run?

>However, I still cannot see GCC on the list what I do "module av".

What is that command for?

> I have added the path of the gcc directory into .bashrc. However, nothing 
> changes.
> "export PATH=$PATH:/..."

This is not useful, we can't tell if you did this right when you show
a nonsense path like "/..."

> "export LD_LIBRARY_PATH=$PATH:/..."

Same reply, and shouldn't that be LD_LIBRARY_PATH not PATH?


> Could you tell me what should I do after installation to link gcc to the 
> system?

No, because

Re: Question: after gcc intallation

[Jonathan Wakely]

Oh and this is the wrong mailing list, please use gcc-h...@gcc.gnu.org instead.

On Wed, 13 Feb 2019 at 17:11, Jonathan Wakely  wrote:
>
> On Wed, 13 Feb 2019 at 16:18, Chang-Hsin Daniel Chen
>  wrote:
> >
> > Hi GCC,
> >
> > This is Daniel. I use fedora 29 and have install gcc-8.2.0 into the system.
>
> Why? Fedora 29 already has GCC 8.2.1
>
> How did you install it? What commands did you run?
>
> >However, I still cannot see GCC on the list what I do "module av".
>
> What is that command for?
>
> > I have added the path of the gcc directory into .bashrc. However, nothing 
> > changes.
> > "export PATH=$PATH:/..."
>
> This is not useful, we can't tell if you did this right when you show
> a nonsense path like "/..."
>
> > "export LD_LIBRARY_PATH=$PATH:/..."
>
> Same reply, and shouldn't that be LD_LIBRARY_PATH not PATH?
>
>
> > Could you tell me what should I do after installation to link gcc to the 
> > system?
>
> No, because

Re: GSoC 2019

[Martin Jambor]

Hello Parashuram,

On Tue, Feb 12 2019, Shourya IIT B wrote:
> Respected Sir,
>
>I am Parashuram Shourya from India. Currently, I am doing my
> Master’s in Geoinformatics from Centre of Studies in Resources
> Engineering(CSRE),
> Indian Institute of Technology Bombay(IITB). I have a Bachelor's degree in
> Computer Science and Engineering.
>
> Currently, I am learning Machine Learning and High-Performance Computing. I
> have vast programming experience in C, C++, Python
>
>   I would love to contribute to GNU Compiler Collection in the upcoming
> Google Summer of Code 2019. I would be very grateful to get any directions
> to start with so that I can pursue and participate in GSoC 2019 with your
> organization.

we are delighted you found contributing to GCC interesting.  Please look
again at the "Before you apply" section of our GSoC wiki page at
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make sure you
are able to build, install and test GCC and then have it generate dumps
and step through some function during compilation.

Afterwards, if you still find contributing to GCC appealing, look at
a suggested idea, try to identify the portion of GCC source which is
involved and email us back to the mailing list, describing which idea
you liked best and what your thoughts about it are.

Good luck,

Martin

F&B #Trending Recipes

[F&B Magazine]

#Trending Recipes  

View In The Web  


























 
MICHAEL POLITZ, 1930 Village Center Cir 3197, Las Vegas, Nevada, 89134, United 
States

UNSUBSCRIBE