On 24.10.2012 08:55, Marc Glisse wrote:
> On Tue, 23 Oct 2012, Vladimir Makarov wrote:
>
>> Hi, I was going to merge LRA into trunk last Sunday. It did not happen. LRA
>> was actively changed last 4 weeks by implementing reviewer's proposals which
>> resulted in a lot of new LRA regressions on G
On Tue, Oct 23, 2012 at 8:09 PM, Ian Lance Taylor wrote:
> On Tue, Oct 23, 2012 at 10:47 AM, Uros Bizjak wrote:
>>
>> Additional test fails on alphaev68-linux-gnu:
>>
>> --- FAIL: TestPassFD (0.15 seconds)
>> passfd_test.go:62: FileConn: dup: Bad file descriptor
>> FAIL
>> FAIL: syscall
>
>
On Wed, Oct 24, 2012 at 10:01 AM, Uros Bizjak wrote:
> On Tue, Oct 23, 2012 at 8:09 PM, Ian Lance Taylor wrote:
>> On Tue, Oct 23, 2012 at 10:47 AM, Uros Bizjak wrote:
>>>
>>> Additional test fails on alphaev68-linux-gnu:
>>>
>>> --- FAIL: TestPassFD (0.15 seconds)
>>> passfd_test.go:62: Fi
On Wed, Oct 24, 2012 at 10:01 AM, Uros Bizjak wrote:
>>> Additional test fails on alphaev68-linux-gnu:
>>>
>>> --- FAIL: TestPassFD (0.15 seconds)
>>> passfd_test.go:62: FileConn: dup: Bad file descriptor
>>> FAIL
>>> FAIL: syscall
>>
>> As far as I can see this error message occurs when cal
> But why do we want the loop at all if the rounded size is zero?
> It's a compile-time constant after all.
Yes, this never occurs in practice because of the value set for PROBE_INTERVAL
and STACK_CHECK_PROTECT. This can only occur in the dynamic case handled in
explow.c:probe_stack_range.
All
On 10/24/2012 10:12 AM, Uros Bizjak wrote:
Is it OK to call dup on the same FD the second time?
To answer my own question:
dup(4) = 9
...
close(9)= 0
dup(4) = -1 EBADF (Bad file descriptor)
Test
On Wed, Oct 10, 2012 at 07:00:22AM +0200, Andreas Krebbel wrote:
> /* This function is called via hook TARGET_SCHED_REORDER before
> !issuing one insn from list READY which contains *NREADYP entries.
> For target z10 it reorders load instructions to avoid early load
> conflicts in t
On Wed, Oct 24, 2012 at 10:22 AM, Florian Weimer wrote:
>>> Is it OK to call dup on the same FD the second time?
>>
>>
>> To answer my own question:
>>
>> dup(4) = 9
>> ...
>> close(9)= 0
>> dup(4) =
On Tue, Oct 23, 2012 at 5:50 PM, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs, because the VLA ARRAY_TYPE in the ctor
> isn't considered variably_modified_type_p during cloning of the ctor
> when the types weren't gimplified yet.
> The size is a non-constant expression that has SAVE_
> On the following testcase we have IF_THEN_ELSE in insn notes,
> and when folding it, folded_arg1 is a subreg from earlier CC setter,
> as the other argument has equiv constant, simplify_relational_operation
> is called on it to simplify it and we end up with invalid RTL sharing
> of the subreg in
On Wed, Oct 24, 2012 at 10:35:33AM +0200, Richard Biener wrote:
> Can you factor this and the variant in gimplify_one_sizepos out into
> a predicate? Like is_gimple_sizepos ()?
>
> Ok with that change.
Here is what I've committed:
2012-10-24 Jakub Jelinek
PR debug/54828
* gim
David Miller writes:
> From: David Miller
> Date: Tue, 23 Oct 2012 21:44:05 -0400 (EDT)
>
>> The first issue sparc runs into is that it does not define it's
>> extra constraints properly. In particular 'T' and 'W' must use
>> define_memory_constraint.
>>
>> Otherwise the EXTRA_MEMORY_CONSTRAINT
Eric Botcazou writes:
>> But why do we want the loop at all if the rounded size is zero?
>> It's a compile-time constant after all.
>
> Yes, this never occurs in practice because of the value set for
> PROBE_INTERVAL
> and STACK_CHECK_PROTECT. This can only occur in the dynamic case handled in
On Wed, Oct 24, 2012 at 10:17:48AM +0100, Richard Sandiford wrote:
> > Sparc accepts addresses of the form:
> >
> > (plus:DI (lo_sum:DI (reg/f:DI 282)
> > (symbol_ref:DI ("__mf_opts") ))
> > (const_int 40 [0x28]))
> >
> > These make use of Sparc's offsetable %lo() relocations.
>
> Hmm,
Hi,
few things I think are worth to be mentioned in changes.html.
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.48
diff -c -3 -p -r1.48 changes.html
*** changes.html21 Oc
Jakub Jelinek writes:
> On Wed, Oct 24, 2012 at 10:17:48AM +0100, Richard Sandiford wrote:
>> > Sparc accepts addresses of the form:
>> >
>> > (plus:DI (lo_sum:DI (reg/f:DI 282)
>> > (symbol_ref:DI ("__mf_opts") ))
>> > (const_int 40 [0x28]))
>> >
>> > These make use of Sparc's offseta
On Tue, Oct 23, 2012 at 6:12 PM, Kenneth Zadeck
wrote:
>
> On 10/23/2012 10:12 AM, Richard Biener wrote:
>>
>> On Tue, Oct 9, 2012 at 5:09 PM, Kenneth Zadeck
>> wrote:
>>>
>>> This patch implements the wide-int class.this is a more general
>>> version
>>> of the double-int class and is meant
On 10/23/12 16:46, Vladimir Makarov wrote:
Hi, I was going to merge LRA into trunk last Sunday. It did not
happen. LRA was actively changed last 4 weeks by implementing
reviewer's proposals which resulted in a lot of new LRA regressions on
GCC testsuite in comparison with reload. Finally,
On Tue, Oct 23, 2012 at 8:46 AM, Vladimir Makarov wrote:
> Hi, I was going to merge LRA into trunk last Sunday. It did not happen.
> LRA was actively changed last 4 weeks by implementing reviewer's proposals
> which resulted in a lot of new LRA regressions on GCC testsuite in
> comparison with
On 03/09/2012 10:01 AM, Sebastian Huber wrote:
Hi,
please have a look at the attached patch. Test suite results for GCC 4.7
http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg00986.html
This patch is still pending for GCC 4.7 and 4.8. Can someone please review and
commit it. Without this p
On Wed, Oct 24, 2012 at 3:42 AM, Joern Rennecke
wrote:
> Quoting Richard Biener :
>
>> On Tue, Oct 16, 2012 at 9:35 PM, Joern Rennecke
>> wrote:
>
> ..
>>>
>>> Well, we could split it anyway, and give ports without the need for
>>> multiple length attributes the benefit of the optimistic algorith
On Tue, Oct 23, 2012 at 3:14 AM, Alexander Ivchenko wrote:
> Please take a look at the attached patch.
>
> I changed the asm-pattern implementation according to your recomendation.
> Changed the name of feature option from -mfxsave to -mfxsr, as it is in
> Intel SDM. Corrected the arguments name i
On Wed, Oct 24, 2012 at 12:52 PM, H.J. Lu wrote:
>> Please take a look at the attached patch.
>>
>> I changed the asm-pattern implementation according to your recomendation.
>> Changed the name of feature option from -mfxsave to -mfxsr, as it is in
>> Intel SDM. Corrected the arguments name in the
On Wed, Oct 24, 2012 at 1:06 PM, Uros Bizjak wrote:
>>> Please take a look at the attached patch.
>>>
>>> I changed the asm-pattern implementation according to your recomendation.
>>> Changed the name of feature option from -mfxsave to -mfxsr, as it is in
>>> Intel SDM. Corrected the arguments nam
Uros Bizjak writes:
> To answer my own question:
>
> dup(4) = 9
> ...
> close(9)= 0
> dup(4) = -1 EBADF (Bad file descriptor)
>
> Test is calling dup on a closed file descriptor.
FD 4 is most likely
Hi
tested x86_64-linux multilib, committed to mainline. A similar fix will
go in 4_7-branch too.
Thanks,
Paolo.
2012-10-24 Haakan Younes
Paolo Carlini
PR libstdc++/55047
* include/bits/random.h (exponential_distribution<>::operator)
On Wed, Oct 24, 2012 at 2:18 PM, Andreas Schwab wrote:
> Uros Bizjak writes:
>
>> To answer my own question:
>>
>> dup(4) = 9
>> ...
>> close(9)= 0
>> dup(4) = -1 EBADF (Bad file descriptor)
>>
>> Te
Add Uros to Cc.
On Tue, Oct 23, 2012 at 2:45 PM, Andrey Turetskiy
wrote:
> Hi,
>
> This patch replaces large const_vector constructions with
> match_operand in sse.md to decrease its size.
> Is it ok?
>
> Changelog:
>
> 2012-10-23 Andrey Turetskiy
>
>* config/i386/avx2intrin.h (_mm256_avg_
On Wed, Oct 24, 2012 at 05:01:15PM +0400, Andrey Turetskiy wrote:
> > This patch replaces large const_vector constructions with
> > match_operand in sse.md to decrease its size.
> > Is it ok?
The *intrin.h changes look all wrong to me, why should one pass a dummy
uninitialized argument to the buil
On Wed, Oct 24, 2012 at 5:31 AM, Uros Bizjak wrote:
> On Wed, Oct 24, 2012 at 2:18 PM, Andreas Schwab wrote:
>> Uros Bizjak writes:
>>
>>> To answer my own question:
>>>
>>> dup(4) = 9
>>> ...
>>> close(9)= 0
>>> dup(4)
On Wed, Oct 24, 2012 at 3:10 PM, Ian Lance Taylor wrote:
> On Wed, Oct 24, 2012 at 5:31 AM, Uros Bizjak wrote:
>> On Wed, Oct 24, 2012 at 2:18 PM, Andreas Schwab
>> wrote:
>>> Uros Bizjak writes:
>>>
To answer my own question:
dup(4) = 9
...
Quoting Richard Biener :
Just to add some extra information, can you quote your ports
ADJUST_INSN_LENGTH and one example instruction with length/lock_length
attribute the above applies to?
This is a bit besides the point, since lock_length does mostly the traditional
branch shortening (with al
On Wed, Oct 24, 2012 at 3:01 PM, Andrey Turetskiy
wrote:
> On Tue, Oct 23, 2012 at 2:45 PM, Andrey Turetskiy
> wrote:
>> Hi,
>>
>> This patch replaces large const_vector constructions with
>> match_operand in sse.md to decrease its size.
>> Is it ok?
No, you don't have to touch generic expand m
Hi guys,
I just applied the below patch to the sourceware src repo. The reason
for the patch is that Cygwin won't be using the in-tree mingw and w32api
any longer, but instead it requires an external installation of a
Mingw64 based w32api, and a Mingw64 build environment to build the
native Windo
This fixes PR54824, an ICE in loop structure verification, by
avoiding the situation of a BB with no successor and no control
statement (such as a noreturn call). This situation leads
RTL expansions call to find_many_sub_basic_blocks to connect such
block to the "next" block, in this testcase for
On Wed, Oct 24, 2012 at 6:19 AM, Uros Bizjak wrote:
> On Wed, Oct 24, 2012 at 3:10 PM, Ian Lance Taylor wrote:
>> On Wed, Oct 24, 2012 at 5:31 AM, Uros Bizjak wrote:
>>> On Wed, Oct 24, 2012 at 2:18 PM, Andreas Schwab
>>> wrote:
Uros Bizjak writes:
> To answer my own question:
>
Jakub Jelinek writes:
> On Tue, Oct 23, 2012 at 03:08:07PM +0200, Dodji Seketeli wrote:
>> +static gimple_stmt_iterator
>> +create_cond_insert_point_before_iter (gimple_stmt_iterator *iter,
>> + bool then_more_likely_p,
>> + basic_
On Tue, Oct 23, 2012 at 06:25:43PM +0200, Sebastian Huber wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033
>
> This patch fixes my problem, but I am absolutely not sure if this is the
> right way.
[snip]
This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9571 all over again.
IMHO your
Jakub Jelinek writes:
> On Tue, Oct 23, 2012 at 03:11:29PM +0200, Dodji Seketeli wrote:
>> + /* (src, n) style memops. */
>> +case BUILT_IN_STRNDUP:
>> + source0 = gimple_call_arg (call, 0);
>> + len = gimple_call_arg (call, 1);
>> + break;
>
> I think you can't instrumen
Jakub Jelinek writes:
>> For 'strlen', can the memory check be done at the end of the string
>> using the returned length?
>
> Guess strlen is commonly expanded inline, so it would be worthwhile to check
> the shadow memory after the call (well, we could check the first byte
> before the call and
Hi all,
I have just committed an obvious fix for a recent OOP regression:
http://gcc.gnu.org/viewcvs?view=revision&revision=192768
Cheers,
Janus
On Wed, Oct 24, 2012 at 04:46:05PM +0200, Dodji Seketeli wrote:
> Fixed. Below is the updated patch.
Ok, thanks.
Jakub
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55048
LRA tried to take BB from non-NOTE_INSN_BASIC_BLOCK note and got NULL
which resulted in SIGSEGV.
The patch was successfully bootstrapped with java on x86/x86-64.
Committed as rev. 192770.
2012-10-24 Vladimir
On Wed, Oct 24, 2012 at 05:16:26PM +0200, Dodji Seketeli wrote:
> Jakub Jelinek writes:
>
> >> For 'strlen', can the memory check be done at the end of the string
> >> using the returned length?
> >
> > Guess strlen is commonly expanded inline, so it would be worthwhile to check
> > the shadow me
Jakub Jelinek writes:
> On Wed, Oct 24, 2012 at 05:16:26PM +0200, Dodji Seketeli wrote:
>> Jakub Jelinek writes:
>>
>> >> For 'strlen', can the memory check be done at the end of the string
>> >> using the returned length?
>> >
>> > Guess strlen is commonly expanded inline, so it would be worth
I am not a maintainer so the below are just some casual comments of
mine. I am deferring to the maintainers for a real review.
Manuel López-Ibáñez writes:
> gcc/
> * tree-diagnostic.c (maybe_unwind_expanded_macro_loc):
> Use diagnostic_attach_note.
> * diagnostic.c (diagnostic
On Wed, Oct 24, 2012 at 05:11:23PM +0200, Dodji Seketeli wrote:
> If I write exactly what you wrote here, I am getting an error for e.g:
>
> void
> bar ()
> {
> char bar[1] = {0};
> int n = 0;
>
> __builtin_memset (bar, 0, n);
> }
I see, the problem is that buil
On Wed, Oct 24, 2012 at 4:30 PM, Ian Lance Taylor wrote:
> On Wed, Oct 24, 2012 at 6:19 AM, Uros Bizjak wrote:
>> On Wed, Oct 24, 2012 at 3:10 PM, Ian Lance Taylor wrote:
>>> On Wed, Oct 24, 2012 at 5:31 AM, Uros Bizjak wrote:
On Wed, Oct 24, 2012 at 2:18 PM, Andreas Schwab
wrote:
>
On Tue, 23 Oct 2012, Joern Rennecke wrote:
> + tm_file="dbxelf.h elfos.h linux.h ${tm_file}"
Should be using gnu-user.h linux.h glibc-stdint.h, not linux.h on its own.
--
Joseph S. Myers
jos...@codesourcery.com
On Tue, 23 Oct 2012, Joern Rennecke wrote:
> I'll be posting the ARC port shortly; it does not fit into a single 100 KB
> posting, so I'm thinking of splitting it in a configury patch and zx
> compressed files/tarballs for arc.c, arc.md, libgcc, and the rest of the port.
The size limit is 400 kB,
Diagnostics should not end with '.' (or '\n', in some cases here); also
avoid starting with a capital letter in cases such as "Operand".
--
Joseph S. Myers
jos...@codesourcery.com
Same diagnostic comment regarding one fatal_error call here; in addition,
diagnostic functions should not be called directly from .md files at all,
because .md files aren't processed by exgettext to extract messages for
translation.
--
Joseph S. Myers
jos...@codesourcery.com
If you need special t-* logit for fp-bit.c / dp-bit.c, rather than being
able to use t-fdpbit, then you need comments explaining why the special
logic rather than the generic code is used.
--
Joseph S. Myers
jos...@codesourcery.com
On 10/10/2012 11:13 AM, Paolo Carlini wrote:
- error ("type transparent class %qT does not have any fields", t);
+ if (TREE_CODE (t) == UNION_TYPE)
+ error ("type transparent union %qT does not have any fields", t);
+ else
+ error ("type transparent cla
Don't use ATTRIBUTE_UNUSED on a parameter that, as in
arc_option_init_struct, is in fact used unconditionally.
handle_option hooks take a location, so use warning_at not plain warning
in arc_handle_option. Same diagnostic issue as noted before applies.
There are lots of obsolete bits in your A
Hi,
a *very* old ICE on invalid, even a regression (from before variadic
templates, I guess!). I tried various other tweaks, like catching the
issue earlier but diagnostic quality decreases, too many cascading error
messages. The below means I have to tweak only a couple of existing
testcases
On Oct 24, 2012, at 2:43 AM, Richard Biener wrote:
> On Tue, Oct 23, 2012 at 6:12 PM, Kenneth Zadeck
> wrote:
>>
>> On 10/23/2012 10:12 AM, Richard Biener wrote:
>>>
>>> + HOST_WIDE_INT val[2 * MAX_BITSIZE_MODE_ANY_INT /
>>> HOST_BITS_PER_WIDE_INT];
>>>
>>> are we sure this rounds properly?
Agreed. OK with the comment added.
Jason
On 10/24/2012 01:20 PM, Paolo Carlini wrote:
+ if (parm == error_mark_node
+ || TREE_PURPOSE (parm) == error_mark_node)
It seems odd to bail out early if the default argument is bad even if we
aren't trying to use it. Doesn't it work to check this further down
where we actually
The following path shouldfix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55049
The patch was successfully bootstrapped on x86-64. Sorry, I can not
bootstrap with mx32 because of libraries absence.
Committed as rev. 192771.
2012-10-24 Vladimir Makarov
PR bootstrap/55049
* lr
On Wed, Oct 24, 2012 at 9:34 AM, Uros Bizjak wrote:
>
> Continuing.
> [New Thread 0x2000307b280 (LWP 8059)]
>
> Breakpoint 18, 0x020002e378c0 in socketpair () from /lib/libc.so.6.1
>
> Continuing.
> [New Thread 0x20003083280 (LWP 8065)]
> [Switching to Thread 0x20003083280 (LWP 8065)]
>
> [...
On Wed, Oct 24, 2012 at 7:46 PM, Ian Lance Taylor wrote:
> On Wed, Oct 24, 2012 at 9:34 AM, Uros Bizjak wrote:
>>
>> Continuing.
>> [New Thread 0x2000307b280 (LWP 8059)]
>>
>> Breakpoint 18, 0x020002e378c0 in socketpair () from /lib/libc.so.6.1
>>
>> Continuing.
>> [New Thread 0x20003083280 (
What about?
/* Add a note with text GMSGID and with LOCATION to the diagnostic CONTEXT. */
Actually, I don't know why I call it "attach". diagnostic_add_note()
or diagnostic_print_note() seems clearer. What do you think?
Cheers,
Manuel.
On 24 October 2012 19:27, Jason Merrill wrote:
> Agree
In the process of factoring out the "lowpart bit field" check
from an earlier patch, I somehow managed to drop an "== 0" condition.
It seems I then compounded that by screwing up the powerpc64 testing
(still not sure how :-().
Anyway, fixed with the patch below, tested on powerpc64-linux-gnu.
Sorr
On 10/19/2012 04:40 PM, Marc Glisse wrote:
So between the following:
a) x?y:z means (x<0)?y:z
b) x?y:z means (x!=0)?y:z
c) x?y:z is rejected, only things like (x==t)?y:z are accepted
d) other
is the choice still b) ? That's an easy one, only 2 characters to change
in the patch (assuming the rest
On Wed, Oct 24, 2012 at 10:52 AM, Uros Bizjak wrote:
> On Wed, Oct 24, 2012 at 7:46 PM, Ian Lance Taylor wrote:
>> On Wed, Oct 24, 2012 at 9:34 AM, Uros Bizjak wrote:
>>>
>>> Continuing.
>>> [New Thread 0x2000307b280 (LWP 8059)]
>>>
>>> Breakpoint 18, 0x020002e378c0 in socketpair () from /li
On 10/24/2012 01:54 PM, Manuel López-Ibáñez wrote:
/* Add a note with text GMSGID and with LOCATION to the diagnostic CONTEXT. */
Sure.
Actually, I don't know why I call it "attach". diagnostic_add_note()
or diagnostic_print_note() seems clearer. What do you think?
How about "append"?
Jas
Hi,
On 10/24/2012 07:30 PM, Jason Merrill wrote:
On 10/24/2012 01:20 PM, Paolo Carlini wrote:
+ if (parm == error_mark_node
+ || TREE_PURPOSE (parm) == error_mark_node)
It seems odd to bail out early if the default argument is bad even if
we aren't trying to use it. Doesn't it wor
On Wed, 24 Oct 2012, Jason Merrill wrote:
On 10/19/2012 04:40 PM, Marc Glisse wrote:
So between the following:
a) x?y:z means (x<0)?y:z
b) x?y:z means (x!=0)?y:z
c) x?y:z is rejected, only things like (x==t)?y:z are accepted
d) other
is the choice still b) ? That's an easy one, only 2 characte
On 10/23/2012 03:43 PM, Jakub Jelinek wrote:
On Tue, Oct 23, 2012 at 03:34:46PM -0600, Jeff Law wrote:
I think it should be backported to 4.7, perhaps with a few days delay after the
trunk commit.
Do we even have debug statements after control flow statements?
They shouldn't be there, so if y
This patch to libgo arranges to define SIGPOLL and SIGCLD if necessary,
as SIGIO and SIGCHLD respectively. This is necessary on GNU/Linux
because SIGPOLL is #define'd as SIGIO before SIGIO is #define'd, and gcc
-fdump-go-spec doesn't understand that. Bootstrapped and ran Go
testsuite on x86_64-un
On Wed, Oct 24, 2012 at 08:36:19PM +0200, Marc Glisse wrote:
> On Wed, 24 Oct 2012, Jason Merrill wrote:
>
> >On 10/19/2012 04:40 PM, Marc Glisse wrote:
> >>So between the following:
> >>a) x?y:z means (x<0)?y:z
> >>b) x?y:z means (x!=0)?y:z
> >>c) x?y:z is rejected, only things like (x==t)?y:z ar
Hi,
On 10/24/2012 06:57 PM, Jason Merrill wrote:
On 10/10/2012 11:13 AM, Paolo Carlini wrote:
- error ("type transparent class %qT does not have any fields", t);
+ if (TREE_CODE (t) == UNION_TYPE)
+error ("type transparent union %qT does not have any
fields", t);
+ else
On Wed, Oct 24, 2012 at 4:25 PM, Richard Biener wrote:
> Comments? Should find_many_sub_basic_blocks really do what
> it does here? Or is the CFG in fact "invalid" (but we don't
> check that in verification)?
If a "noreturn" function is inlined, doesn't the inliner detect that
the inlined body
My guess for the reason why OpenCL has the semantics it does is that if
you stored a boolean result in a variable earlier and then use it as the
? condition, that would require an extra comparison whereas if it's
already a vector of 0 and -1 as expected it can be used directly.
Jason
On 10/24/2012 02:11 PM, Paolo Carlini wrote:
The problem is that the first time we go through the loop, when parm_idx
== 0 and TREE_PURPOSE is error_mark_node, the condition:
if (template_parameter_pack_p (TREE_VALUE (parm))
&& !(arg && ARGUMENT_PACK_P (arg)))
near the beginning o
On 10/24/2012 03:48 PM, Paolo Carlini wrote:
+ error ("type transparent %q#T cannot be made transparent because "
+"a field has neither pointer nor integer type", t);
I'd say "%q#T cannot be made transparent because %q#D has neither
pointer nor integer type", t, field.
The following patch fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55055
In this case, operand was an address containing subreg. LRA before
the patch processed only operands which are subregs of regs.
The patch was successfully bootstrapped on x86/x86-64.
Committed as rev. 192779.
On Wed, 24 Oct 2012, Jason Merrill wrote:
My guess for the reason why OpenCL has the semantics it does is that if you
stored a boolean result in a variable earlier and then use it as the ?
condition, that would require an extra comparison whereas if it's already a
vector of 0 and -1 as expecte
Hi,
On 10/24/2012 09:55 PM, Jason Merrill wrote:
On 10/24/2012 03:48 PM, Paolo Carlini wrote:
+ error ("type transparent %q#T cannot be made transparent
because "
+ "a field has neither pointer nor integer type", t);
I'd say "%q#T cannot be made transparent because %q#D has neit
On 10/24/2012 09:53 PM, Jason Merrill wrote:
On 10/24/2012 02:11 PM, Paolo Carlini wrote:
The problem is that the first time we go through the loop, when parm_idx
== 0 and TREE_PURPOSE is error_mark_node, the condition:
if (template_parameter_pack_p (TREE_VALUE (parm))
&& !(arg &&
On Oct 24, 2012, at 12:38 PM, Jakub Jelinek wrote:
> On Wed, Oct 24, 2012 at 08:36:19PM +0200, Marc Glisse wrote:
>> On Wed, 24 Oct 2012, Jason Merrill wrote:
>>
>>> On 10/19/2012 04:40 PM, Marc Glisse wrote:
So between the following:
a) x?y:z means (x<0)?y:z
b) x?y:z means (x!=0)?
Hi,
let's try again ;) In the light of discussion in Portland, which liked
Marc's idea of using std::decay in the unary common_type too, the below
seems good to go now, given that there are bad interactions with the
front-end bug we have got.
Tested x86_64-linux.
Thanks,
Paolo.
///
On Wed, 24 Oct 2012, Mike Stump wrote:
Well, I suspect the OpenCL community had a ton of people sweat over the
details and take into consideration the realities and the needs of
people. I'd like to believe they had more people in on this and that
this was a compromise for someones vector unit
.. Oh well, and the details of this are even subtler, because, assuming
we want the exact same behavior of the C front-end, we are going to accept:
typedef union {
int* f;
int y;
} __attribute__(( __transparent_union__ )) example_t;
and reject:
typedef union {
int f;
int* y;
} __attrib
On Wed, 24 Oct 2012, Paolo Carlini wrote:
let's try again ;) In the light of discussion in Portland, which liked Marc's
idea of using std::decay in the unary common_type too, the below seems good
to go now, given that there are bad interactions with the front-end bug we
have got.
template
Mike, Sharad,
> Committed in r192750.
Thanks for the review and the commit.
Dominique
Added myself as write after approval maintainer in r192781.
Thanks,
Sharad
Index: ChangeLog
===
--- ChangeLog (revision 192779)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2012-10-24 Sharad Singhai
+
+ * MAINTAINERS (Write After
On Wed, Oct 24, 2012 at 11:03 AM, Ian Lance Taylor wrote:
>
> OK, so it's a garbage collector problem. Can you e-mail me the test
> binary offlist? I will try to figure out where readFile lives. The
> fact that I'm not seeing any GC problems on x86 or x86_64 suggests
> that this is something Al
2012/10/24 Marc Glisse :
> On Wed, 24 Oct 2012, Paolo Carlini wrote:
>
>> let's try again ;) In the light of discussion in Portland, which liked
>> Marc's idea of using std::decay in the unary common_type too, the below
>> seems good to go now, given that there are bad interactions with the
>> fron
PR 55061 is about a case in which the compiler used to build stage 1
(Xcode 3.1.4 on PPC Darwin) is a version of GCC that does not correctly
support the -funwind-tables option. The libbacktrace configure script
was assuming that all versions of GCC support -funwind-tables. This
patch changes it t
On Wed, Oct 24, 2012 at 10:37 AM, Vladimir Makarov wrote:
> The following path shouldfix
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55049
>
> The patch was successfully bootstrapped on x86-64. Sorry, I can not
> bootstrap with mx32 because of libraries absence.
>
> Committed as rev. 192
LRA branch was merged with trunk @ 192779.
Committed as rev. 192787.
On Wed, Oct 24, 2012 at 10:37 AM, Vladimir Makarov wrote:
> The following path shouldfix
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55049
>
> The patch was successfully bootstrapped on x86-64. Sorry, I can not
> bootstrap with mx32 because of libraries absence.
It passed libgcc. Now I g
On Wed, 24 Oct 2012, Iyer, Balaji V wrote:
> > Where in the patch you use int for the size of something (e.g. a list) on
> > the host,
> > please use size_t.
>
> Can you please give me an example where I am violating this rule? Here
> is a link to the last submitted patch in case you need it
>
Uros Bizjak writes:
> Yes, I am running under gdb and all FDs are offset by +4 for some
> reason. So, FD 8 corresponds to FD4 in the strace log.
This is normal, gdb is leaking some fds to the inferior (which is a
bug).
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58
As per discussion in http://gcc.gnu.org/ml/gcc/2012-10/msg00366.html.
I have applied the following obvious fix for rs6000 broken bootstrap.
2012-10-24 Sharad Singhai
* config/rs6000/rs6000.c (rs6000_density_test): Use dump_enabled_p
instead of dump_kind_p.
Index: config/rs60
This also causes PR bootstrap/55067 on AIX due to the use of typedef loc_t.
Thanks, David
Joel and Ralf,
Would you please comment on this patch?
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02154.html
Thanks, David
On Tue, Oct 16, 2012 at 10:32 AM, Jan Hubicka wrote:
> Hi,
> here is third revised version of the complette unroling changes. While
> working
> on the RTL variant I noticed PR54937 and the fact that I was overly aggressive
> on forcing single exit of the last iteration to be taken, because loop
1 - 100 of 113 matches
Mail list logo
