building the latest kernel(2.6.34-rc4-00082-g250541f)
I'm hitting this:
kernel/rtmutex.c: At top level:
kernel/rtmutex.c:1138:1: internal compiler error: in
cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1009
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #6 from irar at gcc dot gnu dot org 2010-04-19 06:18 ---
Subject: Bug 43771
Author: irar
Date: Mon Apr 19 06:17:56 2010
New Revision: 158504
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158504
Log:
PR tree-optimization/43771
* tree-vect-analyze.c (
--- Comment #5 from irar at gcc dot gnu dot org 2010-04-19 06:02 ---
Subject: Bug 43771
Author: irar
Date: Mon Apr 19 06:02:27 2010
New Revision: 158503
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158503
Log:
PR tree-optimization/43771
* tree-vect-slp.c (vect
/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --disable-multilib --enable-language=c,c++
--disable-nls
Thread model: posix
gcc version 4.6.0 20100418 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps'
--- Comment #3 from roman at binarylife dot net 2010-04-19 04:25 ---
Starting from r150519 gcc compiles its own internal libbid wrong.
With the previous revision of gcc, the output of the above test.c is correct:
$ gcc -O test.c && ./a.out
ab=1.23457e-158
xy=1.23457e-158
--
http:/
--- Comment #7 from bangerth at gmail dot com 2010-04-19 02:59 ---
I think the point Andrew wanted to make is that it's a regression
*from the user perspective*. I had a half dozen places in our code
that now no longer compile in c++0x mode. Apparently others do too.
If the standard is
Gcc already contains useful warnings for almost certainly incorrect code. I
propose adding a warning when pointer arithmetic is used inside sizeof, that
degrades an array to a pointer.
char a[]="blabla";
sizeof(a-1);
If the intention was _actually_ to get sizeof(char), it is a really awful way
t
--- Comment #7 from dirtysalt1987 at gmail dot com 2010-04-19 02:25 ---
(In reply to comment #6)
> Just a littke more: alignof (struct _x_t) is 4 therefor so is the alignof(_x_t
> ::data).
>
3ku very much,with your explanation I think I can understand it..3ku very much.
--
http://g
--- Comment #6 from paolo dot carlini at oracle dot com 2010-04-19 02:13
---
In any case, Andrew is right (if I understand correctly the gist of his
message), that a conforming implementation of the FCD can *only* fail to
compile the provided snippet *when* the types are explicitely pro
--- Comment #5 from paolo dot carlini at oracle dot com 2010-04-19 02:08
---
Of course by "standard" I meant the current working draft, the FCD. We are in
the realm of the still *highly* experimental C++0x mode.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
--- Comment #4 from paolo dot carlini at oracle dot com 2010-04-19 02:06
---
Andrew, the situation isn't *that* simple as you seem to believe, because
make_pair is *templatized*, thus in general it works perfectly well with
lvalues. For example, this works:
std::make_pair/**/(x, y);
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-04-19 01:08 ---
Just a littke more: alignof (struct _x_t) is 4 therefor so is the alignof(_x_t
::data).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43774
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-04-19 01:06 ---
With C++0x we have:
template
inline pair::__type,
typename __decay_and_strip<_T2>::__type>
make_pair(_T1&& __x, _T2&& __y)
Which is correct that lvalues cannot be bound to rvalue reference variables.
So
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-04-19 00:30 ---
Well at least change the summary to say what the issue is about. There is
always a copy constructor for classes including POD in C++.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from navin dot kumar at gmail dot com 2010-04-19 00:22
---
Andrew,
What about the performance bug?
empty_t x; // line1
empty_t y = x; // line2
Line2 should not result in copying memory for empty classes. And that was the
old behavior pre-4.5.0
--
navin dot kumar
--- Comment #5 from navin dot kumar at gmail dot com 2010-04-19 00:22
---
Andrew,
What about the performance bug?
empty_t x; // line1
empty_t y = x; // line2
Line2 should not result in copying memory for empty classes. And that was the
old behavior pre-4.5.0
--
http://gcc.gnu.
--- Comment #24 from jason at gcc dot gnu dot org 2010-04-18 22:35 ---
We didn't get the error cascade in 2.95; we did in 3.4. I don't have any
releases in between handy.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-04-18 22:29 ---
This is invalid because you access a null pointer
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from zsojka at seznam dot cz 2010-04-18 22:14 ---
-floop-block -fstrict-aliasing also makes
gfortran.fortran-torture/execute/forall_1.f90 to timeout at -O[123s]
--
zsojka at seznam dot cz changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-04-18 20:33
---
Oh, and does it fail with http://gcc.gnu.org/bugzilla/attachment.cgi?id=20394
applied?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39979
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-04-18 20:32 ---
(In reply to comment #8)
> debbuging 4.3 vs 4.5 start_thread() shows different results:
>
> 4.3:
>
> 182x void thread::start_thread()
> 183x {
> 184x thread_info->self=thread_info;
> 185t>in
Command line:
g++ -fwhopr -r -nostdlib -ftoplevel-reorder 20081204-1_1.C
--- 20081204-1_1.C ---
struct Foo { virtual ~Foo(); };
struct Bar:public Foo { Bar() { } };
void Func() { new Bar(); }
--
g++.dg/lto/20081204-1_1.C
Tested revisions:
r15848
--- Comment #8 from pluto at agmk dot net 2010-04-18 20:28 ---
debbuging 4.3 vs 4.5 start_thread() shows different results:
4.3:
182x void thread::start_thread()
183x {
184x thread_info->self=thread_info;
185t>int const res = pthread_create(&thread_info->thread_
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-18 20:14 ---
Loop invariant motion breaks this.
:
- g_313.0_6 = pretmp.4_9;
- *g_313.0_6 = 0B;
:
# m_21 = PHI <0(11), m_3(D)(2)>
+ g_313.8_12 = *g_313.0_6;
+ g_313.0_6 = pretmp.4_9;
goto ;
we insert stmts not prese
--- Comment #7 from pluto at agmk dot net 2010-04-18 19:04 ---
(In reply to comment #5)
> (In reply to comment #4)
> > during analysis the boost::thread::start_thread() function which causes
> > invalid writes detected by valgrind i've noticed that gcc-4.5 generates
> > bigger and more c
--- Comment #3 from iains at gcc dot gnu dot org 2010-04-18 19:03 ---
(In reply to comment #2)
> "warnings should be issued when a
> deprecated entity is used and not when that deprecation is declared."
>
> it is not "that" deprecation that is declared in your examples but "a"
> depreca
--- Comment #2 from bangerth at gmail dot com 2010-04-18 19:02 ---
Confirmed. Including doesn't help.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #6 from pluto at agmk dot net 2010-04-18 19:01 ---
Created an attachment (id=20413)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20413&action=view)
testcase.#0.
--
pluto at agmk dot net changed:
What|Removed |Added
--
--- Comment #2 from roman at binarylife dot net 2010-04-18 18:34 ---
(In reply to comment #1)
> This needs a testcase. The libdecnumber code is a mess (and I can't find
> an implementation for bid128_ext_fma()).
>
bid128_ext_fma() is in libgcc/config/libbid/bid128_fma.c
--
http:/
--- Comment #3 from navin dot kumar at gmail dot com 2010-04-18 18:33
---
At the very least, you'd agree that it's a performance bug to be copying bytes
from memory when the class is empty. At the severe use-case, it breaks
existing code.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-18 18:32 ---
"warnings should be issued when a
deprecated entity is used and not when that deprecation is declared."
it is not "that" deprecation that is declared in your examples but "a"
deprecation that is declared.
--
ht
--- Comment #2 from navin dot kumar at gmail dot com 2010-04-18 18:31
---
Only GCC4.5.0 is emitting a copy-constructor that copies 1 byte of data
(probably because sizeof(empty_t) == 1 according to the C++ ABI). The
copy-constructor *should* be a noop, and indeed GCC4.4.2 issues a noo
--- Comment #8 from pault at gcc dot gnu dot org 2010-04-18 18:30 ---
(In reply to comment #6)
> (In reply to comment #5)
> > What about pr42274? Is it a duplicate or not?
>
> I don't think so.
>
My patch fixes pr42274 comment #9 but not the main part of it. Janus is quite
right that
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-18 18:30 ---
(In reply to comment #4)
> during analysis the boost::thread::start_thread() function which causes
> invalid writes detected by valgrind i've noticed that gcc-4.5 generates
> bigger and more complex code of this func
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-18 18:24 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-18 18:22 ---
This needs a testcase. The libdecnumber code is a mess (and I can't find
an implementation for bid128_ext_fma()).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Adde
--
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=43784
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-18 18:13 ---
I'm not sure the testcase is valid. We copy a single byte at 0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from baronchaos at ymail dot com 2010-04-18 17:55 ---
Created an attachment (id=20412)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20412&action=view)
numeric.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43786
--- Comment #1 from baronchaos at ymail dot com 2010-04-18 17:54 ---
Created an attachment (id=20411)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20411&action=view)
my.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43786
The following code compiles & runs fine on GCC 4.4.2, it compiles & segfaults
on GCC 4.5.0, arguments: -std=c++0x -g -fno-inline
#include
#include
#include
class empty_t {};
static_assert(std::is_empty::value, "sanity check");
int main(int argc, char** argv)
{
empty_t* x = NULL;
empt
- was trying to compile bc on gentoo
- lto1 process didnt finish after over an hour
- i "cat" as many c-files as possible into my.c and used resulting my.i
- different flags result in different reaction.
a)
x86_64-pc-linux-gnu-gcc -c -o my.o my.i -flto
x86_64-pc-linux-gnu-gcc -c -o numeric.o nu
--- Comment #23 from manu at gcc dot gnu dot org 2010-04-18 17:40 ---
Oh, that is not very difficult to do. But notice that you will still get the
last line:
/home/manuel/src/pr9335.C:4:17: instantiated from here
so we go from 11 to 3 lines. I think that is ok.
So go ahead, commit y
--- Comment #7 from pault at gcc dot gnu dot org 2010-04-18 17:33 ---
Created an attachment (id=20410)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20410&action=view)
Fix for the problem
This needs to be regtested but I believe it to be bombproof.
However, I should attempt to fi
--- Comment #32 from pault at gcc dot gnu dot org 2010-04-18 17:29 ---
Hmmm better mark it as fixed
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #31 from pault at gcc dot gnu dot org 2010-04-18 17:29 ---
Fixed on fortran-dev.
Thanks for the report, Harald.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42353
--- Comment #30 from pault at gcc dot gnu dot org 2010-04-18 17:25 ---
Subject: Bug 42353
Author: pault
Date: Sun Apr 18 17:25:41 2010
New Revision: 158493
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158493
Log:
2010-04-18 Paul Thomas
PR fortran/42353
* re
--- Comment #29 from pault at gcc dot gnu dot org 2010-04-18 17:24 ---
Subject: Bug 42353
Author: pault
Date: Sun Apr 18 17:24:35 2010
New Revision: 158492
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158492
Log:
2010-04-18 Paul Thomas
PR fortran/42353
* re
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #22 from jason at gcc dot gnu dot org 2010-04-18 17:09 ---
(In reply to comment #21)
> Is that ok or you would prefer the following?
>
> /home/manuel/src/pr9335.C:2:36: error: template instantiation depth exceeds
> maximum of 1024 (use -ftemplate-depth= to increase the maxim
--- Comment #3 from dominiq at lps dot ens dot fr 2010-04-18 16:47 ---
> Currently, only the run-time version is implemented.
So could the pr marked as NEW?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41580
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-18 16:44 ---
Confirmed. Related to pr24978. Should probably be marked as blocking pr31392
and pr33056.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41922
--- Comment #1 from navin dot kumar at gmail dot com 2010-04-18 16:43
---
Arguments: g++ -Wall -std=c++0x
--
navin dot kumar at gmail dot com changed:
What|Removed |Added
--- Comment #6 from janus at gcc dot gnu dot org 2010-04-18 16:42 ---
(In reply to comment #5)
> What about pr42274? Is it a duplicate or not?
I don't think so.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
in GCC 4.4.2, the following compiles, but in GCC 4.5.0, it does not:
#include
#include
int main(int argc, char** argv)
{
uint32_t x = 1;
uint32_t y = 2;
std::make_pair(x, y);
return 0;
}
In GCC4.5.0 the error is:
test.cpp: In function int main(int, char**):
test.cpp:8:40: erro
--- Comment #1 from zsojka at seznam dot cz 2010-04-18 16:26 ---
Created an attachment (id=20409)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20409&action=view)
reduced testcase (from gcc.c-torture/execute/builtins/pr22237.c)
Command line:
gcc -Os -fkeep-inline-functions pr43784
Tested revisions:
r158486 - fail
r158225 - OK
4.5 r158131 - OK
4.4 r158133 - OK
Compiler output:
$ /mnt/svn/gcc-trunk/binary-158486-lto-fortran/bin/gcc -Os
-fkeep-inline-functions testcase.c && ./a.out
Aborted
--
Summary: [4.6 Regression] -Os -fkeep-inline-functions causes
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-18 16:24 ---
The tests in comments #0 and #1 give a "Segmentation fault" with trunk or
fortran-dev.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41600
--- Comment #2 from burnus at gcc dot gnu dot org 2010-04-18 16:21 ---
> Could this PR be more explicit about the problem?
No it cannot; as written: For SAME_TYPE_AS and EXTENDS_TYPE_OF one should add a
compile-time simplification to simplify.c.
Currently, only the run-time version is i
--- Comment #5 from dominiq at lps dot ens dot fr 2010-04-18 16:18 ---
What about pr42274? Is it a duplicate or not?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
--- Comment #21 from manu at gcc dot gnu dot org 2010-04-18 16:16 ---
(In reply to comment #20)
> (In reply to comment #19)
> > Well, the patch is mostly done, it reduces the output from 11 to 1 lines
> > and it
> > neatly points out where is the recursive instantiation. So I hope you m
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2010-04-18 16:00
---
On all branches.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2010-04-18 15:57
---
Subject: Bug 43769
Author: ebotcazou
Date: Sun Apr 18 15:56:56 2010
New Revision: 158491
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158491
Log:
PR tree-optimization/43769
* tree-sra.c
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-18 15:56 ---
I cannot reproduce the error at
http://gcc.gnu.org/ml/fortran/2009-09/msg00298.html neither with trunk nor with
fortran-dev. Could this PR be more explicit about the problem?
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2010-04-18 15:56
---
Subject: Bug 43769
Author: ebotcazou
Date: Sun Apr 18 15:56:32 2010
New Revision: 158490
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158490
Log:
PR tree-optimization/43769
* tree-sra.c
uot;xy=%g\n",xy);
}
$ gcc test.c && ./a.out
ab=9.64506e-159
xy=9.64506e-159
$ gcc -O test.c && ./a.out
ab=1.23457e-158
xy=9.64506e-159
$ gcc --version | head -1
gcc (GCC) 4.5.1 20100418 (prerelease)
The correct value is 1.23457e-158:
$ echo "1.
--- Comment #4 from dominiq at lps dot ens dot fr 2010-04-18 15:49 ---
Still there on trunk -> should be marked as NEW.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40994
--- Comment #5 from dominiq at lps dot ens dot fr 2010-04-18 15:42 ---
Confirmed with trunk, fixed with fortran-dev.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41829
--- Comment #3 from dominiq at lps dot ens dot fr 2010-04-18 15:37 ---
Confirmed. Note that between 4.4 and 4.5 the error from the second test of
comment #0 has changed from:
MODULE PROCEDURE myplus
1
Error: Intrinsic operator interface at (1) must be a FU
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-04-18 15:31
---
Re-confirmed.
We have no bounds checking code in fortran/io.c nor in the I/O library.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802
--- Comment #5 from dominiq at lps dot ens dot fr 2010-04-18 15:28 ---
Both the bogus error and the ICE (also with std=f95) are still there. The PR
should be marked NEW.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40728
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-18 15:20 ---
It is caused by revision 158380:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00486.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #3 from iains at gcc dot gnu dot org 2010-04-18 15:17 ---
see:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00585.html
and:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00131.html
--
iains at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #7 from jason at gcc dot gnu dot org 2010-04-18 15:08 ---
That is, the problem is that template_arity_impl calls
arity_helper(type_wrapper,...) in a way that uses arg-dependent lookup,
which means looking up arity_helper within F, which means instantiating F,
which in this ca
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-18 15:04 ---
Confirmed for gcc version 4.4.2, but this pr seems to be fixed for 4.5 (at
least since revision 154654) and trunk. Unless someone is able to point when it
has been fixed and want to backport the fix to 4.4, this pr co
--- Comment #6 from jason at gcc dot gnu dot org 2010-04-18 15:04 ---
Dup of 43608.
*** This bug has been marked as a duplicate of 43608 ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from jason at gcc dot gnu dot org 2010-04-18 15:04 ---
*** Bug 43775 has been marked as a duplicate of this bug. ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #20 from jason at gcc dot gnu dot org 2010-04-18 14:42 ---
(In reply to comment #19)
> Well, the patch is mostly done, it reduces the output from 11 to 1 lines and
> it
> neatly points out where is the recursive instantiation. So I hope you may
> reconsider, unless you think
--- Comment #28 from dominiq at lps dot ens dot fr 2010-04-18 13:55 ---
> I am still getting the message:
Me too with a clean fortran-dev r158481.
Note that the patch in comment #25 fixes it without regression for the test
suite and my own tests.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #27 from pault at gcc dot gnu dot org 2010-04-18 13:50 ---
(In reply to comment #26)
> (In reply to comment #25)
> > A provisional fix for this PR
>
> Actually, what's the issue here? At rev. 158483 the fortran-dev testsuite runs
> cleanly on x86_64-unknown-linux-gnu, and th
--- Comment #4 from pluto at agmk dot net 2010-04-18 13:44 ---
during analysis the boost::thread::start_thread() function which causes
invalid writes detected by valgrind i've noticed that gcc-4.5 generates
bigger and more complex code of this function with few more lock'ed opcodes.
afai
--- Comment #3 from pluto at agmk dot net 2010-04-18 13:34 ---
Created an attachment (id=20408)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20408&action=view)
some tree dumps from 4.3/4.5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39979
--- Comment #26 from janus at gcc dot gnu dot org 2010-04-18 13:13 ---
(In reply to comment #25)
> A provisional fix for this PR
Actually, what's the issue here? At rev. 158483 the fortran-dev testsuite runs
cleanly on x86_64-unknown-linux-gnu, and the test cases in this PR
(gfcbug96.f9
--- Comment #15 from faisalv at yahoo dot com 2010-04-18 12:56 ---
I had (In reply to comment #14)
> *** Bug 43780 has been marked as a duplicate of this bug. ***
>
The DR 743 has been voted into FCD (CD2) - shouldn't this be unsuspended?
thanks!
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #4 from irar at gcc dot gnu dot org 2010-04-18 12:20 ---
Subject: Bug 43771
Author: irar
Date: Sun Apr 18 12:20:34 2010
New Revision: 158484
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158484
Log:
PR tree-optimization/43771
* tree-vect-slp.c (vect
--- Comment #4 from dominiq at lps dot ens dot fr 2010-04-18 11:48 ---
Marked as a 4.5/4.6 regression.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #3 from janus at gcc dot gnu dot org 2010-04-18 11:09 ---
It turns out this problem is not specific to the OOP stuff on fortran-dev, but
instead is due to an underlying problem with PROCEDURE statements (which
affects procedure pointers as well as PPCs), demonstrated by this
--- Comment #5 from pluto at agmk dot net 2010-04-18 08:35 ---
(In reply to comment #4)
> How do we know if this is valid code or not?
>
comeau online testdriver accept this code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43775
--
irar at il dot ibm dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com
|dot org
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-04-18 07:15
---
Present on x86 and x86-64/Linux, as well as on the 4.4 branch.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
91 matches
Mail list logo
