Richard Earnshaw wrote:
On 01/06/15 13:07, Jakub Jelinek wrote:
On Thu, May 07, 2015 at 12:16:32PM +0100, Alan Lawrence wrote:
So for my two cents, or perhaps three:
Any progress on this PR?
A P1 bug that affects several packages stalled for a month isn't a very good
thing... (not to mention b
On 01/06/15 13:07, Jakub Jelinek wrote:
> On Thu, May 07, 2015 at 12:16:32PM +0100, Alan Lawrence wrote:
>> So for my two cents, or perhaps three:
>
> Any progress on this PR?
> A P1 bug that affects several packages stalled for a month isn't a very good
> thing... (not to mention broken profiledb
On Thu, May 07, 2015 at 12:16:32PM +0100, Alan Lawrence wrote:
> So for my two cents, or perhaps three:
Any progress on this PR?
A P1 bug that affects several packages stalled for a month isn't a very good
thing... (not to mention broken profiledbootstrap on ARM due to the same
issue).
I've checke
On Thu, May 07, 2015 at 12:16:32PM +0100, Alan Lawrence wrote:
> So for my two cents, or perhaps three:
>
> (1) It'd be great to have something in the documentation for
> TARGET_FUNCTION_ARG that explains what the contract for the type information
> provided is. Even/especially if some of this is
Richard Biener wrote:
On May 5, 2015 4:33:58 PM GMT+02:00, Richard Earnshaw
wrote:
On 05/05/15 15:33, Richard Earnshaw wrote:
On 05/05/15 15:29, Jakub Jelinek wrote:
On Tue, May 05, 2015 at 02:20:43PM +0100, Richard Earnshaw wrote:
On 05/05/15 14:06, Jakub Jelinek wrote:
For the middle-end
On 05/05/15 19:07, Richard Biener wrote:
> On May 5, 2015 4:33:58 PM GMT+02:00, Richard Earnshaw
> wrote:
>> On 05/05/15 15:33, Richard Earnshaw wrote:
>>> On 05/05/15 15:29, Jakub Jelinek wrote:
On Tue, May 05, 2015 at 02:20:43PM +0100, Richard Earnshaw wrote:
> On 05/05/15 14:06, Jakub
On May 5, 2015 4:33:58 PM GMT+02:00, Richard Earnshaw
wrote:
>On 05/05/15 15:33, Richard Earnshaw wrote:
>> On 05/05/15 15:29, Jakub Jelinek wrote:
>>> On Tue, May 05, 2015 at 02:20:43PM +0100, Richard Earnshaw wrote:
On 05/05/15 14:06, Jakub Jelinek wrote:
> On Tue, May 05, 2015 at 02:0
On 05/05/15 15:33, Richard Earnshaw wrote:
> On 05/05/15 15:29, Jakub Jelinek wrote:
>> On Tue, May 05, 2015 at 02:20:43PM +0100, Richard Earnshaw wrote:
>>> On 05/05/15 14:06, Jakub Jelinek wrote:
On Tue, May 05, 2015 at 02:02:19PM +0100, Richard Earnshaw wrote:
> In a literal sense, yes.
On 05/05/15 15:29, Jakub Jelinek wrote:
> On Tue, May 05, 2015 at 02:20:43PM +0100, Richard Earnshaw wrote:
>> On 05/05/15 14:06, Jakub Jelinek wrote:
>>> On Tue, May 05, 2015 at 02:02:19PM +0100, Richard Earnshaw wrote:
In a literal sense, yes. However, even K&R & stdarg have standard
p
On Tue, May 05, 2015 at 02:20:43PM +0100, Richard Earnshaw wrote:
> On 05/05/15 14:06, Jakub Jelinek wrote:
> > On Tue, May 05, 2015 at 02:02:19PM +0100, Richard Earnshaw wrote:
> >> In a literal sense, yes. However, even K&R & stdarg have standard
> >> promotion and conversion rules (size < int =
On Tue, May 05, 2015 at 09:32:28AM +0200, Jakub Jelinek wrote:
> 2015-05-05 Jakub Jelinek
>
> PR target/65956
> * config/arm/arm.c (arm_needs_doubleword_align): For non-aggregate
> types check TYPE_ALIGN of TYPE_MAIN_VARIANT rather than type itself.
>
> * gcc.c-torture/
On 05/05/15 15:06, Richard Biener wrote:
> On May 5, 2015 2:49:55 PM GMT+02:00, Richard Earnshaw
> wrote:
>> On 05/05/15 13:46, Richard Earnshaw wrote:
>>> On 05/05/15 13:37, Richard Biener wrote:
On May 5, 2015 1:01:59 PM GMT+02:00, Richard Earnshaw
>> wrote:
> On 05/05/15 11:54, Richa
On May 5, 2015 2:49:55 PM GMT+02:00, Richard Earnshaw
wrote:
>On 05/05/15 13:46, Richard Earnshaw wrote:
>> On 05/05/15 13:37, Richard Biener wrote:
>>> On May 5, 2015 1:01:59 PM GMT+02:00, Richard Earnshaw
> wrote:
On 05/05/15 11:54, Richard Earnshaw wrote:
> On 05/05/15 08:32, Jakub Je
On 05/05/15 14:06, Jakub Jelinek wrote:
> On Tue, May 05, 2015 at 02:02:19PM +0100, Richard Earnshaw wrote:
>> In a literal sense, yes. However, even K&R & stdarg have standard
>> promotion and conversion rules (size < int => int, floats promoted to
>> double, etc). What are those rules for GCC's
On Tue, May 05, 2015 at 02:02:19PM +0100, Richard Earnshaw wrote:
> In a literal sense, yes. However, even K&R & stdarg have standard
> promotion and conversion rules (size < int => int, floats promoted to
> double, etc). What are those rules for GCC's overaligned types (ie
> where in the docs do
On 05/05/15 13:54, Jakub Jelinek wrote:
> On Tue, May 05, 2015 at 01:49:55PM +0100, Richard Earnshaw wrote:
>> The real question here is why is TYPE the type of the value, rather than
>> the type of the formal as expressed by the prototype (or implicit
>> prototype in the case of variadics or K&R)?
On Tue, May 05, 2015 at 01:49:55PM +0100, Richard Earnshaw wrote:
> The real question here is why is TYPE the type of the value, rather than
> the type of the formal as expressed by the prototype (or implicit
> prototype in the case of variadics or K&R)? Surely this is the mid-end
> passing the wr
On 05/05/15 13:46, Richard Earnshaw wrote:
> On 05/05/15 13:37, Richard Biener wrote:
>> On May 5, 2015 1:01:59 PM GMT+02:00, Richard Earnshaw
>> wrote:
>>> On 05/05/15 11:54, Richard Earnshaw wrote:
On 05/05/15 08:32, Jakub Jelinek wrote:
> On Mon, May 04, 2015 at 05:00:11PM +0200, Jaku
On 05/05/15 13:37, Richard Biener wrote:
> On May 5, 2015 1:01:59 PM GMT+02:00, Richard Earnshaw
> wrote:
>> On 05/05/15 11:54, Richard Earnshaw wrote:
>>> On 05/05/15 08:32, Jakub Jelinek wrote:
On Mon, May 04, 2015 at 05:00:11PM +0200, Jakub Jelinek wrote:
> So at least changing arm_ne
On 05/05/15 13:37, Richard Biener wrote:
> On May 5, 2015 1:01:59 PM GMT+02:00, Richard Earnshaw
> wrote:
>> On 05/05/15 11:54, Richard Earnshaw wrote:
>>> On 05/05/15 08:32, Jakub Jelinek wrote:
On Mon, May 04, 2015 at 05:00:11PM +0200, Jakub Jelinek wrote:
> So at least changing arm_ne
On May 5, 2015 1:01:59 PM GMT+02:00, Richard Earnshaw
wrote:
>On 05/05/15 11:54, Richard Earnshaw wrote:
>> On 05/05/15 08:32, Jakub Jelinek wrote:
>>> On Mon, May 04, 2015 at 05:00:11PM +0200, Jakub Jelinek wrote:
So at least changing arm_needs_doubleword_align for non-aggregates
>would
>>>
On Tue, May 05, 2015 at 12:01:59PM +0100, Richard Earnshaw wrote:
> > Either way, this would need careful cross-testing against an existing
> > compiler.
> >
>
> It looks as though either patch would cause ABI incompatibility for
>
> typedef int alignedint __attribute__((aligned((8;
>
> int
On 05/05/15 11:54, Richard Earnshaw wrote:
> On 05/05/15 08:32, Jakub Jelinek wrote:
>> On Mon, May 04, 2015 at 05:00:11PM +0200, Jakub Jelinek wrote:
>>> So at least changing arm_needs_doubleword_align for non-aggregates would
>>> likely not break anything that hasn't been broken already and would
On 05/05/15 08:32, Jakub Jelinek wrote:
> On Mon, May 04, 2015 at 05:00:11PM +0200, Jakub Jelinek wrote:
>> So at least changing arm_needs_doubleword_align for non-aggregates would
>> likely not break anything that hasn't been broken already and would unbreak
>> the majority of cases.
>
> Attached
On Mon, May 04, 2015 at 05:00:11PM +0200, Jakub Jelinek wrote:
> So at least changing arm_needs_doubleword_align for non-aggregates would
> likely not break anything that hasn't been broken already and would unbreak
> the majority of cases.
Attached (untested so far). It indeed changes code gener
On Mon, May 04, 2015 at 10:11:13AM +0200, Richard Biener wrote:
> Not sure how this helps when SRA tears apart the parameter. That is,
> isn't the important thing that both the IPA modified function argument
> types/decls have the same type as the types of the parameters SRA ends
> up passing? (a
On Sat, 2 May 2015, Jakub Jelinek wrote:
> Hi!
>
> This is an attempt to fix the following testcase (reduced from gsoap)
> similarly how you've fixed another issue with r221795 other AAPCS
> regressions introduced with r221348 change.
> This patch passed bootstrap/regtest on
> {x86_64,i686,armv7h
Hi!
This is an attempt to fix the following testcase (reduced from gsoap)
similarly how you've fixed another issue with r221795 other AAPCS
regressions introduced with r221348 change.
This patch passed bootstrap/regtest on
{x86_64,i686,armv7hl,aarch64,powerpc64{,le},s390{,x}}-linux.
Though, it st
28 matches
Mail list logo
