On Mon, Oct 8, 2012 at 9:55 PM, Richard Sandiford
wrote:
> Robert Dewar writes:
>> On 10/8/2012 11:01 AM, Nathan Froyd wrote:
>>> - Original Message -
Btw, as for Richards idea of conditionally placing the length field
in
rtx_def looks like overkill to me. These days we'd
2012-10-09 Jonathan Wakely
PR libstdc++/54754
* include/parallel/compatibility.h: Use atomic built-ins when they are
lock-free.
Tested x86_64-linux, i386-linux, powerpc64-linux. There are some
time-outs when running the 'check-parallel' testsuite on ppc64 which
can be
On 9 October 2012 01:39, Jack Howarth wrote:
>The --enable-libstdcxx-time=yes configure option fails to validate the
> presence of a usable nanosleep() call on darwin due to its use of pre-2008
> POSIX timers. As both nanosleep() and sched_yield() have always been available
> on darwin, the att
H,
I hope this change is responsible for today misoptimizations of SPEC at -O3.
While updating unroll_loop_constant_iterations and fighting with double_int
operations I made two trivial mistakes.
I am bootstrapping/regtesting the following and will commit it as obvious if
it passes.
Honza
On 10/08/12 04:31, Richard Henderson wrote:
> Only "tested" visually, by examining assembly diffs of the
> runtime libraries between successive patches. All told it
> would appear to be some remarkable code size improvements.
>
> Please test.
Thanks a lot for looking into this! I'll test the pat
> On Sat, Oct 6, 2012 at 5:56 PM, Jan Hubicka wrote:
> > Hi,
> > does this look better? Moving to cfg.c would importing tree-pass.h and rtl.h
> > that is not cool either. predict.c does all of these.
> > Obviously can also go to a separate file, if preferred.
>
> Attached is how I would do it. Wh
Hi,
I have just merged upstream gcc-4_7-branch on the aarch64-4.7-branch up to
r192191.
Thanks
Sofiane
Hi,
I have just merged upstream trunk on the aarch64-branch up to r192192.
Thanks
Sofiane
Hello,
this is an updated patch for the GCC 4.8. It renames the target
"arm-rtemseabi" to "arm-rtems" to bring the ARM tool chain back to the standard
RTEMS target pattern "$ARCH-rtems".
GCC test suite results for arm-rtems4.11:
http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg02507.html
-
On 10/09/2012 11:08 AM, Sebastian Huber wrote:
Hello,
this is an updated patch for the GCC 4.8. It renames the target
"arm-rtemseabi" to "arm-rtems" to bring the ARM tool chain back to the standard
RTEMS target pattern "$ARCH-rtems".
GCC test suite results for arm-rtems4.11:
http://gcc.gnu.or
On Mon, Oct 8, 2012 at 10:05 PM, Tobias Burnus wrote:
> Some more issues found by Coverity scanner.
>
> lto-cgraph.c: The code seems to be unused, besides, it's a zero-trip loop as
> parm_num is set to 0 and then checked non nonzeroness.
>
> lto-opts: The check whether first_p is non NULL is alway
Oleg Endo wrote:
> This adds documentation on the new thread pointer built-ins that were
> added recently to the SH target.
> Tested with 'make info dvi pdf'.
> OK?
OK.
Regards,
kaz
Oleg Endo wrote:
> This adds the reduced test case as mentioned by Kaz in the PR to the
> test suite.
> Tested with
> make -k check-gcc RUNTESTFLAGS="compile.exp=pr34777*
> --target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
>
> OK?
It should be put into gcc.ta
Oleg Endo wrote:
> This documents the new thread pointer built-ins in the SH www changes
> for 4.8.
> OK?
Looks OK to me.
Regards,
kaz
> H,
> I hope this change is responsible for today misoptimizations of SPEC at -O3.
> While updating unroll_loop_constant_iterations and fighting with double_int
> operations I made two trivial mistakes.
>
> I am bootstrapping/regtesting the following and will commit it as obvious if
> it passes.
I'd like to know if my direction is ok. I can look into other issues
releated to this and fix them, but it doesn't make much sense if
separate build is not supported and can be easily broken in the
future.
This patch is enough for 4.7 to have build working (at least in
Android environment).
Is it
Thanks for the updates.
Vladimir Makarov writes:
>>> + a change in the offset between the eliminable register and its
>>> + substitution if UPDATE_P, or the full offset if FULL_P, or
>>> + otherwise zero.
>> I wonder if an enum would be better than two booleans?
>> It avoids invalid combina
Hi,
This patch adds support for vcond and vcondu to the AArch64
backend.
Tested with no regressions on aarch64-none-elf.
OK for aarch64-branch?
(If so, someone will have to commit for me, as I do not
have commit rights.)
Thanks
James Greenhalgh
---
2012-09-11 James Greenhalgh
Hi,
we noticed that we dump TEMPLATE_DECLs that are built for template friend
declarations in the current file, which doesn't really make sense.
Tested on x86_64-suse-linux, OK for the mainline?
2012-10-09 Eric Botcazou
* c-ada-spec.c (dump_ada_template): Bail out for template decl
On 09/10/12 10:13, Sebastian Huber wrote:
On 10/09/2012 11:08 AM, Sebastian Huber wrote:
Hello,
this is an updated patch for the GCC 4.8. It renames the target
"arm-rtemseabi" to "arm-rtems" to bring the ARM tool chain back to the standard
RTEMS target pattern "$ARCH-rtems".
GCC test suite re
Not doing that appearantly keeps us avoiding this abstraction
in most places. All asserts in its implementation are overzealous
as well as VEC already has all required checking.
Committed as obvious (LTO bootstrap is broken for other reasons
right now).
Richard.
2012-10-09 Richard Guenther
Dodji,
The following tests are failing (with -m32):
FAIL: g++.dg/cpp0x/gen-attrs-36.C (test for warnings, line 9)
FAIL: g++.dg/cpp0x/gen-attrs-36.C (test for excess errors)
FAIL: g++.dg/cpp0x/gen-attrs-37.C (test for excess errors)
FAIL: g++.dg/cpp0x/gen-attrs-8.C (test for warnings, line 5)
FA
On Tue, Oct 09, 2012 at 09:21:25AM +0100, Jonathan Wakely wrote:
> On 9 October 2012 01:39, Jack Howarth wrote:
> >The --enable-libstdcxx-time=yes configure option fails to validate the
> > presence of a usable nanosleep() call on darwin due to its use of pre-2008
> > POSIX timers. As both nano
Hi,
this is patch I comitted after checking, double checking and tripple checking.
I tested the patch on x86_64-linux. Unfortunately -O3 -fpeel-loops
-funroll-loops bootstrap still fails for me (-O3 bootstrap works), but it seems
independent problem - i.e. it fails with the change reverted, too. I
PING.
On 24 September 2012 11:34, Matthew Gretton-Dann
wrote:
> On Wednesday 05 September 2012 13:47:19 Steven Bosscher wrote:
>> On Wed, Sep 5, 2012 at 1:25 PM, Matthew Gretton-Dann wrote:
>> > + /* If the two blocks are in different partitions we do not want to mark
>> > + this as a fallth
As described in the PR, gcc.target/i386/long-double-80-7.c FAILs on
Solaris 9/x86 and 32-bit Linux/x86. The following patch fixes this.
Tested with the appropriate runtest invocation on i386-pc-solaris2.9,
i386-pc-solaris2.10, i686-unknown-linux-gnu and
x86_64-unknown-linux-gnu, installed on main
Updated patch.
--
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 80 79-9
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäf
On 09/10/12 14:23, Sebastian Huber wrote:
Updated patch.
OK.
R.
0001-Rename-target-arm-rtemseabi-to-arm-rtems.patch
From b338cd309306c1540b2519188e83f76950755cc5 Mon Sep 17 00:00:00 2001
From: Sebastian Huber
Date: Mon, 24 Sep 2012 17:49:36 +0200
Subject: [PATCH] Rename target arm-rtems
Hello Dominique,
domi...@lps.ens.fr (Dominique Dhumieres) writes:
> The following tests are failing (with -m32):
>
> FAIL: g++.dg/cpp0x/gen-attrs-36.C (test for warnings, line 9)
> FAIL: g++.dg/cpp0x/gen-attrs-36.C (test for excess errors)
> FAIL: g++.dg/cpp0x/gen-attrs-37.C (test for excess err
> > These tests are still failing on darwin. I think tha
> > target { ! *-*-solaris2* } { ! *-*-darwin* }
> > sould be replaced with
> > target { ! { *-*-solaris2* *-*-darwin* } }
>
> Could someone with a darwin box handy make the appropriate change?
I have never really understood the logic of the
On 08/10/12 08:29, Terry Guo wrote:
Hi,
When running libstdc++ regression test on Cortex-M0, the case 49445.cc fails
with error message:
/tmp/ccMqZdgc.o: In function `std::atomic::load(std::memory_order)
const':^M
/home/build/work/GCC-4-7-build/build-native/gcc-final/arm-none-eabi/armv6-m/
libs
On x86_64-apple-darwin10 The following tests:
g++.dg/gomp/tls-5.C
g++.dg/tls/thread_local-cse.C
g++.dg/tls/thread_local-order*.C
g++.dg/tls/thread_local*g.C
fail with
sorry, unimplemented: dynamic initialization of non-function-local thread_local
variables not supported on this target
In addit
This should fix PR54837, LTO is not yet prepared for
debug source stmts. The following moves checking code that
triggers to a place where it hopefully does not trigger.
LTO bootstrap is broken in other ways though :(
Will commit after non-LTO bootstrap finished to make progress.
Richard.
2012
On Tue, 9 Oct 2012, Richard Biener wrote:
>
> This should fix PR54837, LTO is not yet prepared for
> debug source stmts. The following moves checking code that
> triggers to a place where it hopefully does not trigger.
>
> LTO bootstrap is broken in other ways though :(
>
> Will commit after n
On Tue, Oct 09, 2012 at 04:35:16PM +0200, Richard Biener wrote:
> As Jakub says the checking doesn't add much so I am installing
> the following instead, as obvious.
>
> Richard.
>
> 2012-10-09 Richard Guenther
>
> PR middle-end/54837
> * cfgexpand.c (expand_debug_source_expr): Mo
On 27/09/12 01:02, Janis Johnson wrote:
Test gcc.target/arm/div64-unwinding.c is known to fail for GNU/Linux
targets, as described in PR54732. This patch adds an XFAIL.
Tested on arm-none-eabi and arm-none-linux-gnueabi, checked in on trunk.
Janis
gcc-20120926-5
2012-09-26 Janis Johnson
On Tue, Oct 09, 2012 at 04:07:51PM +0200, Dominique Dhumieres wrote:
> On x86_64-apple-darwin10 The following tests:
>
> g++.dg/gomp/tls-5.C
> g++.dg/tls/thread_local-cse.C
> g++.dg/tls/thread_local-order*.C
> g++.dg/tls/thread_local*g.C
>
> fail with
>
> sorry, unimplemented: dynamic initializa
Hans-Peter Nilsson writes:
> This caused a build failure, see PR54860.
I am on it.
Sorry for the inconvenience.
--
Dodji
HI,
apparently simd_fast_mersenne_twister_engine is designed (so far) for
little endian targets only.
Patch sanity checked x86_64-linux (with the __BYTE_ORDER__ ==
__ORDER_LITTLE_ENDIAN__ checks artificially altered to return false too)
Thanks,
Paolo.
///
2012-10-09 Pa
Paolo Carlini writes:
> apparently simd_fast_mersenne_twister_engine is designed (so far) for
> little endian targets only.
>
> Patch sanity checked x86_64-linux (with the __BYTE_ORDER__ ==
> __ORDER_LITTLE_ENDIAN__ checks artificially altered to return false too)
Isn't this too much? As descri
On 10/09/2012 05:04 PM, Rainer Orth wrote:
Paolo Carlini writes:
apparently simd_fast_mersenne_twister_engine is designed (so far) for
little endian targets only.
Patch sanity checked x86_64-linux (with the __BYTE_ORDER__ ==
__ORDER_LITTLE_ENDIAN__ checks artificially altered to return false
Jason Merrill writes:
> Let's move the alias template case from
> primary_template_instantiation_p into alias_template_specialization_p
> and call the latter from the former. And also call it from tsubst.
Like the below?
Note that I have changed the type of the argument of
alias_template_speci
On 10/09/2012 10:43 AM, Jack Howarth wrote:
On Tue, Oct 09, 2012 at 04:07:51PM +0200, Dominique Dhumieres wrote:
On x86_64-apple-darwin10 The following tests:
g++.dg/gomp/tls-5.C
g++.dg/tls/thread_local-cse.C
g++.dg/tls/thread_local-order*.C
g++.dg/tls/thread_local*g.C
fail with
sorry, unimpl
On 9 October 2012 14:11, Jack Howarth wrote:
> On Tue, Oct 09, 2012 at 09:21:25AM +0100, Jonathan Wakely wrote:
>> I don't like the sched_yield macro being set there because it's
>> detected correctly by configure anyway, but I'm not going to labour
>> that point any more.
>
> Since we are defining
OK.
Jason
Hi,
I'm adding the testcase and closing the PR as fixed for 4.8.0.
Thanks,
Paolo.
/
2012-10-09 Paolo Carlini
PR c++/53763
* g++.dg/cpp0x/decltype43.C: New.
Index: g++.dg/cpp0x/decltype43.C
==
I committed the following patch to speed up the elimination patch (rev.
192262).
The patch was successfully bootstrapped on x86/x86-64.
2012-10-09 Vladimir Makarov
* lra-eliminations.c (lra_eliminate): Use direct access to insns
through lra_insn_recog_data for process_insn_f
> These don't work because of the lack of alias support; that's why I put
> dg-require-alias in the tests. Do I need a different magic incantation?
I understand nothing about alias, weak, ... stuff, but from pr52945, if you need
weak-alias, then you have also to use
/* { dg-require-weak "" } */
On 10/08/2012 05:14 PM, Steven Bosscher wrote:
On Mon, Oct 8, 2012 at 10:26 PM, Vladimir Makarov wrote:
So I checked it on big file with > hundred functionson Intel machine and got
before a part of the patch implementing the insn stack as sbitmap
real=243.40 user=241.61 system=1.00
after the
On Tue, Oct 9, 2012 at 6:10 PM, Vladimir Makarov wrote:
> On 10/08/2012 05:14 PM, Steven Bosscher wrote:
>>
>> On Mon, Oct 8, 2012 at 10:26 PM, Vladimir Makarov
>> wrote:
>>
>>> So I checked it on big file with > hundred functionson Intel machine and
>>> got
>>>
>>> before a part of the patch imp
> I'd like to know if my direction is ok. I can look into other issues
> releated to this and fix them, but it doesn't make much sense if
> separate build is not supported and can be easily broken in the
> future.
I like your direction here.
> This patch is enough for 4.7 to have build working (
> I don't like the sched_yield macro being set there because it's
> detected correctly by configure anyway, but I'm not going to labour
> that point any more.
Indeed. Then somebody will waste hours in the future wondering why
configure says no but their TU says yes.
At least a comment in the co
Small fix for 32 bit targets.
-benjamin2012-10-09 Benjamin Kosnik
* testsuite/20_util/specialized_algorithms/uninitialized_copy/808590.cc:
Fix constant value.
diff --git a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/808590.cc b/libstdc++-v3/testsuite/20_util/s
On Tue, 2012-10-09 at 18:33 +0900, Kaz Kojima wrote:
> Oleg Endo wrote:
> > This adds the reduced test case as mentioned by Kaz in the PR to the
> > test suite.
> > Tested with
> > make -k check-gcc RUNTESTFLAGS="compile.exp=pr34777*
> > --target_board=sh-sim
> > \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml
This patch to libbacktrace adds support for tracing through shared
libraries. The libraries are found by calling dl_iterate_phdr, when it
is available.
This patch has some preliminary support for tracing through libaries
opened via dlopen, but there is no code for actually finding such
libraries.
On Tue, Oct 09, 2012 at 10:49:28AM -0700, Benjamin De Kosnik wrote:
>
> > I don't like the sched_yield macro being set there because it's
> > detected correctly by configure anyway, but I'm not going to labour
> > that point any more.
>
> Indeed. Then somebody will waste hours in the future wonde
On Tue, Oct 09, 2012 at 11:20:48AM -0700, Ian Lance Taylor wrote:
> This patch to libbacktrace adds support for tracing through shared
> libraries. The libraries are found by calling dl_iterate_phdr, when it
> is available.
This functionality is definitely useful for meta-plugins like MELT
(sinc
There is a typo in the header files for libstdc++ where the
atomic_signal_fence() method is actually calling __atomic_thread_fence()
instead of __atomic_signal_fence(). This results in extra barriers in
the executable that don't need to be there.
fixed as trivial and checked into mainline. Is
Hello,
This is the same patch I posted in the PR. It seems to fix the issue.
Tested on rev 192200 with
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
and no new failures.
OK?
Cheers,
Oleg
gcc/ChangeLog:
PR target/52480
On 10/09/2012 01:06 PM, Richard Guenther wrote:
On Tue, Oct 9, 2012 at 6:10 PM, Vladimir Makarov wrote:
On 10/08/2012 05:14 PM, Steven Bosscher wrote:
On Mon, Oct 8, 2012 at 10:26 PM, Vladimir Makarov
wrote:
So I checked it on big file with > hundred functionson Intel machine and
got
befor
On 10/07/2012 08:38 PM, Dehao Chen wrote:
+*stmt_p = build2_loc (input_location,
I think input_location in cp_genericize_r will always be the closing
brace of the function, which might be right for a variable in the
outermost block of the function, but not for variables in inner scopes.
> Date: Mon, 8 Oct 2012 20:52:22 +0100
> From: Jonathan Wakely
>
> On 8 October 2012 20:45, Mark Kettenis wrote:
> > Jonathan,
> >
> > Any further thoughts about this? I've attached a diff that combines
> > my origional diff with the change to use the "newlib" locale model on
> > OpenBSD since t
On Oct 9, 2012, at 6:48 AM, Dominique Dhumieres wrote:
>>> These tests are still failing on darwin. I think tha
>>> target { ! *-*-solaris2* } { ! *-*-darwin* }
>>> sould be replaced with
>>> target { ! { *-*-solaris2* *-*-darwin* } }
>>
>> Could someone with a darwin box handy make the appropria
Yes, you are right. I've changed to use EXPR_LOCATION (stmt) for the location.
New patch attached, testing is on-going.
Thanks,
Dehao
On Tue, Oct 9, 2012 at 12:35 PM, Jason Merrill wrote:
> On 10/07/2012 08:38 PM, Dehao Chen wrote:
>>
>> +*stmt_p = build2_loc (input_location,
>
>
> I think
> >> FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 execution test
> >> FAIL: g++.dg/tls/thread_local4.C -std=gnu++11 execution test
>
> These ought to work. Can you debug the problem?
Backtrace for thread_local4.C
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x1503 o
On Tue, Oct 9, 2012 at 11:32 AM, Basile Starynkevitch
wrote:
>
> You could provide an extra API to register dlopen & dlclose to libbacktrace,
> if that helps you
> (of course, I would prefer avoiding that)
I would prefer avoiding that as well.
Calling dl_iterate_phdr can tell libbacktrace relia
On Tue, Oct 09, 2012 at 01:43:06PM -0700, Ian Lance Taylor wrote:
> On Tue, Oct 9, 2012 at 11:32 AM, Basile Starynkevitch
> wrote:
> >
> > You could provide an extra API to register dlopen & dlclose to
> > libbacktrace, if that helps you
> > (of course, I would prefer avoiding that)
>
> I would
On 9 October 2012 20:48, Mark Kettenis wrote:
>
> I think it is. The newlib ctype classification is identical to the
> traditional BSD scheme that OpenBSD uses.
OK, I'll commit your patch tomorrow, thanks.
The patch bootstrapped and passed gcc regression tests.
Thanks,
Dehao
On Tue, Oct 9, 2012 at 1:16 PM, Dehao Chen wrote:
> Yes, you are right. I've changed to use EXPR_LOCATION (stmt) for the location.
>
> New patch attached, testing is on-going.
>
> Thanks,
> Dehao
>
> On Tue, Oct 9, 2012 at 12:
Hello,
The three patches following this messages fix fallouts from my c++11
attributes patch that I committed earlier.
Here is their summary:
Disambiguate nested objc-message-expressions and c++11 attributes
Update g++.dg/cpp0x/gen-attrs-{8,36,37}.C as c++11 attributes to
types are ignor
On 10/5/12, Diego Novillo wrote:
> On Oct 3, 2012 Lawrence Crowl wrote:
> > Change more non-GTY hash tables to use the new type-safe
> > template hash table. Constify member function parameters that
> > can be const. Correct a couple of expressions in formerly
> > uninstantiated templates.
> >
Hello,
A couple of obj-c++ tests were failing[1] because the tokens '[[' can
either be the beginning of a c++11 attribute (that is itself at the
beginning of a statement), or the beginning of a nested
objc-message-expression. This patch resolves the ambiguity by
tentatively parsing the c++11 attr
Hello,
The current implementation of C++11 attributes forbids them from being
applied to a type unless the type is being declared. I forgot to
adjust g++.dg/cpp0x/gen-attrs-{8,36,37}.C that was being run only on
ia32.
Fixed thus, tested on i386-unknown-linux-gnu and
x86_64-unknown-linux-gnu agai
Hello,
For LRA, compressing the live range chains proved to be quite helpful.
The same can be done for IRA, as in the attached patch.
For the test case of PR54146 the effect is time spent in IRA cut in half:
without patch: integrated RA : 206.35 (28%)
with patch: integrated RA
Hello,
On targets cris-elf, alpha and sparc (for instance) it can happen that
the attribute_tables variable is empty for fortran. So
register_scoped_attributes (called by init_attributes) won't call
register_scoped_attributes, so the hash table member of
scoped_attributes is not created.
Later w
Hi,
more great stuff from Daniel. Tested x86_64-linux, committed to mainline.
Thanks,
Paolo.
//
2012-10-09 Daniel Krugler
* include/std/type_traits (common_time): Provide "SFINAE-friendly"
implementation.
(__success_type, __failure_type): Fix.
Oleg Endo wrote:
> Uhm, yes, I forgot to add the -fschedule-insns and -mprefergot options.
> Regarding the -Os option, I think it's better to test this one at
> multiple optimization levels, just in case. I've looked through
> gcc.c-torture/compile and found some target specific test cases there,
Oleg Endo wrote:
> This is the same patch I posted in the PR. It seems to fix the issue.
> Tested on rev 192200 with
> make -k check RUNTESTFLAGS="--target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
>
> and no new failures.
> OK?
OK.
Regards,
kaz
Hi,
native compilers are now built with -static-libstdc++ -static-libgcc (if
bootstrapped) because the switches are added to LDFLAGS during stage 2 and 3.
Nothing is done for stage 1 or cross-compilers, except for Ada where we force
the switches, but this is far from ideal as reported under the
As David noticed, I forgot PRINT_OPERAND_PUNCT_VALID_P in the patch
that removed %. This fixes it.
Bootstrapped and regression tested on powerpc64-linux. Okay to
apply?
Segher
2012-10-09 Segher Boessenkool
gcc/
* config/rs6000/rs6000.h (PRINT_OPERAND_PUNCT_VALID_P):
Delet
Ok, David preferred the 2 series of patches which replace all of the flags in
target_flags to rs6000_isa_flags to the 3 series of patches, which started
over, and added a new flag word, but did not change the existing options.
In an effort to simplify the main patch, I'm going to push out some of
This patch is a preparation patch for the main infrastructure patch. It
changes the types of the builtin masks and target options from unsigned/signed
int to HOST_WIDE_INT. I built this with #2c also installed (but the two
patches are independent). It bootstraped and had no regressions. Is it o
This patch adds more debugging via -mdebug=reg to the compiler, and it is the
main way I verified that all of the options were set correctly. If you do not
use -mdebug=reg, this patch has no effect. When I emailed this patch, I had
bootstraped the compiler, and I was beginning to do make check.
No before I go an redo the main part of patch #2, I have a question, which
people prefer.
The current code has sequences of:
target_flags |= MASK_FOO; /* set -mfoo */
if ((target_flags_explicit & MASK_FOO)) ... /* Did user do -mfoo or
Hi,
I'm adding the testcase and closing the PR as fixed. Tested x86_64-linux.
Thanks,
Paolo.
//
2012-10-10 Paolo Carlini
PR c++/53307
* g++.dg/cpp0x/decltype44.C: New.
Index: g++.dg/cpp0x/decltype44.C
==
On 10/5/12, Jan Hubicka wrote:
>> On Thu, Oct 4, 2012 at 8:16 PM, Diego Novillo wrote:
>> > On Thu, Oct 4, 2012 at 2:14 PM, Lawrence Crowl wrote:
>> >
>> >> So, Jan Hubicka requested and approved the current spelling.
>> >> What now?
>> >
>> > I don't think we should hold this up. The names Jan
OK.
Jason
These are all OK.
Jason
On Tue, Oct 9, 2012 at 6:53 PM, Segher Boessenkool
wrote:
> As David noticed, I forgot PRINT_OPERAND_PUNCT_VALID_P in the patch
> that removed %. This fixes it.
>
> Bootstrapped and regression tested on powerpc64-linux. Okay to
> apply?
> 2012-10-09 Segher Boessenkool
>
> gcc/
> * co
On 10/09/2012 04:36 PM, Dominique Dhumieres wrote:
==36994== Address 0x1003cd2e0 is 16 bytes inside a block of size 536 free'd
==36994==at 0x10001252D: free (vg_replace_malloc.c:430)
==36994==by 0x1003B5CB2: emutls_destroy (in
/opt/gcc/gcc4.8p-192219/lib/libgcc_s.1.dylib)
Aha. So the
On Tue, Oct 9, 2012 at 6:58 PM, Michael Meissner
wrote:
> Ok, David preferred the 2 series of patches which replace all of the flags in
> target_flags to rs6000_isa_flags to the 3 series of patches, which started
> over, and added a new flag word, but did not change the existing options.
>
> In an
On Tue, Oct 9, 2012 at 7:01 PM, Michael Meissner
wrote:
> This patch is a preparation patch for the main infrastructure patch. It
> changes the types of the builtin masks and target options from unsigned/signed
> int to HOST_WIDE_INT. I built this with #2c also installed (but the two
> patches a
On Tue, Oct 9, 2012 at 7:20 PM, Michael Meissner
wrote:
> This patch adds more debugging via -mdebug=reg to the compiler, and it is the
> main way I verified that all of the options were set correctly. If you do not
> use -mdebug=reg, this patch has no effect. When I emailed this patch, I had
>
> -Original Message-
> From: Richard Earnshaw
> Sent: Tuesday, October 09, 2012 10:01 PM
> To: Terry Guo
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [Patch ARM] Fix that miss DMB instruction for ARMv6-M
>
> On 08/10/12 08:29, Terry Guo wrote:
> > Hi,
> >
> > When running libstdc++ regre
Some recent work showed me that many of the latency values in the
documentation I have for Niagara-4 were simply inaccurate. So I
went through the instruction set and tried to determine the real
values by hand using test programs.
In particular the logical VIS operation, when working on 64-bit
o
On 10/09/2012 07:39 AM, Richard Earnshaw wrote:
> On 27/09/12 01:02, Janis Johnson wrote:
>> Test gcc.target/arm/div64-unwinding.c is known to fail for GNU/Linux
>> targets, as described in PR54732. This patch adds an XFAIL.
>>
>> Tested on arm-none-eabi and arm-none-linux-gnueabi, checked in on t
Ping.
On 10/04/2012 03:45 PM, Meador Inge wrote:
> Hi All,
>
> Currently the gcc-{ar,nm,ranlib} utilities assume that binutils is in
> path when invoking the wrapped binutils program. This goes against the
> accepted practice in GCC to find sub-programs relative to where the
> GCC binaries are s
This fixes a problem with my PR45844 fix. PR45844 was due to rs6000.c
reg_offset_addressing_ok_p testing the operand mode to determine
whether an insn supports reg+offset addressing, but the VSX splat insn
uses a DF/DI mode input operand. So the memory form of this insn was
wrongly seen to suppor
The following patch is formed from latest discussion with Richard Sandiford.
The patch was successfully bootstrapped on x86/x86-64 and ppc64.
Committed as rev. 192287.
012-10-09 Vladimir Makarov
* lra-eliminations.c (lra_eliminate_regs_1): Remove mem_mode
check. Remove form
On 10/09/2012 06:17 AM, Richard Sandiford wrote:
Thanks for the updates.
Vladimir Makarov writes:
+ a change in the offset between the eliminable register and its
+ substitution if UPDATE_P, or the full offset if FULL_P, or
+ otherwise zero.
I wonder if an enum would be better than two
1 - 100 of 110 matches
Mail list logo
