Dear all,
attached is an updated version of Patch 2. The change is that I removed
the global variable for fill_st_vector and updated the comment for
do_traverse_symtree to make assumptions clearer.
This version of the patch was build and regtested (gfortran + libgomp).
OK?
Dear Tobias S.,
On Wed, 2 Nov 2011, DJ Delorie wrote:
> The Renesas RL78 is a new low-power 8/16 bit microcontroller, with an
> architecture much like the original Z80.
Just some random spottings.
> Index: configure.ac
> +# Dereferencing -1 is a compile-time error
This (those lines) look a little cryptic (a
On Wed, Nov 2, 2011 at 6:06 AM, Ian Lance Taylor wrote:
>>> The problem with your proposal is that the output would be invalid Go,
>>> because it would attempt to define the name _aa twice. However, it does
>>> seem plausible that in most scenarios of this type it would be more
>>> useful for -f
On 11/01/2011 06:54 PM, Jason Merrill wrote:
Paolo Carlini's patch to add -Wnarrowing to -Wc++0x-compat (and thus
-Wall) broke bootstrap because of narrowing warnings, so I'd like to add
-Wno-narrowing to the stage 2+ warning flags. Is this the best way to
do that?
Is this a C++-only warning?
On 11/01/2011 04:51 PM, Mike Stump wrote:
> On Nov 1, 2011, at 4:27 AM, Andrew Haley wrote:
>> On 10/30/2011 01:51 PM, Gerald Pfeifer wrote:
>>> Why not just declare
>>> that building from the same directory is not support and have one
>>> simple set of instructions that always works, as opposed to
On Tue, Nov 1, 2011 at 10:02 PM, Martin Jambor wrote:
> Hi,
>
> On Tue, Nov 01, 2011 at 10:37:10AM +0100, Richard Guenther wrote:
>> On Mon, Oct 31, 2011 at 5:58 PM, Martin Jambor wrote:
>> > On Fri, Oct 28, 2011 at 11:21:23AM +0200, Richard Guenther wrote:
>> >> On Thu, Oct 27, 2011 at 9:54 PM,
On Tue, Nov 1, 2011 at 11:06 PM, Martin Jambor wrote:
> Hi,
>
> the patch below is the second (and last) revived type-based
> devirtualization patch that did not make it to 4.6. It deals with
> virtual calls from the function in which the there is also the object
> declaration:
>
> void foo()
> {
On Wed, Nov 2, 2011 at 3:27 AM, Jiangning Liu wrote:
> Hi,
>
> This patch is to fix PR38644 in ARM back-end. OK for trunk?
>
> For every detail, please refer to
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644.
Ok in absence of any target maintainer objection within 24h.
Thanks,
Richard.
> C
Hi,
just consistently save the whole state and compare the whole state (in
operator==). Tested x86_64-linux, committed to mainline. Maybe will go
to 4_6-branch too.
Thanks,
Paolo.
///
2011-11-02 Paolo Carlini
PR libstdc++/50951
* include/bits/random.tc
This fixes PR50902.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-11-02 Richard Guenther
PR tree-optimization/50902
* tree-vect-stmts.c (vectorizable_load): Properly convert
an invariant initializer element.
* gcc.dg/to
Hi,
On Wed, Nov 02, 2011 at 11:02:48AM +0100, Richard Guenther wrote:
> On Tue, Nov 1, 2011 at 11:06 PM, Martin Jambor wrote:
> > Hi,
> >
> > the patch below is the second (and last) revived type-based
> > devirtualization patch that did not make it to 4.6. It deals with
> > virtual calls from t
On Fri, 28 Oct 2011, Joseph S. Myers wrote:
> On Fri, 28 Oct 2011, Richard Guenther wrote:
>
> > + /* Fallthru. */
> > + case OPT_fPIC:
> > + case OPT_fpic:
> > + case OPT_fpie:
> > + case OPT_fcommon:
> > + case OPT_fexceptions:
> > + append_option (decoded_options, decoded_op
On Wed, Nov 2, 2011 at 12:12 PM, Martin Jambor wrote:
> Hi,
>
> On Wed, Nov 02, 2011 at 11:02:48AM +0100, Richard Guenther wrote:
>> On Tue, Nov 1, 2011 at 11:06 PM, Martin Jambor wrote:
>> > Hi,
>> >
>> > the patch below is the second (and last) revived type-based
>> > devirtualization patch tha
On Sat, 29 Oct 2011, Sergey Ostanevich wrote:
> On Fri, Oct 28, 2011 at 7:25 PM, Sergey Ostanevich
> wrote:
> > On Fri, Oct 28, 2011 at 4:52 PM, Richard Guenther wrote:
> >> On Fri, 28 Oct 2011, Sergey Ostanevich wrote:
> >>
> >>> On Fri, Oct 28, 2011 at 12:16 PM, Richard Guenther
> >>> wrote
Hello!
2011-11-02 Uros Bizjak
* config/i386/i386.c (bdesc_args) [IX86_BUILTIN_CVTTPD2DQ256]: Use
CODE_FOR_fix_truncv4dfv4si2, not CODE_FOR_fix_truncv4sfv4si2.
Tested on x86_64-pc-linux-gnu, committed to mainline SVN.
Uros.
Index: i386.c
===
On Sun, 30 Oct 2011, William J. Schmidt wrote:
> Ping.
>
> On Mon, 2011-10-24 at 08:38 -0500, William J. Schmidt wrote:
> > 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 p
Hello!
2011-11-02 Uros Bizjak
* gcc.target/i386/avx-cvt-2.c (dg-options): Add -mtune=generic.
* gcc.target/i386/avx2-cvt-2.c (dg-options): Ditto.
* gcc.target/i386/sse2-cvt-2.c (dg-options): Ditto.
* gcc.target/i386/vectorize4-avx.c (dg-final): Remove xfail *-*
Georg-Johann Lay wrote:
> To support the upcoming named address space support in avr, a 24-bit pointer
> type is needed. This patch adds respective support of a 24-bit integer mode
> called PSI.
>
> The patch supports more than is actually needed for a pointer-only
> implementation: is supplies al
On Wed, 2011-11-02 at 12:55 +0100, Richard Guenther wrote:
> On Sun, 30 Oct 2011, William J. Schmidt wrote:
>
> > Ping.
> >
> > On Mon, 2011-10-24 at 08:38 -0500, William J. Schmidt wrote:
> > > OK, I've removed the pointer-arithmetic case from expand, to be handled
> > > later by straight-line s
> Anyways, instead what I do here is normalize all expansions of
> conditional moves to be of the form:
>
> (set op0 (if_then_else (cmp X Y)
> op3
>op0))
>
> and in the instruction patterns I use "register_operand" and
> constraint
On Wed, Nov 2, 2011 at 12:40 AM, Jason Merrill wrote:
> On 11/02/2011 12:05 AM, Gabriel Dos Reis wrote:
>>>
>>> And I think that "your code won't work in C++11" is
>>> a warning that most C++ programmers will be interested in if they are
>>> asking
>>> for warnings.
>>
>> Even when -std=c++03 -Wa
> 2011-10-24 Andreas Krebbel
>
> * gcc.dg/strlenopt-22.c: New testcase.
This doesn't link if you don't have stpcpy in the libc, e.g. on Solaris.
Here's an excerpt from the Linux man pages:
CONFORMING TO
This function is not part of the C or POSIX.1 standards, and is not
On Wed, Nov 02, 2011 at 01:41:30PM +0100, Eric Botcazou wrote:
> > 2011-10-24 Andreas Krebbel
> >
> > * gcc.dg/strlenopt-22.c: New testcase.
>
> This doesn't link if you don't have stpcpy in the libc, e.g. on Solaris.
>
> Here's an excerpt from the Linux man pages:
>
> CONFORMING TO
>
Currently gcc will promote from QI/HI mode to SI mode various
operators but not minus. It will however promote a neg followed by an
add (add is in the current list of promotable operators and neg is
promoted around config/i386/i386.md:16904). This omission can cause
RAT stalls in tight loops.
Succ
On 11/02/2011 05:40 AM, Paolo Bonzini wrote:
Is this a C++-only warning? Also, how did you test the patch?
It is, but the flag is accepted and ignored by the C front end.
I tested it with a bootstrap.
Jason
Paolo Bonzini writes:
> On 08/16/2011 04:59 AM, Rainer Orth wrote:
>> None of them uses any of those macros, so I think we're safe.
>
> Yes, I checked the same now. Looks like we're good.
Here's the rebased version of the patch I'm about to check in, after
regtesting on i386-pc-solaris2.11, spa
On 11/02/2011 02:47 PM, Jason Merrill wrote:
Is this a C++-only warning? Also, how did you test the patch?
It is, but the flag is accepted and ignored by the C front end.
Then please adjust libcpp/configure.ac too; otherwise the patch is okay
to fix bootstrap. It can be reverted later if
Jakub Jelinek writes:
> Anyway, in the other gcc.dg/strlenopt-* testcases for USE_GNU I was using
> the convention that the name ended with g (i.e. strlenopt-22g.c) and
> the test would start with:
> /* This test needs runtime that provides stpcpy function. */
> /* { dg-do run { target *-*-linux
On Wed, Nov 02, 2011 at 02:55:54PM +0100, Rainer Orth wrote:
> Jakub Jelinek writes:
>
> > Anyway, in the other gcc.dg/strlenopt-* testcases for USE_GNU I was using
> > the convention that the name ended with g (i.e. strlenopt-22g.c) and
> > the test would start with:
> > /* This test needs runti
Paolo Bonzini writes:
> Ok with a couple of changes:
>
>> gcc:
>> * gthr-posix.h, gthr-single.h, gthr.h: Move to ../libgcc.
>
> Move gthr-posix.h to config/
>
>>* config/m32r/linux.h (SUBTARGET_CPP_SPEC): Don't define _PTHREADS
>>if -pthread.
>>* config/mn10300/l
Hello!
> Currently gcc will promote from QI/HI mode to SI mode various
> operators but not minus. It will however promote a neg followed by an
> add (add is in the current list of promotable operators and neg is
> promoted around config/i386/i386.md:16904). This omission can cause
> RAT stalls in
On Wed, 2 Nov 2011, William J. Schmidt wrote:
> On Wed, 2011-11-02 at 12:55 +0100, Richard Guenther wrote:
> > On Sun, 30 Oct 2011, William J. Schmidt wrote:
> >
> > > Ping.
> > >
> > > On Mon, 2011-10-24 at 08:38 -0500, William J. Schmidt wrote:
> > > > OK, I've removed the pointer-arithmetic c
On 11/01/2011 04:48 PM, Richard Henderson wrote:
On 11/01/2011 01:20 PM, David Miller wrote:
Unfortunately, this is not true.
Otherwise we could change the 32-bit default code generation to
v9 from v7 under Linux.
For v7, pa-risc, and sh, we originally allowed the test_and_set and
lock_release
On 11/01/2011 11:57 AM, Richard Henderson wrote:
Any comments on the expectation, or implementation of signal-fence below?
Should I make the distinction between the memory models here at all?
I think the expectation is that signal_fence is identical to
thread_fence, except the compiler doesn't
> > Index: configure.ac
> > +# Dereferencing -1 is a compile-time error
>
> This (those lines) look a little cryptic (and lack punctuation ;)
> Wild improvement guess: "Too small 'int'?".
No, the compiler specifically tests for unaligned accesses and gives a
compile-time error, at Renesas's
Lock free routines are not guaranteed to work if they are not aligned
properly. Until now, the __atmoic_is_lock_free property has simply
relied on the size of an object to determine lockfreeness. This works
when you assume a certain alignment.
The library takes generic pointers and with st
On 11/02/2011 07:59 AM, Andrew MacLeod wrote:
> Simply adds an optional parameter to __atomic_{is_always}_lock_free
> which is used to check alignment against the size parameter. NULL as
> the object pointer produces the same behaviour as today, lockfreeness
> based on proper alignment for an integ
On 11/02/2011 07:18 AM, Andrew MacLeod wrote:
> OK, I think i need to revert my position and introduce
> __atomic_test_and_set() and __atomic_clear(). bah. I'll work on
> that today.
I don't think you do. We already have the __sync functions,
and we should just use those.
What we need is a pre
On 11/02/2011 11:25 AM, Richard Henderson wrote:
On 11/02/2011 07:18 AM, Andrew MacLeod wrote:
OK, I think i need to revert my position and introduce
__atomic_test_and_set() and __atomic_clear(). bah. I'll work on
that today.
I don't think you do. We already have the __sync functions,
and we
On 11/01/2011 10:43 AM, Richard Guenther wrote:
> On Mon, Oct 31, 2011 at 9:19 PM, Tom de Vries wrote:
>> On 10/30/2011 10:54 AM, Richard Guenther wrote:
>>> On Sun, Oct 30, 2011 at 9:27 AM, Tom de Vries
>>> wrote:
On 10/30/2011 09:20 AM, Tom de Vries wrote:
> Richard,
>
> I hav
On 10/31/11 10:11, Eric Botcazou wrote:
>> I'm suggesting a new patch, as attached. Before reload_completed, we
>> directly return 0 upon nlabel == NULL, which should be identical with
>> old behavior, while asserting fail if after reload (where we assume the
>> simple_return/return distinction is
This fixes PR48217, the failure to decode '\\'' from COLLECT_GCC_OPTIONS
in lto-wrapper.
LTO bootstrap & regtest running on x86_64-unknown-linux-gnu.
Richard.
2011-11-02 Richard Guenther
PR lto/48217
* lto-wrapper.c (get_options_from_collect_gcc_options): Properly
de
On 11/02/2011 11:22 AM, Richard Henderson wrote:
On 11/02/2011 07:59 AM, Andrew MacLeod wrote:
Simply adds an optional parameter to __atomic_{is_always}_lock_free
which is used to check alignment against the size parameter. NULL as
the object pointer produces the same behaviour as today, lockfre
Matthias Klose writes:
> I see a build failure with the last update, not yet sure what is going wrong.
>
> /bin/mkdir -p exp; files=`echo ../../../src/libgo/go/exp/ebnf/ebnf.go
> ../../../src/libgo/go/exp/ebnf/parser.go go/scanner.gox go/token.gox os.gox
> strconv.gox unicode.gox utf8.gox | sed -
On 11/02/2011 08:44 AM, Andrew MacLeod wrote:
> that should work shouldnt it?
Yes, so long as the atomic_flag object only wants one memory model.
Which I suppose it does for implementing a mutex.
r~
On Wed, 2 Nov 2011, DJ Delorie wrote:
> - unsigned int __max_iter = 100;
> + unsigned int __max_iter = 65536U;
Doesn't that need to be 65535U for your purpose?
> Index: libgcc/config/rl78/lib2shift.c
> ===
> --- libgcc
On Wed, 2 Nov 2011, DJ Delorie wrote:
> > > Index: configure.ac
> > > +# Dereferencing -1 is a compile-time error
> >
> > This (those lines) look a little cryptic (and lack punctuation ;)
> > Wild improvement guess: "Too small 'int'?".
>
> No, the compiler specifically tests for unaligned ac
On 11/02/2011 07:59 AM, Andrew MacLeod wrote:
> gcc
> * builtins.c (fold_builtin_atomic_always_lock_free): Add object param
> and check alignment if present.
> (expand_builtin_atomic_always_lock_free): Expect 2nd argument.
> (fold_builtin_atomic_is_lock_free): Expect 2
On 11/02/2011 07:59 AM, Andrew MacLeod wrote:
> + /* Parameters at this point are usually cast to void *, so check for
> that
> + and look past the cast. */
> + if (TREE_CODE (arg1) == NOP_EXPR && POINTER_TYPE_P (ttype)
> + && VOID_TYPE_P (TREE_TYPE (ttype)))
> + ar
On 11/02/2011 12:28 PM, Richard Henderson wrote:
On 11/02/2011 07:59 AM, Andrew MacLeod wrote:
+ /* Parameters at this point are usually cast to void *, so check for
that
+and look past the cast. */
+ if (TREE_CODE (arg1) == NOP_EXPR&& POINTER_TYPE_P (ttype)
+ && VO
On 10/18/2011 11:06 AM, Tom de Vries wrote:
> On 10/17/2011 01:51 PM, Richard Guenther wrote:
>> On Sun, Oct 16, 2011 at 12:05 PM, Tom de Vries
>> wrote:
>>> On 10/14/2011 12:00 PM, Richard Guenther wrote:
On Fri, Oct 14, 2011 at 1:12 AM, Tom de Vries
wrote:
> On 10/12/2011 02:19
Nothing major to report.
There seems to be some top-level makefile problem passing
_GLIBCXX_USE_INT128 down to libstdc++-v3 for the -m32 multilib. Richard
is looking at this.
Otherwise, everything working as before.
I will now generate a patchset by subsystem for everyone's perusal.
On Tue, Nov 1, 2011 at 2:53 AM, Richard Guenther
wrote:
> On Tue, Nov 1, 2011 at 1:46 AM, Teresa Johnson wrote:
>> This patch is for google-main only.
>>
>> Tested with bootstrap and regression tests.
>>
>> Print unroll and peel factors along with loop source position under
>> -fopt-info.
>>
>>
On 11/02/2011 09:30 AM, Andrew MacLeod wrote:
> it did in my simply trials as I figured this out in the debugger :-)
> i only did basic tests. OK, Is there a simple way to get to the def?
You should know. You wrote most of that stuff.
> what happens to the alignment of something if its say 'char
DJ Delorie writes:
> Index: libgcc/config.host
> ===
> --- libgcc/config.host(revision 180758)
> +++ libgcc/config.host(working copy)
> @@ -683,12 +683,16 @@ rs6000-ibm-aix5.1.* | powerpc-ibm-aix5.1
> tmake_file
Ok for google/main.
1) may be better to omit the const iteration count for complete unroll message
2) Instead of dumping loop header count, is it better to dump
pre-header count -- it gives an idea of how often the loop is entered.
The loop header count can be derived from loop average iteration a
On 11/02/2011 12:37 PM, Richard Henderson wrote:
On 11/02/2011 09:30 AM, Andrew MacLeod wrote:
it did in my simply trials as I figured this out in the debugger :-)
i only did basic tests. OK, Is there a simple way to get to the def?
You should know. You wrote most of that stuff.
HA. years ago
Uros Bizjak writes:
> #defines with arguments are not working at all. Please consider
> following testcase:
You're right: this approach doesn't work for preprocessor macros with
arguments. Making those work via this approach would be much much
harder.
> Please note missing "struct terminfos" d
Ian Lance Taylor writes:
> This patch updates the Go library to the most recent weekly release. I
> think the only potential portability issues here are the use of the
> ipv6_mreq struct. I'm not entirely sure the new exp/terminal package is
> portable, but it might be.
All go and libgo execut
> >> > > We would like to propose changing AVX generic mode tuning to
> >> generate
> >> > 128-bit
> >> > > AVX instead of 256-bit AVX.
> >> >
> >> > You indicate a 3% reduction on bulldozer with avx256.
> >> > How does avx128 compare to -mno-avx -msse4.2?
> >>
> >> We see these % differences going
On Nov 2, 2011, at 2:42 AM, Andrew Haley wrote:
> On 11/01/2011 04:51 PM, Mike Stump wrote:
>> On Nov 1, 2011, at 4:27 AM, Andrew Haley wrote:
>>> On 10/30/2011 01:51 PM, Gerald Pfeifer wrote:
Why not just declare
that building from the same directory is not support and have one
simp
On 11/02/2011 05:11 PM, Mike Stump wrote:
> On Nov 2, 2011, at 2:42 AM, Andrew Haley wrote:
>> On 11/01/2011 04:51 PM, Mike Stump wrote:
>>> On Nov 1, 2011, at 4:27 AM, Andrew Haley wrote:
On 10/30/2011 01:51 PM, Gerald Pfeifer wrote:
> Why not just declare
> that building from the sam
Hi,
this should restore -Wcast-qual to the 3.4.x (!) behavior, more or less.
The diff seems large but the new code is essentially in the last 5
lines. When fixing this issue the most subtle existing testcase to get
right, IMHO, is c-c++-common/Wcast-qual-1.c. Duplicate warnings should
not be
On Tue, Nov 1, 2011 at 3:00 PM, Peter Bergner wrote:
> +/* Fills in the label name that should be used for a 476 link stack thunk.
> */
> +
> +void
> +get_ppc476_thunk_name (char name[32])
> +{
> + gcc_assert (TARGET_LINK_STACK);
> +
> + if (HAVE_GAS_HIDDEN)
> + sprintf (name, "__ppc476.ge
On Tue, Oct 4, 2011 at 4:57 PM, Mike Stump wrote:
> On Oct 4, 2011, at 2:37 PM, Quentin Neill wrote:
>> Ping?
>
> The problem with this patch is it reorders the listing so that lower priority
> things are after higher priority things. The entire point of the routine is
> to list the high priori
On Nov 2, 2011, at 10:17 AM, Andrew Haley wrote:
> Sure, but that doesn't answer the question, which was "is there ever
> any advantage to building in-srcdir?" The answer "Yes: one can build
> in srcdir" doesn't quite do it!
Well, unstated in that is that one doesn't have to manually create an ob
OK.
Jason
... ehm, we use -Wcast-qual during the bootstrap, thus if I don't want
to break it again, better doing the below too. Seems obvious, by itself.
Paolo.
//
2011-11-02 Paolo Carlini
PR c++/50956
* builtins.c (fold_builtin_memchr): Fix cast.
Index: builtins.c
=
Hi,
I tried GCC trunk to test the non static member initializer, and noticed a
bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50965
I noticed that the reason is that Some code path test if the test is an
aggregate type before running the constructors.
But in C++11 the definition of aggregate
Rainer Orth writes:
> All go and libgo execution tests are failing for me with this patch on
> x86_64-unknown-linux-gnu (CentOS 5.5, I think):
>
> output is:
> /var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li
> bgo/.libs/libgo.so: undefined reference to `inotify_in
> deduce that this path is unreachable is to generate an abort and output an
> informative notice with inform ().
Hmmm... I'll see if I can catch it early enough to do something more
meaningful, then.
> (I don't see what actually generates the error, since there are only two
Actually, it's in
On 11/02/2011 10:54 AM, Ian Lance Taylor wrote:
Rainer Orth writes:
All go and libgo execution tests are failing for me with this patch on
x86_64-unknown-linux-gnu (CentOS 5.5, I think):
output is:
/var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li
bgo/.libs/libg
On 10/26/2011 10:38 AM, Richard Guenther wrote:
> On Tue, Oct 25, 2011 at 2:15 PM, Tom de Vries wrote:
>> Richard,
>>
>> I have a patch for the i686 bootstrap problem reported in PR50763 comment 10.
>>
>> pr50763-2.c looks like this before tail_merge_optimize:
>> ...
>> std_canonical_va_list_type
Ian Lance Taylor writes:
> I assume that CentOS 5.5 uses some version of glibc before version 2.6.
Right:
$ /lib/libc.so.6
GNU C Library stable release version 2.5, by Roland McGrath et al.
> The three functions you mention are not supported in older versions of
> glibc. Fortunately, they ar
David Daney writes:
> On MIPS we fail because of those. I was going to create a patch to
> move those two to libcall_linux_{386,amd64}.go. An alternative would
> be to remove them too.
Moving them sounds good to me. libgo already has a framework for
architecture specific system calls. It doe
On 2 Nov 2011, at 17:18, David Edelsohn wrote:
On Tue, Nov 1, 2011 at 3:00 PM, Peter Bergner
wrote:
+/* Fills in the label name that should be used for a 476 link
stack thunk. */
+
+void
+get_ppc476_thunk_name (char name[32])
+{
+ gcc_assert (TARGET_LINK_STACK);
+
+ if (HAVE_GAS_HIDDE
The invoke.texi change looks fine. The ChangeLog entry needs some work.
http://codereview.appspot.com/5272048/diff/41001/ChangeLog.google-main
File ChangeLog.google-main (right):
http://codereview.appspot.com/5272048/diff/41001/ChangeLog.google-main#newcode6
ChangeLog.google-main:6:
1 2011-11
On 11/02/2011 01:45 PM, Paolo Carlini wrote:
... ehm, we use -Wcast-qual during the bootstrap, thus if I don't want
to break it again, better doing the below too. Seems obvious, by itself.
Yep.
Jason
On Wed, 2011-11-02 at 18:17 +, Iain Sandoe wrote:
> also in macho_branch_islands () :
>
> if (TARGET_LINK_STACK)
> {
> char name[32];
> get_ppc64_thunk_name (name);
> strcat (tmp_buf, ":\n\tmflr r0\n\tbl ");
> strcat (tmp_buf, n
On Wed, 2011-11-02 at 13:18 -0400, David Edelsohn wrote:
> The two new functions have mistakes because I did not realize the
> semantics of HAVE_GAS_HIDDEN. HAVE_GAS_HIDDEN is not a macro to be
> tested at runtime, but a macro tested at compile time.
I'm sorry, I didn't realize that either. Does
Hi,
tested x86_64-linux, committed to mainline.
Paolo.
//
2011-11-02 Richard B. Kreckel
Paolo Carlini
PR libstdc++/50880
* include/std/complex (__complex_acosh): Fix in a better way,
use Kahan's formula.
* include/tr1/complex (__
On 11/02/2011 07:26 PM, Jason Merrill wrote:
On 11/02/2011 01:45 PM, Paolo Carlini wrote:
... ehm, we use -Wcast-qual during the bootstrap, thus if I don't want
to break it again, better doing the below too. Seems obvious, by itself.
Yep.
Great, all done. Note for the accidental reader: it's in
On Wed, 2 Nov 2011, DJ Delorie wrote:
> > > Index: configure.ac
> > > +# Dereferencing -1 is a compile-time error
> >
> > This (those lines) look a little cryptic (and lack punctuation ;)
> > Wild improvement guess: "Too small 'int'?".
>
> No, the compiler specifically tests for unaligned acces
On 2 Nov 2011, at 18:34, Peter Bergner wrote:
On Wed, 2011-11-02 at 18:17 +, Iain Sandoe wrote:
also in macho_branch_islands () :
if (TARGET_LINK_STACK)
{
char name[32];
get_ppc64_thunk_name (name);
strcat (tmp_buf, ":\n\tmfl
OK for google/main with the nits below.
http://codereview.appspot.com/5272048/diff/42003/ChangeLog.google-main
File ChangeLog.google-main (right):
http://codereview.appspot.com/5272048/diff/42003/ChangeLog.google-main#newcode1
ChangeLog.google-main:1: 2011-11-02 Kostya Serebryany
1 2011-
> Ah. All validity issues aside, then "Dereferencing unaligned
> pointers yields a compile-time error" or "pointers with unknown
> alignment" would be much less cryptic: the "Dereferencing -1"
> just sounds like *(char *) -1 or a cut
Good point.
Nobody has asked the obvious question: why does libssp use "*(int *)(-1)
= 0;" in the first place?
Hi,
I am going to benchmark the following hunk separately tonight. It is
independent change.
Rth, Vladimir: there are obviously several options how to make GCC use SSE for
64bit loads/stores in 32bit codegen (and 128bit loads/stores in 128bit
codegen). What do you think is best variant here?
(an
On Wed, 2011-11-02 at 18:52 +, Iain Sandoe wrote:
> Hmm .. I wonder if this is just a temporary glitch because of the move
> of files to libgcc.
Note that I just hit a problem with the libgcc move. We need:
Index: libgcc/config/rs6000/t-ppccomm
=
Another bootstrap issue:
In file included from /home/jason/src/trunk/gcc/fortran/cpp.c:35:0:
/home/jason/src/trunk/gcc/fortran/../../libcpp/internal.h: In function
‘unsigned char* ustrchr(const unsigned char*, int)’:
/home/jason/src/trunk/gcc/fortran/../../libcpp/internal.h:782:55: error:
cast
> I am going to benchmark the following hunk separately tonight. It is
> independent change.
You would probably need some changes from sse.md (for gen_sse2_loadq).
Michael
On 2 Nov 2011, at 19:05, Peter Bergner wrote:
On Wed, 2011-11-02 at 18:52 +, Iain Sandoe wrote:
I'll investigate a bit further later...
So you didn't start your build from scratch? I'll keep my
fingers crossed that a fresh build fixing things for you.
Otherwise, let me know what you fin
Hello.
As subject suggests.
Regression tested on cris-axis-elf.
Comments? OK to install?
* config/cris/constraints.md: New file.
* config/cris/cris.h (REG_CLASS_FROM_LETTER, CONSTRAINT_LEN,
CRIS_CONST_OK_FOR_LETTER_P, CONST_OK_FOR_CONSTRAINT_P,
CONST_DOUBLE
On Wed, 2011-11-02 at 19:33 +, Iain Sandoe wrote:
> I'm going to try this
>
> $ svn diff -x -p gcc/config/rs6000/rs6000.c
> Index: gcc/config/rs6000/rs6000.c
> ===
> --- gcc/config/rs6000/rs6000.c (revision 180788)
> +++ gcc
On 11/02/2011 08:12 PM, Jason Merrill wrote:
Another bootstrap issue:
In file included from /home/jason/src/trunk/gcc/fortran/cpp.c:35:0:
/home/jason/src/trunk/gcc/fortran/../../libcpp/internal.h: In function
‘unsigned char* ustrchr(const unsigned char*, int)’:
/home/jason/src/trunk/gcc/fortran
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 2c53423..6ce240a 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -561,10 +561,14 @@ struct processor_costs ix86_size_cost = {/* costs for
tuning for size */
COSTS_N_BYTES (2), /* cost of FAB
On Wed, 2011-11-02 at 14:05 -0500, Peter Bergner wrote:
> On Wed, 2011-11-02 at 18:52 +, Iain Sandoe wrote:
> > Hmm .. I wonder if this is just a temporary glitch because of the move
> > of files to libgcc.
>
> Note that I just hit a problem with the libgcc move. We need:
>
> Index: libgcc
On Wed, Nov 2, 2011 at 5:50 PM, Ian Lance Taylor wrote:
>> #defines with arguments are not working at all. Please consider
>> following testcase:
>
> You're right: this approach doesn't work for preprocessor macros with
> arguments. Making those work via this approach would be much much
> harder
On 11/02/2011 08:44 PM, Paolo Carlini wrote:
On 11/02/2011 08:12 PM, Jason Merrill wrote:
Another bootstrap issue:
In file included from /home/jason/src/trunk/gcc/fortran/cpp.c:35:0:
/home/jason/src/trunk/gcc/fortran/../../libcpp/internal.h: In
function ‘unsigned char* ustrchr(const unsigned c
this actually.
Paolo.
/
Index: internal.h
===
--- internal.h (revision 180785)
+++ internal.h (working copy)
@@ -739,8 +739,8 @@
static inline int ustrncmp (const unsigned char *, const unsigned char *,
1 - 100 of 161 matches
Mail list logo
