--- 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
--- Comment #51 from bernds at gcc dot gnu dot org 2010-07-29 19:46 ---
Thanks. I can more-or-less produce the same assembly with a cross compiler,
but just from looking at the assembly and the debugging dumps I can't quite
figure out which function is being miscompiled. Can you
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-29 19:47 ---
Subject: Bug 45110
Author: jakub
Date: Thu Jul 29 19:47:02 2010
New Revision: 162691
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162691
Log:
PR debug/45110
* dwarf2out.c (dwarf_attr_name):
Output:
$ gcc -Os -fschedule-insns -fcompare-debug testcase.c
gcc: error: testcase.c: -fcompare-debug failure
Tested revisions:
r162653 - fail
r161170 - fail
r153685 - fail
--
Summary: -fcompare-debug failure with -Os -fschedule-insns
Product: gcc
Version:
--- Comment #1 from zsojka at seznam dot cz 2010-07-29 20:21 ---
Created an attachment (id=21356)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21356action=view)
reduced testcase
Valgrind doesn't report any invalid/uninitialised read while compiling this
testcase.
--
--- Comment #1 from janus at gcc dot gnu dot org 2010-07-29 20:59 ---
Subject: Bug 44962
Author: janus
Date: Thu Jul 29 20:58:57 2010
New Revision: 162695
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162695
Log:
2010-07-29 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #2 from janus at gcc dot gnu dot org 2010-07-29 21:01 ---
Fixed with r162695. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-29 21:07 ---
For completeness, the current patch has failures for for following test cases.
In particular:
- Reading - here, the d == 0 does not harm (e.g. fmt_bz_bn.f).
- FMT_G: Here, the the width check is wrong (e.g.
--- Comment #5 from burnus at gcc dot gnu dot org 2010-07-29 21:07 ---
Subject: Bug 45125
Author: burnus
Date: Thu Jul 29 21:07:34 2010
New Revision: 162696
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162696
Log:
2010-07-29 Tobias Burnus bur...@net-b.de
PR
--- Comment #8 from burnus at gcc dot gnu dot org 2010-07-29 21:07 ---
Subject: Bug 45087
Author: burnus
Date: Thu Jul 29 21:07:34 2010
New Revision: 162696
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162696
Log:
2010-07-29 Tobias Burnus bur...@net-b.de
PR
--- Comment #9 from burnus at gcc dot gnu dot org 2010-07-29 21:08 ---
FIXED on the trunk (4.6).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from burnus at gcc dot gnu dot org 2010-07-29 21:08 ---
FIXED on the trunk (4.6).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-29 21:13 ---
(In reply to comment #1)
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:
[...]
it prints the following output:
ifc: (
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
CC||janus at gcc dot gnu dot org
Status|UNCONFIRMED
--- Comment #10 from sje at cup dot hp dot com 2010-07-29 21:32 ---
I have posted a patch for this bug to gcc-patches.
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02302.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583
--- Comment #6 from sje at cup dot hp dot com 2010-07-29 21:50 ---
Because the ia64-hp-hpux11.31 compiler generates 32 bit code by default you
cannot do a bootstrap build in 64 bit mode. From install.texi:
Note that the bootstrap compiler and the resulting GCC must be link
compatible,
--- Comment #4 from hjl dot tools at gmail dot com 2010-07-29 22:30 ---
It isn't fixed. Revision 162688 gave
FAIL: c-c++-common/uninit-17.c (test for warnings, line 14)
FAIL: c-c++-common/uninit-17.c -Wc++-compat (test for warnings, line 14)
--
hjl dot tools at gmail dot com
1 - 100 of 111 matches
Mail list logo
