On 11/30/2012 04:05 PM, Paolo Carlini wrote:
@@ -219,10 +219,15 @@ cp_convert_to_pointer (tree type, tree expr, tsubs
- expr = build_int_cst (type, 0);
+ expr = (TREE_SIDE_EFFECTS (expr)
+ ? build_nop (type, expr)
+ : build_int_cst (type, 0));
This seems
Compiling the following code with O2
typedef unsigned long ulong;
typedef __SIZE_TYPE__ size_t;
long woo_i(long a, long b) { return a/b; }
GCC generates:
.LFB0:
.cfi_startproc
movq%rdi, %rdx
movq%rdi, %rax
sarq$63, %rdx
idivq %rsi
ret
(No cans of worms opened here, I believe...)
For MMIX with the default, Knuth's ABI (returning values in register
$0, through the register stack), function return values are prepared
in a register-swapped fashion due to the way the register stack works,
which has to be expressed as:
(parallel [
On Fri, 30 Nov 2012, Steve Ellcey wrote:
> While investigating some soft-float issues I tried compiling fp-bit.c in
> libgcc with NO_NANS defined. I wound up with an undefined reference to
> makenan.
Unless anything in the tree defines NO_NANS, I suggest we remove all
support for such a macro
While investigating some soft-float issues I tried compiling fp-bit.c in
libgcc with NO_NANS defined. I wound up with an undefined reference to
makenan.
Here is my attempt at a patch to fix the problem but I am not sure if
returning 0 is the right thing to do for b/0 when NO_NANS is defined.
is
This patch to the Go frontend fixes a bug converting unnamed types to
GIMPLE. It's important to convert all identical unnamed Go types to the
same GIMPLE type, to avoid middle-end errors in assignments and type
conversions. This is done via a hash table. Unfortunately
Type::get_backend_placehold
Hi!
When I've tried to compile the attached testcase (I was trying to see
if tsan could discover the emutls.c data race), I got ICEs because
expr_ptr in certain cases wasn't is_gimple_val and thus was invalid to
pass it directly to a call as argument, fixed thusly.
Unfortunately, trying to compil
> I was mainly arguing with the sentence that for asm volatile, the output
> constraints (did you mean outputs and clobbers?) have essentially no
> meaning. While for some optimizations perhaps it might be desirable
> to treat asm volatile as full optimization barrier, I'm not sure about all
> of
On Fri, Nov 30, 2012 at 09:00:30PM +0400, Dmitry Vyukov wrote:
> and thanks for the nand catch!
Here is updated atomics instrumentation patch, including the 16-byte
atomics, nand, success/failure parameters for cas and 0-5 arguments
instead of 1<<0 through 1<<5 for memory models.
Again, on top of
Hi!
If the pack is unnamed, make_ith_pack_parameter_name will crash.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
acked by Jason in the PR, committed to trunk so far.
2012-12-01 Jakub Jelinek
PR c++/55542
* pt.c (make_ith_pack_parameter_name): Return NU
This is a segfault on a degenerate bitfield case introduced by the rewrite of
the bitfield machinery. In Ada, we have bitfields of size zero and we ask the
middle-end to generate accesses to them. This doesn't work anymore because
get_best_mode now returns VOIDmode instead of QImode in this ca
On Fri, 30 Nov 2012, Uros Bizjak wrote:
For reference, we are talking about:
(define_insn "_vm3"
[(set (match_operand:VF_128 0 "register_operand" "=x,x")
(vec_merge:VF_128
(plusminus:VF_128
(match_operand:VF_128 1 "register_operand" "0,x")
(match_opera
> Yikes, sorry, it wasn't clear to me what PROP_loops really does. Anyway,
> I think I have a better fix now. The problem is just that when removing
> BB 4 (which was a header), we have to zap ->header and ->latch. We
> already have code for this:
>
> if (current_loops != NULL
> && e->s
Hello,
This epilogue_delay_list probably existed only for text epilogues, but
it is now unused.
Tested by building a set of cc1-i files at -O2 for SPARC with and
without the patch, and verifying that there are no code gen changes.
OK for trunk?
Ciao!
Steven
reorg_janitor_4.diff
Description: B
> RTL cprop seems to run both before and after RTL loop optimizers (currently
> after RTL loop optimizers we throw away loops - an arbitrary chosen point
> before IRA across which I could not get things to work). Thus you could do
>
> if (current_loops)
> is_loop_header = bb == bb->loop_fat
On Fri, 30 Nov 2012, Richard Biener wrote:
> If you want to split TARGET_C99_FUNCTIONS then split it properly,
> don't add TARGET_HAS_BIONIC to the selection.
>
> Joseph may provide some guidance here.
My suggested interface would be a target hook such as
targetm.libc_has_function, taking two a
Hi,
this wrong code PR is some sort of continuation of PR 52988, where we
discard side-effects of expression of nullptr_t. Here too, in
cp_convert_to_pointer and in build_ptrmemfunc, we don't check for
side-effects and we replace the expression with a plain int_cst or
nullptr_node. The testca
Hi,
Toplevel configure supports:
# Handle --enable-gold, --enable-ld.
# --disable-gold [--enable-ld]
# Build only ld. Default option.
# --enable-gold [--enable-ld]
# Build both gold and ld. Install gold as "ld.gold", install ld
# as "ld.bfd" and "ld".
# --enable-gold=default [--enab
It turned out that this patch depended on another one from
earlier, so I have backported that to ARM/aarch64-4.7-branch too.
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00452.html
Cheers,
Ian
> -Original Message-
> From: Ian Bolton [mailto:ian.bol...@arm.com]
> Sent: 23 November 2012 1
On 2012-11-30 01:03, Michael Zolotukhin wrote:
> Changelog:
> 2012-11-30 Michael Zolotukhin
>
> * Makefile.in: Add target mddump, build/genmddump.o. Extend
> genprogrtl with mddump.
> * genmddump.c: New.
Ok.
r~
forgot the patch
On 11/30/2012 01:03 PM, Kenneth Zadeck wrote:
Richi
this patch is our attempt to implement the storage classes for wide
int as you suggested. The patch currently does not work for reasons
that will be mentioned below, but we stopped work on it because it is
clear that this
Richi
this patch is our attempt to implement the storage classes for wide int
as you suggested. The patch currently does not work for reasons that
will be mentioned below, but we stopped work on it because it is clear
that this is a terrible idea.
1) Having more than one storage class is l
and thanks for the nand catch!
On Fri, Nov 30, 2012 at 9:00 PM, Dmitry Vyukov wrote:
> On Fri, Nov 30, 2012 at 8:38 PM, Jakub Jelinek wrote:
>> On Tue, Nov 27, 2012 at 12:47:50PM +0400, Dmitry Vyukov wrote:
>>> Yes, you are right.
>>> I think I've done them atomically initially because of things
On Fri, Nov 30, 2012 at 8:38 PM, Jakub Jelinek wrote:
> On Tue, Nov 27, 2012 at 12:47:50PM +0400, Dmitry Vyukov wrote:
>> Yes, you are right.
>> I think I've done them atomically initially because of things like
>> FUTEX_WAKE_OP. I will fix that.
>
> Any progress on that?
>
> BTW, the current
> te
On Tue, Nov 27, 2012 at 12:47:50PM +0400, Dmitry Vyukov wrote:
> Yes, you are right.
> I think I've done them atomically initially because of things like
> FUTEX_WAKE_OP. I will fix that.
Any progress on that?
BTW, the current
template T func_nand(T v, T op) {
return ~v & op;
}
is wrong not jus
On 29 November 2012 21:59, Joseph S. Myers wrote:
> On Thu, 29 Nov 2012, Christophe Lyon wrote:
>
>> 2012-11-28 Christophe Lyon
>>
>> gcc/
>> * config/arm/arm-protos.h (tune_params): Add
>> prefer_neon_for_64bits field.
>> * config/arm/arm.c (prefer_neon_for_64bits): New variabl
On Fri, Nov 30, 2012 at 10:01:37AM +0100, Richard Biener wrote:
> RTL cprop seems to run both before and after RTL loop optimizers (currently
> after RTL loop optimizers we throw away loops - an arbitrary chosen point
> before IRA across which I could not get things to work). Thus you could do
>
> Revised patch to ensure that histograms from the profile summary are streamed
> through the LTO files so that the working set can be computed for use in
> downstream optimizations.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for trunk?
>
> Thanks,
> Teresa
>
> 2012-11-29 Teres
Hi!
Here is updated patch, I've added also -fno-builtin which cured some
failures (will need to analyze exactly later on if it is just assumptions
of the test that are not valid with optimized memory/string etc. builtins
or if we have issues on the GCC side), the only change in the imported
files
Hi all,
I have committed the attached patch, adding myself to the Write After
Approval section of the MAINTAINERS file.
Thanks,
Kyrill
ChangeLog:
2012-11-30 Kyrylo Tkachov
* MAINTAINERS (Write After Approval): Add myself.Index: MAINTAINERS
===
On Fri, Nov 30, 2012 at 3:51 PM, Steven Bosscher wrote:
> This one-liner causes following runtime test failure [1] for
> alphaev68-linux-gnu:
>
> FAIL: gfortran.fortran-torture/execute/save_1.f90 execution, -O2
> FAIL: gfortran.fortran-torture/execute/save_1.f90 execution, -
Revised patch to ensure that histograms from the profile summary are streamed
through the LTO files so that the working set can be computed for use in
downstream optimizations.
Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for trunk?
Thanks,
Teresa
2012-11-29 Teresa Johnson
On Fri, Nov 30, 2012 at 3:51 PM, Steven Bosscher wrote:
> They are r188868 and r189325.
This'd be the diff:
http://gcc.gnu.org/viewcvs/trunk/gcc/alias.c?r1=188448&r2=189325&pathrev=189325
Ciao!
Steven
On Fri, Nov 30, 2012 at 1:29 PM, Uros Bizjak wrote:
> On Fri, Nov 30, 2012 at 11:42 AM, Steven Bosscher wrote:
>> On Fri, Nov 30, 2012 at 11:39 AM, Paolo Bonzini wrote:
>>> Il 29/11/2012 23:47, Uros Bizjak ha scritto:
This one-liner causes following runtime test failure [1] for
alphaev68-
On Fri, Nov 30, 2012 at 02:43:12PM +0400, Konstantin Serebryany wrote:
> I've upstreamed most of your changes, please take a look.
> Looks like we will be able to use libsanitizer/merge.sh to update the
> test code as well.
Thanks.
> > #ifndef ASAN_AVOID_EXPENSIVE_TESTS
> > (TEST(AddressSanitizer
On Thu, Nov 29, 2012 at 6:12 PM, Doug Evans wrote:
> Diego Novillo writes:
> > On Sat, Nov 24, 2012 at 5:58 PM, Doug Evans wrote:
> > > Hi.
> > > This seventh patch adds new options --manifest_subdir, --manifest_name.
> > > Useful when using validate_failures.py with a different tool, instead
I merged trunk revision 193985 to the gccgo branch.
Ian
On Fri, Nov 30, 2012 at 5:30 AM, Richard Biener
wrote:
> On Fri, Nov 30, 2012 at 2:17 PM, H.J. Lu wrote:
>> On Fri, Nov 30, 2012 at 12:45 AM, Richard Biener
>> wrote:
>>> On Thu, Nov 29, 2012 at 6:40 PM, H.J. Lu wrote:
Hi,
When GCC is configured with --with-build-config="bootstra
On Fri, Nov 30, 2012 at 1:34 PM, Marc Glisse wrote:
> Hello,
>
> I experimented with the simplify-rtx transformation you suggested, see:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54855
>
> It works when the argument is a register, but not for memory (which is where
> the constant is in the te
On Fri, Nov 30, 2012 at 2:17 PM, Alexander Ivchenko wrote:
> Bionic has the support of almost all built-in functions from C99 iso
> standard except for only complex math functions.
> (I assume because bionic wants to be as small as possible and nobody
> wants to do complex arithmetic on Android).
On Fri, Nov 30, 2012 at 2:17 PM, H.J. Lu wrote:
> On Fri, Nov 30, 2012 at 12:45 AM, Richard Biener
> wrote:
>> On Thu, Nov 29, 2012 at 6:40 PM, H.J. Lu wrote:
>>> Hi,
>>>
>>> When GCC is configured with --with-build-config="bootstrap-asan", all
>>> -flto tests will fail since -fsanitize=address
On Fri, Nov 30, 2012 at 2:02 PM, Martin Jambor wrote:
> On Thu, Nov 29, 2012 at 11:06:41AM +0100, Martin Jambor wrote:
>> Hi,
>>
>> thanks for the review. When writing a reply I realized I indeed made
>> a mistake or two in the part concerning prev_base and the code was not
>> what it intended to
On Fri, Nov 30, 2012 at 12:45 AM, Richard Biener
wrote:
> On Thu, Nov 29, 2012 at 6:40 PM, H.J. Lu wrote:
>> Hi,
>>
>> When GCC is configured with --with-build-config="bootstrap-asan", all
>> -flto tests will fail since -fsanitize=address is used to compile host
>> libiberty, which is used to cre
On Fri, Nov 30, 2012 at 1:29 PM, Uros Bizjak wrote:
This one-liner causes following runtime test failure [1] for
alphaev68-linux-gnu:
FAIL: gfortran.fortran-torture/execute/save_1.f90 execution, -O2
FAIL: gfortran.fortran-torture/execute/save_1.f90 execution, -O2
-
On Thu, Nov 29, 2012 at 11:06:41AM +0100, Martin Jambor wrote:
> Hi,
>
> thanks for the review. When writing a reply I realized I indeed made
> a mistake or two in the part concerning prev_base and the code was not
> what it intended to be. I'll re-write it today.
OK, this is it. The part in t
Still verifying some of my PRE assumtions by making the code less
obscure ...
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-11-30 Richard Biener
* tree-ssa-pre.c (get_expr_value_id): Do not allocate value-ids
here.
Index: gcc/tree-ssa-pre.c
===
On Sun, 14 Oct 2012, Marc Glisse wrote:
On Sun, 14 Oct 2012, Uros Bizjak wrote:
On Sat, Oct 13, 2012 at 10:52 AM, Marc Glisse wrote:
Hello,
this patch provides an alternate pattern to let combine recognize scalar
operations that preserve the high part of a vector. If the strategy is all
rig
On Fri, Nov 30, 2012 at 11:42 AM, Steven Bosscher wrote:
> On Fri, Nov 30, 2012 at 11:39 AM, Paolo Bonzini wrote:
>> Il 29/11/2012 23:47, Uros Bizjak ha scritto:
>>> This one-liner causes following runtime test failure [1] for
>>> alphaev68-linux-gnu:
>>>
>>> FAIL: gfortran.fortran-torture/execut
Am 30.11.2012 11:22, schrieb Janus Weil:
In my version of the patch I introduced a routine 'gfc_is_finalizable'
to perform this decision.
Okay. How about the following patch? It's the same without the renaming.
Build an regtested on x86-64-linux.*
OK for the trunk?
* * *
I will submit your g
I've upstreamed most of your changes, please take a look.
Looks like we will be able to use libsanitizer/merge.sh to update the
test code as well.
On Fri, Nov 30, 2012 at 2:14 PM, Jakub Jelinek wrote:
> On Fri, Nov 30, 2012 at 01:32:52PM +0400, Konstantin Serebryany wrote:
>> Ideally, I would lik
On Fri, Nov 30, 2012 at 11:39 AM, Paolo Bonzini wrote:
> Il 29/11/2012 23:47, Uros Bizjak ha scritto:
>> This one-liner causes following runtime test failure [1] for
>> alphaev68-linux-gnu:
>>
>> FAIL: gfortran.fortran-torture/execute/save_1.f90 execution, -O2
>> FAIL: gfortran.fortran-torture/ex
Il 29/11/2012 23:47, Uros Bizjak ha scritto:
> This one-liner causes following runtime test failure [1] for
> alphaev68-linux-gnu:
>
> FAIL: gfortran.fortran-torture/execute/save_1.f90 execution, -O2
> FAIL: gfortran.fortran-torture/execute/save_1.f90 execution, -O2
> -fomit-frame-pointer -finli
2012/11/30 Janus Weil :
> Hi,
>
>>> one thing that I do not like about your patch is the modification of
>>> "gfc_find_derived_vtab": You create two versions of it, one of which creates
>>> the vtab if it does not exist, while the other version does not do this.
>>> [...] can you explain to me why
On Wed, Nov 28, 2012 at 3:05 PM, Tom de Vries wrote:
> On 27/11/12 13:41, Richard Biener wrote:
>> On Mon, Nov 19, 2012 at 3:33 AM, Tom de Vries wrote:
>>> Richard,
>>>
>>> Consider the PR55124 example test.c:
>>> ...
>>> int a, b;
>>> long c;
>>>
>>> static void inline
>>> f2 (void)
>>> {
>>>
Hi,
>> one thing that I do not like about your patch is the modification of
>> "gfc_find_derived_vtab": You create two versions of it, one of which creates
>> the vtab if it does not exist, while the other version does not do this.
>> [...] can you explain to me why this would be necessary?
>
>
>
On Fri, Nov 30, 2012 at 01:32:52PM +0400, Konstantin Serebryany wrote:
> Ideally, I would like to limit the differences from upstream.
> I'll put some of your changes upstream, for others I'd ask you to
> consider other choices.
>
> -#include "gtest/gtest.h"
> +#include "dejagnu-gtest.h"
>
> Mayb
> Can the fix be back ported?
Yes, the back port on 4.7 is straightforward, it just needs to be commited.
Yvan
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
On
> Behalf Of Bin Cheng
> Sent: Wednesday, November 28, 2012 9:48 AM
> To: Richard Earnshaw
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH ARM] Disable "-fira-hoist-pressure" on Thumb2
On 29/11/12 15:42, Yvan Roux wrote:
Hi,
on ARMv7, the code generated for the __atomic_load builtins in the
__ATOMIC_ACQUIRE memory model, puts a memory barrier before the load, whereas
the semantic of the acquire memory model implies a barrier after.
The issue seems to be in expand_atomic_load
Jakub,
Great result!
Ideally, I would like to limit the differences from upstream.
I'll put some of your changes upstream, for others I'd ask you to
consider other choices.
-#include "gtest/gtest.h"
+#include "dejagnu-gtest.h"
Maybe like this?
#if ASAN_USE_DEJAGNU_GTEST
#include "dejagnu-gtest.
This removes iterating propagation of value-ids (I verified
it never needs iteration in practice - certainly it does not
need iteration by design).
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-11-30 Richard Biener
* tree-ssa-sccvn.c (run_scc_vn): Remov
On Thu, Nov 29, 2012 at 11:58 PM, Steven Bosscher wrote:
> Hello,
>
> This patch rewrites sched-vis.c, and graph.c, to use the pretty-print
> machinery. This makes it easier to add GIMPLE cfg dumping also,
> because all tree/gimple dumping is done via pretty-print. It also
> removes the ugly (and
I didn't find any dump_rtx - instead, I used print_inline_rtx which
seems to be what we need to output to stdout, instead of stderr.
Updated version of the patch is attached. Ok for trunk?
Changelog:
2012-11-30 Michael Zolotukhin
* Makefile.in: Add target mddump, build/genmddump.o. Ex
On 28/11/12 16:34, Tejas Belagod wrote:
Hi,
The attached patch implements vector alignment hooks
TARGET_VECTOR_ALIGNMENT
TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE
TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
Regression tested on aarch64-none-elf. OK for aarch64-4.7 and trunk?
OK provided
On Thu, Nov 29, 2012 at 6:43 PM, Eric Botcazou wrote:
>> Yikes, sorry, it wasn't clear to me what PROP_loops really does. Anyway,
>> I think I have a better fix now. The problem is just that when removing
>> BB 4 (which was a header), we have to zap ->header and ->latch. We
>> already have code
On Thu, Nov 29, 2012 at 6:40 PM, H.J. Lu wrote:
> Hi,
>
> When GCC is configured with --with-build-config="bootstrap-asan", all
> -flto tests will fail since -fsanitize=address is used to compile host
> libiberty, which is used to create liblto_plugin.so, and linker isn't
> compiled with -fsanitiz
Hello,
> Ok.
Thanks, checked in: http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00937.html
Thanks, K
67 matches
Mail list logo