On Tue, Aug 13, 2013 at 9:42 PM, Jakub Jelinek wrote:
> We right now ICE with -mcmodel=large -fpic on x86_64 on TLS GD and LD
> sequences, because obviously we can't call __tls_get_addr@plt there from code
> potentially more than 2GB away from the PLT slot.
>
> The attached patches add support fo
On Tue, Aug 13, 2013 at 9:47 PM, Jakub Jelinek wrote:
> On x86_64 with -mcmodel=large -fpic -g -O2 we get tons of
> notes about non-delegitimized unspecs like UNSPEC_GOTOFF, UNSPEC_PLTOFF
> or UNSPEC_GOT. Seems we already handle most of those properly for -m32
> code, so the issue is just that w
Hi Richard,
Here is an attempt to address your earlier review comments. Bootstrapped
and there is no new regression for X86_64 and arm. Thank you very much
for your time.
Thanks,
Kugan
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,25 @@
+2013-08-14 Kugan Vivekanandarajah
+
+ *
Hello,
Patch was rebased on top of trunk.
It is applicable on top of [1/8] (which was rebased on new trunk today).
Testing:
1. Bootstrap pass.
2. make check shows no regressions.
3. Spec 2000 & 2006 build show no regressions both with and without -mavx512f
option.
4. Spec 2000 &
Hi Eric,
Thanks for reviewing the patch.
On 01/07/13 18:51, Eric Botcazou wrote:
[Sorry for the delay]
For example, when an expression is evaluated and it's value is assigned
to variable of type short, the generated RTL would look something like
the following.
(set (reg:SI 110)
Ping.
Thanks,
Kyrill
2013-08-14 Kyrylo Tkachov
PR tree-optimization/58088
* fold-const.c (mask_with_trailing_zeros): New function.
(fold_binary_loc): Make sure we don't recurse infinitely
when the X in (X & C1) | C2 is a tree of the form (Y * K1) & K2.
On Wed, Aug 07, 2013 at 11:47:55PM +0200, Paolo Carlini wrote:
> Hi,
>
> On 08/07/2013 10:48 PM, Uros Bizjak wrote:
> >2013-08-07 Uros Bizjak
> >
> > * src/c++98/compatibility.cc (_ZTIe): Use const_cast to avoid warning.
> > (_ZTIPe): Ditto.
> > (ZTIPKe): Ditto.
> >
> >The patch was
On Wed, Aug 14, 2013 at 10:29 AM, Jakub Jelinek wrote:
>> >2013-08-07 Uros Bizjak
>> >
>> > * src/c++98/compatibility.cc (_ZTIe): Use const_cast to avoid warning.
>> > (_ZTIPe): Ditto.
>> > (ZTIPKe): Ditto.
>> >
>> >The patch was bootstrapped on alpha-linux-gnu, regression test is
On 08/14/2013 10:41 AM, Uros Bizjak wrote:
These didn't emit warnings for my target (alpha), so also not being a
C++ person, I left them as they were.
Ok then, for now let's simply go ahead with your original patch. Please
also add a one line comment before the first cast.
Thanks!
Paolo.
The rules to install the dummy libgcc_bc library have never worked as
intented, probably due to the fact that the fedora gcc package installs
it by hand, ignoring all damage that has been done. The target that
creates libgcj_bc.la for the testsuite is mucking around with internal
details that will
On Wed, 14 Aug 2013 12:36:00, Richard Biener wrote:
> ChangeLog without gcc/ prefix - it's for the gcc/ChangeLog file. Ok
> with that
> change.
>
> Thanks,
> Richard.
>
Thanks for your quick response.
But as I do not have check-in access I might need some help.
Thanks
Bernd.
On Tue, 2013-08-13 at 12:09 -0700, Richard Henderson wrote:
> On 08/13/2013 11:26 AM, Jakub Jelinek wrote:
> > On Fri, Aug 02, 2013 at 11:05:33AM -1000, Richard Henderson wrote:
> >> On 08/02/2013 04:45 AM, Andreas Krebbel wrote:
> >>> ! XCFLAGS="${XCFLAGS} -mzarch -mhtm -msoft-float"
> >>
>
On Thu, Aug 01, 2013 at 10:55:15AM +0200, Andreas Krebbel wrote:
> I would like to apply backports of the TX support patches to 4.8
> branch. We released 4.8 with EC12 support already but the support is
> somewhat incomplete without having TX. With these patches we will
> have full EC12 support i
Hi!
On the following testcases we miscompile the code (on -1.c just drop
= {v} from the statements, on -2.c lim moves the volatile stores after the
loop), because SRA drops the volatileness from the MEM_REF.
SRA generally ignores volatile vars and fields etc., but if we have a
structure assignmen
Hello,
As noted in Bugzilla, the problem is this PR is the rare case of removing
the unconditional jump that is used for traversing CFG when simplifying
control flow. We rescan the remaining successors when we know the flow
below the current point has changed, and when we have removed the jum
When doing bootstrap with ubsan, some files require libpthread to be
linked. This patch adds -lpthread into POSTSTAGE1_LDFLAGS for the
bootstrap-ubsan.
Applying to the ubsan branch.
2013-08-14 Marek Polacek
* bootstrap-ubsan.mk (POSTSTAGE1_LDFLAGS): Add -lpthread.
--- gcc/bootstrap-
On 08/12/2013 08:34 PM, Adam Butcher wrote:
Currently it is the implicit function template code in pt.c that updates
this; specifically add_implicit_template_parms and
finish_fully_implicit_template.
It is queried by the parser (both in parser.c and lambda.c) to decide
whether a new [implicit] t
On Wed, Aug 14, 2013 at 4:05 PM, Gabriel Dos Reis
wrote:
> I agree 'const void*' is preferable, and all the places you mention should
> be covered too.
I already installed my original patch, so attached incremental patch
implements preferred solution.
2013-08-14 Uros Bizjak
* src/c++
On Wed, Aug 14, 2013 at 04:22:07PM +0200, Uros Bizjak wrote:
> On Wed, Aug 14, 2013 at 4:05 PM, Gabriel Dos Reis
> wrote:
> > I agree 'const void*' is preferable, and all the places you mention should
> > be covered too.
>
> I already installed my original patch, so attached incremental patch
> i
On Wed, Aug 14, 2013 at 9:07 AM, Jason Merrill wrote:
> On 08/12/2013 08:34 PM, Adam Butcher wrote:
>>
>> Currently it is the implicit function template code in pt.c that updates
>> this; specifically add_implicit_template_parms and
>> finish_fully_implicit_template.
>>
>> It is queried by the par
On Wed, Aug 14, 2013 at 9:22 AM, Uros Bizjak wrote:
>
> On Wed, Aug 14, 2013 at 4:05 PM, Gabriel Dos Reis
> wrote:
> > I agree 'const void*' is preferable, and all the places you mention should
> > be covered too.
>
> I already installed my original patch, so attached incremental patch
> implemen
On Wed, 14 Aug 2013, Andrey Belevantsev wrote:
> Hello,
>
> As noted in Bugzilla, the problem is this PR is the rare case of removing the
> unconditional jump that is used for traversing CFG when simplifying control
> flow. We rescan the remaining successors when we know the flow below the
> c
On Wed, Aug 14, 2013 at 4:34 PM, Gabriel Dos Reis
wrote:
> On Wed, Aug 14, 2013 at 9:22 AM, Uros Bizjak wrote:
>>
>> On Wed, Aug 14, 2013 at 4:05 PM, Gabriel Dos Reis
>> wrote:
>> > I agree 'const void*' is preferable, and all the places you mention should
>> > be covered too.
>>
>> I already in
On Wed, Aug 14, 2013 at 4:36 PM, Uros Bizjak wrote:
> On Wed, Aug 14, 2013 at 4:34 PM, Gabriel Dos Reis
> wrote:
>> On Wed, Aug 14, 2013 at 9:22 AM, Uros Bizjak wrote:
>>>
>>> On Wed, Aug 14, 2013 at 4:05 PM, Gabriel Dos Reis
>>> wrote:
>>> > I agree 'const void*' is preferable, and all the pla
We ICEd on the following testcase because even though the underlying
types were the same, theirs TREE_TYPEs were not. We can use
TYPE_MAIN_VARIANT to see through the typedefs which confused us.
Tested x86_64-pc-linux-gnu, applying to the ubsan branch.
2013-08-14 Marek Polacek
* c-ubs
On 08/12/2013 07:07 PM, Caroline Tice wrote:
The feature is supposed to be active in production code (like the
stack protector).
Okay, and it makes sense to enable this in programs that run with
different privileges than the invoking user.
If a trust transition occurred during the past exec
This fixes a long-standing problem with GCC's implementation of the
PPC64 ELF ABI. If a structure contains a member requiring 128-bit
alignment, and that structure is passed as a parameter, the parameter
currently receives only 64-bit alignment. This is an error, and is
incompatible with correct
On 08/14/2013 05:44 AM, Torvald Riegel wrote:
> Can we instead move the successful path of the HTM fastpath to the
> _ITM_beginTransaction asm function, and just do the fallback and retry
> code in beginend.cc?
Certainly, but this seems like a larger re-design, and I was thinking of
a shorter-term
Ping?
David
On Mon, Aug 12, 2013 at 9:54 AM, Xinliang David Li wrote:
> Fixed some formatting issues and typos. There are no regressions with
> the attached patch. Ok for trunk?
>
> thanks,
>
> David
>
> On Wed, Aug 7, 2013 at 10:12 PM, Xinliang David Li wrote:
>> Hi, the attached is a follow u
These patches haven't been reviewed for more that three weeks:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00808.html
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00811.html
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00906.html
Hi,
I have recently backported the following revisions from to
linaro/gcc-4_8-branch:
200204 (as 201484)
200419 (as 201485)
200466,200467 (as 201486)
200519 (as 201487)
200521 (as 201488)
200531 (as 201489)
200532,200565 (as 201490)
200637 (as 201491)
200670 (as 201493)
200720 (as 201496)
200922
These patches have not been reviewed for more than three weeks:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00807.html
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00812.html
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00816.html
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00819.html
http://gc
> > 2013-08-07 Xinliang David Li
> >
> > * config/i386/i386.h: Adjust macro definition.
> > * config/i386/i386.opt: Define two new options.
> > * config/i386/x86-tune.def: Add arch selector field in macros.
> > * config/i386/i386.h: include x86-tune.def.
> >
On 08/14/2013 08:55 AM, Joern Rennecke wrote:
> These patches have not been reviewed for more than three weeks:
>
> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00807.html
> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00812.html
> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00816.html
> http://g
On Wed, Aug 14, 2013 at 9:01 AM, Jan Hubicka wrote:
>> > 2013-08-07 Xinliang David Li
>> >
>> > * config/i386/i386.h: Adjust macro definition.
>> > * config/i386/i386.opt: Define two new options.
>> > * config/i386/x86-tune.def: Add arch selector field in macros.
>> >
On 14 Aug 2013, at 17:15, Janis Johnson wrote:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00895.html
>
> I'd prefer to have someone else review this patch, which replaces
> -gdwarf-2 with -gdwarf.
It is quite likely to break on (at least) Darwin9..10 and likely later - I'll
give it a s
On Jul 19, 2013, at 11:46 PM, Joern Rennecke
wrote:
> Tested for avr with --target_board=atmega128-sim and native on
> i686-pc-linuc-gnu.
>
> 2013-07-17 Joern Rennecke
>
> * c-c++-common/simulate-thread/bitfields-2.c: Run test only for
> target { ! int16 }.
> * gcc.dg/tree-
Ok.
On Jul 19, 2013, at 11:28 PM, Joern Rennecke
wrote:
> Tested for avr with --target_board=atmega128-sim and native on
> i686-pc-linuc-gnu.
>
> 2013-07-05 Joern Rennecke
>
> * c-c++-common/scal-to-vec1.c: Add !int16 and large_double conditions
> to tests that assume int/double
OK.
On Jul 19, 2013, at 11:14 PM, Joern Rennecke
wrote:
> Tested for avr with --target_board=atmega128-sim and native on
> i686-pc-linuc-gnu.
>
> 2013-07-05 Joern Rennecke
>
> * gcc.dg/pr44214-1.c (v2df): Define size using sizeof (double).
> * gcc.dg/pr44214-3.c (v2df): Likewise
Ok.
On Jul 19, 2013, at 10:54 PM, Joern Rennecke
wrote:
> With 16 bit integers, (int) 0x0001 is just 0, so execution of that test
> fails.
>
> Tested for avr with --target_board=atmega128-sim and native on
> i686-pc-linuc-gnu.
>
> 2013-05-13 Joern Rennecke
>
> * gcc.c-torture/ex
On Wed, Aug 14, 2013 at 9:49 AM, Uros Bizjak wrote:
> On Wed, Aug 14, 2013 at 4:36 PM, Uros Bizjak wrote:
>> On Wed, Aug 14, 2013 at 4:34 PM, Gabriel Dos Reis
>> wrote:
>>> On Wed, Aug 14, 2013 at 9:22 AM, Uros Bizjak wrote:
On Wed, Aug 14, 2013 at 4:05 PM, Gabriel Dos Reis
wrot
On 14 Aug 2013, at 17:19, Iain Sandoe wrote:
> On 14 Aug 2013, at 17:15, Janis Johnson wrote:
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00895.html
>>
>> I'd prefer to have someone else review this patch, which replaces
>> -gdwarf-2 with -gdwarf.
>
> It is quite likely to break on (at
On Aug 14, 2013, at 9:51 AM, Iain Sandoe wrote:
> On 14 Aug 2013, at 17:19, Iain Sandoe wrote:
>> On 14 Aug 2013, at 17:15, Janis Johnson wrote:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00895.html
>>>
>>> I'd prefer to have someone else review this patch, which replaces
>>> -gdwarf
Ok.
On Jul 22, 2013, at 2:40 AM, Joern Rennecke wrote:
> Quoting Jakub Jelinek :
>
>> On Mon, Jul 22, 2013 at 10:31:03AM +0530, Senthil Kumar Selvaraj wrote:
> ..
>>> I ran into this problem a while ago, and after discussion on the
>>> mailing list, added a -gdwarf option to emit DWARF with the
On Aug 14, 2013, at 8:55 AM, Joern Rennecke wrote:
> These patches have not been reviewed for more than three weeks:
Ok, all should be reviewed now, let us know if there are any missed.
As the test directives section of the GCC internals manual says:
The order in which test directives appear in a test can be important:
directives local to GCC sometimes override information used by the
DejaGnu directives, which know nothing about the GCC directives, so
the DejaGnu dire
This patch skips an arm test if the multilib flags include "-mthumb",
which would override the "-marm" used for the test. Tested with
several sets of flags for arm-none-eabi and checked in as obvious.
Janis
2013-04-24 Janis Johnson
* arm-none-linux-eabi.inc (print_eembc_scale_factor):
Ok.
[ minor updates like this can be checked in under the obvious rule if you wish ]
On Jul 19, 2013, at 10:58 PM, Joern Rennecke
wrote:
> Because we now issue the error message for the place of the macro definition,
> the expected line number has to be updated.
>
> Tested for avr with --targe
On 08/14/2013 02:14 AM, Jan Hubicka wrote:
As a temporary hack I suppose I can rely on assembler name of virtual table
to be unique for each templated class?
Actually, that seems like a fine solution for devirtualization; just
compare the mangled name of the vtable to establish type identity.
Ok.
[ be sure to ask Ok? when you would like a review/approval ]
On Jul 19, 2013, at 11:09 PM, Joern Rennecke
wrote:
> Tested for avr with --target_board=atmega128-sim and native on
> i686-pc-linuc-gnu.
>
> 2013-06-24 Joern Rennecke
>
> * gcc.dg/torture/stackalign/builtin-apply-2.c:
Ok.
On Jul 22, 2013, at 3:57 AM, Joern Rennecke wrote:
> Quoting Georg-Johann Lay :
>
>> Joern Rennecke wrote:
>>> xfail for avr*-*-*
>>
>> Hi,
>>
>> the target machine is avr-*-* because, say, avr32 (a 32-bit MCU not
>> officially
>> supported) is a quite different architecture than avr.
>>
On Aug 14, 2013, at 8:47 AM, Joern Rennecke wrote:
> These patches haven't been reviewed for more that three weeks:
>
> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00808.html
> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00811.html
> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00906.html
Ok,
On Wed, Aug 14, 2013 at 3:38 AM, Richard Biener
wrote:
> On Wed, Aug 14, 2013 at 2:02 AM, Sriraman Tallam
> wrote:
>>
>> Hi,
>>
>> I have attached a patch to fix PR57756. Description: The
>> following program,
>>
>> __attribute__((always_inline,target("sse4.2")))
>> __inline int callee ()
>
Jakub Jelinek wrote:
>Hi!
>
>On the following testcases we miscompile the code (on -1.c just drop
>= {v} from the statements, on -2.c lim moves the volatile stores after
>the
>loop), because SRA drops the volatileness from the MEM_REF.
>
>SRA generally ignores volatile vars and fields etc., but if
I committed the following patch as obvious fix.
Index: ChangeLog
===
Index: config/i386/i386.c
===
davidxl@aples2:../tot/gcc\>> svn diff
Index: config/i386/i386.c
==
On Wed, Aug 14, 2013 at 11:12:27AM -0700, Xinliang David Li wrote:
> Index: ChangeLog
> ===
> --- ChangeLog (revision 201732)
> +++ ChangeLog (working copy)
> @@ -1,4 +1,8 @@
> 2013-08-14 Xinliang David Li
> + * config/i3
On Wed, Aug 14, 2013 at 08:17:55PM +0200, Marek Polacek wrote:
> On Wed, Aug 14, 2013 at 11:12:27AM -0700, Xinliang David Li wrote:
> > Index: ChangeLog
> > ===
> > --- ChangeLog (revision 201732)
> > +++ ChangeLog (working copy)
>
Ok. Will drop it in the next patch.
David
On Wed, Aug 14, 2013 at 11:23 AM, Jakub Jelinek wrote:
> On Wed, Aug 14, 2013 at 08:17:55PM +0200, Marek Polacek wrote:
>> On Wed, Aug 14, 2013 at 11:12:27AM -0700, Xinliang David Li wrote:
>> > Index: ChangeLog
>> > =
On 14/08/13 15:00, Jakub Jelinek wrote:
> On Thu, Aug 01, 2013 at 10:55:15AM +0200, Andreas Krebbel wrote:
>> I would like to apply backports of the TX support patches to 4.8
>> branch. We released 4.8 with EC12 support already but the support is
>> somewhat incomplete without having TX. With the
Hi all, Jason,
thus, per the notes I left on the audit trail some time ago, this seems
to me a possible approach to reject this kind of invalid code. What do
you think?
Booted & tested x86_64-linux.
Thanks,
Paolo.
//
Index: cp/call.c
=
Ping?
On Thu, Aug 8, 2013 at 3:16 PM, Caroline Tice wrote:
> This patch replaces the fixed sized array that was holding vtable
> pointers for a particular class hierarchy with a vector, allowing for
> dynamic resizing. It also fixes issues with the warning diagnostics.
> I am in the process of r
Quoting Jakub Jelinek :
On Mon, Jul 22, 2013 at 10:31:03AM +0530, Senthil Kumar Selvaraj wrote:
On Sat, Jul 20, 2013 at 01:45:37AM -0400, Joern Rennecke wrote:
> Although the gcc.dg/debug/dwarf2/dwarf2.exp generally requests dwarf-2
> information, so that the test will work with targets that ha
On 08/14/2013 03:20 PM, Paolo Carlini wrote:
+/* Used in case_conversion. */
Also say what it means. OK with that change.
Jason
On Wed, Aug 14, 2013 at 03:29:21PM -0400, Joern Rennecke wrote:
> Ok to apply?
Yes, thanks.
> 2013-08-14 Joern Rennecke
>
> * gcc.dg/debug/dwarf2/global-used-types.c: Request dwarf output.
> * gcc.dg/debug/dwarf2/inline2.c: Likewise.
> * gcc.dg/debug/dwarf2/inline3.c: Likewi
On Aug 14, 2013, at 12:29 PM, Joern Rennecke
wrote:
> Ok to apply?
Ok.
> 2013-08-14 Joern Rennecke
>
> * gcc.dg/debug/dwarf2/global-used-types.c: Request dwarf output.
> * gcc.dg/debug/dwarf2/inline2.c: Likewise.
> * gcc.dg/debug/dwarf2/inline3.c: Likewise.
> * gcc.d
> -Original Message-
> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
> Sent: Wednesday, August 14, 2013 8:48 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Denis Chertykov; Anatoly Sokolov; Weddington, Eric
> Subject: Ping: [avr] testsuite patches ({3,5,7,8,9,14}/14)
>
> These patches
Hi, Jakub,
According to this discussion thread:
http://gcc.gnu.org/ml/gcc/2013-08/msg00142.html
The bug that David mentioned has been fixed on trunk but not on 4.8 branch.
IMHO it would be a good idea to backport it and Vladmir agreed with that.
The patch and a plaintext ChangeLog are as follow.
On Thu, Aug 15, 2013 at 04:09:18AM +0800, Chung-Ju Wu wrote:
> According to this discussion thread:
> http://gcc.gnu.org/ml/gcc/2013-08/msg00142.html
>
> The bug that David mentioned has been fixed on trunk but not on 4.8 branch.
> IMHO it would be a good idea to backport it and Vladmir agreed wit
On Wed, Aug 14, 2013 at 11:32 AM, Bill Schmidt
wrote:
> Bootstrapped and tested on powerpc64-unknown-linux-gnu with no
> regressions. Ok for trunk?
>
> Thanks,
> Bill
>
>
> gcc:
>
> 2013-08-14 Bill Schmidt
>
> PR target/57949
> * doc/invoke.texi: Add documentation of mcompat-a
Here is the clean up patch. Ok for trunk?
thanks,
David
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 201735)
+++ config/i386/i386.c (working copy)
@@ -2792,7 +2792,6 @@ static const char *stringop_alg_names[]
s
On Wed, Aug 14, 2013 at 01:50:31PM -0700, Xinliang David Li wrote:
> Here is the clean up patch. Ok for trunk?
Ok.
> --- config/i386/i386.c (revision 201735)
> +++ config/i386/i386.c (working copy)
> @@ -2792,7 +2792,6 @@ static const char *stringop_alg_names[]
>
> struct stringop_size_range
On 02/08/13 23:05, Richard Henderson wrote:
> On 08/02/2013 04:45 AM, Andreas Krebbel wrote:
>> ! XCFLAGS="${XCFLAGS} -mzarch -mhtm -msoft-float"
>
> Not good, since _ITM_R{F,D,E,CF,CD,CE} should return values in
> floating point registers; similarly for the write accessors.
Right. I've rev
On 14/08/13 17:33, Richard Henderson wrote:
> On 08/14/2013 05:44 AM, Torvald Riegel wrote:
>> Can we instead move the successful path of the HTM fastpath to the
>> _ITM_beginTransaction asm function, and just do the fallback and retry
>> code in beginend.cc?
>
> Certainly, but this seems like a l
Hello world,
the attached patch enables more sophisticated bounds-checking on
array slices by using gfc_dep_difference to calculate extents.
The information may also be useful in other places of the
front end, I don't really know.
There is one wrinkle (alluded to in the comments) which makes
this
In running the spec 2006 testsuite with several options, we discovered that
-mtune=power8 (which turns on the -mpower8-fusion option) has a segmentation
fault in two benchmarks:
403.gcc when built with -O2 -mcpu=power7 -mtune=power8 -m32
435.gromacs when built with -O3 -funroll-loops -mcpu=power7
On Wed, Aug 14, 2013 at 06:55:26PM -0400, Michael Meissner wrote:
> In running the spec 2006 testsuite with several options, we discovered that
> -mtune=power8 (which turns on the -mpower8-fusion option) has a segmentation
> fault in two benchmarks:
>
> 403.gcc when built with -O2 -mcpu=power7 -mt
On Thu, Aug 15, 2013 at 01:18:00AM +0200, Jakub Jelinek wrote:
> On Wed, Aug 14, 2013 at 06:55:26PM -0400, Michael Meissner wrote:
> > In running the spec 2006 testsuite with several options, we discovered that
> > -mtune=power8 (which turns on the -mpower8-fusion option) has a segmentation
> > fau
Hi,
tested x86_64-linux, make check/check-debug, committing to mainline.
Thanks,
Paolo.
/
2013-08-14 Paolo Carlini
PR libstdc++/58163
* include/bits/basic_string.h (basic_string<>::operator[]): Fix
_GLIBCXX_DEBUG_PEDASSERT check vs C++11.
Greetings,
I've committed r201755 on google/gcc-4_8 branch as r201761.
79 matches
Mail list logo
