Please move such unconstructive arguments elsewhere.
Alfred M. Szmidt a...@gnu.org writes:
Please move such unconstructive arguments elsewhere.
Wait. Steven's comment was on the snarky side, but coming from a
long-time gcc contributor I don't think it was over the line or even
near it. I think he was expressing a perfectly valid point of view
Ian Lance Taylor i...@google.com writes:
Please move such unconstructive arguments elsewhere.
Wait. Steven's comment was on the snarky side, but coming from a
long-time gcc contributor I don't think it was over the line or even
near it. I think he was expressing a perfectly valid point of
Ian Lance Taylor wrote:
Alfred M. Szmidt a...@gnu.org writes:
Please move such unconstructive arguments elsewhere.
Wait. Steven's comment was on the snarky side, but coming from a
long-time gcc contributor I don't think it was over the line or even
near it. I think he was expressing a
On 07/28/10 10:26, Richard Guenther wrote:
[snip]
You can use the flatten attribute to tell the compiler to inline all
calls in a given function, like
void __attribute__((flatten)) foo(void)
{
...
decode1();
...
}
and it will inline decode1() (and recursively all its callees).
[snip]
Will
Wait. Steven's comment was on the snarky side, but coming from a
long-time gcc contributor I don't think it was over the line or even
near it. I think he was expressing a perfectly valid point of view
considering the constraints that the FSF places on gcc developers. For
certain aspects of
Quoting Richard Kenner ken...@vlsi1.ultra.nyu.edu:
Could part of the problem here be that RMS's view on documentation is
that it's meant to be a creative process, somewhat akin to writing a book,
and that mechanically creating documentation will produce something of
much lower quality than
But even for documentation written by hand, often I find that I'd like to
start out with some comment or example from the actual code. The GPL / GFDL
dichotomy doesn't allow me to do that, so some documentation just won't get
written.
Taking an example from actual code would be fair use and
On 07/29/10 08:26, Richard Kenner wrote:
But even for documentation written by hand, often I find that I'd like to
start out with some comment or example from the actual code. The GPL / GFDL
dichotomy doesn't allow me to do that, so some documentation just won't get
written.
Taking an example
Isn't one of the specific instances of this issue the desire to copy
some of the constraints information from the source, which would need to
go into the user manual rather than internals documentation?
And in some cases a function index with documentation may be precisely
what the
Richard Kenner wrote:
Could part of the problem here be that RMS's view on documentation is
that it's meant to be a creative process, somewhat akin to writing a book,
and that mechanically creating documentation will produce something of
much lower quality than what's done by hand? Back when
It buys the HIRLAM code about 100 seconds out of 8 thousands:
New:
$ grep 'FORECAST TOOK' HL_Cycle_2010072912.html
FORECAST TOOK 775.5685 SECONDS
FORECAST TOOK 779.8127 SECONDS
FORECAST TOOK29.8419 SECONDS
FORECAST TOOK 7929.5913 SECONDS
Compared to (old):
$ grep 'FORECAST TOOK'
Thanks for testing it out. There are probably more tuning
opportunities for fortran (e.g. larger solution search space, more
aggressive pruning, and more advanced loop invariants and register
pressure estimation), which I hope someone can continue working on (or
me if I find more time).
David
On
On Thu, Jul 29, 2010 at 12:08 AM, Steven Bosscher stevenb@gmail.com
wrote:
On Wed, Jul 28, 2010 at 11:17 PM, Mark Mitchell m...@codesourcery.com
wrote:
Steven Bosscher wrote:
Why not just ignore RMS and the license issues and simply do what we
think suits us and the project. Let the
On Thu, Jul 29, 2010 at 01:20:45PM -0700, Brian Makin wrote:
Or to move to a better foundation? It seems to me that gcc has had various
issues for various reasons for quite a while now. RMS is all for tightly
controller yet freely distributable software.
Maybe it's time to throw more
Snapshot gcc-4.5-20100729 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100729/
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
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-29 06:34 ---
For completeness: The code is invalid - which gfortran also properly diagnoses
before segfaulting.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2010-07-29 08:11 ---
Close as WONTFIX as suggested by Dominique.
The trunk now uses -fwhole-file and some of the warning messages have been
fixed while others have been added as dg-warning. The commit was Rev.162491:
--- Comment #9 from burnus at gcc dot gnu dot org 2010-07-29 08:26 ---
The committed patch has added:
+#ifdef HAVE_TTYNAME
+ if (u-unit_number == options.stdin_unit
+ || u-unit_number == options.stdout_unit
+ || u-unit_number == options.stderr_unit)
+ {
+
Dwarf 3 and 4 state that if DW_AT_accessibility is missing, the default is
DW_ACCESS_private in DW_TAG_class_type and DW_ACCESS_public otherwise.
Unfortunately dwarf2out.c assumes the default is DW_ACCESS_public always.
Not sure if GDB (or other dwarf consumers) makes the same assumption.
If not,
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-29 08:55 ---
Looking at GDB:
/* Handle accessibility and virtuality of field.
The default accessibility for members is public, the default
accessibility for inheritance is private. */
if (die-tag !=
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-29 08:58 ---
Created an attachment (id=21346)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21346action=view)
gcc46-pr45124.patch
Untested fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45124
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-29 08:58 ---
Created an attachment (id=21347)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21347action=view)
gcc46-pr45110.patch
Untested fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from domob at gcc dot gnu dot org 2010-07-29 09:07 ---
Subject: Bug 45117
Author: domob
Date: Thu Jul 29 09:06:53 2010
New Revision: 162670
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162670
Log:
2010-07-29 Daniel Kraft d...@domob.eu
PR fortran/45117
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-29 09:20 ---
Please provide also gcc command line options used to trigger the ICE on
page-writeback.i. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45102
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-29 09:37 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-29 09:40 ---
Confirmed. In the original code b doesn't overflow.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
As reported by Dominique, the patch for PR 45087,
http://gcc.gnu.org/ml/fortran/2010-07/msg00430.html, causes an ICE for
attachment 20927 (= PR 43945 comment 19 and PR 44936 comment 1).
pr44936_1.f90: In function 'd_coo_err':
pr44936_1.f90:198:0: internal compiler error: in gfc_get_symbol_decl,
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-29 10:01 ---
Confirmed, mine.
We generate wrong constraints for
bar (int * * x)
{
int * D.2737;
bb 2:
D.2737_3 = MEM[(struct Foo *)x_1(D) + -8B].p;
*D.2737_3 = 0;
return;
}
Generating constraints for bar (bar)
--- Comment #3 from domob at gcc dot gnu dot org 2010-07-29 10:03 ---
Fixed on trunk, closing.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45119
--- Comment #1 from mikael at gcc dot gnu dot org 2010-07-29 10:25 ---
Confirmed.
Workaround:
trans-decl.c b/trans-decl.c
index d5be2e4..14e78a4 100644
--- a/trans-decl.c
+++ b/trans-decl.c
@@ -1457,7 +1457,10 @@ gfc_get_extern_function_decl (gfc_symbol * sym)
/* Avoid
--- Comment #7 from mikael at gcc dot gnu dot org 2010-07-29 10:26 ---
(In reply to comment #6)
Patch: http://gcc.gnu.org/ml/fortran/2010-07/msg00430.html
Regressing, see PR45125.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45087
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45102
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-07-29 11:00
---
Subject: Bug 45034
Author: rguenth
Date: Thu Jul 29 10:59:54 2010
New Revision: 162673
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162673
Log:
2010-07-29 Richard Guenther rguent...@suse.de
PR
--- Comment #17 from rguenth at gcc dot gnu dot org 2010-07-29 11:00
---
Fixed on the trunk sofar.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Hi,
When -O -ftree-vrp optimizations are used the volatileness seems to be lost.
Even though this test relies upon undefined behaviour according to the C99 spec
the result is different with optimizations on or off.
I think that even when both accesses of vus are in the same expression it
should
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2010-07-29
11:15 ---
On x86_64-apple-darwin10, these failures at -m32 and -m64 appear to be
suppressed when building with --enable-checking=release and reappear when
building with --enable-checking=yes.
--- Comment #7 from mikael at gcc dot gnu dot org 2010-07-29 11:23 ---
Subject: Bug 44064
Author: mikael
Date: Thu Jul 29 11:22:40 2010
New Revision: 162674
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162674
Log:
2010-07-29 Mikael Morin mik...@gcc.gnu.org
PR
--- Comment #18 from mikael at gcc dot gnu dot org 2010-07-29 11:23 ---
Subject: Bug 42051
Author: mikael
Date: Thu Jul 29 11:22:40 2010
New Revision: 162674
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162674
Log:
2010-07-29 Mikael Morin mik...@gcc.gnu.org
PR
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-29 11:25 ---
Possible values for vus are [0, 65535], volatileness does not change that.
Multiplying this as int is always positive (overflow is undefined), so
we can change the test to (vus * vus) != 0.
--
rguenth at gcc dot
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-29 11:34 ---
Thus, invalid.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from mikael at gcc dot gnu dot org 2010-07-29 11:52 ---
Backport on 4.5 pending...
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from mikael at gcc dot gnu dot org 2010-07-29 11:55 ---
With the link error being tracked as PR44065, I'm tempted to say that this is a
duplicate of PR42051.
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from majbrock at dse dot nl 2010-07-29 12:00 ---
Ok, that is a choice.
But even then vus is read only once, where it appeared twice in the expression.
What about the possible side-effects of reading a volatile?
--
majbrock at dse dot nl changed:
What
--- Comment #2 from dominiq at lps dot ens dot fr 2010-07-29 12:19 ---
The patch in comment #1 fixes the ICE, but AFAICT (due to other patches in my
tree) make an error message to disappear in pr44348, pr44614, and pr44616:
[macbook] f90/bug% cat pr44614.f90
module factory_pattern
--- Comment #3 from schwab at linux-m68k dot org 2010-07-29 12:21 ---
That does not change the fact that vus*vus can be assumed to be non-negative.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-29 12:30 ---
Subject: Bug 45120
Author: rguenth
Date: Thu Jul 29 12:30:09 2010
New Revision: 162676
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162676
Log:
2010-07-29 Richard Guenther rguent...@suse.de
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-29 12:31 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from bernds at gcc dot gnu dot org 2010-07-29 12:40 ---
Subject: Bug 42575
Author: bernds
Date: Thu Jul 29 12:39:57 2010
New Revision: 162678
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162678
Log:
PR rtl-optimization/42575
* dce.c
--- Comment #4 from majbrock at dse dot nl 2010-07-29 12:41 ---
Andreas said:
That does not change the fact that vus*vus can be assumed to be non-negative.
And then this bug was closed again.
So because one part of my report is dismissed you also dismiss the other part?
I already
--- Comment #5 from schwab at linux-m68k dot org 2010-07-29 12:55 ---
Works fine here with gcc 4.4.4.
movzwl vus, %eax
movzwl vus, %edx
--
schwab at linux-m68k dot org changed:
What|Removed |Added
This program is written for AT91SAM9260.
It is on compiled with yagarto with GCC 4.5.0.
on win xp sp2.
The prog reads 10 dwords from
address 0 and sends them through uart.
Adress 0 (on '9260) can either be ROM or SRAM,
depending on REMAP settings.
The prog first does a REMAP, then reads 10
--- Comment #1 from aleksazr at gmail dot com 2010-07-29 13:13 ---
Created an attachment (id=21348)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21348action=view)
all sources
unpack to c:\ so that you have c:\00 folder
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45127
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-29 13:27 ---
And with all other versions I tried (4.3 and 4.5)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45126
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-29 13:30 ---
rar is not a portable archive format. Please use tar instead together with
gzip (or zip).
You might want to try -fno-delete-null-pointer-checks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45127
--- Comment #7 from majbrock at dse dot nl 2010-07-29 13:30 ---
Thank you both for looking into it and explaining the behaviour.
I feel stupid and apologize, because I was certain that it was not read twice.
Yet now I can no longer reproduce that, so I guess I was wrong after all.
--- Comment #15 from bernds at gcc dot gnu dot org 2010-07-29 13:49 ---
Created an attachment (id=21349)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21349action=view)
Potential fix
Could you verify that this fixes it?
--
bernds at gcc dot gnu dot org changed:
The following code (from pr40737)
! { dg-do compile }
module testmod
implicit none
type VARIABLES_MAILLE
real :: cell_var
end type VARIABLES_MAILLE
type (VARIABLES_MAILLE), pointer, dimension( :) :: Hydro_vars
real, pointer, dimension(:) :: Ro
end module testmod
program
The following field is too small for the E edit descriptor:
print '(e4.2)', 1.0
end
Expected: Print a warning like ifort:
test.f90(1): warning #6894: The field width is too small for the number of
fractional digits. [2]
print '(e4.2)', 1.0
---^
For that example at least 7 digits
Command line:
$ gcc -Os -fsched-spec-load -fschedule-insns -fcompare-debug testcase.c
Valgrind output:
$ valgrind --trace-children=yes --track-origins=yes -q
/mnt/svn/gcc-trunk/binary-162653-lto-fortran-checking-yes-rtl-df/bin/gcc -Os
-fsched-spec-load -fschedule-insns -fcompare-debug testcase.c
--- Comment #1 from zsojka at seznam dot cz 2010-07-29 13:59 ---
Created an attachment (id=21350)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21350action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45130
On Linux/x86-64, when configured with
--with-cpu=atom --enable-clocale=gnu --with-system-zlib --enable-shared
--with-demangler-in-ld -with-plugin-ld=ld.gold --enable-gold --with-fpmath=sse
revision 162667 gave
FAIL: gfortran.dg/inquire_size.f90 -O0 execution test
FAIL:
--- Comment #1 from hjl dot tools at gmail dot com 2010-07-29 14:12 ---
It may be caused by revision 162653:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg01007.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-07-29 14:16 ---
It happened between revision 162661 and revision 162667.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2010-07-29 14:19 ---
It is caused by revision 162667:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg01021.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl at gcc dot gnu dot org 2010-07-29 14:31 ---
Subject: Bug 45119
Author: hjl
Date: Thu Jul 29 14:30:18 2010
New Revision: 162683
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162683
Log:
Revert change in revision 162652.
2010-07-29 Xinliang David Li
--- Comment #3 from burnus at gcc dot gnu dot org 2010-07-29 14:40 ---
The segfault occurs for:
l.4768 gfc_add_modify (lse.post, GFC_DECL_SPAN(decl), tmp);
It seems as if GFC_DECL_SPAN(decl) access a NULL pointer. That's
decl-decl_common.lang_specific-span
where
--- Comment #4 from burnus at gcc dot gnu dot org 2010-07-29 14:42 ---
Sorry that comment 3 and the change was supposed to go to PR 45128.
I think the PR here is relatively easily fixable.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-29 14:44 ---
Carry over the comment from PR 45125, where I had posted it initially (and
accidentally).
The segfault occurs for:
l.4768 gfc_add_modify (lse.post, GFC_DECL_SPAN(decl), tmp);
It seems as if
Consider following test-case:
$ cat templorder.cc
#include iostream
struct Foo {
int a;
char b;
};
templatetypename T inline int match(const T x)
{
return 23;
}
template typename T inline int not_match(const T x)
{
return match(x) + 1;
}
template inline int matchint(const int x)
{
--- Comment #4 from burnus at gcc dot gnu dot org 2010-07-29 14:55 ---
HJ, as it works on most systems, can you do some debugging?
a) Does the system has HAVE_TTYNAME defined for libgfortran/ ?
b) If it fails in the library, how? Otherwise: Which of the asserts fails in
the test case?
--- Comment #3 from aleksazr at gmail dot com 2010-07-29 14:56 ---
Created an attachment (id=21351)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21351action=view)
all sources
--
aleksazr at gmail dot com changed:
What|Removed |Added
--- Comment #47 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-29
15:05 ---
Subject: Re: [4.6 regression] Revision 162270 failed
to bootstrap
On Mon, 19 Jul 2010, dave at hiauly1 dot hia dot nrc dot ca wrote:
--- Comment #33 from dave at hiauly1 dot hia dot nrc
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-07-29 15:17 ---
But perhaps I am missing some rule in the C++ standard.
Yes you are. You are missing that fundamental types in C++ don't have an
associated namespace.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45132
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-07-29 15:19 ---
*** This bug has been marked as a duplicate of 29131 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-07-29 15:19
---
*** Bug 45132 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from hjl dot tools at gmail dot com 2010-07-29 15:47 ---
(In reply to comment #4)
HJ, as it works on most systems, can you do some debugging?
Trunk was broken since yesterday and was fixed a while ago.
a) Does the system has HAVE_TTYNAME defined for libgfortran/ ?
The following quick snippet crashes with GCC 4.5.0, on the second call to
get():
#include future
int make_int() { return 52; }
int main()
{
std::futureint future_in = std::async(make_int);
printf(%d\n, future_in.get());
printf(%d\n, future_in.get());
}
Backtrace:
Program received
--- Comment #4 from rearnsha at gcc dot gnu dot org 2010-07-29 16:29
---
Volatile alone won't prevent re-ordering of non-volatile memory operations.
The volatile keyword only applies to that particular location (requiring the
compiler not to remove it, or change the number of
--- Comment #5 from burnus at gcc dot gnu dot org 2010-07-29 17:00 ---
(In reply to comment #4)
Fixed for the unmodified example in comment 1 - and also for PR 40011 comment
47.
However, the following remains to be done: It still fails if one moves module
iso_red into a separate
--- Comment #3 from davidxl at gcc dot gnu dot org 2010-07-29 17:21 ---
Fixed in r162687
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
CC||domob at gcc dot gnu dot org
Status|UNCONFIRMED
--- Comment #1 from paolo dot carlini at oracle dot com 2010-07-29 17:34
---
Jon, can you have a look? Thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from janus at gcc dot gnu dot org 2010-07-29 18:14 ---
Subject: Bug 45004
Author: janus
Date: Thu Jul 29 18:14:16 2010
New Revision: 162688
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162688
Log:
2010-07-29 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #6 from janus at gcc dot gnu dot org 2010-07-29 18:18 ---
Fixed with r162688. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
At revision 162686 boostrapping fails on powerpc-apple-darwin9 with
/opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/lib/ -isystem
The DCE patch for PR rtl-optimization/42575 appears to have introduced a
bootstrap failure on PowerPC targets:
/farm/dje/src/src/gcc/cfg.c: In function 'scale_bbs_frequencies_gcov_type':
/farm/dje/src/src/gcc/cfg.c:1109:1: internal compiler error: in
delete_corresponding_reg_eq_notes, at
--- Comment #1 from dje at gcc dot gnu dot org 2010-07-29 18:32 ---
This fails on powerpc-ibm-aix as well:
/farm/dje/src/src/gcc/cfg.c: In function 'scale_bbs_frequencies_gcov_type':
/farm/dje/src/src/gcc/cfg.c:1109:1: internal compiler error: in
delete_corresponding_reg_eq_notes, at
--- Comment #1 from dje at gcc dot gnu dot org 2010-07-29 18:33 ---
*** This bug has been marked as a duplicate of 45134 ***
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dje at gcc dot gnu dot org 2010-07-29 18:33 ---
*** Bug 45135 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45134
--- Comment #3 from bergner at gcc dot gnu dot org 2010-07-29 18:57 ---
Ditto for powerpc64-linux:
/home/bergner/gcc/gcc-mainline-base/gcc/fortran/module.c: In function
read_module:
/home/bergner/gcc/gcc-mainline-base/gcc/fortran/module.c:4542:1: internal
compiler error: in
--- Comment #4 from dominiq at lps dot ens dot fr 2010-07-29 19:07 ---
Adjust summary.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #4 from changpeng dot fang at amd dot com 2010-07-29 19:14
---
(In reply to comment #1)
The misaligned indirect-refs will vanish soon.
I saw your patch that remove ALIGNED_INDIRECT_REF. Do you also plan to remove
MISALIGNED_INDIRECT_REF? Thanks.
--
--- Comment #5 from aleksazr at gmail dot com 2010-07-29 19:19 ---
Thank you for a good explanation. Cheers!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45127
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-29 19:33 ---
Created an attachment (id=21355)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21355action=view)
Draft patch
Jerry, what do you think?
Note: The smallest width is actually 3 also for D and E: That's enough to
--- Comment #1 from janus at gcc dot gnu dot org 2010-07-29 19:36 ---
Here is a reduced/modified version of the code in comment #0, which also
exhibits a runtime segfault, although the code seems to be valid:
module polynomial
implicit none
private
type, public :: polynom
--- Comment #5 from bergner at gcc dot gnu dot org 2010-07-29 19:37 ---
Debugger info:
#0 fancy_abort (file=0x112a7098
/home/bergner/gcc/gcc-mainline-base/gcc/dce.c, line=495,
function=0x112a7180 delete_corresponding_reg_eq_notes) at
1 - 100 of 127 matches
Mail list logo