[Bug testsuite/40532] FAIL: gcc.dg/builtins-65.c (test for excess errors)
--- Comment #5 from ubizjak at gmail dot com 2009-06-25 07:26 --- (In reply to comment #2) Can you put HAVE_C99_RUNTIME around problematic conversions (just copy the approach from builtins-18.c) ? Attached diff. However, there's still a call left to linK_error. This is due to the fact that your libm provides logb and ilogb. However, according to linux mapages, these are C99 functions. Your target doesn't define TARGET_C99_FUNCTIONS, so optimizer does not recognize logb and ilogb as functions that can be converted. I will simply disable builtins-65.c for non-C99 targets -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-25 07:26:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40532
[Bug testsuite/40532] FAIL: gcc.dg/builtins-65.c (test for excess errors)
--- Comment #6 from ubizjak at gmail dot com 2009-06-25 07:33 ---
(In reply to comment #5)
I will simply disable builtins-65.c for non-C99 targets
... like this:
Index: builtins-65.c
===
--- builtins-65.c (revision 148916)
+++ builtins-65.c (working copy)
@@ -1,5 +1,6 @@
/* { dg-do link } */
/* { dg-options -O2 -ffast-math } */
+/* { dg-require-effective-target c99_runtime } */
extern int ilogbf (float);
extern float logbf (float);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40532
[Bug middle-end/40525] if conversion (in dead_or_predicable) fails for targets with limited conditional execution support
--- Comment #5 from steven at gcc dot gnu dot org 2009-06-25 08:17 ---
Tentative patch:
Index: ifcvt.c
===
--- ifcvt.c (revision 148927)
+++ ifcvt.c (working copy)
@@ -3780,6 +3780,8 @@
basic_block other_bb, basic_block new_dest, int reversep)
{
rtx head, end, jump, earliest = NULL_RTX, old_dest, new_label = NULL_RTX;
+ /* Number of pending changes. */
+ int n_validated_changes = 0;
jump = BB_END (test_bb);
@@ -3849,13 +3851,15 @@
}
if (! cond_exec_process_insns ((ce_if_block_t *)0, head, end, cond,
-prob_val, 0))
- goto cancel;
-
+prob_val, 0)
+ || ! verify_changes (0))
+ cancel_changes (0);
+ n_validated_changes = num_validated_changes ();
earliest = jump;
}
- else
#endif
+ /* Try the NCE path if the CE path did not result in any changes. */
+ if (n_validated_changes 0)
{
/* In the non-conditional execution case, we have to verify that there
are no trapping operations, no calls, no references to memory, and
@@ -3995,8 +3999,10 @@
goto cancel;
}
- if (! apply_change_group ())
-return FALSE;
+ if (verify_changes (n_validated_changes))
+confirm_change_group ();
+ else
+goto cancel;
if (other_bb != new_dest)
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40525
[Bug target/34163] [4.3/4.4/4.5 Regression] 10% performance regression since Nov 1 on Polyhedron's NF on AMD64
--- Comment #14 from ubizjak at gmail dot com 2009-06-25 08:25 --- (In reply to comment #13) Predictive commoning does exactly what you want. It is not effective for the testcase in Comment #9. The dumps for innermost loop are the same for -O2 -funroll-loops [-fpredictive-commoning]: .L6: movss (%rsi), %xmm9 addl$4, %r8d mulss (%rcx), %xmm9 movss (%rdx), %xmm8 movss 4(%rdx), %xmm6 movss 8(%rdx), %xmm4 movss 12(%rdx), %xmm2 subss %xmm9, %xmm8 mulss 0(%rbp), %xmm8 movss %xmm8, (%rdx) movss 4(%rsi), %xmm7 mulss 4(%rcx), %xmm7 subss %xmm7, %xmm6 mulss 4(%rbp), %xmm6 movss %xmm6, 4(%rdx) movss 8(%rsi), %xmm5 mulss 8(%rcx), %xmm5 subss %xmm5, %xmm4 mulss 8(%rbp), %xmm4 movss %xmm4, 8(%rdx) movss 12(%rsi), %xmm3 addq$16, %rsi mulss 12(%rcx), %xmm3 addq$16, %rcx subss %xmm3, %xmm2 mulss 12(%rbp), %xmm2 addq$16, %rbp movss %xmm2, 12(%rdx) addq$16, %rdx cmpl%r9d, %r8d jne .L6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
[Bug target/34163] [4.3/4.4/4.5 Regression] 10% performance regression since Nov 1 on Polyhedron's NF on AMD64
--- Comment #15 from ubizjak at gmail dot com 2009-06-25 08:31 --- (In reply to comment #14) (In reply to comment #13) Predictive commoning does exactly what you want. Predictive commoning failed: no suitable chains -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
[Bug fortran/40549] New: MinGW Fortran patches for libgfortran/Makefile.{in,am}
MinGW (http://www.mingw.org/) now has an official 4.4.0 release - and thus
finally a 4.x release. If one looks at the release,
http://sourceforge.net/project/showfiles.php?group_id=2435package_id=241304
one finds a tar ball (gcc-4.4.0-mingw32-src-2.tar.gz) with patches.
For Fortran, I found the following; we should consider applying them - after
understanding whether the changes make sense.
There are two changes:
a) -no-undefined
b) LIBOBJDIR=
* * *
a) -no-undefined option
For MinGW the -no-undefined is set, cf.
http://www.gnu.org/software/libtool/manual/html_node/libtool-script-contents.html#index-allow_005fundefined_005fflag-358
and more readable:
http://lists.gnupg.org/pipermail/gcrypt-devel/2006-June/000966.html
Doing a grep shows that it is already set for libgomp/Makefile.in and
libssp/Makefile.in.
MinGW sets is additionally for libgfortran, libffi, libjava, libobjc,
libstdc++v3/{,lib*/}.
b) LIBOBJDIR=
See:
http://www.gnu.org/software/autoconf/manual/html_node/AC_005fLIBOBJ-vs-LIBOBJS.html.
I think this part of the patch is a side effect of using autoconf 1.10+ instead
of autoconf 1.9.6, which is suggested for GCC development.
Note: An analogous patch was accepted for libgomp by a build-machinery
maintainer,
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01509.html
---
Index: libgfortran/Makefile.am
===
--- libgfortran/Makefile.am (revision 145042)
+++ libgfortran/Makefile.am (working copy)
@@ -17,7 +17,9 @@ LTLDFLAGS = $(shell $(SHELL) $(top_srcdi
toolexeclib_LTLIBRARIES = libgfortran.la
libgfortran_la_LINK = $(LINK)
-libgfortran_la_LDFLAGS = -version-info `grep -v '^\#'
$(srcdir)/libtool-version` $(LTLDFLAGS) -lm $(extra_ldflags_libgfortran)
$(version_arg)
+libgfortran_la_LDFLAGS = -version-info `grep -v '^\#'
$(srcdir)/libtool-version` \
+$(LTLDFLAGS) -lm $(extra_ldflags_libgfortran) \
+$(version_arg) -no-undefined
myexeclib_LTLIBRARIES = libgfortranbegin.la
myexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)
Index: libgfortran/Makefile.in
===
--- libgfortran/Makefile.in (revision 146010)
+++ libgfortran/Makefile.in (working copy)
@@ -37,6 +37,7 @@ POST_UNINSTALL = :
build_triplet = @build@
host_triplet = @host@
target_triplet = @target@
+LIBOBJDIR =
# dummy sources for libtool
@onestep_t...@am__append_1 = libgfortran_c.c libgfortran_f.f90
@@ -953,7 +954,10 @@ gcc_version := $(shell cat $(top_srcdir)
LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
toolexeclib_LTLIBRARIES = libgfortran.la
libgfortran_la_LINK = $(LINK)
-libgfortran_la_LDFLAGS = -version-info `grep -v '^\#'
$(srcdir)/libtool-version` $(LTLDFLAGS) -lm $(extra_ldflags_libgfortran)
$(version_arg)
+libgfortran_la_LDFLAGS = -version-info `grep -v '^\#'
$(srcdir)/libtool-version` \
+$(LTLDFLAGS) -lm $(extra_ldflags_libgfortran) \
+$(version_arg) -no-undefined
+
myexeclib_LTLIBRARIES = libgfortranbegin.la
myexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)
libgfortranbegin_la_SOURCES = fmain.c
--
Summary: MinGW Fortran patches for libgfortran/Makefile.{in,am}
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40549
[Bug tree-optimization/2462] restrict implementation bug
--- Comment #6 from ubizjak at gmail dot com 2009-06-25 08:58 --- Oops... -- ubizjak at gmail dot com changed: What|Removed |Added Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2462
[Bug target/34163] [4.3/4.4/4.5 Regression] 10% performance regression since Nov 1 on Polyhedron's NF on AMD64
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-06-25 09:01
---
Executing predictive commoning without unrolling.
with -m32. One of the cases SCEV is confused about pointer-plus offsets
being sizetype:
(Data Ref:
stmt: (*x_58(D))[D.1627_54] = D.1638_71;
ref: (*x_58(D))[D.1627_54];
base_object: (*x_58(D))[0];
Access function 0: {(integer(kind=8)) i_43 + -1, +, 1}_1
Access function 1: 0B
vs.
(Data Ref:
stmt: D.1634_67 = (*x_58(D))[D.1632_62];
ref: (*x_58(D))[D.1632_62];
base_object: (*x_58(D))[0];
Access function 0: {(integer(kind=8)) (i_43 + -1) + -1, +, 1}_1
Access function 1: 0B
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
[Bug target/40537] wrong instr. dependency with some SSE intrinsics
--- Comment #9 from ubizjak at gmail dot com 2009-06-25 09:03 --- *** This bug has been marked as a duplicate of 21920 *** -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40537
[Bug c/21920] aliasing violations
--- Comment #141 from ubizjak at gmail dot com 2009-06-25 09:03 --- *** Bug 40537 has been marked as a duplicate of this bug. *** -- ubizjak at gmail dot com changed: What|Removed |Added CC||gael dot guennebaud at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug tree-optimization/36891] [4.3 Regression] ICE with vector division and -ffast-math and LIM
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-06-25 09:44 --- Subject: Bug 36891 Author: rguenth Date: Thu Jun 25 09:44:12 2009 New Revision: 148939 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148939 Log: 2009-06-25 Richard Guenther rguent...@suse.de Backport from mainline 2009-01-12 Jakub Jelinek ja...@redhat.com PR c/32041 * c-parser.c (c_parser_postfix_expression): Allow `-' in offsetof member-designator, handle it as `[0].'. cp/ * parser.c (cp_parser_builtin_offsetof): Allow `-' in offsetof member-designator, handle it as `[0].'. * gcc.dg/pr32041.c: New test. * g++.dg/parse/offsetof9.C: New test. 2008-09-28 Andrew Pinski andrew_pin...@playstation.sony.com Kaushal Kantawala kaushal_kantaw...@playstation.sony.com PR tree-optimization/36891 * tree-ssa-loop-im.c (rewrite_reciprocal): Set DECL_GIMPLE_REG_P on the newly created variable. Create a VECTOR_CST of all 1s for vector types. * gcc.dg/torture/pr36891.c: New testcase. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/parse/offsetof9.C branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr32041.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr36891.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/c-parser.c branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/parser.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-ssa-loop-im.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36891
[Bug c/32041] [4.3 Regression] offsetof buglet
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-06-25 09:44 --- Subject: Bug 32041 Author: rguenth Date: Thu Jun 25 09:44:12 2009 New Revision: 148939 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148939 Log: 2009-06-25 Richard Guenther rguent...@suse.de Backport from mainline 2009-01-12 Jakub Jelinek ja...@redhat.com PR c/32041 * c-parser.c (c_parser_postfix_expression): Allow `-' in offsetof member-designator, handle it as `[0].'. cp/ * parser.c (cp_parser_builtin_offsetof): Allow `-' in offsetof member-designator, handle it as `[0].'. * gcc.dg/pr32041.c: New test. * g++.dg/parse/offsetof9.C: New test. 2008-09-28 Andrew Pinski andrew_pin...@playstation.sony.com Kaushal Kantawala kaushal_kantaw...@playstation.sony.com PR tree-optimization/36891 * tree-ssa-loop-im.c (rewrite_reciprocal): Set DECL_GIMPLE_REG_P on the newly created variable. Create a VECTOR_CST of all 1s for vector types. * gcc.dg/torture/pr36891.c: New testcase. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/parse/offsetof9.C branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr32041.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr36891.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/c-parser.c branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/parser.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-ssa-loop-im.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32041
[Bug tree-optimization/36891] [4.3 Regression] ICE with vector division and -ffast-math and LIM
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-06-25 09:45 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.4.0 4.3.0 4.1.1 |4.4.0 4.3.0 4.3.3 4.1.1 Known to work|4.0.1 4.4.0 |4.0.1 4.3.4 4.4.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36891
[Bug c/32041] [4.3 Regression] offsetof buglet
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-06-25 09:45 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.0.0 4.3.2 |4.0.0 4.3.2 4.3.3 Known to work|3.3.6 3.4.6 4.4.0 |3.3.6 3.4.6 4.3.4 4.4.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32041
[Bug tree-optimization/2462] restrict implementation bug
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-06-25 10:28 --- With the new restrict implementation baz() works and all the rest would work as well if the calls to link_error () would not cause the malloced memory to be clobbered. The artifact here is that malloced memory is considered global (we are not allowed to remove stores to it). But this is all unrelated to restrict support which should be properly fixed now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2462
[Bug target/38900] ICE: unable to find a register to spill
--- Comment #4 from ivmai at mail dot ru 2009-06-25 10:31 --- Bug confirmed in mingw-w64 gcc v4.5.0 (32-bit target). Bug also observed in MinGW gcc v3.4.5 and v4.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug middle-end/40493] [4.5 Regression] New SRA miscompiled binutils
--- Comment #14 from jamborm at gcc dot gnu dot org 2009-06-25 10:38 --- Subject: Bug 40493 Author: jamborm Date: Thu Jun 25 10:38:13 2009 New Revision: 148941 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148941 Log: 2009-06-25 Martin Jambor mjam...@suse.cz PR tree-optimization/40493 * tree-sra.c (sra_modify_expr): Correct BIT_FIELD_REF argument numbers. (enum unscalarized_data_handling): New type. (handle_unscalarized_data_in_subtree): Return what has been done. (load_assign_lhs_subreplacements): Handle left flushes differently. (sra_modify_assign): Use unscalarized_data_handling, simplified condition determining whether to remove the statement. * testsuite/gcc.c-torture/execute/pr40493.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr40493.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40493
[Bug c/14050] [DR289] c99 restrict doesn't work in abs declarator
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-06-25 11:10 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14050
[Bug target/15623] nop insertion does not look see restrict pointers
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-06-25 11:14 --- I don't have nops on either of the two functions with trunk. And -minsert-sched-nops doesn't exist there either. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15623
[Bug c/35503] Warning about restricted pointers?
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-25 11:15 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-25 11:15:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35503
[Bug middle-end/38012] vectorizer ignores 'restrict'
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-25 11:19 ---
double* __restrict__ va;
const double* __restrict__ vb;
for(unsigned i=0; ia.size(); i++) {
va = a[i];
vb = b[i];
(*va) = (*vb) *coef;
}
this only says that a[i] and b[i] do not alias in one loop iteration, it
doesn't
cover cross-iteration dependencies that the vectorizer needs.
double* __restrict__ va = a;
const double* __restrict__ vb = b;
for(unsigned i=0; ia.size(); i++) {
va[i] = vb[i] *coef;
}
will work.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38012
[Bug c/32041] [4.3 Regression] offsetof buglet
--- Comment #10 from mikpe at it dot uu dot se 2009-06-25 12:12 ---
(In reply to comment #9)
Fixed.
The gcc-4.3 backport or PR32041 to c-parser.c adds an assignment to `loc'. The
mainline version needed that for build_array_ref, but in 4.3 build_array_ref
does not take a loc parameter so the assignment is redundant. Suggested fixup:
--- gcc-4.3-pr32041/gcc/c-parser.c.~1~ 2009-06-25 14:01:22.0 +0200
+++ gcc-4.3-pr32041/gcc/c-parser.c 2009-06-25 14:06:20.0 +0200
@@ -5353,7 +5353,6 @@ c_parser_postfix_expression (c_parser *p
{
if (c_parser_next_token_is (parser, CPP_DEREF))
{
- loc = c_parser_peek_token (parser)-location;
offsetof_ref = build_array_ref (offsetof_ref,
integer_zero_node);
goto do_dot;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32041
[Bug c++/40550] New: Segmentation fault caused by alignment error in sse code
The following code is misscompiled on 32 bit machines using gcc-4.4.0,
gcc-4.3.3 and gcc-4.3.2 with the -msse switch
===
typedef float v2sf __attribute__ ((vector_size (2 * sizeof(float;
int main()
{
v2sf a = {1.0, 0.0};
v2sf b = {0.0, 1.0};
v2sf d;
d = a + b;
return 0;
}
=
The program runs fine without the -msse switch but segfaults as soon as
compiled with -msse.
The reason for this is the use of the movaps instruction on a seemingly
unaligned chunk of memory.
As a note, the same program compiles fine, if doubles are used instead of
floats.
--
Summary: Segmentation fault caused by alignment error in sse code
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tux008 at googlemail dot com
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40550
[Bug c/32041] [4.3 Regression] offsetof buglet
--- Comment #11 from rguenther at suse dot de 2009-06-25 12:25 ---
Subject: Re: [4.3 Regression] offsetof buglet
On Thu, 25 Jun 2009, mikpe at it dot uu dot se wrote:
--- Comment #10 from mikpe at it dot uu dot se 2009-06-25 12:12 ---
(In reply to comment #9)
Fixed.
The gcc-4.3 backport or PR32041 to c-parser.c adds an assignment to `loc'. The
mainline version needed that for build_array_ref, but in 4.3 build_array_ref
does not take a loc parameter so the assignment is redundant. Suggested fixup:
--- gcc-4.3-pr32041/gcc/c-parser.c.~1~ 2009-06-25 14:01:22.0 +0200
+++ gcc-4.3-pr32041/gcc/c-parser.c 2009-06-25 14:06:20.0 +0200
@@ -5353,7 +5353,6 @@ c_parser_postfix_expression (c_parser *p
{
if (c_parser_next_token_is (parser, CPP_DEREF))
{
- loc = c_parser_peek_token (parser)-location;
offsetof_ref = build_array_ref (offsetof_ref,
integer_zero_node);
goto do_dot;
Thanks for noticing, I'll fix this up.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32041
[Bug c++/40550] Segmentation fault caused by alignment error in sse code
--- Comment #1 from tux008 at googlemail dot com 2009-06-25 12:27 --- Created an attachment (id=18067) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18067action=view) This program segfaults if compiled with gcc-4.4.0 and -msse on i686 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40550
[Bug c++/40550] Segmentation fault caused by alignment error in sse code
--- Comment #2 from tux008 at googlemail dot com 2009-06-25 12:28 --- Created an attachment (id=18068) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18068action=view) corresponding ii-file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40550
[Bug target/40550] Segmentation fault caused by alignment error in sse code
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-25 12:36 ---
Confirmed. With 4.4 the issue seems to be different as we use mov{l,h}ps but
access beyond the stack clobbering the return location. Oops. Doesn't
segfault with -fstack-protector.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||uros at gcc dot gnu dot org,
||rguenth at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Component|c++ |target
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2009-06-25 12:36:43
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40550
[Bug middle-end/38751] [4.3 Regression] odd performance regression with -Os
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-06-25 12:39 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38751
[Bug middle-end/38751] [4.3 Regression] odd performance regression with -Os
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-25 12:39 --- Subject: Bug 38751 Author: rguenth Date: Thu Jun 25 12:39:01 2009 New Revision: 148943 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148943 Log: 2009-06-25 Richard Guenther rguent...@suse.de Backport from mainline 2009-01-07 Richard Guenther rguent...@suse.de PR middle-end/38751 * fold-const.c (extract_muldiv): Remove obsolete comment. (fold_plusminus_mult_expr): Undo MINUS_EXPR to PLUS_EXPR canonicalization for the canonicalization. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/fold-const.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38751
[Bug libgcj/38396] [4.3 Regression] ecj1 linked against both -lgcj and -lgcj_bc
--- Comment #29 from rguenth at gcc dot gnu dot org 2009-06-25 12:40 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail|4.3.2 |4.3.2 4.3.3 Known to work|4.4.0 |4.3.4 4.4.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38396
[Bug libgcj/38396] [4.3 Regression] ecj1 linked against both -lgcj and -lgcj_bc
--- Comment #30 from rguenth at gcc dot gnu dot org 2009-06-25 12:40 --- Subject: Bug 38396 Author: rguenth Date: Thu Jun 25 12:40:30 2009 New Revision: 148944 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148944 Log: 2009-06-25 Richard Guenther rguent...@suse.de Backport from mainline 2008-12-19 Jakub Jelinek ja...@redhat.com PR libgcj/38396 * configure.ac (use_libgcj_bc): Set to no if not enable_shared. (LIBGCJ_SPEC): Use -lgcj instead of -lgcj_bc even for -static or -static-libgcj. * Makefile.am (ecjx_SOURCES): Add ecjx.cc. (ecjx_LDADD): Don't add libgcj.la when NATIVE USE_LIBBGCJ_BC. * ecjx.cc: New file. * Makefile.in: Regenerated. * configure: Regenerated. 2009-01-11 Matthias Klose d...@ubuntu.com * Makefile.am (ecjx_LDADD): Add $(extra_ldflags). * Makefile.in: Regenerate. Added: branches/gcc-4_3-branch/libjava/ecjx.cc Modified: branches/gcc-4_3-branch/libjava/ChangeLog branches/gcc-4_3-branch/libjava/Makefile.am branches/gcc-4_3-branch/libjava/Makefile.in branches/gcc-4_3-branch/libjava/configure branches/gcc-4_3-branch/libjava/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38396
[Bug fortran/40551] New: Wrong code due to missing copy-in/copy-out stried array to assumed-size dummy
Bug reported (with longer test case) by Maciej Zwierzycki at http://gcc.gnu.org/ml/fortran/2009-06/msg00254.html The following program should produce 1 2 -42 -42 but it produces 1 -42 2 -42 For a(1,:) = func() gfortran decides to pass result value by reference - and uses an array descriptor for this (why?): func (struct array1_integer(kind=4) __result) and func (parm.7); However, as func(2) is an explicit-shaped array, it should be contiguous and thus for call sub(func) simply the address is passed, ignoring the stride: sub ((integer(kind=4)[0:] *) parm.4.data); At some place the copy-in/copy-out must happen. Actually, I had assumed that already the call to func would cause a temporary be created. That's actually what happens in case of g95: SC1 = *func_ ();; Test case: integer :: a(2,2) a = -42 a(1,:) = func() print *,a contains function func() integer :: func(2) call sub(func) end function func subroutine sub(a) integer :: a(2) a = [1,2] end subroutine end -- Summary: Wrong code due to missing copy-in/copy-out stried array to assumed-size dummy Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 40443 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40551
[Bug fortran/40551] Wrong code due to missing copy-in/copy-out stried array to assumed-size dummy
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-25 13:32 --- Fails with 4.3.x to 4.5.0 (In 4.1.x/4.2.x it also fails, but there no return value is set at all, i.e. one gets warning: Function does not return a value - and four times -42.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.1 4.5.0 4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40551
Re: Warning while building for win64
On Tue, Jun 23, 2009 at 3:39 AM, Nick Cliftonni...@redhat.com wrote: Hi, NightStrike wrote: When building a binutils where host=target=x86_64-w64-mingw32, I see the following warnings that should be cleaned up: ../../src/libiberty/md5.c: In function ‘md5_process_bytes’: ../../src/libiberty/md5.c:234:11: warning: cast from pointer to integer of different size Problems with the libiberty library should be forwarded to the gcc-bugs@gcc.gnu.org list rather than here. Mind you the libiberty maintainers do also happen to read this list, so you may well get a response to the actual problem. But officially the correct list to use is the gcc-bugs list. Thanks for the update. Replying to gcc-bugs instead. Can anyone on this new list help?
[Bug regression/40516] using --with-cloog and --with-ppl without specifying a location with = causes configuration errors
--- Comment #1 from nightstrike at gmail dot com 2009-06-25 13:58 --- I imagine this applies to any target, not just win64 targets. I can't change that setting, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40516
[Bug c/40528] Add a new ifunc attribute
--- Comment #7 from hjl dot tools at gmail dot com 2009-06-25 14:12 --- It is easier to support C++ with option 3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528
[Bug middle-end/40493] [4.5 Regression] New SRA miscompiled binutils
--- Comment #15 from jamborm at gcc dot gnu dot org 2009-06-25 14:21 --- I have checked out trunk 148941, compiled binutils with it (configured with --disable-werror), ran the testsuite and there were no failures. Thus I consider this fixed. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40493
[Bug fortran/40551] Wrong code due to missing copy-in/copy-out stried array to assumed-size dummy
--- Comment #2 from dominiq at lps dot ens dot fr 2009-06-25 14:21 --- The following program should produce 1 2 -42 -42 but it produces 1 -42 2 -42 You probably mean the opposite! If so, I confirm the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40551
[Bug fortran/40551] Wrong code due to missing copy-in/copy-out stried array to assumed-size dummy
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-25 15:06 --- Another example. The following two subroutines are essentially identical, except that one has an explicit interface and one an implicit interface. The only extra information the explicit interface provides is that the function takes no arguments. If one looks at the dumps, one finds: D.1548 = func (); and func (parm.1); which is surely incompatible. subroutine test1() integer :: array(2) external :: func integer :: func array = func() end subroutine test1 subroutine test2 integer :: array2(2) interface function func() integer :: func(2) end function func end interface array2 = func() end subroutine test2 -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-25 15:06:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40551
[Bug tree-optimization/2462] restrict implementation bug
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2009-06-25 15:31 --- (In reply to comment #7) With the new restrict implementation baz() works and all the rest would work as well if the calls to link_error () would not cause the malloced memory to be clobbered. The artifact here is that malloced memory is considered global (we are not allowed to remove stores to it). The intention for link_error was to just make it easier to write a test, not to prohibit optimization. Please feel free to adjust the code accordingly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2462
[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-06-25 15:37 --- Hmm, I'm getting somewhere with this. By compiling the g++ testsuite ptrflags.C case with --save-temps, manually hacking all the superfluous typeinfo stuff out, and re-assembling and linking it, I can turn a FAIL into a PASS, with all the typeinfo and related stuff being imported from the DLL. So I think typeinfo can be made to work, and work with both __GXX_MERGED_TYPEINFO_NAMES and __GXX_TYPEINFO_EQUALITY_INLINE. All I need to do is stop the compiler from emitting comdat definitions of items with vague linkage when they are dllimported, or perhaps make the linker prefer an import over a comdat section when the same symbol could be resolved by either. Or perhaps both. I think the linker fix is what you were suggesting when you said since if we depend on auto-import than we should treat dll imports thae same as static lib imports More later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
[Bug fortran/40551] Wrong code due to missing copy-in/copy-out stried array to assumed-size dummy
--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-25 15:43 --- (In reply to comment #3) Another example. Which is invalid. Mea culpa: A procedure ... shall have an explicit interface if ... (3) The procedure has a result that (a) is an array (That is something, -fwhole-file should be able to catch; currently it just gives an ICE. I failed to find the restriction to specify dimension in F77, but presumably I simply looked at the wrong place.) I see three possibilities: a) Returning a pointer instead of passing by the _result array descriptor by reference. (As g95 does. Fix in caller+callee) b) Doing the copy-in/copy-out in the called function (fix in callee) c) Passing an array descriptor, but one which is contiguous (fix in caller) d) Variant of A+C: Just pass a pointer and not an array descriptor the function Notes: (a) Means that there is only a single copy out. It will break the ABI, but that's anyway planned. (b) Means potentially many copy-in/copy-out. This might not be intended (some people use automatic arrays vs. assumed-shape arrays on purpose to decide whether a contiguous array or strides should be used - depending on the size and what the function does, either is faster). (c) Is a compromise - there is also only a single copy out. (d) Is a variant of (a) and (c); it save some space but I think only for little gain. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40551
[Bug rtl-optimization/40552] New: wrong-code with -fsched2-use-superblocks and exceptions
cat bug.cc
#include string
void f() {
throw 1;
}
struct Foo {
Foo(const std::string s);
std::string s;
};
Foo::Foo(const std::string s_)
: s(s_)
{
f();
}
int main() {
try {
Foo foo();
} catch (...) {
}
}
g++ -O2 -fsched2-use-superblocks bug.cc
./a.out
Aborted (core dumped)
(This program should exit normally.)
Backtrace:
#0 0x7fd3d9e9b065 in raise () from /lib/libc.so.6
#1 0x7fd3d9e9e153 in abort () from /lib/libc.so.6
#2 0x7fd3da1cdb41 in _Unwind_Resume () from /lib/libgcc_s.so.1
#3 0x00400a02 in Foo (this=0x7fffe2b81eb0, s...@0x4377) at bug.cc:16
...
I'm using SVN revision 148947 on linux x86_64.
--
Summary: wrong-code with -fsched2-use-superblocks and exceptions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at scarlet dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40552
[Bug fortran/40551] Wrong code due to missing copy-in/copy-out stried array to assumed-size dummy
--- Comment #5 from burnus at gcc dot gnu dot org 2009-06-25 16:04 --- I think I would go for option (b) of creating a new array descriptor, which is then used for copy out. The place where currently the creation of a temporary is prevented is: gfc_trans_arrayfunc_assign If the return symbol is assumed shape, deferred shape (pointer, allocatable) or the actual is known to be contiguous (whole array, which is not an assumed-shape/deferred-shape dummy) one can continue as is, otherwise one needs to pack the arrays. (Todo: Check that no copy in happens.) At some point, we need a contiguous check - also for F2008's CONTIGUOUS attribute. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40551
[Bug target/40550] Segmentation fault caused by alignment error in sse code
--- Comment #4 from ubizjak at gmail dot com 2009-06-25 17:09 ---
4.4 fixed movaps isse by calling ix86_expand_vector_move to generate unaligned
move.
The core of the problem is however in the middle end, where we expnd from:
main ()
{
vector float D.1414;
vector float D.1413;
vector float D.1412;
v2sf d;
v2sf b;
v2sf a;
int D.1407;
bb 2:
a = { 1.0e+0, 0.0 };
b = { 0.0, 1.0e+0 };
D.1412 = BIT_FIELD_REF a, 128, 0;
D.1413 = BIT_FIELD_REF b, 128, 0;
D.1414 = D.1412 + D.1413;
d = {D.1414};
D.1407 = 0;
return D.1407;
}
So, when BIT_FIELD_REF is expanded, we end at ix86_expand_vector_move through:
#0 ix86_expand_vector_move (mode=V4SFmode, operands=0x7fffd9e0) at
../../gcc-svn/branches/gcc-4_4-branch/gcc/config/i386/i386.c:12370
#1 0x008cbc3f in gen_movv4sf (operand0=0x72888100,
operand1=0x72888900) at
../../gcc-svn/branches/gcc-4_4-branch/gcc/config/i386/sse.md:194
#2 0x0050dc2f in emit_move_insn_1 (x=0x4c, y=0x72888900) at
../../gcc-svn/branches/gcc-4_4-branch/gcc/expr.c:3355
#3 0x0050df37 in emit_move_insn (x=0x72888100, y=0x72888900)
at ../../gcc-svn/branches/gcc-4_4-branch/gcc/expr.c:3443
#4 0x00512f0f in store_expr (exp=0x7297d820,
target=0x72888100, call_param_p=0, nontemporal=0 '\0') at
../../gcc-svn/branches/gcc-4_4-branch/gcc/expr.c:4779
#5 0x00505fd6 in expand_assignment (to=0x72a5e8c0,
from=0x7297d820, nontemporal=16 '\20') at
../../gcc-svn/branches/gcc-4_4-branch/gcc/expr.c:4395
#6 0x0050785f in expand_expr_real_1 (exp=0x77b7bb80, target=0x0,
tmode=value optimized out, modifier=EXPAND_NORMAL, alt_rtl=0x0) at
../../gcc-svn/branches/gcc-4_4-branch/gcc/expr.c:9234
#7 0x0050cd57 in expand_expr_real (exp=0x77b7bb80, target=value
optimized out, tmode=value optimized out, modifier=value optimized out,
alt_rtl=value optimized out) at
../../gcc-svn/branches/gcc-4_4-branch/gcc/expr.c:7125
Unfortunatelly, middle end wants to move:
(mem/c/i:V4SF (plus:SI (reg/f:SI 54 virtual-stack-vars)
(const_int -24 [0xffe8])) [0+0 S16 A32])
and V4SF is wrong mode for V2SF value that lives in memory. And finally, when
assigning the value to d, we fell off the stack trying to store V4SF to V2SF
slot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40550
[Bug target/40550] Segmentation fault caused by alignment error in sse code
--- Comment #5 from ubizjak at gmail dot com 2009-06-25 17:32 --- The problem is also present on 4.5.0. The executable won't segfault, because -O0 generates more temporaries on stack. However: xorps %xmm1, %xmm1 movlps 56(%esp), %xmm1 (*) movhps 64(%esp), %xmm1 xorps %xmm0, %xmm0 movlps 48(%esp), %xmm0 (**)movhps 56(%esp), %xmm0 addps %xmm1, %xmm0 (*) This slot is not initialized (**) This one belongs to a. -- ubizjak at gmail dot com changed: What|Removed |Added Known to fail||4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40550
[Bug middle-end/40550] Segmentation fault caused by alignment error in sse code
--- Comment #6 from ubizjak at gmail dot com 2009-06-25 17:49 --- Middle end. -- ubizjak at gmail dot com changed: What|Removed |Added Component|target |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40550
[Bug target/15623] nop insertion does not look see restrict pointers
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-06-25 17:57 --- Well the nop insertion is not working any more ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2006-10-22 23:07:55 |2009-06-25 17:57:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15623
[Bug middle-end/40553] New: wrong result(nan) using vector extensions on athlon-xp
I'm using the code from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40550
and added output of the result vector:
#include cstdio
typedef float v2sf __attribute__ ((vector_size (2 * sizeof(float;
int main()
{
v2sf a = {1.0, 0.0};
v2sf b = {0.0, 1.0};
v2sf d;
d = a + b;
float* dp = (float*) d;
printf(%f %f \n, dp[0], dp[1]);
return 0;
}
the vector d contains (nan, nan) compiled with g++ -march=athlon-xp opposed to
(1,1) if compiled without flags. Looking through the generated assembler code I
found that the compiler happens to use the %mm registers. So for good measure I
added a call to femms() after the addition to flush the multimedia-state:
#include cstdio
typedef float v2sf __attribute__ ((vector_size (2 * sizeof(float;
int main()
{
v2sf a = {1.0, 0.0};
v2sf b = {0.0, 1.0};
v2sf d;
d = a + b;
float* dp = (float*) d;
__builtin_ia32_femms();
printf(%f %f \n, dp[0], dp[1]);
return 0;
}
et voila, the program gives the true answer. But as gcc is also rummaging
around in the SSE registers and seems to do the actual addition on the x87-FPU,
this might not be the true solution. Note that as in the other bug a double
version of this code works fine. Not also that optimized versions of this code
work too, but this seems due to optimizing the addition away.
--
Summary: wrong result(nan) using vector extensions on athlon-xp
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: CaptainSifff at gmx dot de
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40553
[Bug middle-end/40553] wrong result(nan) using vector extensions on athlon-xp
--- Comment #1 from CaptainSifff at gmx dot de 2009-06-25 18:50 --- Created an attachment (id=18069) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18069action=view) failing program using vector extensions -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40553
[Bug middle-end/40553] wrong result(nan) using vector extensions on athlon-xp
--- Comment #2 from CaptainSifff at gmx dot de 2009-06-25 18:51 --- Created an attachment (id=18070) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18070action=view) the intermediate source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40553
[Bug middle-end/40553] wrong result(nan) using vector extensions on athlon-xp
--- Comment #3 from CaptainSifff at gmx dot de 2009-06-25 18:51 --- Created an attachment (id=18071) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18071action=view) the generated assembly source by gcc-4.3.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40553
[Bug middle-end/40553] wrong result(nan) using vector extensions on athlon-xp
--- Comment #4 from CaptainSifff at gmx dot de 2009-06-25 18:55 --- As an additional note: if compiled with -m3dnow the program produces nans if compiled with -msse the program produces a segfault which seems to be due to the same alignment issue as in bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40550 -- CaptainSifff at gmx dot de changed: What|Removed |Added Component|target |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40553
[Bug target/38731] Local strings on the stack not aligned
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-06-25 19:00 --- Subject: Bug 38731 Author: pinskia Date: Thu Jun 25 19:00:26 2009 New Revision: 148948 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148948 Log: 2009-06-25 Andrew Pinski andrew_pin...@playstation.sony.com PR target/38731 * config/rs6000/rs6000.c (LOCAL_ALIGNMENT): Redefine to just use DATA_ALIGNMENT instead. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38731
[Bug target/38731] Local strings on the stack not aligned
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-06-25 19:01 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38731
[Bug target/15623] nop insertion does not look see restrict pointers
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-25 19:30 --- which makes this bug ... ??? dependent on a bug you're going to file? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15623
[Bug middle-end/40550] Segmentation fault caused by alignment error in sse code
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-06-25 19:32 --- D.1412 = BIT_FIELD_REF a, 128, 0; is certainly not the size of v2sf... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40550
Re: [Bug target/15623] nop insertion does not look see restrict pointers
Sent from my iPhone On Jun 25, 2009, at 12:30 PM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-25 19:30 --- which makes this bug ... ??? dependent on a bug you're going to file? Most likely closing as won't fix as this is not important for any newer ppcs. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --- --- -- Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15623
[Bug target/15623] nop insertion does not look see restrict pointers
--- Comment #7 from pinskia at gmail dot com 2009-06-25 19:33 --- Subject: Re: nop insertion does not look see restrict pointers Sent from my iPhone On Jun 25, 2009, at 12:30 PM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-25 19:30 --- which makes this bug ... ??? dependent on a bug you're going to file? Most likely closing as won't fix as this is not important for any newer ppcs. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --- --- -- Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15623 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15623
[Bug libfortran/40555] problem with libgfortran
--- Comment #1 from abidmuslim at gmail dot com 2009-06-26 02:09 --- Created an attachment (id=18072) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18072action=view) detail of error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40555
[Bug libfortran/40555] problem with libgfortran
--- Comment #2 from kargl at gcc dot gnu dot org 2009-06-26 02:27 --- Are you trying to build gcc in its source directory? Have you read http://gcc.gnu.org/install/? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40555
[Bug libfortran/40555] problem with libgfortran
--- Comment #3 from abidmuslim at gmail dot com 2009-06-26 03:00 --- Subject: Re: problem with libgfortran On Fri, Jun 26, 2009 at 10:58 AM, Abid Muslim Malik abidmus...@gmail.com wrote: I read the online install GCC document and other tips on line for installing GCC. I use the following to configure the enviorment ./configure --prefix=/home/myname/local The GMP and MPFR are already in the source directory. The installation document mentions that if they are, then one does not have to use --with-gmp and --with-mpfr. Are you trying to build gcc in its source directory? By source directory if you mean /gcc-4.4.0/ . Yes I am using make command in this directory after using configure as mentioned above. Thanks for your e-mail and time On Fri, Jun 26, 2009 at 10:27 AM, kargl at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #2 from kargl at gcc dot gnu dot org 2009-06-26 02:27 --- Are you trying to build gcc in its source directory? Have you read http://gcc.gnu.org/install/? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40555 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- Abid M. Malik ** I have learned silence from the talkative, toleration from the intolerant, and kindness from the unkind---Gibran If you do not think about the future, then you can not have the one!--- Galsworthy -- Abid M. Malik ** I have learned silence from the talkative, toleration from the intolerant, and kindness from the unkind---Gibran If you do not think about the future, then you can not have the one!--- Galsworthy -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40555
[Bug libfortran/40555] problem with libgfortran
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-06-26 03:03 --- *** This bug has been marked as a duplicate of 35619 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40555
[Bug bootstrap/35619] [4.3/4.4/4.5 Regression] fixed includes not being found if building in src dir
--- Comment #28 from pinskia at gcc dot gnu dot org 2009-06-26 03:03 --- *** Bug 40555 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||abidmuslim at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35619
[Bug libfortran/40555] problem with libgfortran
--- Comment #5 from abidmuslim at gmail dot com 2009-06-26 03:10 --- Subject: Re: problem with libgfortran Hello: I checked 35619 . However, I could not understand what is the solution to the error. I apologize for this. Thanks On Fri, Jun 26, 2009 at 11:03 AM, pinskia at gcc dot gnu dot orggcc-bugzi...@gcc.gnu.org wrote: --- Comment #4 from pinskia at gcc dot gnu dot org 2009-06-26 03:03 --- *** This bug has been marked as a duplicate of 35619 *** -- pinskia at gcc dot gnu dot org changed: What |Removed |Added Status|UNCONFIRMED |RESOLVED Resolution| |DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40555 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40555
Re: Warning while building for win64
This is a special case because all the logic has to be done in md5.c as preprocessor macros. You'd need someone familiar with the platform (Chris, Danny, Kai) to specify a reliable way to detect that platform and/or define the types accordingly. If it can typedef md5_uintptr directly, or use the _LIBC clause, that would be best.
[Bug libfortran/40555] problem with libgfortran
--- Comment #6 from kargl at gcc dot gnu dot org 2009-06-26 03:48 --- (In reply to comment #5) Subject: Re: problem with libgfortran Hello: I checked 35619 . However, I could not understand what is the solution to the error. I apologize for this. Do not try to build gcc in its source directory. tar -zxf gcc-4.4.0.tar.gz mkdir obj cd obj ../gcc-4.4.0/configure Add whatever configure you want to this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40555
[Bug middle-end/40556] New: [4.5 Regression] ICE with recursion
The following valid code snippet triggers an ICE when compiled with -O2:
===
struct A {};
struct A foo()
{
return foo();
}
void bar()
{
foo();
}
===
bug.c:11:1: internal compiler error: in ipcp_analyze_node, at ipa-cp.c:183
Please submit a full bug report, [etc.]
The regression appeared between 2009-05-09 and 2009-05-22.
--
Summary: [4.5 Regression] ICE with recursion
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40556
[Bug target/40503] DEC_EVAL_METHOD not match operators
--- Comment #2 from tydeman at tybor dot com 2009-06-26 05:57 --- Created an attachment (id=18073) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18073action=view) Find precision of *, /, +, -, == -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40503
