On 13-04-15 1:20 AM, shiva Chen wrote:
HI,
I'm trying to port a new 32bit target to GCC 4.8.0 with LRA enabled
There is an error case which generates following RTL
(insn 536 267 643 3 (set (reg/f:SI 0 $r0 [477]) == r477 assign to r0
(plus:SI (reg/f:SI 31 $sp)
Hi there,
A quick note to say, first, thank you for providing such a great site! I am in
the middle of a writing project (topic: finding - and keeping - a job in the
modern world) and discovered your site while researching. And, second, I wanted
to let you know that I did find a link that’s no
Hi,
looks like XOP/FAM4/FAM is responsible for the additional errors I
see when running gcc-testsuite or glibc-testsuite. I've opened Bug
56866 as a starting point, so the subject is a little bit misleading:
Bug 56866 - gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles
Hello delay-slot target maintainers :-)
As you know, I'm playing with a new for-now-toy delay slot filling
pass that preserves the CFG, and uses DF and sched-deps instead of
resource.c. It's now beginning to take form enough that I run into the
to-be-expected unexpected problems and questions.
Full test2.c.209r.reload is about 296kb and i can't send successfully.
Is there another way to send the dump file?
Shiva
2013/4/18 Shiva Chen shiva0...@gmail.com:
Hi, Vladimir
attachment is the ira dump of the case
Shiva
2013/4/17 Vladimir Makarov vmaka...@redhat.com:
On 13-04-15 1:20
Hi, Vladimir
Previous patch probably not completed.
The new patch will record lra_reg_info[i].offset as the offset from
eliminate register to the pseudo i
and keep updating when the stack has been changed.
Therefore, lra-assign could get the latest offset to identify the
pseudo content is equal
On 04/17/2013 03:52 PM, Steven Bosscher wrote:
First of all: What is still important to handle?
It's clear that the expectations in reorg.c are anything goes but
modern RISCs (everything since the PA-8000, say) probably have some
limitations on what is helpful to have, or not have, in a delay
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56984
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56957
Andrey Belevantsev abel at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53453
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56984
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50789
Andrey Turetskiy andrey.turetskiy at gmail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #16 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2013-04-17
08:40:09 UTC ---
(In reply to comment #3)
A way to tell gcc a variable is not uninitialized is to perform
self-initialization like
int i = i;
this will cause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2013-04-17
08:48:33 UTC ---
So the questions are:
- is it desirable that uncprop does anything to SSA_NAME_VAR == NULL phis?
sure - it is all about improving out-of-SSA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50789
--- Comment #12 from rguenther at suse dot de rguenther at suse dot de
2013-04-17 08:53:21 UTC ---
On Wed, 17 Apr 2013, andrey.turetskiy at gmail dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50789
Andrey Turetskiy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-17
08:56:00 UTC ---
I don't see how we could declare the testcase invalid, why would n need to be
volatile? It isn't live across the setjmp call, it is even declared after
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56814
--- Comment #5 from janus at gcc dot gnu.org 2013-04-17 08:58:25 UTC ---
Alternative patch:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c(revision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56644
--- Comment #6 from Markus Eisenmann meisenmann@fh-salzburg.ac.at
2013-04-17 09:01:04 UTC ---
Created attachment 29888
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29888
Prevent redirect to some libintl-functions if NLS isn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #7 from rguenther at suse dot de rguenther at suse dot de
2013-04-17 09:07:10 UTC ---
On Wed, 17 Apr 2013, jakub at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #6 from Jakub
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40986
--- Comment #15 from Markus Schöpflin markus.schoepflin at comsoft dot de
2013-04-17 09:15:22 UTC ---
I have bisected the problem using the git gcc repository, unfortunately 121
commits are left after bisecting, as in between the last known good
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56644
--- Comment #7 from Markus Eisenmann meisenmann@fh-salzburg.ac.at
2013-04-17 09:17:36 UTC ---
At least this error is based on some libintl-macros, which will redirect some
stdio-functions (like vsnprintf ...) to their
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-17
09:28:55 UTC ---
#include stdio.h
#include setjmp.h
static sigjmp_buf env;
static inline int g (int x)
{
if (x)
{
fprintf (stderr, Returning 0\n);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44269
Shakthi Kannan skannan at redhat dot com changed:
What|Removed |Added
CC||skannan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #18 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-17
09:31:59 UTC ---
In fact, we should have removed the i=i idiom a long time ago. The correct
thing to do (as Linus says) is to initialize the variable to a sensible value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #19 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-17
09:37:24 UTC ---
(In reply to comment #2)
1. Split the -Wuninitialized into two different warnings: one for which gcc
knows that the variable is uninitialized and one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-17
09:39:58 UTC ---
(In reply to comment #2)
There is a seek inside next_record_w_unf. That function is used for DIRECT
I/O.
Looks conceptually wrong to me for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #9 from Richard Biener rguenth at gcc dot gnu.org 2013-04-17
09:57:52 UTC ---
Created attachment 29889
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29889
patch
Untested patch. The patch handles setjmp similar to a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56985
Bug #: 56985
Summary: gcc/fortran/resolve.c:920: '%s' in cannot appear in
COMMON ...
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45655
Shakthi Kannan skannan at redhat dot com changed:
What|Removed |Added
CC||skannan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45688
Shakthi Kannan skannan at redhat dot com changed:
What|Removed |Added
CC||skannan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981
--- Comment #4 from Janne Blomqvist jb at gcc dot gnu.org 2013-04-17 10:50:07
UTC ---
The reason why gfortran is slow here is that for non-regular files we use
unbuffered I/O. If you write to a regular file instead of /dev/null, you'll see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #20 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2013-04-17
11:17:14 UTC ---
(In reply to comment #18)
In fact, we should have removed the i=i idiom a long time ago. The correct
thing to do (as Linus says) is to initialize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #21 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-17
11:26:01 UTC ---
(In reply to comment #20)
OK, so a solution would be to add a configure test for projects that don't
want
such warnings (while still using -Wall) to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #22 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-17
11:31:29 UTC ---
(In reply to comment #20)
(In reply to comment #18)
In fact, we should have removed the i=i idiom a long time ago. The correct
thing to do (as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56814
--- Comment #6 from janus at gcc dot gnu.org 2013-04-17 11:41:21 UTC ---
(In reply to comment #5)
Alternative patch:
In contrast to the patch in comment #3, this one regtests cleanly ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56921
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #23 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2013-04-17
12:24:56 UTC ---
(In reply to comment #21)
When an unrecognized warning option is requested (e.g., -Wunknown-warning),
GCC
will emit a diagnostic stating that the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
--- Comment #24 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2013-04-17
12:34:40 UTC ---
BTW, since with the latest GCC versions (such as Debian's GCC 4.7.2), the
warning is no longer issued with -Wno-maybe-uninitialized, perhaps the bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45688
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56948
David Edelsohn dje at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45688
--- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-17
13:30:35 UTC ---
Actually, the bug was version level functioning. Since it is obvious, I fixed
it.
http://gcc.gnu.org/r198028
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958
--- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-17
13:50:58 UTC ---
Author: jb
Date: Wed Apr 17 10:19:40 2013
New Revision: 198023
URL: http://gcc.gnu.org/viewcvs?rev=198023root=gccview=rev
Log:
PR 40958 Compress
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320
--- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2013-04-17
14:16:40 UTC ---
Sorry, the most recent paper in the series is actually N3639.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55149
--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2013-04-17
14:19:07 UTC ---
Likewise capturing VLAs is covered in N3639 (only capture by reference allowed)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981
--- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-17
14:50:16 UTC ---
(In reply to comment #4)
The reason why gfortran is slow here is that for non-regular files we use
unbuffered I/O. If you write to a regular file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35649
Trevor Morgan trevmrgn+bug at gmail dot com changed:
What|Removed |Added
Target|h8300-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56986
Bug #: 56986
Summary: config/epiphany/epiphany.opt:108: floatig
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56987
Bug #: 56987
Summary: gcc/config/avr/avr.opt:80: change - changed?
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10474
Martin Jambor jamborm at gcc dot gnu.org changed:
What|Removed |Added
CC||jamborm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53453
m...@gcc.gnu.org mrs at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.7.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371
Martin Jambor jamborm at gcc dot gnu.org changed:
What|Removed |Added
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56718
Martin Jambor jamborm at gcc dot gnu.org changed:
What|Removed |Added
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56814
--- Comment #7 from janus at gcc dot gnu.org 2013-04-17 16:15:06 UTC ---
Fixed on trunk with:
Author: janus
Date: Wed Apr 17 16:13:07 2013
New Revision: 198032
URL: http://gcc.gnu.org/viewcvs?rev=198032root=gccview=rev
Log:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53453
--- Comment #19 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2013-04-17
16:21:39 UTC ---
I've sent a message to the gcc-patches list with a pointer to the gcc-patches
list for the work.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56988
Bug #: 56988
Summary: ipa-cp incorrectly propagates a field of an aggregate
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40986
Ludovic Brenta ludo...@ludovic-brenta.org changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866
--- Comment #9 from Winfried Magerl winfried.mag...@t-online.de 2013-04-17
18:41:06 UTC ---
Hi,
at least one confirmation. I've done some further checks about
float-errors in glibc and that FAM/FAM4 are the extension responsible
for the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56989
Bug #: 56989
Summary: wrong location in error message
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56990
Bug #: 56990
Summary: ICE: SIGFPE with -fsanitize=thread and empty struct
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958
--- Comment #11 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2013-04-17 19:36:45 UTC ---
With these patches in, parallel compilation of multi-file cp2k becomes
significantly faster. Time for a full build goes from 70s to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56909
Arthur Zhang mail2arthur at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56991
Bug #: 56991
Summary: constexpr std::initializer_list crashes on too complex
initialization
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866
--- Comment #10 from Mikael Pettersson mikpe at it dot uu.se 2013-04-17
20:15:47 UTC ---
(In reply to comment #9)
How to proceed?
Derive a stand-alone test case from the failing glibc module and whatever glibc
code it requires, then
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56909
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56909
--- Comment #14 from Arthur Zhang mail2arthur at gmail dot com 2013-04-17
21:02:14 UTC ---
(In reply to comment #13)
What is the benefit to use '--build=i686-pc-mingw32' than
'--with-arch=i686'?
It doesn't force -march=i686 by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866
--- Comment #11 from Winfried Magerl winfried.mag...@t-online.de 2013-04-17
21:02:38 UTC ---
Hi Mike,
On Wed, Apr 17, 2013 at 08:15:47PM +, mikpe at it dot uu.se wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56989
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56909
--- Comment #15 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-04-17
21:35:54 UTC ---
Why below output has '-march=pentiumpro'?
I think it's the autodetected arch, but maybe I'm confused. Never mind.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866
--- Comment #12 from Marc Glisse glisse at gcc dot gnu.org 2013-04-17
21:49:15 UTC ---
(In reply to comment #11)
If fixing broken gcc's XOP/FMA/FMA4-extensions on AMD-CPUs depends on my
ability to extract a stand-alone-test from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56847
--- Comment #8 from Han Shen shenhan at google dot com 2013-04-17 23:42:22
UTC ---
Hi, any progress on this?
Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56992
Bug #: 56992
Summary: building Wine with -Og causes GCC to seg fault
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56992
--- Comment #1 from James Eder jimportal at gmail dot com 2013-04-17 23:47:39
UTC ---
Created attachment 29892
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29892
testcase-min.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993
Bug #: 56993
Summary: power gcc built 416.gamess generates wrong result
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #10 from Leif Leonhardy bugfeed at online dot de 2013-04-18
01:17:31 UTC ---
One proposed requirement on setjmp is that it be usable like any other
function, that is, that it be callable in *any* expression context, and that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981
--- Comment #6 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2013-04-18
01:21:42 UTC ---
I like Jannes idea with the flags. Also, it seems that at the time we open a
file we know it is /dev/null or /dev/nul in some cases by the file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56682
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-04-18
01:58:03 UTC ---
-fsanitize=thread
I think it requires -fPIE but really it should not.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56994
Bug #: 56994
Summary: Incorrect documentation for Fortran NEAREST intrinsic
function
Classification: Unclassified
Product: gcc
Version: unknown
Status:
On 2013-04-16 13:55, Jakub Jelinek wrote:
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.
On Wed, Apr 17, 2013 at 1:12 AM, Eric Botcazou ebotca...@adacore.com wrote:
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
This patch is also necessary for my new delay-slot scheduler to keep
basic block boundaries correctly up-to-date. The emit-rtl API does
that already.
Cross-tested powerpc64 x mips. Currently running bootstraptest on
sparc64-unknown-linux-gnu. OK if it passes?
Yes, modulo
@@ -538,6 +502,8
+ if (type1 != type2 || TREE_CODE (type1) != RECORD_TYPE)
+goto may_overlap;
ick, can TREE_CODE (type1) != RECORD_TYPE happen as well here?
Please add a comment similar to the Fortran ??? above.
It can happen because we stop at unions (and qualified unions) and for them we
On 04/17/2013 02:49 AM, Han Shen wrote:
+ if (flag_stack_protect == 3)
+cpp_define (pfile, __SSP_STRONG__=3);
if (flag_stack_protect == 2)
cpp_define (pfile, __SSP_ALL__=2);
3 and 2 should be replaced by SPCT_FLAG_STRONG and SPCT_FLAG_ALL.
I define these SPCT_FLAG_XXX in
Hi,
I suggest for this one test case either making it compile only and
dropping main() such that the pattern match only looks in the
assembled output of the cmp_* functions
The testcase will check only for assembly pattern of the instruction
as per your suggestion.
Please find attached the
Hi Julian,
From: Julian Brown [mailto:jul...@codesourcery.com]
Sent: 13 April 2013 15:04
To: Julian Brown
Cc: Kyrylo Tkachov; gcc-patches@gcc.gnu.org; Richard Earnshaw; Ramana
Radhakrishnan
Subject: Re: [PATCH][ARM][1/2] Add support for vcvt_f16_f32 and
vcvt_f32_f16 NEON intrinsics
On
This fixes PR56982 by properly modeling the control-flow
of setjmp. It basically behaves as a non-local goto target
so this patch treats it so - it makes it start a basic-block
and get abnormal edges from possible sources of non-local
gotos. The patch also fixes the bug that longjmp is marked
This fixes PR56921 in a better way and restores the ability
to ggc-collect during RTL loop passes. The patch stores
the simple-loop-description in a separate member of struct loop
and not its aux field which is not scanned by GC.
Bootstrapped and tested on x86_64-unknown-linux-gnu and
On Wed, 10 Apr 2013, Richard Biener wrote:
This handles commutative operations during SLP tree build in the
way that if one configuration does not match, the build will
try again with commutated operands for. This allows to remove
the special-casing of commutated loads in a complex
These changes are what we used to try here at Intel after bunch of
changes which made pre-alloc scheduler more stable. We benchmarked
both register pressure algorithms and overall result was not that
promising.
We saw number of regressions e.g. for optset -mavx -O3 -funroll-loops
-ffast-math
Currently, epilogue is not generated in RTL for function that can return
using a single instruction. This patch enables RTL epilogue for such
functions on targets that can benefit from using a sequence of LDRD
instructions in epilogue instead of a single LDM instruction.
No regression on qemu
This patch converts define_insn into define_insn_and_split to split
some alternatives of movsicc_insn and some scc patterns that cannot be
expressed using movsicc. The patch emits cond_exec RTL insns.
Ok for trunk?
Thanks,
Greta
gcc/
2013-02-19 Greta Yorsh greta.yo...@arm.com
*
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
http://translationproject.org/latest/gcc/de.po
(This file, 'gcc-4.8.0.de.po', has just
Bryce McKinlay bmckin...@gmail.com writes:
It certainly _did_ work as intended previously.
Only by chance, when libtool has to relink the library during install.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
And
Hi all,
here is patch for a recent regression with procedure pointers.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.8?
Cheers,
Janus
2013-04-17 Janus Weil ja...@gcc.gnu.org
PR fortran/56814
* interface.c (check_result_characteristics): Get result from interface
if
Janus Weil:
here is patch for a recent regression with procedure pointers.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.8?
Looks rather obvious. OK - and thanks for the patch.
Tobias
PS: If you have time, could you review my C_LOC patch at
On 13-04-16 6:56 PM, Michael Meissner wrote:
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]))
Bootstrap/make check/Specs2k are passing on i686 and x86_64.
Thanks for returning to this!
glibc has quite comprehensive testsuite for stringop. It may be useful to test
it
with -minline-all-stringop -mstringop-stategy=vector
I tested the patch on my core notebook and my memcpy micro
1 - 100 of 130 matches
Mail list logo
