Hello Joseph,
Please help to review this new Multilib feature. It intends to provide user
a chance to define their own multilib selection rules. Those rules will be
appended to rules generated by gcc script genmultilib. Thus when gcc can't
find suitable multilib from its own rules, it can fall bac
Hi!
Seems I wrote a patch 7.5 years ago for and on the 3.4 branch
(supposedly for a testcase that went latent on the trunk at that time,
due to SSA merge?), and missed the fact that GET_RTX_CLASS changed
on the trunk from characters to enum.
Fixed thusly, bootstrapped/regtested on x86_64-linux an
Hi!
As the testcase shows, a REAL_CST can appear in MINUS_EXPR as second operand
(that is not canonicalized to PLUS_EXPR of negated value, unlike integer
constants (with exception of minimum value)). The following patch handles
constants there and punts if it isn't SSA_NAME or a constant that can
Hi!
On 32-bit HWI warning there is a warning about signed (INTVAL) vs. unsigned
({,op_}precision) comparison (on 64-bit HWI that doesn't trigger, as
INTVAL is 64-bit signed long, while precision is 32-bit unsigned).
This patch fixes the warning and makes sure we don't try to optimize
shifts by neg
Hi!
On Mon, Oct 08, 2012 at 10:01:53AM +, Kumar, Venkataramanan wrote:
Both the testcases fail on i686-linux unfortunately:
Excess errors:
/usr/src/gcc/gcc/testsuite/gcc.dg/pr53397-1.c:1:0: warning:
-fprefetch-loop-arrays not supported for this target (try -march switches)
[enabled by defau
Looks like S_M_A A is cracking through resistance at the $0.09 position
and is organized to rise past $.15 this next few days! Lets press these
shorters off the tower and we would all put together a solid profit on
S_M_A A.
Today: Oct 10th
Company: SMA Alliance, Inc.
Stock: S_M_A A
Buy at: $0.
Hi,
the attached patch adds initial support for the latest release of the
IBM mainframe series - the IBM zEnterprise EC12 (zEC12).
The new -march=zEC12 option can be used to generate code for the new
machine. As usual -mtune=zEC12 only enables zEC12 specific tuning
without making use of new instr
On Tue, Oct 9, 2012 at 9:28 PM, Hans-Peter Nilsson wrote:
> On Tue, 9 Oct 2012, Ian Lance Taylor wrote:
>> Patch bootstrapped and ran libbacktrace and Go testsuites on
>> x86_64-unknown-linux-gnu. Committed to mainline.
>
> Trying x86_64 host gcc 4.1.2 (--target=rl78-elf but not the issue) at
> r
On Tue, 9 Oct 2012, Ian Lance Taylor wrote:
> Patch bootstrapped and ran libbacktrace and Go testsuites on
> x86_64-unknown-linux-gnu. Committed to mainline.
Trying x86_64 host gcc 4.1.2 (--target=rl78-elf but not the issue) at
r192285:
/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONF
On 12-10-09 5:24 PM, Steven Bosscher wrote:
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 : 2
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
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
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
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
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
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
> -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
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
>
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 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 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: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
These are all OK.
Jason
OK.
Jason
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
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
==
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
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.
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
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
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
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
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
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,
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.
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
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,
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,
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
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,
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
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:
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.
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 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
> >> 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
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
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
> 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 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.
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
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
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
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
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
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, 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
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
> 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
> 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 (
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
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
> 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 "" } */
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
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
==
OK.
Jason
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
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
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 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
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
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
Hans-Peter Nilsson writes:
> This caused a build failure, see PR54860.
I am on it.
Sorry for the inconvenience.
--
Dodji
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
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: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 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
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 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
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
> > 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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.
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
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 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
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
1 - 100 of 110 matches
Mail list logo
