--- Comment #4 from hjl dot tools at gmail dot com 2010-07-30 04:11 ---
I was wrong. It never worked.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45136
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-07-30
02:48 ---
At r162696, this bug is back on x86_64-apple-darwin10...
gfortran -r -nostdlib -o cns_solve-1007222053.exe array_reduced.o cns_reduced.o
genic_reduced.o -DINTEGER='long int' -DCNS_ARCH_TYPE_LINUX -fdefaul
--- Comment #52 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-30
02:27 ---
Subject: Re: [4.6 regression] Revision 162270 failed
to bootstrap
On Thu, 29 Jul 2010, bernds at gcc dot gnu dot org wrote:
> --- Comment #51 from bernds at gcc dot gnu dot org 2010-07-29 19
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-07-30 01:55
---
I see this as an enhancement.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-07-30 01:49
---
This is really odd because the patch does not touch these parts of the library,
at least for inquire_3.f90. I wonder if there is something latent here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45131
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-07-30 01:47
---
Reply to comment #9.
Yes, this is what I was thinking. I wanted to float the first step out there to
see what else we would discover. As seen in PR 45131 there are other oddities
we need to deal with.
--
h
--- Comment #3 from zsojka at seznam dot cz 2010-07-30 01:35 ---
Thank you for the reply! Then, the bug had to be fixed/hiden before r161655, I
can reproduce it with r161170, r153685 and gcc 4.5.0. (maybe you replied to a
wrong PR?)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=451
--- Comment #2 from kkojima at gcc dot gnu dot org 2010-07-30 00:50 ---
With -g, .ira for the above test case has the insns:
(insn 143 141 229 14 (set (reg/f:SI 1 r1 [238])
(const_int 2046 [0x7fe])) yyy.c:25 176 {movsi_ie}
(expr_list:REG_EQUAL (const_int 2046 [0x7fe])
--- Comment #1 from kkojima at gcc dot gnu dot org 2010-07-30 00:49 ---
Created an attachment (id=21357)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21357&action=view)
A reduced test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45137
SH doesn't bootstrap on trunk for a while with
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/sched-vis.o differs
It turned out that -g changes the result of postreload
optimization for sched-vis.c.
--
Summary: -g changes the generated
--- Comment #2 from hjl dot tools at gmail dot com 2010-07-30 00:32 ---
It is caused by revision 161655:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg6.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- 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 cha
--- 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 #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
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
CC||janus at gcc dot gnu dot org
Status|UNCONFIRMED
--- 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: (
--- 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 #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 #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=gcc&view=rev&rev=162696
Log:
2010-07-29 Tobias Burnus
PR fortran/45087
P
--- 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=gcc&view=rev&rev=162696
Log:
2010-07-29 Tobias Burnus
PR fortran/45087
P
--- 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. transpose
--- 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 #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=gcc&view=rev&rev=162695
Log:
2010-07-29 Janus Weil
PR fortran/44962
* reso
--- 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=21356&action=view)
reduced testcase
Valgrind doesn't report any invalid/uninitialised read while compiling this
testcase.
--
http://
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: 4.6.0
--- 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=gcc&view=rev&rev=162691
Log:
PR debug/45110
* dwarf2out.c (dwarf_attr_name): H
--- 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 produc
--- 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
/home/bergner/gcc/gcc-mainline-base/gcc/dia
--- 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
complex,
--- 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=21355&action=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 #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 #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.
--
http://gcc.gnu.
--- 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
Summary|[4
--- 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 delete_cor
--- 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 #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 #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 dc
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 dce.c:495
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
/opt/gc
--- 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
--- 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=gcc&view=rev&rev=162688
Log:
2010-07-29 Janus Weil
PR fortran/45004
* tran
--- 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
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
CC||domob at gcc dot gnu dot org
Status|UNCONFIRMED
--- 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
Status
--- 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 sepa
--- 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 accesses)
The following quick snippet crashes with GCC 4.5.0, on the second call to
get():
"""
#include
int make_int() { return 52; }
int main()
{
std::future future_in = std::async(make_int);
printf("%d\n", future_in.get());
printf("%d\n", future_in.get());
}
"""
Backtrace:
Program received sig
--- 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/ ?
Y
--- 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 #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 #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 #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 n
--- 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=21351&action=view)
all sources
--
aleksazr at gmail dot com changed:
What|Removed |Added
---
--- 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?
Consider following test-case:
$ cat templorder.cc
#include
struct Foo {
int a;
char b;
};
template inline int match(const T &x)
{
return 23;
}
template inline int not_match(const T &x)
{
return match(x) + 1;
}
template <> inline int match(const int &x)
{
return 42;
}
inline int ma
--- 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 GFC_DECL_SP
--- 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 |Ad
--- 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 lang_s
--- 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=gcc&view=rev&rev=162683
Log:
Revert change in revision 162652.
2010-07-29 Xinliang David Li
--- 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 #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 #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
---
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: gfortran.dg/inquire_siz
--- 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=21350&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45130
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
=
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 a
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 TF_AD_SPLI
--- 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=21349&action=view)
Potential fix
Could you verify that this fixes it?
--
bernds at gcc dot gnu dot org changed:
Wh
--- 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.
Thank
--- 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 #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 #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=21348&action=view)
all sources
unpack to c:\ so that you have c:\00 folder
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45127
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 dword
--- 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
--- 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 co
--- 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=gcc&view=rev&rev=162678
Log:
PR rtl-optimization/42575
* dce.c (word_dce_pro
--- 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 #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=gcc&view=rev&rev=162676
Log:
2010-07-29 Richard Guenther
PR tree-optimization/
--- 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 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
impl
--- 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|R
--- 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 #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
Know
--- 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
Status|U
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfi
--- 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
--- 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=gcc&view=rev&rev=162674
Log:
2010-07-29 Mikael Morin
PR fortran/42051
P
--- 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=gcc&view=rev&rev=162674
Log:
2010-07-29 Mikael Morin
PR fortran/42051
PR
--- 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.
http://gcc.gnu.org/ml/
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 s
--- 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
Kn
--- 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=gcc&view=rev&rev=162673
Log:
2010-07-29 Richard Guenther
PR middle-end/45034
--
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 #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
--- 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 probl
--
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 #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
St
--- 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;
:
D.2737_3 = MEM[(struct Foo *)x_1(D) + -8B].p;
*D.2737_3 = 0;
return;
}
Generating constraints for bar (bar)
bar.arg0
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,
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
1 - 100 of 110 matches
Mail list logo
