I'd like to backport the fox for PR48189 to 4.7 branch, so we can
close the PR. Ok?
2013-04-16 Marek Polacek
Backport from mainline
2013-01-08 Steven Bosscher
Jakub Jelinek
PR tree-optimization/48189
* predict.c (predict_loops): If max
On Tue, Apr 16, 2013 at 09:05:33AM +0200, Marek Polacek wrote:
> I'd like to backport the fox for PR48189 to 4.7 branch, so we can
> close the PR. Ok?
Ok, thanks.
Jakub
Linking with -findirect-dispatch fails with this error:
x86_64-linux-gcj -o ecjx -findirect-dispatch
--main=org.eclipse.jdt.internal.compiler.batch.GCCMain
../../../gcc/libjava/../ecj.jar ecjx.o
/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld:
/tmp/ccppO92n.o: undefi
On Tue, Apr 16, 2013 at 10:35:29AM +0200, Andreas Schwab wrote:
> Linking with -findirect-dispatch fails with this error:
>
> x86_64-linux-gcj -o ecjx -findirect-dispatch
> --main=org.eclipse.jdt.internal.compiler.batch.GCCMain
> ../../../gcc/libjava/../ecj.jar ecjx.o
> /usr/lib64/gcc/x86_64-s
On Tue, Apr 16, 2013 at 9:38 AM, Jakub Jelinek wrote:
> On Tue, Apr 16, 2013 at 10:35:29AM +0200, Andreas Schwab wrote:
>> Linking with -findirect-dispatch fails with this error:
>>
>> x86_64-linux-gcj -o ecjx -findirect-dispatch
>> --main=org.eclipse.jdt.internal.compiler.batch.GCCMain
>> ../..
Jakub Jelinek writes:
> That doesn't look right, if -findirect-dispatch now newly needs
> _Jv_MonitorExit (when has that been added?), then the symbol should
> be added to libgcj_bc.so.
libgcj_bc.so is just a dummy library. You need to look at the installed
file, not the one in the build direct
On Tue, Apr 16, 2013 at 11:13:35AM +0200, Andreas Schwab wrote:
> Jakub Jelinek writes:
>
> > That doesn't look right, if -findirect-dispatch now newly needs
> > _Jv_MonitorExit (when has that been added?), then the symbol should
> > be added to libgcj_bc.so.
>
> libgcj_bc.so is just a dummy lib
Hi,
Please consider this as a reminder to review the patch posted at
following link:-
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00045.html
Please review the patch and let me know if its okay?
Thanks & Regards,
Naveen.H.S
Jakub Jelinek writes:
> at dynamic link time it is a dummy library with no symbols that just
> adds DT_NEEDED of the latest and greatest libgcj.so.N, which provides
> all the symbols.
Which is exactly the problem. --no-copy-dt-needed-entries has been the
default for a long time now.
Andreas.
Hello!
2013-04-16 Uros Bizjak
* doc/invoke.texi (i386 Option): Reword mstack-protector-guard
description.
Tested on x86_64-pc-linux-gnu.
OK for mainline?
Uros.
Index: doc/invoke.texi
===
--- doc/invoke.texi (revisio
Hi,
This patch intends to improve cortex-m4 FPU pipeline description based on
below findings:
1) The integer instructions can be pipelined with fused/chained mac
instructions.
2) The two-cycle 32-bit floating point load instructions should be put
together to save one cycle. The three-cycle 64-bit
On Tue, Apr 16, 2013 at 11:37:07AM +0200, Andreas Schwab wrote:
> Jakub Jelinek writes:
>
> > at dynamic link time it is a dummy library with no symbols that just
> > adds DT_NEEDED of the latest and greatest libgcj.so.N, which provides
> > all the symbols.
>
> Which is exactly the problem. --n
On 15/04/13 18:19, Greta Yorsh wrote:
Generate prologue/epilogue using STRD/LDRD in ARM mode, when tuning
prefer_ldrd_strd flag is set, such as in Cortex-A15.
The previous version of this patch was posted for review here:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00995.html
The new version i
Am 16.04.2013 11:48, schrieb Jakub Jelinek:
> On Tue, Apr 16, 2013 at 11:37:07AM +0200, Andreas Schwab wrote:
>> Jakub Jelinek writes:
>>
>>> at dynamic link time it is a dummy library with no symbols that just
>>> adds DT_NEEDED of the latest and greatest libgcj.so.N, which provides
>>> all the s
On 16/04/13 10:47, Terry Guo wrote:
Hi,
This patch intends to improve cortex-m4 FPU pipeline description based on
below findings:
1) The integer instructions can be pipelined with fused/chained mac
instructions.
2) The two-cycle 32-bit floating point load instructions should be put
together to
On 29/03/13 09:59, Terry Guo wrote:
Hello,
The attached pipeline patch intends to turn following code generation
ldr r5, [r4, #12]
adds r2, r2, #16
str r5, [r3, #8]
to
ldr r5, [r4, #12]
str r5, [r3, #8]
adds r2, r2, #16
The reason is that the STR can be started from the second cycle of its
p
> Note that looking at the access path _is_ assuming TBAA constraints as
> soon as the base objects are not the same (in the above case '*p' and 'a'
> are not the same and p could alias a in a way that all f1 and f2 overlap).
Right, but here I'm assuming (and asserting) that the base objects are t
Jakub Jelinek writes:
> Why would that be a problem? libgcj.so the linker sees (i.e. the dummy
> library) doesn't intentionally have DT_NEEDED libgcj.so.N, programs and
> shared libraries linked with -findirect-dispatch should be adding
> libgcj_bc.so to DT_NEEDED, not libgcj.so.N.
But the dumm
On Tue, Apr 16, 2013 at 11:57:54AM +0200, Andreas Schwab wrote:
> Jakub Jelinek writes:
>
> > Why would that be a problem? libgcj.so the linker sees (i.e. the dummy
> > library) doesn't intentionally have DT_NEEDED libgcj.so.N, programs and
> > shared libraries linked with -findirect-dispatch sh
Jakub Jelinek writes:
> $ readelf -Wa libjava/.libs/libgcj_bc.so
That's not the installed library.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On Tue, Apr 16, 2013 at 12:11:06PM +0200, Andreas Schwab wrote:
> Jakub Jelinek writes:
>
> > $ readelf -Wa libjava/.libs/libgcj_bc.so
>
> That's not the installed library.
If that isn't the installed library, then the bug is that it isn't
installed. Our spec file reshuffles libraries around h
Jakub Jelinek writes:
> If that isn't the installed library, then the bug is that it isn't
> installed.
It's always been this way.
install-exec-hook: install-binPROGRAMS install-toolexeclibLTLIBRARIES \
install-libexecsubPROGRAMS
## Support for libgcj_bc: dummy shared library used only
Hi Mikael,
>> And then, the call to gfc_match_varspec shouldn't be there in the first
>> place. I'll test the following later.
>
> It seems like the parts you're removing have essentially been there
> since day zero. Would be interesting to know if (and where) your patch
> fails.
actually I just
>> For '}' case, can you simply just add
>>
>> /* Skip over any character after a percent sign. */
>> if (*p == '%' && *(p + 1))
>> {
>> p += 2;
>> continue;
>> }
>>
>> without changing the do-while loop to the while loop?
>
> Loop condition (*p++ != '}') must be moved to loop body for it to n
Janus Weil wrote:
As the comment says which the patch is removing, the gfc_match_varspec
should be relevant for cases like this:
print *,char_func()(1:3)
print *,array_func()(2)
print *,derived_type_func()%comp
Are we sure that all of these are actually invalid? (At least they are
rejected by g
On Tue, Apr 16, 2013 at 03:41:52PM +0400, Maksim Kuznetsov wrote:
> Richard, Jeff, could you please have a look?
I wonder if it %{ and %} shouldn't be better handled in final.c
for all #ifdef ASSEMBLER_DIALECT targets, rather than just for one specific.
Also:
*(p + 1)
should be better written as
On Thu, 28 Mar 2013, Richard Biener wrote:
>
> The domwalker fix to order dom children after inverted postorder
> exposed the latent issue that LIM relies on domwalk to walk
> all blocks defining SSA names before all blocks using them ...
> which is what the following patch tries to fix using the
On Tue, Apr 16, 2013 at 11:55 AM, Eric Botcazou wrote:
>> Note that looking at the access path _is_ assuming TBAA constraints as
>> soon as the base objects are not the same (in the above case '*p' and 'a'
>> are not the same and p could alias a in a way that all f1 and f2 overlap).
>
> Right, but
On 02/04/13 08:10, Hurugalawadi, Naveen wrote:
(compare:CC_NZ
--- gcc/testsuite/gcc.target/aarch64/adds1.c1970-01-01 05:30:00.0
+0530
+++ gcc/testsuite/gcc.target/aarch64/adds1.c2013-04-01 13:40:48.189390503
+0530
@@ -0,0 +1,149 @@
+/* { dg-do run } */
+/* { dg-options "
On 12/04/13 12:38, Hurugalawadi, Naveen wrote:
--- gcc/testsuite/gcc.target/aarch64/adds3.c1970-01-01 05:30:00.0
+0530
+++ gcc/testsuite/gcc.target/aarch64/adds3.c2013-04-12 16:18:29.472945730
+0530
@@ -0,0 +1,61 @@
+/* { dg-do run } */
+/* { dg-options "-O2 --save-temps" } */
+
On 04/15/2013 11:15 PM, Han Shen(沈涵) wrote:
Hi, I'm to bring up this patch about '-fstack-protector-strong' for trunk.
Background - some times stack-protector is too-simple while
stack-protector-all over-kills, for example, to build one of our core
systems, we forcibly add "-fstack-protector-all
On 15/04/13 05:37, Hurugalawadi, Naveen wrote:
Hi,
Same issue as my previous reply applies here.
Thanks for the suggestion.
Please find attached the modified patch as per your suggestions.
Please review the same and let me know if there should be any
further modifications in it.
Thanks,
Nav
The problem was that C_ASSOCIATED was made available multiple times. As
gfc_intrinsic_func_interface calls gfc_intrinsic_symbol, the sym->module
was set to "(intrinsic)" which didn't match the original
"__iso_c_binding". Hence, the symbols weren't recognized as the same and
an error is printed.
On Tue, 16 Apr 2013, Uros Bizjak wrote:
> 2013-04-16 Uros Bizjak
>
> * doc/invoke.texi (i386 Option): Reword mstack-protector-guard
> description.
Looks good to me.
Thanks,
Gerald
Jakub Jelinek writes:
> I'm pretty sure when the changes were added for gcc 4.2 it worked just fine,
I'm pretty sure it never worked as intented.
Andreas.
* Makefile.am (toolexeclib_LTLIBRARIES) [USE_LIBGCJ_BC]: Use
install/libgcj_bc.la instead of libgcj_bc.la.
(noinst_
On Tue, Apr 16, 2013 at 06:13:14PM +0200, Andreas Schwab wrote:
> Jakub Jelinek writes:
>
> > I'm pretty sure when the changes were added for gcc 4.2 it worked just fine,
>
> I'm pretty sure it never worked as intented.
Both libraries are actually intended to be installed, not just one.
Does yo
On Tue, Apr 16, 2013 at 5:13 PM, Andreas Schwab wrote:
> Jakub Jelinek writes:
>
>> I'm pretty sure when the changes were added for gcc 4.2 it worked just fine,
>
> I'm pretty sure it never worked as intented.
It certainly _did_ work as intended previously. Though I've not tested
it for a while.
On Sun, Apr 14, 2013 at 3:34 PM, Steven Bosscher wrote:
> Hello,
>
> My new delay branch scheduler uses TODO_verify_rtl_sharing but it
> turns out that verify_rtl_sharing doesn't handle SEQUENCEs correctly:
> Clearing the used-flags is done correctly, but verifying insns in the
> SEQUENCE fails. Th
Hi,
when function profiling is enabled also all the leaf functions are
forced to create a stack frame. This does not appear to be necessary
if the mcount call happens *before* the function prologue.
It also should not be necessary to do this when only -fprofile-arcs is
used since this option only
Jakub Jelinek writes:
> Both libraries are actually intended to be installed, not just one.
No, the other library is never installed, but generated on the fly. See
.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"An
Richard, this is the first of the tree level patches so that you can see
how the wide-int changes will effect the tree level. This patch
converts builtins.c so that it does not in any way assume that tree-cst
holds two HWIs. The patch divides all math into two categories:
Things that are
Here is a small patch which fixes a derp in the C++11 standard up for
repair in c+14 or so.
It allows you to have things like
template
constexpr int
operator"" _crypto()
{...}
...
int i = "hi there!"_crypto;
And many other things.
The string literal operator template can examine the s
Hi,
I have attached an updated patch that addresses all the comments raised.
On Fri, Apr 12, 2013 at 1:58 AM, Jakub Jelinek wrote:
> On Thu, Apr 11, 2013 at 12:05:41PM -0700, Sriraman Tallam wrote:
>> I have attached a patch that fixes this. I have added an option
>> "-mgenerate-builtins" that
Tobias Burnus wrote:
Can you put this behind an option so the user has to specify that
he really means it?
Regarding an option: Would be -f(no-)directives (with default = on) a
suitable option, which also affects the other !GCC$ attributes, such
as dllexport etc.?
Namely, the attached patch?
Thanks for the feedback, folks.
I've removed the builder type and added some overloads to simplify the
creation of gimple assignments. I have only added exactly the functions
I needed to simplify a bit of gcc/asan.c. I plan to continue adding and
tweaking as I change client code.
Some thin
OK.
Jason
Hello,
With the recent add_insn_* cleanups, we can now simplify
reorg.c:emit_delay_sequence.
Without this patch, emit_delay_sequence hacks the insns chain
"manually", setting PREV_INSN and NEXT_INSN to chain everything
together properly. But emit-rtl provides an abstraction of sorts for
that, and
I tracked down the bug with the spec 2006 benchmark WRF using the LRA register
allocator.
At one point LRA has decided to use the CTR to hold a CCmode value:
(insn 11019 11018 11020 16 (set (reg:CC 66 ctr [4411])
(reg:CC 66 ctr [4411])) module_diffusion_em.fppized.f90:4885 360
{*movcc_in
> For the C family I found exactly one - the layout_type case, and fixed
> it in the FEs by making empty arrays use [1, 0] domains or signed domains
> (I don't remember exactly). I believe the layout_type change was to make
> Ada happy.
I'm skeptical, I had to narrow down the initial kludge becau
Hi Florian, thanks for the review!
On Tue, Apr 16, 2013 at 6:32 AM, Florian Weimer wrote:
Please include the proposed changelog entries.
Done.
+ if (flag_stack_protect == 3)
+cpp_define (pfile, "__SSP_STRONG__=3");
if (flag_stack_protect == 2)
cpp_define (pfile, "__SSP_ALL__=2
This patch implements indirect call promotion for AutoFDO.
Bootstrapped and passed gcc regression tests.
Is it okay for gcc-4_7 branch?
Thanks,
Dehao
http://codereview.appspot.com/8814043
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index d17b250..c217846 100644
--- a/gcc/Makefile.in
+++ b/g
51 matches
Mail list logo
