--- Comment #2 from pzhao at gcc dot gnu dot org 2010-06-25 07:32 ---
Subject: Bug 44517
Author: pzhao
Date: Fri Jun 25 07:31:49 2010
New Revision: 161363
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161363
Log:
gcc/
2010-06-25 Shujing Zhao
PR c/44517
* c-p
--- Comment #15 from jakub at gcc dot gnu dot org 2010-06-25 08:13 ---
Created an attachment (id=21000)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21000&action=view)
gcc46-pr43866.patch
Here is a complete fix.
This includes what the earlier two patches did, plus for nested
tre
--- Comment #13 from bernds at gcc dot gnu dot org 2010-06-25 08:56 ---
Subject: Bug 43902
Author: bernds
Date: Fri Jun 25 08:56:24 2010
New Revision: 161366
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161366
Log:
With large parts from Jim Wilson:
PR target/43
--- Comment #3 from borntraeger at de dot ibm dot com 2010-06-25 09:02
---
Created an attachment (id=21001)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21001&action=view)
Potential fix for compile time regression
Here is a potential fix. We just limit prefetching to loops with
--- Comment #16 from rakdver at gcc dot gnu dot org 2010-06-25 09:04
---
> Now, in the first loop if we decide to unswitch on cond3, it transforms this
> into:
...
> If cond3 tests some variable that is initialized only if cond1 is false, this
> unswitching (besides not being very usefu
--- Comment #17 from rakdver at gcc dot gnu dot org 2010-06-25 09:12
---
(In reply to comment #16)
> > Now, in the first loop if we decide to unswitch on cond3, it transforms this
> > into:
> ...
> > If cond3 tests some variable that is initialized only if cond1 is false,
> > this
> >
--- Comment #18 from jakub at gcc dot gnu dot org 2010-06-25 09:14 ---
That part comes from the questionable testcase, which does
a_sp => matrix%local_data_sp
before the loop unconditionally, eventhough matrix%local_data_sp is
uninitialized unless use_sp is .true.
Without the unswitching
I think this was not reported yet, and both refer to the same problem.
--
Summary: unitialized memory on testcases abstract_type_6.f03 and
typebound_call_4.f03
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: nor
--- Comment #11 from burnus at gcc dot gnu dot org 2010-06-25 09:17 ---
(In reply to comment #10)
> What language is GAMESS written in?
Fortran, of course. See: http://www.spec.org/cpu2006/Docs/416.gamess.html
and http://www.msg.ameslab.gov/GAMESS/GAMESS.html
> The above simply is not
--- Comment #19 from jakub at gcc dot gnu dot org 2010-06-25 09:19 ---
The compiler doesn't know that matrix%local_data_sp is uninitialized (at least
unless it would propagate that info in some IPA pass), matrix%local_data_sp is
a field in what an arguments points at (and the argument is
--- Comment #12 from mikael at gcc dot gnu dot org 2010-06-25 09:27 ---
(In reply to comment #11)
> However, regressions are now on transpose :
> - alloc_comp_transformational_1.f90 : double free on function exit. I will
> have to investigate.
Fixed
> - char_length_8.f90 : reshape doe
--- Comment #20 from jv244 at cam dot ac dot uk 2010-06-25 09:28 ---
(In reply to comment #18)
> That part comes from the questionable testcase, which does
> a_sp => matrix%local_data_sp
> before the loop unconditionally, eventhough matrix%local_data_sp is
> uninitialized unless use_sp i
--- Comment #13 from mikael at gcc dot gnu dot org 2010-06-25 09:34 ---
Created an attachment (id=21002)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21002&action=view)
Updated patch
As I was having memory corruption regressions, I started to run valgrind on
some testcases, whose
--- Comment #14 from mikael at gcc dot gnu dot org 2010-06-25 09:36 ---
TODO:
* testcases to check anything that might be impacted by the patch
* split the patch for review & commit
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
--- Comment #21 from jakub at gcc dot gnu dot org 2010-06-25 09:38 ---
True. Most of the fields of the pointer are still uninitialized (NULLIFY only
clears the data field).
I'm afraid when NULLIFY doesn't clear the whole struct there will be always a
possibility valgrind might complain,
--- Comment #15 from mikael at gcc dot gnu dot org 2010-06-25 09:42 ---
Isn't there a problem with the size of the patch ?
pr43829_3.diff 46.78 KB
I get here:
% du -h pr43829_3.diff
240Kpr43829_3.diff
%
At least it is not truncated (I have just checked).
--
http://gcc.gnu.o
--- Comment #1 from mikael at gcc dot gnu dot org 2010-06-25 09:45 ---
It is fixed by the patch at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829#c13
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44662
--- Comment #16 from rguenther at suse dot de 2010-06-25 09:45 ---
Subject: Re: Scalarization of reductions
On Fri, 25 Jun 2010, mikael at gcc dot gnu dot org wrote:
> --- Comment #15 from mikael at gcc dot gnu dot org 2010-06-25 09:42
> ---
> Isn't there a problem with the
--- Comment #12 from mikael at gcc dot gnu dot org 2010-06-25 10:32 ---
(In reply to comment #11)
> Thus, seemingly, reject_statement leaves the symtree in a half-existing state.
> It calls: gfc_undo_symbols () and undo_new_statement (). I think the former
> one only does a partial clea
--- Comment #13 from mikael at gcc dot gnu dot org 2010-06-25 10:33 ---
Created an attachment (id=21003)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21003&action=view)
patch against my (diry) tree
patch restoring the old equivalence list on reject_statement ()
--
http://gcc
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-06-25 10:35
---
Subject: Bug 44555
Author: rguenth
Date: Fri Jun 25 10:35:40 2010
New Revision: 161370
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161370
Log:
2010-06-25 Richard Guenther
Backport from mainl
hi,
the latest llvm/clang++ reports an error during parsing
included from :
In file included from t00.cpp:1:
In file included from /usr/include/c++/4.5.0/tr1/functional:39:
/usr/include/c++/4.5.0/tr1/tuple:68:30: error: variadic templates are only
allowed in C++0x
template
afaics there's no #
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-25 11:08 ---
(In reply to comment #0)
> the latest llvm/clang++ reports an error during parsing
> included from :
>
> In file included from t00.cpp:1:
> In file included from /usr/include/c++/4.5.0/tr1/functional:39:
> /usr/includ
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-25 11:26 ---
This goes wrong with -O2 -funroll-loops already during tree opts. In vrp2 we
have:
b[2][1]{lb: 1 sz: 1} = D.1599_148;
b[3][1]{lb: 1 sz: 1} = D.1599_154;
D.1635_152 = 2;
D.1636_151 = &b[2][1]{lb: 1 sz: 1};
D.
--- Comment #2 from mikael at gcc dot gnu dot org 2010-06-25 11:29 ---
(In reply to comment #1)
> It is fixed by the patch at:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829#c13
>
relevant hunk:
diff --git a/decl.c b/decl.c
index aa7a266..840c32c 100644
--- a/decl.c
+++ b/decl.c
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-25 11:49
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #2 from redi at gcc dot gnu dot org 2010-06-25 11:55 ---
http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.other_compilers
If the guards were there as you suggest, tr1::tuple would only be usable in
C++0x mode, where it's redundant because you have std::tuple anyway.
g++
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-25 11:59
---
Totally agree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44663
--- Comment #6 from jakub at gcc dot gnu dot org 2010-06-25 12:07 ---
Subject: Bug 44539
Author: jakub
Date: Fri Jun 25 12:07:00 2010
New Revision: 161374
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161374
Log:
PR tree-optimization/44539
* tree-cfgcleanup.c (f
--- Comment #22 from jakub at gcc dot gnu dot org 2010-06-25 12:11 ---
Subject: Bug 43866
Author: jakub
Date: Fri Jun 25 12:10:42 2010
New Revision: 161375
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161375
Log:
PR middle-end/43866
* tree-ssa-loop-unswitch.c (
Unaware of any current (GDB) problems from it.
echo 'class C { public: C () {} }; int main() { C c; }' | g++ -Wall -g -x c++ -
FAIL g++ (GCC) 4.4.5 20100625 (prerelease)
FAIL g++ (GCC) 4.5.1 20100625 (prerelease)
FAIL g++ (GCC) 4.6.0 20100625 (experimental) [under the test below]
C
in gcc-4.5 and trunk:
gimplify.c:
/* Return true if T is a CALL_EXPR or an expression that can be
- assignmed to a temporary. Note that this predicate should only be
+ assigned to a temporary. Note that this predicate should only be
used during gimplification.
--- Comment #7 from jakub at gcc dot gnu dot org 2010-06-25 12:30 ---
Should be fixed now.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #23 from jakub at gcc dot gnu dot org 2010-06-25 12:30 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-25 13:09 ---
Subject: Bug 44665
Author: manu
Date: Fri Jun 25 13:09:28 2010
New Revision: 161380
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161380
Log:
2010-06-25 Manuel López-Ibáñez
PR 44665
* tree
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-25 13:10 ---
For DW_AT_low_pc, we do this because of (DWARF4, 3.1.1:
"A DW_AT_low_pc attribute may also be specified in combination with
DW_AT_ranges to specify the default base address for use in location lists (see
Section 2.6.2)
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-25 13:14 ---
FIXED in trunk.
Such fixes are considered obvious, so feel free to commit patches to fix them.
Fixing changelogs and svn logs for typos falls also into the obvious category.
If you do not have write access, just send a
--- Comment #1 from turutani at scphys dot kyoto-u dot ac dot jp
2010-06-25 13:54 ---
Created an attachment (id=21004)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21004&action=view)
sample code
This is a test code to generate error.
gcc-4.2.5 20090325 generates no error.
gcc-4.
--- Comment #18 from hjl dot tools at gmail dot com 2010-06-25 14:09
---
(In reply to comment #17)
> Subject: Re: [4.4/4.5/4.6 Regression] Performance
> degradation for simple fibonacci numbers calculation
>
> This is not correct, when profile is guessed we should look into th
On Jun 25, 2010, at 3:49 AM, "pluto at agmk dot net" > wrote:
hi,
the latest llvm/clang++ reports an error during parsing
included from :
Both of these are c++0x only headers and really are only supported
when compiling in c++0x mode.
In file included from t00.cpp:1:
In file includ
--- Comment #4 from pinskia at gmail dot com 2010-06-25 14:18 ---
Subject: Re: New: missed GXX_EXPERIMENTAL guards in ?
On Jun 25, 2010, at 3:49 AM, "pluto at agmk dot net" wrote:
> hi,
>
> the latest llvm/clang++ reports an error during parsing
> included from :
Both of these a
--- Comment #5 from paolo dot carlini at oracle dot com 2010-06-25 14:23
---
Wrong Andrew.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44663
"12.5.2.12 Argument presence and restrictions on arguments not present
A dummy argument or an entity that is host associated with a dummy argument is
not present if the dummy argument
[...]
* does not have the ALLOCATABLE or POINTER attribute, and corresponds to an
actual argument that
- has t
Command line:
$ gfortran -O2 -fprofile-generate
or
$ gfortran -O1 -finline-small-functions -fprofile-generate
Compiler output:
$ gfortran -O1 -finline-small-functions -fprofile-generate
/mnt/svn/gcc-trunk/gcc/testsuite/gfortran.dg/char_pointer_assign_5.f90
/mnt/svn/gcc-trunk/gcc/testsuite/gfortran
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-checking
Target Milestone|--- |4.5.1
--- Comment #22 from sfilippone at uniroma2 dot it 2010-06-25 15:31 ---
(In reply to comment #21)
Ok, I bit the bullet, and fooled around with the internals to see what was
happening. I did a very naive thing of adding warnings in
resolve.c:resolve_typebound_generic_call, and I think I h
--- Comment #1 from hjl at gcc dot gnu dot org 2010-06-25 15:33 ---
Subject: Bug 44326
Author: hjl
Date: Fri Jun 25 15:33:21 2010
New Revision: 161389
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161389
Log:
Don't search DEBUG_INSNs for removable zero extends.
2010-06-25 H.J
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-25 15:34 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #4 from matz at gcc dot gnu dot org 2010-06-25 15:34 ---
Indeed. Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassig
--- Comment #23 from sfilippone at uniroma2 dot it 2010-06-25 15:34 ---
(In reply to comment #22)
>
generic_23.f03 obviously works becase the binding name DOIT and the procedure
name are one and the same
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
--- Comment #8 from sje at cup dot hp dot com 2010-06-25 16:10 ---
Resolved with code change to test case.
--
sje at cup dot hp dot com changed:
What|Removed |Added
er)
<3d> DW_AT_name: v
<41> DW_AT_type: <0x33>
<45> DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst:
0)
<48> DW_AT_accessibility: 2 (protected)
DIE <0x33> should have DW_AT_accessibility.
! { dg-options "-O2 -funroll-loops" }
function foo (b)
character (len=1) :: b(4)
logical :: foo
foo = any (b .ne. (/"1","2","3","4"/))
end
results in horrible code:
movzbl .LC0(%rip), %edx
movl$1, %eax
cmpb%dl, (%rdi)
jne .L2
movzbl .LC1(
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44669
--- Comment #1 from jan dot kratochvil at redhat dot com 2010-06-25 16:31
---
Dependent GDB Bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=11757
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44668
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-25 16:43 ---
Another testcase:
[...@gnu-6 44659]$ cat extract-3.c
typedef struct
{
unsigned char c1;
unsigned char c2;
unsigned char c3;
unsigned char c4;
} foo_t;
int
foo (foo_t x)
{
return x.c2 != 0;
}
[...@gnu-6 4
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-25
16:48 ---
Subject: Re: [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and
--traditional-cpp
It occured to me that this is only failing for me with 32-bit cc1,
i.e. i386-pc-solaris2.11, sparc-sun-solaris2.11, mi
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-25
16:49 ---
Subject: Re: 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0
>> --- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-06-22 01:24
>> ---
>> atan2_1.f90 has failed on other p
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-25 16:53 ---
Created an attachment (id=21005)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21005&action=view)
gcc46-pr44668.patch
Patch to fix this for typedefs. More work will be needed to handle it for
other DW_TAG_* typ
--- Comment #4 from changpeng dot fang at amd dot com 2010-06-25 17:08
---
(In reply to comment #3)
> Created an attachment (id=21001)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21001&action=view) [edit]
> Potential fix for compile time regression
>
> Here is a potential fix.
../../gcc/gcc/config/arm/arm.c: In function insn_code
locate_neon_builtin_icode(int, neon_itype*):
../../gcc/gcc/config/arm/arm.c:18244: error: structure key with uninitialized
const members
--
Summary: arm port fails to build with --enable-build-with-cxx
Product: gcc
--- Comment #14 from kargl at gcc dot gnu dot org 2010-06-25 17:14 ---
(In reply to comment #11)
>
> Well, it is invalid code - based on a valid Fortran code. If you use Delta to
> reduce a test case (cf.
> http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction),
> it simply removes li
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-25 17:50 ---
It is caused by revision 150519:
http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00199.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #15 from jakub at gcc dot gnu dot org 2010-06-25 18:11 ---
Well, the compiler shouldn't ICE on invalid input.
And, delta is just a simple text tool, it depends on the user how he writes the
test script. Ideally when reducing a testcase to find an ICE the delta test
script s
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-06-25 18:22
---
Please go ahead and commit, OK by me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-25 18:23 ---
Created an attachment (id=21006)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21006&action=view)
gcc46-pr44668.patch
Updated patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from ro at gcc dot gnu dot org 2010-06-25 18:32 ---
Subject: Bug 8
Author: ro
Date: Fri Jun 25 18:31:33 2010
New Revision: 161392
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161392
Log:
2010-06-25 Jerry DeLisle
PR fortran/8
* gfortr
--- Comment #13 from ro at gcc dot gnu dot org 2010-06-25 18:33 ---
Subject: Bug 8
Author: ro
Date: Fri Jun 25 18:33:01 2010
New Revision: 161393
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161393
Log:
2010-06-25 Jerry DeLisle
PR fortran/8
* gfortr
--- Comment #14 from ro at gcc dot gnu dot org 2010-06-25 18:36 ---
Thanks, installed on mainline and 4.5 branch.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
.c (main): Output include of insn-constants.h
* Makefile.in (insn-enums.o): Depend on insn-constants.h.
Modified:
branches/multi-target-20100625-branch/gcc/ChangeLog
branches/multi-target-20100625-branch/gcc/Makefile.in
branches/multi-target-20100625-branch/gcc/genenums.c
--
rs6000.c (rs6000_xcoff_strip_dollar): Use const char *
variable for const char * strchr result.
Modified:
branches/multi-target-20100625-branch/gcc/ChangeLog
branches/multi-target-20100625-branch/gcc/config/rs6000/rs6000.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44637
50.c: Likewise.
* config/s390/s390.c: Likewise.
* config/rs6000/rs6000.c: Likewise.
* config/arm/arm.c: Likewise.
* config/i386/i386.c: Likewise.
Modified:
branches/multi-target-20100625-branch/gcc/ChangeLog
branches/multi-target-20100625-branch/gcc/Makefile.i
On Linux/x86-64, revision 161382:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg01300.html
caused make-check failure in the libstdc++-v3 dir, during
the final link for testsuite_shared.so, ld spills:
relocation R_X86_64_PC32 against symbol
`__gnu_cxx::__common_pool<__gnu_cxx::__pool, true>::_S_get_po
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44671
--- Comment #21 from ro at gcc dot gnu dot org 2010-06-25 18:56 ---
Jerry, could you perhaps have a look at this one, too? This is the last
remaining
fortran testsuite failure on Solaris 11/x86.
Thanks.
Rainer
--
ro at gcc dot gnu dot org changed:
What|Removed
g/i386/i386.c: Likewise.
* config/i386/cygming.h: Likewise.
Modified:
branches/multi-target-20100625-branch/gcc/ChangeLog
branches/multi-target-20100625-branch/gcc/Makefile.in
branches/multi-target-20100625-branch/gcc/config/alpha/alpha.c
branches/multi-target-20100625-branch
y_reload): Likewise.
Modified:
branches/multi-target-20100625-branch/gcc/ChangeLog
branches/multi-target-20100625-branch/gcc/bt-load.c
branches/multi-target-20100625-branch/gcc/config/alpha/alpha.c
branches/multi-target-20100625-branch/gcc/config/bfin/bfin.c
branches/multi-target-
--- Comment #2 from tjvries at xs4all dot nl 2010-06-25 19:16 ---
Created an attachment (id=21007)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21007&action=view)
slightly more minimal testcase
reproduced on trunk revision 161295
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2010-06-25 19:24
---
Rainer,
I will look at the array_constructor_23.f itself and see what the front-end is
doing with it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
--- Comment #23 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-25
19:26 ---
Subject: Re: [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously
Great, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
Follow up to PR 43388.
Currently,
ALLOCATE (var(allocate-shape-spec-list), SOURCE=source-expr)
works but
ALLOCATE (var(allocate-shape-spec-list), SOURCE=array-source-expr)
does not; in the latter case the array shape should be taken from the SOURCE --
this is a new Fortran 2008 feature.
Cur
--- Comment #3 from tjvries at xs4all dot nl 2010-06-25 20:06 ---
Created an attachment (id=21008)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21008&action=view)
partially redoing the fix for bug 20612
The problem is in this piece of code in lambda_loopnest_gcc_loopnest:
...
--- Comment #24 from jvdelisle at gcc dot gnu dot org 2010-06-25 20:20
---
Created an attachment (id=21009)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21009&action=view)
Modified array_constructor_23.f to allow for some precision error
Rainer,
Try this version of the test cas
--- Comment #3 from sje at cup dot hp dot com 2010-06-25 20:21 ---
I see this failure on ia64 linux and hp-ux. The interesting thing is that it
fails when compiled with C++ but not when compiled with C. Here is a smaller
test case that shows that the imaginary part of c1 is +0 in the g
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-25 20:31 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-25
20:34 ---
Subject: Re: [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously
Jerry,
> Try this version of the test case and see what it does. If this fails, I will
--- Comment #26 from jvdelisle at gcc dot gnu dot org 2010-06-25 20:41
---
I will commit the change
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
--- Comment #27 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-25
20:43 ---
Subject: Re: [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously
> --- Comment #26 from jvdelisle at gcc dot gnu dot org 2010-06-25 20:41
> ---
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-25 20:51 ---
Can you verify that reverting r160903 fixes the issue and attach differences
in -fdump-rtl-expand-details and assembly (and maybe point me to the
important difference?)
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-25 20:56 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #6 from aoliva at gcc dot gnu dot org 2010-06-25 21:11 ---
Subject: Bug 44610
Author: aoliva
Date: Fri Jun 25 21:11:32 2010
New Revision: 161413
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161413
Log:
PR debug/44610
* simplify-rtx.c (delegitimize_mem_from_attrs):
--- Comment #7 from aoliva at gcc dot gnu dot org 2010-06-25 21:12 ---
Subject: Bug 44610
Author: aoliva
Date: Fri Jun 25 21:11:56 2010
New Revision: 161414
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161414
Log:
PR debug/44610
* simplify-rtx.c (delegitimize_mem_from_attrs):
--- Comment #8 from aoliva at gcc dot gnu dot org 2010-06-25 21:13 ---
Fixed
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Reproduced on 4.6.0 and 4.1.2 as well.
Here is the header file:
class TestClass
{
public:
void testFn() const;
private:
static const int VAR1 = 9;
static const int VAR2 = 5;
};
And here is the source file including it:
#include "testclass.h"
void TestClass::testFn() const
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-25 21:31 ---
You need indeed a definition.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-25 21:32 ---
Note if case does not need a diagnostic according to the C++ standard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44673
--- Comment #28 from jvdelisle at gcc dot gnu dot org 2010-06-25 21:32
---
Subject: Bug 38946
Author: jvdelisle
Date: Fri Jun 25 21:32:37 2010
New Revision: 161416
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161416
Log:
2010-06-25 Jerry DeLisle
PR testsuite/38946
config/sh/sh.c (sh_override_options): Change type to match hook.
Make manipulation of global flags dependent on main_target.
(TARGET_OVERRIDE_OPTIONS): Redefine.
gcc/po:
* EXCLUDES: Add gentargtype.cc.
Added:
branches/multi-target-20100625-branch/ChangeLog.multi-target
--- Comment #3 from Hodapp87 at gmail dot com 2010-06-25 21:45 ---
(In reply to comment #1)
> You need indeed a definition.
>
Why does it require a definition in the ternary case, but not in the if/else?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44673
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-06-25 21:47 ---
In the case of if, the value was "inlined" and in the case of ?:, it is not. I
had a patch which changed the behavior but lost it when I moved companies.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44673
1 - 100 of 115 matches
Mail list logo
