> Ok, I committed your suggestion to trunk for now.
Thanks!
--
Eric Botcazou
The Go language was extended to permit calling the builtin function
append with the first argument having type []byte and the second
argument having type string, followed by an ellipsis. This appends the
string to the slice. This patch implements this new functionality.
Bootstrapped and ran Go te
This patch makes a couple of fixes to the syscall rewrite I committed
earlier today. There was a typo in the umask library call. The gettid
call is actually GNU/Linux-specific. In any case, gettid and tgkill are
apparently not in libc, and are only available by calling syscall
directly. Bootstr
From: David Miller
Date: Sun, 23 Oct 2011 16:32:36 -0400 (EDT)
> From: Eric Botcazou
> Date: Sun, 23 Oct 2011 11:58:57 +0200
>
>>> I'll try to brainstorm on this, thanks for letting me know about the
>>> Solaris target problem.
>>
>> Let's fix the regression quickly though.
>
> I'll fix it by
A long time ago, before the public release of Go, the Go type known as a
"slice" was known as an "open array". I used the name
is_open_array_type in a Go frontend function. This mechanical patch
renames that function to be is_slice_type. Bootstrapped on
x86_64-unknown-linux-gnu. Committed to ma
On Sun, Oct 23, 2011 at 9:16 PM, Paolo Carlini wrote:
> On 10/24/2011 04:10 AM, Gabriel Dos Reis wrote:
>>
>> Before the patch, -std=c++0x effectively put off -Wc++0x-compat because we
>> are compiling c++98/c++03 code, so we can only *warn* about possible
>> compatibility conflict with C++11. How
The non-trivial aspects (and what took the most time for me) of these
changes are:
1) Getting the register move costs and class preferencing right such
that the VIS3 moves do get effectively used for incoming
float/vector argument passing on 32-bit, yet IRA and reload don't
go nuts alloc
Original patch against the generated NEWS file by Karl Berry.
Installed (and, yes, I updated the underlying PR 11137, too).
Gerald
Index: gcc-3.3/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.3/changes.html,v
retrieving r
Original patch against the generated NEWS file by Karl Berry.
Installed.
Gerald
Index: gcc-3.4/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.4/changes.html,v
retrieving revision 1.157
diff -u -r1.157 changes.html
--- gcc-
On 10/24/2011 04:10 AM, Gabriel Dos Reis wrote:
Before the patch, -std=c++0x effectively put off -Wc++0x-compat
because we are compiling c++98/c++03 code, so we can only *warn* about
possible compatibility conflict with C++11. However, the narrowing
diagnostic required by C++11 is NOT a warning
On Sun, Oct 23, 2011 at 8:48 PM, Paolo Carlini wrote:
> Hi,
>
> On 10/24/2011 03:30 AM, Gabriel Dos Reis wrote:
>>
>> We do not use -W or -Wno- to suppressed *required* diagnostics. So, when
>> -std=c++0x, -Wno-narrowing should not have any effect.
>
> Personally, I have no problem with this, but
Hi,
On 10/24/2011 03:30 AM, Gabriel Dos Reis wrote:
We do not use -W or -Wno- to suppressed *required* diagnostics. So,
when -std=c++0x, -Wno-narrowing should not have any effect.
Personally, I have no problem with this, but note, I'm not inventing
anything new here, the behavior you are discus
On Sun, Oct 23, 2011 at 7:56 PM, Paolo Carlini wrote:
> ... and the patch ;)
I am bit puzzled by this:
+This flag is included in @option{-Wc++0x-compat}.
+With -std=c++0x, @option{-Wno-narrowing} suppresses the diagnostic
+required by the standard.
and this:
- /* If we're allowing C++0x constr
On Mon, 10 Oct 2011, Gerald Pfeifer wrote:
> I realized this one hasn't made it in, but is really nice. I made a
> number of minor edits (typos, markup, simplifying headings,... among
> others). What do you think -- should we include this?
Checking mailing list archives I realized that Jakub h
... and the patch ;)
Paolo.
/c-family
2011-10-23 Paolo Carlini
PR c++/50810
* c-opts.c (c_common_handle_option): Do not enable -Wc++0x-compat
as part of -Wall; handle -Wc++0x-compat.
(c_common_post_options): -std=c++0x enables -Wnarrowing.
Hi,
Personally, I would be in favor of taking -Wc++0x-compat out of -Wall.
Patch pre-approved.
Thanks.
It makes sense though that -Wextra implies -Wc++0x-compat.
Indeed, it would. However, unfortunately, we are using -W to bootstrap
(it just failed on me). Thus I'm bootstrapping and testing
> Date: Mon, 24 Oct 2011 00:03:45 +0400
> From: Anatoly Sokolov
For future reference, please add the diff "-p" option for
readability. With subversion, you need to add the equivalence
of "diff-cmd = /home/hp/.scripts/svn-diff"
under [helpers] in your ~/.subversion/config and have a svn-diff
equi
PR libstdc++/50834
* doc/xml/manual/using.xml: Update thread safety docs w.r.t. C++11.
committed to trunk
Index: doc/xml/manual/using.xml
===
--- doc/xml/manual/using.xml (revision 180334)
+++ doc/xml/manual/using.xml
These tests are already growing big and ugly, and they will get even
more conditions when the VIS3 FP moves arrive.
Furthermore, we will need to have to do the same check in a third location,
in a new spliiter for the 64-bit vector moves that will be added for VIS3.
Committed to trunk.
2011-10-23 Steven G. Kargl
* simplify.c (simplify_transformation_to_array): Fix memory leak.
Index: simplify.c
===
--- simplify.c (revision 180352)
+++ simplify.c (working copy)
@@ -516,6 +516,7 @@ simplify_transformation_t
On Sun, Oct 23, 2011 at 4:28 PM, Paolo Carlini wrote:
> On 10/23/2011 11:05 PM, Gabriel Dos Reis wrote:
>>
>> On Sun, Oct 23, 2011 at 3:45 PM, Eric Botcazou
>> wrote:
Anyway, the below appears to work for me. Eric shall I commit it?
>>>
>>> I have other errors for config/i386/i386.c on
A good example of a case where this matters is pdist.c in the testsuite.
Before this change we get code for the beginning of function 'foo' like:
add %sp, -112, %sp
std %o0, [%sp+96]
stx %g0, [%sp+104]
ldd [%sp+96], %f10
std %o2, [%sp+96
While working on the vis3 fp move support, I came to find that we
weren't making sure that non-trivial vector constants went to memory.
The vector move patterns only support -1 and 0, so we have to force
all other values to memory.
Committed to trunk.
gcc/
* config/sparc/predicates.md
Since there is a mixture of signed vs. unsigned regnos used in these
tests, I had to code this as ((unsigned) x <= 31) otherwise we get
warnings in the unsigned cases for x >= 0.
Perhaps the signedness should be shored up at some point, but I left
that for some other time.
I'm currently just try
On 10/23/2011 11:05 PM, Gabriel Dos Reis wrote:
On Sun, Oct 23, 2011 at 3:45 PM, Eric Botcazou wrote:
Anyway, the below appears to work for me. Eric shall I commit it?
I have other errors for config/i386/i386.c on my x86-64 machine. But are we
sure that we want to warn on
static unsigned HOS
On 10/21/2011 05:20 PM, Jason Merrill wrote:
I think we're down to minor cosmetic issues:
On 10/21/2011 03:55 PM, Tom Tromey wrote:
There are a few spots like this that are missing a space before an open
paren.
+ if (DECL_LANGUAGE(decl) == lang_c)
Another one.
- if (warn_cx
On Sun, Oct 23, 2011 at 3:45 PM, Eric Botcazou wrote:
>> Anyway, the below appears to work for me. Eric shall I commit it?
>
> I have other errors for config/i386/i386.c on my x86-64 machine. But are we
> sure that we want to warn on
>
> static unsigned HOST_WIDE_INT unknown[4] = { -1, -1, 0, 0 }
On 10/23/2011 10:47 PM, Paolo Carlini wrote:
On 10/23/2011 10:39 PM, Paolo Carlini wrote:
On 10/23/2011 10:25 PM, Eric Botcazou wrote:
Oh my, I thought I was till using C here... Ok, I'll fix that.
The base compiler is a C compiler, stage 2/3 are built with the C++
compiler.
Yes, yes. Sorry a
On 10/23/2011 10:39 PM, Paolo Carlini wrote:
On 10/23/2011 10:25 PM, Eric Botcazou wrote:
Oh my, I thought I was till using C here... Ok, I'll fix that.
The base compiler is a C compiler, stage 2/3 are built with the C++
compiler.
Yes, yes. Sorry about this.
Anyway, the below appears to work
> Anyway, the below appears to work for me. Eric shall I commit it?
I have other errors for config/i386/i386.c on my x86-64 machine. But are we
sure that we want to warn on
static unsigned HOST_WIDE_INT unknown[4] = { -1, -1, 0, 0 };
with -Wall? This seems overly picky to me.
--
Eric Botcaz
On 10/23/2011 10:25 PM, Eric Botcazou wrote:
Oh my, I thought I was till using C here... Ok, I'll fix that.
The base compiler is a C compiler, stage 2/3 are built with the C++ compiler.
Yes, yes. Sorry about this.
Anyway, the below appears to work for me. Eric shall I commit it?
Thanks,
Paolo
From: Eric Botcazou
Date: Sun, 23 Oct 2011 11:58:57 +0200
>> I'll try to brainstorm on this, thanks for letting me know about the
>> Solaris target problem.
>
> Let's fix the regression quickly though.
I'll fix it by the end of tonight.
> Oh my, I thought I was till using C here... Ok, I'll fix that.
The base compiler is a C compiler, stage 2/3 are built with the C++ compiler.
--
Eric Botcazou
On 10/23/2011 10:19 PM, Eric Botcazou wrote:
So, to be clear, this is for bootstrapping with a C++ compiler, right?
Honestly, didn't try that... It's definitely possible that there are
glitches in the tree wrt -Wnarrowing in C++.
Bootstrapping with the C++ compiler has been the default for month
> So, to be clear, this is for bootstrapping with a C++ compiler, right?
> Honestly, didn't try that... It's definitely possible that there are
> glitches in the tree wrt -Wnarrowing in C++.
Bootstrapping with the C++ compiler has been the default for months...
--
Eric Botcazou
> The code in question is
>
> static unsigned HOST_WIDE_INT unknown[4] = { -1, -1, 0, 0 };
>
> This is on amd64-unknown-freebsd8.0, though I am puzzled it does not
> seem to trigger for other 64-bit platforms?
It does trigger on Linux. I guess the patch wasn't bootstrapped.
There is another pr
On 10/23/2011 10:07 PM, Gerald Pfeifer wrote:
Is it possible that this is responsible for a bootstrap failure introduced
in the last 27 hours or so?
/scratch/tmp/gerald/gcc-HEAD/gcc/tree-object-size.c:44:59: error: narrowing
conversion of '-0x1' from 'int' to 'long unsigned int'
Is it possible that this is responsible for a bootstrap failure introduced
in the last 27 hours or so?
/scratch/tmp/gerald/gcc-HEAD/gcc/tree-object-size.c:44:59: error: narrowing
conversion of '-0x1' from 'int' to 'long unsigned int' inside {
} [-Werror=narrowing]
/scratch/tmp/g
Hello.
This patch removes obsolete GO_IF_LEGITIMATE_ADDRESS macro from CRIS back
end in the GCC and introduces equivalent ARGET_LEGITIMATE_ADDRESS_P target
hook.
Regression tested on cris-axis-elf.
OK to install?
* config/cris/cris.c (reg_ok_for_base_p, reg_ok_for_index_p,
Hello!
We have the same pattern with generic name just below this one.
2011-10-23 Uros Bizjak
* config/i386/sse.md (avx2_lshl3): Remove insn pattern.
(VI248_256): Remove mode iterator.
* config/i386/i386.md (ix86_expand_vec_perm): Use gen_ashlv4di3
instead of g
This patch is a rewrite of the syscall package in the Go library. This
rewrite moves it from libgo/syscalls to libgo/go/syscall, to more
closely match the master Go library. More importantly, it changes most
library calls to call new entersyscall and exitsyscall functions. These
functions curren
Hello!
2011-10-23 Uros Bizjak
* config/i386/sse.md (sseintprefix): Rename from gthrfirstp.
(_maskload): Delete expander.
(_maskload) Merge insn
pattern from *avx2_maskload and
*avx_maskload using V48_AVX mode
iterator. Use sseintprefix mode attr
On 10/23/2011 11:00 AM, Paolo Carlini wrote:
+With -std=c++0x, @option{-Wno-narrowing} suppresses the diagnostic
+required by the standard. This flag is included in @option{-Wall} and
+@option{-Wc++0x-compat}.
I'd swap those two sentences. OK with that change.
Jason
On Sun, Oct 23, 2011 at 12:24:46PM +0200, Richard Guenther wrote:
> >> space in the free list afterward we free it back on the next GC cycle.
> >> Then if there's a malloc or other allocator later it can grab
> >> the address space we freed.
> >>
> >> That was done to address your earlier concern.
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 other is -fopt-report which is
>> more elaborate form of dump files. A
Hi,
On 10/23/2011 07:23 AM, Paolo Carlini wrote:
-@item -Wno-narrowing @r{(C++ and Objective-C++ only)}
+@item -Wnarrowing @r{(C++ and Objective-C++ only)}
@opindex Wnarrowing
@opindex Wno-narrowing
-With -std=c++0x, suppress the diagnostic required by the standard for
-narrowing conversions w
Hi,
while looking into the inlining dumps I noticed that by adding extra logic to
identify
inlining benefits, the badness metric is now really scaled down. For tramp3d in
ranges
from 0 to 400 that is quite coarse for thousdands of functions. This patch
scales
it up and makes the overflow situat
Hello!
As discussed in the PR, avx{,2}_maskload pattern outputs zero element
to destination register, when corresponding mask selector is not set.
So, there is no dependency on target register value.
While the attached patch fixes mainline, following one-liner is enough
to fix other relase branch
On 10/23/2011 07:23 AM, Paolo Carlini wrote:
-@item -Wno-narrowing @r{(C++ and Objective-C++ only)}
+@item -Wnarrowing @r{(C++ and Objective-C++ only)}
@opindex Wnarrowing
@opindex Wno-narrowing
-With -std=c++0x, suppress the diagnostic required by the standard for
-narrowing conversions within
Hi,
When there is pair of data-refs with unknown dependence in basic block
SLP we currently require all the loads in the basic block to be before
all the stores in order to avoid load after store dependencies. But
this is too conservative. It's enough to check that in the pairs of
loads and stores
Hi,
this is essentially about enabling -Wnarrowing as part of -Wc++0x-compat
(see audit trail for details). Tested x86_64-linux.
Ok for mainline?
Thanks,
Paolo.
/
/c-family
2011-10-23 Paolo Carlini
PR c++/50810
* c-opts.c (c_common_handle_option): Enab
On Sun, Oct 23, 2011 at 12:23 PM, Richard Guenther
wrote:
> On Fri, Oct 21, 2011 at 8:30 PM, Andi Kleen wrote:
>>> > diff --git a/gcc/ggc-page.c b/gcc/ggc-page.c
>>> > index ba88e3f..eb0eeef 100644
>>> > --- a/gcc/ggc-page.c
>>> > +++ b/gcc/ggc-page.c
>>> > @@ -972,6 +972,54 @@ release_pages (voi
On Fri, Oct 21, 2011 at 8:30 PM, Andi Kleen wrote:
>> > diff --git a/gcc/ggc-page.c b/gcc/ggc-page.c
>> > index ba88e3f..eb0eeef 100644
>> > --- a/gcc/ggc-page.c
>> > +++ b/gcc/ggc-page.c
>> > @@ -972,6 +972,54 @@ release_pages (void)
>> > page_entry *p, *start_p;
>> > char *start;
>> > size
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 other is -fopt-report which is
> more elaborate form of dump files. Are you object to both or just the
> opt-report one?
What? I'm
> Do you have an idea why we test flag_trapping_math here?
Not really, the test was added with the contradictory comment:
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01674.html
--
Eric Botcazou
Here is a resubmission of the libgcc patch, removing the dependence on a header
(arch/atomic.h) that's not installed by linux.
Walter
* config.host: Handle tilegx and tilepro.
* config/tilegx/sfp-machine.h: New file.
* config/tilegx/sfp-machine32.h: New file.
* con
> This is precisely what I tried initially, and my posting was
> explicitly trying to explain that this kind of approach cannot
> work. :-)
It will work for Richard's case though and that's clearly the most glaring
problem. Moreover, it will bring Linux on par with Solaris, which is also a
good
On Fri, Oct 21, 2011 at 2:22 PM, William J. Schmidt
wrote:
>
>
> On Fri, 2011-10-21 at 11:26 +0200, Richard Guenther wrote:
>> On Tue, Oct 18, 2011 at 4:14 PM, William J. Schmidt
>> wrote:
>
>
>
>> > +
>> > + /* We don't use get_def_for_expr for S1 because TER doesn't forward
>> > + S1 in s
On Fri, Oct 21, 2011 at 2:19 PM, Kai Tietz wrote:
> 2011/10/21 Richard Guenther :
>> On Thu, Oct 20, 2011 at 3:08 PM, Kai Tietz wrote:
>>> Hello,
>>>
>>> this patch re-enables the branch-cost optimization on simple boolean-typed
>>> operands, which are casted to a wider integral type. This happ
On Sun, Oct 23, 2011 at 10:56 AM, Eric Botcazou wrote:
> Hi,
>
> the comment of the function reads:
>
> /* Given a tree comparison code, return the code that is the logical inverse
> of the given code. It is not safe to do this for floating-point
> comparisons, except for NE_EXPR and EQ_EXPR,
Hi,
the comment of the function reads:
/* Given a tree comparison code, return the code that is the logical inverse
of the given code. It is not safe to do this for floating-point
comparisons, except for NE_EXPR and EQ_EXPR, so we receive a machine mode
as well: if reversing the compari
Hi,
I committed the attached update.
Ira
? yy
cvs diff: Diffing .
Index: vectorization.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/tree-ssa/vectorization.html,v
retrieving revision 1.27
diff -r1.27 vectorization.html
9,12c9,1
62 matches
Mail list logo
