Hi,
MULTIARCH_DIRNAME was removed @r196649 since the dir info had been
combined in MULTILIB_OSDIRNAMES.
But MULTIARCH_DIRNAME was re-added @r201164. With this change, the
final multiarch_dir is combined as
"aarch64-linux-gnu:aarch64-linux-gnu", which is incorrect and leads to
multiarch build fail
If you want to limit to x86_64-linux only, please do:
target { { i?86-*-linux* x86_64-*-linux* } && lp64 }
instead. Also, what advantages do you see for trying to assemble
the result? If you instead just do dg-do compile, you can drop -save-temps
from dg-options and /* { dg-final { cleanup-saved
On Fri, Jan 10, 2014 at 12:34:49PM +0400, Maxim Ostapenko wrote:
> Thanks, got it. Is it OK now?
Yes, thanks.
> 2014-01-10 Max Ostapenko
>
> * c-c++-common/asan/no-asan-stack.c: New test.
Jakub
Tom de Vries writes:
>> Why not just collect the usage information at
>> the end of final rather than at the beginning, so that all splits during
>> final have been done?
>
> If we have a call to a leaf function, the final rtl representation does not
> contain calls. The problem does not lie in
Ping
On Wed, Dec 18, 2013 at 4:28 PM, Andrey Turetskiy
wrote:
> Ping
>
> On Fri, Dec 13, 2013 at 3:09 PM, Andrey Turetskiy
> wrote:
>> Hi,
>> I've added option -foffload-target to specify target and options for
>> target compiler for offloading.
>> Please, have a look.
>>
>> --
>> Best regards,
Huacai Chen writes:
> For human-readability, I submit a patch to Linux kernel to display
> Loongson-2E/2F/3A in /proc/cpuinfo. But that break -march=native, this
> patch fix that.
Thanks, applied to trunk, 4.8 and 4.7 with a minor formatting tweak.
Richard
On Thu, Jan 9, 2014 at 9:06 PM, Richard Sandiford
wrote:
> I got an off-list request to backport the bswap patterns to 4.8.
> They've been in trunk for a while without any problems being reported
> and they should be relatively safe.
>
> Here's what I applied after testing on mips64-linux-gnu (wit
Hi,
>
> 2013-12-22 Eric Botcazou
>
> * gcc.target/arm/neon-nested-apcs.c: New test.
>
This new test fails when GCC is configured as target
arm-none-linux-gnueabihf and --with-float=hard:
tools/arm-none-linux-gnueabihf/bin/ld: error: ./neon-nested-apcs.exe
uses VFP register arguments, /tm
On 01/10/2014 12:36 PM, Jakub Jelinek wrote:
On Fri, Jan 10, 2014 at 12:34:49PM +0400, Maxim Ostapenko wrote:
Thanks, got it. Is it OK now?
Yes, thanks.
2014-01-10 Max Ostapenko
* c-c++-common/asan/no-asan-stack.c: New test.
Jakub
Commited in 206515.
-Maxim.
Richard Biener writes:
> On Thu, Jan 9, 2014 at 9:06 PM, Richard Sandiford
> wrote:
>> I got an off-list request to backport the bswap patterns to 4.8.
>> They've been in trunk for a while without any problems being reported
>> and they should be relatively safe.
>>
>> Here's what I applied after
Am 10.01.2014 09:23, schrieb Zhenqiang Chen:
> Hi,
>
> MULTIARCH_DIRNAME was removed @r196649 since the dir info had been
> combined in MULTILIB_OSDIRNAMES.
>
> But MULTIARCH_DIRNAME was re-added @r201164. With this change, the
> final multiarch_dir is combined as
> "aarch64-linux-gnu:aarch64-lin
On Mon, Dec 2, 2013 at 4:49 PM, Uros Bizjak wrote:
>>> Does it support using libbacktrace in GCC?
>>
>> Not on it's own, but the support in the upstream maintained files
>> is there, so hopefully it will be just a matter of follow-up patch
>> with configury/Makefile etc. stuff, I'll work on it on
On Fri, Jan 10, 2014 at 10:23:59AM +0100, Uros Bizjak wrote:
> I was able to compile sanitizer with r206475 (after Jakub's fixes) and
> run the testsuite. However, on 64bit target, I got some failures in
> asan and several timeouts in tsan [1].
Some of the tsan tests seems to FAIL randomly for qui
> This new test fails when GCC is configured as target
> arm-none-linux-gnueabihf and --with-float=hard:
> tools/arm-none-linux-gnueabihf/bin/ld: error: ./neon-nested-apcs.exe
> uses VFP register arguments, /tmp/cc9LLqES.o does not
> tools/arm-none-linux-gnueabihf/bin/ld: failed to merge target spe
On 10 January 2014 17:23, Matthias Klose wrote:
> Am 10.01.2014 09:23, schrieb Zhenqiang Chen:
>> Hi,
>>
>> MULTIARCH_DIRNAME was removed @r196649 since the dir info had been
>> combined in MULTILIB_OSDIRNAMES.
>>
>> But MULTIARCH_DIRNAME was re-added @r201164. With this change, the
>> final multi
Hello,
We've [at least] 2 patterns with wrong conditions.
Bootstrapped.
AVX-512 testsuite more complicated.
Few tests are fail, and it seems that not because of
the patch. I am trying to find guilty commit.
Failing this tests: avx512f-vpmovsxbd-2.c and
other *-extension insns.
gcc/
* co
Hi all,
This patch will resolve testsuite/gcc.dg/pr44194-1.c failure observed in
aarch64 target by refining the second scan-rtl-dump-not pattern.
For aarch64 target, the following barrier is generated which will
exactly match the current pattern
"insn \[^\n\]*set \\(mem". This is undesired. B
> This patch will resolve testsuite/gcc.dg/pr44194-1.c failure observed in
> aarch64 target by refining the second scan-rtl-dump-not pattern.
>
> For aarch64 target, the following barrier is generated which will
> exactly match the current pattern
> "insn \[^\n\]*set \\(mem". This is undesired. By
Am 10.01.2014 10:49, schrieb Zhenqiang Chen:
> On 10 January 2014 17:23, Matthias Klose wrote:
>> Am 10.01.2014 09:23, schrieb Zhenqiang Chen:
>>> Hi,
>>>
>>> MULTIARCH_DIRNAME was removed @r196649 since the dir info had been
>>> combined in MULTILIB_OSDIRNAMES.
>>>
>>> But MULTIARCH_DIRNAME was r
On Thu, Jan 9, 2014 at 11:00 PM, Steve Ellcey wrote:
> Some header files needed by plugins are not present in the installed plugin
> include directory. This patch adds those headers. I added all the headers
> I needed for my plugin plus the ones mentioned in the patch. I did not add
> the x86 s
On 10 Jan 13:07, Kirill Yukhin wrote:
> Few tests are fail, and it seems that not because of
> the patch. I am trying to find guilty commit.
I filed PR59754 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59754)
--
Thanks, K
On Fri, Jan 10, 2014 at 11:07 AM, Kirill Yukhin wrote:
> Hello,
> We've [at least] 2 patterns with wrong conditions.
>
> Bootstrapped.
>
> AVX-512 testsuite more complicated.
> Few tests are fail, and it seems that not because of
> the patch. I am trying to find guilty commit.
>
> Failing this tes
On Fri, Jan 10, 2014 at 10:39 AM, Jakub Jelinek wrote:
> On Fri, Jan 10, 2014 at 10:23:59AM +0100, Uros Bizjak wrote:
>> I was able to compile sanitizer with r206475 (after Jakub's fixes) and
>> run the testsuite. However, on 64bit target, I got some failures in
>> asan and several timeouts in tsa
Hi Eric,
Thank you for your suggestion!
I have made the adjustment and test it. Please check the new attachment.
Regards,
Renlin Li
On 10/01/14 10:42, Eric Botcazou wrote:
This patch will resolve testsuite/gcc.dg/pr44194-1.c failure observed in
aarch64 target by refining the second scan-rtl-du
On 09/01/14 17:34, Kyrill Tkachov wrote:
> Hi all,
>
> After my CRC32 intrinsics patch that added new entries into the bdesc_2arg
> table, the arm_init_iwmmxt_builtins function tries to iterate over them and
> blows up, causing an ICE when trying to compile with -mcpu=iwmmxt.
>
> This patch fix
On 09/01/14 17:02, Kyrill Tkachov wrote:
> Hi all,
>
> When adding the testsuite options for the crypto tests we need to make sure
> that
> don't end up adding -mfloat-abi=softfp to a hard-float target like
> arm-none-linux-gnueabihf. This patch adds that code to figure out which
> -mfpu/-mflo
On 09/01/14 17:37, Kyrill Tkachov wrote:
> Hi all,
>
> The Cortex-A53 and Cortex-A57 processors support the CRC32 extensions to
> ARMv8-a, so we specify that in their definitions in arm-cores.def.
> This also updates their big.LITTLE amalgamation and removes the redundant
> FL_THUMB_DIV and FL_A
On 09/01/14 17:42, Kyrill Tkachov wrote:
> Hi all,
>
> SET RTXs don't have a mode, so the code to calculate a reg-to-reg set in the
> arm
> rtx costs function needs to get the mode from one of the registers involved.
> We
> already did that when the source is a CONST_INT.
>
> This patch fixes
On 09/01/14 20:42, Tom de Vries wrote:
> On 09-01-14 15:41, Richard Earnshaw wrote:
>> On 30/03/13 16:10, Tom de Vries wrote:
>>> On 29/03/13 13:54, Tom de Vries wrote:
I split the patch up into 10 patches, to facilitate further review:
...
0001-Add-command-line-option.patch
000
On 10/01/14 09:46, Eric Botcazou wrote:
>> This new test fails when GCC is configured as target
>> arm-none-linux-gnueabihf and --with-float=hard:
>> tools/arm-none-linux-gnueabihf/bin/ld: error: ./neon-nested-apcs.exe
>> uses VFP register arguments, /tmp/cc9LLqES.o does not
>> tools/arm-none-linux
Hi!
Ping.
On Thu, 19 Dec 2013 17:49:09 +0100, I wrote:
> Ping.
>
> On Tue, 10 Dec 2013 13:53:39 +0100, I wrote:
> > At the end of this email you can find the patch that I'd like to apply to
> > gomp-4_0-branch for OpenACC structured blocks, after the following two
> > have been approved:
>
> >
Hi all,
On Fri, Jan 10, 2014 at 10:39 AM, Jakub Jelinek wrote:
> Some of the tsan tests seems to FAIL randomly for quite a while
> (since they were added), didn't have time to look if it is just bugs
in the test or
> some compiler issue or library issue.
When I've commited these tsan tests,
Hi!
Ping.
On Thu, 19 Dec 2013 17:44:25 +0100, I wrote:
> Ping.
>
> On Fri, 13 Dec 2013 11:13:03 +0100, I wrote:
> > On Thu, 5 Sep 2013 18:11:05 +0200, Jakub Jelinek wrote:
> > > 4) the reference testcase showed a problem with fold_stmt calls
> > > we do very early, during gimplification, becaus
> Some tests can do it because they don't produce an executable.
OK, there is some related dg-skip-if magic in 20090811-1.c, maybe Christophe
can try that too.
--
Eric Botcazou
Hi!
Ping, after another month. I've only received a private note from one
build machinery manintainer who found this beyond his level of expertise,
and wished me luck to find someone else to review. Any takers in the new
year?
On Sat, 14 Dec 2013 13:12:28 +0100, I wrote:
> Ping, after another m
On 10/01/14 11:48, Eric Botcazou wrote:
>> Some tests can do it because they don't produce an executable.
>
> OK, there is some related dg-skip-if magic in 20090811-1.c, maybe Christophe
> can try that too.
>
Can you not use (or add something similar to) { dg-add-options arm_neon }?
R.
On Fri, Jan 10, 2014 at 12:51:10PM +0100, Thomas Schwinge wrote:
> > > +static bool
> > > +maybe_fold_stmt (gimple_stmt_iterator *gsi)
> > > +{
> > > + bool changed = false;
> > > + struct gimplify_omp_ctx *ctx;
> > > + for (ctx = gimplify_omp_ctxp; ctx; ctx = ctx->outer_context)
> > > +if (
Dependence analysis in the vectorizer assumes that all references
take part in vectorization - which is of course the case for
loop-based vectorization. For BB vectorization unrelated DRs
can be inbetween vectorized stmts though. The original fix
properly verified that when accounting DDRs that
> Can you not use (or add something similar to) { dg-add-options arm_neon }?
Probably, yes, something like:
/* { dg-do run } */
/* { dg-require-effective-target arm_neon_hw } */
/* { dg-options "-fno-omit-frame-pointer -mapcs-frame -O" } */
/* { dg-add-options arm_neon } */
--
Eric Botcazou
Hello,
This patch unrolls string compare for length < 8 and residual bytes
after the word at a time loops (with cmp/str), using base+offset
addressing mode.
It also allows the builtin to be inlined for non-constant lengths.
No new regressions. Upgraded test case to handle former case.
OK for tru
Christian Bruel wrote:
> This patch unrolls string compare for length < 8 and residual bytes
> after the word at a time loops (with cmp/str), using base+offset
> addressing mode.
> It also allows the builtin to be inlined for non-constant lengths.
>
> No new regressions. Upgraded test case to han
On 10/01/14 12:28, Eric Botcazou wrote:
>> Can you not use (or add something similar to) { dg-add-options arm_neon }?
>
> Probably, yes, something like:
>
> /* { dg-do run } */
> /* { dg-require-effective-target arm_neon_hw } */
> /* { dg-options "-fno-omit-frame-pointer -mapcs-frame -O" } */
> /
Three documentation bugs fixed by the attached patches
2014-01-10 Jonathan Wakely
PR libstdc++/59698
* doc/xml/manual/status_cxx1998.xml (iso.1998.specific): Markup
and stylistic improvements.
* doc/xml/manual/codecvt.xml (std.localization.facet.codecvt): Likewise
and updat
On Fri, Jan 10, 2014 at 10:23 AM, Uros Bizjak wrote:
> On Mon, Dec 2, 2013 at 4:49 PM, Uros Bizjak wrote:
>
Does it support using libbacktrace in GCC?
>>>
>>> Not on it's own, but the support in the upstream maintained files
>>> is there, so hopefully it will be just a matter of follow-up pa
Hi,
with the attached patch the jump over the extraction of CC into a GPR
for the good case (CC0) is removed. Starting with tbegin being
flagged as "returns_twice" this generates slow code and prevents the
backend optimization for nonescaping transaction from working
correctly.
This fixes the fo
It's incorrect to use CMN to compare with a negated operand if the
following condition is an inequality. This is because of boundary
conditions when the negated operations overflow (or when zero), since
the flags are then not the swapped version of the comparison.
This patch restricts the pattern
On Fri, Jan 10, 2014 at 03:50:33PM +0400, Maxim Ostapenko wrote:
> On Fri, Jan 10, 2014 at 10:39 AM, Jakub Jelinek wrote:
>
> > Some of the tsan tests seems to FAIL randomly for quite a while
> > (since they were added), didn't have time to look if it is just
> bugs in the test or
> > some compil
> > /* { dg-do run } */
> > /* { dg-require-effective-target arm_neon_hw } */
> > /* { dg-options "-fno-omit-frame-pointer -mapcs-frame -O" } */
> > /* { dg-add-options arm_neon } */
>
> Yes, something like that.
OK, installed after checking that this doesn't change the test, thanks.
--
Eric Bo
Hello,
It seems that we miss few more intrinsics.
I've also added some missing substed predicates
Also I've fixed bogus rcp14 pattern and removeed
some redundant subst attributes.
Bootstrapped. New & existing tests pass (expcept
for those mentioned in PR about REE).
Is it ok for trunk?
gcc/
On Fri, Jan 10, 2014 at 07:20:38PM +0300, Kirill Yukhin wrote:
> @@ -28920,6 +28927,7 @@ static const struct builtin_description
> bdesc_special_args[] =
>{ OPTION_MASK_ISA_AVX512F, CODE_FOR_avx512f_movntv16sf,
> "__builtin_ia32_movntps512", IX86_BUILTIN_MOVNTPS512, UNKNOWN, (int)
> VOID_FTY
On 09-01-14 13:33, Richard Biener wrote:
On Thu, 9 Jan 2014, Tom de Vries wrote:
On 09-01-14 10:16, Richard Biener wrote:
This fixes PR59715 by splitting critical edges again before
code sinking. The critical edge splitting done before PRE
was designed to survive until sinking originally, bu
Hello,
It seems this patch causes several regressions in gfortran on ARM too:
gfortran.dg/default_format_1.f90
gfortran.dg/default_format_denormal_1.f90
gfortran.dg/fmt_bz_bn.f
gfortran.dg/fmt_read_bz_bn.f90
gfortran.dg/g77/f77-edit-t-in.f
gfortran.dg/list_read_4.f90
gfortran.dg/namelist_11.f
gfor
On 10-01-14 12:39, Richard Earnshaw wrote:
On 09/01/14 20:42, Tom de Vries wrote:
On 09-01-14 15:41, Richard Earnshaw wrote:
On 30/03/13 16:10, Tom de Vries wrote:
On 29/03/13 13:54, Tom de Vries wrote:
I split the patch up into 10 patches, to facilitate further review:
...
0001-Add-command-l
Hi,
expand_movstr is work fine when we don't define movstr pattern or
always expand it successfully, however it's will crash when if movstr
expand fail since expand_insn expect always expand successfully (it's
place a gcc_unreachable() when expand fail).
this patch use maybe_expand_insn instead o
On Fri, Jan 10, 2014 at 05:44:22PM +0100, Christophe Lyon wrote:
> It seems this patch causes several regressions in gfortran on ARM too:
> gfortran.dg/default_format_1.f90
> gfortran.dg/default_format_denormal_1.f90
> gfortran.dg/fmt_bz_bn.f
> gfortran.dg/fmt_read_bz_bn.f90
> gfortran.dg/g77/f77-e
On 10 January 2014 17:45, Jakub Jelinek wrote:
> On Fri, Jan 10, 2014 at 05:44:22PM +0100, Christophe Lyon wrote:
>> It seems this patch causes several regressions in gfortran on ARM too:
>> gfortran.dg/default_format_1.f90
>> gfortran.dg/default_format_denormal_1.f90
>> gfortran.dg/fmt_bz_bn.f
>>
On 01/09/2014 03:34 PM, Jakub Jelinek wrote:
> 2014-01-09 Jakub Jelinek
>
> * target-globals.c (save_target_globals): Allocate < 4KB structs using
> GC in payload of target_globals struct instead of allocating them on
> the heap and the larger structs separately using GC.
>
On 10/01/14 17:37, Andrew Pinski wrote:
> On Fri, Jan 10, 2014 at 7:14 AM, Richard Earnshaw wrote:
>> It's incorrect to use CMN to compare with a negated operand if the
>> following condition is an inequality. This is because of boundary
>> conditions when the negated operations overflow (or when
On Fri, Jan 10, 2014 at 7:14 AM, Richard Earnshaw wrote:
> It's incorrect to use CMN to compare with a negated operand if the
> following condition is an inequality. This is because of boundary
> conditions when the negated operations overflow (or when zero), since
> the flags are then not the sw
On Fri, Jan 10, 2014 at 9:38 AM, Richard Earnshaw wrote:
> On 10/01/14 17:37, Andrew Pinski wrote:
>> On Fri, Jan 10, 2014 at 7:14 AM, Richard Earnshaw wrote:
>>> It's incorrect to use CMN to compare with a negated operand if the
>>> following condition is an inequality. This is because of bound
This patch "fixes" a regression on trunk and the 4.8 branch:
Running /tmp/hpautotest-gcc48/gcc/gcc/testsuite/gcc.dg/dg.exp ...
...
FAIL: gcc.dg/pr46309.c scan-tree-dump-times reassoc2 "Optimizing range tests
[^\r\n]*_[0-9]* -.0, 31. and -.128, 159.[\n\r]* into" 1
The comment in the test seen in
Hi!
If folded_casts is true, sccp can introduce undefined behavior even when
there was none in the original loop, e.g. all actual additions performed in
unsigned type and then cast back to signed.
The following patch fixes that by turning the arithmetic stmts added by sccp
use unsigned operations
Hi!
The following patch attempts to improve both compile time and generated
code for array initializers if there are many consecutive same elements.
Without the patch even T1 instead of T10 takes a minute to compile
and generates hundreds of kilobytes large routine.
Without the patch, we
Hi!
split_data_refs_to_components used the name_expansions affine cache
through determine_offset, and since my patch uses it even more often,
but if it returns NULL, we don't free the cache and it can contain garbage
next time we perform tree_predictive_commoning_loop.
Bootstrapped/regtested on x
Hi!
The new REGNO != REGNO optimization assumes that a lowpart subreg of
the extended reg will be the value of the original expression.
But that is the case of only scalar integral modes, e.g. for vector
mode extensions a lowpart subreg will occupy just say half or even fewer
vector elements, but
On 01/10/14 13:45, Jakub Jelinek wrote:
Hi!
The new REGNO != REGNO optimization assumes that a lowpart subreg of
the extended reg will be the value of the original expression.
But that is the case of only scalar integral modes, e.g. for vector
mode extensions a lowpart subreg will occupy just sa
I happened to notice an obvious error in one of the builtin tables.
Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no
regressions. Committed as obvious.
Thanks,
Bill
2014-01-10 Bill Schmidt
* config/rs6000/rs6000-builtin.def: Fix pasto for VPKSDUS.
Index: gcc/con
As mentioned in the PR. We have a memory load and two extensions.
The first extension requires a copy because its source and destination
are not the same hard register.
The second extension does not require a copy and has a wider mode than
the first extension.
In this case we have to make
Hi,
this patch fixes checking ICE in the attached testcase that happens because we
end up
devirtualizing into a function that is not withing possible polymorphic call
target.
The defauled analysis is in the PR and also in comment bellow. The basic
problem
is that we build type inheritance tree
This patch moves the LIPO linking before profile annotation so that
iterative-early-inline can cover functions from aux-module.
Bootstrapped and passed regression test and benchmark test.
OK for google-4_8?
Thanks,
Dehao
Index: gcc/auto-profile.c
On Fri, Jan 10, 2014 at 02:36:47PM -0700, Jeff Law wrote:
> As mentioned in the PR. We have a memory load and two extensions.
>
> The first extension requires a copy because its source and
> destination are not the same hard register.
>
> The second extension does not require a copy and has a wi
As mentioned in the PR, we have a case where within a block the reaching
def (defining insn) occurs after the use (extension insn). This
obviously can only happen in a loop and AFAICT should only happen for an
uninitialized use.
Anyway, in this situation we'd segfault in reg_used_between_p
On Fri, Jan 10, 2014 at 02:58:59PM -0700, Jeff Law wrote:
> +2014-01-10 Jeff Law
> +
> + PR middle-end/59743
> + * ree.c (combine_reaching_defs): Ensure the defining statement
> + occurs before the extension when optimizing extensions with
> + different source and destination har
On 01/10/14 15:03, Jakub Jelinek wrote:
On Fri, Jan 10, 2014 at 02:58:59PM -0700, Jeff Law wrote:
+2014-01-10 Jeff Law
+
+ PR middle-end/59743
+ * ree.c (combine_reaching_defs): Ensure the defining statement
+ occurs before the extension when optimizing extensions with
+
Hi,
This patch adds PROCESSOR_INTEL, which is almost identical to
PROCESSOR_SILVERMONT, except that __tune_slm__/__tune_silvermont__
aren't defined for -mtune=intel. OK for trunk?
Thanks.
H.J.
---
2014-01-10 H.J. Lu
* config/i386/i386-c.c (ix86_target_macros_internal): Handle
On 01/10/14 14:52, Jakub Jelinek wrote:
There is one thing I still worry about, if some target has
an insn to say sign extend or zero extend a short memory load
into HARD_REGNO_NREGS () > 1 register, but the other involved
register has the only one (or fewer) hard registers available to it.
Cons
Ok.
David
On Fri, Jan 10, 2014 at 1:50 PM, Dehao Chen wrote:
> This patch moves the LIPO linking before profile annotation so that
> iterative-early-inline can cover functions from aux-module.
>
> Bootstrapped and passed regression test and benchmark test.
>
> OK for google-4_8?
>
> Thanks,
> De
[Sorry for dropping the ball here]
> I think that may_be_unaligned_p is just seriously out-dated ... shouldn't it
> be sth like
>
> get_object_alignment_1 (ref, &align, &bitpos);
> if step * BITS_PER_UNIT + bitpos is misaligned
> ...
>
> or rather all this may_be_unaligned_p stuff should be
On Jan 10, 2014, at 11:26 AM, Hans-Peter Nilsson
wrote:
> This patch "fixes" a regression on trunk and the 4.8 branch:
> Index: gcc/testsuite/gcc.dg/pr46309.c
> ===
> --- gcc/testsuite/gcc.dg/pr46309.c(revision 206534)
> +++ gcc
> From: Mike Stump
> Date: Sat, 11 Jan 2014 01:55:09 +0100
> On Jan 10, 2014, at 11:26 AM, Hans-Peter Nilsson
> wrote:
> > This patch "fixes" a regression on trunk and the 4.8 branch:
>
> > Index: gcc/testsuite/gcc.dg/pr46309.c
> > ==
80 matches
Mail list logo
