Quoting Kaz Kojima kkoj...@rr.iij4u.or.jp:
I've got some regressions with make check on sh4-unknown-linux-gnu.
It looks that all of them are failed with the undefined references to
__unorddf2/__unordsf2 when -mieee enabled.
That's a bug, then; we shouldn't use a library function there,
but
Christian Bruel wrote:
Hi Kaz,
Kaz Kojima wrote:
BTW, it looks that softfp __unord?f2 routines check signaling NaNs
only. This makes __builtin_isnan return false for quiet NaNs for
which current fp-bit ones return true when -mieee enabled. Perhaps
that change of behavior might be OK for
On 7/22/10 3:34 AM, Steven Bosscher wrote:
On Wed, Jul 21, 2010 at 10:09 PM, Maxim Kuvyrkovma...@codesourcery.com wrote:
Cselib can /always/ be used during second scheduling pass
Except with the selective scheduler when it works on regions that are
not extended basic blocks, I suppose?
Quoting Christian Bruel christian.br...@st.com:
Edited to apply on top of latest Joern's patch. Certainly not optimal
but it fixes the QNaNs checks for builtins and inlined unordered
comparisons for -mieee or -fno-inite-math-only.
You are still on the wrong track; as I said in my earlier
Status
==
The GCC 4.5 branch is now frozen for preparation of a GCC 4.5.1
release candidate. Please refrain from checking in non-documentation
changes without release manager approval. If everything goes
right GCC 4.5.1 will be released around Jul 1st.
Quality Data
Priority
The 4.5 branch is frozen for preparation of a 4.5.1 release candidate
and the 4.5.1 release. Please refrain from checking in non-documentation
changes without release manager approval.
Thanks,
Richard.
A release canidate for GCC 4.5.1 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5.1-RC-20100722/
and shortly its mirrors. It has been generated from SVN revision 162408.
I have sofar bootstrapped and tested the release candidate on
x86_64-unknown-linux-gnu. Please test it and report
Joern Rennecke wrote:
Quoting Christian Bruel christian.br...@st.com:
Edited to apply on top of latest Joern's patch. Certainly not optimal
but it fixes the QNaNs checks for builtins and inlined unordered
comparisons for -mieee or -fno-inite-math-only.
You are still on the wrong track; as I
Joern Rennecke joern.renne...@embecosm.com wrote:
That's a bug, then; we shouldn't use a library function there,
but the cmpordered[sd]f_t_4 patterns.
Argh, I've missed the required patterns are incorporated already
in your patch. I'll test it again with sh-softfp-predicate-fix
when the tests
oops, resending it with a small typo fix (a branch became delayed :-().
Just in case it we accepted that SNaNs and QNaNs are not exclusive and
mimic the C model, a synthetic illustrative test case:
Compile with
sh-superh-elf-gcc -O2 -mieee -m4-nofpu snan.c snan2.c -g -o l.u ;
Quoting Christian Bruel christian.br...@st.com:
About the other part of your answer, non supporting SNaNs in the
fp-bit.c, it is a possibility that I didn't consider in my fix. This
restriction is quite a surprise to me because, related to NaNs, it is
not what I guess from the implementation
Quoting Christian Bruel christian.br...@st.com:
Using the ieee-sf.S + this patch
OK
Is this only a proof-of-concept, because you only change the ne[sd]f2
implementation? And you go out of your way to only accept a restricted
set of values. Plus, the overuse of the arithmetic unit hurts
Quoting Christian Bruel christian.br...@st.com:
oops, resending it with a small typo fix (a branch became delayed :-().
For an actual patch, you need to use the SL* macros from
config/sh/lib1funcs.h because the SH1 does not have delayed branches.
I refer you to the various issues I have raised with attributes proposals
in WG14 in the past, some at least of which have also been forwarded to
WG21. The committees have generally chosen not to listen to compatibility
concerns, except insofar as WG14 ended up not adopting general attribute
On Thu, 8 Jul 2010, Robert Dewar wrote:
For another take, though the Ada standard extensively uses the word
integral, it does prefer integer type, by analogy with array type,
record type etc, where no adjective is available.
But as noted the C++ standard prefers integral type, so might as
Snapshot gcc-4.5-20100722 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100722/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Fri, 16 Jul 2010, Joern Rennecke wrote:
Quoting Naveen H. S navee...@kpitcummins.com:
extendsfdf2 - gcc.c-torture/execute/conversion.c
gcc.dg/torture/fp-int-convert-float.c, gcc.dg/pr28796-2.c
Note that some tests invoke undefined behaviour; I've also come across this
when doing
Benjamin Kosnik wrote:
Is there a separate issue for libstdc++ doxygen? This situation is
subtly different from the one outlined above: it is the application of
a GPL'd tool over GPL'd sources, which the FSF + Red Hat legal have
both told me for years results in GPL'd docs (and is clearly
On Fri, Jul 23, 2010 at 1:22 AM, Mark Mitchell m...@codesourcery.com wrote:
2. Can we move GPL'd code into GFDL'd manuals, or copy text from GFDL's
manuals into GPL'd code, or auto-generated GFDL's manuals from GPL'd code?
This got complicated; see previous postings. But, it's not relevant to
Steven Bosscher wrote:
2. Can we move GPL'd code into GFDL'd manuals, or copy text from GFDL's
manuals into GPL'd code, or auto-generated GFDL's manuals from GPL'd code?
This got complicated; see previous postings. But, it's not relevant to
your question, since you're not trying to do that.
On Thu, Jul 22, 2010 at 04:36:46PM -0700, Mark Mitchell wrote:
Steven Bosscher wrote:
2. Can we move GPL'd code into GFDL'd manuals, or copy text from GFDL's
manuals into GPL'd code, or auto-generated GFDL's manuals from GPL'd code?
This got complicated; see previous postings. But,
Hi,
You mean I should define insn like this:
(define_insn *iorqi3_imm
[(set (mem:QI (match_operand:HI 0 register_operand b))
(ior:QI (mem:QI (match_operand:HI 1 register_operand b)
(mem:QI (plus: HI (match_operand:HI 2
register_operand f)
Quoting Joseph S. Myers jos...@codesourcery.com:
That diff does not appear to relate to undefined behavior. GCC considers
these out-of-range conversions to yield an unspecified value, possibly
raising an exception, as per Annex F, and does not take the liberty of
optimizing on the basis of
Quoting Joe Buck joe.b...@synopsys.com:
RMS is unlikely to abandon the GFDL because the features that many object
to as non-free are intentionally chosen, in part to make sure that he can
get his message out even in situations where a distributor would not agree
with that message. I think he
A release canidate for GCC 4.5.1 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5.1-RC-20100722/
and shortly its mirrors. It has been generated from SVN revision 162408.
I have sofar bootstrapped and tested the release candidate on
x86_64-unknown-linux-gnu. Please test
Joe Buck wrote:
However, if we have text that is entirely generated from a GPL program
by some kind of generator program, that text can be distributed under
the GPL.
As a license statement, that's accurate. As a policy statement, the FSF
seems to object if the output is a manual, but not
--- Comment #7 from jakub at gcc dot gnu dot org 2010-07-22 06:38 ---
Subject: Bug 45015
Author: jakub
Date: Thu Jul 22 06:38:25 2010
New Revision: 162397
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162397
Log:
PR debug/45015
* var-tracking.c (adjust_mems):
--- Comment #6 from jakub at gcc dot gnu dot org 2010-07-22 06:42 ---
Subject: Bug 44942
Author: jakub
Date: Thu Jul 22 06:42:02 2010
New Revision: 162398
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162398
Log:
Backport from mainline
2010-07-16 Jakub Jelinek
--- Comment #7 from burnus at gcc dot gnu dot org 2010-07-22 06:44 ---
(In reply to comment #5)
I have now asked at
Seemingly, I break the dependency chain in comment 3; thus, only with an added
TARGET in the module variable declaration and with an assumed-shaped dummy in
bar the
--- Comment #7 from jakub at gcc dot gnu dot org 2010-07-22 06:46 ---
Subject: Bug 44942
Author: jakub
Date: Thu Jul 22 06:46:28 2010
New Revision: 162399
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162399
Log:
Backport from mainline
2010-07-16 Jakub Jelinek
--- Comment #8 from jakub at gcc dot gnu dot org 2010-07-22 06:46 ---
Should be fixed now.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jakub at gcc dot gnu dot org 2010-07-22 06:48 ---
Should be fixed now for 4.4+.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-22 07:53 ---
Of course libmudflapth needs to come first, otherwise it doesn't override
libpthread symbols it means to override.
If it doesn't, that is a user error though.
--
jakub at gcc dot gnu dot org changed:
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-22 07:59 ---
So, 1. is fixed. If __sync_*compare_and_swap on PowerPC doesn't act as full
barrier, that would be a target bug, not libgomp bug.
Unless separate __sync_*_acq/__sync_*_rel builtins are added, I'm afraid the
only
--- Comment #13 from ramana at gcc dot gnu dot org 2010-07-22 08:31 ---
Subject: Bug 43698
Author: ramana
Date: Thu Jul 22 08:30:36 2010
New Revision: 162404
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162404
Log:
Fix PR target/43698
2010-07-22 Ramana Radhakrishnan
--- Comment #8 from burnus at gcc dot gnu dot org 2010-07-22 08:40 ---
Mine. Additional fix is needed for gfc_symbols_could_alias:
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -2811,6 +2811,17 @@ gfc_symbols_could_alias (gfc_symbol *lsym, gfc_symbol
*rsym)
if
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44281
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-22 08:49 ---
Fixed in 4.6 (by disabling struct-reorg).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44468
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-22 08:50 ---
wontfix on the branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||spop at gcc dot gnu dot org
Priority|P3
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-07-22 08:53 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44777
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44793
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44816
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44982
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45008
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44991
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.1
Version|unknown |4.5.0
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44763
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44753
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44581
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43867
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-22 09:04 ---
This was fixed. We now print
t.C: In function 'int __gthread_active_p()':
t.C:8:1: note: file /tmp/t.gcda not found, execution counts assumed to be zero
--
rguenth at gcc dot gnu dot org changed:
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44581
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-22 09:05 ---
Fixed on the branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44763
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44858
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.4.0
Known to work|4.1.2 |4.1.2 4.3.4
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45008
--- Comment #5 from jakub at gcc dot gnu dot org 2010-07-22 09:36 ---
The VRP changes have been committed, so on the trunk this will be now
reproduceable only with -O1 or -O2 -fno-tree-vrp.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44858
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-07-22 09:41
---
Can't be P1. We shipped it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.5.1 |4.3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33637
--- Comment #1 from nickc at redhat dot com 2010-07-22 09:42 ---
Hi Kazuhiro-san,
This is not a bug, it is the expected behaviour.
What is happening is that the return value from func() is being promoted to
signed int (and not unsigned int as you might expect). Thus since the
MOV.B
--- Comment #16 from burnus at gcc dot gnu dot org 2010-07-22 09:43 ---
(In reply to comment #13)
Created an attachment (id=21003)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21003action=view) [edit]
patch against my (diry) tree
patch restoring the old equivalence list on
Patch posted to http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01718.html
--- Comment #2 from dodji at gcc dot gnu dot org 2010-07-22 09:46 ---
Subject: Re: wrong nesting for inner template class
Patch posted to http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01718.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45024
--- Comment #9 from paul dot richard dot thomas at gmail dot com
2010-07-22 10:00 ---
Subject: Re: Aliasing of TARGET dummy argument not
detected correctly
Dear Tobias,
I think the patch below looks fine, however, if I set a break point, the
function gfc_check_dependency
This patch
2010-07-20 Jakub Jelinek ja...@redhat.com
* var-tracking.c (vt_expand_loc, vt_expand_loc_dummy): Bump maximum
depth to 8 from 5.
broke sparc-sun-solaris2.* bootstrap building 64-bit libjava:
$ /var/gcc/gcc-4.6.0-20100721/11-gcc-gas/./gcc/gcj
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-22 10:23 ---
That would be a target bug then, something isn't delegitimized when it should.
Please put a breakpoint on output_operand_lossage and print a backtrace and the
rtx that is being printed.
--
jakub at gcc dot gnu dot
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-22
10:35 ---
Subject: Re: [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC:
output_operand: invalid expression as operand
Here you go:
Breakpoint 5, output_operand_lossage (cmsgid=0xfe940c60 ) at
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-22 10:46 ---
This one actually shouldn't be IMHO delegimized, the setm44 value is just a
temporary and thus it shouldn't hold any value interesting for debug info.
Can you please attach -fdump-rtl-vartrack dump?
--
--- Comment #4 from davi dot arnaut at sun dot com 2010-07-22 10:54 ---
Let's get it documented? One sentence should do. I think it's pertinent because
-lpthread will most of the time come before user supplied compiler flags.
--
davi dot arnaut at sun dot com changed:
--- Comment #11 from jakub at gcc dot gnu dot org 2010-07-22 11:03 ---
Perhaps with LTO we could special case this (perhaps using some special
attribute) and only construct/destruct the first of these
static ios_base::Init __ioinit;
vars and optimize all the others away together with
--- Comment #12 from paolo dot carlini at oracle dot com 2010-07-22 11:25
---
The same idea vaguely occurred to me...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44952
--- Comment #9 from anitha dot boyapati at atmel dot com 2010-07-22 11:26
---
I think the bug is not due to 'naked' function. When the naked attribute is
removed for __init_seed(void), the following diff can be observed in the
assembly file.
--- Comment #10 from burnus at gcc dot gnu dot org 2010-07-22 11:35 ---
Subject: Bug 45019
Author: burnus
Date: Thu Jul 22 11:35:09 2010
New Revision: 162410
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162410
Log:
2010-07-22 Tobias Burnus bur...@net-b.de
PR
--- Comment #13 from jakub at gcc dot gnu dot org 2010-07-22 11:41 ---
So reopening for this enhancement...
Another alternative would be some .init.first array or something similar which
would contain pointers to functions to be run as early constructors and linker
would remove
--- Comment #39 from bernds at gcc dot gnu dot org 2010-07-22 11:48 ---
HJ, Dave, can you retest with mainline?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
--- Comment #19 from rob1weld at aol dot com 2010-07-22 11:50 ---
(In reply to comment #10)
Adding an additional 64-bit default configuration
(like amd64-pc-solaris2* or whatever) doubles the testing burden on me for
no
real benefit. In fact, I believe that the
--- Comment #4 from ro at gcc dot gnu dot org 2010-07-22 12:09 ---
Created an attachment (id=21281)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21281action=view)
-fdump-rtl-vartrack output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45028
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-22
12:10 ---
Subject: Re: [4.6 regression] ICE building 64-bit libjava on Solaris 2/SPARC:
output_operand: invalid expression as operand
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-22 10:46 ---
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-22 12:14 ---
Subject: Bug 45017
Author: rguenth
Date: Thu Jul 22 12:14:27 2010
New Revision: 162411
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162411
Log:
2010-07-22 Richard Guenther rguent...@suse.de
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-22 12:15 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from borntraeger at de dot ibm dot com 2010-07-22 12:41
---
the testcase will fail on big endian machines.
since r2=f and r1=2 instead of r2=2 and r1=f.
Can you adopt the testcase to check the endianess?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45017
--- Comment #5 from rguenther at suse dot de 2010-07-22 12:42 ---
Subject: Re: miscompile with bitfield and
optimization
On Thu, 22 Jul 2010, borntraeger at de dot ibm dot com wrote:
--- Comment #4 from borntraeger at de dot ibm dot com 2010-07-22 12:41
---
the testcase
ARM's *push_multi pattern code implementation can result in a buffer overflow.
The assembler instruction gets there built up in a 100 byte buffer but worst
case more buffer space is needed.
Original code:
--8--
{
int i;
char pattern[100];
if (TARGET_ARM)
--- Comment #9 from jamborm at gcc dot gnu dot org 2010-07-22 12:52 ---
Subject: Bug 44891
Author: jamborm
Date: Thu Jul 22 12:52:14 2010
New Revision: 162413
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162413
Log:
2010-07-22 Martin Jambor mjam...@suse.cz
PR
--- Comment #1 from John dot Tytgat at aaug dot net 2010-07-22 12:53
---
Created an attachment (id=21282)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21282action=view)
Proposed patch to fix the buffer overflow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45029
--- Comment #10 from jamborm at gcc dot gnu dot org 2010-07-22 12:54
---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
=gccview=revrev=162414
Log:
2010-07-22 Richard Guenther rguent...@suse.de
* lib/target-supports-dg.exp (dg-require-linker-plugin): New proc.
* lib/target-supports.exp (check_linker_plugin_available): Likewise.
PR lto/43373
* gcc.dg/lto/20100722-1_0.c: New testcase
=gccview=revrev=162414
Log:
2010-07-22 Richard Guenther rguent...@suse.de
* lib/target-supports-dg.exp (dg-require-linker-plugin): New proc.
* lib/target-supports.exp (check_linker_plugin_available): Likewise.
PR lto/43373
* gcc.dg/lto/20100722-1_0.c: New testcase
--- Comment #6 from schwab at linux-m68k dot org 2010-07-22 12:59 ---
Huh? This is one byte, how does endianess come into play?
By the use of bitfields.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45017
--- Comment #6 from jakub at gcc dot gnu dot org 2010-07-22 13:02 ---
Thanks, can I also ask for -fdump-rtl-aligments dump (i.e. one immediately
before *.vartrack)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45028
--- Comment #7 from ro at gcc dot gnu dot org 2010-07-22 13:09 ---
Created an attachment (id=21283)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21283action=view)
-fdump-rtl-alignments output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45028
This is a bug which needs to be fixed before -fwhole-file can be enabled by
default. Otherwise, the test results look fine. (Note: I tested with
-fwhole-file enabled by default and including the patch for PR 44945.)
Extended test case: gfortran.fortran-torture/execute/entry_4.f90
real,
--- Comment #8 from jakub at gcc dot gnu dot org 2010-07-22 13:34 ---
So it is wrong already before *.alignments, as it has stuff like:
(insn:TI 256 255 1556 2
/vol/gcc/src/hg/trunk/local/libjava/classpath/gnu/javax/print/ipp/attribute/defaults/FinishingsDefault.java:117
(set (reg:D
I
1 - 100 of 190 matches
Mail list logo
