[Bug preprocessor/40376] New: GCC defines UNICODE instead of _UNICODE for -municode
The new option -municode incorrectly defines UNICODE. Instead, it should
define _UNICODE. Jon_Y provided the following suggestion for a fix:
Index: gcc/config/i386/mingw-w64.h
===
--- gcc/config/i386/mingw-w64.h (revision 148266)
+++ gcc/config/i386/mingw-w64.h (working copy)
@@ -24,7 +24,7 @@
#undef CPP_SPEC
#define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} \
- %{municode:-DUNICODE}"
+ %{municode:-D_UNICODE}"
#undef STARTFILE_SPEC
#define STARTFILE_SPEC "%{shared|mdll:dllcrt2%O%s} \
--
Summary: GCC defines UNICODE instead of _UNICODE for -municode
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nightstrike at gmail dot com
GCC target triplet: *-w64-mingw*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40376
[Bug target/40375] redundant register move with -mthumb
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-08 03:27 --- This might be caused by scheduling before the register allocator (or maybe the lack of). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40375
[Bug target/40375] redundant register move with -mthumb
--- Comment #1 from carrot at google dot com 2009-06-08 03:23 --- Created an attachment (id=17962) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17962&action=view) test case shows the redundant register move This problem occurs quite frequently if both caller and callee have multiple parameters. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40375
[Bug target/40375] New: redundant register move with -mthumb
Compile the following code with -mthumb -O2 -Os,
extern void foo(int*, const char*, int);
void test(const char name[], int style)
{
foo(0, name, style);
}
I got:
push{r4, lr}
mov r3, r0 // A
mov r2, r1 // B
mov r0, #0 // C
mov r1, r3 // D
bl foo
pop {r4, pc}
Instructions A and D move register r0 to r1, actually it can be replaced with 1
instruction
mov r1, r0
and place it between B and C.
--
Summary: redundant register move with -mthumb
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40375
[Bug web/40374] New: OpenMP version needs updating in GCC 4.4.0 manual
The gcc 4.4.0 manual states: When -fopenmp is specified, the compiler generates parallel code according to the OpenMP Application Program Interface v2.5 Per (http://gcc.gnu.org/gcc-4.4/changes.html), GCC 4.4.0 supports OpenMP 3.0. -- Summary: OpenMP version needs updating in GCC 4.4.0 manual Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: web AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: weeks at iastate dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40374
[Bug rtl-optimization/30807] postreload bug (might be generic in trunk)
--- Comment #7 from kkojima at gcc dot gnu dot org 2009-06-07 22:58 --- Created an attachment (id=17961) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17961&action=view) test case for 4.3 A reduced test case for 4.3 -O2 -fpic on sh4-unknown-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30807
[Bug target/16350] gcc only understands little endian ARM systems
--- Comment #24 from aldot at gcc dot gnu dot org 2009-06-07 22:51 ---
Nick,
As mentioned in #22 the following hunk that was in the patch was not applied:
diff --git a/gcc/config/arm/linux-elf.h b/gcc/config/arm/linux-elf.h
index 07455ee..d8e65d2 100644
--- a/gcc/config/arm/linux-elf.h
+++ b/gcc/config/arm/linux-elf.h
@@ -51,7 +51,7 @@
#undef MULTILIB_DEFAULTS
#define MULTILIB_DEFAULTS \
- { "marm", "mlittle-endian", "mhard-float", "mno-thumb-interwork" }
+ { "marm", TARGET_ENDIAN_OPTION, "mhard-float", "mno-thumb-interwork" }
/* Now we define the strings used to build the spec file. */
#undef LIB_SPEC
Please install.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350
[Bug fortran/40367] -Wextra description missing from gfortran manual page
--- Comment #4 from weeks at iastate dot edu 2009-06-07 22:15 --- I was somehow looking at an older version of the gcc manual page; the 4.4.0 version does describe -Wextra. Mea culpa. -- weeks at iastate dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40367
[Bug c++/40373] [4.3/4.4/4.5 Regression] ICE with invalid destructor call
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40373
[Bug c++/40373] New: [4.3/4.4/4.5 Regression] ICE with invalid destructor call
The following invalid code snippet triggers an ICE:
==
struct A;
namespace { struct A; }
struct B {};
template void foo(T t)
{
t.~A();
}
void bar()
{
foo(B());
}
==
bug.cc: In function 'void foo(T)':
bug.cc:8:6: error: reference to 'A' is ambiguous
bug.cc:1:8: error: candidates are: struct A
bug.cc:2:20: error: struct::A
bug.cc: In function 'void foo(T) [with T = B]':
bug.cc:13:10: instantiated from here
bug.cc:8:3: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in check_dtor_name, at cp/call.c:247
Please submit a full bug report, [etc.]
The bug affects the trunk, the 4.4 branch, and the 4.3 branch.
The bug was introduced on the 4.3 branch after the release of GCC 4.3.3.
--
Summary: [4.3/4.4/4.5 Regression] ICE with invalid destructor
call
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
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=40373
[Bug c++/40372] [4.4/4.5 Regression] ICE with invalid use of non-static data members
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40372
[Bug c++/40372] New: [4.4/4.5 Regression] ICE with invalid use of non-static data members
The following invalid code snippet triggers an ICE since GCC 4.4.0:
==
template struct A
{
int i;
friend void foo() { int x[i]; }
};
struct B
{
int j;
friend int bar() { return j; }
};
==
bug.cc: In function 'void foo()':
bug.cc:3:7: error: invalid use of non-static data member 'A< >::i'
bug.cc:4:29: error: from this location
bug.cc: In function 'int bar()':
bug.cc:9:7: error: invalid use of non-static data member 'B::j'
bug.cc:10:29: error: from this location
bug.cc:10:29: internal compiler error: tree check: expected class 'expression',
have 'exceptional' (error_mark) in fold_build_cleanup_point_expr, at
fold-const.c:15537
Please submit a full bug report, [etc.]
--
Summary: [4.4/4.5 Regression] ICE with invalid use of non-static
data members
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
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=40372
[Bug c++/40371] New: ICE with template operator
The following invalid code snippet triggers an ICE since at least GCC 2.95.3:
=
struct A
{
typedef void (&F)();
template operator F();
};
void foo()
{
A()();
}
=
bug.cc: In function 'void foo()':
bug.cc:9:7: internal compiler error: in add_template_candidate_real, at
cp/call.c:2477
Please submit a full bug report, [etc.]
--
Summary: ICE with template operator
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
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=40371
[Bug c++/40370] [4.4/4.5 Regression] ICE with invalid array bound in template class
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40370
[Bug c++/40370] New: [4.4/4.5 Regression] ICE with invalid array bound in template class
The following invalid code snippet triggers an ICE since GCC 4.4.0:
=
struct A
{
static int i;
};
template struct B
{
int x[A::i];
};
=
bug.cc:8:13: internal compiler error: tree check: did not expect class 'type',
have 'type' (record_type) in contains_placeholder_p, at tree.c:2498
Please submit a full bug report, [etc.]
The bug is related to PR28879.
--
Summary: [4.4/4.5 Regression] ICE with invalid array bound in
template class
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
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=40370
[Bug fortran/40349] compiler crash with -O3
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-06-07 19:20 --- Also works for me on newer versions. This is very likely PR 36817. Please try a more recent compiler and reopen this bug if it persists. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40349
[Bug fortran/40008] F2008: Add NEWUNIT= for OPEN statement
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-06-07 19:08 --- Subject: Bug 40008 Author: jvdelisle Date: Sun Jun 7 19:07:46 2009 New Revision: 148255 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148255 Log: 2009-06-07 Jerry DeLisle PR fortran/40008 * gfortran.dg/negative_unit.f: Update test. * gfortran.dg/negative_unit_int8.f: Update test. * gfortran.dg/newunit_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/newunit_1.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/negative_unit.f trunk/gcc/testsuite/gfortran.dg/negative_unit_int8.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40008
[Bug fortran/40008] F2008: Add NEWUNIT= for OPEN statement
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2009-06-07 19:01 --- Subject: Bug 40008 Author: jvdelisle Date: Sun Jun 7 19:00:47 2009 New Revision: 148253 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148253 Log: 2009-06-07 Jerry DeLisle PR libfortran/40008 * libgfortran.h: Define IOPARM_OPEN_HAS_NEWUNIT. * io/open.c (st_open): Don't error on negative unit number if NEWUNIT was specified. If NEWUNIT is specified, call new function to get the unique unit number and assign it. * io/io.h (st_parameter_open): Add pointer to newunit. Add prototype for next_available_newunit. Add prototype for new function, get_unique_unit_number. * io/unit.c: Declare next_available_newunit. Define the first newunit number. (init_units): Initialize next_available_unit. (get_unique_unit_number): New function. Fix whitespace and comments. * io/transfer.c (data_transfer_init): Update error message to not be specific to OPEN statements. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/io/open.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unit.c trunk/libgfortran/libgfortran.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40008
[Bug fortran/40008] F2008: Add NEWUNIT= for OPEN statement
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2009-06-07 18:57 --- Subject: Bug 40008 Author: jvdelisle Date: Sun Jun 7 18:57:43 2009 New Revision: 148252 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148252 Log: 2009-05-31 Jerry DeLisle PR fortran/40008 * gfortran.h (gfc_open): Add newunit expression to structure. * io.c (io_tag): Add new unit tag and fix whitespace. (match_open_element): Add matching for newunit. (gfc_free_open): Free the newunit expression. (gfc_resolve_open): Add newunit to resolution and check constraints. (gfc_resolve_close): Add check for non-negative unit. (gfc_resolve_filepos): Likewise. (gfc_resolve_dt): Likewise. * trans-io.c (set_parameter_value): Build runtime checks for unit numbers within range of kind=4 integer. (gfc_trans_open) Set the newunit parameter. * ioparm.def (IOPARM): Define the newunit parameter as a pointer to GFC_INTEGER_4, pint4. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/io.c trunk/gcc/fortran/ioparm.def trunk/gcc/fortran/trans-io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40008
[Bug libfortran/40334] [4.4/4.5 Regression] changed BACKSPACE behaviour at end of file.
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-06-07 17:40 --- Subject: Bug 40334 Author: jvdelisle Date: Sun Jun 7 17:40:24 2009 New Revision: 148251 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148251 Log: 2009-06-07 Jerry DeLisle PR libfortran/40334 * io/list_read.c (list_formatted_read_scalar): Set the end file conditions after a return from EOF error. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40334
[Bug fortran/25104] [F2003] Non-initialization expr. as case-selector
--- Comment #18 from burnus at gcc dot gnu dot org 2009-06-07 17:33 --- Subject: Bug 25104 Author: burnus Date: Sun Jun 7 17:33:34 2009 New Revision: 148250 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148250 Log: 2009-06-07 Daniel Franke PR fortran/25104 PR fortran/29962 * array.c (gfc_append_constructor): Added NULL-check. * check.c (gfc_check_spread): Check DIM. (gfc_check_unpack): Check that the ARRAY arguments provides enough values for MASK. * intrinsic.h (gfc_simplify_spread): New prototype. (gfc_simplify_unpack): Likewise. * intrinsic.c (add_functions): Added new simplifier callbacks. * simplify.c (gfc_simplify_spread): New. (gfc_simplify_unpack): New. * expr.c (check_transformational): Allow additional * transformational intrinsics in initialization expression. 2009-06-07 Daniel Franke PR fortran/25104 PR fortran/29962 * gfortran.dg/spread_init_expr.f03: New. * gfortran.dg/unpack_init_expr.f03: New. * gfortran.dg/intrinsic_argument_conformance_2.f90: Adjusted error message. Added: trunk/gcc/testsuite/gfortran.dg/spread_init_expr.f03 trunk/gcc/testsuite/gfortran.dg/unpack_init_expr.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/check.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/intrinsic_argument_conformance_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
[Bug fortran/29962] Initialization expressions
--- Comment #19 from burnus at gcc dot gnu dot org 2009-06-07 17:33 --- Subject: Bug 29962 Author: burnus Date: Sun Jun 7 17:33:34 2009 New Revision: 148250 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148250 Log: 2009-06-07 Daniel Franke PR fortran/25104 PR fortran/29962 * array.c (gfc_append_constructor): Added NULL-check. * check.c (gfc_check_spread): Check DIM. (gfc_check_unpack): Check that the ARRAY arguments provides enough values for MASK. * intrinsic.h (gfc_simplify_spread): New prototype. (gfc_simplify_unpack): Likewise. * intrinsic.c (add_functions): Added new simplifier callbacks. * simplify.c (gfc_simplify_spread): New. (gfc_simplify_unpack): New. * expr.c (check_transformational): Allow additional * transformational intrinsics in initialization expression. 2009-06-07 Daniel Franke PR fortran/25104 PR fortran/29962 * gfortran.dg/spread_init_expr.f03: New. * gfortran.dg/unpack_init_expr.f03: New. * gfortran.dg/intrinsic_argument_conformance_2.f90: Adjusted error message. Added: trunk/gcc/testsuite/gfortran.dg/spread_init_expr.f03 trunk/gcc/testsuite/gfortran.dg/unpack_init_expr.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/check.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/intrinsic_argument_conformance_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
[Bug c/40369] New: Unexpected Macro expansion leading to error
The following code was tried :
/* File1.c*/
#include
#define _q "
int main()
{
printf(_q ABC _q);
}
When given the -E option, I get
int main()
{
printf(" ABC ");
}
but when the same code was compiled ( gcc File1.c ), then the following errors
were received :
7 : missing terminating " character
7 : missing terminating " character
7 : 'ABC' undeclared
This was the unexpected error(list) obtained from that code.
--
Summary: Unexpected Macro expansion leading to error
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: saurabh dot manchanda at yahoo dot co dot in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40369
[Bug c/40368] -foptimize-sibling-calls drops assignment from tail call
--- Comment #7 from john at iastate dot edu 2009-06-07 17:10 --- PS, if there was an obvious place to find which versions are supported that would be most helpful -- I sire couldn't find it on the website... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40368
[Bug c/40368] -foptimize-sibling-calls drops assignment from tail call
--- Comment #6 from john at iastate dot edu 2009-06-07 17:04 --- OK, thanks. I will see about getting a newer gcc. I borrowed a machine with gcc 4.1.2 and it seems to have been fixed by that point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40368
[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level
--- Comment #10 from aldot at gcc dot gnu dot org 2009-06-07 16:54 ---
4.3.3 does not simplify it, 4.4.0 onward do.
for reference
4.3.3:
Substituing values and folding statements
Constants propagated: 0
Copies propagated: 0
Predicates folded: 0
ior (bD.1193)
{
D.1200;
unsigned charD.10 D.1199;
signed charD.9 D.1198;
signed charD.9 D.1197;
D.1196;
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
# VUSE { SMT.4D.1206 }
D.1196_2 = bD.1193_1(D)->bitD.1192;
D.1197_3 = (signed charD.9) D.1196_2;
D.1198_4 = D.1197_3 | 1;
D.1199_5 = (unsigned charD.10) D.1198_4;
D.1200_6 = () D.1199_5;
# SMT.4D.1206_8 = VDEF { SMT.4D.1206 }
bD.1193_1(D)->bitD.1192 = D.1200_6;
return;
# SUCC: EXIT [100.0%]
}
4.4.0:
Pass statistics:
Constants propagated: 1
Number of ASSERT_EXPR expressions inserted: 1
Statements deleted: 5
ior (struct B * bD.1247)
{
D.1254;
unsigned charD.10 D.1253;
signed charD.9 D.1252;
signed charD.9 D.1251;
D.1250;
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
# SMT.10D.1266_8 = VDEF { SMT.10D.1266 }
bD.1247_1(D)->bitD.1246 = 1;
return;
# SUCC: EXIT [100.0%]
}
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.3
Known to work||4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18031
[Bug c/40368] -foptimize-sibling-calls drops assignment from tail call
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-06-07 16:50 --- 3.3 has not been supported release of the FSF for a couple of years now. Since this is a modified version of GCC, you should report it to the folks who maintain it (in this case netbsd). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40368
[Bug c/40368] -foptimize-sibling-calls drops assignment from tail call
--- Comment #4 from john at iastate dot edu 2009-06-07 16:49 --- Created an attachment (id=17960) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17960&action=view) List.i from -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40368
[Bug c/40368] -foptimize-sibling-calls drops assignment from tail call
--- Comment #3 from john at iastate dot edu 2009-06-07 16:46 --- Using built-in specs. Configured with: /home/nick/work/netbsd/src/tools/gcc/../../gnu/dist/gcc/configu re --enable-long-long --disable-multilib --enable-threads --disable-symvers --bu ild=i386-unknown-netbsdelf --host=i386--netbsdelf --target=i386--netbsdelf Thread model: posix gcc version 3.3.3 (NetBSD nb3 20040520) /usr/bin/../libexec/cc1 -E -quiet -v -I../../h -iprefix /usr/bin/../libexec/ -D __GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=3 -dD List.c -foptimize-sibl ing-calls -O1 List.i ignoring nonexistent directory "/usr/libexec/include" #include "..." search starts here: #include <...> search starts here: ../../h /usr/include End of search list. /usr/bin/../libexec/cc1 -fpreprocessed List.i -quiet -dumpbase List.c -auxbase List -g3 -O1 -version -foptimize-sibling-calls -o List.s GNU C version 3.3.3 (NetBSD nb3 20040520) (i386--netbsdelf) compiled by GNU C version 3.3.3 (NetBSD nb3 20040520). GGC heuristics: --param ggc-min-expand=38 --param ggc-min-heapsize=16384 as -o List.o List.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40368
[Bug c/40368] -foptimize-sibling-calls drops assignment from tail call
--- Comment #2 from john at iastate dot edu 2009-06-07 16:45 ---
I will attach the -v -save-temps output, but it is large, so...
The source:
static void ListInit (
Listthis,
int argc,
va_list ap
) {
ListPrivate private = PRIVATE(this);
super(0);
private->list = listConstructRef();
}
The code (via objdump -r -d):
0c14 :
c14: 55 push %ebp
c15: 89 e5 mov%esp,%ebp
c17: 83 ec 10sub$0x10,%esp
c1a: 6a 00 push $0x0
c1c: ff 75 08pushl 0x8(%ebp)
c1f: 89 e9 mov%ebp,%ecx
c21: e8 ce ff ff ff call bf4 <__supertramp.0>
c26: 83 c4 10add$0x10,%esp
c29: c9 leave
c2a: e9 fc ff ff ff jmpc2b
c2b: R_386_PC32 listConstructRef
--
john at iastate dot edu changed:
What|Removed |Added
Component|target |c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40368
[Bug target/40368] -foptimize-sibling-calls drops assignment from tail call
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-07 16:40 --- What target is this for? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40368
[Bug c/40368] New: -foptimize-sibling-calls drops assignment from tail call
A function ends with: pointer->field = callSomething(); (where pointer is obtained via an argument (a pointer to struct) passed to the function). At -O1 and above, if -foptimize-sibling-calls is on, the call is converted to a jump, losing the assignment. -- Summary: -foptimize-sibling-calls drops assignment from tail call Product: gcc Version: 3.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: john at iastate dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40368
[Bug fortran/29962] Initialization expressions
--- Comment #18 from burnus at gcc dot gnu dot org 2009-06-07 16:35 --- Subject: Bug 29962 Author: burnus Date: Sun Jun 7 16:35:06 2009 New Revision: 148249 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148249 Log: 2009-06-07 Daniel Franke PR fortran/25104 PR fortran/29962 * check.c (gfc_check_all_any): Check rank of DIM. (gfc_check_count): Likewise. * intrinsic.h (gfc_simplify_all): New prototype. (gfc_simplify_any): Likewise. (gfc_simplify_count): Likewise. (gfc_simplify_sum): Likewise. (gfc_simplify_product): Likewise. * intrinsic.c (add_functions): Added new simplifier callbacks. * simplify.c (transformational_result): New. (simplify_transformation_to_scalar): New. (simplify_transformation_to_array): New. (gfc_count): New. (gfc_simplify_all): New. (gfc_simplify_any): New. (gfc_simplify_count): New. (gfc_simplify_sum): New. (gfc_simplify_product): New. * expr.c (check_transformational): Allow additional * transformational intrinsics in initialization expression. 2009-06-07 Daniel Franke PR fortran/25104 PR fortran/29962 * gfortran.dg/count_init_expr.f03 * gfortran.dg/product_init_expr.f03 * gfortran.dg/sum_init_expr.f03 Added: trunk/gcc/testsuite/gfortran.dg/count_init_expr.f03 trunk/gcc/testsuite/gfortran.dg/product_init_expr.f03 trunk/gcc/testsuite/gfortran.dg/sum_init_expr.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
[Bug fortran/25104] [F2003] Non-initialization expr. as case-selector
--- Comment #17 from burnus at gcc dot gnu dot org 2009-06-07 16:35 --- Subject: Bug 25104 Author: burnus Date: Sun Jun 7 16:35:06 2009 New Revision: 148249 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148249 Log: 2009-06-07 Daniel Franke PR fortran/25104 PR fortran/29962 * check.c (gfc_check_all_any): Check rank of DIM. (gfc_check_count): Likewise. * intrinsic.h (gfc_simplify_all): New prototype. (gfc_simplify_any): Likewise. (gfc_simplify_count): Likewise. (gfc_simplify_sum): Likewise. (gfc_simplify_product): Likewise. * intrinsic.c (add_functions): Added new simplifier callbacks. * simplify.c (transformational_result): New. (simplify_transformation_to_scalar): New. (simplify_transformation_to_array): New. (gfc_count): New. (gfc_simplify_all): New. (gfc_simplify_any): New. (gfc_simplify_count): New. (gfc_simplify_sum): New. (gfc_simplify_product): New. * expr.c (check_transformational): Allow additional * transformational intrinsics in initialization expression. 2009-06-07 Daniel Franke PR fortran/25104 PR fortran/29962 * gfortran.dg/count_init_expr.f03 * gfortran.dg/product_init_expr.f03 * gfortran.dg/sum_init_expr.f03 Added: trunk/gcc/testsuite/gfortran.dg/count_init_expr.f03 trunk/gcc/testsuite/gfortran.dg/product_init_expr.f03 trunk/gcc/testsuite/gfortran.dg/sum_init_expr.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
[Bug fortran/40367] -Wextra description missing from gfortran manual page
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-06-07 16:20 --- No, the gcc man page applies to all languages of the GNU Compiler collection. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40367
[Bug fortran/40367] -Wextra description missing from gfortran manual page
--- Comment #2 from weeks at iastate dot edu 2009-06-07 16:14 --- The description in the gcc manual page states the behavior for C/C++; little of it could apply to Fortran. It would be nice to know how how this option affects Fortran code (e.g., does it turn on all the warnings not enabled by -Wall?). -- weeks at iastate dot edu changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40367
[Bug middle-end/32950] [4.5 regression] ICE with __complex__ double
--- Comment #16 from pinskia at gcc dot gnu dot org 2009-06-07 15:55 --- Wait, (In reply to comment #15) > (In reply to comment #11) > > It is caused by revision 147980: > > > > http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00959.html > > > > Revision 147978 also does not work if you compile the testcase with > the -fno-tree-sra switch. > > New SRA uncovers this problem because it sees the structure containing > only a single field always accessed as a structure and never as a > scalar and so does not scalarize it. Something goes wrong later on, > probably when expanding to RTL. Unfortunately, I cannot help fixing > that. I think that should always scalarize as it is a single field as it is always better to scalarize single field structs (except maybe bitfield ones). -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32950
[Bug fortran/40367] -Wextra description missing from gfortran manual page
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-07 15:52 --- -Wextra is documented in the standard GCC manual. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40367
[Bug fortran/40367] New: -Wextra description missing from gfortran manual page
The gfortran manual page is missing a description of "-Wextra". The description of "-Wunused-parameter" mentions the use of "-Wall -Wextra", but nowhere in the manual page is -Wextra described. -- Summary: -Wextra description missing from gfortran manual page Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: weeks at iastate dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40367
[Bug middle-end/32950] [4.5 regression] ICE with __complex__ double
--- Comment #15 from jamborm at gcc dot gnu dot org 2009-06-07 14:41 --- (In reply to comment #11) > It is caused by revision 147980: > > http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00959.html > Revision 147978 also does not work if you compile the testcase with the -fno-tree-sra switch. New SRA uncovers this problem because it sees the structure containing only a single field always accessed as a structure and never as a scalar and so does not scalarize it. Something goes wrong later on, probably when expanding to RTL. Unfortunately, I cannot help fixing that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32950
[Bug fortran/36874] Add shape checks to cshift/eoshift
--- Comment #9 from tkoenig at gcc dot gnu dot org 2009-06-07 14:41 --- If nobody minds, I'll do this (it's part of PR 34670 anyway). -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||34670 nThis|| AssignedTo|dfranke at gcc dot gnu dot |tkoenig at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36874
[Bug fortran/38914] [4.3 only] ICE with array inquiry functions above contains in parameter expression
--- Comment #8 from tkoenig at gcc dot gnu dot org 2009-06-07 14:39 --- I don't want to do any backport to 4.3 any more. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38914
[Bug middle-end/40328] [4.5 Regression] internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1811
--- Comment #8 from hjl at gcc dot gnu dot org 2009-06-07 14:37 --- Subject: Bug 40328 Author: hjl Date: Sun Jun 7 14:36:55 2009 New Revision: 148248 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148248 Log: 2009-06-07 H.J. Lu Backport from mainline: 2009-06-03 Richard Guenther PR middle-end/40328 * gcc.dg/torture/pr40328.c: New testcase. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr40328.c - copied unchanged from r148247, trunk/gcc/testsuite/gcc.dg/torture/pr40328.c Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40328
[Bug libfortran/40187] c_f_pointer with stride in SHAPE
--- Comment #9 from burnus at gcc dot gnu dot org 2009-06-07 14:37 --- > Does this need a 4.4 backport? I'm inclined to think not. Good question. As it is no regression, backporting is not required; it is a wrong-code bug, but strides are rather special. Thus for me either is OK - backporting or just closing as FIXED. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40187
[Bug target/36399] FSF GCC ABI bug on darwin/x86-32
--- Comment #5 from hjl dot tools at gmail dot com 2009-06-07 14:27 --- (In reply to comment #4) > Yeah. Looking through our local changes, I think you just need this line in > i386.h: > > #define SSE_REGPARM_MAX (TARGET_64BIT ? 8 : (TARGET_MACHO ? 4 : (TARGET_SSE ? > 3 > : 0))) > > However Apple employees can't currently touch GPLv3 code, so we can't do the > testing. Stan, can you do this? > Shouldn't it be #define SSE_REGPARM_MAX (TARGET_64BIT ? 8 : (TARGET_SSE ? (TARGET_MACHO ? 4 : 3 : 0))) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36399
[Bug libfortran/40187] c_f_pointer with stride in SHAPE
--- Comment #8 from tkoenig at gcc dot gnu dot org 2009-06-07 14:24 --- Does this need a 4.4 backport? I'm inclined to think not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40187
[Bug fortran/36874] Add shape checks to cshift/eoshift
--- Comment #8 from burnus at gcc dot gnu dot org 2009-06-07 13:59 --- Compile time check is now there (4.5 trunk). Missing is a run-time check. Example: real, dimension(1,0) :: a, b, c integer :: sp(3), i a = 4.0 sp = 1 i = 1 b = eoshift (a,sp(1:i)) ! Invalid end NAG f95 writes at run time: Shape mismatch (dimension 1) between ARRAY and SHIFT in CSHIFT -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36874
[Bug fortran/36874] Add shape checks to cshift/eoshift
--- Comment #7 from burnus at gcc dot gnu dot org 2009-06-07 13:46 --- Subject: Bug 36874 Author: burnus Date: Sun Jun 7 13:45:47 2009 New Revision: 148247 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148247 Log: 2009-06-07 Daniel Franke * check.c (dim_rank_check): Return SUCCESS if DIM=NULL. (gfc_check_lbound): Removed (now) redundant check for DIM=NULL. (gfc_check_minloc_maxloc): Likewise. (check_reduction): Likewise. (gfc_check_size): Likewise. (gfc_check_ubound): Likewise. (gfc_check_cshift): Added missing shape-conformance checks. (gfc_check_eoshift): Likewise. * gfortran.h (gfc_check_conformance): Modified prototype to printf-style. * expr.c (gfc_check_conformance): Accept error-message chunks in printf-style. Changed all callers. 2009-06-07 Daniel Franke PR fortran/36874 * gfortran.dg/intrinsic_argument_conformance_2.f90: Adjusted error message. * gfortran.dg/zero_sized_1.f90: Removed checks with incompatible shapes. * gfortran.dg/zero_sized_5.f90: Likewise. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/check.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/intrinsic_argument_conformance_2.f90 trunk/gcc/testsuite/gfortran.dg/zero_sized_1.f90 trunk/gcc/testsuite/gfortran.dg/zero_sized_5.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36874
[Bug middle-end/32950] [4.5 regression] ICE with __complex__ double
--- Comment #14 from hjl at gcc dot gnu dot org 2009-06-07 13:40 --- Subject: Bug 32950 Author: hjl Date: Sun Jun 7 13:39:54 2009 New Revision: 148246 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148246 Log: 2009-06-07 H.J. Lu Backport from mainline: 2009-06-07 H.J. Lu PR middle-end/32950 * g++.dg/torture/pr32950.C: New. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/torture/pr32950.C - copied unchanged from r148245, trunk/gcc/testsuite/g++.dg/torture/pr32950.C Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32950
[Bug middle-end/32950] [4.5 regression] ICE with __complex__ double
--- Comment #13 from hjl at gcc dot gnu dot org 2009-06-07 13:38 --- Subject: Bug 32950 Author: hjl Date: Sun Jun 7 13:38:38 2009 New Revision: 148245 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148245 Log: 2009-06-07 H.J. Lu Backport from mainline: 2009-06-07 H.J. Lu PR middle-end/32950 * g++.dg/torture/pr32950.C: New. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr32950.C - copied unchanged from r148244, trunk/gcc/testsuite/g++.dg/torture/pr32950.C Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32950
[Bug middle-end/32950] [4.5 regression] ICE with __complex__ double
--- Comment #12 from hjl at gcc dot gnu dot org 2009-06-07 13:35 --- Subject: Bug 32950 Author: hjl Date: Sun Jun 7 13:35:05 2009 New Revision: 148244 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148244 Log: 2009-06-07 H.J. Lu PR middle-end/32950 * g++.dg/torture/pr32950.C: New. Added: trunk/gcc/testsuite/g++.dg/torture/pr32950.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32950
[Bug middle-end/32950] [4.5 regression] ICE with __complex__ double
--- Comment #11 from hjl dot tools at gmail dot com 2009-06-07 13:26 --- It is caused by revision 147980: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00959.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||mjambor at suse dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32950
[Bug c++/40362] openmp: some libgomp functions trigger data races
--- Comment #7 from jakub at gcc dot gnu dot org 2009-06-07 13:07 ---
valgrind just isn't smart enough to understand it.
Obviously --enable-linux-futex build has a lot of synchronization primitives
that are beyond what valgrind is able to understand, but even with the posix
only primitives e.g.:
static inline void *gomp_ptrlock_get (gomp_ptrlock_t *ptrlock)
{
if (ptrlock->ptr != NULL)
return ptrlock->ptr;
gomp_mutex_lock (&ptrlock->lock);
if (ptrlock->ptr != NULL)
{
gomp_mutex_unlock (&ptrlock->lock);
return ptrlock->ptr;
}
return NULL;
}
is not something valgrind can understand. Try removing the first if/return and
see if it helps drd. The reason why it is safe to do is that all supported
libgomp targets have atomic pointer-sized loads/stores, and the pointer always
starts as NULL and is only set to non-NULL value inside of a critical section
guarded by the associated lock. Once it is non-NULL, it never changes its
value again. So, if the inline sees the value non-NULL, it can safely assume
it will be non-NULL all the time and doesn't have to take the lock...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40362
[Bug fortran/29962] Initialization expressions
--- Comment #17 from burnus at gcc dot gnu dot org 2009-06-07 11:53 --- Subject: Bug 29962 Author: burnus Date: Sun Jun 7 11:53:21 2009 New Revision: 148243 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148243 Log: 2009-06-07 Daniel Franke PR fortran/25104 PR fortran/29962 * intrinsic.h (gfc_simplify_dot_product): New prototype. (gfc_simplify_matmul): Likewise. (gfc_simplify_transpose): Likewise. * intrinsic.c (add_functions): Added new simplifier callbacks. * simplify.c (init_result_expr): New. (compute_dot_product): New. (gfc_simplify_dot_product): New. (gfc_simplify_matmul): New. (gfc_simplify_transpose): New. * expr.c (check_transformational): Allow transformational * intrinsics with simplifier in initialization expression. 2009-06-07 Daniel Franke PR fortran/25104 PR fortran/29962 * gfortran.dg/dot_product_1.f03: New. * gfortran.dg/matmul_8.f03: New. * gfortran.dg/transpose_3.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/dot_product_1.f03 trunk/gcc/testsuite/gfortran.dg/matmul_8.f03 trunk/gcc/testsuite/gfortran.dg/transpose_3.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
[Bug fortran/25104] [F2003] Non-initialization expr. as case-selector
--- Comment #16 from burnus at gcc dot gnu dot org 2009-06-07 11:53 --- Subject: Bug 25104 Author: burnus Date: Sun Jun 7 11:53:21 2009 New Revision: 148243 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148243 Log: 2009-06-07 Daniel Franke PR fortran/25104 PR fortran/29962 * intrinsic.h (gfc_simplify_dot_product): New prototype. (gfc_simplify_matmul): Likewise. (gfc_simplify_transpose): Likewise. * intrinsic.c (add_functions): Added new simplifier callbacks. * simplify.c (init_result_expr): New. (compute_dot_product): New. (gfc_simplify_dot_product): New. (gfc_simplify_matmul): New. (gfc_simplify_transpose): New. * expr.c (check_transformational): Allow transformational * intrinsics with simplifier in initialization expression. 2009-06-07 Daniel Franke PR fortran/25104 PR fortran/29962 * gfortran.dg/dot_product_1.f03: New. * gfortran.dg/matmul_8.f03: New. * gfortran.dg/transpose_3.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/dot_product_1.f03 trunk/gcc/testsuite/gfortran.dg/matmul_8.f03 trunk/gcc/testsuite/gfortran.dg/transpose_3.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
[Bug libstdc++/40088] Creating a std::ostringstream object locks a global mutex
--- Comment #10 from paolo dot carlini at oracle dot com 2009-06-07 11:07 --- Benjamin, do you have a strong opinion about this issue? I don't, really, but especially in the light of the C++0x drafts (thanks to Greg for pointing it out), I would close for now the issue with a patch adding a configure time option to not use the mutex, the current safe but slow behavior as default, probably. If I'm not mistaken, in either case the *.so would be binary compatible anyway. In the future, we should probably move to the one global locale per thread, but I don't think it's easily implementable without affecting the ABI... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo at gcc dot gnu dot ||org, bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40088
[Bug testsuite/40359] [4.5 Regression] Revision 148211 caused a lot of failures in the vect test suite.
--- Comment #10 from eres at il dot ibm dot com 2009-06-07 10:51 --- (In reply to comment #9) > The patch in comment #8 fixes the failures reported in comment #7. I now see > (powerpc-apple-darwin9 with -m64): > FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Alignment of access > forced using versioning" 3 I can not reproduce this failure; I appreciate it if you could post the vectorizer dump file (produced with -fdump-tree-vect-details flag) thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40359
[Bug c/11751] wrong evaluation order of an expression
--- Comment #85 from schwab at linux-m68k dot org 2009-06-07 09:04 --- *** Bug 40366 has been marked as a duplicate of this bug. *** -- schwab at linux-m68k dot org changed: What|Removed |Added CC||ashutosh dot sharma dot 0204 ||at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
[Bug c/40366] Array + XOR swap fails
--- Comment #2 from schwab at linux-m68k dot org 2009-06-07 09:04 --- *** This bug has been marked as a duplicate of 11751 *** -- schwab at linux-m68k dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40366
[Bug tree-optimization/40348] Powerpc spe segfaults in vectorizing powf (a[i], 0.5f)
--- Comment #2 from irar at il dot ibm dot com 2009-06-07 07:59 ---
So, I guess this patch fixes it?
Thanks,
Ira
Index: tree-vect-patterns.c
===
--- tree-vect-patterns.c(revision 148035)
+++ tree-vect-patterns.c(working copy)
@@ -515,6 +515,9 @@ vect_recog_pow_pattern (gimple last_stmt
&& REAL_VALUES_EQUAL (TREE_REAL_CST (exp), dconsthalf))
{
tree newfn = mathfn_built_in (TREE_TYPE (base), BUILT_IN_SQRT);
+ if (!newfn)
+return NULL;
+
*type_in = get_vectype_for_scalar_type (TREE_TYPE (base));
if (*type_in)
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40348
[Bug testsuite/40359] [4.5 Regression] Revision 148211 caused a lot of failures in the vect test suite.
--- Comment #9 from dominiq at lps dot ens dot fr 2009-06-07 07:48 --- The patch in comment #8 fixes the failures reported in comment #7. I now see (powerpc-apple-darwin9 with -m64): FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Alignment of access forced using versioning" 3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40359
[Bug c/40366] Array + XOR swap fails
--- Comment #1 from pinskia at gmail dot com 2009-06-07 07:23 ---
Subject: Re: New: Array + XOR swap fails
Both of these are undefined. Look up about sequence point rules.
Sent from my iPhone
On Jun 7, 2009, at 12:15 AM, "ashutosh dot sharma dot 0204 at gmail
dot com" wrote:
> Compiler Version:
> gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There
> is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
>
>
> Sample code:
>
> #include
>
> int main() {
>int a[2];
>a[0]=10;
>a[1]=20;
>printf("a[0] = %d a[1] = %d\n", a[0], a[1]);
>a[0]^=a[1]^=a[0]^=a[1];
>printf("a[0] = %d a[1] = %d\n", a[0], a[1]);
>return 0;
> }
>
> gcc test.c -o test -O2
>
> a[0] = 10 a[1] = 20
> a[0] = 20 a[1] = 10
>
> gcc test.c -o test -O0
>
> a[0] = 10 a[1] = 20
> a[0] = 0 a[1] = 10
>
> Bug: When compiled with -O0 swap fails.
> Swap only fails in case of array. Following code works fine with -O0:
>
> #include
>
> int main() {
>int a, b;
>a=10;
>b=20;
>printf("a = %d b = %d\n", a, b);
>a^=b^=a^=b;
>printf("a = %d b = %d\n", a, b);
>return 0;
> }
>
>
> --
> Summary: Array + XOR swap fails
> Product: gcc
> Version: unknown
>Status: UNCONFIRMED
> Severity: major
> Priority: P3
> Component: c
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: ashutosh dot sharma dot 0204 at gmail dot com
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40366
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40366
Re: [Bug c/40366] New: Array + XOR swap fails
Both of these are undefined. Look up about sequence point rules.
Sent from my iPhone
On Jun 7, 2009, at 12:15 AM, "ashutosh dot sharma dot 0204 at gmail
dot com" wrote:
Compiler Version:
gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
Sample code:
#include
int main() {
int a[2];
a[0]=10;
a[1]=20;
printf("a[0] = %d a[1] = %d\n", a[0], a[1]);
a[0]^=a[1]^=a[0]^=a[1];
printf("a[0] = %d a[1] = %d\n", a[0], a[1]);
return 0;
}
gcc test.c -o test -O2
a[0] = 10 a[1] = 20
a[0] = 20 a[1] = 10
gcc test.c -o test -O0
a[0] = 10 a[1] = 20
a[0] = 0 a[1] = 10
Bug: When compiled with -O0 swap fails.
Swap only fails in case of array. Following code works fine with -O0:
#include
int main() {
int a, b;
a=10;
b=20;
printf("a = %d b = %d\n", a, b);
a^=b^=a^=b;
printf("a = %d b = %d\n", a, b);
return 0;
}
--
Summary: Array + XOR swap fails
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ashutosh dot sharma dot 0204 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40366
[Bug c/40366] New: Array + XOR swap fails
Compiler Version:
gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Sample code:
#include
int main() {
int a[2];
a[0]=10;
a[1]=20;
printf("a[0] = %d a[1] = %d\n", a[0], a[1]);
a[0]^=a[1]^=a[0]^=a[1];
printf("a[0] = %d a[1] = %d\n", a[0], a[1]);
return 0;
}
gcc test.c -o test -O2
a[0] = 10 a[1] = 20
a[0] = 20 a[1] = 10
gcc test.c -o test -O0
a[0] = 10 a[1] = 20
a[0] = 0 a[1] = 10
Bug: When compiled with -O0 swap fails.
Swap only fails in case of array. Following code works fine with -O0:
#include
int main() {
int a, b;
a=10;
b=20;
printf("a = %d b = %d\n", a, b);
a^=b^=a^=b;
printf("a = %d b = %d\n", a, b);
return 0;
}
--
Summary: Array + XOR swap fails
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ashutosh dot sharma dot 0204 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40366
[Bug testsuite/40359] [4.5 Regression] Revision 148211 caused a lot of failures in the vect test suite.
--- Comment #8 from eres at il dot ibm dot com 2009-06-07 07:12 --- Created an attachment (id=17959) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17959&action=view) patch to fix syntax errors in tests This patch should fix the syntax errors. I'll sumbit it also if the problem is solved. Thanks again, Revital -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40359
[Bug c++/40362] openmp: some libgomp functions trigger data races
--- Comment #6 from bart dot vanassche at gmail dot com 2009-06-07 07:09 --- (In reply to comment #5) > You have to read the code to understand how that happens. > But basically GOMP_parallel_start does: > gomp_team_start (fn, data, num_threads, gomp_new_team (num_threads)); > > Where gomp_new_team creates the *thr (which is a big malloc) and then > gomp_team_start creates the threads (and also does the write before creating > the thread). As far as I can see gomp_new_team() only creates threads upon the first invocation or when its third argument is larger than for any previous invocation. So I'm still not convinced that comment #3 is correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40362
