On 23/01/15 16:34, Jeff Law wrote:
Just for reference, the PA allows a 14 bit displacement in memory
addresses which use integer registers, but only a 5 bit displacement for
FP registers. Other than the displacement amounts, I suspect this is
the same core problem you have on your port.
Yes, t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64754
is a LTO bug where stage 1 and stage 2 compilers generate
different LTO IR. Is there a way to dump LTO IR to see the
actual difference in LTO IR?
Thanks.
--
H.J.
On 1/23/2015 10:59 AM, Jonathan Wakely wrote:
> On 23/01/15 10:53 -0600, Joel Sherrill wrote:
>> Is there a better way to automate a signature compliance? To tweak
>> what they have done?
> Testing member function signatures for compliance is inherently
> flawed, they just shouldn't do it.
>
> I w
On 23/01/15 10:53 -0600, Joel Sherrill wrote:
Is there a better way to automate a signature compliance? To tweak
what they have done?
Testing member function signatures for compliance is inherently
flawed, they just shouldn't do it.
I would say they should be testing that the function can be c
On 1/23/2015 9:55 AM, Jonathan Wakely wrote:
> On 22/01/15 16:07 -0600, Joel Sherrill wrote:
>> On 1/22/2015 3:44 PM, Marc Glisse wrote:
>>> On Thu, 22 Jan 2015, Joel Sherrill wrote:
>>>
I think this is a glibc issue but since this method is defined in the C++
standards, I thought there
On 01/23/15 06:46, Andrew Stubbs wrote:
How does reload ensure that an SImode value (re)loaded into an FP
register has a valid stack index?
The FP load instruction allows a smaller index range than the integer
equivalent, but nothing checks the destination register, only the source
mode.
Unfo
On 23 January 2015 at 16:07, Ricardo Telichevesky wrote:
> gcc: Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) - don't
> know what that means expected a number like 4.2.1 or something like that,
> 2.53 GHz Intel Core 2 Duo
Hi Ricardo,
This is not gcc at all, it's Clang+LLVM. :/
Thanks Richard for your input, much appreciated.
I followed up on your suggestions; unfortunately the -Wdisabled-optimization option you suggested did not cause any warnings. Still trying one by one the --params options without success. I got a new hint, though, running the same examples on a
On 22/01/15 16:07 -0600, Joel Sherrill wrote:
On 1/22/2015 3:44 PM, Marc Glisse wrote:
On Thu, 22 Jan 2015, Joel Sherrill wrote:
I think this is a glibc issue but since this method is defined in the C++
standards, I thought there were plenty of language lawyers here. :)
s/glibc/libstdc++/ an
On 23 January 2015 at 13:46, Andrew Stubbs wrote:
> How does reload ensure that an SImode value (re)loaded into an FP register
> has a valid stack index?
You could use CANNOT_CHANGE_MODE_CLASS, or request secondary reload.
For the latter, you can look at the memory/pseudo to decide if the
address
How does reload ensure that an SImode value (re)loaded into an FP
register has a valid stack index?
The FP load instruction allows a smaller index range than the integer
equivalent, but nothing checks the destination register, only the source
mode.
I'm trying to solve a problem in which GCC
Dear GCC team,
I would like to contribute to the project.
I have a background in embedded systems programming, but few
experience in compiler development.
I'd like to try with fixing PR64744.
Would some one help me to understand what should be correct compilers
behaviour with an example below:
It seems that in gcc 4.7, the rnreg pass for renaming registers after
reload is not vliw aware. In particular I saw it reassign a register
that is in use in the same vliw.
To be more concrete, I saw it change the following pseudo code
DI:a30 = v0
SI:a14 = -a14
to
DI:a30 = v0
SI
13 matches
Mail list logo
