The comment is still valid now.
r
gcc/Changelog:
2011-10-25 Roberto Agostino Vitillo
PR c++/30066
* doc/invoke.texi (fvisibility-inlines-hidden): Documentation change.
gcc/c-family/Changelog:
2011-10-25 Roberto Agostino Vitillo
PR c++/30066
* c.opt (fvisi
Ping ** 0.571428
Jakub Jelinek wrote:
Though, what could be done is just special case OpenMP workshare regions,
insert everything into BLOCK local vars unless in OpenMP workshare, in
that
case put the BLOCK with the temporary around the workshare rather than
inside of it. In the case of omp par
The Go rules for the order of evaluation in tuple assignments were
clarified. In a statement like
i, x[i] = 1, 2
the value of "i" used in "x[i]" must be the value that "i" had before
the assignment statement, not the value it gets while evaluating the
assignment. This patch implements tha
On 09.08.11 13:59, Rainer Orth wrote:
Hi Andreas,
the patch below survives bootstrap stage-1 on PowerPC FreeBSD successfully.
W/o patch we try to fliter-out ibm-ldouble.c. So from my understanding the
pattern ibm-ldouble.c does never match since there is a path prepended to
the file name.
With
Comitted to trunk.
gcc/testsuite/
* gcc.target/sparc/vis3move-1.c: New test.
* gcc.target/sparc/vis3move-2.c: New test.
* gcc.target/sparc/vis3move-3.c: New test.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@180418
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/testsu
2011/10/24 Richard Henderson :
> 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 \
>> + (
> 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 (!!!).
>
These are actually two separate issues. Sparclet was an embedded
design
---
gcc/config/spu/spu.md | 433 -
1 files changed, 0 insertions(+), 433 deletions(-)
diff --git a/gcc/config/spu/spu.md b/gcc/config/spu/spu.md
index ca2cad9..3178a6d 100644
--- a/gcc/config/spu/spu.md
+++ b/gcc/config/spu/spu.md
@@ -4947,439 +494
The ones that expand to VPERM can be handled by generic code.
The even v4si and v4sf expanders remain until vector.md can be
updated to not invoke them directly.
---
gcc/config/rs6000/altivec.md | 134 +-
1 files changed, 2 insertions(+), 132 deletions(-)
From: Richard Henderson
These can be generated by vec_perm_const now. We could keep the
patterns around, as technically it may be less work, but this
exercises a code path needed by less primary platforms.
---
gcc/config/i386/sse.md | 29 -
1 files changed, 0 inser
From: Richard Henderson
The can_vec_perm_p interface changed to use a C integer array. This
allows easy re-use from the rtl level and the gimple level within
the vectorizer. It allows both to determine if a given permutation
is (un-)supported without having to create tree/rtl garbage.
The expa
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
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
---
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
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,
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, 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
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
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
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
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
Just committed the following:
* MAINTAINERS (Write After Approval): Add myself.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 180393)
+++ MAINTAINERS (working copy)
@@ -392,6 +392,7 @@
Martin Jambor
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
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: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
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
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 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/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)
> +
>
> 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
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
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
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
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
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
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: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 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
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 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
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/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
OK.
Jason
OK.
Jason
OK.
Jason
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))
> +
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
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
> 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 @@
>
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
> 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:
> 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
> 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
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
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
> 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
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
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 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 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.
This works for me. Do you agree?
It looks good to me.
OK, will commit.
Thanks guys.
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
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.
>
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 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/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
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 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 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.
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
>
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
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
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 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
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, 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 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
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
.. 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.
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
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
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
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 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
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 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 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 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
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
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
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 (
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
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
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
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
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
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/
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
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
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
1 - 100 of 111 matches
Mail list logo
