Wilco Dijkstra writes:
> Hi Richard,
>> Sure, the "extern array of unknown size" case isn't about section anchors.
>> But this part of my message (snipped above) was about the other case
>> (objects of known size), and applied to individual objects as well as
>> section anchors.
>>
>> What I was t
Hi Richard,
> Sure, the "extern array of unknown size" case isn't about section anchors.
> But this part of my message (snipped above) was about the other case
> (objects of known size), and applied to individual objects as well as
> section anchors.
>
> What I was trying to say is: yes, we need b
Wilco Dijkstra writes:
> Hi Richard,
>
>>> No - the testcases fail with that.
>>
>> Hmm, OK. Could you give more details? What does the motivating case
>> actually look like?
>
> Well it's now a very long time ago since I first posted this patch but the
> failure
> was in SPEC. It did something
Hi Richard,
>> No - the testcases fail with that.
>
> Hmm, OK. Could you give more details? What does the motivating case
> actually look like?
Well it's now a very long time ago since I first posted this patch but the
failure
was in SPEC. It did something like &array[0xff000 - x], presuma
On 10/12/19 3:56 AM, Richard Sandiford wrote:
> Wilco Dijkstra writes:
>> Hi Richard,
>>
>>> If global_char really is a char then isn't that UB?
>>
>> No why?
>
> Well, "simple expressions like &global_char + 0xff00" made it sound
> like there really was a:
>
>extern char global_char;
>
Richard Sandiford writes:
> Wilco Dijkstra writes:
>> We can do all kinds of arithmetic based on pointers, either using
>> pointer types or converted to uintptr_t. Note that the optimizer
>> actually creates these expressions, for example arr[N-x] can be
>> evaluated as (&arr[0] + N) - x. So thi
Wilco Dijkstra writes:
> Hi Richard,
>
>> If global_char really is a char then isn't that UB?
>
> No why?
Well, "simple expressions like &global_char + 0xff00" made it sound
like there really was a:
extern char global_char;
Only &global_char and &global_char + 1 are defined in that case.
Hi Richard,
> If global_char really is a char then isn't that UB?
No why? We can do all kinds of arithmetic based on pointers, either using
pointer types or converted to uintptr_t. Note that the optimizer actually
creates
these expressions, for example arr[N-x] can be evaluated as (&arr[0] + N
Wilco Dijkstra writes:
> ping
>
> In aarch64_classify_symbol symbols are allowed full-range offsets on
> relocations.
> This means the offset can use all of the +/-4GB offset, leaving no offset
> available
> for the symbol itself. This results in relocation overflow and link-time
>
ping
In aarch64_classify_symbol symbols are allowed full-range offsets on
relocations.
This means the offset can use all of the +/-4GB offset, leaving no offset
available
for the symbol itself. This results in relocation overflow and link-time
errors
for simple expressions like
ping
In aarch64_classify_symbol symbols are allowed full-range offsets on
relocations.
This means the offset can use all of the +/-4GB offset, leaving no offset
available
for the symbol itself. This results in relocation overflow and link-time
errors
fo
ping
In aarch64_classify_symbol symbols are allowed full-range offsets on
relocations.
This means the offset can use all of the +/-4GB offset, leaving no offset
available
for the symbol itself. This results in relocation overflow and link-time
errors
for simple expr
ping
In aarch64_classify_symbol symbols are allowed full-range offsets on
relocations.
This means the offset can use all of the +/-4GB offset, leaving no offset
available
for the symbol itself. This results in relocation overflow and link-time
errors
for simple expressions
ping
In aarch64_classify_symbol symbols are allowed full-range offsets on
relocations.
This means the offset can use all of the +/-4GB offset, leaving no offset
available
for the symbol itself. This results in relocation overflow and link-time
errors
for simple expressions like &globa
Richard Earnshaw (lists) wrote:
>
> So isn't the real bug that we've permitted the user to create an object
> that is too large for the data model?
No that's a different issue I'm not trying to address here. The key is that as
long
as the start of the symbol is in range, we should be able to lin
On 23/08/16 15:10, Wilco Dijkstra wrote:
> In aarch64_classify_symbol symbols are allowed full-range offsets on
> relocations.
> This means the offset can use all of the +/-4GB offset, leaving no offset
> available
> for the symbol itself. This results in relocation overflow and link-time
> er
16 matches
Mail list logo
