My earlier N3276 work only affected the function call syntax, but it
needs to affect implicit function calls from overloaded operators as well.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit c3deee14326a96c9b058fb5433cf98fd64f8d618
Author: Jason Merrill
Date: Thu Apr 11 13:46:4
Ok.
As followup, the profile generation tool should be moved into compiler
space to avoid format mismatch.
David
On Wed, Apr 10, 2013 at 4:47 PM, Dehao Chen wrote:
> Hi,
>
> This patch
> 1. Uses relative line offset (lineno - start_lineno_of_function) to
> represent AutoFDO profile. This ensure
On Thu, Apr 11, 2013 at 12:43 PM, Xinliang David Li wrote:
> What is the compile time impact for turning it on? Code not including
> the intrinsic headers should not be affected too much. If the impact
> is small, why not turning on this option by default -- which seems to
> be the behavior of IC
On Thu, Apr 11, 2013 at 1:05 PM, Sriraman Tallam wrote:
> On Thu, Apr 11, 2013 at 12:43 PM, Xinliang David Li
> wrote:
>> What is the compile time impact for turning it on? Code not including
>> the intrinsic headers should not be affected too much. If the impact
>> is small, why not turning on
Hi,
I would like to backport the fix for PR51825 I posted here
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00316.html
to the 4.8 branch.
The fix was committed to trunk on Wed, 20 Mar 2013, so it is on trunk now
for three weeks.
It fixes a namelist issue where namelist lines like
arr(2)%a%b
Great that it is already covered.
David
On Thu, Apr 11, 2013 at 1:09 PM, Sriraman Tallam wrote:
> On Thu, Apr 11, 2013 at 1:05 PM, Sriraman Tallam wrote:
>> On Thu, Apr 11, 2013 at 12:43 PM, Xinliang David Li
>> wrote:
>>> What is the compile time impact for turning it on? Code not including
Hi,
This patch fix the bug of sum_all, which is used in loop unroll. The
fix will suppress unrolling loops when the program is hot instruction
footprint is large.
Bootstrapped and passed regression tests.
Is it okay for googe-4_7 branch?
Thanks,
Dehao
--- a/gcc/auto-profile.c
+++ b/gcc/auto-pr
On Thu, Apr 11, 2013 at 1:47 AM, Dehao Chen wrote:
> Hi,
>
> This patch
> 1. Uses relative line offset (lineno - start_lineno_of_function) to
> represent AutoFDO profile. This ensures profile still work for
> modified source code.
Is this something that is possible to do on trunk, too?
Sounds like
On 04/11/2013 02:32 PM, David Edelsohn wrote:
On Thu, Apr 11, 2013 at 1:30 PM, Vladimir Makarov wrote:
Here is a patch to enable LRA for rs6000. The patch includes code changes
in rs6000 machine-dependent parts and in LRA parts.
I've added a new switch -mlra for rs6000 to make debugging
yes -- Dehao first needs to rip out some internal dependencies for the
profile generation tool before it can be pushed upstream.
David
On Thu, Apr 11, 2013 at 2:04 PM, Steven Bosscher wrote:
> On Thu, Apr 11, 2013 at 1:47 AM, Dehao Chen wrote:
>> Hi,
>>
>> This patch
>> 1. Uses relative line off
ok.
David
On Thu, Apr 11, 2013 at 1:56 PM, Dehao Chen wrote:
> Hi,
>
> This patch fix the bug of sum_all, which is used in loop unroll. The
> fix will suppress unrolling loops when the program is hot instruction
> footprint is large.
>
> Bootstrapped and passed regression tests.
>
> Is it okay f
2013/4/11 Tobias Burnus :
> Am 11.04.2013 16:23, schrieb Janus Weil:
>
>>> [Btw, I also thought about doing a full "gfc_compare_interfaces" in
>>> "resolve_global_procedure", but that would probably be too strict.]
>>
>> Comment to self: It's certainly more strict, but I think this is a
>> good thi
Am 11.04.2013 23:38, schrieb Janus Weil:
2013/4/11 Tobias Burnus :
Comment to Janus: It should be possible to disable the error check,
e.g. by making it a warning.
That's actually what the current code does: By default,
it only warns and does not print an error.
No, at least the type mismatch
Hi Tobias,
> An unallocated polymorphic variable has the declared type; however, for
> static (SAVE) variables, the current code didn't set the value.
>
> (That the end of scope deallocation/_gfortran_caf_deregister is gone for
> coarrays (declared in the main program) was a side effect. The
> syn
>>> Thus, I think one should be strict about the requires-explicit-interface
>>> diagnostic (= new code, using F90+), but for interface mismatch (= could
>>> be
>>> old Fortran 66 code), it should be either disabled or - as currently -
>>> just
>>> be a warning.
>>
>> How about enabling it by defa
On Thu, Apr 11, 2013 at 12:47 PM, Richard Biener wrote:
> That said - I'm positively sure I will hit the IRA / reload
> issue again when adding mandatory IL verification (though
> for that they can simply drop the properties).
>
> So, if we ignore that "GC boundary" is global we can add
> PROP_gc_s
On Thu, Apr 11, 2013 at 10:26 AM, Jakub Jelinek wrote:
> On Thu, Apr 11, 2013 at 10:20:18AM -0500, Gabriel Dos Reis wrote:
>> On Thu, Apr 11, 2013 at 12:55 AM, Jakub Jelinek wrote:
>> > On Wed, Apr 10, 2013 at 09:04:06PM -0500, Gabriel Dos Reis wrote:
>> >> We might be saying the same thing using
Am 12.04.2013 00:05, schrieb Janus Weil:
Just one minor nit:
+ if (sym->ts.type == BT_CLASS && TREE_STATIC (sym->backend_decl)
+ && CLASS_DATA (sym)->attr.allocatable)
I'd find it somewhat clearer to check for "sym->attr.save" instead of
"TREE_STATIC (sym->backend_decl)", but that may
Am 12.04.2013 00:17, schrieb Janus Weil:
Hmm, I think I'd prefer to have for the arguments only a warning with
-std=gnu - except for the function result value, which should always be an
error. And also the "requires an explicit interface" checks should always
use an error.
Why the distinction (a
Gabriel Dos Reis wrote:
Patch OK.
I am not sure whether I have seen the latest patch, but in the one I saw
there is a typo in the .texi text:
+only when the stdandard error is a terminal. The forms
"standard"
Thanks for the patch, I think it can be quite useful.
Tobias
PS: Please also u
Bionic in Android 4.2 starts to support stack-protector canary at TLS for x86.
Android prior to 4.2 still looks at a global variable for stack
canary. To maintain backward compatibility, I propose to add a new
option -mstack-protector-guard={global,tls} for i386 back-end to use
canary at global o
2013/4/12 Tobias Burnus :
> Am 12.04.2013 00:05, schrieb Janus Weil:
>
>> Just one minor nit:
>>
>> + if (sym->ts.type == BT_CLASS && TREE_STATIC (sym->backend_decl)
>> + && CLASS_DATA (sym)->attr.allocatable)
>>
>> I'd find it somewhat clearer to check for "sym->attr.save" instead of
>>
Hello!
> Bionic in Android 4.2 starts to support stack-protector canary at TLS for x86.
>
> Android prior to 4.2 still looks at a global variable for stack
> canary. To maintain backward compatibility, I propose to add a new
> option -mstack-protector-guard={global,tls} for i386 back-end to use
>
101 - 123 of 123 matches
Mail list logo
