--- Comment #4 from jakub at gcc dot gnu dot org 2010-09-09 06:51 ---
Subject: Bug 45588
Author: jakub
Date: Thu Sep 9 06:50:56 2010
New Revision: 164051
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164051
Log:
PR c++/45588
* pt.c (tsubst) : Call mark_rvalue_u
--- Comment #1 from gcc at abeckmann dot de 2010-09-09 06:24 ---
Created an attachment (id=21746)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21746&action=view)
minimized testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45609
--- Comment #10 from mt at debian dot org 2010-09-09 06:23 ---
I have tried to reproduce the problem with g++ 4.5 and couldn't make it fail
anymore. The problem, however, is that I couldn't make it fail with g++ 4.4
either. Whatever the essential change might have been, the PPL instance
(I looked for duplicate -Wuninitialized bugs but didn't see anything similar)
In the attached minimized testcase I get a clear 'is used uninitialized'
warning downgraded to a 'may be used uninitialized' warning on unrelated code
changes.
The program compiles correctly with the following flags: -O
--- Comment #10 from christian dot eggers at kathrein dot de 2010-09-09
06:17 ---
(In reply to comment #9)
> I've submitted a patch solving PR40386. So now we can solve this problem by
> preventing slot sharing when setjmp is used.
>
> I'll send a patch soon.
Could you please send me
--- Comment #1 from burnus at gcc dot gnu dot org 2010-09-09 05:35 ---
I am not sure how to improve this (internally).
NAG also prints:
f95 hjf.f90
Error: hjf.f90, line 26: Inconsistent usage of CURVE
detected at )@%
Error: hjf.f90, line 26: Component of function reference
--- Comment #5 from t7 at gmail dot com 2010-09-09 04:55 ---
What is the status of this PR ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45230
This test case is invalid. It is rejected with an error message that is
nonsense in this context.
program test
implicit none
type line_struct
integer :: width = 10
end type
type symbol_struct
integer :: typee = 10
end type
type curve_struct
type (line_struct) line
type (symbol_struct)
--- Comment #3 from lacombar at gmail dot com 2010-09-09 04:34 ---
Some random config of the linux kernel, as of 2.6.36-rc3 results on the
following
stat.c: In function 'show_stat':
stat.c:123:1: error: unable to find a register to spill in class 'FP_REGS'
stat.c:123:1: error: this is t
--- Comment #8 from hp at gcc dot gnu dot org 2010-09-09 04:11 ---
(In reply to comment #7)
> And last but not
> least, decorate the new insn(s) with REG_INC notes as appropriate, as regmove
> (the next pass) seems to expect them: note that insn 1223 doesn't have one.
See-also PR11052,
--- Comment #7 from hp at gcc dot gnu dot org 2010-09-09 04:08 ---
Bother, I should have spotted the general area of this bug faster. It's a
matter of ifcvt.c calling
emit_insn_before_setloc (seq, if_info->jump,
INSN_LOCATOR (if_info->insn_a));
when
struct A{
enum A {yesterday, today, tomorrow};
};
int main(){}
The code above gives error
prog.cpp:2: error: class A has the same name as the class in which it is
declared
It is at the best confusing. The error message could probably be 'declaration
of a memeber of the same name as the cla
--- Comment #14 from tstarling at wikimedia dot org 2010-09-09 02:31
---
(In reply to comment #11)
> So? We are not changing glibc here. The C++ library does *not* use buffering
> in
> the synced mode, and it does otherwise, for fstreams in particular. Where do
> you think the performa
--- Comment #1 from hugo dot arregui at gmail dot com 2010-09-09 02:28
---
Created an attachment (id=21745)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21745&action=view)
ii file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45606
I cannot reproduce the error without std.
I wrote an small testcase, wich one I include to make clear the situation.
The code:
#include
template
class Test
{
protected:
typedef std::list ListAlias;
ListAlias list;
public:
typedef typename ListAlias::const_iterat
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-09 01:17 ---
I think this is the same issue as PR 19816.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
The following testcase taken from testsuite (and many others):
// PR 14535
// { dg-do run }
// { dg-options "-O -finline" }
//
// Original test case failure required that Raiser constructor be inlined.
extern "C" void abort();
bool destructor_called = false;
struct B {
virtual void Run(){}
On Linux/x86, revision 164033 gave
FAIL: g++.dg/opt/pr30965.C scan-tree-dump-times optimized "variable_..D. =
v_..D." 2
FAIL: g++.dg/tree-ssa/pointer-reference-alias.C scan-tree-dump-times optimized
"\*a" 1
FAIL: g++.dg/tree-ssa/pr27090.C scan-tree-dump optimized "f_..D.->x;"
Revision 164022 is O
--- Comment #4 from t7 at gmail dot com 2010-09-09 00:09 ---
Status?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45406
--- Comment #6 from manu at gcc dot gnu dot org 2010-09-08 23:33 ---
(In reply to comment #5)
> The changes done in pp_c_cv_qualifiers print "�__attribute__((const))�"
> or
> '"__attribute__((noreturn))"' for function pointer even if they are defined
> with 'const' or 'volatile' in
--- Comment #9 from danglin at gcc dot gnu dot org 2010-09-08 23:32 ---
Subject: Bug 45250
Author: danglin
Date: Wed Sep 8 23:32:06 2010
New Revision: 164036
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164036
Log:
PR target/45250
* config/pa/pa.md (nonlocal_g
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-08 23:31
---
Note, if you really need the name __cxa_guard_acquire to trigger the bug, which
is in the implementor "namespace", due to the double underscore in front, this
is a low priority ICE on *illegal*.
--
http://
--- Comment #5 from rmansfield at qnx dot com 2010-09-08 23:05 ---
The changes done in pp_c_cv_qualifiers print "__attribute__((const))" or
'"__attribute__((noreturn))"' for function pointer even if they are defined
with 'const' or 'volatile' in the users code and this may be confusin
--- Comment #4 from aoliva at gcc dot gnu dot org 2010-09-08 22:00 ---
Fixed
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #18 from aoliva at gcc dot gnu dot org 2010-09-08 21:56 ---
Fixed
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from aoliva at gcc dot gnu dot org 2010-09-08 21:54 ---
Subject: Bug 45531
Author: aoliva
Date: Wed Sep 8 21:54:02 2010
New Revision: 164032
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164032
Log:
PR debug/45531
* cfglayout.c (fixup_reorder_chain): Skip debug
--- Comment #17 from aoliva at gcc dot gnu dot org 2010-09-08 21:54 ---
Subject: Bug 45419
Author: aoliva
Date: Wed Sep 8 21:53:48 2010
New Revision: 164031
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164031
Log:
PR debug/45419
PR debug/45408
* tree-pretty-print.c (dump_gene
--- Comment #5 from aoliva at gcc dot gnu dot org 2010-09-08 21:54 ---
Subject: Bug 45408
Author: aoliva
Date: Wed Sep 8 21:53:48 2010
New Revision: 164031
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164031
Log:
PR debug/45419
PR debug/45408
* tree-pretty-print.c (dump_gener
--- Comment #11 from ramana at gcc dot gnu dot org 2010-09-08 21:36 ---
Subject: Bug 44392
Author: ramana
Date: Wed Sep 8 21:35:48 2010
New Revision: 164029
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164029
Log:
2010-09-08 Ramana Radhakrishnan
PR target/44392
--- Comment #39 from LpSolit at netscape dot net 2010-09-08 21:35 ---
I have done some progress. The DB has been successfully upgraded to 3.6.2
(locally, of course), and I have converted GCC hardcoded columns into custom
fields, i.e. using offically supported features in Bugzilla 3.x. So
--- Comment #15 from w6ws at earthlink dot net 2010-09-08 21:32 ---
Subject: Re: Bit intrinsics: ILEN and IBCHNG
FX wrote:
>--- Comment #14 from fxcoudert at gcc dot gnu dot org 2010-09-08 19:52
>---
>Possible remaining are only old extensions, not sure they're useful: ILEN a
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-09-08 21:13
---
Confirmed for SPARC/Solaris.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from hubicka at gcc dot gnu dot org 2010-09-08 21:04
---
So hot-bb-frequency-fraction solves the whole regression?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334
--- Comment #9 from burnus at gcc dot gnu dot org 2010-09-08 21:00 ---
For what it is worth, on AMD Athlon 64 X2 4800+ / x86-64-linux, I get for
gfortran -O3 -ffast-math -march=native -- and with with and without -flto:
0m45.132s -- (options as above)
0m52.731s -- additionally -fwhole-
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ./configure : (reconfigured) ./configure
--enable-languages=c,c++,fortran,java,objc --no-create --no-recursion
Thread model: posix
gcc version 4.6.0 20100908 (experimental) (GCC)
--- Comment #2 from dominiq at lps dot ens dot fr 2010-09-08 20:14 ---
This is due to revision 163598:
http://gcc.gnu.org/viewcvs?view=revision&sortby=date&revision=163598
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
-
For MOVE_ALLOC coarrays should not be allowed - maybe some other places should
be checked as well.
For MOVE_ALLOC, see interpretation request at
http://j3-fortran.org/doc/meeting/193/10-200.txt
Test program:
integer, allocatable :: a[:], b
call move_alloc (a, b)
end
--
Summary: Re
--- Comment #9 from vmakarov at redhat dot com 2010-09-08 20:06 ---
(In reply to comment #8)
> (In reply to comment #7)
> > Is this still a bug then? Should ira-share-spill-slots be automatically
> > disabled for the caller function when a callee function can return twice?
> >
> I've n
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2010-09-08 19:52
---
Possible remaining are only old extensions, not sure they're useful: ILEN and
IBCHNG.
Closing?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2010-09-08 19:42
---
Documentation fix committed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2010-09-08 19:39
---
Subject: Bug 18555
Author: fxcoudert
Date: Wed Sep 8 19:39:13 2010
New Revision: 164022
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164022
Log:
PR other/18555
* doc/cppopts.texi (-isys
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2010-09-08 19:35
---
Subject: Bug 38282
Author: fxcoudert
Date: Wed Sep 8 19:35:35 2010
New Revision: 164021
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164021
Log:
PR fortran/38282
* intrinsic.c (add_fu
--- Comment #4 from tkoenig at gcc dot gnu dot org 2010-09-08 19:30 ---
This makes a ton of sense to do.
We should also convert the frontend passes to a general expression
walker, as you indicated in one comment.
--
tkoenig at gcc dot gnu dot org changed:
What|Remove
--- Comment #11 from greened at obbligato dot org 2010-09-08 19:16 ---
(In reply to comment #9)
> >If it's an illegal program, gcc should at least emit a warning, if not an
> error.
>
>
> It is not an invalid program,
Yes, you are quite right. I will take this up with the LLVM folks.
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-09-08 19:03
---
This is very interesting (aka a real bugger):
Reversing the order of the declarations in
type curve_struct
type (line_struct) line
type (symbol_struct) symbol
end type
to
type curve_struct
type (symbol_
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-09-08 19:01
---
vector types are naturally aligned just like integer types. That is they are
aligned on their size.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45600
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-09-08 19:01 ---
>If it's an illegal program, gcc should at least emit a warning, if not an
error.
It is not an invalid program, it is just undefined at runtime. There was a
defect report against the C standard asking if a diagnos
--- Comment #8 from greened at obbligato dot org 2010-09-08 18:59 ---
(In reply to comment #6)
> The alignment of llvm_cbe__24__StackDv_P53 is only 64bits so you are casting
> to
> a greater aligned type and then dereferencing it.
I didn't know that typing something as a vector guarant
--- Comment #7 from greened at obbligato dot org 2010-09-08 18:58 ---
(In reply to comment #5)
> Why is the code undefined? Can you explain in terms of the original test
> source? I don't immediately see anything undefined there.
Ah, the cast from int field5 to v4df? Yes, that doesn'
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-09-08 18:55 ---
The alignment of llvm_cbe__24__StackDv_P53 is only 64bits so you are casting to
a greater aligned type and then dereferencing it.
That being said, the LLVM C back-end produces crazy c code that is also
undefined bec
--- Comment #5 from greened at obbligato dot org 2010-09-08 18:52 ---
Why is the code undefined? Can you explain in terms of the original test
source? I don't immediately see anything undefined there.
--
greened at obbligato dot org changed:
What|Removed
--- Comment #4 from jv244 at cam dot ac dot uk 2010-09-08 18:22 ---
(In reply to comment #3)
> just a question. why is this illegal ?
it is R528 in the section on the data statement of the F2003 standard that
suggests this has to be a scalar-structure-component. Not so obvious why, if
y
--- Comment #5 from LpSolit at netscape dot net 2010-09-08 18:18 ---
Resetting the target milestone, which doesn't exist in the 'classpath' product.
--
LpSolit at netscape dot net changed:
What|Removed |Added
---
--- Comment #4 from LpSolit at netscape dot net 2010-09-08 18:18 ---
Resetting the target milestone, which doesn't exist in the 'classpath' product.
--
LpSolit at netscape dot net changed:
What|Removed |Added
---
--- Comment #5 from LpSolit at netscape dot net 2010-09-08 18:18 ---
Resetting the target milestone, which doesn't exist in the 'classpath' product.
--
LpSolit at netscape dot net changed:
What|Removed |Added
---
--- Comment #5 from LpSolit at netscape dot net 2010-09-08 18:18 ---
Resetting the target milestone, which doesn't exist in the 'classpath' product.
--
LpSolit at netscape dot net changed:
What|Removed |Added
---
--- Comment #5 from LpSolit at netscape dot net 2010-09-08 18:18 ---
Resetting the target milestone, which doesn't exist in the 'classpath' product.
--
LpSolit at netscape dot net changed:
What|Removed |Added
---
--- Comment #3 from LpSolit at netscape dot net 2010-09-08 18:18 ---
Resetting the target milestone, which doesn't exist in the 'classpath' product.
--
LpSolit at netscape dot net changed:
What|Removed |Added
---
--- Comment #3 from LpSolit at netscape dot net 2010-09-08 18:18 ---
Resetting the target milestone, which doesn't exist in the 'classpath' product.
--
LpSolit at netscape dot net changed:
What|Removed |Added
---
--- Comment #2 from nicola at gcc dot gnu dot org 2010-09-08 18:16 ---
objc/typedstream.h has been deprecated in 4.6.0 and will be removed in the next
GCC release. There is no point in trying to fix a bug in it.
Please use gnustep-base or some other Foundation-type library if you need
--- Comment #5 from jamborm at gcc dot gnu dot org 2010-09-08 18:15 ---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Resolution|
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-09-08 18:13 ---
Subject: Bug 45443
Author: jamborm
Date: Wed Sep 8 18:13:03 2010
New Revision: 164018
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164018
Log:
2010-09-08 Martin Jambor
PR other/45443
*
--- Comment #6 from jakub at gcc dot gnu dot org 2010-09-08 18:10 ---
Created an attachment (id=21744)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21744&action=view)
gcc46-pr20517.patch
Untested patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20517
--- Comment #8 from dominiq at lps dot ens dot fr 2010-09-08 18:08 ---
If I revert the patch in comment #5 from revision 164002, compiling the code in
comment #6 gives a segmentation fault.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45577
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-01 01:25 ---
That is because it is the same as PR 31217.
*** This bug has been marked as a duplicate of 31217 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
When a while loop with the true condition (while (1)) contains
an if statement with a modulus evaluated on a counter variable, it
appears that gcc incorrectly optimizes out the modulus check as a
constant (even though the counter variable is updated after the if
statement). If the counter
--- Comment #3 from jakub at gcc dot gnu dot org 2010-09-08 17:52 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from nicola at gcc dot gnu dot org 2010-09-08 17:52 ---
Created an attachment (id=21743)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21743&action=view)
A tidied up testcase ready for the GCC testsuite
--
nicola at gcc dot gnu dot org changed:
What
--- Comment #5 from jakub at gcc dot gnu dot org 2010-09-08 17:52 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from nicola at gcc dot gnu dot org 2010-09-08 17:50 ---
Apologies, bugzilla confused me by jumping to the next bug and I attached a
testcase to the wrong bug! ;-)
Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23215
--- Comment #8 from dominiq at lps dot ens dot fr 2010-09-08 17:49 ---
One of the first thing taught in fortran is that the loop ordering in the test
in comment #0 is bad.
If the loops are interchanged (as they should) the code vectorize. Is not
-floop-interchange supposed to do that if
--- Comment #6 from nicola at gcc dot gnu dot org 2010-09-08 17:49 ---
Created an attachment (id=21742)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21742&action=view)
A tidied up testcase ready for the GCC testsuite
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23215
--- Comment #7 from nicola at gcc dot gnu dot org 2010-09-08 17:48 ---
Confirmed.
Thanks
--
nicola at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #9 from vmakarov at redhat dot com 2010-09-08 17:44 ---
The problem is in that pseudos (r121 in our case) spilled by IRA are
not added to live_throughout of reload chain. As the result,
pseudo_forbidden_regs are not set up for such pseudos and they can get
a hard registers (
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-09-08 17:43 ---
Yes this is invalid with respect of alignment requirements.
It becomes obvious from the optimized at -O0 on the trunk.
v4df llvm_cbe_r5585;
v4df llvm_cbe_r5584;
struct l_DV1 llvm_cbe__24__StackDv_P53;
unsig
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-08 17:39 ---
I think this code is undefined with respect of alignment requirements.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45600
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-09-08 17:36 ---
Subject: Bug 45443
Author: jamborm
Date: Wed Sep 8 17:36:40 2010
New Revision: 164011
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164011
Log:
2010-09-08 Martin Jambor
PR other/45443
*
--- Comment #2 from jamborm at gcc dot gnu dot org 2010-09-08 17:27 ---
Subject: Bug 45443
Author: jamborm
Date: Wed Sep 8 17:27:09 2010
New Revision: 164009
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164009
Log:
2010-09-08 Martin Jambor
PR other/45443
*
--- Comment #4 from jakub at gcc dot gnu dot org 2010-09-08 17:24 ---
Subject: Bug 45595
Author: jakub
Date: Wed Sep 8 17:23:52 2010
New Revision: 164008
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164008
Log:
PR fortran/45595
* openmp.c (resolve_omp_do): Rep
--- Comment #3 from jakub at gcc dot gnu dot org 2010-09-08 17:22 ---
Subject: Bug 45595
Author: jakub
Date: Wed Sep 8 17:22:36 2010
New Revision: 164007
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164007
Log:
PR fortran/45595
* openmp.c (resolve_omp_do): Rep
--- Comment #28 from mikael at gcc dot gnu dot org 2010-09-08 17:21 ---
(In reply to comment #27)
> What is the fate of the patch in comment #19?
>
Some (admittedly small) parts of the patch are already on trunk.
The transpose patches still waiting review at
http://gcc.gnu.org/ml/fortra
--- Comment #14 from jamborm at gcc dot gnu dot org 2010-09-08 17:01
---
Patches submitted to the mailing list for approval/comments:
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00674.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44972
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-08 16:58
---
Actually, it seems pretty straightforward to me that S is nondeduced in the
last case: see 14.8.2.4/4, the last line.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #2 from jakub at gcc dot gnu dot org 2010-09-08 16:47 ---
Subject: Bug 45597
Author: jakub
Date: Wed Sep 8 16:47:16 2010
New Revision: 164005
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164005
Log:
PR fortran/45597
* trans-openmp.c (gfc_trans_omp_
--- Comment #2 from jakub at gcc dot gnu dot org 2010-09-08 16:46 ---
Subject: Bug 45595
Author: jakub
Date: Wed Sep 8 16:46:13 2010
New Revision: 164004
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164004
Log:
PR fortran/45595
* openmp.c (resolve_omp_do): Rep
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-08 16:44
---
Please clarify: "As far as I can find on the net, it should work." No compiler
to which I have access compiles it, I tried, besides GCC, Intel, SunStudio,
Comeau, VC++8. Note I didn't really analyze the testcas
--- Comment #2 from stephane at magnenat dot net 2010-09-08 16:31 ---
Output of g++ -v -save-temps -o test.o -c test.cpp :
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gc
--- Comment #1 from stephane at magnenat dot net 2010-09-08 16:30 ---
Created an attachment (id=21741)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21741&action=view)
Minimal test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45601
The explicit template instantiation fails. As far as I can find on the net, it
should work. See attached minimal test case.
--
Summary: explicit template instanciation problem
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norma
--- Comment #24 from rwild at gcc dot gnu dot org 2010-09-08 16:26 ---
(In reply to comment #22)
> I've just read this thread and am now unsure as to whether there is a bug with
> GCC or not. It sounds like your initial troubles have gone away and now there
> is a new problem. Would it
--- Comment #1 from ibolton at gcc dot gnu dot org 2010-09-08 16:21 ---
reg is assigned to a temporary (reg.0) at the very first tree pass, as shown by
this 004t.gimple dump:
d ()
{
struct b * const reg.0;
unsigned int * D.2019;
int D.2020;
goto ;
:
c ();
:
reg.0 = reg;
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-08 16:19 ---
This is caused by revision 163973:
http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00265.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45598
--- Comment #5 from jakub at gcc dot gnu dot org 2010-09-08 16:19 ---
Yes, please, and assign to me (working on a simplify_comparison fix for that).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20517
--- Comment #12 from sfilippone at uniroma2 dot it 2010-09-08 16:11 ---
(In reply to comment #11)
> (In reply to comment #10)
>
> How did you configure those prebuilt gmp/mpfr/mpc libraries installed under
> your home directory? In particular, did you configure them all with
> --disabl
--- Comment #2 from greened at obbligato dot org 2010-09-08 16:09 ---
Created an attachment (id=21740)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21740&action=view)
Reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45600
--- Comment #1 from greened at obbligato dot org 2010-09-08 16:08 ---
Compile with -c -mavx reduced.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45600
For the attached testcase, gcc generates a vmovapd for the store to
llvm_cbe__24__StackDv_P53. The latest Intel sde generates an alignment error:
SDE ERROR: ALIGN32 FAILED PC=40048b MEMEA=7ff057d0 vmovapd ymmword ptr
[rax], ymm0
It looks like gcc is considering 16-byte aligned data to be sui
--- Comment #11 from mikpe at it dot uu dot se 2010-09-08 16:00 ---
(In reply to comment #10)
> (In reply to comment #9)
> >
> I have found a cure.
>
> The original configuration had GMP, MPFR and MPC built and installed under the
> user home directory (there were neither mpfr nor mpc
--- Comment #7 from dominiq at lps dot ens dot fr 2010-09-08 15:52 ---
The following code reduced from
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/76f99e7fd4f3e772#
module type2_type
implicit none
type, abstract :: Type2
character :: typeName*(30) = "
--- Comment #10 from sfilippone at uniroma2 dot it 2010-09-08 15:35 ---
(In reply to comment #9)
>
I have found a cure.
The original configuration had GMP, MPFR and MPC built and installed under the
user home directory (there were neither mpfr nor mpc system-wide, and gmp was a
bit ol
1 - 100 of 159 matches
Mail list logo
