Eric Botcazou writes:
>> Thanks, and to Bernd for the review. I went ahead and applied it to trunk.
>
> Thanks. We need something for the 4.8 branch as well, probably the
> builtins.c
> hunk and the reversion of the cse.c/cselib.c/dse.c changes to the 4.7 state.
OK, how about this? It looks
On Thu, Mar 13, 2014 at 07:15:34AM +, Richard Sandiford wrote:
> Eric Botcazou writes:
> >> Thanks, and to Bernd for the review. I went ahead and applied it to trunk.
> >
> > Thanks. We need something for the 4.8 branch as well, probably the
> > builtins.c
> > hunk and the reversion of the
Hi!
On Wed, 12 Mar 2014 14:48:03 +0100, I wrote:
> On Wed, 4 Sep 2013 20:54:47 +0200, Jakub Jelinek wrote:
> > This patch implements #pragma omp {target{, data, update},teams} lowering
> > and expansion, and adds stub calls into libgomp, so that (for now
> > unconditionally) we can at least alway
2014-03-12 17:35 GMT+04:00 Georg-Johann Lay :
> This fixes a problem because cc_plus and cc_minus are in the wrong places in
> calls of avr_out_plus_1. This is important when avr_out_plus is called from
> notice_update_cc. This means that cc_status might be determined
> incorrectly.
>
> In the va
Hi,
This patch adds initial set of tests and dg infrastructure for
LeakSanitizer runtime.
Tested on x86_64.
Ok to commit?
-Maxim
2014-03-13 Max Ostapenko
* c-c++-common/lsan/fork.c: New test.
* c-c++-common/lsan/ignore_object.c: New test.
* c-c++-common/lsan/ignore_object_errors.c: Ne
On Wed, 12 Mar 2014, Rainer Orth wrote:
> Richard Biener writes:
>
> > On Mon, 10 Mar 2014, Rainer Orth wrote:
> >
> >> Richard Biener writes:
> >>
> >> > Ouch. But as lto-plugin is a host module it should link against
> >> > the host libgcc, no? During stage1, that is. So the question is
>
Hi,
fixes the LRA problems described in:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60501
and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604
Bootstrapped and regtested on s390, s390x, and x86_64.
Ok?
Bye,
-Andreas-
2014-03-13 Andreas Krebbel
PR rtl-optimization/60501
*
On Wed, 12 Mar 2014, Jakub Jelinek wrote:
> Hi!
>
> Apparently 435.gromacs benchmark is very sensitive (of course with
> -ffast-math) to reassociation ordering.
>
> We were sorting on SSA_NAME_VERSIONs, which has the disadvantage that we
> reuse SSA_NAME_VERSIONs from SSA_NAMEs dropped by earlie
On Wed, 12 Mar 2014, Cong Hou wrote:
> Thank you for pointing it out. I didn't realized that alias analysis
> has influences on this issue.
>
> The current problem is that the epilogue may be unnecessary if the
> loop bound cannot be larger than the number of iterations of the
> vectorized loop m
On Thu, Mar 13, 2014 at 10:25:57AM +0100, Richard Biener wrote:
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> Ok. Does this also fix the PPC regression?
That is a question for Peter, if we can ask him to test it.
>From what I understood, the bug no longer reproduce
On Thu, Mar 13, 2014 at 1:10 AM, Cesar Philippidis
wrote:
> I noticed that the lto-wrapper is a little noisy without the -v option
> when -save-temps is used. E.g.,
>
> $ gcc main.c -flto -save-temps
> [Leaving LTRANS /tmp/ccSEvaB7.args]
> [Leaving LTRANS /tmp/ccQomDzb.ltrans.out]
> [Leaving LTRAN
Committed as r208533.
--
Ilmir.
Richard Biener writes:
>> > So then if it succeeds to link to a shared libgcc_s then why
>> > is it not able to find that later? Maybe you miss setting
>> > of a suitable LD_LIBRARY_PATH to pick up the runtime for
>> > your host compiler?
>>
>> For the same reason that we use -static-libstdc++
While trying cleanup-saved-temps in a LTO testcase (which of course
doesn't work ... error executing dg-final: bad level "5" (!??)) I
ran into a TCL error printing the error - we use bogus variables.
Fixed as obvious.
Richard.
2014-03-13 Richard Biener
* lib/lto.exp (lto-execute): F
On Thu, Mar 13, 2014 at 10:24:13AM +0100, Andreas Krebbel wrote:
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -4720,6 +4720,17 @@ Add operand 2 and operand 1, storing the result in
> operand 0. All operands
> must have mode @var{m}. This can be used even on two-address machines, by
> m
Ping!
On 03/06/2014 07:44 PM, Dimitris Papavasiliou wrote:
Ping!
On 02/27/2014 11:44 AM, Dimitris Papavasiliou wrote:
Ping!
On 02/20/2014 12:11 PM, Dimitris Papavasiliou wrote:
Hello all,
Pinging this patch review request again. See previous messages quoted
below for details.
Regards,
Dimi
On Thu, Mar 13, 2014 at 10:31 AM, Richard Biener
wrote:
> On Thu, Mar 13, 2014 at 1:10 AM, Cesar Philippidis
> wrote:
>> I noticed that the lto-wrapper is a little noisy without the -v option
>> when -save-temps is used. E.g.,
>>
>> $ gcc main.c -flto -save-temps
>> [Leaving LTRANS /tmp/ccSEvaB7.
On Thu, 13 Mar 2014, Rainer Orth wrote:
> Richard Biener writes:
>
> >> > So then if it succeeds to link to a shared libgcc_s then why
> >> > is it not able to find that later? Maybe you miss setting
> >> > of a suitable LD_LIBRARY_PATH to pick up the runtime for
> >> > your host compiler?
> >>
On 12/03/14 22:35, Hán Shěn (沈涵) wrote:
> ARM build (on chrome) is broken because of duplicate entries in arm.md
> and unspecs.md. Fixed by removing duplication and merge those in
> arm.md into unspecs.md.
>
> (We had a similar fix for google/gcc-4_8 here -
> http://gcc.gnu.org/viewcvs/gcc?view=re
Richard Biener writes:
>> Exactly my words. But gcc provides zero help for that. All proposed
>> workarounds (having every user of gcc set LD_LIBRARY_PATH, messing
>> around with ldconfig or equivalent, having every single compiler user
>> provide -rpath/-R on his own) are usability or function
Committed.
Index: htdocs/gcc-4.9/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/porting_to.html,v
retrieving revision 1.4
diff -u -r1.4 porting_to.html
--- htdocs/gcc-4.9/porting_to.html 7 Mar 2014 19:45:14 -
Hello!
When compiling regex.c from libiberty, several warnings are emitted:
../../gcc-svn/trunk/libiberty/regex.c: In function 'byte_regex_compile':
../../gcc-svn/trunk/libiberty/regex.c:154:47: warning: right-hand
operand of comma expression has no effect [-Wunused-value]
# define bzero(s,
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -4720,6 +4720,17 @@ Add operand 2 and operand 1, storing the result in
> operand 0. All operands must have mode @var{m}. This can be used even on
> two-address machines, by means of constraints requiring operands 1 and 0 to
> be the same locati
This makes sure we simplify an expression before giving up because
the caller only expects a singleton result. Otherwise patterns like
(match_and_simplify
(plus @0 integer_zerop)
@0)
(match_and_simplify
(plus (plus @0 INTEGER_CST_P@1) INTEGER_CST_P@2)
(plus @0 (plus @1 @2)))
that expec
On 13/03/14 12:16, Eric Botcazou wrote:
>> --- a/gcc/doc/md.texi
>> +++ b/gcc/doc/md.texi
>> @@ -4720,6 +4720,17 @@ Add operand 2 and operand 1, storing the result in
>> operand 0. All operands must have mode @var{m}. This can be used even on
>> two-address machines, by means of constraints requi
On Thu, Mar 13, 2014 at 12:16 PM, Eric Botcazou wrote:
>> --- a/gcc/doc/md.texi
>> +++ b/gcc/doc/md.texi
>> @@ -4720,6 +4720,17 @@ Add operand 2 and operand 1, storing the result in
>> operand 0. All operands must have mode @var{m}. This can be used even on
>> two-address machines, by means of c
On 13/03/14 12:25, Richard Biener wrote:
> On Thu, Mar 13, 2014 at 12:16 PM, Eric Botcazou wrote:
>>> --- a/gcc/doc/md.texi
>>> +++ b/gcc/doc/md.texi
>>> @@ -4720,6 +4720,17 @@ Add operand 2 and operand 1, storing the result in
>>> operand 0. All operands must have mode @var{m}. This can be used
Hi Ilmir!
On Thu, 13 Mar 2014 13:34:54 +0400, Ilmir Usmanov wrote:
> Committed as r208533.
Yay! \o/
Three minor things:
Please move the entries from gcc/ChangeLog.gomp to the more specific
gcc/[...]/ChangeLog.gomp files. Generally, we need to locate and then
put ChangeLog snippets into the
On Thu, 2014-03-13 at 10:30 +0100, Jakub Jelinek wrote:
> On Thu, Mar 13, 2014 at 10:25:57AM +0100, Richard Biener wrote:
> > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >
> > Ok. Does this also fix the PPC regression?
>
> That is a question for Peter, if we can ask
Hi Thomas!
On 13.03.2014 15:38, Thomas Schwinge wrote:
Hi Ilmir!
On Thu, 13 Mar 2014 13:34:54 +0400, Ilmir Usmanov wrote:
Committed as r208533.
Yay! \o/
Thanks! Yay indeed.
And thanks a lot for your comments.
The following change seems the right thing to do -- but why doesn't the
curre
This is again a request for approval to fix PR59396.
Problem is that the assembler name might or might not be prefixed by '*'
depending on when TARGET_SET_CURRENT_FUNCTION is called.
The change is just to fix wrong warning because the current implementation of
TARGET_SET_CURRENT_FUNCTION /alw
Hi,
this 4.9 regression is again an ICE during error recovery:
check_specialization_namespace errors out,
maybe_process_partial_specialization doesn't check its return value, and
the ICE happens much later, in retrieve_specialization, in the gcc_assert:
/* There should be as many levels of
On 03/13/2014 12:33 PM, Maxim Ostapenko wrote:
Hi,
This patch adds initial set of tests and dg infrastructure for
LeakSanitizer runtime.
Tested on x86_64.
Ok to commit?
-Maxim
Fixed subject.
2014-03-13 Max Ostapenko
* c-c++-common/lsan/fork.c: New test.
* c-c++-common/lsan/ignore_o
On 13.03.2014 16:19, Ilmir Usmanov wrote:
The following change seems the right thing to do -- but why doesn't the
current code trigger a GCC ICE due to a failing subcode check? (At least
I thought you had test cases exercising the respective OpenACC vector
clauses?) Can you please check that?
Committed.
Richard.
2014-03-13 Richard Biener
* gimple-match-head.c (gimple_resimplify2, gimple_resimplify3):
Implement missing call handling.
(gimple_match_and_simplify): Fix lhs gathering.
Index: gcc/gimple-match-head.c
=
This "physically" separates forwprop and combining all stmts to
allow an easy lattice implementation.
Committed.
Richard.
2014-03-13 Richard Biener
* tree-ssa-forwprop.c (ssa_forward_propagate_and_combine):
Split out combining with gimple_match_and_simplify to a
sepa
On 03/13/2014 06:43 AM, Peter Bergner wrote:
On Thu, 2014-03-13 at 10:30 +0100, Jakub Jelinek wrote:
>On Thu, Mar 13, 2014 at 10:25:57AM +0100, Richard Biener wrote:
> > >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >
> >Ok. Does this also fix the PPC regression?
>
On Thu, Mar 13, 2014 at 09:53:47AM -0500, Pat Haugen wrote:
> On 03/13/2014 06:43 AM, Peter Bergner wrote:
> >On Thu, 2014-03-13 at 10:30 +0100, Jakub Jelinek wrote:
> >>>On Thu, Mar 13, 2014 at 10:25:57AM +0100, Richard Biener wrote:
> > > >Bootstrapped/regtested on x86_64-linux and i686-linux
The following finishes call matching support (see the added pattern
and the testcase amendment). It also adds basic support for
matching GENERIC expressions and calls - to eventually handle
the weird case of GIMPLE containing a GENERIC tcc_comparison
as operand zero of a COND_EXPR rhs.
Committed
OK.
Jason
Hi!
I've been told that the SC has approved the secondary platform list changes,
so I went ahead and committed the changes to our web pages.
--- gcc-4.9/criteria.html 15 Mar 2013 16:39:45 - 1.1
+++ gcc-4.9/criteria.html 13 Mar 2014 15:01:00 -
@@ -110,12 +110,12 @@ applica
On 03/13/14 09:02, Jakub Jelinek wrote:
Hi!
I've been told that the SC has approved the secondary platform list changes,
so I went ahead and committed the changes to our web pages.
Thanks. I should have taken care of this a few weeks ago when the
decision was made.
Hopefully everyone realize
On Wed, Mar 12, 2014 at 10:52 PM, Wei Mi wrote:
> I saw the problem last patch had on ia32. Without explicit call in rtl
> template, scheduler may schedule the sp adjusting insn across tls
> descriptor and break the alignment assumption.
> I am testing the updated patch on x86_64.
>
> Can we combi
pr58066-2.patch worked for pr58066.c on ia32/x32/x86_64, but it failed
on bootstrap.
/usr/local/google/home/wmi/workarea/gcc-r208410-2/build/./gcc/xgcc
-B/usr/local/google/home/wmi/workarea/gcc-r208410-2/build/./gcc/
-B/usr/local/google/home/wmi/workarea/gcc-r208410-2/build/install/x86_64-unknown-
>
> My ia32 change generates much worse code:
>
> [hjl@gnu-6 gcc]$ cat /tmp/c.i
> static __thread char ccc, bbb;
>
> int __cxa_get_globals()
> {
> return &ccc - &bbb;
> }
> [hjl@gnu-6 gcc]$ ./xgcc -B./ -S -O2 -fPIC /tmp/c.i
> [hjl@gnu-6 gcc]$ cat c.s
> .file "c.i"
> .section .text.unlikely,"ax",@p
On Thu, Mar 13, 2014 at 02:24:06PM +0100, Georg-Johann Lay wrote:
>
> Problem is that the assembler name might or might not be prefixed by '*'
> depending on when TARGET_SET_CURRENT_FUNCTION is called.
>
> The change is just to fix wrong warning because the current implementation
> of TARGET_SET_
This fixes a flaw in the mechanism implemented to register modes and types
declared in the back-end with the front-end. The mechanism was implicitly
making the assumption that it is possible to deduce the size of a FP mode
from its precision and alignment; that's wrong in the general case, although
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57189
The patch was successfully bootstrapped and tested on x86-64.
Committed as rev. 208549.
2014-03-13 Vladimir Makarov
PR rtl-optimization/57189
* lra-constraints.c (process_alt_operands): Disfavo
Hi,
the reference re-building part of ipa_modify_call_arguments has a
stupid bug in the while loop condition, which means it does not look
at statements produced by force_gimple_operand_gsi which may lead to
bugs such as PR 60461.
The 4.8 branch does not have this code and does not exhibit the bu
On Thu, Mar 13, 2014 at 04:56:12PM +0100, Martin Jambor wrote:
> PR lto/60461
> * ipa-prop.c (ipa_modify_call_arguments): Fix iteration condition.
>
> testsuite/
> * gcc.dg/lto/pr60461_0.c: New test.
>
> diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
> index 4fb916a..efe8c7a 10064
On Mar 13, 2014, at 11:36, Eric Botcazou wrote:
> This fixes a flaw in the mechanism implemented to register modes and types
> declared in the back-end with the front-end. The mechanism was implicitly
> making the assumption that it is possible to deduce the size of a FP mode
> from its precisio
> On 03/11/2014 05:08 PM, Jan Hubicka wrote:
> >Jason, I was looking into this and I think I have patch that works. I would
> >just like to verify I inderstnad things right. First thing I implemented is
> >to
> >consistently skip dtors of abstract classes as per the comment in
> >abstract_class_
On 07.03.2014 15:37, Ilmir Usmanov wrote:
Hi Thomas!
I prepared simple patch to add support of OpenACC data, kernels and
parallel constructs to C++ FE.
It adds support of data clauses too.
OK to gomp4 branch?
Fixed subject: changed file extensions of tests and fixed comments.
OK to gomp4
> I tried pr58066-3.patch on the above testcase, the code it generated
> seems ok. I think after we change the 32bits pattern in i386.md to be
> similar as 64bits pattern, we should change 32bit expand to be similar
> as 64bit expand in legitimize_tls_address too?
>
> Thanks,
> Wei.
>
Sorry, I pas
On Thu, Mar 13, 2014 at 3:36 AM, Uros Bizjak wrote:
>
> Attached patch changes the return value of the bzero macro to void, as
> defined in a 4.3BSD:
>
>void bzero(void *s, size_t n);
>
> As an additional benefit, the changed macro now generates warning when
> its return value is used (whi
Am 03/13/2014 04:41 PM, schrieb Senthil Kumar Selvaraj:
On Thu, Mar 13, 2014 at 02:24:06PM +0100, Georg-Johann Lay wrote:
Problem is that the assembler name might or might not be prefixed by '*'
depending on when TARGET_SET_CURRENT_FUNCTION is called.
The change is just to fix wrong warning be
On Thu, Mar 13, 2014 at 05:19:02PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 13, 2014 at 04:56:12PM +0100, Martin Jambor wrote:
> > PR lto/60461
> > * ipa-prop.c (ipa_modify_call_arguments): Fix iteration condition.
> >
> > testsuite/
> > * gcc.dg/lto/pr60461_0.c: New test.
> >
> > di
Hi!
The outer-1.c testcase apparently fails on 32-bit HWI targets, the problem
is that the int x[1][1]; array has bitsize that fits into uhwi, but
not shwi, so we get negative maxsize that isn't -1.
After discussions with Richard on IRC, I've implemented computation of
bitsize and maxsize
> Can we combine the last two patches, both adding call explicitly in
> rtl template for tls_local_dynamic_base_32/tls_global_dynamic_32, and
> set ix86_tls_descriptor_calls_expanded_in_cfun to true only after
> reload complete?
>
Hi H.J.
I attached the patch which combined your two patches and t
Hi!
We get bogus warning on the -1 and -4 testcases.
The problem is that we accept without warning an __asm rename like:
extern void *baz (void *dest, const void *src, __SIZE_TYPE__ n);
extern __typeof (baz) baz __asm("bazfn");
only if it doesn't have DECL_ASSEMBLER_NAME_SET_P yet, after it is
set
On Thu, Mar 13, 2014 at 10:55 AM, Wei Mi wrote:
>> Can we combine the last two patches, both adding call explicitly in
>> rtl template for tls_local_dynamic_base_32/tls_global_dynamic_32, and
>> set ix86_tls_descriptor_calls_expanded_in_cfun to true only after
>> reload complete?
>>
>
> Hi H.J.
>
On Fri, May 17, 2013 at 03:59:07PM -0600, Jeff Law wrote:
> On 05/17/2013 03:53 PM, Steven Bosscher wrote:
> >On Fri, May 17, 2013 at 11:16 PM, Jeff Law wrote:
> >>>What's happened, is that emitting the epilogue at the end of basic
> >>>block 4 (with a barrier at the end) has made the use insn 43
>
Thanks Richard, I'll remove UNSPEC_SIN/COS from my patch.
Han
On Thu, Mar 13, 2014 at 3:07 AM, Richard Earnshaw wrote:
> On 12/03/14 22:35, Hán Shěn (沈涵) wrote:
>> ARM build (on chrome) is broken because of duplicate entries in arm.md
>> and unspecs.md. Fixed by removing duplication and merge th
Ping.
On Tue, Mar 04, 2014 at 05:40:29PM +0100, Marek Polacek wrote:
> This should fix ICE on insane alignment. Normally, check_user_alignment
> detects e.g. alignment 1 << 32, but not 1 << 28. However, record_align
> is in bits, so it's actually 8 * (1 << 28) and that's greater than
> INT_MAX.
Hi Jakub,
Is this change different from the one attached to PR? I have a
bootstrap/regtest
going with it.
Dave
On 3/13/2014 1:50 PM, Jakub Jelinek wrote:
Hi!
The outer-1.c testcase apparently fails on 32-bit HWI targets, the problem
is that the int x[1][1]; array has bitsize that f
On Thu, Mar 13, 2014 at 02:13:39PM -0400, John David Anglin wrote:
> Is this change different from the one attached to PR? I have a
> bootstrap/regtest
> going with it.
Yes, the one attached to the PR had major bugs, in two spots replaced
if (maxsize == -1
with
if (!maxsize.is_minus_one ()
ra
On Thu, Mar 13, 2014 at 6:30 PM, Ian Lance Taylor wrote:
> On Thu, Mar 13, 2014 at 3:36 AM, Uros Bizjak wrote:
>>
>> Attached patch changes the return value of the bzero macro to void, as
>> defined in a 4.3BSD:
>>
>>void bzero(void *s, size_t n);
>>
>> As an additional benefit, the chang
On Thu, Mar 13, 2014 at 11:24 AM, Uros Bizjak wrote:
> On Thu, Mar 13, 2014 at 6:30 PM, Ian Lance Taylor wrote:
>> On Thu, Mar 13, 2014 at 3:36 AM, Uros Bizjak wrote:
>>>
>>> Attached patch changes the return value of the bzero macro to void, as
>>> defined in a 4.3BSD:
>>>
>>>void bzero
2014-03-13 21:41 GMT+04:00 Georg-Johann Lay :
> Am 03/13/2014 04:41 PM, schrieb Senthil Kumar Selvaraj:
>
>> On Thu, Mar 13, 2014 at 02:24:06PM +0100, Georg-Johann Lay wrote:
>>>
>>>
>>> Problem is that the assembler name might or might not be prefixed by '*'
>>> depending on when TARGET_SET_CURREN
On March 13, 2014 6:50:53 PM CET, Jakub Jelinek wrote:
>Hi!
>
>The outer-1.c testcase apparently fails on 32-bit HWI targets, the
>problem
>is that the int x[1][1]; array has bitsize that fits into uhwi,
>but
>not shwi, so we get negative maxsize that isn't -1.
>
>After discussions with Ri
Am 03/13/2014 07:36 PM, schrieb Denis Chertykov:
2014-03-13 21:41 GMT+04:00 Georg-Johann Lay:
Am 03/13/2014 04:41 PM, schrieb Senthil Kumar Selvaraj:
On Thu, Mar 13, 2014 at 02:24:06PM +0100, Georg-Johann Lay wrote:
Problem is that the assembler name might or might not be prefixed by '*'
de
The original ICE is caused by the dwarf2cfi pass not noticing a stack
adjustment in the insn stream. The reason for the miss is that the push/pop
was added by a post-reload splitter, which did nothing to mark the insn for
special treatment.
In the PR, Jakub and I threw around several ideas.
My f
On Thu, 13 Mar 2014, Jakub Jelinek wrote:
> 2014-03-13 Jakub Jelinek
>
> PR middle-end/36282
> * c-pragma.c (apply_pragma_weak): Only look at
> TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl)) if
> DECL_ASSEMBLER_NAME_SET_P (decl).
> (maybe_apply_pending_pragma
Hello,
Le 10/03/2014 03:15, jimmie.da...@l-3com.com a écrit :
> Index: gcc/gcc/fortran/symbol.c
> ===
> --- gcc/gcc/fortran/symbol.c (revision 208437)
> +++ gcc/gcc/fortran/symbol.c (working copy)
> @@ -3069,56 +3069,56 @@
>
>
On 03/13/2014 10:36 AM, Uros Bizjak wrote:
> +# define bzero(s, n)(memset (s, '\0', n), (void) 0)
AFAICS, the comma operator was only needed because of the
intention to return 's'. If 's' is not be returned, then simply
# define bzero(s, n) ((void) memset (s, '\0', n))
shoul
On Thu, Mar 13, 2014 at 10:24 PM, Pedro Alves wrote:
> On 03/13/2014 10:36 AM, Uros Bizjak wrote:
>> +# define bzero(s, n)(memset (s, '\0', n), (void) 0)
>
> AFAICS, the comma operator was only needed because of the
> intention to return 's'. If 's' is not be returned, then simply
>
> #
This patch adds a test case for PR c++/53711 which seems to have been
resolved by r199906.
PR c++/53711
* d++.dg/warn/anonymous-namespace-6.C: New test.
---
gcc/testsuite/g++.dg/warn/anonymous-namespace-6.C | 8
1 file changed, 8 insertions(+)
create mode 100644 gcc/test
This patch fixes PR rtl-optimization/60155.
The PA backend has a number of INSN patterns which trap on signed
overflow. These are
implemented as parallels using the trap_if code. Currently,
single_set does not consider
a parallel with a trap_if rtx to be a single set. This causes an ICE
On Thu, Mar 13, 2014 at 2:27 AM, Richard Biener wrote:
> On Wed, 12 Mar 2014, Cong Hou wrote:
>
>> Thank you for pointing it out. I didn't realized that alias analysis
>> has influences on this issue.
>>
>> The current problem is that the epilogue may be unnecessary if the
>> loop bound cannot be
On 3/13/14, 2:52 AM, Richard Biener wrote:
> On Thu, Mar 13, 2014 at 10:31 AM, Richard Biener
> wrote:
>> On Thu, Mar 13, 2014 at 1:10 AM, Cesar Philippidis
>> wrote:
>>> I noticed that the lto-wrapper is a little noisy without the -v option
>>> when -save-temps is used. E.g.,
>>>
>>> $ gcc main.
Committed to branch dmalcolm/jit:
gcc/jit/
* libgccjit.c (is_valid_cast): New.
(gcc_jit_context_new_cast): Check for compatible types.
* internal-api.c (gcc::jit::recording::memento_of_get_type::
is_int): New.
(gcc::jit::recording::memento_of_get_type::is_f
Ian Lance Taylor writes:
> The bug report http://golang.org/issue/7074 shows that math.Log2(1)
> produces the wrong result on Aarch64, because the Go math package is
> compiled to use a fused multiply-add instruction. This patch to the
> libgo configure script will use -ffp-contract=off when com
On Thu, Mar 13, 2014 at 6:27 PM, Michael Hudson-Doyle
wrote:
> Ian Lance Taylor writes:
>
>> The bug report http://golang.org/issue/7074 shows that math.Log2(1)
>> produces the wrong result on Aarch64, because the Go math package is
>> compiled to use a fused multiply-add instruction. This patch
Ian Lance Taylor writes:
> On Thu, Mar 13, 2014 at 6:27 PM, Michael Hudson-Doyle
> wrote:
>> Ian Lance Taylor writes:
>>
>>> The bug report http://golang.org/issue/7074 shows that math.Log2(1)
>>> produces the wrong result on Aarch64, because the Go math package is
>>> compiled to use a fused m
On Wed, Feb 5, 2014 at 2:29 AM, Venkataramanan Kumar
wrote:
> Hi Marcus,
>
>> + "ldr\\t%x2, %1\;str\\t%x2, %0\;mov\t%x2,0"
>> + [(set_attr "length" "12")])
>>
>> This pattern emits an opaque sequence of instructions that cannot be
>> scheduled, is that necessary? Can we not expand individual
>>
On Mon, 18 Nov 2013 19:04:59 +0100
Jan Hubicka wrote:
> Hi,
> this patch switches the default for fat-lto-objects as was documented for a
> while. -ffat-lto-objects doubles compilation time and often makes users to
> not notice that LTO was not used at all (because they forgot to use
> gcc-ar/gcc
2014-03-13 22:58 GMT+04:00 Georg-Johann Lay :
> Am 03/13/2014 07:36 PM, schrieb Denis Chertykov:
>>
>> 2014-03-13 21:41 GMT+04:00 Georg-Johann Lay:
>>>
>>> Am 03/13/2014 04:41 PM, schrieb Senthil Kumar Selvaraj:
>>>
On Thu, Mar 13, 2014 at 02:24:06PM +0100, Georg-Johann Lay wrote:
>
>
87 matches
Mail list logo
