Without aligning the asan stack base,base will only 64-bit aligned in
ARM machines.
But asan require 256-bit aligned base because of this:
1.right shift take ASAN_SHADOW_SHIFT(which is 3) bits are zeros
2.store multiple/load multiple instructions require the other 2 bits are
zeros
that add up low
Hi Tobias!
On 20.02.2014 03:51, Tobias Burnus wrote:
On 10.02.2014 02:22, Tobias Burnus wrote:
a) Does this part work well when both -fopenmp and -fopenacc is
used? I mean: "!$acc loop" followed/preceded by "!$omp do"? I could
imagine that there could be clashes, especially when - e.g. -
co
On Thu, Feb 20, 2014 at 04:19:12PM +0800, lin zuojian wrote:
> Without aligning the asan stack base,base will only 64-bit aligned in
> ARM machines.
> But asan require 256-bit aligned base because of this:
> 1.right shift take ASAN_SHADOW_SHIFT(which is 3) bits are zeros
> 2.store multiple/load mul
On Tue, Feb 18, 2014 at 02:01:03PM +0100, Richard Biener wrote:
>
> This makes sure to run cleanup-all-empty-eh even at -O0 via ehcleanup2.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk
> (and branches?)
>
> Thanks,
> Richard.
>
> 2014-02-18 Richard Biener
>
>
> On Thu, Feb 20, 2014 at 04:19:12PM +0800, lin zuojian wrote:
>> Without aligning the asan stack base,base will only 64-bit aligned in
>> ARM machines.
>> But asan require 256-bit aligned base because of this:
>> 1.right shift take ASAN_SHADOW_SHIFT(which is 3) bits are zeros
>> 2.store multiple/
If you don't mind my realigning on STRICT_ALIGNMENT machines,I will make
patch v2 soon.
>> On Thu, Feb 20, 2014 at 04:19:12PM +0800, lin zuojian wrote:
>>> Without aligning the asan stack base,base will only 64-bit aligned in
>>> ARM machines.
>>> But asan require 256-bit aligned base because of th
On Thu, Feb 20, 2014 at 05:13:36PM +0800, lin zuojian wrote:
> > You certainly don't want to do any of the extra aligning
> > on non-strict alignment targets, so all the changes must be
> > if (STRICT_ALIGNMENT) guarded, as they are quite expensive (you need one
> > extra register in that case).
>
On Thu, Feb 20, 2014 at 10:21:12AM +0100, Jakub Jelinek wrote:
> > > Or, if ARM supports unaligned loads/stores using special instructions,
> > > perhaps you should also benchmark the alternative of not realigning, but
> > > instead making sure those unaligned instructions are used for the shadow
>
Hi!
On Wed, 19 Feb 2014 18:59:59 +0100, Jakub Jelinek wrote:
> On Wed, Feb 19, 2014 at 09:49:20PM +0400, Ilya Verbin wrote:
> > 2014-02-19 20:10 GMT+04:00 Thomas Schwinge :
> > > Here is such a libgomp plugin plus the infrastructure for initial support
> > > of non-shared memory host execution.
Hello all,
Pinging this patch review request again. See previous messages quoted
below for details.
Regards,
Dimitris
On 02/13/2014 04:22 PM, Dimitris Papavasiliou wrote:
Hello,
Pinging this patch review request. Can someone involved in the
Objective-C language frontend have a quick look a
Hi,
The case is an execution case, while the main function doesn't return 0.
Committed as obvious.
Thanks,
bin
gcc/testsuite/ChangeLog
2014-02-20 Bin Cheng
* gcc.dg/tree-prof/crossmodule-indircall-1.c: Return 0
for execution test case.
And the patch..
Thanks,
bin
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of bin.cheng
> Sent: Thursday, February 20, 2014 6:42 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH GCC]Fix obvious bogus test case
>
> Hi,
> Th
Oh, you may think my patch have not violated STRICT_ALIGNMENT.My patch
doesn't realign stack_pointer,but virtual_stack_vars,although they may
share the same position mostly.
As you can see,the code emitted just make the stack 8 bytes aligned.
> You mean that for the prologues right now on ARM we e
On Thu, Feb 20, 2014 at 06:46:21PM +0800, lin zuojian wrote:
> Oh, you may think my patch have not violated STRICT_ALIGNMENT.My patch
> doesn't realign stack_pointer,but virtual_stack_vars,although they may
> share the same position mostly.
> As you can see,the code emitted just make the stack 8 by
>> Or, if ARM supports unaligned loads/stores using special instructions,
>> perhaps you should also benchmark the alternative of not realigning, but
>> instead making sure those unaligned instructions are used for the shadow
>> memory loads/stores in the asan prologue/epilogue.
> I have tried to u
Hi!
On Wed, 19 Feb 2014 17:10:15 +0100, I wrote:
> $ gcc -m64 -Wall -Wextra -shared -o libgomp-plugin-host.so.1
> [...]/libgomp/plugin-host.c -fPIC -O -DDEBUG
>
> ..., and then set LIBGOMP_PLUGIN_PATH=$PWD in the environment.
If putting plugins for several architectures into the same direct
于 2014年02月20日 19:05, Ramana Radhakrishnan 写道:
>>> Or, if ARM supports unaligned loads/stores using special instructions,
>>> perhaps you should also benchmark the alternative of not realigning, but
>>> instead making sure those unaligned instructions are used for the shadow
>>> memory loads/stores
On Wed, Feb 19, 2014 at 11:32 PM, Joseph S. Myers
wrote:
> On Wed, 19 Feb 2014, Prathamesh Kulkarni wrote:
>
>> I have sent it attached this time.
>
> Thanks, this version is OK. Please start the copyright assignment
> paperwork process if you haven't already done so, if you may be
> contributing
On Wed, 19 Feb 2014, Bin.Cheng wrote:
> On Wed, Feb 19, 2014 at 10:06 PM, Richard Biener wrote:
> > On Wed, 19 Feb 2014, Bin.Cheng wrote:
> >
> >> Hi Richard,
> >> Does this have to wait for stage 1? Or I will try to work out a full
> >> patch with loop recreating issue fixed.
> >
> > If it is a
The libjava sourcelocation output test has been FAILing on mainline for
more than a year, with no sign of anything happening to resolve that.
To reduce testsuite noise, I suggest to XFAIL the test. In all mainline
test results from february, only a single set of testresults that
included libjava r
> On Tue, Feb 18, 2014 at 06:55:51PM +0100, Jose E. Marchesi wrote:
> > This patch fixes builds with --enable-sanitizer, which seems to be the
> > default for sparc now.
> >
> > Build tested in a sparc64-*-linux-gnu system with linux 3.8.13 headers.
> >
> > 2014-02-18
Show column number of left operand instead of comma operator
in the warning "left-hand operand of comma expression has no effect"
Example:
ax.c:4:6: warning: left-hand operand of comma expression has no effect
[-Wunused-value]
x , y;
^
Instead of comma operator, show location of left-op
>
> At this point I would suggest to either apply my patch to gcc's
> libsanitizer to fix the sparc build
Please don't.
The "merge" is actually not a merge, it is a simple copy of LLVM
sources over the GCC sources,
no *merging* is ever expected to happen.
> until next merge[1] or disable
> buildin
On Thu, Feb 20, 2014 at 01:15:37PM +0100, Jose E. Marchesi wrote:
> Yesterday I fetched and built the latest llvm/compiler-rt in sparc64. I
> could not manage (in a reasonable time) to get the stuff in
> compiler-rt/lib/sanitizer_common and compiler-rt/lib/asan built: these
> directories seems to
On Thu, Feb 20, 2014 at 4:34 PM, Jakub Jelinek wrote:
> On Thu, Feb 20, 2014 at 01:15:37PM +0100, Jose E. Marchesi wrote:
>> Yesterday I fetched and built the latest llvm/compiler-rt in sparc64. I
>> could not manage (in a reasonable time) to get the stuff in
>> compiler-rt/lib/sanitizer_common a
A rather simple patch.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2014-02-20 Tobias Burnus
PR fortran/602864
* libgfortran/io/inquire.c (yes, no): New static const char vars.
(inquire_via_unit): Use them. Return proper value for
write=, read= and readwrite= for stdi
On Thu, Feb 20, 2014 at 05:52:09PM +0530, Prathamesh Kulkarni wrote:
> Show column number of left operand instead of comma operator
> in the warning "left-hand operand of comma expression has no effect"
>
> Example:
> ax.c:4:6: warning: left-hand operand of comma expression has no effect
> [-Wunus
On Thu, Feb 20, 2014 at 04:44:48PM +0400, Konstantin Serebryany wrote:
> On Thu, Feb 20, 2014 at 4:34 PM, Jakub Jelinek wrote:
> > On Thu, Feb 20, 2014 at 01:15:37PM +0100, Jose E. Marchesi wrote:
> >> Yesterday I fetched and built the latest llvm/compiler-rt in sparc64. I
> >> could not manage (
Hello!
> A rather simple patch.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
>
> 2014-02-20 Tobias Burnus
>
> PR fortran/602864
... we are not there yet with PR numbers ;)
Uros.
This is an internal change to allow retrieval of the Reason argument
for a given message suppressed by Warnings (Off). No functional effect.
Tested on x86_64-pc-linux-gnu, committed on trunk
2014-02-20 Robert Dewar
* errout.adb (Set_Warnings_Mode_Off): Add Reason argument.
(Se
Dear Uros,
Tobias's patch is designed to be future-proof!
Cheers
Paul
On 20 February 2014 14:26, Uros Bizjak wrote:
> Hello!
>
>> A rather simple patch.
>>
>> Build and regtested on x86-64-gnu-linux.
>> OK for the trunk?
>>
>> 2014-02-20 Tobias Burnus
>>
>> PR fortran/602864
>
> ... we are
This patch corrects the propagation of various SPARK aspects from a generic
template to an instance.
-- Source --
-- values.ads
package Values is
In_1 : Integer := 1234;
end Values;
-- gen.ads
with Values; use Values;
generic
package Gen
with Abstract_State
On Thu, Feb 20, 2014 at 12:05 PM, Rainer Orth
wrote:
> The libjava sourcelocation output test has been FAILing on mainline for
> more than a year, with no sign of anything happening to resolve that.
> To reduce testsuite noise, I suggest to XFAIL the test. In all mainline
> test results from feb
On Thu, Feb 20, 2014 at 6:26 PM, Marek Polacek wrote:
> On Thu, Feb 20, 2014 at 05:52:09PM +0530, Prathamesh Kulkarni wrote:
>> Show column number of left operand instead of comma operator
>> in the warning "left-hand operand of comma expression has no effect"
>>
>> Example:
>> ax.c:4:6: warning:
A Raise_Expression is expected to be of any type, and can appear as a component
of any expression. This patch introduces a new type Raise_Type, that is the
initial type of such a node prior to full resolution. A Raise_Expression node
must eventually carry the type imposed by the context. If the typ
For composite types, any object size should be allowed that is a multiple
of the alignment, but the front end was rejecting some cases. The following
should compile clean, giving the output shown for -gnatR2:
1. package ObjSizeTest is
2.type R is record
3. A : Integer;
Bryce McKinlay writes:
> The fix for this is to have libjava use libbackttrace to get source
> line numbers, rather than rely on external addr2line.
I see. Doesn't sound exactly like 4.9 material, though.
Thanks.
Rainer
--
-
This patch updates the error diagnostics of various SPARK features to emit
clearer and more descriptive messages.
-- Source --
-- messages.ads
package Messages
with SPARK_Mode => On
is
A : Integer := 1;
B : Integer := 2;
procedure Error_1 (X : in Integer)
When gnatmake is invoked with -s and some additional compilation switches
(-gnateA, -gnateE, -gnateF, -gnateinn, -gnateu, -gnateV or -gnateY),
recompilation does not necessarily occur. This patch fix this.
The test is to invoke gnatmake with -s and one or these switches:
recompilation should occur.
On 19/02/14 16:35, Richard Sandiford wrote:
> gcc/
> * config/s390/s390.c (s390_mainpool_start): Emit the main_pool
> instruction at the start of the function if the base register is
> call-clobbered. Revert 2014-02-07 change.
> (s390_early_mach): Don't initialize the base
The following fixes an ICE I got when building libjava with a local
patch. This causes us to substitute &MEM[&a, 5] into MEM[_3, 0]
to MEM[&MEM[&a, 5], 0] and then asking stmt_ends_bb_p which doesn't
expect such bogus MEM_REFs. The MEM_REF is canonicalized by
calling fold_stmt on it later, but t
Ping^3~~~
Is there a way in getting attention from libffi maintainers? I really
would like to see the patch made into gcc before the stage 4 closes.
Thanks,
Yufeng
On 02/12/14 18:08, Yufeng Zhang wrote:
Ping^2~~
Thanks,
Yufeng
On 01/14/14 12:10, Yufeng Zhang wrote:
Ping~
Originally post
Hi,
Issue here is that the argument type gets NULL for function-call of
cp_parser_functional_cast. This invalid type is the result of
cp_parser_simple_type_specifier call.
2014-02-20 Kai Tietz
PR c++/58873
* parser.c (cp_parser_functional_cast): Treat NULL_TREE
valued type argume
This patch to the Go frontend avoids a compiler crash on invalid code.
It also fixes the case of *&x when x is not addressable--the expression
was being converted to x without checking, meaning that the compiler
would accept invalid code. Finally, an error message is fixed to have
correct punctuat
Hi,
Latest version of AVX512 spec
http://download-software.intel.com/sites/default/files/managed/50/1a/319433-018.pdf
Has a few changes.
This patch fixes first of them:
Vptestnmd and vptestnmq instructions now have CPUID AVX512F instead of
AVX512CD. This path changes thier CPUID accordingly.
Howeve
OK.
Jason
On 02/19/2014 10:00 PM, Adam Butcher wrote:
+ if (current_template_parms)
+{
+ cp_binding_level *maybe_tmpl_scope = current_binding_level->level_chain;
+ while (maybe_tmpl_scope && maybe_tmpl_scope->kind == sk_class)
+ maybe_tmpl_scope = maybe_tmpl_scope->level_chain;
+
On Thu, Feb 20, 2014 at 4:39 PM, Ilya Tocar wrote:
> Latest version of AVX512 spec
> http://download-software.intel.com/sites/default/files/managed/50/1a/319433-018.pdf
> Has a few changes.
> This patch fixes first of them:
> Vptestnmd and vptestnmq instructions now have CPUID AVX512F instead of
This patch adds large GOT support for the Nios II backend. Tested by
running glibc tests with -fPIC forced on. A few smaller libgcc fixes
are also included as well. Patch committed.
Chung-Lin
2014-02-20 Chung-Lin Tang
Sandra Loosemore
gcc/
* config/nios2/nios2.m
On Thu, Feb 20, 2014 at 10:27:18AM -0500, Jason Merrill wrote:
> OK.
Please include the testcase from the PR into the testsuite though.
Jakub
As described in the PR, we were performing an unconditional store back to the
EXPECT parameter. This is fine, so long as EXPECT is not in thread shared
memory, e.g. a local variable. But the example in the PR uses shared memory
where the extra store introduces a race condition.
I've left a note
Hi Tobias,
> A rather simple patch.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
the patch looks pretty much trivial, int the sense that you just
hard-wire the expected values for the std* units as a special case. I
wonder why the 'inquire_read' and 'inquire_write' functions d
On Thu, Feb 20, 2014 at 11:49:30AM -0600, Richard Henderson wrote:
> Tested on x86_64 and i686, and manually inspecting the generated code.
> Any ideas how to regression test this?
No idea about how to test this.
> @@ -5330,14 +5330,23 @@ expand_builtin_atomic_compare_exchange (enum
> machine_mo
OK.
Jason
Hi Janus,
On Thu, Feb 20, 2014 at 06:51:30PM +0100, Janus Weil wrote:
> > Build and regtested on x86-64-gnu-linux.
> > OK for the trunk?
>
> the patch looks pretty much trivial, int the sense that you just
> hard-wire the expected values for the std* units as a special case. I
> wonder why the 'i
Hi!
As discussed in the PR, gen_reg_rtx from when init_emit has not been
initialized is highly undesirable. The following patch makes sure that
for d->testing_p we never call gen_reg_rtx (i.e. from within
ix86_vectorize_vec_perm_const_ok) and never try to emit insns.
Bootstrapped/regtested on x8
On Thu, 20 Feb 2014, Prathamesh Kulkarni wrote:
> On Wed, Feb 19, 2014 at 11:32 PM, Joseph S. Myers
> wrote:
> > On Wed, 19 Feb 2014, Prathamesh Kulkarni wrote:
> >
> >> I have sent it attached this time.
> >
> > Thanks, this version is OK. Please start the copyright assignment
> > paperwork pro
There is also definitely a use-after-free if you call _Unwind_DeleteException
in your personality before returning _URC_INSTALL_CONTEXT (which you should, if
you don't want to leak and your landing pad doesn't call it). I'm not sure
though how to fix it. It seems the problem that register 0 is i
On 02/20/2014 12:09 PM, Jakub Jelinek wrote:
> On Thu, Feb 20, 2014 at 11:49:30AM -0600, Richard Henderson wrote:
>> Tested on x86_64 and i686, and manually inspecting the generated code.
>> Any ideas how to regression test this?
>
> No idea about how to test this.
>
>> @@ -5330,14 +5330,23 @@ ex
Hello!
As discussed in PR 57896, calling gen_reg_rtx without populated crtl
was the cause of severe internal data corruption. The code following
/* Make sure regno_pointer_align, and regno_reg_rtx are large
enough to have an element for this pseudo reg number. */
comment is simply not pr
On Thu, Feb 20, 2014 at 08:34:46PM +0100, Uros Bizjak wrote:
> 2014-02-20 Uros Bizjak
>
> * emit-rtl.c (gen_reg_rtx): Assert that
> crtl->emit.regno_pointer_align_length is non-zero.
>
> The patch was bootstrapped and regression tested on
> x86_64-pc-linux-gnu {,-m32} on 4.8 and 4.9 br
On Thu, Feb 20, 2014 at 07:39:33PM +0100, Jakub Jelinek wrote:
> active) with RTL checking, further tested with
> GCC_TEST_RUN_EXPENSIVE=1 make -j16 -k check
> RUNTESTFLAGS='--target_board=unix\{-msse2,-msse3,-mssse3,-msse4,-mavx,-mavx2,-mavx512f\}
> dg-torture.exp=*vshuf*'
> (on AVX HW, so -mavx
On Thu, Feb 20, 2014 at 9:05 PM, Jakub Jelinek wrote:
> On Thu, Feb 20, 2014 at 08:34:46PM +0100, Uros Bizjak wrote:
>> 2014-02-20 Uros Bizjak
>>
>> * emit-rtl.c (gen_reg_rtx): Assert that
>> crtl->emit.regno_pointer_align_length is non-zero.
>>
>> The patch was bootstrapped and regress
On Thu, Feb 20, 2014 at 9:08 PM, Jakub Jelinek wrote:
>> active) with RTL checking, further tested with
>> GCC_TEST_RUN_EXPENSIVE=1 make -j16 -k check
>> RUNTESTFLAGS='--target_board=unix\{-msse2,-msse3,-mssse3,-msse4,-mavx,-mavx2,-mavx512f\}
>> dg-torture.exp=*vshuf*'
>> (on AVX HW, so -mavx2
On Feb 16, 2014, at 4:21 PM, David Holsgrove wrote:
> I've attached an updated patch
Ok, thanks.
On 02/20/2014 12:39 PM, Jakub Jelinek wrote:
> + if (!d->testing_p)
> +{
> + dremap.target = gen_reg_rtx (dremap.vmode);
> + dfinal.op0 = gen_lowpart (dfinal.vmode, dremap.target);
> +}
...
> + if (d->testing_p)
> + d_copy.target = gen_lowpart (V4DFmode, d->target);
On Thu, Feb 20, 2014 at 02:41:06PM -0600, Richard Henderson wrote:
> On 02/20/2014 12:39 PM, Jakub Jelinek wrote:
> > + if (!d->testing_p)
> > +{
> > + dremap.target = gen_reg_rtx (dremap.vmode);
> > + dfinal.op0 = gen_lowpart (dfinal.vmode, dremap.target);
> > +}
> ...
> > +
Hi,
>> > Build and regtested on x86-64-gnu-linux.
>> > OK for the trunk?
>>
>> the patch looks pretty much trivial, int the sense that you just
>> hard-wire the expected values for the std* units as a special case. I
>> wonder why the 'inquire_read' and 'inquire_write' functions don't
>> actually
On 02/20/2014 02:59 PM, Jakub Jelinek wrote:
> ... so all we care about is that
> target/op0/op1 have the right modes and that target is a different register
> from op0 and op0 either the same as op1 or yet another register.
That's my point: yet another register. Thus the creation of a brand new
Hi all,
attached is a patch for an ICE-on-valid regression related to finalization.
What the patch does is to defer the building of the vtabs to a later
stage. Previously this was done only for some rare cases, now we do it
basically for all vtabs. This is necessary with finalization, since
build
Hi Richard,
It would be nice to be able to pass -mvirt to the gcc driver. Does this patch
look okay to install?
Also, please let me know if I can install now or if I need to wait for stage 1.
Thanks,
Catherine
virt.cl
Description: virt.cl
virt.patch
Description: virt.patch
"Moore, Catherine" writes:
> It would be nice to be able to pass -mvirt to the gcc driver. Does this
> patch look okay to install?
> Also, please let me know if I can install now or if I need to wait for stage
> 1.
I don't see any problem with it going in now.
> @@ -17447,6 +17448,14 @@ Use (d
I've backported this patch from trunk at r205292. Committed on
google/gcc-4_8 branch as r207971.
Tested with make check in libiberty.
-cary
2013-11-22 Cary Coutant
libiberty/
* cp-demangle.c (struct d_info_checkpoint): New struct.
(struct d_print_info): Add current_t
On Thu, Dec 5, 2013 at 3:54 PM, Jan Hubicka wrote:
>> On Thu, 21 Nov 2013, Jan Hubicka wrote:
>>
>> > >
>> > > Why do you need an additional -fparallelism? Wouldn't
>> > > -fwpa=... be a better match, matching -flto=...? As we already
>> > > pass down a -fwpa option to WPA this would make things
* include/std/iomanip (_Quoted_string operator>>): Do not clear
string if input is not quoted.
Currently the string is cleared regardless of
how the string is handled. This patch just
moves the clearing down so that we do not clear
it if we are not going to quote the string
(i.e. let operator
On 21 February 2014 00:00, Lars Gullik Bjønnes wrote:
>
> * include/std/iomanip (_Quoted_string operator>>): Do not clear
>string if input is not quoted.
>
> Currently the string is cleared regardless of
> how the string is handled. This patch just
> moves the clearing down so that we do not c
On 02/20/2014 01:22 PM, Richard Henderson wrote:
> On 02/20/2014 12:09 PM, Jakub Jelinek wrote:
>> On Thu, Feb 20, 2014 at 11:49:30AM -0600, Richard Henderson wrote:
>>> Tested on x86_64 and i686, and manually inspecting the generated code.
>>> Any ideas how to regression test this?
>>
>> No idea a
.9-20140209 to 20140220
Also major faults went down somewhat.
gcc49
gcc version 4.9.0 20140209 (experimental) (GCC)
real=178.91 user=1829.87 system=125.76 share=1093%% maxrss=1231580 ins=37848
outs=7852280 mfaults=49741854 waits=151528
gcc49
gcc version 4.9.0 20140220 (experimental) (GCC)
re
t; LTO build time going from 4.9-20140209 to 20140220
Good to know! It also improves firefox build noticeably.
I added some comments to the PR itself. I do not see how it can make too many
WPA processes, given that it does not fork without explicit -flto=N argument
that is not passed by the boo
Hi,
I have misunderstood the meaning of STRICT_ALIGNMENT.Sorry for that Jakub.
I think patch v2 have modified as Jakub suggested.
---
Without aligning the asan stack base,this base will only 64-bit aligned
in ARM machines.
But asan require 256-bit aligned base because of this:
1.right shift take
This libgo patch from Michael Hudson-Doyle fixes the heap address for
Aarch64, as described in the patch. Bootstrapped and ran Go testsuite
on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r dd599141ce32 libgo/runtime/malloc.goc
--- a/libgo/runtime/malloc.goc Thu Feb 20 07:18:12 20
Hi all,
Compiling inline asm results in ICE (PR60034). Alignment calculation in
aarch64_classify_address for (symbol_ref:DI ("*.LANCHOR4") [flags
0x182])) seems wrong here.
Fixing this also caused a regression for pr38151.c, which is due to
complex type being allocated with wrong alignment. Atta
Hello,
While fixing PR 58960 I forgot about single-block regions placing the
initialization of the new nr_regions_initial variable in the wrong place.
Thus for single block regions we ended up with nr_regions = 1 and
nr_regions_initial = 0 and effectively turned off sched-pressure
immediately
Hi Janus,
Janus Weil wrote:
What the patch does is to defer the building of the vtabs to a later
stage. Previously this was done only for some rare cases, now we do it
basically for all vtabs. This is necessary with finalization, since
building the vtab also implies building the finalization wra
On Thu, Feb 20, 2014 at 7:39 PM, Jakub Jelinek wrote:
> As discussed in the PR, gen_reg_rtx from when init_emit has not been
> initialized is highly undesirable. The following patch makes sure that
> for d->testing_p we never call gen_reg_rtx (i.e. from within
> ix86_vectorize_vec_perm_const_ok)
Hi,
Janus Weil wrote:
Namely, either unconditionally using for UNIT=:
if ((cf & IOPARM_INQUIRE_HAS_READWRITE) != 0)
p = (u->flags.action == ACTION_READWRITE) ? yes : no;
We probably still need some special case for stdin/stdout/stderr.
Do we? If the new version of the patch works correctly
On Fri, Feb 21, 2014 at 08:30:39AM +0100, Uros Bizjak wrote:
> Attached is the complete backport of the patch to 4.7 branch. Jakub,
> there is a slight churn in expand_vec_parm_interleave2 (there is no
> dfinal.one_operand_p), can you please check if everything is OK there?
Yeah, one_operand_p has
87 matches
Mail list logo
