--- Comment #10 from davidxl at gcc dot gnu dot org 2010-08-28 06:00
---
fixed in r163610.
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
CC||hjl dot tools at gmail dot
|
--- Comment #4 from igodard at pacbell dot net 2010-08-28 04:32 ---
Yes, I understand that the comma is not a sequence point, and a may be
evaluated (to a&) in any order w/r/t f() (to bool). But it is not legal to
evaluate a to bool before the call of |=, because |= takes bool&,
not bool
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-28 04:30 ---
It may be related to PR 44659.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-08-28 04:15 ---
>There *is* a sequence point.
No, the comma for function arguments is not a sequence point. So a or f()
could be evaluated first. And then really |= is not a real function :). It is
an operator which the operator
--- Comment #2 from igodard at pacbell dot net 2010-08-28 04:11 ---
"No it must be evaluated as if it was:
operator|=(a, f())"
Exactly. The arguments (a and f()) must be evaluated to their parameter types
(bool& and bool) before the call to |=. There *is* a sequence point; it's the
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-28 03:34 ---
This code is undefined.
sz.b |= f(sz, sz, sz, 3);
Has two setting of sz.b without a sequence point.
That is it can be interrupted as either:
bool temp = sz.b;
bool temp1 = f(sz, sz, sz, 3);
sz.b = temp | te
This code:
#include
struct s{
s(bool& bb) : i(0), b(bb), j(0) {}
int i;
bool& b;
int j;
};
boolf(s s1, s s2, s s3, int k) {
s3.b = true;
return false;
}
int main() {
bool bz = false;
s sz(bz);
sz.b |= f(sz, sz
--- Comment #3 from kargl at gcc dot gnu dot org 2010-08-28 00:25 ---
Reverting 163597 fixes the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45436
--- Comment #2 from kargl at gcc dot gnu dot org 2010-08-27 23:47 ---
FX, I've added you to this pr because I think your recent patch
to start integration of the REAL(16) code is the cause.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Add
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-27 23:39 ---
I believe that it is related to r163597. During the build of
libgfortran, the file kinds.h is generated. This file now
has GFC_REAL_10 and GFC_REAL_16 typedef'd to 'long double'.
--
kargl at gcc dot gnu dot org c
On Linux/x86, revision 163599 failed to bootstrap:
../../../src-trunk/libgfortran/intrinsics/cshift0.c: In function 'cshift0':
../../../src-trunk/libgfortran/intrinsics/cshift0.c:145:5: error: duplicate
case value
../../../src-trunk/libgfortran/intrinsics/cshift0.c:138:5: error: previously
used h
It would be nice for to automatically generate Fortran
interface blocks from the C source.
Something like
gfortran -fgenerate-c-interop-blocks foo.c
--
Summary: Automatically generate C interop interface blocks from C
code
Product: gcc
Versi
It is unnecessary to shift a value in a high register position (ah, bh, ch, dh)
down to a low register position (al, bl, cl, dl) to perform a machine
comparison. X86-64 Linux ABI exhaustive example:
#include
#include
#include
__attribute__ ((noinline)) bool check_via_c(uint64_t i) {
if ((i &
--- Comment #28 from driscoll at cs dot wisc dot edu 2010-08-27 22:53
---
> Your two functions are well defined as the scope of the temp is only lost
> after going out of scope.
I see "A reference is bound to a temporary object: the temporary object is
destroyed at the end of the refer
--- Comment #27 from pinskia at gcc dot gnu dot org 2010-08-27 22:21
---
>This first one is inspired by the code I was working on:
Your two functions are well defined as the scope of the temp is only lost after
going out of scope. So there is no references to a temp escaping unlike th
--- Comment #26 from driscoll at cs dot wisc dot edu 2010-08-27 22:02
---
I was surprised to see this is not caught by a warning as well. (The discussion
of whether it should be an error is silly; it pretty clearly shouldn't be.
There's -Werror if you disagree.)
Motivation: This surfac
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-27 21:51 ---
Fixed with r163599. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-27 21:51 ---
Subject: Bug 45432
Author: janus
Date: Fri Aug 27 21:50:47 2010
New Revision: 163599
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163599
Log:
2010-08-27 Janus Weil
PR fortran/45432
* matc
--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-27 21:35 ---
You need to read the documentation, which would tell you you need to use
-fmain=HelloWorld option.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2010-08-27 21:24
---
Subject: Bug 32049
Author: fxcoudert
Date: Fri Aug 27 21:24:13 2010
New Revision: 163597
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163597
Log:
PR fortran/32049
* gfortran.h (gfc_real
--- Comment #1 from leo dot izen at gmail dot com 2010-08-27 21:08 ---
Created an attachment (id=21580)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21580&action=view)
file I tried to compile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45433
Target: x86_64-fedora-linux-gnu
Configured with: ./configure --build=x86_64-fedora-linux-gnu --with-ecj-jar
Thread model: posix
gcc version 4.6.0 20100827 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-fsaw-java-file' '-v' '-save-temps' '-o' 'HelloWorld
--- Comment #2 from giecrilj at stegny dot 2a dot pl 2010-08-27 20:58
---
#9 0x00442a5e in digest_init_r (type=0x7618ac00,
init=0x7617c4c0, nested=1 '\001') at ../../gcc/cp/typeck2.c:785
785 permerror (input_location, "initializer-string for
array of
--- Comment #1 from janus at gcc dot gnu dot org 2010-08-27 19:40 ---
This should fix it (it was some kind of double-free problem):
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 163594)
+++ gcc/fortran/m
When running gfortran gfortran.dg/allocate_alloc_opt_9.f90 I get an ICE with
free_expr0(): Bad expr type
That happens for the second call to gfc_match_allocate and the ICE happens via
gfc_match_allocate (match.c:309) -> gfc_free_expr
valgrind writes:
==2974== Invalid read of size 4
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-08-27 19:25
---
Not working on the C frontend change. But the warning should be gone on trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #41 from burnus at gcc dot gnu dot org 2010-08-27 19:20 ---
FIXED on the 4.6 trunk.
Thanks to all involved in implementing the math intrinsics.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #40 from burnus at gcc dot gnu dot org 2010-08-27 19:18 ---
Subject: Bug 33197
Author: burnus
Date: Fri Aug 27 19:17:45 2010
New Revision: 163595
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163595
Log:
gcc/fortran/
2010-08-27 Tobias Burnus
PR fortran/3
--- Comment #9 from janus at gcc dot gnu dot org 2010-08-27 19:15 ---
Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from janus at gcc dot gnu dot org 2010-08-27 19:14 ---
Fixed with r163594. Closing.
(Salvatore, please open a new PR for your problem in comment #3 if you have
reduced it.)
--
janus at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-27 19:10 ---
4.5 and 4.6 give the column number, but of the closing brace, which is no
better
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45431
--- Comment #7 from janus at gcc dot gnu dot org 2010-08-27 19:02 ---
Subject: Bug 45420
Author: janus
Date: Fri Aug 27 19:02:15 2010
New Revision: 163594
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163594
Log:
2010-08-27 Janus Weil
PR fortran/45420
* matc
--- Comment #9 from rguenther at suse dot de 2010-08-27 18:52 ---
Subject: Re: Number of iteration analysis
bogus
On Fri, 27 Aug 2010, rakdver at kam dot mff dot cuni dot cz wrote:
> --- Comment #8 from rakdver at kam dot mff dot cuni dot cz 2010-08-27
> 18:47 ---
> Subject
--- Comment #8 from rakdver at kam dot mff dot cuni dot cz 2010-08-27
18:47 ---
Subject: Re: Number of iteration analysis
bogus
> > > when looking at the exit 6->7 number_of_iterations_ne is present with
> > > iv->base (cxb3014__test_block__char_pointers__element * {ref-all})
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|rtl-optimization|middle-end
Summary|Code size regression between|[4.5/4.6 R
--- Comment #2 from longb at cray dot com 2010-08-27 18:36 ---
Created an attachment (id=21579)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21579&action=view)
Test case, including source files and compile script
Attached tar.gz file contains the source files and the compile.gnu
== Steps to reproduce ==
#!/bin/sh
# 1. Create the source file
cat > 'bugpp.cpp' <<'/* EOF */'
struct personal_data
{ char name [01]; char surname [01]; }
const sc_me = {
"Christopher",
"Yeleighton" };
/* EOF */
# 2. Compile as C++
make 'bugpp'
# 3. Compile as C
mv 'bugpp.cpp' 'bug.c'
make
--- Comment #17 from pinskia at gcc dot gnu dot org 2010-08-27 18:33
---
*** Bug 45428 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-08-27 18:33 ---
*** This bug has been marked as a duplicate of 11407 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from longb at cray dot com 2010-08-27 18:31 ---
Comments from original submitter:
A [deleted] user has given me the following code which fails with gcc/4.5.0.
The
code is OK with PGI and CCE. The problem seems to come about from the use of
threadprivate in mod_globals.f
For this version:
> gfortran -v
Using built-in specs.
COLLECT_GCC=/opt/gcc/4.5.0/bin/../snos/bin/gfortran
COLLECT_LTO_WRAPPER=/opt/gcc/4.5.0/snos/libexec/gcc/x86_64-suse-linux/4.5.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../xt-gcc-4.5.0/configure --prefix=/opt/gcc/4.5.0/snos
--disa
--- Comment #3 from rwild at gcc dot gnu dot org 2010-08-27 18:15 ---
Maybe. Not all requirements from the installation manual can be checked
easily.
This one we can maybe fix, but for that please provide all information asked
for.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #1 from giecrilj at stegny dot 2a dot pl 2010-08-27 18:06
---
(In reply to comment #0)
> Fails to compile, but should work:
>
> struct A {
> char x[4];
> A():x("bug") { }
> };
>
> Error i get is:
>
> "main.cpp:3: error: array used as initializer"
>
Why do you thi
--- Comment #5 from reza at parvan dot net 2010-08-27 17:59 ---
(In reply to comment #2)
> That's not the main problem here. The problem is that this is an aggregate
> and
> we SRA only automatic vars, not global vars. And it isn't constant either
Jakub,
Thanks for that insight. Of
--- Comment #29 from iains at gcc dot gnu dot org 2010-08-27 17:38 ---
(In reply to comment #12)
> Subject: Re: m32 lto produces non-relocatable subtraction
> expression errors
>
> Hmm, actually the symbol is not changed, since it is externally visible
> symbol.
> I guess the
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-08-27 17:27 ---
Or in the cddce1 dump:
Analyzing # of iterations of loop 1
exit condition [p_4(D), + , 1](no_overflow) != 0B
bounds on difference of bases: -18446744073709551615 ... 0
result:
# of iterations -(long unsign
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-08-27 17:26 ---
You can see that analysis happening with the C testcase on unpatched trunk
when looking at the cunrolli dump at -O2 for example.
Analyzing # of iterations of loop 1
exit condition [p_4(D), + , 1](no_overflow) != 0
--- Comment #5 from rguenther at suse dot de 2010-08-27 17:23 ---
Subject: Re: Number of iteration analysis
bogus
On Fri, 27 Aug 2010, rakdver at kam dot mff dot cuni dot cz wrote:
> --- Comment #4 from rakdver at kam dot mff dot cuni dot cz 2010-08-27
> 16:33 ---
> Subject
--- Comment #9 from davidxl at gcc dot gnu dot org 2010-08-27 17:01 ---
Will take a look
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #6 from uros at gcc dot gnu dot org 2010-08-27 16:54 ---
Subject: Bug 41484
Author: uros
Date: Fri Aug 27 16:53:51 2010
New Revision: 163591
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163591
Log:
PR target/41484
* config/i386/sse.md (sse4_1_extend
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-27 16:16 ---
(In reply to comment #4)
> Created an attachment (id=21576)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21576&action=view) [edit]
> Patch to remove special (vec_duplicate ...) insn RTXes
>
> This patch remov
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-27 16:12 ---
I think the bug is that we assume the exit is taken at some point, which is
not true if we assume the induction variable does not wrap (so we only can
assume one of both those assumptions at the same time).
--
h
On Linux/ia64, revision 163565 gave
FAIL: gcc.dg/vect/no-section-anchors-vect-64.c scan-tree-dump-times vect
"Alignment of access forced using peeling" 2
Revision 163561 is OK.
--
Summary: [4.6 Regression] gcc.dg/vect/no-section-anchors-vect-
64.c
Prod
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-08-27 16:01
---
Investigating on IA-64.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rakdver at kam dot mff dot cuni dot cz 2010-08-27
16:33 ---
Subject: Re: New: Number of iteration
analysis bogus
> when looking at the exit 6->7 number_of_iterations_ne is present with
> iv->base (cxb3014__test_block__char_pointers__element * {ref-all}) re
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
Version|4.5.3 |4.6.0
http://
--- Comment #8 from hjl dot tools at gmail dot com 2010-08-27 15:52 ---
It is caused by revision 162653:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg01007.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-08-27 16:31
---
Gerald, we have problems with the third-party libraries (GMP,MPFR,MPC) on the
SPARC, newer versions are miscompiled by earlier versions of GCC. So I'd
suggest to stick to the minimal versions listed in:
http://
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-08-27 16:00
---
I can confirm something similar (an unaligned access) on IA64/Linux:
(botca...@tinto) /nile.build/botcazou/gcc-head/ia64-unknown-linux-gnu $
gcc/gnat1 -quiet assert1.adb -I gcc/ada/rts
gnat1(32495): unaligned acc
--- Comment #3 from roger dot ferrer at bsc dot es 2010-08-27 15:46 ---
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > (void(*)(void)) my_fun<_T> // This is test.cpp:22
> >
> > Can I assume you meant to case to (void(*)(void*)) here?
Yes
--- Comment #2 from redi at gcc dot gnu dot org 2010-08-27 15:21 ---
(In reply to comment #1)
> (In reply to comment #0)
> > (void(*)(void)) my_fun<_T> // This is test.cpp:22
>
> Can I assume you meant to case to (void(*)(void*)) here?
With that change 4.5 and 4.6 compile the c
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-27 15:15 ---
(In reply to comment #0)
> (void(*)(void)) my_fun<_T> // This is test.cpp:22
Can I assume you meant to case to (void(*)(void*)) here?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45428
I do not know if this is a duplicate report as there are other similar tickets
about problems with addresses of overloads, but as far as I've seen none seems
to be reported against template-ids.
Consider this snippet.
---
struct function
{
void (*outline)(void *);
};
template
struct info
{
--- Comment #10 from bbiswas at email dot unc dot edu 2010-08-27 15:05
---
Subject: Re: internal compiler error gcc 4.5.1
Yes. mpc 0.8.2 includes symbols found in gmp 3.0.0. But you can't use
gmp 3.0.0
because then gcc fails to build ("internal compiler error"). mpc 0.8.1
doesn't
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2010-08-27 15:01
---
Dominique, thanks for testing that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43217
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2010-08-27 15:00
---
Subject: Bug 43217
Author: jvdelisle
Date: Fri Aug 27 15:00:11 2010
New Revision: 163588
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163588
Log:
2010-08-27 Jerry DeLisle
PR libfortran/4321
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-27 14:59 ---
And here's the patch I'm talking about:
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01981.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-27 14:50 ---
C testcase:
extern void abort (void);
int __attribute__((noinline,noclone))
foo (char *p)
{
int h = 0;
do
{
if (*p == '\0')
break;
++h;
if (p == 0)
abort ();
++p;
--- Comment #13 from dominiq at lps dot ens dot fr 2010-08-27 14:48 ---
The following test
! { dg-do run )
program hello2
call wrtout (9hHELLO YOU, 9)
stop
end
subroutine wrtout (iarray, nchrs)
integer(1), parameter :: zero = 0
LOGICAL, PARAMETER :: bigend = IACHAR(TRANSFER(1,"
The analysis for nb_iterations_upper_bound is bogus when we derive bounds for
an exit check ptr == 0 (leading to an assert). The testcase looks like
(subroutine cxb3014__test_block__char_pointers__value from acats CXB3014):
:
# p_1 = PHI
# h_2 = PHI <0(3), h_10(8)>
D.3266_7 = *p_1;
if (D
--- Comment #6 from sfilippone at uniroma2 dot it 2010-08-27 14:40 ---
(In reply to comment #3)
end if
> class default
> call aa%mv_to_coo(actmp,info)
> if (info == psb_success_) then
> if (present(b)) then
> call psb_rwextd(nr,actmp,info,b%a,ro
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-08-27 14:36
---
> I successfully built gcc on Solaris 10
> using these versions of gmp/mpfr/mpc:
>
> gmp 4.3.2
> mpfr 2.4.2
> mpc 0.8.1
>
> The instructions on the prerequisites.html page you reference b
--- Comment #12 from dominiq at lps dot ens dot fr 2010-08-27 14:20 ---
On ppc, the original test gives before patch
48454C4C 4F20594F 5500
So it seems that the test is likely to fail on ppc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43217
--- Comment #8 from bbiswas at email dot unc dot edu 2010-08-27 14:19
---
Subject: Re: internal compiler error gcc 4.5.1
I successfully built gcc on Solaris 10
using these versions of gmp/mpfr/mpc:
gmp 4.3.2
mpfr 2.4.2
mpc 0.8.1
The instructions on the prereq
--- Comment #28 from howarth at nitro dot med dot uc dot edu 2010-08-27
14:15 ---
(In reply to comment #27)
> Created an attachment (id=21578)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21578&action=view) [edit]
> corrected m32 darwin lto fix using external
>
My mistake. The
--- Comment #27 from howarth at nitro dot med dot uc dot edu 2010-08-27
14:13 ---
Created an attachment (id=21578)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21578&action=view)
corrected m32 darwin lto fix using external
--
howarth at nitro dot med dot uc dot edu changed:
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-08-27 14:02
---
> make check: OK for GMP but fails for MPFR
>
> Solution: build GMP, MPFR and MPC separately and add --with-... to configure
> gcc.
> Note: GMP must be build for 32 bits, i.e. set env var ABI=32
Yes, or else con
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-08-27 14:02
---
Dominiq, can you test the output of the test case for me on PPC?
hollerith8.f90 in the gfortran post.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43217
--- Comment #26 from howarth at nitro dot med dot uc dot edu 2010-08-27
13:59 ---
(In reply to comment #25)
> Created an attachment (id=21577)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21577&action=view) [edit]
> m32 darwin lto fix using external
>
This version almost works.
--- Comment #25 from howarth at nitro dot med dot uc dot edu 2010-08-27
13:54 ---
Created an attachment (id=21577)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21577&action=view)
m32 darwin lto fix using external
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44812
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2010-08-27 13:25
---
Closing as fixed. Please reopen if the problem has not gone away.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-08-27 13:01 ---
The few remaining bound checks do not look simple to remove (if at all).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
--- Comment #3 from danglin at gcc dot gnu dot org 2010-08-27 12:50 ---
Introduced in revision 162337:
2010-07-20 Jakub Jelinek
* var-tracking.c (vt_expand_loc, vt_expand_loc_dummy): Bump maximum
depth to 8 from 5.
--
danglin at gcc dot gnu dot org changed:
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-08-27 12:16 ---
Without -fbounds-check we have around 650 million calls to
iv_ca_get_num_inv_exprs ... called from iv_ca_recount_cost. With
-fbounds-check
this balloons to nearly 5 billion calls to that function.
David - this soun
--- Comment #7 from ramana at gcc dot gnu dot org 2010-08-27 12:14 ---
can this be backported to the 4.5 branch please ?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from tkoenig at gcc dot gnu dot org 2010-08-27 12:12
---
Fixed on trunk.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2010-08-27
12:10 ---
Testsuite results for m32_to_fix2.diff at
http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg02690.html.
This approach completely fixes the darwin-specific lto failures on
x86_64-apple-darwin10.
--
http
--- Comment #20 from tkoenig at gcc dot gnu dot org 2010-08-27 12:09
---
Subject: Bug 45159
Author: tkoenig
Date: Fri Aug 27 12:08:47 2010
New Revision: 163584
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163584
Log:
2010-08-27 Thomas Koenig
PR fortran/45159
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-08-27 12:06 ---
MODULE hfx_contract_block
INTEGER, PARAMETER :: dp=KIND(0.0D0)
CONTAINS
SUBROUTINE
block_9_2(mc_max,md_max,kbd,kbc,kad,kac,pbd,pbc,pad,pac,prim,scale)
INTEGER :: mc_max, md_ma
--- Comment #1 from burnus at gcc dot gnu dot org 2010-08-27 11:58 ---
Confirm, the bounds checks are misplaces. Simplified test case:
implicit none
integer :: A(1), i,b(1)
logical :: mask(1)
mask = .false.
b = 5
do i = 2, 2
where (mask)
A = b(i)
end where
end do
end
If one
--- Comment #4 from jv244 at cam dot ac dot uk 2010-08-27 11:45 ---
(In reply to comment #3)
>
> this connection with bounds-checking makes it sound familiar.
>
I had a similar bug open (and fixed) as PR43627
with a comment from you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627#c11
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-27 11:41 ---
Reproducable with -O3 alone, -fbounds-check makes it more visible. With plain
-O3:
tree iv optimization : 22.64 (33%) usr 0.18 (11%) sys 22.97 (32%) wall
113858 kB (16%) ggc
and with added -fbounds-check:
--- Comment #5 from sfilippone at uniroma2 dot it 2010-08-27 11:38 ---
(In reply to comment #4)
> (In reply to comment #3)
> I tried to reproduce this by modifying your original test case, but did not
> succeed so far. Can you provide a standalone test case for this problem? My
> feeling
--- Comment #23 from dominiq at lps dot ens dot fr 2010-08-27 10:30 ---
With the patch in comment #21 I get for powerpc-apple-darwin9
Running target unix/-m32
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw/share/dejagnu/config/unix.exp as gen
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-27 10:23 ---
Can also be seen here:
http://gcc.opensuse.org/SPEC/CFP/sb-barbella.suse.de-head-64-2006/times.html
and here:
http://gcc.opensuse.org/c++bench-frescobaldi/polyhedron/polyhedron-summary.txt-1-0.html
I'm looking at
--- Comment #10 from dominiq at lps dot ens dot fr 2010-08-27 10:23 ---
I think the test case has not been committed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43217
--- Comment #1 from burnus at gcc dot gnu dot org 2010-08-27 10:11 ---
I learned about this restriction at
http://groups.google.com/group/comp.lang.fortran/msg/94c45e3d727f49fc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45426
Fortran 2008 (and earlier) have:
"3.3.3.5 Fixed form statements"
"The program unit END statement shall not be continued. A statement whose
initial line appears to be a program unit END statement shall not be
continued."
(That applies to all END: "A program unit is a main program, an
external subp
1 - 100 of 112 matches
Mail list logo
