On 2015-02-16, at 1:47 PM, John David Anglin wrote:
> On 2015-02-16, at 11:38 AM, Richard Henderson wrote:
>
>>>
>>> Possibly the constant can somehow be forced into the data section where the
>>> relocations
>>> aren't a problem?
>>
>> Hmm. It looks like we might already do that. See
>> de
On 2015-02-16, at 11:38 AM, Richard Henderson wrote:
>>
>> Possibly the constant can somehow be forced into the data section where the
>> relocations
>> aren't a problem?
>
> Hmm. It looks like we might already do that. See default_select_rtx_section.
Thanks, I see the problem. default_relo
On 02/14/2015 06:50 AM, John David Anglin wrote:
> Possibly the constant can somehow be forced into the data section where the
> relocations
> aren't a problem?
Hmm. It looks like we might already do that. See default_select_rtx_section.
r~
On 2015-02-13, at 12:08 PM, Richard Henderson wrote:
> On 02/13/2015 05:22 AM, John David Anglin wrote:
>> + /* Reload sometimes tries to put const data symbolic operands in
>> + readonly memory. The HP SOM linker doesn't allow symbolic data
>> + in readonly memory. */
>> + if (TARGET_
On 02/13/2015 05:22 AM, John David Anglin wrote:
> + /* Reload sometimes tries to put const data symbolic operands in
> + readonly memory. The HP SOM linker doesn't allow symbolic data
> + in readonly memory. */
> + if (TARGET_SOM
> + && !function_label_operand (x, VOIDmode)
> +
The recent change to use the "Q" constraint instead of the "m" constraint in
several patterns caused
a regression that broke the build of the Debian webkitgtk package. Memory
addresses (spills) with out
of range offsets were not being reloaded in functions with large frames. This
change fixes