The following valid code snippet triggers an ICE on trunk when compiled with
-O3 on i686-pc-linux-gnu and x86_64-unknown-linux-gnu:
===
templateint struct A
{
void foo(void(*)(A));
void bar(void(*f)(A)) { foo(f); foo(f); }
};
templateint N
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44206
--- Comment #12 from reichelt at gcc dot gnu dot org 2010-05-20 06:25
---
The failure in comment #1 might be related to PR 44206.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
--- Comment #1 from wilson at gcc dot gnu dot org 2010-05-20 06:27 ---
Subject: Bug 43764
Author: wilson
Date: Thu May 20 06:26:52 2010
New Revision: 159610
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159610
Log:
PR target/43764
* mips.c (mips_call_expr_from_insn): New arg
--- Comment #2 from wilson at gcc dot gnu dot org 2010-05-20 06:27 ---
Mine.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #2 from hp at gcc dot gnu dot org 2010-05-20 06:45 ---
Subject: Bug 44202
Author: hp
Date: Thu May 20 06:44:45 2010
New Revision: 159611
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159611
Log:
PR target/44202
* gcc.c-torture/execute/pr44202-1.c: New
--- Comment #3 from hp at gcc dot gnu dot org 2010-05-20 06:46 ---
Subject: Bug 44202
Author: hp
Date: Thu May 20 06:45:38 2010
New Revision: 159612
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159612
Log:
PR target/44202
* config/cris/cris.md (*addsi3_v32):
--- Comment #4 from hp at gcc dot gnu dot org 2010-05-20 06:47 ---
Subject: Bug 44202
Author: hp
Date: Thu May 20 06:47:41 2010
New Revision: 159613
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159613
Log:
PR target/44202
* gcc.c-torture/execute/pr44202-1.c: New
--- Comment #5 from hp at gcc dot gnu dot org 2010-05-20 06:48 ---
Subject: Bug 44202
Author: hp
Date: Thu May 20 06:48:37 2010
New Revision: 159614
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159614
Log:
PR target/44202
* config/cris/cris.md (*addsi3_v32):
--- Comment #6 from hp at gcc dot gnu dot org 2010-05-20 06:50 ---
Subject: Bug 44202
Author: hp
Date: Thu May 20 06:50:15 2010
New Revision: 159615
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159615
Log:
PR target/44202
* gcc.c-torture/execute/pr44202-1.c: New
--- Comment #7 from hp at gcc dot gnu dot org 2010-05-20 06:51 ---
Subject: Bug 44202
Author: hp
Date: Thu May 20 06:51:05 2010
New Revision: 159616
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159616
Log:
PR target/44202
* config/cris/cris.md (*addsi3_v32):
--- Comment #8 from hp at gcc dot gnu dot org 2010-05-20 06:52 ---
Subject: Bug 44202
Author: hp
Date: Thu May 20 06:52:25 2010
New Revision: 159617
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159617
Log:
PR target/44202
* gcc.c-torture/execute/pr44202-1.c: New
--- Comment #9 from hp at gcc dot gnu dot org 2010-05-20 06:53 ---
Subject: Bug 44202
Author: hp
Date: Thu May 20 06:53:34 2010
New Revision: 159618
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159618
Log:
PR target/44202
* config/cris/cris.md (*addsi3_v32):
--- Comment #10 from hp at gcc dot gnu dot org 2010-05-20 07:02 ---
Fixed, see also http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01456.html.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from irar at il dot ibm dot com 2010-05-20 07:13 ---
Do you mean that extract_even implementation does something illegal with this
last element? Misaligned load also accesses elements outside the array, but the
problem is in extract_even?
Other than doing something in
--- Comment #5 from burnus at gcc dot gnu dot org 2010-05-20 07:40 ---
TODO: Constraint checks are missing and partially incorrect,
cf. http://gcc.gnu.org/ml/fortran/2010-05/msg00225.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43851
program ice_prog
type::ice_type
integer,dimension(:),allocatable::list
end type ice_type
type(ice_type)::this
integer::dim,i
allocate(this%list(dim),source=[(i,i=1,dim)])
end program ice_prog
Compiling this with GNU Fortran (GCC) 4.6.0 20100518 (experimental) will cause
a segmentation
--- Comment #1 from borntraeger at de dot ibm dot com 2010-05-20 08:29
---
Indeed. I think I found a typo when handling array prefetches.
a potential fix might be:
--- gcc/tree-ssa-loop-prefetch.c(Revision 159557)
+++ gcc/tree-ssa-loop-prefetch.c(Arbeitskopie)
@@
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-20 08:50 ---
(In reply to comment #1)
Do you mean that extract_even implementation does something illegal with this
last element? Misaligned load also accesses elements outside the array, but
the
problem is in extract_even?
--- Comment #1 from dominiq at lps dot ens dot fr 2010-05-20 08:52 ---
Confirmed. Note that as such the code is invalid (dim is not set), but adding a
line dim=10 does not remove the ICE. The backtrace is:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason:
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-20 09:36 ---
Confirmed. The problem occurs with allocatable components only, allocatable
variables are fine.
#0 0x0813d1cd in conformable_arrays (e1=0x8bff710, e2=0x8bc9a30) at
--- Comment #5 from paolo dot carlini at oracle dot com 2010-05-20 09:57
---
On it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from irar at il dot ibm dot com 2010-05-20 10:04 ---
I am curious what is the problem with that? These elements are not used, they
are just loaded...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44183
--- Comment #4 from mikpe at it dot uu dot se 2010-05-20 10:18 ---
(In reply to comment #3)
I am curious what is the problem with that? These elements are not used, they
are just loaded...
An out-of-bounds read can result in a SEGV if the memory is unmapped. Worse
things can happen
--- Comment #26 from redi at gcc dot gnu dot org 2010-05-20 10:18 ---
I tweaked the patch to apply it to 4.4.3 (replacing ASM_BYTE with .byte) and it
fixes the bootstrap failure for this config:
--enable-languages=c,c++,fortran --with-arch=core2 --with-as=/usr/sfw/bin/gas
--with-gnu-as
--- Comment #5 from irar at il dot ibm dot com 2010-05-20 10:24 ---
Even if we are talking about less than vector size from array boundary? And
that boundary is not (vector) aligned.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44183
--- Comment #12 from jakub at gcc dot gnu dot org 2010-05-20 10:29 ---
Subject: Bug 44074
Author: jakub
Date: Thu May 20 10:28:36 2010
New Revision: 159622
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159622
Log:
PR target/44074
* configure: Regenerate.
--- Comment #13 from jakub at gcc dot gnu dot org 2010-05-20 10:30 ---
Patching in configure pieces generated with autoconf 2.64 into autoconf 2.59
generated configure totally broke the branch, configure after a few errors kept
printing y in an endless loop.
--
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-05-20
10:32 ---
Subject: Re: Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on
same line
--- Comment #13 from jakub at gcc dot gnu dot org 2010-05-20 10:30
---
Patching in configure pieces
--- Comment #6 from mikpe at it dot uu dot se 2010-05-20 11:05 ---
It depends on the specific values of (a) array end alignment and (b) the number
of bytes read. As long as the array end + number of bytes read can cross a page
boundary, you're potentially causing SEGV or other errors.
--- Comment #1 from dodji at gcc dot gnu dot org 2010-05-20 11:06 ---
A patch has been proposed to
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01476.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44188
Sorry, I report this bug with a Major severity, because it applies to all
front-ends and backends.
Consider the following code:
static void f() __attribute__((warning(should not be linked)));
void f() {}
int main() { f(); }
---
You just can't compile it without removing -Werror,
because
--- Comment #1 from redi at gcc dot gnu dot org 2010-05-20 11:40 ---
IMHO this is an enhancement request, not severity=Major
-Werror is not on by default, if you choose to enable it then you deal with the
consequences.
Obviously the ideal is for every warning to be controllable by an
--- Comment #2 from redi at gcc dot gnu dot org 2010-05-20 11:45 ---
N.B. Bug 44054 is the PR for the fortran FE to support -Werror= etc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209
As I always wonder if my compiler could help me find more bugs,
and the list of warnings I enable tend to be very long,
and -Wall is not enough for me...
(This bug certainly depends on #44209: Some warnings are not linked to
diagnostics options)
It would be great to have the following options:
--- Comment #16 from rguenther at suse dot de 2010-05-20 11:48 ---
Subject: Re: [4.5 Regression] Aliasing bug triggered by
Boost.Bind/Boost.Function
On Thu, 20 May 2010, jason at gcc dot gnu dot org wrote:
--- Comment #15 from jason at gcc dot gnu dot org 2010-05-20 05:35
--- Comment #10 from ro at gcc dot gnu dot org 2010-05-20 12:06 ---
Subject: Bug 43870
Author: ro
Date: Thu May 20 12:05:54 2010
New Revision: 159625
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159625
Log:
PR bootstrap/43870
* df-scan.c (df_ref_compare):
--- Comment #11 from ro at gcc dot gnu dot org 2010-05-20 12:07 ---
Subject: Bug 43870
Author: ro
Date: Thu May 20 12:07:23 2010
New Revision: 159626
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159626
Log:
PR bootstrap/43870
* df-scan.c (df_ref_compare):
--- Comment #12 from ro at gcc dot gnu dot org 2010-05-20 12:08 ---
Subject: Bug 43870
Author: ro
Date: Thu May 20 12:08:34 2010
New Revision: 159627
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159627
Log:
PR bootstrap/43870
* df-scan.c (df_ref_compare):
--- Comment #13 from ro at gcc dot gnu dot org 2010-05-20 12:10 ---
Fixed for 4.4.5, 4.5.1, 4.6.0.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from segher at gcc dot gnu dot org 2010-05-20 12:10 ---
I don't see the problem with 4.3 .
Kyle, are you sure it doesn't happen for you with 4.4?
I use
powerpc-linux-gnuspe-gcc -Wall -W -O1 -pthread -ftls-model=initial-exec
-mcpu=8540 -fPIC -S t.c -fverbose-asm
paste
--- Comment #7 from joakim dot tjernlund at transmode dot se 2010-05-20
12:13 ---
The below code doesn't generate any add with carry insn's for
either x86 nor powerpc:
u16
ipsum(u16 *buf, unsigned len, u16 sum)
{
int rest, carry ;
u32 acc_sum, *buf_u32, x;
acc_sum = sum;
len
--- Comment #7 from Kyle dot D dot Moffett at boeing dot com 2010-05-20
12:17 ---
Created an attachment (id=20707)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20707action=view)
Assembled tc.c output from Debian-built powerpc-linux-gnuspe-gcc 4.3.4
--
--
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=44204
module ice_module
type::ice_type
class(ice_type),pointer::next
contains
procedure::ice_proc
end type ice_type
contains
subroutine ice_proc(this)
class(ice_type)::this
end subroutine ice_proc
subroutine ice_sub()
type(ice_type),dimension(2)::ice_array
--- Comment #8 from Kyle dot D dot Moffett at boeing dot com 2010-05-20
12:19 ---
Created an attachment (id=20708)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20708action=view)
Assembled tc.c output from Debian-built powerpc-linux-gnuspe-gcc 4.4.4
--
--
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=44203
--- Comment #2 from borntraeger at de dot ibm dot com 2010-05-20 12:28
---
Created an attachment (id=20709)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20709action=view)
new version of the fix.
There is actually a second bug :-(
We not only have to replace step with stepsize
--- Comment #9 from Kyle dot D dot Moffett at boeing dot com 2010-05-20
12:29 ---
Created an attachment (id=20710)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20710action=view)
Assembled tc.c output from Debian-built powerpc-linux-gnuspe-gcc 4.4.2
--
--- Comment #10 from Kyle dot D dot Moffett at boeing dot com 2010-05-20
12:37 ---
Ok, it looks like the bug was introduced in the 4.4 branch between 4.4.2 and
4.4.4, because my old GCC 4.4.2 compiler works, but the 4.4.4 I built yesterday
after I noticed this report does not.
If
--- Comment #17 from rguenth at gcc dot gnu dot org 2010-05-20 13:24
---
It is actually the scheduler that breaks the testcase. Easier to look at
is -O2 -fwhole-program. -fno-schedule-insns2 fixes it (as well as
-fno-tree-pre
or -fno-tree-dominator-opts, both of which are necessary
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-20 13:27 ---
So, we have:
bb 3:
[pr44205.c : 7:11] i.1_2 = i;
[pr44205.c : 7:10] if (i.1_2 != 0)
goto bb 4;
else
goto bb 5;
bb 4:
[pr44205.c : 8:4] i = 0;
goto bb 6;
bb 5:
[pr44205.c : 10:4] i = 1;
bb 6:
--- Comment #1 from redi at gcc dot gnu dot org 2010-05-20 13:31 ---
(In reply to comment #0)
This would allow reducing this (infamous) list:
-W -Wall -Wextra -Wstrict-aliasing=2 -Wfloat-equal -Wundef -Wconversion
-Winline -Wmissing-field-initializers -Wshadow -Wcast-align -Wformat=2
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-05-20 13:33
---
Also have one tweak to do for blank STOP which I will fix shortly and add some
test cases.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43851
--- Comment #11 from pault at gcc dot gnu dot org 2010-05-20 13:51 ---
(In reply to comment #10)
Am I right in thinking that -fwhole-file could be enabled by default, if this
PR were to be fixed? (The appropriate changes in the testsuite would have to
be mad too.)
Paul
--
module ice_module
type :: B_type
class(A_type),pointer :: A_comp ! A_type is not yet defined
end type B_type
type :: A_type
contains
procedure :: A_proc
end type A_type
contains
subroutine A_proc(this)
class(A_type),target,intent(inout) :: this
end subroutine
--- Comment #18 from jason at gcc dot gnu dot org 2010-05-20 14:00 ---
Unassigning myself.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from jason at gcc dot gnu dot org 2010-05-20 14:01 ---
And changing component to rtl-opt.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from dje at gcc dot gnu dot org 2010-05-20 14:25 ---
Has anyone tested if generating an instruction sequence that uses the carry bit
actually improves performance on modern POWER processors? It reduces the
number of instructions, which is good when optimizing for size,
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-20 14:33 ---
A similar example:
$ cat conversion.f90
REAL(8), PARAMETER :: h = HUGE(0.0_8)
real*4 x
data x / h /
end
$ gfortran-svn -Wall conversion.f90
conversion.f90:1.28:
REAL(8), PARAMETER :: h = HUGE(0.0_8)
module ice_module
type :: a_type
end type a_type
type,extends(a_type),abstract :: b_type
end type b_type
type,extends(b_type) :: c_type
end type c_type
end module ice_module
f951: interner Compiler-Fehler: in ensure_not_abstract, bei
fortran/resolve.c:10559
--
Summary:
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-20 14:44 ---
Created an attachment (id=20711)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20711action=view)
gcc46-pr44205.patch
Doing it at gimplification time would be actually very hard, we only create the
continue label
--- Comment #9 from joakim dot tjernlund at transmode dot se 2010-05-20
14:47 ---
(In reply to comment #8)
Has anyone tested if generating an instruction sequence that uses the carry
bit
actually improves performance on modern POWER processors? It reduces the
number of
--- Comment #4 from hubicka at gcc dot gnu dot org 2010-05-20 14:57 ---
Subject: Bug 44197
Author: hubicka
Date: Thu May 20 14:57:27 2010
New Revision: 159629
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159629
Log:
PR middle-end/44197
* varpool.c
--- Comment #2 from eric dot estievenart at free dot fr 2010-05-20 15:06
---
-W is a synonym for -Wextra, so it is pointless to use both
This perfectly illustrates the problem; I have already spend hours digging
into the manual, what I attempted was to have as much warnings as
--- Comment #17 from jason at gcc dot gnu dot org 2010-05-20 15:13 ---
Hmm...I tried reverting the change to functional::swap, but all the libstdc++
tests still pass on x86_64-linux, and I haven't been able to write a failing
testcase either. Anyone else have a testcase that still
--- Comment #18 from rguenther at suse dot de 2010-05-20 15:17 ---
Subject: Re: Revisit std::function for aliasing issues
and efficiency
On Thu, 20 May 2010, jason at gcc dot gnu dot org wrote:
--- Comment #17 from jason at gcc dot gnu dot org 2010-05-20 15:13
---
--- Comment #3 from spop at gcc dot gnu dot org 2010-05-20 15:30 ---
Subject: Bug 44185
Author: spop
Date: Thu May 20 15:29:40 2010
New Revision: 159630
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159630
Log:
Fix PR44185: new prefetch test failures.
2010-05-20 Changpeng Fang
--- Comment #4 from spop at gcc dot gnu dot org 2010-05-20 15:30 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #19 from jason at gcc dot gnu dot org 2010-05-20 15:40 ---
Aha. That sounds good to me; I don't expect your testcase to work, because it
doesn't involve a char buffer. The copy does need to use the object
representation, but I think the new-expression should be undefined
--- Comment #20 from rguenther at suse dot de 2010-05-20 15:44 ---
Subject: Re: Revisit std::function for aliasing issues
and efficiency
On Thu, 20 May 2010, jason at gcc dot gnu dot org wrote:
--- Comment #19 from jason at gcc dot gnu dot org 2010-05-20 15:40
---
Aha.
--- Comment #3 from jan dot kratochvil at redhat dot com 2010-05-20 16:03
---
No regressions for FSF GDB HEAD x86_64-linux-gnu with FSF GCC HEAD.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44205
--- Comment #3 from redi at gcc dot gnu dot org 2010-05-20 16:14 ---
(In reply to comment #2)
-W is a synonym for -Wextra, so it is pointless to use both
This perfectly illustrates the problem; I have already spend hours digging
Then I have misunderstood the problem. How does this
--- Comment #9 from pthaugen at gcc dot gnu dot org 2010-05-20 16:23
---
Spec testing went fine, differences in the noise range.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-20 16:25 ---
Patch:
http://gcc.gnu.org/ml/fortran/2010-05/msg00242.html
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jakub at gcc dot gnu dot org 2010-05-20 16:31 ---
Have you also bootstrapped/regtested the patch? I can do so (easily for 4.4
branch, with more effort for the trunk), but haven't done that yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-20 16:35 ---
Subject: Bug 44178
Author: jakub
Date: Thu May 20 16:34:43 2010
New Revision: 159632
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159632
Log:
PR debug/44178
* haifa-sched.c
--- Comment #21 from jason at gcc dot gnu dot org 2010-05-20 16:49 ---
The alias_set_subset_of change isn't in 4.5? Then that's not what's making the
libstdc++ function tests pass with the swap change reverted...:)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-20 16:59 ---
Subject: Bug 44178
Author: jakub
Date: Thu May 20 16:58:52 2010
New Revision: 159634
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159634
Log:
PR debug/44178
* haifa-sched.c
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-20 17:00 ---
Subject: Bug 43521
Author: jakub
Date: Thu May 20 17:00:32 2010
New Revision: 159635
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159635
Log:
PR debug/43521
* decl.c (start_java_method): Set
--- Comment #5 from jakub at gcc dot gnu dot org 2010-05-20 17:01 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-20 17:01 ---
A proper come-on-and-pick-up testcase would be nice ...
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2010-05-20 17:04 ---
The manual documents what is enabled by -Wall and -Wextra and all other groups
options. We will accept patches fixing any missing/mistaken entries. You could
also propose some warnings to be moved to Wextra. Getting
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-20 17:06 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from ro at gcc dot gnu dot org 2010-05-20 17:15 ---
Initial patch posted for COMDAT group with Sun as. Will require an updated
configure test to work on SPARC, though.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from meissner at gcc dot gnu dot org 2010-05-20 17:39
---
Fix checked in on March 26, 2010.
--
meissner at gcc dot gnu dot org changed:
What|Removed |Added
If you have code that does division by a constant that can be auto vectorized
by the compiler, the compiler does not convert the division to multiplication
by the reciprocal if -freciprocal-math (or -ffast-math), but instead does the
division.
The bug is in fold-const.c near line 11254, where the
--- Comment #21 from dje at gcc dot gnu dot org 2010-05-20 17:52 ---
I tested the patch from comment #14 on top of the DECL_PRESERVE_P patch from PR
44132, which was necessary to get back to a sane level of C++ and libgomp
failures on AIX. The DECL_DLLIMPORT_P and DECL_ATTRIBUTES patch
The following code raise undefined reference link errors:
toto.C:(.text+0x10): undefined reference to `A::a'
toto.C:(.text+0x18): undefined reference to `B::a'
The code:
struct A {
static const int a = 0;
};
struct B {
static const int a = 1;
};
int main() {
bool b = true;
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-20 17:53 ---
*** This bug has been marked as a duplicate of 42101 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-05-20 17:53
---
*** Bug 44215 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pthaugen at gcc dot gnu dot org 2010-05-20 17:59
---
No I didn't bootstrap/regtest. I can take care of trunk if you want to do 4.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199
--- Comment #1 from meissner at gcc dot gnu dot org 2010-05-20 18:00
---
Actually in looking at it further, I was wrong in the initial claim. Auto
vectorization now handles division by a constant. Explicit vectors like
PowerPC (and probably SPU) do show the problem.
--
--- Comment #2 from meissner at gcc dot gnu dot org 2010-05-20 18:02
---
Created an attachment (id=20712)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20712action=view)
Example program that shows the issue on powerpc.
Compile with -mcpu=power7 on powerpc.
--
--- Comment #5 from jason at gcc dot gnu dot org 2010-05-20 18:14 ---
Fixed for 4.3.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Since the introduction of the configure check for the --no-merge-exidx-entries
linker option, all libjava tests fail on IRIX 6.5:
output is:
(null): WARNING 1 : Unknown option: -no-merge-exidx-entries (ignored).
FAIL: linking PR9577
The problem is that the SGI ld warns about unknown options
--- Comment #1 from ro at gcc dot gnu dot org 2010-05-20 18:23 ---
Paolo, do you happen to have an idea how to handle this cleanly?
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jakub at gcc dot gnu dot org 2010-05-20 18:23 ---
If you could, it would be very much appreciated. Starting 4.4
bootstrap/regtest now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199
--- Comment #2 from ro at gcc dot gnu dot org 2010-05-20 18:26 ---
This is not an enhancement, but simply a bug: the testsuite should use the
built
libraries, not some version that happens (or not) to be installed on the
system.
--
ro at gcc dot gnu dot org changed:
What
On Solaris 11/x86 with Sun as, two 64-bit libgomp testcases fail:
FAIL: libgomp.c/atomic-2.c (test for excess errors)
WARNING: libgomp.c/atomic-2.c compilation failed to produce executable
FAIL: libgomp.c/atomic-5.c (test for excess errors)
WARNING: libgomp.c/atomic-5.c compilation failed to
1 - 100 of 147 matches
Mail list logo
