Re: An odd case with structure field alignment.

[Richard Biener via Gcc]

On Sun, Sep 4, 2022 at 3:33 PM Iain Sandoe  wrote:
>
> Hi,
>
> I am clearly missing something here … can someone point out where it is?
>
> https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Variable-Attributes.html#Variable%20Attributes
> in the discussion of applying this to structure fields:
>
> "The aligned attribute can only increase the alignment; but you can decrease 
> it by specifying packed as well."
>
> Consider:
>
> struct odd {
>   int * __attribute__((aligned(2))) a;

I think this applies the attribute to the type.  For non-aggregate
types 'packed' is ignored.  So the above
is equivalent to

typedef int *A __attribute__((aligned(2)));

struct odd {
  A a;
  char c;
};

>   char c;
> };
>
> I would expect, given reading of the information on the aligned attribute, 
> that the under-alignment of a would be ignored (since there is no packed 
> attribute on either the field or the struct).
>
> However, on x86_64, powerpc64 linux and x86_64, powerpc Darwin, I see that 
> the size of the struct is sizeof(pointer) + 2 and the alignment is 2.
>
> OTOH:
>
> struct OK {
>   int  __attribute__((aligned(2))) a;
>   char c;
> };
>
> behaves as expected (the under-alignment is ignored, silently).
>
> as does this…
>
> struct maybe {
>   int *a  __attribute__((aligned(2)));
>   char c;
> };

Where for both of these cases the attribute applies to the FIELD_DECL.
The documentation refers to
alignment of fields, not the alignment of types.

At least that's my understanding of this issue.

IIRC clang has issues when matching GCC attribute parsing rules, esp.
when applied to pointer types.

Richard.

> * the type of the pointer does not seem to be relevant (i.e. AFAICT the 
> behaviour is the same for char * etc.)
>
> Is there some special rule about pointers that I have not found ?
>
> [it’s making an ABI mismatch with clang, which treats the int * as expected 
> from the documentation quoted above]
>
> cheers
> Iain
>
>
>

Re: An odd case with structure field alignment.

[Iain Sandoe]

> On 5 Sep 2022, at 09:53, Richard Biener via Gcc  wrote:
> 
> On Sun, Sep 4, 2022 at 3:33 PM Iain Sandoe  wrote:
>> 
>> Hi,
>> 
>> I am clearly missing something here … can someone point out where it is?
>> 
>> https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Variable-Attributes.html#Variable%20Attributes
>> in the discussion of applying this to structure fields:
>> 
>> "The aligned attribute can only increase the alignment; but you can decrease 
>> it by specifying packed as well."
>> 
>> Consider:
>> 
>> struct odd {
>>  int * __attribute__((aligned(2))) a;
> 
> I think this applies the attribute to the type.  

That was what I wondered - but it does not seem to apply the under-alignment to 
a non-pointer type ...

> For non-aggregate
> types 'packed' is ignored.  So the above
> is equivalent to
> 
> typedef int *A __attribute__((aligned(2)));
> 
> struct odd {
>  A a;
>  char c;
> };

Which (for the record) works as expected on both compilers.
> 
>>  char c;
>> };
>> 
>> I would expect, given reading of the information on the aligned attribute, 
>> that the under-alignment of a would be ignored (since there is no packed 
>> attribute on either the field or the struct).
>> 
>> However, on x86_64, powerpc64 linux and x86_64, powerpc Darwin, I see that 
>> the size of the struct is sizeof(pointer) + 2 and the alignment is 2.
>> 
>> OTOH:
>> 
>> struct OK {
>>  int  __attribute__((aligned(2))) a;
>>  char c;
>> };

However, this does _not_ treat the same sequence as “typedef int A 
__attribute__((aligned(2)))”

>> behaves as expected (the under-alignment is ignored, silently).
>> 
>> as does this…
>> 
>> struct maybe {
>>  int *a  __attribute__((aligned(2)));
>>  char c;
>> };
> 
> Where for both of these cases the attribute applies to the FIELD_DECL.

> The documentation refers to
> alignment of fields, not the alignment of types.

sure, but I can’t at the moment see a consistent rule to file a bug about.

> At least that's my understanding of this issue.
> 
> IIRC clang has issues when matching GCC attribute parsing rules, esp.
> when applied to pointer types.

probably; when I looked at the decls produced there seemed to be no way to
to tell the position of the attribute in the decl (so to decide if it’s a type 
attr or a
field attr). … possibly that means poking at the parser too… 

attributes in aggregates are fun, for sure ..  

Iain

> 
> Richard.
> 
>> * the type of the pointer does not seem to be relevant (i.e. AFAICT the 
>> behaviour is the same for char * etc.)
>> 
>> Is there some special rule about pointers that I have not found ?
>> 
>> [it’s making an ABI mismatch with clang, which treats the int * as expected 
>> from the documentation quoted above]
>> 
>> cheers
>> Iain

Re: Setting test suite not to try debug output cases

[Richard Biener via Gcc]

On Fri, Sep 2, 2022 at 8:57 PM Koning, Paul via Gcc  wrote:
>
> Given that pdp11 no longer supports debug output, I get a lot more test 
> failures, like this:
>
> spawn -ignore SIGHUP /Users/pkoning/Documents/svn/build/pdp/gcc/xgcc 
> -B/Users/pkoning/Documents/svn/build/pdp/gcc/ -mlra 
> -fdiagnostics-plain-output -Og -g -w -c -o 2105-1.o 
> /Users/pkoning/Documents/svn/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c
> xgcc: warning: target system does not support debug output
> cc1: warning: target system does not support debug output
> FAIL: gcc.c-torture/compile/2105-1.c   -Og -g  (test for excess errors)
>
> I assume there is some way in the test suite machinery to globally skip all 
> "debug output" cases.  How would I do that?

Hmm.  In testsuite/lib/prune.exp there's

# Ignore stabs obsoletion warnings
regsub -all "(^|\n)\[^\n\]*\[Ww\]arning: STABS debugging
information is obsolete and not supported anymore\[^\n\]*" $text ""
text

maybe you can (selectively for pdp11) add similar pruning of the
'target system does not support debug output' message?
I think you should be able to use

   if { [istarget pdp11-*-*] } then {
 regsub -all " ... " ...
   }

>
> paul
>

Re: Setting test suite not to try debug output cases

[Koning, Paul via Gcc]

> On Sep 5, 2022, at 5:29 AM, Richard Biener  wrote:
> 
> 
> [EXTERNAL EMAIL] 
> 
> On Fri, Sep 2, 2022 at 8:57 PM Koning, Paul via Gcc  wrote:
>> 
>> Given that pdp11 no longer supports debug output, I get a lot more test 
>> failures, like this:
>> 
>> spawn -ignore SIGHUP /Users/pkoning/Documents/svn/build/pdp/gcc/xgcc 
>> -B/Users/pkoning/Documents/svn/build/pdp/gcc/ -mlra 
>> -fdiagnostics-plain-output -Og -g -w -c -o 2105-1.o 
>> /Users/pkoning/Documents/svn/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c
>> xgcc: warning: target system does not support debug output
>> cc1: warning: target system does not support debug output
>> FAIL: gcc.c-torture/compile/2105-1.c   -Og -g  (test for excess errors)
>> 
>> I assume there is some way in the test suite machinery to globally skip all 
>> "debug output" cases.  How would I do that?
> 
> Hmm.  In testsuite/lib/prune.exp there's
> 
># Ignore stabs obsoletion warnings
>regsub -all "(^|\n)\[^\n\]*\[Ww\]arning: STABS debugging
> information is obsolete and not supported anymore\[^\n\]*" $text ""
> text
> 
> maybe you can (selectively for pdp11) add similar pruning of the
> 'target system does not support debug output' message?
> I think you should be able to use
> 
>   if { [istarget pdp11-*-*] } then {
> regsub -all " ... " ...
>   }

Thanks, I'll look into that.  Should it be more general to cover any other 
targets that don't have debug output?  I think pdp11 isn't the only one but I'm 
not sure.

paul

Re: Setting test suite not to try debug output cases

[Richard Biener via Gcc]

On Mon, Sep 5, 2022 at 2:23 PM Koning, Paul  wrote:
>
>
>
> > On Sep 5, 2022, at 5:29 AM, Richard Biener  
> > wrote:
> >
> >
> > [EXTERNAL EMAIL]
> >
> > On Fri, Sep 2, 2022 at 8:57 PM Koning, Paul via Gcc  wrote:
> >>
> >> Given that pdp11 no longer supports debug output, I get a lot more test 
> >> failures, like this:
> >>
> >> spawn -ignore SIGHUP /Users/pkoning/Documents/svn/build/pdp/gcc/xgcc 
> >> -B/Users/pkoning/Documents/svn/build/pdp/gcc/ -mlra 
> >> -fdiagnostics-plain-output -Og -g -w -c -o 2105-1.o 
> >> /Users/pkoning/Documents/svn/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c
> >> xgcc: warning: target system does not support debug output
> >> cc1: warning: target system does not support debug output
> >> FAIL: gcc.c-torture/compile/2105-1.c   -Og -g  (test for excess errors)
> >>
> >> I assume there is some way in the test suite machinery to globally skip 
> >> all "debug output" cases.  How would I do that?
> >
> > Hmm.  In testsuite/lib/prune.exp there's
> >
> ># Ignore stabs obsoletion warnings
> >regsub -all "(^|\n)\[^\n\]*\[Ww\]arning: STABS debugging
> > information is obsolete and not supported anymore\[^\n\]*" $text ""
> > text
> >
> > maybe you can (selectively for pdp11) add similar pruning of the
> > 'target system does not support debug output' message?
> > I think you should be able to use
> >
> >   if { [istarget pdp11-*-*] } then {
> > regsub -all " ... " ...
> >   }
>
> Thanks, I'll look into that.  Should it be more general to cover any other 
> targets that don't have debug output?  I think pdp11 isn't the only one but 
> I'm not sure.

True - pruning generally sounds more useful.

Richard.

> paul
>

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Alejandro Colomar via Gcc]

Hi Martin,

On 9/3/22 22:02, Alejandro Colomar wrote:

We thought about using this syntax

int foo(char buf[.n], int n);


BTW, it would be useful if this syntax was accepted for void * too, 
especially since GNU C allows pointer arithmetic on void *.


void *memmove(void dest[.n], const void src[.n], size_t n);

I understand that a void array doesn't make sense, so defining a VLA of 
type void is an error elsewhere, but since array parameters are not 
really arrays, and instead pointers, this could be reasonable.


The same that these "arrays" can have zero sizes, or even negative ones 
in some weird cases.


Cheers,

Alex

--
Alejandro Colomar



OpenPGP_signature
Description: OpenPGP digital signature

Re: RISC-V V C Intrinsic API v1.0 release meeting reminder (Sep 05, 2022)

[eop Chen]

The meeting minute is updated in the document of the Google calendar link. 


Regards,

eop Chen

> eop Chen  於 2022年9月1日 下午1:15 寫道：
> 
> 
> Hi all,
> 
> A reminder that an open meeting to draft the RISC-V V C Intrinsic API v1.0 
> release is going to
> be held on next Monday 2022/09/05 7AM (GMT -7) / 10PM (GMT +8). The planned 
> agenda will
> be to have a roundtable of introductions for participants and briefly go over 
> milestones for
> v1.0 release so we can extend the discussions offline in the issue threads.
> 
> Please join the calendar to be constantly notified - Google calender link 
> ,
>  ICal 
> 
> 
> Regards,
> 
> eop Chen