On 05/11/2012 01:59 PM, Richard Guenther wrote:
This fixes the dependency of vectorization of strided loads on
gather support. For that to work we need to lift the restriction
in data-ref analysis that requries a constant DR_STEP. Fortunately
fallout is small.
Would this also vectorize strid
On 05/12/2012 05:13 AM, Jason Merrill wrote:
I find the name "sentry" confusing; I don't see how it applies.
Perhaps "current" instead?
Eh, from the point of view of a C++ library guy is even more confusing
but I tried to overcome that feeling ;) Anyway the below is the patch as
committed, usi
On 05/12/2012 04:55 AM, Jason Merrill wrote:
On 05/11/2012 06:03 AM, Paolo Carlini wrote:
if (TYPE_PTR_P (type)
&& !TYPE_PTRFN_P (type)
- && !TYPE_PTR_TO_MEMBER_P (type))
+ && !TYPE_PTRMEM_P (type))
The check for !pointer to member is no longer necessary, since they
don't use POINT
On Fri, May 11, 2012 at 11:16:08AM -0700, H.J. Lu wrote:
> This patch uses + in constraint and match_dup in xbegin_1. OK for
> trunk?
The patch is buggy, xbegin expander leaves operands[0] uninitialized.
Fixed thusly, untested on rtm hw though:
2012-05-12 Andrew Pinski
H.J. Lu
Committed as obvious: character(len=:) is allowed as result in pure
functions - while character(len=*) functions are not. (In the latter
case, the length the function returns depends on the definition of the
caller (!).)
The attached patch was build and regtested on x86-64-linux and committed
On Fri, May 11, 2012 at 8:11 PM, Xinliang David Li wrote:
> To be more specific, does the following match what your envisioned?
>
> 1) when multiple streams are specified for dumping, the information
> will be dumped to all streams IF the new dumping interfaces are used
> (see below). For legacy c
On Sat, May 12, 2012 at 9:53 AM, Toon Moene wrote:
> On 05/11/2012 01:59 PM, Richard Guenther wrote:
>
>> This fixes the dependency of vectorization of strided loads on
>> gather support. For that to work we need to lift the restriction
>> in data-ref analysis that requries a constant DR_STEP. F
-linux-gnu.
gcc version 4.8.0 20120512 (experimental).
Have a nice weekend.
Alessandro.
2012/5/7 Tobias Burnus :
> Hello,
>
>
> On 05/06/2012 09:37 PM, Alessandro Fanfarillo wrote:
>>
>> The patch is bootstrapped and tested on x86_64-unknown-linux-gnu - gcc
>&
On 05/12/2012 12:36 PM, Richard Guenther wrote:
On Sat, May 12, 2012 at 9:53 AM, Toon Moene wrote:
On 05/11/2012 01:59 PM, Richard Guenther wrote:
This fixes the dependency of vectorization of strided loads on
gather support. For that to work we need to lift the restriction
in data-ref an
On Sat, May 12, 2012 at 1:39 PM, Toon Moene wrote:
> On 05/12/2012 12:36 PM, Richard Guenther wrote:
>
>> On Sat, May 12, 2012 at 9:53 AM, Toon Moene wrote:
>
>
>>> On 05/11/2012 01:59 PM, Richard Guenther wrote:
>>>
This fixes the dependency of vectorization of strided loads on
gather
Hello Alessandro,
Alessandro Fanfarillo wrote:
in attachment there's the new candidate patch, revisited by Tobias,
for PR fortran/45170, PR fortran/52158 and PR fortran/49430
(unexpectedly).
Please, check the Changelog, I don't know whether the descriptions are ok.
The patch is bootstrapped and
On 11 May 2012 21:23, Joseph S. Myers wrote:
>
> There's nothing wrong with having separate autogenerated functions for
> each language if you want to split things out that way, but it would seem
> simpler just to have one function called somewhere central, whatever
> option it is (common or not)
On Fri, May 11, 2012 at 7:04 PM, Sriraman Tallam wrote:
> Hi H.J.,
>
> I have updated the patch to improve the dispatching method like we
> discussed. Each feature gets a priority now, and the dispatching is
> done in priority order. Please see i386.c for the changes.
>
> Patch also available fo
libgcc/
* config/rs6000/aix-unwind.h (ucontext_for): Helper for ...
(ppc_aix_fallback_frame_state): New, implementation of ...
(MD_FALLBACK_FRAME_STATE_FOR): Define.
Please do not create another definition of the register number for LR.
Earlier in the file it is defined as
On Sat, 12 May 2012, Manuel L?pez-Ib??ez wrote:
> On 11 May 2012 21:23, Joseph S. Myers wrote:
> >
> > There's nothing wrong with having separate autogenerated functions for
> > each language if you want to split things out that way, but it would seem
> > simpler just to have one function called
On Sat, May 12, 2012 at 10:12 AM, Joseph S. Myers
wrote:
> I don't think common.opt should have LangEnabledBy listing different
> languages, though; that information should be in the front ends' .opt
> files.
Agreed.
> And, before we add such language-specific enabling of a
> language-independen
On 12 May 2012 17:18, Gabriel Dos Reis wrote:
> On Sat, May 12, 2012 at 10:12 AM, Joseph S. Myers
> wrote:
>> I don't think common.opt should have LangEnabledBy listing different
>> languages, though; that information should be in the front ends' .opt
>> files.
>
> Agreed.
Ideally, yes. But how?
Sounds good.
On Sat, May 12, 2012 at 3:31 AM, Richard Guenther
wrote:
> On Fri, May 11, 2012 at 8:11 PM, Xinliang David Li wrote:
>> To be more specific, does the following match what your envisioned?
>>
>> 1) when multiple streams are specified for dumping, the information
>> will be dumped to
On Sat, 12 May 2012, Manuel López-Ibáñez wrote:
> Let's assume C-specific option -Wx enables common option -Wy. How can
> I record this information in c.opt? Using Wx LangEnables(C, Wy) does
Wy
LangEnabledBy(C C++, Wx)
There is no restriction on c.opt to contain only options marked as
specifi
On Sat, May 12, 2012 at 11:05 AM, Xinliang David Li wrote:
> The downside is that the dump file format will look different from the
> stderr output which is less than ideal.
BTW, why do people want to use stderr for dumping internal IRs,
as opposed to stdout or other files? That does not sound
On 12 May 2012 18:12, Joseph S. Myers wrote:
> On Sat, 12 May 2012, Manuel López-Ibáñez wrote:
>
>> Let's assume C-specific option -Wx enables common option -Wy. How can
>> I record this information in c.opt? Using Wx LangEnables(C, Wy) does
>
> Wy
> LangEnabledBy(C C++, Wx)
>
> There is no rest
On Sat, May 12, 2012 at 9:26 AM, Gabriel Dos Reis
wrote:
> On Sat, May 12, 2012 at 11:05 AM, Xinliang David Li
> wrote:
>
>> The downside is that the dump file format will look different from the
>> stderr output which is less than ideal.
>
> BTW, why do people want to use stderr for dumping int
Hi,
the below is my (very conservative, I think) interpretation of what we
recently summarized we want to do wrt these -Wconversion warnings in the
conditional expressions context. Of course many details could be
different, please let me know... This is booted and tested on x86_64-linux.
Tha
On 12 May 2012 19:34, Paolo Carlini wrote:
> Hi,
>
> the below is my (very conservative, I think) interpretation of what we
> recently summarized we want to do wrt these -Wconversion warnings in the
> conditional expressions context. Of course many details could be different,
> please let me know.
On 05/12/2012 07:51 PM, Manuel López-Ibáñez wrote:
It seems very conservative also to me. I think the code should just
unconditionally recurse on the operands of COND_EXPR. The recursion
should then take care of the casts. So then c = b ? c : i; will warn
about 'i', not about the whole condition
On 12 May 2012 20:15, Paolo Carlini wrote:
> On 05/12/2012 07:51 PM, Manuel López-Ibáńez wrote:
>>
>> It seems very conservative also to me. I think the code should just
>> unconditionally recurse on the operands of COND_EXPR. The recursion
>> should then take care of the casts. So then c = b ? c
On Sun, 6 May 2012, Andrew Pinski wrote:
> > For the record: MIPS processors that implement CLZ/CLO (for some reason
> > CTZ/CTO haven't been added to the architecture, but these operations can
> > be cheaply transformed into CLZ/CLO) generally have a dedicated unit that
> > causes no pipeline st
On Sat, 12 May 2012, Manuel López-Ibáñez wrote:
> Well, I was trying to avoid "merging" flags. Are there any examples of
> other such flags that are merged? The thing is that the "merge" done
> right now is really just concatenating existing flags. It doesn't work
> to set Init(1) and Init(0) in t
On Sat, May 12, 2012 at 11:36 AM, Maciej W. Rozycki
wrote:
> On Sun, 6 May 2012, Andrew Pinski wrote:
>
>> > For the record: MIPS processors that implement CLZ/CLO (for some reason
>> > CTZ/CTO haven't been added to the architecture, but these operations can
>> > be cheaply transformed into CLZ/C
Something changed recently, probably in the back-end, and this broke bootstrap
with Ada enabled because the gnattools cannot be linked anymore.
Fixed thusly, bootstrapped/regtested on PowerPC/Linux, applied on the mainline.
2012-05-12 Eric Botcazou
* gcc-interface/Makefile.in (TOOLS
This is a regression present on the mainline and 4.7 branch. The attached
testcase now fails because the function lacks a stack frame that would yield
the unique CFA expected by the unwinder.
Bootstrapped/regtested on PowerPC/Linux, applied on mainline and 4.7 branch.
2012-05-12 Eric Botcazo
> libgcc/
> * config/rs6000/aix-unwind.h (ucontext_for): Helper for ...
> (ppc_aix_fallback_frame_state): New, implementation of ...
> (MD_FALLBACK_FRAME_STATE_FOR): Define.
I forgot to ask, is there a non-Ada, target-specific testcase that you
can add to ensure this functiona
Paolo Bonzini wrote:
> Il 11/05/2012 07:13, Matthias Klose ha scritto:
>> +The multiarch tuples are defined
>> +in @uref{http://wiki.debian.org/Multiarch/Tuples}.
>
> Is this needed? Aren't they defined simply by the GCC source code?
> Surely if some other OS implements multiarch with different t
According to discussion in the PR, GDB would prefer a
DW_TAG_structure_type with DW_AT_signature to a DW_TAG_typedef with
DW_AT_type when the type in question is a class. I haven't been able to
reproduce the failure with current GDB, but it passes the testsuite
after the change as well.
Test
34 matches
Mail list logo
