* Problem in cxx_fundamental_alignment_p?
@ 2016-06-29 19:21 Bernd Schmidt
2016-07-01 8:34 ` Dodji Seketeli
0 siblings, 1 reply; 4+ messages in thread
From: Bernd Schmidt @ 2016-06-29 19:21 UTC (permalink / raw)
To: GCC Patches, Dodji Seketeli
[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]
I came across what I think is a bug in cxx_fundamental_alignment_p.
User alignments are specified in units of bytes. This is documented, and
we can also see the following in handle_aligned_attribute, for the case
when we have no args:
align_expr = size_int (ATTRIBUTE_ALIGNED_VALUE / BITS_PER_UNIT);
Then, we compute the log of that alignment in check_user_alignment:
i = check_user_alignment (align_expr, true)
That's the log of the alignment in bytes, as we can see a little further
down:
SET_TYPE_ALIGN (*type, (1U << i) * BITS_PER_UNIT);
Then, we call check_cxx_fundamental_alignment_constraints, which
recomputes the alignment (in bytes) from that log:
unsigned requested_alignment = 1U << align_log;
It then calls cxx_fundamental_alignment_p, where we compare it to
TYPE_ALIGN values, which are specified in bits. So I think we have a
mismatch there.
Does that sound right? The patch below was bootstrapped and tested on
x86_64-linux, without issues, but I'm not convinced this code is covered
by any testcase. Dodji?
Bernd
[-- Attachment #2: fundamental-align.diff --]
[-- Type: text/x-patch, Size: 1842 bytes --]
* c-common.c (cxx_fundamental_alignment_p): Use TYPE_ALIGN_UNIT,
not TYPE_ALIGN.
Index: gcc/c-family/c-common.c
===================================================================
--- gcc/c-family/c-common.c (revision 237797)
+++ gcc/c-family/c-common.c (working copy)
@@ -7668,10 +7668,10 @@ fail:
return NULL_TREE;
}
-/* Check whether ALIGN is a valid user-specified alignment. If so,
- return its base-2 log; if not, output an error and return -1. If
- ALLOW_ZERO then 0 is valid and should result in a return of -1 with
- no error. */
+/* Check whether ALIGN is a valid user-specified alignment, specified
+ in bytes. If so, return its base-2 log; if not, output an error
+ and return -1. If ALLOW_ZERO then 0 is valid and should result in
+ a return of -1 with no error. */
int
check_user_alignment (const_tree align, bool allow_zero)
{
@@ -12700,9 +12700,9 @@ scalar_to_vector (location_t loc, enum t
return stv_nothing;
}
-/* Return true iff ALIGN is an integral constant that is a fundamental
- alignment, as defined by [basic.align] in the c++-11
- specifications.
+/* Return true iff ALIGN, which is specified in bytes, is an integral
+ constant that is a fundamental alignment, as defined by
+ [basic.align] in the c++-11 specifications.
That is:
@@ -12712,10 +12712,11 @@ scalar_to_vector (location_t loc, enum t
alignof(max_align_t)]. */
bool
-cxx_fundamental_alignment_p (unsigned align)
+cxx_fundamental_alignment_p (unsigned align)
{
- return (align <= MAX (TYPE_ALIGN (long_long_integer_type_node),
- TYPE_ALIGN (long_double_type_node)));
+ unsigned limit = MAX (TYPE_ALIGN_UNIT (long_long_integer_type_node),
+ TYPE_ALIGN_UNIT (long_double_type_node));
+ return align <= limit;
}
/* Return true if T is a pointer to a zero-sized aggregate. */
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Problem in cxx_fundamental_alignment_p?
2016-06-29 19:21 Problem in cxx_fundamental_alignment_p? Bernd Schmidt
@ 2016-07-01 8:34 ` Dodji Seketeli
2016-07-01 9:56 ` Bernd Schmidt
0 siblings, 1 reply; 4+ messages in thread
From: Dodji Seketeli @ 2016-07-01 8:34 UTC (permalink / raw)
To: Bernd Schmidt; +Cc: GCC Patches
Hello Bernd,
Bernd Schmidt <bschmidt@redhat.com> writes:
> I came across what I think is a bug in cxx_fundamental_alignment_p.
>
> User alignments are specified in units of bytes. This is documented,
> and we can also see the following in handle_aligned_attribute, for the
> case when we have no args:
> align_expr = size_int (ATTRIBUTE_ALIGNED_VALUE / BITS_PER_UNIT);
> Then, we compute the log of that alignment in check_user_alignment:
> i = check_user_alignment (align_expr, true)
> That's the log of the alignment in bytes, as we can see a little
> further down:
> SET_TYPE_ALIGN (*type, (1U << i) * BITS_PER_UNIT);
>
> Then, we call check_cxx_fundamental_alignment_constraints, which
> recomputes the alignment (in bytes) from that log:
> unsigned requested_alignment = 1U << align_log;
> It then calls cxx_fundamental_alignment_p, where we compare it to
> TYPE_ALIGN values, which are specified in bits. So I think we have a
> mismatch there.
>
> Does that sound right?
Yes, I think you are right on all account.
> The patch below was bootstrapped and tested on x86_64-linux, without
> issues,
The patch looks good to me, thanks.
> but I'm not convinced this code is covered by any testcase.
Hmhm, looking at the test cases, accompanying the initial patch that
introduced that code, I agree. I guess we should probably add a test case that
uses [[gnu::aligned (val)]], with 'val' being an alignment that is
greater than MAX (TYPE_ALIGN_UNIT (long_long_integer_type_node),
TYPE_ALIGN_UNIT (long_double_type_node))
in the g++.dg/cpp0x/gen-attrs-*.C series of tests?
--
Dodji
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Problem in cxx_fundamental_alignment_p?
2016-07-01 8:34 ` Dodji Seketeli
@ 2016-07-01 9:56 ` Bernd Schmidt
2016-07-13 21:57 ` Jeff Law
0 siblings, 1 reply; 4+ messages in thread
From: Bernd Schmidt @ 2016-07-01 9:56 UTC (permalink / raw)
To: Dodji Seketeli; +Cc: GCC Patches, Joseph Myers, Jason Merrill
[-- Attachment #1: Type: text/plain, Size: 816 bytes --]
On 07/01/2016 10:34 AM, Dodji Seketeli wrote:
>> The patch below was bootstrapped and tested on x86_64-linux, without
>> issues,
>
> The patch looks good to me, thanks.
Alright. I think we need a C frontend maintainer or maybe Jason to
approve it. Attaching again.
>> but I'm not convinced this code is covered by any testcase.
>
> Hmhm, looking at the test cases, accompanying the initial patch that
> introduced that code, I agree. I guess we should probably add a test case that
> uses [[gnu::aligned (val)]], with 'val' being an alignment that is
> greater than MAX (TYPE_ALIGN_UNIT (long_long_integer_type_node),
> TYPE_ALIGN_UNIT (long_double_type_node))
> in the g++.dg/cpp0x/gen-attrs-*.C series of tests?
I really don't know what this code is even doing, so I'll leave that up
to you...
Bernd
[-- Attachment #2: fundamental-align.diff --]
[-- Type: text/x-patch, Size: 1842 bytes --]
* c-common.c (cxx_fundamental_alignment_p): Use TYPE_ALIGN_UNIT,
not TYPE_ALIGN.
Index: gcc/c-family/c-common.c
===================================================================
--- gcc/c-family/c-common.c (revision 237797)
+++ gcc/c-family/c-common.c (working copy)
@@ -7668,10 +7668,10 @@ fail:
return NULL_TREE;
}
-/* Check whether ALIGN is a valid user-specified alignment. If so,
- return its base-2 log; if not, output an error and return -1. If
- ALLOW_ZERO then 0 is valid and should result in a return of -1 with
- no error. */
+/* Check whether ALIGN is a valid user-specified alignment, specified
+ in bytes. If so, return its base-2 log; if not, output an error
+ and return -1. If ALLOW_ZERO then 0 is valid and should result in
+ a return of -1 with no error. */
int
check_user_alignment (const_tree align, bool allow_zero)
{
@@ -12700,9 +12700,9 @@ scalar_to_vector (location_t loc, enum t
return stv_nothing;
}
-/* Return true iff ALIGN is an integral constant that is a fundamental
- alignment, as defined by [basic.align] in the c++-11
- specifications.
+/* Return true iff ALIGN, which is specified in bytes, is an integral
+ constant that is a fundamental alignment, as defined by
+ [basic.align] in the c++-11 specifications.
That is:
@@ -12712,10 +12712,11 @@ scalar_to_vector (location_t loc, enum t
alignof(max_align_t)]. */
bool
-cxx_fundamental_alignment_p (unsigned align)
+cxx_fundamental_alignment_p (unsigned align)
{
- return (align <= MAX (TYPE_ALIGN (long_long_integer_type_node),
- TYPE_ALIGN (long_double_type_node)));
+ unsigned limit = MAX (TYPE_ALIGN_UNIT (long_long_integer_type_node),
+ TYPE_ALIGN_UNIT (long_double_type_node));
+ return align <= limit;
}
/* Return true if T is a pointer to a zero-sized aggregate. */
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Problem in cxx_fundamental_alignment_p?
2016-07-01 9:56 ` Bernd Schmidt
@ 2016-07-13 21:57 ` Jeff Law
0 siblings, 0 replies; 4+ messages in thread
From: Jeff Law @ 2016-07-13 21:57 UTC (permalink / raw)
To: Bernd Schmidt, Dodji Seketeli; +Cc: GCC Patches, Joseph Myers, Jason Merrill
On 07/01/2016 03:56 AM, Bernd Schmidt wrote:
> On 07/01/2016 10:34 AM, Dodji Seketeli wrote:
>
>>> The patch below was bootstrapped and tested on x86_64-linux, without
>>> issues,
>>
>> The patch looks good to me, thanks.
>
> Alright. I think we need a C frontend maintainer or maybe Jason to
> approve it. Attaching again.
>
>>> but I'm not convinced this code is covered by any testcase.
>>
>> Hmhm, looking at the test cases, accompanying the initial patch that
>> introduced that code, I agree. I guess we should probably add a test
>> case that
>> uses [[gnu::aligned (val)]], with 'val' being an alignment that is
>> greater than MAX (TYPE_ALIGN_UNIT (long_long_integer_type_node),
>> TYPE_ALIGN_UNIT (long_double_type_node))
>> in the g++.dg/cpp0x/gen-attrs-*.C series of tests?
>
> I really don't know what this code is even doing, so I'll leave that up
> to you...
>
>
> Bernd
>
>
> fundamental-align.diff
>
>
> * c-common.c (cxx_fundamental_alignment_p): Use TYPE_ALIGN_UNIT,
> not TYPE_ALIGN.
FWIW, this patch is OK. It'd be even better if we had a testcase.
A patch making cxx_fundamental_alignment_p static, removing its
protototype from c-common.h is pre-approved as AFAICT
cxx_fundamental_alignment_p is not used outside c-common.c
jeff
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-07-13 21:57 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-29 19:21 Problem in cxx_fundamental_alignment_p? Bernd Schmidt
2016-07-01 8:34 ` Dodji Seketeli
2016-07-01 9:56 ` Bernd Schmidt
2016-07-13 21:57 ` Jeff Law
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).