Hi Jonathan,
On 22 Oct 2011, at 22:54, Jonathan Wakely wrote:
I've committed this, if I've broken anything for non-POSIX platforms
there will be time to fix it before 4.7
At present, (180333-180339) these tests seem to be failing on *-
darwin{9,10} (which are posix) - with the failure owing
Eric, if you could give this some eyeballs I'd really appreciate it.
I think this brings the number of move patterns down to a more
acceptable level. I didn't have the muster to attack the TFmode
moves just yet. But honestly I think this is a good start.
I quickly ran this through check-gcc bo
Original discussion here:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00751.html
This patch enables vector conversions for ARM NEON architecture. In its
current state vectorizer can't handle type conversions in the hottest
loop of libmp3lame on NEON since its backend doesn't have appropriate
On 24 October 2011 08:27, Iain Sandoe wrote:
> Hi Jonathan,
>
> On 22 Oct 2011, at 22:54, Jonathan Wakely wrote:
>
>> I've committed this, if I've broken anything for non-POSIX platforms
>> there will be time to fix it before 4.7
>
> At present, (180333-180339) these tests seem to be failing on *-d
On Sun, Oct 23, 2011 at 7:28 PM, Xinliang David Li wrote:
> On Sun, Oct 23, 2011 at 3:18 AM, Richard Guenther
> wrote:
>> On Fri, Oct 21, 2011 at 6:48 PM, Xinliang David Li
>> wrote:
>>> There are two proposals here. One is -fopt-info which prints out
>>> informational notes to stderr, and the
Hi,
With this patch we are able to stop basic block analysis in case of
unsupported data-ref and still vectorize the first part of the basic
block.
Bootstrapped and tested on powerpc64-suse-linux.
Committed.
Ira
ChangeLog:
PR tree-optimization/50730
* tree-vect-data-refs.c (vec
This patch reimplements the synchronization of the mechanism which handles the
allocation, deallocation and finalization of heap-allocated controlled objects.
Tested on x86_64-pc-linux-gnu, committed on trunk
2011-10-24 Hristian Kirtchev
* s-finmas.adb (Attach): Synchronize and call t
This patch corrects the usage of source locations in the generation of a type
initialization procedure. Inconsistent locations may lead to false positives
detected by the elaboration check circuitry.
Tested on x86_64-pc-linux-gnu, committed on trunk
2011-10-24 Hristian Kirtchev
* exp_
This patchlet eliminates a typo in Covers_Some_Interface.
Tested on x86_64-pc-linux-gnu, committed on trunk
2011-10-24 Eric Botcazou
* sem_disp.adb (Covers_Some_Interface): Fix typo.
Index: sem_disp.adb
===
--- sem_disp.
The predicate that decides whether to dequeue a high priority item included a
negation operator, but this reversed the correct sense.
Tested on x86_64-pc-linux-gnu, committed on trunk
2011-10-24 Matthew Heaney
* a-cuprqu.adb, a-cbprqu.adb (Dequeue_Only_High_Priority):
Predicat
This patches fixes a regression introduced when adding support for
aggregate projects. The latter now accept a new list attribute called
Project_Path. But if the user already has a string variable by this name,
the project can no longer be loaded by GNAT. The following project should
be loaded with
Part of work for KA07-013
This patch adds a couple of missing warnings to the set of warnings
that are activated by -gnatw.g or -gnatg. This affects only internal
builds, so no test is required. The necessary adjustments to front-end
sources to avoid triggering these new warnings have already been
Spotted by Karl as well, and addressed thusly.
Gerald
Index: egcs-1.1/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/egcs-1.1/index.html,v
retrieving revision 1.5
diff -u -r1.5 index.html
--- egcs-1.1/index.html 4 Jan 2003 18:34:18
This patch adjusts enumeration put to conform with the ruling in
ramification AI Ada2012-R036. Width number of characters must be
output on a single line, if impossible, a layout error is raised.
The following test program:
1. with Ada.Text_IO;
2. use Ada.Text_IO;
3. procedure Tes
On Fri, Oct 21, 2011 at 1:56 PM, Rainer Orth
wrote:
> Iain Sandoe writes:
>
>> It looks like the gnat testsuite is also broken - but HP's fix doesn't
>> recover that.
>> .. will try and take a look - but short on time today,
>
> I think I see what's going on: in gnat.log, I find
>
> Running /vol/
On 10/21/11 20:38, Bernd Schmidt wrote:
> On 10/21/11 15:42, Bernd Schmidt wrote:
>> On 10/14/11 17:35, Vladimir Makarov wrote:
>>> The scheduler part of the patch is ok for me (other part changes are
>>> obvious). Could you only commit it at the beginning of the next week.
>>
>> I've committed th
The PR uses -fshrink-wrap as the only option, no -Ox. We crash because
shrink-wrapping expects return insns to be generated later on, and that
code is guarded with if (optimize).
Committed the following as obvious after bootstrapping on i686-linux.
Bernd
Hi,
the below is a new variant removing -Wc++0x-compat from -Wall (cannot be
added to -Wextra either because bootstrap passes -W) and also, as
requested by Gaby, preventing -Wno-narrowing from suppressing the
warning in C++0x mode (if the user really needs to silence it,
-Wno-c++0x-compat wor
This patch adds description of EIND usage.
This is needed because users are confused about it and some undocumented
caveats and even developers might get confused if there is no clear statement
about EIND usage and limitations.
The patch adds the description as subsubsection to the AVR Options su
2011/10/24 Georg-Johann Lay :
> This patch adds description of EIND usage.
>
> This is needed because users are confused about it and some undocumented
> caveats and even developers might get confused if there is no clear statement
> about EIND usage and limitations.
>
> The patch adds the descript
On Mon, Oct 24, 2011 at 6:47 AM, Paolo Carlini wrote:
> Hi,
>
> the below is a new variant removing -Wc++0x-compat from -Wall (cannot be
> added to -Wextra either because bootstrap passes -W) and also, as requested
> by Gaby, preventing -Wno-narrowing from suppressing the warning in C++0x
> mode (
Hi,
On Mon, Oct 24, 2011 at 6:47 AM, Paolo Carlini wrote:
Hi,
the below is a new variant removing -Wc++0x-compat from -Wall (cannot be
added to -Wextra either because bootstrap passes -W) and also, as requested
by Gaby, preventing -Wno-narrowing from suppressing the warning in C++0x
mode (if t
This fixes PR50838.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2011-10-24 Richard Guenther
PR tree-optimization/50838
* tree-data-ref.c (dr_analyze_indices): Properly canonicalize
a MEM_REF base if we change it.
* gcc.dg/torture/p
On Thu, 20 Oct 2011, Jakub Jelinek wrote:
> On Thu, Oct 20, 2011 at 11:42:01AM +0200, Richard Guenther wrote:
> > > + if (TREE_CODE (scalar_dest) == VIEW_CONVERT_EXPR
> > > + && is_pattern_stmt_p (stmt_info))
> > > +scalar_dest = TREE_OPERAND (scalar_dest, 0);
> > >if (TREE_CODE (sca
On 10/24/2011 02:18 PM, Paolo Carlini wrote:
OK with a minor correction. This bit
+With -std=c++0x, @option{-Wno-c++0x-compat} can be used to suppress
+the diagnostic required by the standard.
should not be there. It is currently an accident of implementation
detail as opposed to a feature.
On Mon, Oct 24, 2011 at 7:18 AM, Paolo Carlini wrote:
> Hi,
>>
>> On Mon, Oct 24, 2011 at 6:47 AM, Paolo Carlini
>> wrote:
>>>
>>> Hi,
>>>
>>> the below is a new variant removing -Wc++0x-compat from -Wall (cannot be
>>> added to -Wextra either because bootstrap passes -W) and also, as
>>> request
On 10/24/2011 07:47 AM, Paolo Carlini wrote:
the below is a new variant removing -Wc++0x-compat from -Wall (cannot be
added to -Wextra either because bootstrap passes -W)
I don't understand the rationale for this. If the warning is
problematic for bootstrap, why not just add -Wno-narrowing to
On 10/24/2011 09:06 AM, Jason Merrill wrote:
On 10/24/2011 07:47 AM, Paolo Carlini wrote:
the below is a new variant removing -Wc++0x-compat from -Wall (cannot be
added to -Wextra either because bootstrap passes -W)
I don't understand the rationale for this. If the warning is problematic
for b
This adds missing documentation for OS_task and OS_main function attributes.
The subsection with "progmem" documentation is moved up for alphabetical order
(AVR typically appears between ARM and Blackfin).
Ok for 4.6?
Johann
PR target/49824
* doc/extend.texi (Declaring Attribute
On Mon, Oct 24, 2011 at 8:06 AM, Jason Merrill wrote:
> On 10/24/2011 07:47 AM, Paolo Carlini wrote:
[...]
>> and also, as
>> requested by Gaby, preventing -Wno-narrowing from suppressing the
>> warning in C++0x mode (if the user really needs to silence it,
>> -Wno-c++0x-compat works). I also adde
On 10/24/2011 09:26 AM, Gabriel Dos Reis wrote:
On Mon, Oct 24, 2011 at 8:06 AM, Jason Merrill wrote:
No. I added -Wno-narrowing specifically to suppress the diagnostic in C++0x
mode; see c++/49793. There are several diagnostics required by standards
that can be suppressed by -Wno- flags, s
Hello,
what about the attached patch based on the original patch provided by Bernd
Schmidt with modifications suggested by Richard Earnshaw.
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 8
.. just to let you know guys, I'm already unassigned from the PR, but
today I wanted to give it one (actually 3) more try. Given the
controversy, I don't feel like further following the issue, it just
makes me nervous. Eventually, feel free to adjust my patches to your likes.
Paolo.
OK, I've removed the pointer-arithmetic case from expand, to be handled
later by straight-line strength reduction. Here's the patch to deal
with just the specific pattern of PR46556 (which will also eventually be
handled by strength reduction, but not as quickly).
(FYI, I've been thinking through
This sketches a simple local mod-ref analysis, piggy-backed ontop
of the local IPA pure-const machinery (well, just sharing its
pass really). I am not yet sure how or if it will be possible
to IPA propagate this (other than handling already processed
bodies during local discovery) - we would need
On Mon, Oct 24, 2011 at 8:29 AM, Jason Merrill wrote:
> On 10/24/2011 09:26 AM, Gabriel Dos Reis wrote:
>>
>> On Mon, Oct 24, 2011 at 8:06 AM, Jason Merrill wrote:
>
>>> No. I added -Wno-narrowing specifically to suppress the diagnostic in
>>> C++0x
>>> mode; see c++/49793. There are several di
This is the same explanation as aleady approved for 4.6.
Ok for trunk?
Johann
PR target/50820
* doc/invoke.texi (AVR Options): New subsubsection to explain EIND
handling and indirect jump/calls on devices > 128k.
Index: doc/invoke.texi
On Mon, 24 Oct 2011, Dmitry Plotnikov wrote:
> * neon.md (floatv2siv2sf2): New.
> (floatunsv2siv2sf2): New.
> (floatv4siv4sf2): New.
> (floatunsv4siv4sf2): New.
My undertstanding is that the NEON conversions of integer vectors to
floating point always round to nearest - so
On Mon, 24 Oct 2011, Richard Guenther wrote:
> On Thu, 20 Oct 2011, Jakub Jelinek wrote:
>
> > On Thu, Oct 20, 2011 at 11:42:01AM +0200, Richard Guenther wrote:
> > > > + if (TREE_CODE (scalar_dest) == VIEW_CONVERT_EXPR
> > > > + && is_pattern_stmt_p (stmt_info))
> > > > +scalar_dest =
On 10/24/2011 09:49 AM, Gabriel Dos Reis wrote:
On Mon, Oct 24, 2011 at 8:29 AM, Jason Merrill wrote:
Right, -Wno-long-long is only useful in C++03 and C90. But it does in fact
suppress a standard diagnostic.
a diagnostic of an extension :-)
I'm not going to argue semantics any further. W
This is the same documentation extension as proposed for 4.6.
Ok for trunk?
Johann
PR target/49824
* doc/extend.texi (Declaring Attributes of Functions):
Document OS_main and OS_task attributes.
(Specifying Attributes of Variables): Move up
subsection "AVR
2011/10/24 Georg-Johann Lay :
> This adds missing documentation for OS_task and OS_main function attributes.
>
> The subsection with "progmem" documentation is moved up for alphabetical order
> (AVR typically appears between ARM and Blackfin).
>
> Ok for 4.6?
>
> Johann
>
> PR target/49824
>
2011/10/24 Georg-Johann Lay :
> This is the same explanation as aleady approved for 4.6.
>
> Ok for trunk?
>
> Johann
>
> PR target/50820
> * doc/invoke.texi (AVR Options): New subsubsection to explain EIND
> handling and indirect jump/calls on devices > 128k.
>
Ok.
Denis.
On Mon, Oct 24, 2011 at 9:10 AM, Jason Merrill wrote:
> On 10/24/2011 09:49 AM, Gabriel Dos Reis wrote:
>>
>> On Mon, Oct 24, 2011 at 8:29 AM, Jason Merrill wrote:
>>>
>>> Right, -Wno-long-long is only useful in C++03 and C90. But it does in
>>> fact
>>> suppress a standard diagnostic.
>>
>> a d
2011/10/24 Georg-Johann Lay :
> This is the same documentation extension as proposed for 4.6.
>
> Ok for trunk?
>
> Johann
>
> PR target/49824
> * doc/extend.texi (Declaring Attributes of Functions):
> Document OS_main and OS_task attributes.
> (Specifying Attributes of
On 10/24/2011 10:39 AM, Gabriel Dos Reis wrote:
Hmm, the narrowing semantics also affects SFINAE, not just simple declaration.
If we want a flag that can also affect the outcome of overload
resolution, it should one of the the -fflags, such as -fpermissive.
I don't want the option to affect SFI
On 24 October 2011 15:02, Joseph S. Myers wrote:
> On Mon, 24 Oct 2011, Dmitry Plotnikov wrote:
>
>> * neon.md (floatv2siv2sf2): New.
>> (floatunsv2siv2sf2): New.
>
>> (floatv4siv4sf2): New.
>> (floatunsv4siv4sf2): New.
>
> My undertstanding is that the NEON conversions of in
On 10/21/11 15:46, Joseph S. Myers wrote:
On Fri, 21 Oct 2011, Aldy Hernandez wrote:
X32 uses x86-64 instruction set with 32bit pointers. It has the same
atomic support as x86-64 and has atomic support for int128.
Oh, you aren't talking about 32 bit, but a 32 bit abi on a 64 bit machine.
Th
On Mon, Oct 24, 2011 at 8:31 AM, Aldy Hernandez wrote:
> On 10/21/11 15:46, Joseph S. Myers wrote:
>>
>> On Fri, 21 Oct 2011, Aldy Hernandez wrote:
>>
> X32 uses x86-64 instruction set with 32bit pointers. It has the same
> atomic support as x86-64 and has atomic support for int128.
>
Bootstrapped and tested on i686 with same number of errors.
Sorry to ask you to run more tests, but can you also test x86-64? If
there are no regressions on x86-64 either, OK.
Aldy
This works for me. Do you agree?
It looks good to me.
OK, will commit.
Thanks guys.
On Sat, Oct 22, 2011 at 10:11 AM, Iyer, Balaji V
wrote:
> Hello Everyone,
> This patch is for the Cilkplus GCC branch. This patch will replace the
> poisoned implicit_built_in_decls array with the appropriate function calls.
>
> Thanks,
I checked it in for you.
--
H.J.
On Sat, Oct 22, 2011 at 10:11 AM, Iyer, Balaji V
wrote:
> Hello Everyone,
> This patch is for the Cilkplus GCC branch. It will add a new function
> parameter (CALL_NORMAL) to build_special member_call. This patch is needed
> to fix a merge issue.
>
> Thanks,
>
I checked it in for you.
On Mon, Oct 24, 2011 at 04:09:49PM +0200, Richard Guenther wrote:
> This one bootstraps and regtests fine on x86_64-unknown-linux-gnu.
> I didn't find a good pattern to split out, eventually how we call
> the vectorizable_* routines should be re-factored a bit.
Here is an updated patch on top of w
On 10/24/11 10:40, Aldy Hernandez wrote:
Bootstrapped and tested on i686 with same number of errors.
Sorry to ask you to run more tests, but can you also test x86-64? If
there are no regressions on x86-64 either, OK.
As discussed off-line, I'll run x86-64 tests for you since you don't
have
> Well, you seem to keep not reading what I write. I am not opposed
> to adding -fopt-info/report nor to funnel messages to stdout/err. What
> I am opposed is the way you want to introduce them. I want you to
> fix what we dump into dump files, so that both -fopt-report and -fopt-info
> can be i
Hi!
This is something that got fixed on the trunk as part of PR48400,
but in 4.6 dwarf2out_source_line is quite a bit different, emits
discriminators only when using .loc directives etc.
Ok for branch?
2011-10-24 Jakub Jelinek
PR debug/50816
* dwarf2out.c (dwarf2out_source_lin
On Mon, 24 Oct 2011, Ramana Radhakrishnan wrote:
> That is correct - they round towards nearest if converting from
> integer to floating point and round towards zero if converting in the
> reverse direction. !flag_rounding_math should be the case at the very
> least. I'm not yet convinced that you
> Great, committed to trunk.
Minor nit: can't you uncouple the GY, ZC and DF couples of constraints now?
We presumably need only one member of the couples per alternative now, i.e
F,G,C in FP insns and D,Y,Z in vector insns.
--
Eric Botcazou
Jason Merrill writes:
> On 10/21/2011 07:37 PM, Dodji Seketeli wrote:
>> It also makes linemap_expand_location_full to return the location it
>> resolved to.
>
> I think I'd prefer to have expand_location call
> linemap_resolve_location and then linemap_expand_location, and perhaps
> remove linem
> This patch implements the front end work for fixing this problem
>
> References to atomic variables (identifiers or expanded names)
> have a flag Atomic_Sync_Required to flag to the back end that
> appropriate memory barriers are to be generated.
For the sake of completeness, gigi will translate
Jason Merrill writes:
> I think a better fix to your binary search algorithm would be to change
>
> mn = md;
>
> to be
>
> mn = md + 1;
>
> since you've eliminated md as a possibility. And then change the test to
>
> (mn < mx).
>
Right, thanks.
Here the updated patch, bootstrapped and te
> Eric, if you could give this some eyeballs I'd really appreciate it.
Looks good to me, modulo...
> diff --git a/gcc/config/sparc/sparc.md b/gcc/config/sparc/sparc.md
> index 0f716d6..3462e6f 100644
> --- a/gcc/config/sparc/sparc.md
> +++ b/gcc/config/sparc/sparc.md
> @@ -240,6 +240,17 @@
>
Hi,
the attached patch fixes all the strlenopt failures on s390x (without
nuking the strcat folding).
The one case I couldn't get working so far is the second strlen in:
__attribute__((noinline, noclone)) size_t
bar (char *p, char *q)
{
char *r;
size_t l1, l2;
r = strchr (p, '\0');
strc
On Mon, Oct 24, 2011 at 9:53 AM, Jason Merrill wrote:
> On 10/24/2011 10:39 AM, Gabriel Dos Reis wrote:
>>
>> Hmm, the narrowing semantics also affects SFINAE, not just simple
>> declaration.
>> If we want a flag that can also affect the outcome of overload
>> resolution, it should one of the the
On Mon, Oct 24, 2011 at 07:15:14PM +0200, Andreas Krebbel wrote:
> + if (dsi->prev != 0 && (chainsi = verify_related_strinfos (dsi)) !=
> NULL)
> + {
> + bool stmt_set_p = false;
> +
> + for (; chainsi && chainsi != dsi; chainsi = get_strinfo
> (chainsi->next))
> +
OK.
Jason
OK.
Jason
OK.
Jason
On 10/24/2011 01:21 PM, Gabriel Dos Reis wrote:
On Mon, Oct 24, 2011 at 9:53 AM, Jason Merrill wrote:
So, if you make -Wno-narrowing meaningful in C++11 mode then how can
it not affect sfinae (case 1.b.) and still be consistent with the
other case where a diagnostic is required the expression ac
On 2011/10/18 04:03 PM, Eric Botcazou wrote:
>> thread_prologue_and_epilogue_insns should detect all cases where a
>> return insn can be created. So any CFG cleanup that runs before it does
>> not need this functionality.
>
> So we're left with CFG cleanups that run after it and could forward edge
On 10/24/11 20:02, Chung-Lin Tang wrote:
> On 2011/10/18 04:03 PM, Eric Botcazou wrote:
>>> thread_prologue_and_epilogue_insns should detect all cases where a
>>> return insn can be created. So any CFG cleanup that runs before it does
>>> not need this functionality.
>>
>> So we're left with CFG cl
Hello!
2011-10-24 Uros Bizjak
* gcc.target/i386/sse-5.c (dg-options): Add -mno-sse.
Remove -march=i386.
(dg-skip-if): Remove.
* gcc.target/i386/funcspec-1.c: Ditto.
* gcc.target/i386/funcspec-3.c (dg-options): Add -mno-sse3.
Tested on x86_64-pc-linux-gn
On Mon, Oct 24, 2011 at 12:46 PM, Jason Merrill wrote:
> On 10/24/2011 01:21 PM, Gabriel Dos Reis wrote:
>>
>> On Mon, Oct 24, 2011 at 9:53 AM, Jason Merrill wrote:
>> So, if you make -Wno-narrowing meaningful in C++11 mode then how can
>> it not affect sfinae (case 1.b.) and still be consistent
On 10/24/2011 02:13 PM, Gabriel Dos Reis wrote:
yes, but how does the compiler distinguish a "legacy code" compiled
under C++11 from non-legacy C++11 code?
It doesn't.
The problem is with C++11 codes. There is no reason for them to be subjected
to the inconsistency, especially for codes in h
On Mon, Oct 24, 2011 at 1:17 PM, Jason Merrill wrote:
> On 10/24/2011 02:13 PM, Gabriel Dos Reis wrote:
>> The problem is with C++11 codes. There is no reason for them to be
>> subjected
>> to the inconsistency, especially for codes in header files that are
>> upgraded (beyond control of the end
On 10/24/2011 02:47 PM, Gabriel Dos Reis wrote:
What about (testcase)
int f(char);
double f(...);
const int n = sizeof f({257});
?
The narrowing conversion would be marked as 'bad' and therefore the
second overload chosen. As before, the objective is to only change the
d
http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg02603.html shows two
test failures on sparc64-linux, fixed by this patch.
Tested x86_64-linux and committed to trunk.
* testsuite/30_threads/async/49668.cc: Add missing dg-require.
* testsuite/30_threads/packaged_task/49668.cc: Like
The 6g Go compiler has picked up an error if a naked return is used when
named result variables are shadowed. This catches a typical error in Go
programs when using the := construct. This patch implements the same
error in the gccgo frontend. The patch includes a few fixes in the Go
library; eac
Again originally by Karl Berry against our generated NEWS file;
applied.
Gerald
Index: egcs-1.0/features.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/egcs-1.0/features.html,v
retrieving revision 1.7
diff -u -r1.7 features.html
--- egc
With a different fix than Karl suggested (and I also adjusted the
PR): replace powerpc linux by powerpc-unknown-linux-gnu. Applied.
Gerald
Index: gcc-3.2/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.2/changes.html,v
ret
> Can you please explain this stmt_set_p stuff? dont_invalidate should be
> only set on strinfos that will be seen by the immediately following
> maybe_invalidate call (at the end of handle_builtin_strcpy caller -
> strlen_optimize_stmt). If you set it on which unshare_strinfo is called,
> if the
On 10/24/2011 09:18 AM, Kai Tietz wrote:
> A possible patch for 4.6 gcc versions I attached to this mail.
...
> +/* For 32-bit Windows we need valid frame-pointer for function using
> + setjmp. */
> +#define SUBTARGET_SETJMP_NEED_FRAME_POINTER \
> + (!TARGET_64BIT && cfun->calls_setjmp)
> +
>
On Mon, Oct 24, 2011 at 10:04:45PM +0200, Andreas Krebbel wrote:
> > Can you please explain this stmt_set_p stuff? dont_invalidate should be
> > only set on strinfos that will be seen by the immediately following
> > maybe_invalidate call (at the end of handle_builtin_strcpy caller -
> > strlen_op
On 10/23/2011 08:53 PM, David Miller wrote:
> -(define_insn "*movsi_insn"
> +(define_insn "*movsi_insn_novis3"
>[(set (match_operand:SI 0 "nonimmediate_operand" "=r,r,r,m,!f,!f,!m,d,d")
> (match_operand:SI 1 "input_operand" "rI,K,m,rJ,f,m,f,J,P"))]
> - "(register_operand (operands[0],
On Mon, Oct 24, 2011 at 2:05 PM, Jason Merrill wrote:
> On 10/24/2011 02:47 PM, Gabriel Dos Reis wrote:
>>
>> What about (testcase)
>>
>> int f(char);
>> double f(...);
>>
>> const int n = sizeof f({257});
>>
>> ?
>
> The narrowing conversion would be marked as 'bad' and therefore t
From: Eric Botcazou
Date: Mon, 24 Oct 2011 19:00:42 +0200
>> Great, committed to trunk.
>
> Minor nit: can't you uncouple the GY, ZC and DF couples of constraints now?
> We presumably need only one member of the couples per alternative now, i.e
> F,G,C in FP insns and D,Y,Z in vector insns.
Ri
From: Richard Henderson
Date: Mon, 24 Oct 2011 14:05:28 -0700
> You shouldn't need to split these anymore. See the enabled attribute, as
> used on several other targets so far.
See the patch I posted 2 hours after this one.
From: Eric Botcazou
Date: Mon, 24 Oct 2011 19:06:53 +0200
> ...notv9fpu is somewhat ambiguous, fpunotv9 sounds better. I'd also change
> the
> final (const_int 1) to (const_int 0) if you explicitly test "none" above.
Agreed, I'll make these changes and commit to trunk.
Thanks for the review
Just committed the following:
* MAINTAINERS (Write After Approval): Add myself.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 180393)
+++ MAINTAINERS (working copy)
@@ -392,6 +392,7 @@
Martin Jambor
Hi,
2011/10/12 Jason Merrill :
>>> Copying the decl is unlikely to do what we want, I think. Does putting
>>> the
>>> target decl directly into the method vec work?
>>
>> Unfortunately not, it ends up with the same error: undefined
>> reference.
>
> Hunh, that's surprising.
>
>> Furthermore, I do
In doing my next round of lazy builtins I noticed I had accidently put in an
extra new line into builtins.c. I committed this patch as being obvious after
doing a bootstrap:
2011-10-24 Michael Meissner
* builtins.c (set_builtin_user_assembler_name): Remove extra
newline added
This patch adds lazy builtin support for C (by default) and C++ (by option).
At the moment, I have disabled C++ by default because there is a tree layout,
that I can't figure how to avoid C++ from complaining when libcpp/mkdeps.c is
compiled. The problem is string.h has the following:
/* Find the
As discussed earlier today.
Committed to trunk.
gcc/
* config/sparc/sparc.md: Only use F, G, and C constraints in FP
insns. Only use D, Y, and Z constraints in vector insns.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@180410
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/C
Eric, could you please take a look again at your reload bug fix
first posted at:
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01671.html
It looks correct to me, and I can reproduce it with the VIS3 fp moves
enabled by simply adjusting the costs and register class preferences
such that IR
PR libstdc++/49894
* include/std/mutex (__mutex_base,__recursive_mutex_base): Define new
base classes to manage construction/destruction of native mutexes,
using NSDMI when INIT macros are defined.
(mutex,recursive_mutex,timed_mutex,recursive_timed_mutex): Der
Eric, David Brenner noticed that sparc little-endian support is
a candidate for deprecation or deletion. I support the latter,
we have no real OS targets supporting it and sparclet support
was removed in 2003 (!!!).
In fact, only sp64-elf.h even tries to override the endianness
macros correctly,
---
gcc/tree.def |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/tree.def b/gcc/tree.def
index 1472cb1..77dc7d7 100644
--- a/gcc/tree.def
+++ b/gcc/tree.def
@@ -1186,12 +1186,12 @@ DEFTREECODE (VEC_PACK_SAT_EXPR, "vec_pack_sat_expr",
tcc_binary, 2)
DEFTREECODE
The Idea with this patch set is to re-arrange vector permutation
so that it can be used to implement other patterns automatically.
In particular, Altivec, SPU currently have (and Sparc VIS would need)
a large amount of boilerplate code that transforms several higher
level tree codes into vector pe
From: Richard Henderson
---
gcc/expr.c| 20 +---
gcc/optabs.c | 116 +
gcc/optabs.h |3 +
gcc/tree-vect-data-refs.c | 80 ---
gcc/tree-vect-generic.c |9
5 fi
1 - 100 of 111 matches
Mail list logo
