Hi,
this patch fixes IPA-ICF's polymorphic type matching. Basically
ipa-polymorphic-call looks for the following cases:
- data living in automatic or static variables of polymorphic type
- dynamic type changes done by explicit calls to constructor or writes
of virtual table pointer
- pa
> 2015-03-09 Martin Liska
>
> * config/i386/i386.c (def_builtin): Collect union of all
> possible masks.
> (ix86_add_new_builtins): Do not iterate over all builtins
> in cases that isa value has no intersection with possible masks
> and(or) last passed value is equ
> > CFG cleanup currently searches for calls that became noreturn and
> > fixes them up (splitting block and removing the fallthru). Previously
> > that was technically necessary as propagation may have turned an
> > indirect call into a direct noreturn call and the CFG verifier would
> > have bar
Hi,
I have wrote a testcase that reproduces argument overwriting bug during arm
code generation.
I wrote this testcase with the help of Mikael Pettersson.
If some format is not proper to run in gcc testsuite framework, please
correct me.
Please refer to the following bugzilla link for details:
h
On Thu, Mar 12, 2015 at 10:22:37PM +0300, Ilya Verbin wrote:
> On Thu, Mar 12, 2015 at 15:21:35 +0100, Jakub Jelinek wrote:
> > On Thu, Mar 12, 2015 at 04:56:35PM +0300, Ilya Verbin wrote:
> > > This happens because the var_x is added into offload tables for both
> > > share.o and
> > > test.o. T
On Thu, Mar 12, 2015 at 15:21:35 +0100, Jakub Jelinek wrote:
> On Thu, Mar 12, 2015 at 04:56:35PM +0300, Ilya Verbin wrote:
> > This happens because the var_x is added into offload tables for both
> > share.o and
> > test.o. The patch below fixes this issue. Regtested on x86_64-linux and
> > i68
I assumed that Pthreads was enough to ensure pthread_rwlock_t but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64847 shows that isn't
true for HPUX (seems it was optional prior to POSIX 1003.1-2001).
This adds an autoconf check to decide whether to use pthread_rwlock_t
or the fallback implementat
Hello Paul,
have you had time to look at this again?
Mikael
Ping:
https://gcc.gnu.org/ml/fortran/2015-02/msg00045.html
The PR shows that the compiler ICEs whenever it tries to expand an atomic
operation at the file scope. That happens because it creates temporaries
via create_tmp_var, which also pushes the variable into the current binding,
but that can't work if current_function_decl is NULL. The fix is I think
On Thu, Mar 12, 2015 at 10:00 AM, Matthias Klose wrote:
> On 03/12/2015 05:41 PM, Ian Lance Taylor wrote:
>> The cgo tool installed by gccgo works fine on 32-bit PPC. This patch
>> notes that fact in the gccgo version of the go tool. This is GCC PR
>> 65404. Bootstrapped and ran Go testsuite on
On 03/12/2015 05:41 PM, Ian Lance Taylor wrote:
> The cgo tool installed by gccgo works fine on 32-bit PPC. This patch
> notes that fact in the gccgo version of the go tool. This is GCC PR
> 65404. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
> Committed to mainline.
same thin
On 03/12/2015 06:13 AM, Paolo Carlini wrote:
52718_red.C:1:22: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
void* fun(void* a = 0);
52718_red.C:2:16: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
void* f2 = fun();
OK, then your second
This patch changes the gotools to add GOCFLAGS to the build command,
since the command is both compiling and linking. The main effect of
this is to, by default, build with -g -O2, which previously was not
happening. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to main
The cgo tool installed by gccgo works fine on 32-bit PPC. This patch
notes that fact in the gccgo version of the go tool. This is GCC PR
65404. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 81cc50c9140d libgo/go/go/build/build.go
--- a/libgo/g
On Thu, Mar 12, 2015 at 11:29 AM, Michael Meissner
wrote:
> On Wed, Mar 11, 2015 at 08:52:54PM -0400, David Edelsohn wrote:
>> On Wed, Mar 11, 2015 at 6:21 PM, Michael Meissner
>> wrote:
>> > On Wed, Mar 11, 2015 at 01:02:06PM -0400, David Edelsohn wrote:
>> >> I am concerned with the create_TOC_
On Wed, Mar 11, 2015 at 08:52:54PM -0400, David Edelsohn wrote:
> On Wed, Mar 11, 2015 at 6:21 PM, Michael Meissner
> wrote:
> > On Wed, Mar 11, 2015 at 01:02:06PM -0400, David Edelsohn wrote:
> >> I am concerned with the create_TOC_reference use for TARGET_TOC. Has
> >> this been tested with big
On Thu, Mar 12, 2015 at 04:56:35PM +0300, Ilya Verbin wrote:
> This happens because the var_x is added into offload tables for both share.o
> and
> test.o. The patch below fixes this issue. Regtested on x86_64-linux and
> i686-linux. However I'm not sure how to create a regression test, which w
Hi,
We have a problem with declare target variables in fortran modules, here is a
small reproducer:
+ share.f90:
module share
integer :: var_x
!$omp declare target(var_x)
end module
+ test.f90:
use share
var_x = 10
!$omp target update to(var_x)
end
+
$ gfortran -fopenmp -c
For P a subprogram, P'Code_Address is expected to return
the address at which the machine code for P starts.
It differs from 'Address on targets where function
symbol names denote the address of a function descriptor,
a record from which the code address can be fetched
(e.g. on ppc-aix).
On such
Hi all
we have merged the gcc-4_9-branch into linaro/gcc-4_9-branch up to
revision 221341 as r221360. We have also backported this set of revisions:
* r212011 as r221216 : PR tree-optimization/61607
* r214942 as r221216 : Abstract away marking loops for removal
* r214957 as r221216 : Sanity chec
On Thu, Mar 12, 2015 at 2:28 PM, Kyrill Tkachov wrote:
>>> The patch fixes that by calculating the size of the first element by
>>> taking the size of the outer mode and subtracting the size of the second
>>> element.
>>>
>>> I've added an assert to make sure that the second element is not also a
>> The patch fixes that by calculating the size of the first element by
>> taking the size of the outer mode and subtracting the size of the second
>> element.
>>
>> I've added an assert to make sure that the second element is not also a
>> const_int, as a vec_concat of const_ints doesn't make sen
After noticing tree-parloop.c passing crap to split_block (a tree
rather than a gimple or an rtx) I noticed those CFG functions simply
take void * pointers. The following patch fixes that and adds
two overloads, one for GIMPLE use and one for RTL use.
Bootstrapped on x86_64-unknown-linux-gnu, te
This fixes sth noticed by Honza - I was resetting OEP_ADDRESS_OF
before actually testing for it in MEM_REF/TARGET_MEM_REF handling.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-03-12 Richard Biener
PR middle-end/65270
* fold-const.c (operand_eq
Hi,
On 03/11/2015 09:26 PM, Jason Merrill wrote:
On 03/06/2015 03:36 AM, Paolo Carlini wrote:
this is a regression about duplicate warnings with
-Wzero-as-null-pointer-constant. The regression is rather old, affects
4_8-branch too, and started when check_default_argument got a
perform_implicit_
There are two groups of features which are not properly implemented with
remote access:
* "caf(:)[i]%a" might have a byte stride which is not compatible with
the size of "a". (Fix: new array descriptor.)
* All access which involves dereferencing pointers in a remote coarray
(e.g. "caf[i]%ptr_c
On 11 Mar 19:11, Ilya Enkovich wrote:
> 2015-03-11 18:59 GMT+03:00 H.J. Lu :
> > On Wed, Mar 11, 2015 at 7:37 AM, Matthias Klose wrote:
> >> current trunk fails to build on x86*-linux, when configured for x32
> >> multilibs
> >> because libmpx doesn't support these. Disable them.
> >>
> >> ok for
Hi,
This patch fixes PR64895, related to the gcc.target/i386/fuse-caller-save*.c
failures for -m32 -fpic.
Bootstrapped and reg-tested on x86_64 for unix/ and unix/-m32.
Build and reg-tested on x86_64 for unix/fpic and unix/fpic/-m32.
Approved here ( https://gcc.gnu.org/bugzilla/show_bug.cgi?i
On 30-01-15 20:49, Uros Bizjak wrote:
Hello!
Attached patch adds nonpic target requirement for some (obvious)
cases, where data access or PIC register setup confuses scan-asms.
2015-01-30 Uros Bizjak
* gcc.target/i386/fuse-caller-save-rec.c: Require nonpic target.
* gcc.target/i38
On Thu, Mar 12, 2015 at 10:50 AM, Ilya Enkovich wrote:
>> > > > Test O2 ref patchedOfast + LTO ref patched
>> > > > 164.gzip12 0 (-100%)39 0 (-100%)
>> > > > 175.vpr 0 0 (-0%) 4 0 (-100%)
>> > > > 176.gcc 141
On Thu, Mar 12, 2015 at 11:41 AM, Tom de Vries wrote:
Attached patch adds nonpic target requirement for some (obvious)
cases, where data access or PIC register setup confuses scan-asms.
2015-01-30 Uros Bizjak
* gcc.target/i386/fuse-caller-save-rec.c: Require
On 10 Mar 19:08, Uros Bizjak wrote:
> Hello!
>
> > > > Test O2 ref patchedOfast + LTO ref patched
> > > > 164.gzip12 0 (-100%)39 0 (-100%)
> > > > 175.vpr 0 0 (-0%) 4 0 (-100%)
> > > > 176.gcc 141 6 (-96%)
On Thu, Mar 12, 2015 at 9:11 AM, Tom de Vries wrote:
>> Attached patch adds nonpic target requirement for some (obvious)
>> cases, where data access or PIC register setup confuses scan-asms.
>>
>> 2015-01-30 Uros Bizjak
>>
>> * gcc.target/i386/fuse-caller-save-rec.c: Require nonpic target
Hi Guys,
The patch below updates the 20101011-1.c test in the gcc testsuite to
add a few more targets whose (simulated) runtime does not support
trapping on division by zero.
OK to apply ?
Cheers
Nick
gcc/testsuite/ChangeLog
2015-03-12 Nick Clifton
* gcc.c-torture/execute/
Hi,
Currently cgraph merge has several issues with instrumented code:
- original function node may be removed => no assembler name conflict is
detected between function and variable
- only orig_decl name is privatized for instrumented function => node still
shares assembler name which causes i
On 12-03-15 10:57, Uros Bizjak wrote:
On Thu, Mar 12, 2015 at 9:11 AM, Tom de Vries wrote:
Attached patch adds nonpic target requirement for some (obvious)
cases, where data access or PIC register setup confuses scan-asms.
2015-01-30 Uros Bizjak
* gcc.target/i386/fuse-caller-save-re
On 03/04/2015 11:00 AM, Marat Zakirov wrote:
Hi all!
Here is the patch which forces ASan to work on memory access without
proper alignment. it's useful because some programs like linux kernel
often cheat with alignment which may cause false negatives. This patch
needs additional support for
This backports the fixes for PR target/64304 , miscompilation with
-mgeneral-regs-only, to the 4.8 & 4.9 branch from trunk r219844.
Tested on x86_64 by using qemu of aarch64.
OK for 4.8 & 4.9 ?
---gcc-4.8---
diff -rupN gcc-4.8-20150226/gcc/Ch
On Thu, Mar 12, 2015 at 11:51:51AM +0300, Ilya Enkovich wrote:
> On 09 Mar 15:51, Jakub Jelinek wrote:
> > On Mon, Mar 02, 2015 at 01:25:43PM +0300, Ilya Enkovich wrote:
> > > > --- a/gcc/toplev.c
> > > > +++ b/gcc/toplev.c
> > > > @@ -1376,6 +1376,11 @@ process_options (void)
> > > > {
> > >
On Tue, 10 Mar 2015, Richard Biener wrote:
> On Tue, 10 Mar 2015, Richard Biener wrote:
>
> >
> > This removes the old vestige loop to find a gsi for a stmt (from times
> > where gsi_for_stmt was O(n)).
> >
> > PR44563 shows gimple_split_block quite high in the profile (this
> > patch doesn't f
Hi Jiangjiji,
This is definitely stage 1 material by now...
At my glance it all looks like the right approach, I have a question below:
On 12/03/15 09:20, Jiangjiji wrote:
+
+(define_insn "aarch64_fmulx_lane"
+ [(set (match_operand:VDQF 0 "register_operand" "=w")
+(unspec:VDQF [(match
This just updates the status link on the homepage from the 4.9.2-rc1
announcement to the final release announcement a week later.
Committed to CVS.
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revis
On Tue, 10 Mar 2015, Richard Biener wrote:
>
> CFG cleanup currently searches for calls that became noreturn and
> fixes them up (splitting block and removing the fallthru). Previously
> that was technically necessary as propagation may have turned an
> indirect call into a direct noreturn call
On 09 Mar 15:51, Jakub Jelinek wrote:
> On Mon, Mar 02, 2015 at 01:25:43PM +0300, Ilya Enkovich wrote:
> > > --- a/gcc/toplev.c
> > > +++ b/gcc/toplev.c
> > > @@ -1376,6 +1376,11 @@ process_options (void)
> > > {
> > >if (targetm.chkp_bound_mode () == VOIDmode)
> > > error ("-f
2015-03-12 12:02 GMT+03:00 Jakub Jelinek :
> On Thu, Mar 12, 2015 at 11:51:51AM +0300, Ilya Enkovich wrote:
>> On 09 Mar 15:51, Jakub Jelinek wrote:
>> > On Mon, Mar 02, 2015 at 01:25:43PM +0300, Ilya Enkovich wrote:
>> > > > --- a/gcc/toplev.c
>> > > > +++ b/gcc/toplev.c
>> > > > @@ -1376,6 +1376,
Hi,
This is a ping for: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00775.html
Regtested with aarch64-linux-gnu on QEMU.
This patch has no regressions for aarch64_be-linux-gnu big-endian target too.
OK for the trunk? Thanks.
Index: gcc/ChangeLog
===
On Wed, Dec 18, 2013 at 09:53:38AM -0500, David Edelsohn wrote:
https://gcc.gnu.org/ml/gcc-patches/2013-12/msg01599.html
> Why change the code from swapping the words at the initial
> change_address() to swapping the words in the call to gen_bswapsi2()?
Sorry for dropping this on the floor for so
Hi,
Instrumented function pointer may be propagated into not instrumented indirect
call and vice versa. It requires additional call modifications (either remove
bounds or change callee). Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK for trunk?
Thanks,
Ilya
--
gcc/
2015-03-12 Il
James Greenhalgh wrote:
> On Wed, Mar 11, 2015 at 04:24:07PM +, Ramana Radhakrishnan wrote:
> >
> > >
> > > Attached patch as text.
> > >
> > > 2015-03-11 Junmo Park
> > >
> > > * config/arm/cortex-a57.md (cortex_a57_crypto_simple): Add
> > > crypto_sha256_fast.
> > >
Attached patch as text.
2015-03-11 Junmo Park
* config/arm/cortex-a57.md (cortex_a57_crypto_simple): Add
crypto_sha256_fast.
(cortex_a57_crypto_complex): Add crypto_sha256_slow.
Ok to commit to trunk?
OK, Thanks Sebastian.
regards
Ramana
Thanks,
Sebastia
On 03/11/15 08:44, David Edelsohn wrote:
On Mon, Mar 9, 2015 at 7:30 PM, Michael Meissner
wrote:
This bug was one I unfortunately introduced with the -mupper-regs support. If
the reload pass needed to reload a PLUS operation (for example, due to using
odd address with the LD/STD instructions),
Hi Jakub,
with my OPC UA Server, I observe a reproducible crash in
ScopedReport::AddThread: tctx==NULL
in "if ((u32)rep_->threads[i]->id == tctx->tid)".
Apparently, Dmitry has already fixed that in the obvious way.
So we should cherry pick these two changes from LLVM: 224508 and 224755
See atta
current trunk fails to build on x86*-linux, when configured for x32 multilibs
because libmpx doesn't support these. Disable them.
ok for the trunk?
* Disable libmpx x32 multilib builds.
--- a/config-ml.in
+++ b/config-ml.in
@@ -102,6 +102,7 @@
Makefile=${ac_file-Makefile}
ml_config_she
On 05/02/15 11:28 +, Renlin Li wrote:
Hi all,
This patch simply remove the target selector. It should pass for all target
which applies.
The comment in the code is not correct. stderr is redirected, not the stdout.
Therefore, the return status which is streamed into stdout should properly
On 03/10/2015 01:03 PM, Paolo Carlini wrote:
Good question, but we don't have this issue, because for that we emit
anyway:
65370.C:11:36: error: default argument specified in explicit
specialization [-fpermissive]
C::C(const C&, bool = false);
nothing changes about that kind of testcase, usua
Hello!
> > > Test O2 ref patchedOfast + LTO ref patched
> > > 164.gzip12 0 (-100%)39 0 (-100%)
> > > 175.vpr 0 0 (-0%) 4 0 (-100%)
> > > 176.gcc 141 6 (-96%) 294 10 (-97%)
> > > 181.mcf
On 11/03/2015 02:11, 박준모 wrote:
> Hi all,
>
> This patch only affect sha2 crypto instruction's order when gcc
> performs instruction scheduling(rtl-sched1,2).
>
> There are no definition for crypto_sha256_fast, crypto_sha256_slow on
> "cortex-a57.md".
>
> This makes poor result of instructio
I'd like to backport the following patch that suppresses bogus ubsan errors.
I had to tweak the testcase a bit since 4.9 doesn't know -fno-sanitize-recover.
Bootstrapped/regtested on x86_64-linux, ok for 4.9?
2015-03-10 Marek Polacek
Backported from mainline
2014-12-04 Marek
> On Mon, 16 Feb 2015, James Bowman wrote:
>
> > I have updated the target options. Space-saving is now enabled by
> > -Os. There is also a new option -msim to enable building for the
> > simulator (the simulator is pending submission to gdb-binutils).
>
> The documentation in this patch doesn't
60 matches
Mail list logo
