Hi,
I've committed the attached patch which fixes PR 55718 by adding
support for GOTENT + constant to legitimize_pic_address in the S/390
backend.
The patch also does some rearrangements of the whole function in order
to avoid some duplicate code.
Bye,
-Andreas-
2013-01-10 Andreas Krebbel
On Wed, 9 Jan 2013, Eric Botcazou wrote:
> > This fixes PR55882 - set_mem_attributes_minus_bitpos misses to
> > account for the to-be applied bitpos when computing MEM_ALIGN.
> > It extracts alignment from 't' instead of &t - bitpos.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, bo
On Thu, 10 Jan 2013, Jakub Jelinek wrote:
> Hi!
>
> We weren't processing GIMPLE_ASMs that set complex SSA_NAMEs, which lead to
> SSA_NAMEs with NULL SSA_NAME_DEF_STMT, either leading to crashes or silent
> wrong code, depending on --enable-checking. Fixed thusly,
> bootstrapped/regtested on x86
I haven't heard any complaints about the caret diagnostics being
enabled by default, so I am tempted to think it will stay like it is
for GCC 4.8. This patch documents that and also the new -Wpedantic.
OK?
Cheers,
Manuel.
caret.diff
Description: Binary data
On Thu, 10 Jan 2013, Richard Biener wrote:
> On Wed, 9 Jan 2013, Eric Botcazou wrote:
>
> > > This fixes PR55882 - set_mem_attributes_minus_bitpos misses to
> > > account for the to-be applied bitpos when computing MEM_ALIGN.
> > > It extracts alignment from 't' instead of &t - bitpos.
> > >
> >
Hi Joel,
Well Doh!
The gcc-abi and 8byte multilib variants appeared to have
been added around 2012-11-20 by Nick Clifton. I think he
missed changing the ASM_SPEC in gcc/config/v850/rtems.h
when he added it. v850-rtems-gcc wasn't passing in the expected
cpu specification flags.
Nick.. how does
On Thu, Jan 10, 2013 at 6:15 AM, Jeff Law wrote:
>
> Gary Funck noted that vrp06.c has two tests with the same output. After
> further investigation it was clear that expected output strings were too
> lenient and were in fact masking a missed optimization.
>
> This patch tightens the expected ou
Hello!
>> This patch tightens the expected output from the vrp dump which has the side
>> effect of making each test's string unique. Obviously the masked failure is
>> xfailed.
>>
>> OK for the trunk?
>
> Hmm, but if the SSA versions are simply i_10 then i_.*0 will still match it
> the same? I
On Thu, 10 Jan 2013, Richard Biener wrote:
> On Thu, 10 Jan 2013, Richard Biener wrote:
>
> > On Wed, 9 Jan 2013, Eric Botcazou wrote:
> >
> > > > This fixes PR55882 - set_mem_attributes_minus_bitpos misses to
> > > > account for the to-be applied bitpos when computing MEM_ALIGN.
> > > > It extr
On Thu, Jan 10, 2013 at 11:07:26AM +0400, Konstantin Serebryany wrote:
> >> Our internal LLVM bots (Linux, Mac and Android) are also green, but
> >> since the changes are large something may potentially break on other
> >> platforms.
> >>
> >> Ok to commit?
Ok, but it would be nice if the prctl st
Hello Uros,
It seems I didn't sent a patch with last changes. Sorry if so.
Vladimir
2012-12-27 Vladimir Yakovlev :
> On Sun, Dec 30, 2012 at 5:05 PM, Vladimir Yakovlev
> wrote:
>> I fixed typos and added CalangeLog.
>>
>> 2012-12-27 Vladimir Yakovlev >
>> * config/i386/i386-c.c (i
On Thu, Jan 10, 2013 at 2:59 PM, Jakub Jelinek wrote:
> On Thu, Jan 10, 2013 at 11:07:26AM +0400, Konstantin Serebryany wrote:
>> >> Our internal LLVM bots (Linux, Mac and Android) are also green, but
>> >> since the changes are large something may potentially break on other
>> >> platforms.
>> >>
On Thu, Jan 10, 2013 at 12:12 PM, Vladimir Yakovlev
wrote:
> It seems I didn't sent a patch with last changes. Sorry if so.
>
> Vladimir
>
> 2012-12-27 Vladimir Yakovlev
> * config/i386/i386-c.c (ix86_target_macros_internal): New case.
> (ix86_target_macros_internal): Likew
On Thu, Jan 10, 2013 at 03:27:41PM +0400, Konstantin Serebryany wrote:
> > So, I'd guard the prctl call with additional
> > #ifdef PR_SET_NAME
>
> Ok.
> I'd prefer to guard the whole test with #if defined(__linux__) &&
> defined(PR_SET_NAME).
That is not sufficient. You can have PR_SET_NAME defi
On Thu, Jan 10, 2013 at 12:28:24PM +0100, Uros Bizjak wrote:
> On Thu, Jan 10, 2013 at 12:12 PM, Vladimir Yakovlev
> wrote:
>
> > It seems I didn't sent a patch with last changes. Sorry if so.
> >
> > Vladimir
> >
> > 2012-12-27 Vladimir Yakovlev at the end of line.
> >
> > * config
> Going over this what's strange as well is that we adjust MEM_SIZE
> with bitpos, too. At least when the MEM has non-BLKmode this
> means that MEMs mode and MEM_SIZE is inconsistent? Or how do
> a MEMs mode and MEM_SIZE relate?
Yes, the MEM attributes are incomplete/inconsistent between the cal
On Thu, Jan 10, 2013 at 03:57:44PM +0400, Konstantin Serebryany wrote:
> > That is not sufficient. You can have PR_SET_NAME defined in the headers,
> > but still the underlying kernel doesn't need to handle it.
> >
> Like this?
> http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/asan/tests
I think that PR55792 shows we still have locations in our IL
with BLOCKs that are not in the functions BLOCK tree which
will lead to hard to trigger GC issues with location/BLOCKs
merged into location_t now.
The following fixes one issue I noticed when writing a verifier
for locations. remove_un
On Thu, Jan 10, 2013 at 4:23 PM, Jakub Jelinek wrote:
> On Thu, Jan 10, 2013 at 03:57:44PM +0400, Konstantin Serebryany wrote:
>> > That is not sufficient. You can have PR_SET_NAME defined in the headers,
>> > but still the underlying kernel doesn't need to handle it.
>> >
>> Like this?
>> http:/
Hi,
On Thu, 10 Jan 2013, Eric Botcazou wrote:
> > Going over this what's strange as well is that we adjust MEM_SIZE
> > with bitpos, too. At least when the MEM has non-BLKmode this
> > means that MEMs mode and MEM_SIZE is inconsistent? Or how do
> > a MEMs mode and MEM_SIZE relate?
>
> Yes, th
Hi,
It all begun with discussion here
http://gcc.gnu.org/ml/gcc/2012-11/msg00205.html
Since -fpic option is turned on by default in Android we have certain test
fails. The reason for that is that those tests rely on the
availability of functions, defined in them
and with -fpic compiler conservat
On Thu, 10 Jan 2013, Michael Matz wrote:
> Hi,
>
> On Thu, 10 Jan 2013, Eric Botcazou wrote:
>
> > > Going over this what's strange as well is that we adjust MEM_SIZE
> > > with bitpos, too. At least when the MEM has non-BLKmode this
> > > means that MEMs mode and MEM_SIZE is inconsistent? Or
Rainer Orth writes:
> 2013-01-08 Rainer Orth
>
> * g++.dg/tls/thread_local-cse.C: Don't xfail on *-*-solaris2.9.
> Add tls options.
> * g++.dg/tls/thread_local2.C: Likewise.
> * g++.dg/tls/thread_local2g.C: Likewise.
> * g++.dg/tls/thread_local6.C: Likewise.
>
Committed as obvious (leaves a single caller of
set_mem_attributes_minus_bitpos).
Richard.
2013-01-10 Richard Biener
* builtins.c (expand_builtin_init_trampoline): Use
set_mem_attributes.
Index: gcc/builtins.c
=
On Thu, Jan 10, 2013 at 2:50 PM, Alexander Ivchenko wrote:
> Hi,
>
> It all begun with discussion here
> http://gcc.gnu.org/ml/gcc/2012-11/msg00205.html
>
> Since -fpic option is turned on by default in Android we have certain test
> fails. The reason for that is that those tests rely on the
> av
On Tue, Jan 08, 2013 at 08:48:52PM +, Richard Sandiford wrote:
> Tested on x86_64-linux-gnu. OK to install?
Ok, thanks.
Jakub
Hello,
for the case:
[...]
use select_precision, only: wp => dp
interface
subroutine ode_derivative(x)
import :: wp
[...]
`wp' is currently imported in the subroutine namespace under its
original name `dp', which leads to an error if one tries to use `w
Gabriel Dos Reis writes:
> I read your reply. I am now even more puzzled
> than before. The call to uses_template_parm indicates that
> we expect that code to work when are also when processing a template
> (e.g. for non-dependent cases inside a template.)
> That makes me wonder how it could po
The following is what I use to track down PR55792 - it adds verification
that the GIMPLE IL only contains references to BLOCKs that are part
of the functions BLOCK tree. Otherwise BLOCKs lack a reference that is
seen by the garbage collector and funny things can happen.
It probably should also s
On Thu, Jan 10, 2013 at 11:01:30AM +0400, Konstantin Serebryany wrote:
> Hi,
>
> The attached patch is the libsanitizer merge from upstream r171973.
>
> Lots of changes. Among other things:
> - slow CFI-based unwinder (off by default for now)
> - more interceptors in asan (read, pread, etc)
>
On Thu, Jan 10, 2013 at 04:36:26PM +0100, Richard Biener wrote:
>
> The following is what I use to track down PR55792 - it adds verification
> that the GIMPLE IL only contains references to BLOCKs that are part
> of the functions BLOCK tree. Otherwise BLOCKs lack a reference that is
> seen by the
On Thu, 10 Jan 2013, Jakub Jelinek wrote:
> On Thu, Jan 10, 2013 at 04:36:26PM +0100, Richard Biener wrote:
> >
> > The following is what I use to track down PR55792 - it adds verification
> > that the GIMPLE IL only contains references to BLOCKs that are part
> > of the functions BLOCK tree. Ot
On Thu, Jan 10, 2013 at 9:22 AM, Dodji Seketeli wrote:
>
> Also, I am not sure if this patch would be appropriate for commit, now
> that we are in 'regression-only' mode. But seeing this alias-template
> related thing not working hurts me. :) So at worst I'll schedule the
> patch for when stage
On Thu, Jan 10, 2013 at 9:22 AM, Dodji Seketeli wrote:
> But during the instantiation of the *members* of test, we try to
> instantiate Alias>, without coercing (and thus without
> folding) the argument {the_truth}. We do this using
> instantiate_alias_template, called from tsubst.
>
> The patch
On 01/10/2013 03:31 AM, Uros Bizjak wrote:
Hello!
This patch tightens the expected output from the vrp dump which has the side
effect of making each test's string unique. Obviously the masked failure is
xfailed.
OK for the trunk?
Hmm, but if the SSA versions are simply i_10 then i_.*0 will
Hi,
This patch updates the top-level configuration files to explicitly set
libgloss_dir to aarch64 for aarch64*-*-* targets.
OK to commit?
Thanks,
Yufeng
2013-01-10 Yufeng Zhang
* configure.ac: Set libgloss_dir for the aarch64*-*-* targets.
* configure: Regenerated.diff -
This removes a couple of left-overs from the pre toplevel bootstrap era.
No functional changes. This paves the way for a real change that we want to
enable for the 4.8.0 release.
Tested on x86_64-suse-linux (w and w/o --disable-bootstrap), applied on the
mainline.
2013-01-10 Eric Botcazou
On 01/10/2013 03:13 AM, Richard Biener wrote:
Hmm, but if the SSA versions are simply i_10 then i_.*0 will still match it
the same? I think you want the more elaborate 'i_\[0-9\]* . 0' here?
Per Uros's suggestion I'm using i[0-9]+ to ensure we one or more digits.
Please also open a bug for
On 01/10/2013 11:11 AM, Gabriel Dos Reis wrote:
Hmm, is it necessary to coerce all levels as opposed to just the
innermost arguments?
No. But if you read the code, it's really only coercing the innermost
level. Just the name is misleading.
If this approach looks acceptable, could I replac
Apparently a .gitignore file was added to the gdb repository a while
back, and I think it makes sense for it to be in the gcc repository as
well. I made a few edits to avoid ignoring things that are actually
part of the gcc repository; this isn't strictly necessary, as the ignore
file only app
The following patch fixes (?) PR55833 by recomputing irreducible loops
after every unswitch-transformation. With this testcase, when we perform
loop unswitching on the RTL level, we end up in situation where we have
a loop into which we get through loop exit of another loop which is
a part of an i
On Thu, Jan 10, 2013 at 6:31 PM, Marek Polacek wrote:
> + /* We changed the CFG. Recompute irreducible BBs and edges. */
> + mark_irreducible_loops ();
This is a very expensive fix for a really unusual situation.
I don't think this is the right thing to do...
Ciao!
Steven
I have a long diatribe on the PR as to why the current generated code is
correct, and more optimal than when the test used to "pass". Bottom
line is that we now perform less branches and less loads/stores, at the
expense of one register to register move.
http://gcc.gnu.org/bugzilla/sh
> The problem with this intermediate inconsistency is that ...
>
> > That's why only the final result should matter and need be correct.
>
> ... this can't be ensured anymore. In some cases the inconsistency
> between the mem attributes and what XEXP(MEM, 0) represents can't be
> repaired by the
Hi,
AFAIU the regexps, they are not doing what they are supposed to do
on powerpc-apple-darwin9: the assembly reads
fmr f1,f0
i.e., fmr \[0-9\]+ or fmr 1 are never found.
If I use "fmr f?\[0-9\]+,f?\[0-9\]+", then the test fails,
in line with the other powerpc.
If I use "lfd \(f?\[0-9\]
On 01/10/2013 03:13 AM, Richard Biener wrote:
On Thu, Jan 10, 2013 at 6:15 AM, Jeff Law wrote:
Gary Funck noted that vrp06.c has two tests with the same output. After
further investigation it was clear that expected output strings were too
lenient and were in fact masking a missed optimizatio
Ping! (What do we do with this little bugger?)
@Paul: Was your comment 19 in the PR meant as an OK for my patch
(submitted here: http://gcc.gnu.org/ml/fortran/2012-12/msg00097.html),
or was it just a general agreement with the previous comments?
Cheers,
Janus
2012/12/16 Janus Weil :
> Hi Tobia
On 01/10/13 12:58, Dominique Dhumieres wrote:
Hi,
AFAIU the regexps, they are not doing what they are supposed to do
on powerpc-apple-darwin9: the assembly reads
fmr f1,f0
i.e., fmr \[0-9\]+ or fmr 1 are never found.
If I use "fmr f?\[0-9\]+,f?\[0-9\]+", then the test fails,
in line w
On Wed, Jan 9, 2013 at 12:34 AM, Tobias Burnus wrote:
> Janne Blomqvist worte:
>>
>> On Sun, Jan 6, 2013 at 6:52 PM, Tobias Burnus wrote:
>>>
>>> >Attached is a small variation, which in addition handles the case that a
>>>
>>> >non-BOOL_C LOGICAL, Bind(C) dummy argument (or result variable) is u
Hello!
As mentioned by Andrew is PR, reload can't handle jump_insns. Expand
with %eax hard register temporary to avoid this limitation.
2012-01-10 Uros Bizjak
PR target/55929
* config/i386/i386.md (xbegin): Use %eax as a temporary register.
Bootstrapped and regression tested
On Thu, Jan 10, 2013 at 01:40:09PM -0600, Aldy Hernandez wrote:
> commit 61ceeb130c2c2c342f19e716397ffddd212a0b32
> Author: Aldy Hernandez
> Date: Thu Jan 10 11:58:37 2013 -0600
>
> PR target/55565
> * gcc.target/powerpc/ppc-mov-1.c: Update scan-assembler-not
> regex.
Ok with
> PS. IIRC some previous discussions around such darwin peculiarities
> the f? decoration may be too simplistic to cover all the powerpc
> flavors (A. Pinski may know better).
I have found the links for that: r168960 (pr41146). A. Pinski asked to
add %?. I don't know which ppc platform uses it and
On Thu, Jan 10, 2013 at 11:57 AM, Dominique Dhumieres
wrote:
>> PS. IIRC some previous discussions around such darwin peculiarities
>> the f? decoration may be too simplistic to cover all the powerpc
>> flavors (A. Pinski may know better).
>
> I have found the links for that: r168960 (pr41146). A.
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55672
The patch was successfully tested and bootstrapped on x86-64 (with and
without -fstack-check=generic).
Committed as rev. 195095.
2013-01-10 Vladimir Makarov
PR rtl-optimization/pr55672
* lra-elimi
Hi
Here is an other version of this patch. Indeed there were no need
to expose many stuff public. Inheriting from _Hash_code_base is fine, it
is not final and it deals with EBO itself. I only kept usage of
_Hashtable_ebo_helper when embedding H2 functor. As it is an extension
we could hav
Hi,
> On Thu, Jan 10, 2013 at 6:31 PM, Marek Polacek wrote:
> > + /* We changed the CFG. Recompute irreducible BBs and edges. */
> > + mark_irreducible_loops ();
>
> This is a very expensive fix for a really unusual situation.
>
> I don't think this is the right thing to do...
I agree -- at
Hello Jeff,
> If you're using something from the Cygnus port, then it would be covered
> by the blanket copyright assignment Cygnus had in place with the FSF.
> If there are any doubts about the origin of a hunk of GCC code I could
> probably pull out the old sources to determine if it came fro
On 10/01/2013, at 12:24 AM, Alexander Ivchenko wrote:
>> Config/linux-android.h is a better place for this declaration.
I was wrong here. Config/linux-android.h is not a "re-includable" header, and
is not fit for function declarations.
>
> That wouldn't help, I got the following error:
>
> I
Jürgen,
Adding the binutils list as more appropriate for some concerns discussed
here.
> > > > ll, sc, dmult, ddiv, cvt.w.s, 64 bit FPU instructions.
> > > > ll and sc is disabled with "-mno-llsc" and works.
> > > > cvt.w.s is replaced by trunc.w.s. This seems to work.
> > >
> > > Probably sho
Currently, the plugin documentation doesn't mention that it requires
gcc 4.5 or later. The patch to add this statement is attached and
here's the ChangeLog:
2013-01-10 Dave Johansen
* gcc/doc/plugins.texi: Added gcc.4.5.0 or later note to
Plugins documentation.
plugins_doc.patch
Desc
On 01/10/2013 03:58 PM, "Jürgen Urban" wrote:
Hello Jeff,
If you're using something from the Cygnus port, then it would be covered
by the blanket copyright assignment Cygnus had in place with the FSF.
If there are any doubts about the origin of a hunk of GCC code I could
probably pull out the o
61 matches
Mail list logo
