"Steve Ellcey " writes:
> diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md
> index 397c40a..ad03040 100644
> --- a/gcc/config/mips/mips.md
> +++ b/gcc/config/mips/mips.md
> @@ -6674,7 +6674,10 @@
> {
>if (TARGET_LOONGSON_2EF || TARGET_LOONGSON_3A)
> /* Loongson 2[ef] and Lo
Hi!
On the following (nonsensical) testcase we ICE because of pointer type
mismatch. Fixed thusly, bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk/4.8?
2013-08-13 Jakub Jelinek
PR sanitizer/56417
* asan.c (instrument_strlen_call): Fix typo in comment.
Hi!
On the following testcase we ICE because we have an indirect (MEM_REF)
clobber stmt that uses anonymous SSA_NAME. ipa-split.c (intentionally)
ignores clobber stmts because they don't result in executable code,
but that can lead into clobber stmts mentioning SSA_NAMEs that aren't
initialized.
On Mon, 12 Aug 2013 12:04:45 -0400
David Edelsohn wrote:
> * config/rs6000/rs6000.c (rs6000_legitimize_reload_address): Don't
> perform invalid legitimization on greater-than-word-size modes for
> TARGET_E500_DOUBLE.
>
> Disabling greater-than-word-size for E500v2 instead of continua
On Mon, Aug 12, 2013 at 10:56:44AM +0200, Marek Polacek wrote:
> On Fri, Aug 09, 2013 at 08:40:00PM +0200, Richard Biener wrote:
> > Marek Polacek wrote:
> > >In this PR the problem was that when dealing with the gimple assign in
> > >the tailcall optimization, we, when the rhs operand is of a vec
This is a rather unusual situation where a pragma Shared is put on a packed
array. In this case, we generate wrong code for array accesses on BE targets.
Tested on x86_64-suse-linux, applied on the mainline.
2013-08-13 Eric Botcazou
* gcc-interface/utils2.c (build_atomic_load): Do
On Tue, Aug 13, 2013 at 12:24:59PM +0200, Jakub Jelinek wrote:
> On Mon, Aug 12, 2013 at 10:56:44AM +0200, Marek Polacek wrote:
> > On Fri, Aug 09, 2013 at 08:40:00PM +0200, Richard Biener wrote:
> > > Marek Polacek wrote:
> > > >In this PR the problem was that when dealing with the gimple assign
Jakub Jelinek writes:
> Hi!
>
> On the following (nonsensical) testcase we ICE because of pointer type
> mismatch. Fixed thusly, bootstrapped/regtested on x86_64-linux and
> i686-linux, ok for trunk/4.8?
>
> 2013-08-13 Jakub Jelinek
>
> PR sanitizer/56417
> * asan.c (instrument_st
Hi Iyer,
>First off, my sincerest apologies for letting this bug slip the cracks. I
> am attaching a patch that seem to work fine with the .i file that you have
> submitted in bugzilla for both C and C++. Please let me know if this fix
> works for you and if it is OK for trunk.
thanks for
On Tue, Aug 13, 2013 at 12:24:59PM +0200, Jakub Jelinek wrote:
> On Mon, Aug 12, 2013 at 10:56:44AM +0200, Marek Polacek wrote:
> > On Fri, Aug 09, 2013 at 08:40:00PM +0200, Richard Biener wrote:
> > > Marek Polacek wrote:
> > > >In this PR the problem was that when dealing with the gimple assign
On Tue, Aug 13, 2013 at 01:51:27PM +0200, Marek Polacek wrote:
> Sure. Ok to apply this one if it passes regtesting?
Yes, thanks.
> 2013-08-13 Marek Polacek
> Jakub Jelinek
>
> PR tree-optimization/57980
> * tree-tailcall.c (process_assignment): Return false
> w
On Tue, Aug 13, 2013 at 12:27:26PM +0200, Jakub Jelinek wrote:
> Also, for the testcase,
> typedef int V __attribute__ ((vector_size (sizeof (int;
> looks weird, that is one element vector, can you use 2 * sizeof (int)
> instead and add -w to dg-options (for the various -Wpsabi warnings)?
Ok,
When doing bootstrap with -fsanitize=undefined, I noticed undefined
behavior in this file. We basically do 1 << 32, since NUM_CONDITIONS
is #defined to 32, which is not defined. I admit I didn't followed
the algorithm at all, but this patch passed bootstrap + regtesting
on x86_64-linux. So, ok f
Ping.
On 23 July 2013 16:18, Yvan Roux wrote:
> Hi,
>
> I forgot to add the test case with the PR fix, the attached patch add it.
>
> Thanks,
> Yvan
>
> ChangeLog
>
> gcc/testsuite
>
> 2013-07-23 Yvan Roux
>
> PR target/57909
> * gcc.target/arm/pr57909.c: New test.
>
>
> On 17
On 08/12/2013 07:52 PM, Adam Butcher wrote:
Presumably with pedwarn it would need to be relaxed to simply
"accepted with -std=c++1y or -std=gnu++1y"
for all?
Yes.
flag_iso was the only thing I could find to discriminate
between gnu++1y and c++1y?
Right, we don't make that distinction fo
On Mon, Aug 12, 2013 at 01:01:46PM +0100, Andrew Haley wrote:
> I think this one is obvious/trivial, but I'll ask anyway.
>
> OK?
To 4.8? Sure.
> 2013-08-12 Andrew Haley
>
> Backport from mainline:
> * 2013-07-11 Andreas Schwab
>
> * config/aarch64/aarch64-linux.h (CPP
> -Original Message-
> From: Rainer Orth [mailto:r...@cebitec.uni-bielefeld.de]
> Sent: Tuesday, August 13, 2013 7:18 AM
> To: Iyer, Balaji V
> Cc: Jakub Jelinek; gcc-patches@gcc.gnu.org; Marek Polacek
> (pola...@redhat.com)
> Subject: Re: [PATCH] Fix for PR c/57490
>
> Hi Iyer,
>
> >
Hi,
I have realised a double escape is required in scan-assembler patterns
for special characters to match literally. Additionally I've noticed a
couple escapes missing altogether. There are no regressions with the
mips-linux-gnu target and the change below. OK to apply?
2013-08-13 Maciej
On Wed, 7 Aug 2013, Richard Sandiford wrote:
> > When I run two of your new tests in gcc.target/mips (nan-legacy.c and
> > nans-legacy.c), they are failing because my GCC is putting out
> >
> > .word 4294967295
> >
> > instead of
> >
> > .word -1
> >
> > like the test is expecting.
>
Hi Iyer,
>> thanks for the patch. I've just bootstrapped it on i386-pc-solaris2.10
>> and all an-
>> if.c failures are gone. That said, I wonder why we need the separate
>> pr57490.c
>> testcase, which is practically a preprocessed version of an-if.c with the
>> HAVE_IO
>> code removed.
>
> Well
> -Original Message-
> From: Rainer Orth [mailto:r...@cebitec.uni-bielefeld.de]
> Sent: Tuesday, August 13, 2013 9:38 AM
> To: Iyer, Balaji V
> Cc: Jakub Jelinek; gcc-patches@gcc.gnu.org; Marek Polacek
> (pola...@redhat.com)
> Subject: Re: [PATCH] Fix for PR c/57490
>
> Hi Iyer,
>
> >>
Hi,
I'm trying to have a possibility to dynamically choose between
compatible multilibs (see thread
http://gcc.gnu.org/ml/gcc/2013-08/msg00114.html) if preferred one is
missing. It would allow me to configure MPX binaries to link with MPX
library if such library exists and use non-MPX library vers
On Mon, Aug 12, 2013 at 8:49 PM, Gerald Pfeifer wrote:
>> Does this also deserve a news post? I certainly found it to be
>> interesting news!
>
> Sure. Want to add one, David?
I am adding the following to News:
diff -c -p -r1.888 index.html
*** index.html 12 Aug 2013 00:01:45 - 1.888
On Wed, 7 Aug 2013, Richard Sandiford wrote:
> > BTW, what's the "Check for MicroMIPS support." note seen in the
> > config.host piece of the patch referring to?
>
> No idea, please remove it.
I have committed the change below.
2013-08-13 Maciej W. Rozycki
libgcc/
* confi
>
> On 08/09/13 11:01, Julian Brown wrote:
> > On Thu, 8 Aug 2013 15:44:17 +0100
> > Kyrylo Tkachov wrote:
> >
> >> Hi all,
> >>
> >> The recently added gcc.target/arm/pr58041.c test exposed a bug in the
> >> backend. When compiling for NEON and with -mno-unaligned-access we
> >> end up generatin
Jakub Jelinek wrote:
>Hi!
>
>On the following testcase we ICE because we have an indirect (MEM_REF)
>clobber stmt that uses anonymous SSA_NAME. ipa-split.c (intentionally)
>ignores clobber stmts because they don't result in executable code,
>but that can lead into clobber stmts mentioning SSA_NAM
On 08/13/13 15:57, Kyrylo Tkachov wrote:
On 08/09/13 11:01, Julian Brown wrote:
On Thu, 8 Aug 2013 15:44:17 +0100
Kyrylo Tkachov wrote:
Hi all,
The recently added gcc.target/arm/pr58041.c test exposed a bug in the
backend. When compiling for NEON and with -mno-unaligned-access we
end up gen
This is a regression present on all the active branches. The compiler
generates code that doesn't execute the expected number of iterations for a
loop with a dynamic upper bound whose value is exactly the upper bound of the
base index type and is obtained through a narrowing conversion.
Tested
ping ^3
Thanks,
Dehao
On Fri, Jul 26, 2013 at 6:15 PM, Dehao Chen wrote:
> ping^2
>
> Thanks,
> Dehao
>
> On Tue, Jul 16, 2013 at 5:40 PM, Dehao Chen wrote:
>> ping...
>>
>> Thanks,
>> Dehao
>>
>> On Mon, Jul 8, 2013 at 5:55 PM, Dehao Chen wrote:
>>> In lookup_stmt_eh_lp, negative return value
On Mon, Aug 12, 2013 at 10:07 AM, Caroline Tice wrote:
> On Mon, Aug 12, 2013 at 4:15 AM, Florian Weimer wrote:
>> On 08/12/2013 12:39 AM, Caroline Tice wrote:
>>>
>>> On Sun, Aug 11, 2013 at 1:04 PM, Florian Weimer
>>> wrote:
On 08/11/2013 01:08 AM, Caroline Tice wrote:
>
>
>>
The following patch has been backported into gcc-4_8-branch.
The patch was successfully tested and bootstrapped on x86/x86-64.
Committed as rev. 201695.
2013-08-13 Vladimir Makarov
Backport from mainline
2013-06-06 Vladimir Makarov
PR rtl-optimization/57459
Starting a new thread, based on the discussion from [PATCH/Merge
Request] Vtable Verification feature
I would like to start a new thread to discuss some of the issues here
(see snip from old thread below).
On Thu, Aug 8, 2013 at 4:01 PM, Joseph S. Myers wrote:
> On Thu, 8 Aug 2013, Caroline Tic
On Tue, 2013-08-13 at 14:28 +0100, Maciej W. Rozycki wrote:
> This has passed mips-linux-gnu regression testing on a 32-bit host, but I
> can't regression-test a 64-bit host easily -- Steve, can you please verify
> that this change indeed works for you? Richard, OK to apply assuming that
> it
"Maciej W. Rozycki" writes:
> 2013-08-13 Maciej W. Rozycki
>
> gcc/testsuite/
> * gcc.target/mips/fabs-2008.c: Correct scan-assembler pattern
> escapes.
> * gcc.target/mips/fabs-legacy.c: Likewise.
> * gcc.target/mips/fabsf-2008.c: Likewise.
> * gcc.target/m
"Maciej W. Rozycki" writes:
> I've had a look now and that is related to the width of `long' on the
> host -- encode_ieee_double returns its output 32-bit bit patterns in a
> buffer of signed longs. The arithmetic value of these patterns therefore
> depends on whether the width of `long' is 3
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"
>
> Not good, since _ITM_R{F,D,E,CF,CD,CE} should return values in
> floating point registers; similarly for the write acc
Xingxing Pan found a typo in IRA code. Here is the patch to fix it.
The patch was bootstrapped on x86/x86-64. I did not find code
generation difference on x86/x86-64, s390, ppc, and arm on variety
tests. The code might make some small difference on other targets though.
Committed as rev.
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"
>>
>> Not good, since _ITM_R{F,D,E,CF,CD,CE} should return values in
>> flo
This fixes an ICE on a call to a valued procedure that takes a converted
integer as actual parameter passed by reference.
Tested on x86_64-suse-linux, applied on the mainline.
2013-08-13 Eric Botcazou
* gcc-interface/trans.c (Call_to_gnu): Deal with specific conditional
expr
Hi!
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 for that in gcc and also teaches linker
about those, because o
This change ensures that conditional branch instructions that are generated
as part of the exception handling circuitry for cleanup actions are marked
specially, more precisely by clearing the column number. This makes it
possible for coverage analysis tools to properly ignore them, and ensures
Hi!
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 we wouldn't fall back into the -m32 handling
code which take
Tested on x86_64-suse-linux, applied on the mainline.
2013-08-13 Eric Botcazou
* gcc-interface/decl.c (gnat_to_gnu_entity): Replace True with true.
(is_cplusplus_method): Likewise, and False with false.
(components_need_strict_alignment): Likewise.
* gcc-interf
This disconnects a good chunk of the alias set circuitry in ASIS mode because
it was bypassing kludges put in place for this mode specifically.
Tested on x86_64-suse-linux, applied on the mainline.
2013-08-13 Eric Botcazou
* gcc-interface/decl.c (gnat_to_gnu_entity): Do not bother ab
Hi Joseph,
The fixed patch and the changelogs are attached in this
email(http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00758.html). I have
addressed your concerns below:
Thanks,
Balaji V. Iyer.
> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: Fr
Hello!
These two insns have implicit address operands, so when Pmode !=
word_mode (x32 with -maddress-mode=short) we have to instruct the
linker to emit 0x67 address override prefix.
The patch also changes *sse3_monitor pattern to emit mnemonic with
implicit operands, to avoid duplicating operand
Richi and everyone else who may be interested,
Congrats on your first child. They are a lot of fun, but are very
high maintenence.
Today we put up the wide-int branch for all to see and play with. See
svn+ssh://gcc.gnu.org/svn/gcc/branches/wide-int
At this point, we have completed testing it
On Tue, 13 Aug 2013, Richard Sandiford wrote:
> > gcc/testsuite/
> > * gcc.target/mips/fabs-2008.c: Correct scan-assembler pattern
> > escapes.
> > * gcc.target/mips/fabs-legacy.c: Likewise.
> > * gcc.target/mips/fabsf-2008.c: Likewise.
> > * gcc.target/mips/fabsf-legacy.c
On Tue, 13 Aug 2013, Richard Sandiford wrote:
> > I've had a look now and that is related to the width of `long' on the
> > host -- encode_ieee_double returns its output 32-bit bit patterns in a
> > buffer of signed longs. The arithmetic value of these patterns therefore
> > depends on whethe
> When doing bootstrap with -fsanitize=undefined, I noticed undefined
> behavior in this file. We basically do 1 << 32, since NUM_CONDITIONS
> is #defined to 32, which is not defined. I admit I didn't followed
> the algorithm at all, but this patch passed bootstrap + regtesting
> on x86_64-linux.
> It might be more flexible to represent the analysis results as a
> type/inheritance graph -- i.e. explicitly introduce inheritance edge
> class to capture the interitence relationship (offset, etc) between
> two class nodes. The 'method' should probably be augmented to include
Yep, that is gener
Jason,
I introduced an warning on ODR violations (i.e. when I hot two types that are
equivalent by my ODR code and have different canonical types). Unforutnately
this hits a false positives on template instantiations. Here my ODR code
apparently never sees the types of template parameters; just th
This patch fixes a problem with -fdebug-types-section and with
-gsplit-dwarf where the hash computation for the type signature
and for the DW_AT_dwo_id attribute may produce results that differ
from run to run. For dw_val_class_vec values (e.g., the const value
of a small struct), both hash computa
This patch is for the google/gcc-4_7 and google/gcc-4_8 branches.
It fixes a problem with -fdebug-types-section and with
-gsplit-dwarf where the hash computation for the type signature
and for the DW_AT_dwo_id attribute may produce results that differ
from run to run. For dw_val_class_vec values (
Hi,
I have attached a patch to fix PR57756. Description: The
following program,
__attribute__((always_inline,target("sse4.2")))
__inline int callee ()
{
return 0;
}
__attribute__((target("sse")))
__inline int caller ()
{
return callee();
}
does not generate an error and callee is inli
this patch fixes a wrong code generation issue in the i386 target, PR58105.
The i386 target has a feature that is called multi-versioned functions.
That is a function may have different implementations which are chosen based on
the cpuid information at runtime. That is done by a resolver function
Sorry, forgot to mention:
This patch has been bootstrapped and regression tested on i686-pc-linux-gnu.
> this patch fixes a wrong code generation issue in the i386 target, PR58105.
>
> The i386 target has a feature that is called multi-versioned functions.
> That is a function may have different i
I have committed the following change from Google 4.7 (which is a
typo-fix) as obvious.
saugustine@sterling: ~/gcc-google-4_8/gcc/gcc $ svn diff dwarf2out.c
Index: dwarf2out.c
===
--- dwarf2out.c (revision 201717)
+++ dwarf2out.c (wor
On 08/10/2013 02:16 PM, Caroline Tice wrote:
I would like to make the following changes to the MAINTAINERS file.
May I commit this?
-- Caroline Tice
cmt...@google.com
2013-08-10 Caroline Tice
* MAINTAINERS: Add myself as libvtv maintainer. Correct my email
address in the Write After Approv
Hi,
here is current patch that implements the inheritance graph construction and
reachable function lookup. I think I now understand binfos right. I added
record_binfo that basically does what get_binfo_at_offset does without
considering the offset (i.e. sort of get_binfo_at_any_offset) and I can
60 matches
Mail list logo
