Hi,
Here patch v2. Move the function as Andrew instructed.
* tree-inline.c (setup_one_parameter): Add strict aliasing check.
* c-family/c-common.c (strict_aliasing_warning): Move to alias.c.
* c-family/c-common.h (strict_aliasing_warning): Move to tree.h.
* alias.c (strict_alia
On Mon, Aug 18, 2014 at 10:57:58PM +0200, Manuel López-Ibáñez wrote:
> On 18 August 2014 22:04, Marek Polacek wrote:
> > +void
> > +maybe_warn_bool_compare (location_t loc, enum tree_code code, tree op0,
> > +tree op1)
> > +{
> > + if (TREE_CODE_CLASS (code) != tcc_compari
Hi Andrew,
I configure my gcc only to c language family. Sorry for my sloppy. I
have not run the test yet either. I only run my test manually.
That will be patch v2 soon.
--
Lin Zuojian
On Mon, Aug 18, 2014 at 9:35 PM, lin zuojian wrote:
> Hi,
> I want to add a warning to inlining function when violate strict
> aliasing.
> See bug:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546
> For details.
>
> * tree-inline.c (global): Add new include to c-family/c-co
Oops, I forgot to attach patch in the previous mail.
On Mon, Aug 18, 2014 at 10:51 PM, Kito Cheng wrote:
> Hi Vladimir:
>
> Here is a tiny typo in comment, allono -> allocno.
>
> ChangLog
> 2014-08-18 Kito Cheng
>
> * ira.c: Fix typo in comment.
From 6999747b19f53d140571f93991962292637
Hi,
I want to add a warning to inlining function when violate strict
aliasing.
See bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546
For details.
* tree-inline.c (global): Add new include to c-family/c-common.h. To
access strict aliasing check.
(setup_one_parameter): Add
OK.
Jason
Ping? Still on the trunk now.
> -Original Message-
> From: Tony Wang [mailto:tony.w...@arm.com]
> Sent: Tuesday, August 12, 2014 9:32 AM
> To: gcc-patches@gcc.gnu.org
> Subject: [PING v2][Patch]Fix ICE for gcc.dg/noncompile/920507-1.c
>
> Ping 2, and pasted my observation about this ICE,
On Tue, 2014-08-12 at 15:17 -0600, Jeff Law wrote:
> On 08/06/14 11:19, David Malcolm wrote:
> > gcc/
> > * rtl.h (PREV_INSN): Split macro in two: the existing one,
> > for rvalues, and...
> > (SET_PREV_INSN): New macro, for use as an lvalue.
> > (NEXT_INSN, SET_NEXT_INSN): Likewise
Committed as revision 214127.
2014-08-18 Patrick Palka
* MAINTAINERS (Write After Approval): Add myself.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 214126)
+++ MAINTAINERS (revision 214127)
@@ -494,6 +494,7 @@
Carlo
On Tue, 2014-08-12 at 15:16 -0600, Jeff Law wrote:
> On 08/06/14 11:19, David Malcolm wrote:
> > This is further scaffolding; convert the BB_* and SET_BB_* macros
> > into functions. Convert the BB_* rvalue-style functions into returning
> > rtx_insn * rather than plain rtx.
> >
> > For now, this
My recent patch to check_effective_target_arm_v8_neon_ok_nocache didn't
take into account that when compiling the test itself, the option
"-march=armv8-a" is added to the flags used for the effective-target
check, so it caused more multilibs to be skipped than needed to be.
This patch uses "march=
Hi
I think this is a minor documentation bug which is in the head but also
seems to be in the gcc 4.4.7 docs shipped with CentOS 6.x.
OK to commit?
2014-08-18 Joel Sherrill
* doc/invoke.texi: -fno-cxa-atexit should be -fno-use-cxa-atexit.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke
The following patch adds a new CPP() to *.opt files that tells the
options machinery to keep in sync libcpp options and GCC options.
This will allow us to fix a lot of latent bugs where CPP warnings do
not follow the rules of other warnings options. In this patch, I only
deal with Wvariadic-macros
On Fri, 15 Aug 2014, Manuel L?pez-Ib??ez wrote:
> Hi,
>
> This patch moves the location of various Wformat warnings from
> pointing to the first character of the function name (such as printf)
> to the actual format string. This is specially useful when you have
> something like
>
> printf (cond
On Tue, 12 Aug 2014, Marek Polacek wrote:
> And now the version with two bugs mention elsewhere fixed as well.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2014-08-12 Marek Polacek
>
> * doc/invoke.texi: Document -Wc99-c11-compat.
> c-family/
> * c.opt (Wc99-c11-
On Tue, 12 Aug 2014, Marek Polacek wrote:
> This then is the version with both issues fixed (and new test).
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2014-08-12 Marek Polacek
>
> gcc/c-family/
> * c-opts.c (sanitize_cpp_opts): Make warn_long_long be set according
>
Hello
The SD-6 [1] document keeps a list of built-in #defines that allow application
and library writers know when certain language and library features have been
implemented by the compiler. They are optional, since a compliant compiler
must implement them all.
But they're really useful.
Thi
On Mon, 2014-08-18 at 16:57 -0400, Hans-Peter Nilsson wrote:
> On Mon, 18 Aug 2014, Oleg Endo wrote:
> > On Sun, 2014-08-17 at 16:56 -0400, Hans-Peter Nilsson wrote:
> > > On Fri, 15 Aug 2014, Oleg Endo wrote:
> > > > > How about the attached .html as a replacement for the current one?
> > > > > I
On 18 August 2014 22:04, Marek Polacek wrote:
> +void
> +maybe_warn_bool_compare (location_t loc, enum tree_code code, tree op0,
> +tree op1)
> +{
> + if (TREE_CODE_CLASS (code) != tcc_comparison)
> +return;
> +
> + /* CMP */
> + if (TREE_CODE (op1) == INTEGER_CST
On Mon, 18 Aug 2014, Oleg Endo wrote:
> On Sun, 2014-08-17 at 16:56 -0400, Hans-Peter Nilsson wrote:
> > On Fri, 15 Aug 2014, Oleg Endo wrote:
> > > > How about the attached .html as a replacement for the current one?
> > > > I removed the requirement of setting up a combined tree, as I believe
> >
On Tue, 2014-08-12 at 15:15 -0600, Jeff Law wrote:
> On 08/06/14 11:19, David Malcolm wrote:
> > This is an enabling patch, splitting existing macros in two, covering
> > the rvalue and lvalue uses separately.
> >
> > Followup patches will replace these with functions, and gradually convert
> > the
On Sun, 2014-08-17 at 16:56 -0400, Hans-Peter Nilsson wrote:
> On Fri, 15 Aug 2014, Oleg Endo wrote:
> > > How about the attached .html as a replacement for the current one?
> > > I removed the requirement of setting up a combined tree, as I believe
> > > it makes things much more easy. At least i
On Tue, 2014-08-12 at 15:08 -0600, Jeff Law wrote:
> On 08/06/14 11:19, David Malcolm wrote:
> > gcc/
> > * rtl.h (for_each_rtx_in_insn): New function.
> > * rtlanal.c (for_each_rtx_in_insn): Likewise.
> OK. Note that we're moving away from for_each_rtx... I haven't
> looked, but there'
On Mon, 18 Aug 2014, Richard Earnshaw wrote:
> Hmm, I'm not sure about this. It might not be used at present, but on
> AArch64, with more call-clobbered registers than call-saved registers, I
> would expect this ought to be a win. The fact that it isn't on today
> may say more about the way it w
On Mon, Aug 18, 2014 at 04:10:49PM -0400, Jason Merrill wrote:
> On 08/18/2014 04:04 PM, Marek Polacek wrote:
> >Unfortunately, this warning cannot be enabled by -Wall yet, because
> >of a few blunders we have in the codebase. But we really should iron out
> >that soon.
>
> Can you take care of t
On 08/18/2014 04:04 PM, Marek Polacek wrote:
Unfortunately, this warning cannot be enabled by -Wall yet, because
of a few blunders we have in the codebase. But we really should iron out
that soon.
Can you take care of that as well?
The patch looks good to me, but if it should be part of -Wall
On Fri, Aug 15, 2014 at 10:34 PM, Konstantin Serebryany
wrote:
> If this is -O1 or higher, then most (but not all) of your cases
> *should* be optimized by the compiler before asan kicks in.
You mean hoisting memory accesses from branches?
Sure, the tests are simplified beyond all limits.
On the
On Tue, 2014-08-12 at 15:06 -0600, Jeff Law wrote:
> On 08/06/14 11:19, David Malcolm wrote:
> > gcc/
> > * coretypes.h (class rtx_insn): Add forward declaration.
> >
> > * rtl.h: Include is-a.h
> > (struct rtx_def): Add dummy "desc" and "tag" GTY options as a
> > workaround to ensu
The testcase here
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01557.html
prodded me into implementing the -Wbool-compare warning, which
should pipe down such a code. This warning detects dubious code
such as (i1 == i2) == 2 - which can never be true. The implementation
was quite straightforward
OK.
Jason
On Wed, 2014-08-13 at 07:48 -0600, Jeff Law wrote:
> On 08/13/14 04:07, Richard Biener wrote:
> > On Wed, Aug 13, 2014 at 12:01 PM, Martin Jambor wrote:
> >> Hi,
> >>
> >> On Wed, Aug 06, 2014 at 01:19:44PM -0400, David Malcolm wrote:
> >>> In many circumstances, is_a_helper ::test assumes that th
On 08/18/2014 03:05 PM, Paolo Carlini wrote:
I understand... It would be nice to also have a testcase for the class
template counterpart of the snippet in DR 1584, where it makes a real
difference. Then figuring out a complete patch not causing regressions
will be easier.
I think this is a prob
On Tue, 2014-08-12 at 14:55 -0600, Jeff Law wrote:
> On 08/06/14 11:19, David Malcolm wrote:
> > This commit is a placeholder for me when rebasing, to help organize the
> > patch kit.
> >
> > /
> > * rtx-classes-status.txt: New file
> OK. For those who may be watching, patch #236 removes this
Hi,
recently, while having a look to c++/58614, I noticed that if we are
going to use default arguments we can clean up quite a few functions and
function calls, for example cp_parser_expression, per the below, which
passes testing. Is this something we want to pursue?
Thanks,
Paolo.
//
On Mon, Aug 18, 2014 at 9:16 PM, H.J. Lu wrote:
>> Attached patch fixes the problem with false data dependency on output
>> register for popcnt, lzcnt and tzcnt insns on sandybridge and haswell
>> targets.
>>
>> The new insn pattern shadows existing one, and after reload, the
>> clearing isns is
On Tue, 2014-08-12 at 20:26 -0400, David Malcolm wrote:
> On Tue, 2014-08-12 at 14:39 -0600, Jeff Law wrote:
> > On 08/06/14 11:19, David Malcolm wrote:
> > >
> > > The aim of the patch series is to improve the type-safety and
> > > readability of the backend by introducing subclasses of rtx (actua
On Sat, Aug 16, 2014 at 6:01 AM, Uros Bizjak wrote:
> Hello!
>
> Attached patch fixes the problem with false data dependency on output
> register for popcnt, lzcnt and tzcnt insns on sandybridge and haswell
> targets.
>
> The new insn pattern shadows existing one, and after reload, the
> clearing
Hi,
On 08/18/2014 09:01 PM, Jason Merrill wrote:
On 08/15/2014 03:37 PM, Paolo Carlini wrote:
On 08/15/2014 09:22 PM, Jason Merrill wrote:
On 08/15/2014 03:16 PM, Paolo Carlini wrote:
+ bool in_function = (TREE_TYPE (tparms)
+ && DECL_FUNCTION_TEMPLATE_P (TREE_TYPE (tparms)));
On Mon, Aug 18, 2014 at 8:30 PM, Kirill Yukhin wrote:
>> > (define_insn "_ashrv"): New.
>>
>> It looks to me that the macroization is somehow wrong for ashrv. I'd
>> split the mode iterator to:
>>
>> > +(define_mode_iterator VI248_AVX512
>> > + [(V16SI "TARGET_AVX512F") (V8SI "TARGET_AVX
On 08/15/2014 03:37 PM, Paolo Carlini wrote:
On 08/15/2014 09:22 PM, Jason Merrill wrote:
On 08/15/2014 03:16 PM, Paolo Carlini wrote:
+ bool in_function = (TREE_TYPE (tparms)
+ && DECL_FUNCTION_TEMPLATE_P (TREE_TYPE (tparms)));
Huh? There's no such thing as a template paramete
On 08/18/2014 05:24 AM, Kyrill Tkachov wrote:
> -(define_insn "*csinc2_insn"
> +(define_insn "*csinc2__insn"
>[(set (match_operand:GPI 0 "register_operand" "=r")
> (plus:GPI (match_operator:GPI 2 "aarch64_comparison_operator"
> - [(match_operand:CC 3 "cc_register" "") (co
The first improves support for shorthand concepts, and includes the
ability to write default arguments. Also, no more ICE when omitting
identifiers for template parameters.
The second adds constraint checks when taking the address of an
overloaded function.
Corresponding change logs follow:
2014
Hello Uroš,
On 15 Aug 20:23, Uros Bizjak wrote:
> On Fri, Aug 15, 2014 at 1:42 PM, Kirill Yukhin
> wrote:
> > (define_insn "_ashrv"): New.
>
> It looks to me that the macroization is somehow wrong for ashrv. I'd
> split the mode iterator to:
>
> > +(define_mode_iterator VI248_AVX512
> >
On Sat, 16 Aug 2014, Patrick Palka wrote:
> 2014-08-17 Patrick Palka ppa...@gcc.gnu.org
>
> * c-typeck.c (build_c_cast): Do a conversion even when the
> TYPE_MAIN_VARIANTs are the same.
>
> 2014-08-17 Patrick Palka ppa...@gcc.gnu.org
>
> * gcc.dg/pr13519-1.c: Adjust.
OK,
On Mon, Aug 18, 2014 at 11:06 PM, David Malcolm wrote:
> On Mon, 2014-08-18 at 01:11 +0530, Prathamesh Kulkarni wrote:
>> We now have at-least one test-case for each of constant folding
>> patterns
>> in match-constant-folding.pd
>>
>> [gcc/testsuite/gcc.dg/tree-ssa]
>> * match-constant-folding.
On Mon, 2014-08-18 at 01:11 +0530, Prathamesh Kulkarni wrote:
> We now have at-least one test-case for each of constant folding
> patterns
> in match-constant-folding.pd
>
> [gcc/testsuite/gcc.dg/tree-ssa]
> * match-constant-folding.c: Add test-cases.
>
> [...snip...]
A minor nit for one of th
On 07/28/14 08:42, Ajit Kumar Agarwal wrote:
Please find the following patch for init_priority support for microblaze.
Testing Done : No regressions seen in gcc and g++ regressions testsuite.
[Patch, microblaze]: Add Init_priority support.
Added TARGET_ASM_CONSTRUCTOR and TARGET_ASM_D
Well, you're right that it could be. So I presented the wrong justification.
Clearly we would benefit from some better cost infrastructure here, ideally that
is expressive, taken into account at all appropriate stages of the compiler, and
tunable per core. I imagine that steps (patches) towards
On 08/18/2014 06:07 PM, Ilya Verbin wrote:
I discovered an issue in the LTO streaming out for target - currently any file
(even without any pragma) compiled with -fopenmp/-fopenacc contains
.gnu.target_lto_* sections. This increases the size of an object file and
makes lto-wrapper to run mkof
Hi Bernd,
I discovered an issue in the LTO streaming out for target - currently any file
(even without any pragma) compiled with -fopenmp/-fopenacc contains
.gnu.target_lto_* sections. This increases the size of an object file and
makes lto-wrapper to run mkoffload.
Therefore, I propose to re
> > When I compile for mipsel ABI o32 with -mhard-float and -msingle-fpu, It get
> > the warning:
> >
> > Warning: float register should be even, was 1.
> >
> > I would say the warning is wrong, because odd FPU registers are available.
>
> This is wrong but this is the area which is in flux at t
On 18 August 2014 17:51, VandeVondele Joost
wrote:
> ping ?
>
> https://gcc.gnu.org/ml/fortran/2014-06/msg00114.html
So the negative version is -Wno-use-no-only? That sounds weird.
Cheers,
Manuel.
On 04 Jun 01:15, Jeff Law wrote:
> On 06/03/14 01:10, Ilya Enkovich wrote:
> >Hi,
> >
> >This patch does not allow splitting in case bounds are returned until
> >retutrned bounds are supported. It also propagates instrumentation marks
> >for generated call and function.
> >
> >Bootstrapped and t
ping ?
https://gcc.gnu.org/ml/fortran/2014-06/msg00114.html
When --enable-gold=no is used to configure gcc, we will see
configure: line 21572: test: =: unary operator expected
I checked in this patch to set install_gold_as_default to no for
--enable-gold=no. Tested on Linux/x86-64.
H.J.
---
Index: ChangeLog
=
ping ?
https://gcc.gnu.org/ml/fortran/2014-05/msg00162.html
Hi there!
I have a fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61875.
This situation occurs when somebody decides to build GCC with these
flags which are forbidden for libsanitizer. They get strange error (see
bug above) which I know how to fix but think that I should not. Instead
of
On 06 Jun 11:59, Ilya Enkovich wrote:
> 2014-06-03 13:07 GMT+04:00 Richard Biener :
> > On Mon, Jun 2, 2014 at 5:56 PM, Ilya Enkovich
> > wrote:
> >> +
> >> + /* If indirect call has following BUILT_IN_CHKP_BNDRET
> >> +call then we need to make it's copy for the direct
> >> +
On 08/18/2014 07:36 AM, Christophe Lyon wrote:
> On 8 August 2014 02:30, Janis Johnson wrote:
>> Running an arm-none-eabi test that adds "-mthumb" for a multilib that
>> uses "-march=armv5te -mfloat-abi=hard" works fine if the test doesn't
>> have any calls, but if it does then the effective-targe
> This patch is ok. I assume you have tested compiling with/without cloog
> and isl.
Yes, I’ve tested compiling with/without cloog and isl. Thank you very
much for review!
--
Cheers, Roman Gareev.
Hi,
Firefox FDO build fails with undefined reference to __builtin_unreachable.
THis is caused by a bug
in gimple-fold that introduces the refernece in the cases it hits impossible
devirtualization.
We use __builtin_unreachable in the case we update call, but when updating
reference, we need
to
On Sun, Aug 17, 2014 at 8:39 PM, Bill Schmidt
wrote:
> On Sun, 2014-08-17 at 14:52 -0400, David Edelsohn wrote:
>> On Wed, Aug 13, 2014 at 7:14 PM, Bill Schmidt
>> wrote:
>> > Hi,
>> >
>> > This patch adds a PowerPC-specific pass just prior to the first cse RTL
>> > pass. The pass runs only when
Hi,
This patch adds support for va_arg_pack and va_arg_pack_len for instrumented
functions into inliner. There are two things to do: 1) ignore bounds args when
computing va_arg_pack_len 2) remove bounds args when expanding va_arg_pack in
not instrumented call.
Thanks,
Ilya
--
2014-08-15 Ilya
Ping.
--
Evandro Menezes Austin, USA
e.mene...@samsung.com +1-512-425-3365
-Original Message-
From: Evandro Menezes [mailto:e.mene...@samsung.com]
Sent: Friday, August 15, 2014 14:55
To: 'James Greenhalgh'
Cc: 'gcc-patches@gcc.gnu.org'; 'Jame
On 18/08/14 15:48, Kito Cheng wrote:
> Hi all:
>
> This patch clean up CALLER_SAVE_PROFITABLE marco include doc since
> seem nobody use it.
>
> Bootstrap and regression testing running on x86_64-unknown-linux-gnu :)
>
> ChangLog
> 2014-08-18 Kito Cheng
>
> * doc/tm.texi.in (CALLER_SA
Hi Vladimir:
Here is a tiny typo in comment, allono -> allocno.
ChangLog
2014-08-18 Kito Cheng
* ira.c: Fix typo in comment.
Hi all:
This patch clean up CALLER_SAVE_PROFITABLE marco include doc since
seem nobody use it.
Bootstrap and regression testing running on x86_64-unknown-linux-gnu :)
ChangLog
2014-08-18 Kito Cheng
* doc/tm.texi.in (CALLER_SAVE_PROFITABLE): Remove.
* gcc/doc/tm.texi: Regenera
Hi,
This small patch adds support for new reference type for IPA pure const
analysis.
Thanks,
Ilya
--
2014-08-15 Ilya Enkovich
* ipa-pure-const.c (propagate_pure_const): Support
IPA_REF_CHKP.
diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
index b964502..d7688d5 10
The following moves snprintf folding from builtins.c to gimple-fold.c.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2014-08-18 Richard Biener
PR tree-optimization/62090
* builtins.c (fold_builtin_snprintf): Move to gimple-fold.c.
(fold_built
On 8 August 2014 02:30, Janis Johnson wrote:
> Running an arm-none-eabi test that adds "-mthumb" for a multilib that
> uses "-march=armv5te -mfloat-abi=hard" works fine if the test doesn't
> have any calls, but if it does then the effective-target checks for
> arm_thumb1_ok and arm_thumb2_ok pass
On Mon, Aug 18, 2014 at 8:59 AM, Patrick Palka wrote:
> On Mon, Aug 18, 2014 at 8:50 AM, Richard Biener
> wrote:
>> On Mon, Aug 18, 2014 at 2:31 PM, Patrick Palka wrote:
>>> On Mon, Aug 18, 2014 at 6:48 AM, Richard Biener
>>> wrote:
On Mon, Aug 18, 2014 at 4:00 AM, Patrick Palka
wro
This is a first step towards re-gimplifying statements with
propagated addresses in the core propagation routines that
already deal (well, some of them...) with computing invariantness.
The patch moves all such re-gimplification before any simplifications
are performed (which means once "fixed" t
Ping.
Thanks,
Matthew
> Sent: 07 August 2014 07:21
> > Please don't add target macros. Add a hook if you must, but we're
> > supposed to remove target macros, not add new ones :-)
>
> Thanks Steven, I wasn't sure if there were still things that were
> acceptable as macros. There's a lot to get
for 2 and 3 argument calls.
Committed.
Richard.
2014-08-18 Richard Biener
* gimple-fold.c (gimple_build): Add function call overloads
with two and three arguments.
* gimple-fold.h (gimple_build): Likewise.
Index: gcc/gimple-fold.c
===
On Mon, 18 Aug 2014, Prathamesh Kulkarni wrote:
> On Fri, Aug 15, 2014 at 6:18 PM, Richard Biener wrote:
> >
> > The following introduces "manually" written patterns. That is,
> > part of the matching and the transform are fully manual. An
> > example where this is necessary is when the result
The secondary_reload_class hook gets called for pseudos which have
not been allocated a hard register. For pseudos with the FP_REGS
class this results in the hook stating that the pseudo must be
reloaded via GR_REGS as it is neither in an FP_REG nor in memory.
This is obviously wasteful as LRA will
Committed.
Richard.
2014-08-18 Richard Biener
* gimple-match-head.c (gimple_simplify): Handle calls with
three arguments.
Index: gcc/gimple-match-head.c
===
--- gcc/gimple-match-head.c (revision 214018)
+++
On 03 Jun 11:33, Richard Biener wrote:
> On Tue, Jun 3, 2014 at 9:13 AM, Ilya Enkovich wrote:
> > Hi,
> >
> > This patch preserves CALL_WITH_BOUNDS flag for calls during PRE.
>
> Ok.
>
> Richard.
>
Merging with the trunk I found that op2 field of vn_reference_op_struct is now
used to pass EH
On Fri, Aug 15, 2014 at 1:13 PM, Roman Gareev wrote:
>> I've attached the patch, which should eliminate CLooG library
>> installation dependency from GCC. The CLooG AST generator is still the
>> main code generator, but the isl ast generator will be chosen in case
>> of nonavailability of CLooG li
On Mon, Aug 18, 2014 at 8:50 AM, Richard Biener
wrote:
> On Mon, Aug 18, 2014 at 2:31 PM, Patrick Palka wrote:
>> On Mon, Aug 18, 2014 at 6:48 AM, Richard Biener
>> wrote:
>>> On Mon, Aug 18, 2014 at 4:00 AM, Patrick Palka wrote:
Hi,
The fix for PR38615 indirectly broke the promo
On Mon, Aug 18, 2014 at 2:31 PM, Patrick Palka wrote:
> On Mon, Aug 18, 2014 at 6:48 AM, Richard Biener
> wrote:
>> On Mon, Aug 18, 2014 at 4:00 AM, Patrick Palka wrote:
>>> Hi,
>>>
>>> The fix for PR38615 indirectly broke the promotion of const local arrays
>>> to static storage in many cases.
On Mon, Aug 18, 2014 at 6:48 AM, Richard Biener
wrote:
> On Mon, Aug 18, 2014 at 4:00 AM, Patrick Palka wrote:
>> Hi,
>>
>> The fix for PR38615 indirectly broke the promotion of const local arrays
>> to static storage in many cases. The commit in question, r143570, made
>> it so that only arrays
Hi all,
Currently for code:
int
foo (unsigned a, unsigned b)
{
int r = 0;
r = a & b;
if (a & b)
return ++ r;
return r;
}
we generate:
foo:
andw0, w0, w1
cmpw0, wzr
csincw0, wzr, w0, eq
ret
If we relax the csinc and similar patterns to accept the CC_Z and
On 15 Aug 23:08, Jan Hubicka wrote:
> > Hi,
> >
> > I get a segafult in decl_maybe_in_construction_p during function
> > versioning. We have following steps in clone creation (e.g. as in
> > create_version_clone_with_body):
> > 1. Create function decl
> > 2. Create clone of cgraph node
> > 3
On Sun, Aug 17, 2014 at 11:01 PM, Prathamesh Kulkarni
wrote:
> On Mon, Aug 18, 2014 at 2:11 AM, Prathamesh Kulkarni
> wrote:
>> [gcc/doc]
>> * match-and-simplify.texi: Replace addres by address.
>>
> This version adds a small note for capturing expressions.
>
> [gcc/doc]
> * match-and-simplif
On Sun, Aug 17, 2014 at 9:41 PM, Prathamesh Kulkarni
wrote:
> We now have at-least one test-case for each of constant folding patterns
> in match-constant-folding.pd
>
> [gcc/testsuite/gcc.dg/tree-ssa]
> * match-constant-folding.c: Add test-cases.
Thanks - committed.
Richard.
> Thanks,
> Prat
On Mon, Aug 18, 2014 at 4:00 AM, Patrick Palka wrote:
> Hi,
>
> The fix for PR38615 indirectly broke the promotion of const local arrays
> to static storage in many cases. The commit in question, r143570, made
> it so that only arrays that don't potentially escape from the scope in
> which they'r
Ping?
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent: Thursday, August 07, 2014 6:56 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] Cancel bswap opt when intermediate stmts are reused
>
> Hi
On 13/08/14 08:49, Thomas Preud'homme wrote:
>> From: Richard Earnshaw
>> Sent: Monday, August 11, 2014 4:54 PM
>>
>> I think this is the wrong place for this sort of fix up. HFmode values
>> are fixed up in the consttable_4 pattern and it looks wrong to be that
>> HImode values are then fixed up
On Fri, Aug 15, 2014 at 10:29 PM, Aldy Hernandez wrote:
> This test is failing with LTO because in the LTRANS phase (DCE) we realize
> that the call to f() is useless, so we don't generate it. This leads to an
> uncalled f() which also gets deleted. We end up with an empty main(), and
> rightly
this patch enable auto-vectorization for copysignf by using vector
bit selection instruction on arm32 when neon available.
for a simple testcase:
for (i = 0; i < N; i++)
r[i] = __builtin_copysignf (a[i], b[i]);
assuming vector factor be 4, the generated instruction sequences is:
OK to 4.8 then?
On Thu, Aug 14, 2014 at 6:36 PM, Richard Biener
wrote:
> On Thu, Aug 14, 2014 at 7:34 AM, Joey Ye wrote:
>> PR60484 is marked as 4.7/4.8 regression and it is reported against 4.8
>> recently by an user.
>>
>> OK backporting to 4.7/4.8?
>
> The 4.7 branch is closed.
>
> Richard.
>
On 8/18/14 18:07, Bin.Cheng wrote:
> On Mon, Aug 18, 2014 at 6:06 PM, Chen Gang wrote:
>> On 08/18/2014 03:05 PM, Bin.Cheng wrote:
>>> On Sun, Aug 17, 2014 at 6:48 PM, Chen Gang wrote:
On 08/10/2014 04:15 PM, Chen Gang wrote:
> On 08/10/2014 04:03 PM, Mike Stump wrote:
>> On Aug 9,
On Mon, Aug 18, 2014 at 6:06 PM, Chen Gang wrote:
> On 08/18/2014 03:05 PM, Bin.Cheng wrote:
>> On Sun, Aug 17, 2014 at 6:48 PM, Chen Gang wrote:
>>> On 08/10/2014 04:15 PM, Chen Gang wrote:
On 08/10/2014 04:03 PM, Mike Stump wrote:
> On Aug 9, 2014, at 9:55 AM, Chen Gang wrote:
>>>
On 08/18/2014 03:05 PM, Bin.Cheng wrote:
> On Sun, Aug 17, 2014 at 6:48 PM, Chen Gang wrote:
>> On 08/10/2014 04:15 PM, Chen Gang wrote:
>>> On 08/10/2014 04:03 PM, Mike Stump wrote:
On Aug 9, 2014, at 9:55 AM, Chen Gang wrote:
>>
>
> Excuse me, I can not find it with `find ./ |
> > > > What is harder to fix about n32 than o32?
> > >
> > > "-msingle-float" with n32 creates 64 bit FPU instructions like dmtc1 and
> > > dmfc1. So I can't compile it for r5900. When I disable it, I get
> internal
> > > compiler errors.
> >
> > That certainly seems like a bug. Can you file a bug
> On Aug 18, 2014, at 1:33 AM, Tom de Vries wrote:
>
>> On 14-08-14 16:34, Richard Biener wrote:
>>> On Sat, Aug 9, 2014 at 7:14 AM, Tom de Vries wrote:
>>> On 08-08-14 17:17, Tom de Vries wrote:
>
> Maybe instead of a new mem_alias_equal_p simply compare MEM_ATTRs
> with mem_attr
Dear All,
There are known issues with unlimited polymorphic variables
representing characters : see
https://groups.google.com/forum/#!topic/comp.lang.fortran/aRz3HMpblTs
and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901
One way or another, the variable itself needs to carry the string
length
On 14-08-14 16:34, Richard Biener wrote:
On Sat, Aug 9, 2014 at 7:14 AM, Tom de Vries wrote:
On 08-08-14 17:17, Tom de Vries wrote:
Maybe instead of a new mem_alias_equal_p simply compare MEM_ATTRs
with mem_attrs_eq_p?
I propose to fix it this way (as attached) on 4.8/4.9/trunk, and maybe
1 - 100 of 106 matches
Mail list logo
