--- Comment #3 from rsandifo at gcc dot gnu dot org 2010-06-05 07:27
---
Kenny, I too don't like target_reinit, and FWIW
I fought the same battle before the patch was submitted.
The argument then, and I suspect the argument now,
is that although the function is horribly inefficient,
it
--- Comment #11 from tkoenig at gcc dot gnu dot org 2010-06-05 08:49
---
Dear Paul,
thanks a lot for your helpful comments.
Just one thing: I currently don't see how to refer to multiple
indices for an array element.
In the code you pointed out, this is done with a single variable,
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-05 08:49 ---
Shifts with shift count equal or greater than bitsize of the lhs type are
undefined in both C and C++ standards.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from mikael at gcc dot gnu dot org 2010-06-05 09:31 ---
(In reply to comment #9)
> I have thought a little bit about this, and the problem is
> a bit daunting ;-) Of course, this is at least partly because
> my experience with the scalarizer is close to non-existant, but
--- Comment #8 from dominiq at lps dot ens dot fr 2010-06-05 09:52 ---
At revision 160309, I get
[macbook] lin/test% gfc -O3 -ffast-math -funroll-loops -fomit-frame-pointer
-fwhole-program -flto rnflow.f90 --param hot-bb-frequency-fraction=1000
[macbook] lin/test% time a.out > /dev/null
--- Comment #28 from dominiq at lps dot ens dot fr 2010-06-05 09:54 ---
Is there any interest to understand what broke the test and what fixed it? If
not, I'll close this pr as fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #1 from jsm28 at gcc dot gnu dot org 2010-06-05 10:10 ---
Confirmed. Testing a patch.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDe
If the attached test case is compiled with current trunk, it runs almost 4
times more slowly than the same code compiled with gcc 4.4 and identical
options:
~/ujedi/splotchnew>gcc -O2 -v bugrep.c -W -Wall
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /tmp/S/gcc-4.4.2/conf
--- Comment #1 from martin at mpa-garching dot mpg dot de 2010-06-05 10:18
---
Created an attachment (id=20849)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20849&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44423
--- Comment #29 from rguenth at gcc dot gnu dot org 2010-06-05 10:36
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-05 10:38 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-06-05 10:40 ---
(In reply to comment #4)
> >Interesting! What's the difference between 17 and 18?
>
> Exact representation.
Complete unrolling.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43529
--- Comment #12 from pault at gcc dot gnu dot org 2010-06-05 10:40 ---
(In reply to comment #11)
OK, all this has a simple explanation. A revamped version of the original
testcase segfaults in runtime, at -O0.
! { dg-do compile }
! Test the fix for PR43895, in which the dummy 'a' was n
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-05 10:47 ---
We have (4.4):
:
va.f[0] = a->r;
va.f[1] = a->g;
va.f[2] = a->b;
va.f[3] = 0.0;
pretmp.40 = va.v;
ivtmp.61 = 0;
:
att.12 = MEM[base: pre1, index: ivtmp.61] * pre2;
tmpatt = {att.12, att.12, att.12,
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-05 10:56 ---
Ok. Fact is that no pass can move invariant store/load pairs. But that's
pre-existing - the main issue is that the new SRA implementation ends up
rematerializing the stores inside the loop!
Diff of pre-esra vs. es
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-05 11:42 ---
(In reply to comment #1)
> Shifts with shift count equal or greater than bitsize of the lhs type are
> undefined in both C and C++ standards.
... and we should warn in trivial cases like this.
--
manu at gcc dot g
--- Comment #4 from zadeck at naturalbridge dot com 2010-06-05 11:44
---
richard,
the reason that i went into such details about my port in (2) was to get the
reinit_regs issue out in a place so that if someone decided to take on this
beast, they had all of the issues in front of them
--- Comment #10 from joseph at codesourcery dot com 2010-06-05 11:57
---
Subject: Re: real.c rounding not perfect
On Fri, 4 Jun 2010, exploringbinary at gmail dot com wrote:
> BTW, why doesn't gcc use David Gay's dtoa.c (http://www.netlib.org/fp/dtoa.c)
> for correct rounding?
Anyth
--- Comment #2 from jsm28 at gcc dot gnu dot org 2010-06-05 12:54 ---
Subject: Bug 44322
Author: jsm28
Date: Sat Jun 5 12:54:41 2010
New Revision: 160312
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160312
Log:
PR c/44322
* c-typeck.c (build_unary_op): Merge q
--- Comment #3 from jsm28 at gcc dot gnu dot org 2010-06-05 12:57 ---
Fixed for 4.6.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #2 from jason at gcc dot gnu dot org 2010-06-05 13:14 ---
Subject: Bug 9694
Author: jason
Date: Sat Jun 5 13:13:46 2010
New Revision: 160313
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160313
Log:
* testsuite/util/testsuite_abi.h: Work around glibc BZ 969
alphaev67-dec-osf5.1
echo timestamp > s-options
nawk -f /home/jayk/src/gcc-4.5.0/gcc/opt-functions.awk -f
/home/jayk/src/gcc-4.5.0/gcc/opth-gen.awk \
< optionlist > tmp-options.h
awk: There is a regular expression error.
*?+ not preceded by valid expression
The source line
--- Comment #13 from pault at gcc dot gnu dot org 2010-06-05 14:08 ---
(In reply to comment #12)
This is tiresome - it regtested fine, I update the tree and now I get failures
on:
alloc_comp_result_1.f90
alloc_comp_scalar_1.f90
alloc_comp_transformational_1.f90
All three segfault at ru
If I say /src/gcc/configure -prefix=$HOME, and it can't find /usr/lib/libgmp.a,
etc., perhaps it should probe as if I said -with-gmp=$HOME?
Similarly, if it doesn't already, it should probe /usr/local, well, er, if I
omit -prefix -- so equivalent to the first suggestion.
--
Summary: s
Surprising. I'll try 4.4.
cc -c -g -DIN_GCC-DHAVE_CONFIG_H -I. -I. -I/home/jayk/src/gcc-4.5.0/gcc
-I/home/jayk/src/gcc-4.5.0/gcc/. -I/home/jayk/src/gcc-4.5.0/gcc/../include
-I/home/jayk/src/gcc-4.5.0/gcc/../libcpp/include -I/home/jayk/include
-I/home/jayk/src/gcc-4.5.0/gcc/../libdecnumber
-I
--- Comment #5 from jakub at gcc dot gnu dot org 2010-06-05 14:49 ---
Subject: Bug 44361
Author: jakub
Date: Sat Jun 5 14:49:16 2010
New Revision: 160317
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160317
Log:
PR c++/44361
* c-typeck.c (mark_exp_read): Handle
--- Comment #1 from jsm28 at gcc dot gnu dot org 2010-06-05 14:54 ---
Appears to have been introduced by r149722.
r149722 | manu | 2009-07-16 22:29:52 + (Thu, 16 Jul 2009) | 60 lines
2009-07-17 Aldy Hernandez
Manuel López-Ibáñez
PR 40435
* tree-co
--- Comment #6 from jakub at gcc dot gnu dot org 2010-06-05 15:02 ---
Subject: Bug 44361
Author: jakub
Date: Sat Jun 5 15:02:32 2010
New Revision: 160318
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160318
Log:
PR c++/44361
* c-typeck.c (mark_exp_read): Handle
--- Comment #2 from jay dot krell at cornell dot edu 2010-06-05 15:13
---
similar with 4.4.4. I'll try 4.3. Eventually I might build but I never know the
minimal set of files to get for sysroot.. :(
^
cc: Error: /home/jayk/src/gcc-4.4.4/gcc/sel-sched-dump.c, line 258: In the
in
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-06-05 15:34
---
The testcase doesn't pass on 4.5 branch with RTL checking:
/home/eric/gnat/gnat6_45/src/gcc/testsuite/g++.dg/debug/pr44178.C:39:1:
internal compiler error: RTL check: expected elt 3 type 'B', have '0' (rtx
barrie
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-05 15:50 ---
Do you mean we should not use VA_ARGS in GCC? Then, what? static inline? Is
this warned by -pedantic? Shouldn't it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44426
--- Comment #1 from jay dot krell at cornell dot edu 2010-06-05 15:52
---
fixed title, proceeding wih gawk and gcc 4.3
--
jay dot krell at cornell dot edu changed:
What|Removed |Added
---
--- Comment #4 from joseph at codesourcery dot com 2010-06-05 17:36 ---
Subject: Re: [4.5/4.6 Regression] gcc 4.5.0 requires
c9x compiler to build
On Sat, 5 Jun 2010, manu at gcc dot gnu dot org wrote:
> Do you mean we should not use VA_ARGS in GCC? Then, what? static inline? Is
> th
--- Comment #5 from jsm28 at gcc dot gnu dot org 2010-06-05 17:40 ---
build_call_nofold in builtins.c introduced by:
r152236 | matz | 2009-09-28 12:54:23 + (Mon, 28 Sep 2009) | 54 lines
* builtins.c (interclass_mathfn_icode): New helper.
[...]
Variadic macros in sel-sched-
--- Comment #14 from pault at gcc dot gnu dot org 2010-06-05 17:51 ---
Subject: Bug 43895
Author: pault
Date: Sat Jun 5 17:51:39 2010
New Revision: 160326
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160326
Log:
2010-06-05 Paul Thomas
PR fortran/43895
* tr
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44426
On GCC farm gcc40, system compiler is GCC 4.1, bootstrap with CC="gcc -m64"
build/genautomata ../../trunk/gcc/config/rs6000/rs6000.md \
insn-conditions.md > tmp-automata.c
out of memory allocating 4072 bytes after a total of 18446739677587395048 bytes
make[3]: *** [s-automata] Error 1
fail at
Bootstrapping revision 160319 on powerpc-apple-darwin9 failed at stage 1 with:
...
gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-Wold-style-definition -fno-common -DHAVE_CONFIG_H -DGENERATOR_FI
--- Comment #13 from tkoenig at netcologne dot de 2010-06-05 18:27 ---
Subject: Re: inline matmul for small matrix sizes
mikael at gcc dot gnu dot org wrote:
> I'm working on nested scalarization loops for the sum intrinsic
> (pr43829) ;
> inlining matmul should be straightforward aft
--- Comment #7 from jakub at gcc dot gnu dot org 2010-06-05 18:32 ---
That's because of PR43332, which has been fixed just on the trunk, not on 4.5
branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44178
--- Comment #7 from jakub at gcc dot gnu dot org 2010-06-05 19:00 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from manu at gcc dot gnu dot org 2010-06-05 19:04 ---
(In reply to comment #4)
> Subject: Re: [4.5/4.6 Regression] gcc 4.5.0 requires
> c9x compiler to build
>
> On Sat, 5 Jun 2010, manu at gcc dot gnu dot org wrote:
>
> > Do you mean we should not use VA_ARGS in GCC?
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-06-05 19:10 ---
(In reply to comment #6)
> (In reply to comment #4)
> > Subject: Re: [4.5/4.6 Regression] gcc 4.5.0 requires
> > c9x compiler to build
> >
> > On Sat, 5 Jun 2010, manu at gcc dot gnu dot org wrote:
> >
> > > Do y
--- Comment #8 from manu at gcc dot gnu dot org 2010-06-05 19:39 ---
(In reply to comment #7)
> >
> > > For the cases that are inserting UNKNOWN_LOCATION, I'd suggest just
> > > changing all the call sites of the macro to pass UNKNOWN_LOCATION
> > > explicitly, and removing the macro.
--- Comment #7 from dodji at gcc dot gnu dot org 2010-06-05 20:03 ---
So I posted an updated patch for this to
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00437.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44188
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
Last reconfirmed|2010-05-18 21:50:32 |2010-06-05 20:
--- Comment #6 from gcc-bugzilla at contacts dot eelis dot net 2010-06-05
20:12 ---
Looks fixed in 4.4.1.
--
gcc-bugzilla at contacts dot eelis dot net changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-06-05 20:41 ---
We do warn:
t.c:6:6: warning: right shift count >= width of type [enabled by default]
t.c:8:6: warning: right shift count >= width of type [enabled by default]
--
pinskia at gcc dot gnu dot org changed:
--- Comment #7 from sandra at codesourcery dot com 2010-06-05 20:41 ---
OK, I'm testing a hack to rewrite_use_compare to make it know that it doesn't
have to introduce a temporary just to compare against constant zero. I'm also
doing a little tuning of the costs model for -Os, using CSi
--- Comment #9 from joseph at codesourcery dot com 2010-06-05 21:33 ---
Subject: Re: [4.4/4.5/4.6 Regression] gcc 4.5.0 requires
c9x compiler to build
On Sat, 5 Jun 2010, manu at gcc dot gnu dot org wrote:
>
>
> --- Comment #6 from manu at gcc dot gnu dot org 2010-06-05 19:04
--- Comment #1 from segher at gcc dot gnu dot org 2010-06-05 22:57 ---
Patch posted at http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00449.html
--
segher at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from segher at gcc dot gnu dot org 2010-06-05 22:57 ---
Patch posted at http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00449.html
--
segher at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #17 from manu at gcc dot gnu dot org 2010-06-05 23:38 ---
Reconfirmed with revision 159764.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from redi at gcc dot gnu dot org 2010-06-05 23:39 ---
Indeed, so I'll close this.
4.4 gives
const char* D::foo(typename B::X) [with U = int]
and 4.6 gives
const char* D::foo(typename B::X) [with U = int, typename B::X = int]
--
redi at gcc dot gnu dot org changed:
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-05 23:45 ---
This is not a duplicate of PR 99 (it shows it but that is not what this PR is
about). This is about the excessive diagnostics. In revision 159764 we get:
/home/manuel/pr20906.C:3:34: error: variable or field pop decl
--- Comment #8 from manu at gcc dot gnu dot org 2010-06-05 23:48 ---
(In reply to comment #7)
> Indeed, so I'll close this.
> 4.4 gives
> const char* D::foo(typename B::X) [with U = int]
> and 4.6 gives
> const char* D::foo(typename B::X) [with U = int, typename B::X = int]
>
Could you
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-06 00:13 ---
This testcase does show PR99 but that is not what this PR is about. The
diagnostics of GCC would be clearer if it said:
/home/manuel/pr20313.C:10:30: error: invalid use of incomplete type struct
s<>
/home/manuel/pr20
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-06 00:14 ---
In GCC 4.6 the output is:
/home/manuel/pr20313.C:10:30: error: invalid use of incomplete type struct
s< >
/home/manuel/pr20313.C:5:22: error: declaration of struct s< >
--
manu at gcc dot gnu dot org changed:
--- Comment #4 from igodard at pacbell dot net 2010-06-06 00:50 ---
Wow - a blast from the past! FWIW, I still think that the "" is
confusing. That 4.6 drops one of the messages is an improvement though...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20313
--- Comment #8 from schaub-johannes at web dot de 2010-06-06 01:01 ---
(In reply to comment #6)
> Dup of bug 15272.
>
I don't know about the internals of GCC, but from a Standard point of view, the
code in that bug shows a different problem than the code in my bug report.
In my bug r
Source:
static const int __attribute__((used)) i = 1;
int main(void)
{
int r;
__asm__ ("movl _i(%%rip), %0" : "=r"(r));
return r;
}
> /usr/local/gcc46/bin/gcc -O3 -o attrused attrused.c
> /usr/local/gcc46/bin/gcc -O3 -o attrused attrused.c -flto
Undefined symbols:
"_i", referenced
--- Comment #9 from janus at gcc dot gnu dot org 2010-06-06 02:04 ---
Subject: Bug 43945
Author: janus
Date: Sun Jun 6 02:04:04 2010
New Revision: 160335
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160335
Log:
2010-06-05 Paul Thomas
Janus Weil
PR fo
--- Comment #10 from janus at gcc dot gnu dot org 2010-06-06 02:28 ---
Comment #0 is fixed by r160335, but the ICE in comment #4 is still there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
--- Comment #11 from janus at gcc dot gnu dot org 2010-06-06 02:49 ---
Reduced test case for comment #4:
module foo_mod
type foo
contains
procedure, pass(a) :: doit
generic :: do => doit
end type
contains
subroutine doit(a)
class(foo) :: a
end subroutine
end mod
--- Comment #12 from janus at gcc dot gnu dot org 2010-06-06 03:02 ---
(In reply to comment #11)
> Reduced test case for comment #4:
Even further reduced:
module foo_mod
type foo
contains
procedure :: doit
generic :: do => doit
end type
contains
subroutine doit(a)
--- Comment #15 from janus at gcc dot gnu dot org 2010-06-06 03:17 ---
I guess we can close this, right?
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-06 03:26 ---
At r160335, I don't see the failure on x86_64-unknown-linux-gnu. Maybe it has
been fixed by some middle-end changes by now. Can anyone confirm that the error
is gone?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-06 03:37 ---
Here is a related test case (by Salvatore):
module s_mat_mod
implicit none
type :: s_sparse_mat
end type
contains
subroutine s_set_triangle(a)
class(s_sparse_mat), intent(inout) :: a
end subroutine
end
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-06-06 06:01
---
I have managed a patch that writes one very big record as in the test case. I
don't have sufficient memory to actually test a read.
It should be noted that the record length stored in gfc_unit which is created
a
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-06-06 06:10
---
There is one last improvement we can do here. Currently we are using
gfc_match_init_expr. This works fine, but the error messages are worded toward
initialization expressions and not stop codes. We could genera
70 matches
Mail list logo
