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 pola...@redhat.com
Backport from mainline
2013-01-08 Steven Bosscher ste...@gcc.gnu.org
Jakub Jelinek ja...@redhat.com
PR
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:
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
On Tue, Apr 16, 2013 at 9:38 AM, Jakub Jelinek ja...@redhat.com 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 ja...@redhat.com 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
On Tue, Apr 16, 2013 at 11:13:35AM +0200, Andreas Schwab wrote:
Jakub Jelinek ja...@redhat.com 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
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 ja...@redhat.com 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
Hello!
2013-04-16 Uros Bizjak ubiz...@gmail.com
* 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
===
---
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
On Tue, Apr 16, 2013 at 11:37:07AM +0200, Andreas Schwab wrote:
Jakub Jelinek ja...@redhat.com 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
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
Am 16.04.2013 11:48, schrieb Jakub Jelinek:
On Tue, Apr 16, 2013 at 11:37:07AM +0200, Andreas Schwab wrote:
Jakub Jelinek ja...@redhat.com 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
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
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 the
Jakub Jelinek ja...@redhat.com 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.
On Tue, Apr 16, 2013 at 11:57:54AM +0200, Andreas Schwab wrote:
Jakub Jelinek ja...@redhat.com 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
Jakub Jelinek ja...@redhat.com 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 ja...@redhat.com 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
Jakub Jelinek ja...@redhat.com 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
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 tried
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 not
execute after
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
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 ebotca...@adacore.com 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
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,
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.
I
On Tue, 16 Apr 2013, Uros Bizjak wrote:
2013-04-16 Uros Bizjak ubiz...@gmail.com
* doc/invoke.texi (i386 Option): Reword mstack-protector-guard
description.
Looks good to me.
Thanks,
Gerald
Jakub Jelinek ja...@redhat.com 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.
On Tue, Apr 16, 2013 at 06:13:14PM +0200, Andreas Schwab wrote:
Jakub Jelinek ja...@redhat.com 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
On Tue, Apr 16, 2013 at 5:13 PM, Andreas Schwab sch...@suse.de wrote:
Jakub Jelinek ja...@redhat.com 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
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. The
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
Jakub Jelinek ja...@redhat.com 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
mvm8v4iu5q2@hawking.suse.de.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA
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
templatetypename CharT, CharT... String
constexpr int
operator _crypto()
{...}
...
int i = hi there!_crypto;
And many other things.
The string literal
Hi,
I have attached an updated patch that addresses all the comments raised.
On Fri, Apr 12, 2013 at 1:58 AM, Jakub Jelinek ja...@redhat.com 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
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
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
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
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 because
Hi Florian, thanks for the review!
On Tue, Apr 16, 2013 at 6:32 AM, Florian Weimer fwei...@redhat.com 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
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
+++
51 matches
Mail list logo
