Paul Pluzhnikov writes:
> Keying off NDEBUG rather than __OPTIMIZE__ seems like a more
> consistent approach -- if you want assert()s, then you probably also
> want these checks.
That's a bad idea. NDEBUG ("Be really slow unless the user has
positively defined this macro, whose use is rare enoug
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, June 04, 2013 11:49 PM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org; Steve Ellcey
> Subject: Re: [PATCH] pr57457
>
> On 06/04/13 12:58, Iyer, Balaji V wrote:
> >
> >
> > Actually, you can eliminate the
On 06/04/13 12:58, Iyer, Balaji V wrote:
Actually, you can eliminate the entire if-statement (i.e. remove
if-statement and make the body unconditional). This is because, if
flag_enable_cilkplus is true and is_cilkplus_reduce_builtin (fundecl)
is true, then it would have returned vec_safe_length
1) GCC uses the all-fields instruction instead of the one-field
form unless you use -mmfcrf (or -mcpu=power4, etc.), although
the one-field mfcr works fine on all CPUs and is never slower
(I'm not talking about mfocrf; just the plain mfcr instruction);
Ugh, need more coffee, forget about this on
We cannot avoid an mfcr then, either. It would be one machine
instruction shorter though (but can be more expensive to execute,
on some CPUs).
That you get two MFCRs on 64-bit is a target bug.
Not true there. If you look at the 64bit output you will see you are
using the one cr mfcr version i
Committed as 199680
If I'm reading things right, pass_update_address_taken is never actually
used.
Deleting it, I was able to still successfully bootstrap on
x86_64-unknown-linux-gnu (using gcc-4.7.2-2.fc17.x86_64).
The use of the pass appears to have been removed in:
http://gcc.gnu.org/r164525
Should I remove it
The table of struct tsan_map_atomic within tsan.c is never modified, so
it can be marked as const.
Successfully bootstrapped on x86_64-unknown-linux-gnu (using
gcc-4.7.2-2.fc17.x86_64).
OK for trunk?
2013-06-05 David Malcolm
* tsan.c (tsan_atomic_table): Make const.
Index: gcc/tsan.
On Tue, Jun 4, 2013 at 6:42 PM, Segher Boessenkool
wrote:
>> However, in looking at it, if we rewrite the code to have come from
>> comparisons:
>
>
>
>
>
>> _Bool bfoo_cmp (long w, long x, long y, long z)
>> {
>> _Bool a = (w < x);
>> _Bool b = (y < z);
>> _Bool r = ~a & b;
>> return r;
However, in looking at it, if we rewrite the code to have come from
comparisons:
_Bool bfoo_cmp (long w, long x, long y, long z)
{
_Bool a = (w < x);
_Bool b = (y < z);
_Bool r = ~a & b;
return r;
}
We get:
.L.bfoo_cmp:
cmpd 6,3,4
cmpd 7,5,6
mfcr 3,2
On Tue, 2013-06-04 at 15:43 -0600, Jeff Law wrote:
> On 06/04/2013 03:29 PM, David Malcolm wrote:
> > call_stmt_vars is only used inside of tree-ssa-structalias.c, so it can
> > be made static.
> >
> > Successfully bootstrapped on x86_64-unknown-linux-gnu (using
> > gcc-4.7.2-2.fc17.x86_64).
> >
>
Hi,
this ICE on valid happens in the cp_parser_abort_tentative_parse called
at the end of cp_parser_decltype_expr. I started seriously looking into
it when I noticed that a variant of the testcase not using variadic
templates is fine, thus I concentrated on
cp_parser_parameter_declaration and
attached is a testcase that would cause problem when source has changed:
$ g++ test.cc -O2 -fprofile-generate -DOLD
$ ./a.out
$ g++ test.cc -O2 -fprofile-use
test.cc:34:1: internal compiler error: in operator[], at vec.h:815
}
^
0x512740 vec::operator[](unsigned int)
../../gcc/vec.h:815
0x512740
Hi,
my changes to visibility flag broke on Mozilla in two interesting way. First
is ICE in get_alias_symbol. Until now I was not aware that C++ FE can create
same body aliases for external symbols. Most of the symtab code deals with it
as with weakrefs that works by accident rather than design.
On 2013-05-31 14:47 , Brooks Moses wrote:
Index: contrib/testsuite-management/validate_failures.py
===
--- contrib/testsuite-management/validate_failures.py(revision 199390)
+++ contrib/testsuite-management/validate_failures.py
On 06/04/2013 03:29 PM, David Malcolm wrote:
call_stmt_vars is only used inside of tree-ssa-structalias.c, so it can
be made static.
Successfully bootstrapped on x86_64-unknown-linux-gnu (using
gcc-4.7.2-2.fc17.x86_64).
OK for trunk?
2013-06-04 David Malcolm
* tree-ssa-structalias.
Ping.
On Thu, May 23, 2013 at 2:41 PM, Sriraman Tallam wrote:
> Ping, for review of ipa-inline.c change.
>
> Sri
>
> On Mon, May 20, 2013 at 11:04 AM, Sriraman Tallam wrote:
>> On Fri, May 17, 2013 at 11:21 PM, Jakub Jelinek wrote:
>>> On Fri, May 17, 2013 at 09:00:21PM -0700, Sriraman Tallam w
call_stmt_vars is only used inside of tree-ssa-structalias.c, so it can
be made static.
Successfully bootstrapped on x86_64-unknown-linux-gnu (using
gcc-4.7.2-2.fc17.x86_64).
OK for trunk?
2013-06-04 David Malcolm
* tree-ssa-structalias.c (call_stmt_vars): Make static.
Index: gcc/tr
This patch allows me to build libgfortran for a cross-compiling toolchain
using newlib. Currently the checks done by AC_CHECK_FUNCS_ONCE fail with
my toolchain because the compile/link fails due to the configure script not
using the needed linker script in the link command. The check for with_new
On 06/03/2013 08:23 AM, Kai Tietz wrote:
Btw there is one optimization in this context which might be something
worth here too.
-X -> X for 1-bit typed X (signed doesn't matter here).
I've had a hell of a time trying to trigger a case where this isn't
already handled. Samples welcome.
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, June 04, 2013 2:07 PM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org; Steve Ellcey
> Subject: Re: [PATCH] pr57457
>
> On 06/04/2013 11:37 AM, Iyer, Balaji V wrote:
> >
> > Yes, that does simplify the whol
Hi,
Sorry for the long delay. Test case added and patch attached. OK to commit?
Thanks
Sri
On Wed, May 22, 2013 at 5:14 PM, H.J. Lu wrote:
> On Wed, May 22, 2013 at 4:20 PM, Sriraman Tallam wrote:
>> Hi,
>>
>>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57362
>>
>>This ICE reported
2013/6/4 Jeff Law :
> On 06/04/2013 04:45 AM, Richard Biener wrote:
>>>
>>>
>>> Yes. Booleans are integral types with a single bit of precision, right?
>>> So
>>> this check should allow boolean types. What am I missing?
>>
>>
>> We have BOOLEAN_TYPEs that do not have a TYPE_PRECISION of one
>> (
On 06/04/2013 04:45 AM, Richard Biener wrote:
Yes. Booleans are integral types with a single bit of precision, right? So
this check should allow boolean types. What am I missing?
We have BOOLEAN_TYPEs that do not have a TYPE_PRECISION of one
(but still are two-valued, and we assume those va
On 06/04/2013 11:37 AM, Iyer, Balaji V wrote:
Yes, that does simplify the whole thing. Here is an updated ChangeLog
and patch (with testcode) attached. So, is it Ok for trunk?
gcc/testsuite/ChangeLog 2013-06-04 Balaji V. Iyer
PR C/57457 * c-c++-common/cilk-plus/AN/pr57457.c: New test.
gcc/c
"Jürgen Urban" writes:
> Hello Richard,
>
>> Thanks, looks good. The comments I have are only minor and seemed easier
>> to spell out as a revised patch, attached below. The changes are:
>>
>> * removing the config.sub bit, which looked redundant. We already have
>> the up-to-date upstream co
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Monday, June 03, 2013 3:07 PM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org; Steve Ellcey
> Subject: Re: [PATCH] pr57457
>
> On 05/31/2013 12:01 PM, Iyer, Balaji V wrote:
> >
> >
> >> -Original Message- F
On 05/24/2013 12:15 PM, Caroline Tice wrote:
Changes to g++spec.c only affect the g++ driver, not the gcc
driver. Are you sure this is what you want? Can't you handle
this stuff directly in the specs like address sanitizer does?
I haven't seen a response to this comm
Mike Stump wrote:
:-o, The things we never knew. Anyway, use of hacks like this, should
result in the hack being documented. At least then we can find them
with find-grep in emacs, and know about it. I'm not in favor of using
hacks like this, I don't endorse it. If someone wants to approve such
Hi, Dodji,
Thanks for helping update the patch. The new patch passed all
regression test and can fix the problem in my huge source file. I
added ChangeLog entry to the patch. Could any libcpp maintainers help
check if it is ok for trunk?
Thanks,
Dehao
libcpp/ChangeLog:
2013-06-04 Dehao Chen
ok.
David
On Tue, Jun 4, 2013 at 9:51 AM, Dehao Chen wrote:
> Patch updated to set the iteration threshold to 10 for AutoFDO.
> Performance test shows ok.
>
> OK for google-4_8 branch?
>
> Thanks,
> Dehao
>
> Index: gcc/ipa-inline.c
> =
[ sorry for the dup ]
On Jun 4, 2013, at 12:37 AM, Tobias Burnus wrote:
> I think some of the test cases might to it on purpose: "dg-do run" causes
> the test case to run only once while "dg-do run" runs multiple times with
> different options. If the testcase is supposed to test the run-time
On Jun 4, 2013, at 12:37 AM, Tobias Burnus wrote:
> I think some of the test cases might to it on purpose: "dg-do run" causes
> the test case to run only once while "dg-do run" runs multiple times with
> different options. If the testcase is supposed to test the run-time library,
> calling it
Patch updated to set the iteration threshold to 10 for AutoFDO.
Performance test shows ok.
OK for google-4_8 branch?
Thanks,
Dehao
Index: gcc/ipa-inline.c
===
--- gcc/ipa-inline.c (revision 199593)
+++ gcc/ipa-inline.c (working copy
On 06/04/2013 10:30 AM, Iyer, Balaji V wrote:
-Original Message-
From: Steve Ellcey [mailto:sell...@mips.com]
Sent: Monday, June 03, 2013 6:31 PM
To: Jeff Law
Cc: Iyer, Balaji V; gcc-patches@gcc.gnu.org
Subject: Re: [patch, testsuite, cilk] Fix cilk tests for simulators
On Mon, 2013-06-0
> -Original Message-
> From: Steve Ellcey [mailto:sell...@mips.com]
> Sent: Monday, June 03, 2013 6:31 PM
> To: Jeff Law
> Cc: Iyer, Balaji V; gcc-patches@gcc.gnu.org
> Subject: Re: [patch, testsuite, cilk] Fix cilk tests for simulators
>
> On Mon, 2013-06-03 at 13:47 -0600, Jeff Law wrote
Richard's question is that inlining should deal with extra arguments
just fine -- those paths (the insane profile case) won't be executed
anyway. Do you have a case showing otherwise (i.e., the mismatch
upsets the compiler?)
David
On Tue, Jun 4, 2013 at 8:07 AM, Dehao Chen wrote:
> On Tue, Jun
Hi Joseph,
> > It creates a command line option, -mrestrict-it, that can be used
> to
>
> Command-line options need documenting in invoke.texi.
I've added some documentation in invoke.texi
Confirmed that documentation builds ok.
Thanks,
Kyrill
2013-06-04 Kyrylo Tkachov
* config/a
On Jun 3, 2013, at 22:59 , Olivier Hainque wrote:
>> I suggest another approach: if there are significant differences between
>> the run-time systems, they ought to be preserved in the canonical target
>> names. So, adjust config.sub so that it preserve them, and then we can
>> decide based on t
On Tue, Jun 4, 2013 at 3:56 AM, Richard Biener
wrote:
>
> On Tue, Jun 4, 2013 at 2:55 AM, Dehao Chen wrote:
> > Hi,
> >
> > This patch was committed to google branch. But I think it is of
> > general interest. So is it ok for trunk?
> >
> > Thanks,
> > Dehao
> >
> > gcc/ChangeLog:
> >
> > 2013-06
On Tue, 4 Jun 2013, Kyrylo Tkachov wrote:
> It creates a command line option, -mrestrict-it, that can be used to
Command-line options need documenting in invoke.texi.
--
Joseph S. Myers
jos...@codesourcery.com
This patch allows the user to specify -mfp-in-toc/-msum-in-toc options
without being overridden when -fsection-anchors or -mcmodel != small
is in effect. I also change the default to -mno-fp-in-toc for
-mcmodel=medium, because -mcmodel=medium ought to be able to address
constants anywhere from the
On Tue, Jun 4, 2013 at 9:05 AM, Alan Modra wrote:
> ppc64 SFmode constants in the TOC occupy the first word of a dword.
> For little-endian, we don't need to shift left. Bootstrapped etc. and
> committed as obvious revision 199646.
>
> * config/rs6000/rs6000.c (output_toc): Correct little
On Tue, Jun 4, 2013 at 9:11 AM, Alan Modra wrote:
> This enables long double support for little-endian. It assumes we keep
> the same ordering as big-endian, ie. the first double is the larger
> magnitude or inf/nan. Bootstrapped powerpc64-linux. OK to apply?
>
> * config/rs6000/ibm-ld
This enables long double support for little-endian. It assumes we keep
the same ordering as big-endian, ie. the first double is the larger
magnitude or inf/nan. Bootstrapped powerpc64-linux. OK to apply?
* config/rs6000/ibm-ldouble.c: Enable for little-endian.
Index: libgcc/config/rs6
ppc64 SFmode constants in the TOC occupy the first word of a dword.
For little-endian, we don't need to shift left. Bootstrapped etc. and
committed as obvious revision 199646.
* config/rs6000/rs6000.c (output_toc): Correct little-endian float
constant output.
Index: gcc/config/rs
Hi all,
IT blocks in ARMv8 AArch32 Thumb mode are somewhat restricted.
They cannot contain more than one instruction, and that one instruction
has to be a 16-bit variant of a restricted subset of instructions.
ARMv7 IT blocks that don't fit in this category are allowed by ARMv8,
but are deprecated
Dehao Chen a écrit:
>> So, I'd say that in this hunk of your patch:
>>
>>> @@ -1002,7 +1002,8 @@ _cpp_stack_include (cpp_reader *pfile, const char
>>> linemap_add is not called) or we were included from the
>>> command-line. */
>>>if (file->pchname == NULL && file->err_no == 0
>>
On Tue, Jun 4, 2013 at 2:55 AM, Dehao Chen wrote:
> Hi,
>
> This patch was committed to google branch. But I think it is of
> general interest. So is it ok for trunk?
>
> Thanks,
> Dehao
>
> gcc/ChangeLog:
>
> 2013-06-03 Dehao Chen
>
> *gimple-low.c (gimple_check_call_args): Restrict the call_a
On Mon, Jun 3, 2013 at 8:34 PM, Jeff Law wrote:
> On 06/03/2013 12:32 PM, Kai Tietz wrote:
>>
>> 2013/6/3 Jeff Law :
>>>
>>> On 06/03/2013 11:00 AM, Richard Henderson wrote:
On 06/03/2013 09:37 AM, Kai Tietz wrote:
>
>
> foo:
> .seh_endprologue
>
On Mon, Jun 3, 2013 at 6:05 PM, Jeff Law wrote:
> On 06/03/2013 02:24 AM, Richard Biener wrote:
>>
>> On Fri, May 31, 2013 at 10:18 PM, Jeff Law wrote:
>>>
>>>
>>> This is an implementation to fix a missed optimization pointed out to me
>>> by
>>> Kai.
>>>
>>> In all these examples, assume a & b
Mikael Morin wrote:
+++ b/gcc/fortran/trans-decl.c
@@ -3872,7 +3892,8 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym,
gfc_wrapped_block * block)
/* Deallocate when leaving the scope. Nullifying is not
needed. */
- if (!sym->attr.result && !sym->attr
Ping^2?
Rebase it to trunk. Is it OK for trunk, 4.8 and 4.7?
Thanks!
-Zhenqiang
diff --git a/libgcc/config.host b/libgcc/config.host
index 0247bb0..d791797 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -331,10 +331,10 @@ arm*-*-linux*)# ARM GNU/Linux with
ELF
Le 03/06/2013 12:22, Tobias Burnus a écrit :
> * PING *
>
> Attached is just a re-diff.
>
> OK for the trunk?
>
Hello, it looks good; one question below...
> diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
> index 100ec18..7521dee 100644
> --- a/gcc/fortran/trans-decl.c
> +++ b/
On 3 June 2013 17:35, Ian Bolton wrote:
> 2013-06-03 Ian Bolton
>
> gcc/
> * config/aarch64/aarch64.md (*mov_aarch64): Call
> into function to generate MOVI instruction.
> * config/aarch64/aarch64.c (aarch64_simd_container_mode):
> New function.
> (aarc
On 3 June 2013 17:34, Ian Bolton wrote:
> 2013-06-03 Ian Bolton
>
> * config/aarch64/aarch64.c (simd_immediate_info): Remove
> element_char member.
> (sizetochar): Return signed char.
> (aarch64_simd_valid_immediate): Remove elchar and other
> unnecessar
On 3 June 2013 17:32, Ian Bolton wrote:
> 2013-06-03 Ian Bolton
>
> * config/aarch64/aarch64.c (simd_immediate_info): Struct to hold
> information completed by aarch64_simd_valid_immediate.
> (aarch64_legitimate_constant_p): Update arguments.
> (aarch64_simd_val
On 3 June 2013 17:31, Ian Bolton wrote:
> 13-06-03 Ian Bolton
>
> * config/aarch64/aarch64.c (aarch64_simd_valid_immediate): No
> longer static.
> (aarch64_simd_immediate_valid_for_move): Remove.
> (aarch64_simd_scalar_immediate_valid_for_move): Update call.
>
On 3 June 2013 17:31, Ian Bolton wrote:
> 13-06-03 Ian Bolton
>
> * config/aarch64/aarch64.c (aarch64_simd_valid_immediate): Change
> return type to bool for prototype.
> (aarch64_legitimate_constant_p): Check for true instead of not -1.
> (aarch64_simd_valid_im
[RFC] Allow functions calling mcount before prologue to be leaf functions
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00993.html
[PATCH] PR57377: Fix mnemonic attribute
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01364.html
[PATCH] Doc: Add documentation for the mnemonic attribute
http://gcc.gn
For the larger-than-a-word case, store_bit_field_1 factors out the processing
order into a 'backwards' local variable:
unsigned int backwards = WORDS_BIG_ENDIAN && fieldmode != BLKmode;
and uses it consistently afterward. There is the symmetrical processing in
extract_bit_field_1 and it
Manfred Schwarb wrote:
I did some tests for unbalanced curly braces in the gfortran testsuite
and got quite some output, see attached patch.
additionally,
- corrected "dg-do run" issues (double space)
I think some of the test cases might to it on purpose: "dg-do run"
causes the test case to
62 matches
Mail list logo
