--- Comment #1 from jiez at gcc dot gnu dot org 2010-03-29 03:39 ---
Created an attachment (id=20243)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20243&action=view)
The test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43562
GCC ICE on the attached test case.
$ ./cc1 /tmp/t.c
bak
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data>
Assembling functions:
bak
/tmp/t.c: In function bak:
/tmp/t.c:17:1: internal compiler error: Segmentation fault
Please submit a full bug report,
wit
--- Comment #1 from danglin at gcc dot gnu dot org 2010-03-29 02:52 ---
This is also now present on 4.4 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43441
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Known to fail||4.5.0
Known to work||4.4.3
--- Comment #26 from jvdelisle at gcc dot gnu dot org 2010-03-29 02:50
---
Reopening. I have one more regression here related to the patch sequence here.
It has to do with reading a file with no EOR marker at the end of a file.
program test
character (len=80) :: line
character (len
--- Comment #2 from hjl dot tools at gmail dot com 2010-03-29 02:49 ---
It is caused by revision 147083:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00057.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #7 from yao_yin at 163 dot com 2010-03-29 01:56 ---
Sorry, I gave a wrong example..
In fact, the code in PR 29131:
template
int t(T i)
{
return f (i); // OK, with g++ 4.4.3
}
int
f (int i)
{
return i;
}
int
main()
{
return t(1);
}
can be compiled with g++ 4.4.3
bu
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c |middle-end
h
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
CC|rus at google dot com |
AssignedTo|unassigned at gcc dot gnu |rus at google d
--- Comment #15 from wirawan0 at gmail dot com 2010-03-28 23:01 ---
Yes, just close it. I'm waiting the gentoo folks to find out which patch was
causing this error. It was so slow there...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43146
--- Comment #1 from rus at google dot com 2010-03-28 22:58 ---
Subject: Re: profile-mode version of forward_list
missing
On Sun, Mar 28, 2010 at 3:36 AM, paolo dot carlini at oracle dot com
wrote:
>
>
> --
>
> paolo dot carlini at oracle dot com changed:
>
> What
--- Comment #10 from hubicka at gcc dot gnu dot org 2010-03-28 21:47
---
Subject: Bug 43505
Author: hubicka
Date: Sun Mar 28 21:46:50 2010
New Revision: 157786
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157786
Log:
PR tree-optimization/43505
* cgraph.c (cgr
--- Comment #2 from burnus at gcc dot gnu dot org 2010-03-28 21:19 ---
Valgrind shows:
==4509== Conditional jump or move depends on uninitialised value(s)
==4509==at 0x4EB51A3: _gfortran_shape_4 (shape_i4.c:47)
==4509==by 0x40091E: myfunc.1553 (hjfdf.f90:19)
==4509==by 0x400
--- Comment #11 from eric dot cabret at gmail dot com 2010-03-28 21:01
---
Created an attachment (id=20242)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20242&action=view)
File obtained with command "strace -s 1024 ./a_nok_withdebug.out >
strace_s1024_a_nok.txt 2>&1" (executed on
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2010-03-28
20:59 ---
Confirmed with current gcc trunk on x86_64 Fedora 10 that the alternative patch
which uses GCC_CHECK_EMUTLS still leaves the build properly passing
-DHAVE_CC_TLS -DUSE_TLS for native TLS targets.
--
--- Comment #10 from eric dot cabret at gmail dot com 2010-03-28 20:52
---
Created an attachment (id=20241)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20241&action=view)
File obtained with command "strace -s 1024 ./a_nok_withdebug.out >
strace_s1024_a_nok.txt 2>&1"
--
http
--- Comment #9 from eric dot cabret at gmail dot com 2010-03-28 20:52
---
Created an attachment (id=20240)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20240&action=view)
File obtained with command "strace -s 1024 ./a_ok_withdebug.out >
strace_s1024_a_ok.txt 2>&1"
--
http://
--- Comment #1 from pault at gcc dot gnu dot org 2010-03-28 20:50 ---
Dear Dominiq,
Unfortunately, what you report here is a consequence of the way in which
-fwhole-file has to be implemented. The order changes because of the need to
resolve called procedures and I can well believe tha
--- Comment #8 from eric dot cabret at gmail dot com 2010-03-28 20:45
---
Created an attachment (id=20239)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20239&action=view)
a.out not OK obtained by command "gcc -g main.c" (with debug infos on 64bit
ubuntu)
--
http://gcc.gnu.or
--- Comment #7 from eric dot cabret at gmail dot com 2010-03-28 20:45
---
Created an attachment (id=20238)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20238&action=view)
a.out OK obtained by command "gcc -g main.c" (with debug infos on 64bit ubuntu)
--
http://gcc.gnu.org/bu
--- Comment #1 from pault at gcc dot gnu dot org 2010-03-28 20:39 ---
(In reply to comment #0)
> My understanding is that thus the following program is invalid:
>
> pure subroutine foo(a, c, d)
> integer, volatile, intent(inout) :: a, c ! OK
> integer, volatile :: b ! OK
> intege
--- Comment #6 from eric dot cabret at gmail dot com 2010-03-28 20:37
---
Here are new files (preprocessed sources OK and not OK) and binaries obtained
only with command "gcc main.c"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43556
--- Comment #5 from eric dot cabret at gmail dot com 2010-03-28 20:36
---
Created an attachment (id=20237)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20237&action=view)
a.out not OK obtained by command "gcc main.c"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43556
--- Comment #2 from ubizjak at gmail dot com 2010-03-28 20:35 ---
simplify_gen_subreg is called with VOIDmode outermode.
(gdb) f 3
#3 0x0055ca74 in expand_debug_expr (exp=0x71f1)
at ../../gcc-svn/trunk/gcc/cfgexpand.c:2416
2416 op0 = simplify_gen_subreg
--- Comment #4 from eric dot cabret at gmail dot com 2010-03-28 20:35
---
Created an attachment (id=20236)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20236&action=view)
a.out OK obtained by command "gcc main.c"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43556
--- Comment #3 from eric dot cabret at gmail dot com 2010-03-28 20:34
---
Created an attachment (id=20235)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20235&action=view)
Preprocessed source OK with "gcc -E main.c"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43556
--- Comment #2 from eric dot cabret at gmail dot com 2010-03-28 20:34
---
Created an attachment (id=20234)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20234&action=view)
Preprocessed source not OK with "gcc -E main.c"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43556
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2010-03-28
20:31 ---
Created an attachment (id=20233)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20233&action=view)
alternative patch that uses GCC_CHECK_EMUTLS and set_use_emutls
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #1 from ubizjak at gmail dot com 2010-03-28 20:22 ---
Confirmed with "cc1 -O -g -fwhole-program file1.c file2.c"
#0 fancy_abort (file=0xd4a558 "../../gcc-svn/trunk/gcc/simplify-rtx.c",
line=5135, function=0xd4b590 "simplify_subreg")
at ../../gcc-svn/trunk/gcc/diagn
--- Comment #1 from sezeroz at gmail dot com 2010-03-28 20:12 ---
Happens on x86_64-pc-linux-gnu, too. Segfaults with gcc-4.3.0 and 4.3.2 (as
shipped by fedora), but runs fine with 3.3.6, 3.4.6 and my custom 4.4.4.
--
sezeroz at gmail dot com changed:
What|Removed
The code below fails to compile and giving the indicated error message.
Based on the C++ standard, is this a compiler bug or my code is invalid?
Is this related to C++ bug #21903?
$ gcc -v -save-temps -Wall -Werror test/noinherit/09.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured wit
--- Comment #2 from regehr at cs dot utah dot edu 2010-03-28 19:34 ---
I no longer see this behavior.
--
regehr at cs dot utah dot edu changed:
What|Removed |Added
--- Comment #2 from schaub-johannes at web dot de 2010-03-28 19:33 ---
I've done some analysis for this using the argument-deduction during partial
ordering rules as clarified by
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#214:
template
void f(U&) { } // #1
template
vo
--- Comment #1 from paolo dot carlini at oracle dot com 2010-03-28 19:27
---
Jason, what do you think?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2010-03-28
19:21 ---
Untested alternative approach to fix this...
Index: libgcc/Makefile.in
===
--- libgcc/Makefile.in (revision 157785)
+++ libgcc/Makefile.in
83- --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20100328 (experimental) (GCC)
--
Summary: possible wrong code bug
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
The following code used to work with gcc-4.4.3.
The Comeau online compiler also accepts it.
But with the gcc-4.5 trunk, it is rejected as ambiguous.
template void f(U&) { }
template void f(T const&) { }
int main()
{
int a;
f(a);
}
This is a reduced test case from boost.phoenix.
--- Comment #7 from irar at il dot ibm dot com 2010-03-28 18:22 ---
(In reply to comment #5)
> When defining the missing function like this:
>
> static inline int mid_pred(int a, int b, int c)
> {
> int t= (a-b)&((a-b)>>31);
> a-=t;
> b+=t;
> b-= (b-c)&((b-c)>>31);
>
--- Comment #6 from irar at il dot ibm dot com 2010-03-28 18:05 ---
(In reply to comment #4)
> What about fixing the diagnostic message like this:
>
It would be nice to do the same for SLP (compute_data_dependences_for_bb) for
completeness.
Thanks,
Ira
> diff --git a/gcc/tree-vect-da
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-28 17:46 ---
EDG accepts both.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Statu
Very recently we started to reject
class Compressible;
template class Engine;
template
class Engine
{
public:
typedef T Element_t;
Element_t read(int);
};
template
T Engine::read(int)
{
}
Engine x;
with
t2.ii:12:3: error: prototype for 'T Engine::read(int)' does
not match any in class '
--- Comment #21 from hubicka at ucw dot cz 2010-03-28 17:30 ---
Subject: Re: [4.5 regression] 0.5% code size
regression caused by r147852
> > I think I saw one but it was wrong. I would be interested to at least know
> > what this patch is about :)
>
> It's about not accounti
The following causes an ICE with latest gcc 4.5.0 (svn r157452):
cat > file1.c << EOF
struct s1_s {
int v;
};
struct s1_s g1;
void __attribute__((externally_visible)) func1() {
struct s1_s *l1 = &g1;
l1->v = 0;
}
EOF
cat > f
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-28 17:20 ---
Works for me (thus I suggest to file a bug with Ubuntu).
Which optimization options? Please attach preprocessed source.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from burnus at gcc dot gnu dot org 2010-03-28 17:12 ---
Mine. I have a patch: http://gcc.gnu.org/ml/fortran/2010-03/msg00190.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
My system is Ubuntu 64 bits Lucid Lynx.
with this following small program, I obtain a crazy segmentation fault in
strchr() with gcc4.4.3-4ubuntu5 AND NOT with gcc4.4.1-4ubuntu9 (with same glibc
in both case) :
// gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 -> execution gives a "segmentation fault"
// gcc (U
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-28 17:01 ---
(In reply to comment #3)
> What about fixing this bug with
>
> diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
> index afbd342..2601b58 100644
> --- a/gcc/tree-vect-loop.c
> +++ b/gcc/tree-vect-loop.c
> @@
--- Comment #20 from rguenther at suse dot de 2010-03-28 17:00 ---
Subject: Re: [4.5 regression] 0.5% code size
regression caused by r147852
On Sun, 28 Mar 2010, hubicka at ucw dot cz wrote:
> --- Comment #19 from hubicka at ucw dot cz 2010-03-28 16:56 ---
> Subject: Re: [4
--- Comment #3 from spop at gcc dot gnu dot org 2010-03-28 16:57 ---
What about fixing this bug with
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index afbd342..2601b58 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -2173,9 +2173,9 @@ vect_estimate_min_prof
--- Comment #19 from hubicka at ucw dot cz 2010-03-28 16:56 ---
Subject: Re: [4.5 regression] 0.5% code size
regression caused by r147852
> > > There is also some miscounting of overall unit size, Micha has a patch for
> > > that (but it completely chokes tramp3d results). The
--- Comment #18 from rguenther at suse dot de 2010-03-28 16:43 ---
Subject: Re: [4.5 regression] 0.5% code size
regression caused by r147852
On Sun, 28 Mar 2010, hubicka at ucw dot cz wrote:
> --- Comment #17 from hubicka at ucw dot cz 2010-03-28 16:33 ---
> Subject: Re: [4
--- Comment #14 from hjl at gcc dot gnu dot org 2010-03-28 16:41 ---
Subject: Bug 40722
Author: hjl
Date: Sun Mar 28 16:40:50 2010
New Revision: 157784
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157784
Log:
2010-03-28 H.J. Lu
PR target/40722
* mkfixinc.sh
--- Comment #5 from spop at gcc dot gnu dot org 2010-03-28 16:35 ---
When defining the missing function like this:
static inline int mid_pred(int a, int b, int c)
{
int t= (a-b)&((a-b)>>31);
a-=t;
b+=t;
b-= (b-c)&((b-c)>>31);
b+= (a-b)&((a-b)>>31);
return b;
}
--- Comment #17 from hubicka at ucw dot cz 2010-03-28 16:33 ---
Subject: Re: [4.5 regression] 0.5% code size
regression caused by r147852
> Indeed.
>
> There is also some miscounting of overall unit size, Micha has a patch for
> that (but it completely chokes tramp3d results).
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-28 16:33 ---
Confirmed. The problem seems to be gimplification of type sizes where
we end up putting the size calculation stmts into the conditional block,
a place not dominating the 2nd stmt where we re-use it:
x2d = (double
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-03-28
16:29 ---
Testsuite results for revised patch at
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg02449.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
--- Comment #4 from spop at gcc dot gnu dot org 2010-03-28 16:28 ---
What about fixing the diagnostic message like this:
diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index 37ae9b5..44248b3 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -1
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-03-28
16:11 ---
Created an attachment (id=20232)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20232&action=view)
proposed patch to pass -DUSE_EMUTLS via libgcc/config/t-emutls on darwin
Corrected ChangeLog and comm
--- Comment #26 from rguenth at gcc dot gnu dot org 2010-03-28 15:50
---
ppc folks, can you re-confirm this bug again? There have been some register
allocation changes meanwhile.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from spop at gcc dot gnu dot org 2010-03-28 15:56 ---
(In reply to comment #1)
> > What does this message mean?
> > "vector iteration cost = 2056 is divisible by scalar iteration cost = 4 by a
> > factor greater than or equal to the vectorization factor = 4 ."
> > Is the v
--- Comment #1 from sezeroz at gmail dot com 2010-03-28 15:49 ---
Happens with 4.3.0 and 4.4.4 on i686-pc-linux, too. Reproduced the problem with
g++ only at -O0. -O1 and higher output the wanted result.
--
sezeroz at gmail dot com changed:
What|Removed
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-03-28 15:46
---
(In reply to comment #15)
> I've been discussing this on IRC a while ago with Richard Guenther, but forgot
> to add a record.
>
> It seems that for 4.5, it is best to leave inlining heruistics as it is. THe
> cod
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-28 15:39 ---
How is this a regression anyway? __builtin_unreachable () is new with 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
In some cases addressing elements of multidimensioanl variable-length array
goes wrong. Consider the program:
#include
#include
int nx,ny;
void f(double *x1d,int choice)
{
double (*x2d)[nx][ny]=(double(*)[nx][ny])x1d;
unsigned long delta;
// (*x2d)[0][0]=123; // <-
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-03-28 15:34
---
(In reply to comment #12)
> (In reply to comment #10)
> > Created an attachment (id=20228)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20228&action=view) [edit]
> > Broken stdlib.h
> >
> > Hi,
> >
> > Thi
--- Comment #4 from burnus at gcc dot gnu dot org 2010-03-28 15:11 ---
For completeness: The test case was based on a post at
http://groups.google.ca/group/comp.lang.fortran/browse_thread/thread/f5ec99089ea72b79
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43266
--- Comment #3 from pault at gcc dot gnu dot org 2010-03-28 15:05 ---
Created an attachment (id=20231)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20231&action=view)
Fix for the PR
Bootstraps and regtests on FC9/x86_64
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
--- Comment #16 from rguenther at suse dot de 2010-03-28 14:45 ---
Subject: Re: Weird temporary array allocation
On Sun, 28 Mar 2010, burnus at gcc dot gnu dot org wrote:
> --- Comment #15 from burnus at gcc dot gnu dot org 2010-03-28 14:10
> ---
> Actually, I am wondering w
--- Comment #12 from hjl dot tools at gmail dot com 2010-03-28 14:44
---
(In reply to comment #10)
> Created an attachment (id=20228)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20228&action=view) [edit]
> Broken stdlib.h
>
> Hi,
>
> This patched caused problems for mingw-w64
--- Comment #4 from kevin at koconnor dot net 2010-03-28 14:43 ---
This problem has returned. The test case above no longer causes the problem -
but simply changing the test case to also assign a value to the variable shows
the problem. This is with gcc from svn (r157452).
New test ca
--- Comment #15 from burnus at gcc dot gnu dot org 2010-03-28 14:10 ---
Actually, I am wondering whether one needs to do
D.1620_135 = __builtin_malloc (1);
for temporary arrays. For user-accessible ALLOCATABLE arrays one does - because
ALLOCATED(array) needs also to be .TRUE. for zero-
--- Comment #14 from burnus at gcc dot gnu dot org 2010-03-28 13:56 ---
Created an attachment (id=20230)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20230&action=view)
Draft patch for NULL check for deallocation
Draft patch for removing the NULL check before __builtin_free. Acco
--- Comment #13 from burnus at gcc dot gnu dot org 2010-03-28 13:05 ---
(In reply to comment #12)
> (I am thinking of
>call f(array(...))
> where one knows that "f" does not allow for a zero-sized array argument.
s/where/if/ - in the general case one does not know. Especially for
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-28 12:58 ---
The return statement does not have line information, even without LTO:
f2 (int i, int j)
{
:
[/home/richard/src/trunk/gcc/testsuite/gcc.dg/guality/pr41353-1.c : 23:5] j_3
= j_1(D) + i_2(D);
[/home/richard/src/tr
--- Comment #12 from burnus at gcc dot gnu dot org 2010-03-28 12:57 ---
(In reply to comment #8)
> atmp.5.dim[0].lbound = 0;
> atmp.5.dim[0].ubound = D.1612;
> D.1616 = D.1612 < 0;
>
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-28 12:41 ---
There is no line 28 to break on, instead it breaks at f3().
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from burnus at gcc dot gnu dot org 2010-03-28 11:56 ---
And the culprit is unit 30 ("$HOME/tmp/_phsi.ebar" alias unit=iuebar), which is
a binary file (672000 bytes), which is automatically deleted
(PH/close_phq.f90).
The file is opened with: form='unformatted', access='d
--- Comment #1 from irar at il dot ibm dot com 2010-03-28 11:16 ---
Looks similar to PR 32806.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43543
--- Comment #3 from irar at il dot ibm dot com 2010-03-28 11:07 ---
(In reply to comment #1)
> hadamard8_diff.c:44: note: not vectorized: unhandled data-ref
There is a function call in this loop as well.
> hadamard8_diff.c:26: note: not vectorized: data ref analysis failed D.2771_12
--- Comment #2 from irar at il dot ibm dot com 2010-03-28 10:58 ---
(In reply to comment #0)
> sub_hfyu_median_prediction.c:18: note: not vectorized: unhandled data-ref
>
> Looking with GDB at it, I get:
> (gdb) p debug_data_references (datarefs)
> (Data Ref:
> stmt: D.2736_16 = *D
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last re
I'm looking for help for the profile-mode version (I'm going to take care of
the debug-mode one)
--
Summary: profile-mode version of forward_list missing
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priorit
--- Comment #11 from jon_y at users dot sourceforge dot net 2010-03-28
10:17 ---
Created an attachment (id=20229)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20229&action=view)
log from buildbot
Here is the error output from one of the buildbot slaves.
--
http://gcc.gnu.or
--- Comment #10 from jon_y at users dot sourceforge dot net 2010-03-28
10:14 ---
Created an attachment (id=20228)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20228&action=view)
Broken stdlib.h
Hi,
This patched caused problems for mingw-w64 stdlib.h, see attachment.
--
htt
--- Comment #1 from irar at il dot ibm dot com 2010-03-28 09:41 ---
(In reply to comment #0)
> What does this message mean?
> "vector iteration cost = 2056 is divisible by scalar iteration cost = 4 by a
> factor greater than or equal to the vectorization factor = 4 ."
> Is the vectoriza
--- Comment #2 from irar at il dot ibm dot com 2010-03-28 08:59 ---
I think PR 35229 covers this issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43425
--- Comment #9 from burnus at gcc dot gnu dot org 2010-03-28 08:52 ---
The issue seems to be the buffering. If one uses GFORTRAN_UNBUFFERED_ALL=1 the
result is correct, without it is not.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #8 from burnus at gcc dot gnu dot org 2010-03-28 08:19 ---
(In reply to comment #7)
> Turning off format caching is very easy for debugging purposes.
I tried this (see comment 4), but it did not seem to help.
I now added a printf for "*(GFC_REAL_8 *)dest, buffer" in read_f,
88 matches
Mail list logo
