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
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
On Sun, Oct 23, 2011 at 10:56 AM, Eric Botcazou ebotca...@adacore.com 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
On Fri, Oct 21, 2011 at 2:19 PM, Kai Tietz ktiet...@googlemail.com wrote:
2011/10/21 Richard Guenther richard.guent...@gmail.com:
On Thu, Oct 20, 2011 at 3:08 PM, Kai Tietz kti...@redhat.com wrote:
Hello,
this patch re-enables the branch-cost optimization on simple boolean-typed
operands,
On Fri, Oct 21, 2011 at 2:22 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com 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
wschm...@linux.vnet.ibm.com wrote:
snip
+
+ /* We don't use get_def_for_expr for S1
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
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.
*
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
On Fri, Oct 21, 2011 at 6:48 PM, Xinliang David Li davi...@google.com 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
On Fri, Oct 21, 2011 at 8:30 PM, Andi Kleen a...@firstfloor.org 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_t
On Sun, Oct 23, 2011 at 12:23 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Oct 21, 2011 at 8:30 PM, Andi Kleen a...@firstfloor.org 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
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 paolo.carl...@oracle.com
PR c++/50810
* c-opts.c
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
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
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
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
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
On Sun, Oct 23, 2011 at 3:18 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Oct 21, 2011 at 6:48 PM, Xinliang David Li davi...@google.com 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
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.
This will
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
Hello!
2011-10-23 Uros Bizjak ubiz...@gmail.com
* config/i386/sse.md (sseintprefix): Rename from gthrfirstp.
(avx_avx2_maskloadssemodesuffixavxsizesuffix): Delete expander.
(avx_avx2_maskloadssemodesuffixavxsizesuffix) Merge insn
pattern from
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
Hello!
We have the same pattern with generic name just below this one.
2011-10-23 Uros Bizjak ubiz...@gmail.com
* config/i386/sse.md (avx2_lshlmode3): Remove insn pattern.
(VI248_256): Remove mode iterator.
* config/i386/i386.md (ix86_expand_vec_perm): Use
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,
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]
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
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 problem
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
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
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
From: Eric Botcazou ebotca...@adacore.com
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.
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,
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
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
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
On Sun, Oct 23, 2011 at 3:45 PM, Eric Botcazou ebotca...@adacore.com 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] = {
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
On 10/23/2011 11:05 PM, Gabriel Dos Reis wrote:
On Sun, Oct 23, 2011 at 3:45 PM, Eric Botcazouebotca...@adacore.com 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
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
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,
On Sun, Oct 23, 2011 at 4:28 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
On 10/23/2011 11:05 PM, Gabriel Dos Reis wrote:
On Sun, Oct 23, 2011 at 3:45 PM, Eric Botcazouebotca...@adacore.com
wrote:
Anyway, the below appears to work for me. Eric shall I commit it?
I have other errors
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.
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
Date: Mon, 24 Oct 2011 00:03:45 +0400
From: Anatoly Sokolov ae...@post.ru
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
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
... and the patch ;)
Paolo.
/c-family
2011-10-23 Paolo Carlini paolo.carl...@oracle.com
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
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 had
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
On Sun, Oct 23, 2011 at 8:48 PM, Paolo Carlini paolo.carl...@oracle.com 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
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
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
---
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
On Sun, Oct 23, 2011 at 9:16 PM, Paolo Carlini paolo.carl...@oracle.com 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
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
From: David Miller da...@davemloft.net
Date: Sun, 23 Oct 2011 16:32:36 -0400 (EDT)
From: Eric Botcazou ebotca...@adacore.com
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
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.
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
57 matches
Mail list logo
