[Bug fortran/37472] bad output on default-format write of double in common block with -m64 flag i
--- Comment #2 from burnus at gcc dot gnu dot org 2008-09-11 06:01 --- I cannot reproduce the problem with gfortran 4.1, 4.2, 4.3 or 4.4 on x86-64-linux with either -m32 or -m64, which makes debugging not easier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37472
[Bug other/37474] New: [4.4 Regression] mpfr related memory corruption, part 2
Jakub, thanks for fixing PR37419 so quickly. I can confirm that the testcase from this bug now works. However, there's a second testcase I have that still shows a similar problem with current trunk (revision 140257): (sid)1151:[EMAIL PROTECTED]: ..4.3-2008-09-11-r140257/gcc] ./cc1 -quiet -O3 ~/gst-plugins-base0.10-imgconvert.i *** glibc detected *** ./cc1: free(): invalid next size (fast): 0x02025420 *** === Backtrace: = /lib/libc.so.6[0x7f315eda1968] /lib/libc.so.6(cfree+0x76)[0x7f315eda3a76] ./cc1[0x80c083] ./cc1[0x80c507] ./cc1[0x829762] ./cc1[0x6404d9] ./cc1[0x640715] ./cc1[0x64072d] ./cc1[0x64072d] ./cc1[0x736f0c] ./cc1[0x8b0710] ./cc1[0x8b2444] ./cc1[0x416743] ./cc1[0x6e7f09] /lib/libc.so.6(__libc_start_main+0xe6)[0x7f315ed4c1a6] ./cc1(mpfr_cosh+0xc1)[0x4044d9] === Memory map: 0040-00d94000 r-xp 08:07 164732 /home/tbm/tmp/gcc/4.3-2008-09-11-r140257/gcc/cc1 00f94000-0101e000 rw-p 00994000 08:07 164732 /home/tbm/tmp/gcc/4.3-2008-09-11-r140257/gcc/cc1 0101e000-010b2000 rw-p 0101e000 00:00 0 01f4b000-02361000 rw-p 01f4b000 00:00 0 [heap] 7f315800-7f3158021000 rw-p 7f315800 00:00 0 7f3158021000-7f315c00 ---p 7f3158021000 00:00 0 7f315c09f000-7f315c0b5000 r-xp 08:07 5522074 /lib/libgcc_s.so.1 7f315c0b5000-7f315c2b5000 ---p 00016000 08:07 5522074 /lib/libgcc_s.so.1 7f315c2b5000-7f315c2b6000 rw-p 00016000 08:07 5522074 /lib/libgcc_s.so.1 7f315c2b6000-7f315c2bb000 rw-p 7f315c2b6000 00:00 0 7f315c2bd000-7f315c2c4000 rw-p 7f315c2bd000 00:00 0 7f315c2d2000-7f315c2d7000 rw-p 7f315c2d2000 00:00 0 7f315c2d9000-7f315c2da000 rw-p 7f315c2d9000 00:00 0 7f315c2db000-7f315c2e6000 rw-p 7f315c2db000 00:00 0 7f315c2e8000-7f315c2eb000 rw-p 7f315c2e8000 00:00 0 7f315c2ee000-7f315c2ef000 rw-p 7f315c2ee000 00:00 0 7f315c3b6000-7f315c3ba000 rw-p 7f315c3b6000 00:00 0 7f315c3bc000-7f315c3bd000 rw-p 7f315c3bc000 00:00 0 7f315c3bf000-7f315c3c rw-p 7f315c3bf000 00:00 0 7f315c3c1000-7f315c3c2000 rw-p 7f315c3c1000 00:00 0 7f315c3c5000-7f315c3c7000 rw-p 7f315c3c5000 00:00 0 7f315c3c8000-7f315c3ca000 rw-p 7f315c3c8000 00:00 0 7f315c3cb000-7f315c3cd000 rw-p 7f315c3cb000 00:00 0 7f315c3ce000-7f315c3d5000 rw-p 7f315c3ce000 00:00 0 7f315c3d6000-7f315c3e2000 rw-p 7f315c3d6000 00:00 0 7f315c3e3000-7f315c3e4000 rw-p 7f315c3e3000 00:00 0 7f315c3e5000-7f315c3e6000 rw-p 7f315c3e5000 00:00 0 7f315c3e7000-7f315c3e9000 rw-p 7f315c3e7000 00:00 0 7f315c3ea000-7f315c3ec000 rw-p 7f315c3ea000 00:00 0 7f315c3ed000-7f315c3ef000 rw-p 7f315c3ed000 00:00 0 7f315c3f-7f315c3f1000 rw-p 7f315c3f 00:00 0 7f315c3f2000-7f315c3fa000 rw-p 7f315c3f2000 00:00 0 7f315c3fc000-7f315c40 rw-p 7f315c3fc000 00:00 0 7f315c401000-7f315c406000 rw-p 7f315c401000 00:00 0 7f315c407000-7f315c40b000 rw-p 7f315c407000 00:00 0 7f315c40d000-7f315c40e000 rw-p 7f315c40d000 00:00 0 7f315c41-7f315c415000 rw-p 7f315c41 00:00 0 7f315c418000-7f315c419000 rw-p 7f315c418000 00:00 0 7f315c41a000-7f315c422000 rw-p 7f315c41a000 00:00 0 7f315c423000-7f315c425000 rw-p 7f315c423000 00:00 0 7f315c427000-7f315c428000 rw-p 7f315c427000 00:00 0 7f315c429000-7f315c42a000 rw-p 7f315c429000 00:00 0 7f315c42b000-7f315c438000 rw-p 7f315c42b000 00:00 0 7f315c439000-7f315c43a000 rw-p 7f315c439000 00:00 0 7f315c43b000-7f315c43c000 rw-p 7f315c43b000 00:00 0 7f315c43d000-7f315c43e000 rw-p 7f315c43d000 00:00 0 7f315c43f000-7f315c441000 rw-p 7f315c43f000 00:00 0 7f315c442000-7f315c444000 rw-p 7f315c442000 00:00 0 7f315c448000-7f315c44a000 rw-p 7f315c448000 00:00 0 7f315c44b000-7f315c44c000 rw-p 7f315c44b000 00:00 0 7f315c44d000-7f315c455000 rw-p 7f315c44d000 00:00 0 7f315c457000-7f315c46c000 rw-p 7f315c457000 00:00 0 7f315c46d000-7f315c477000 rw-p 7f315c46d000 00:00 0 7f315c478000-7f315c47c000 rw-p 7f315c478000 00:00 0 7f315c47e000-7f315c47f000 rw-p 7f315c47e000 00:00 0 7f315c485000-7f315c486000 rw-p 7f315c485000 00:00 0 7f315c487000-7f315c489000 rw-p 7f315c487000 00:00 0 7f315c48b000-7f315c48f000 rw-p 7f315c48b000 00:00 0 7f315c494000-7f315c495000 rw-p 7f315c494000 00:00 0 7f315c497000-7f315c49b000 rw-p 7f315c497000 00:00 0 7f315c49d000-7f315c4a4000 rw-p 7f315c49d000 00:00 0 7f315c4a6000-7f315c4ab000 rw-p 7f315c4a6000 00:00 0 7f315c4ac000-7f315c4ae000 rw-p 7f315c4ac000 00:00 0 7f315c4af000-7f315c4b3000 rw-p 7f315c4af000 00:00 0 7f315c4b4000-7f315c4b7000 rw-p 7f315c4b4000 00:00 0 7f315c4b8000-7f315c4b9000 rw-p 7f315c4b8000 00:00 0 7f315c4ba000-7f315c4be000 rw-p 7f315c4ba000 00:00 0 7f315c4bf000-7f315c4c2000 rw-p 7f315c4bf000 00:00 0 7f315c4c5000-7f315c4c6000 rw-p 7f315c4c5000 00:00 0 7f315c4c8000-7f315c4cb000 rw-p 7f315c4c8000 00:00 0 7f315c4cc000-7f315c4cf000 rw-p 7f315c4cc000 00:00 0 7f315c4d-7f315c4d3000 rw-p 7f315c4d 00:00 0 7f315c4d4000-7f315c4d5000 rw-p 7f315c4d4000 00:00 0 7f315c4d6000-7f315c4d8000 rw-p 7f315c4d6000 00:00 0 7f315c4d9000-7f315c4f rw-p 7f315c4d9000
[Bug other/37474] [4.4 Regression] mpfr related memory corruption, part 2
--- Comment #1 from tbm at cyrius dot com 2008-09-11 06:36 --- Created an attachment (id=16290) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16290action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37474
[Bug fortran/36214] Wrong simplification of BOZ constants
--- Comment #8 from domob at gcc dot gnu dot org 2008-09-11 07:29 --- Subject: Bug 36214 Author: domob Date: Thu Sep 11 07:28:18 2008 New Revision: 140264 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140264 Log: 2008-09-11 Daniel Kraft [EMAIL PROTECTED] PR fortran/36214 * simplify.c (simplify_cmplx): Added linebreak to long line. * target-memory.c (gfc_convert_boz): Fix indentation. (gfc_interpret_float): Set mpfr precision to right value before calling mpfr_init. 2008-09-11 Daniel Kraft [EMAIL PROTECTED] PR fortran/36214 * gfortran.dg/boz_9.f90: Corrected test. * gfortran.dg/boz_13.f90: New test. * gfortran.dg/boz_14.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/boz_13.f90 trunk/gcc/testsuite/gfortran.dg/boz_14.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/fortran/target-memory.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/boz_9.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36214
[Bug target/37382] [4.4 Regression] ICE in extract_insn: var_decl 0x7fda26ff4b40 swig_module) 0)
--- Comment #6 from jakub at gcc dot gnu dot org 2008-09-11 07:34 --- Subject: Bug 37382 Author: jakub Date: Thu Sep 11 07:33:23 2008 New Revision: 140265 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140265 Log: PR target/37382 * expmed.c (extract_low_bits): Avoid creating invalid subregs. * dse.c (find_shift_sequence): Use extract_low_bits instead of simplify_gen_subreg. * gcc.c-torture/compile/pr37382.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr37382.c Modified: trunk/gcc/ChangeLog trunk/gcc/dse.c trunk/gcc/expmed.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37382
[Bug target/37382] [4.4 Regression] ICE in extract_insn: var_decl 0x7fda26ff4b40 swig_module) 0)
--- Comment #7 from jakub at gcc dot gnu dot org 2008-09-11 07:40 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37382
[Bug other/37474] [4.4 Regression] mpfr related memory corruption, part 2
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-11 07:42:26 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37474
[Bug c++/36391] Compilation never ends
--- Comment #5 from rhorstmann at securecomputing dot com 2008-09-11 07:49 --- I think this is the same as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512 So should be fixed in 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36391
[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR
--- Comment #9 from dodji at gcc dot gnu dot org 2008-09-11 07:56 --- @Jakub: * I think (x ? c.i : c.j) = y; should be valid. because we then fall into the item 4 of the spec, PDF page 115, section 5.16: Conditional operator which reads: If the second and third operands are lvalues and have the same type, the result is of that type and is an lvalue * (x ? c.i : a) = y; should not be valid because we fall into the item 5 that says: Otherwise, the result is an rvalue. Then we fall into item 6: Lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conversions are performed on the second and third operands. After those conversions, one of the following shall hold: The second and third operands have the same type; the result is of that type. So after this point, the result is an rvalue. So the assignation becomes invalid. * (x ? c.i : c.k) = y; Should be invalid as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37146
[Bug other/37474] [4.4 Regression] mpfr related memory corruption, part 2
--- Comment #2 from jakub at gcc dot gnu dot org 2008-09-11 08:19 ---
vect_analyze_slp_instance/vect_supported_load_permutation_p/vect_supported_slp_permutation_p
are buggy.
0x00a51e93 in vect_supported_slp_permutation_p
(instance=0x7fffe4bfafd8) at ../../gcc/tree-vect-analyze.c:3157
3157 tmp_loads[index] = load;
(gdb) p *instance
$23 = {root = 0x7fffe4d95fd0, group_size = 2, unrolling_factor = 8, cost =
{outside_of_loop = 0, inside_of_loop = 33},
load_permutation = 0x7fffe512cfb8, loads = 0x7fffe512efb8}
(gdb) p *instance-load_permutation
$24 = {base = {num = 12, alloc = 16, vec = {5}}}
(gdb) x/12w instance-load_permutation-base.vec
0x7fffe512cfc0: 0x0005 0x0005 0x0002 0x0002
0x7fffe512cfd0: 0x0004 0x0004 0x0001 0x0001
0x7fffe512cfe0: 0x0003 0x0003 0x 0x
(gdb) p index
$25 = 5
So it is writing well past the end of tmp_loads (which has group_size == 2
entries).
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||irar at gcc dot gnu dot org
AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu
||dot org
Status|ASSIGNED|NEW
Last reconfirmed|2008-09-11 07:42:26 |2008-09-11 08:19:46
date||
Target Milestone|4.4.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37474
[Bug other/37474] [4.4 Regression] mpfr related memory corruption, part 2
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37474
[Bug other/37474] [4.4 Regression] vect_supported_slp_permutation_p memory corruption
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-11 08:22 --- It has absolutely nothing to do with mpfr (neither did the other memory corruption), no idea where you got it from. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4 Regression] mpfr |[4.4 Regression] |related memory corruption, |vect_supported_slp_permutati |part 2 |on_p memory corruption http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37474
[Bug other/37474] [4.4 Regression] vect_supported_slp_permutation_p memory corruption
-- irar at il dot ibm dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-09-11 08:19:46 |2008-09-11 08:53:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37474
[Bug libstdc++/37475] New: codecvt::do_in/do_out functions return ok when the output sequence has zero length
The following member functions of the class codecvtwchar_t, char, mbstate_t result in(stateT state, const externT* from, const externT* from_end, const externT* from_next, internT* to, internT* to_limit, internT* to_next) const and result out(stateT state, const internT* from, const internT* from_end, const internT* from_next, externT* to, externT* to_limit, externT* to_next) const return ok if (to==to_limit) but (from from_end), that is, when the output sequence contains no elements but the input sequence is not empty. However, as appears from the description of the functions' return values (22.2.1.5.2 p4), partial should be returned instead: ok - completed the conversion partial - not all source characters converted error - encountered a character in [from,from_end) that it could not convert noconv - internT and externT are the same type, and input sequence is identical to converted sequence Note that these functions do return partial if the output sequence is not empty but still not large enough to contain all converted characters from the input sequence, that is, if 0 (to_limit - to) (from_end - from). [EMAIL PROTECTED]:/mnt/hgfs/shared/temp/test$ g++ -Wall test.cpp ./a.out Calls do_out() function when size of input sequenceis 2, output - 1: do_out() returns partial. Calls do_out() function when size of input sequenceis 2, output - 0: do_out() returns ok. Calls do_in() function when size of input sequenceis 2, output - 1: do_in() returns partial. Calls do_in() function when size of input sequenceis 2, output - 0: do_in() returns ok. [EMAIL PROTECTED]:/mnt/hgfs/shared/temp/test$ g++ --version g++ (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4) Copyright (C) 2006 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. -- Summary: codecvt::do_in/do_out functions return ok when the output sequence has zero length Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tsyvarev at ispras dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
[Bug libstdc++/37475] codecvt::do_in/do_out functions return ok when the output sequence has zero length
--- Comment #1 from tsyvarev at ispras dot ru 2008-09-11 09:35 --- Created an attachment (id=16291) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16291action=view) test.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
[Bug other/37474] [4.4 Regression] vect_supported_slp_permutation_p memory corruption
--- Comment #4 from irar at il dot ibm dot com 2008-09-11 09:58 ---
Testing:
Index: tree-vect-analyze.c
===
--- tree-vect-analyze.c (revision 140274)
+++ tree-vect-analyze.c (working copy)
@@ -3200,6 +3200,10 @@ vect_supported_load_permutation_p (slp_i
/* FORNOW: the only supported permutation is 0..01..1.. of length equal to
GROUP_SIZE and where each sequence of same drs is of GROUP_SIZE length as
well. */
+ if (VEC_length (int, load_permutation)
+ != (unsigned int) (group_size * group_size))
+return false;
+
supported = true;
for (j = 0; j group_size; j++)
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37474
[Bug libstdc++/37477] New: std::uncaught_exception() returns wrong value after entering terminate() in some cases
The description of uncaught_exception() throw() function states (18.6.4): Returns: true after completing evaluation of a throw-expression until either completing initialization of the exception-declaration in the matching handler or entering unexpected() due to the throw; or after entering terminate() for any reason other than an explicit call to terminate(). Apart from an explicit call to terminate() from the user's code, terminate() is called in the following situations (15.5.1): 1. When the exception handling mechanism, after completing evaluation of the expression to be thrown but before the exception is caught, calls a user function that exits via an uncaught exception. 2. When the exception handling mechanism cannot find a handler for a thrown exception. 3. When the destruction of an object during stack unwinding exits using an exception. 4. When construction or destruction of a non-local object with static storage duration exits using an exception. 5. When execution of a function registered with atexit exits using an exception. 6. When a throw-expression with no operand attempts to rethrow an exception and no exception is being handled. 7. When unexpected throws an exception which is not allowed by the previously violated exception specification, and std::bad_exception is not included in that exception-specification. However std::uncaught_exception called within a terminate_handler returns false in the cases 2,4,5,7 and true in the other cases (terminate_handler is specified using std::set_terminate()). The attached examples demonstrate the above 7 situations when terminate() is called implicitly and display the return value of std::uncaught_exception(). For example, reproducing situation 2: [EMAIL PROTECTED]:/mnt/hgfs/shared/temp/test$ g++ -Wall test2.cpp ./a.out Exception will be thrown and it won't be catched. This situation meets the following condition when terminate should be called: 2.When the exception handling mechanism cannot find a handler for a thrown exception. Inside terminate_handler uncaught_exception() returns *false*. terminate called after throwing an instance of 'char const*' Aborted (core dumped) [EMAIL PROTECTED]:/mnt/hgfs/shared/temp/test$ g++ --version g++ (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4) Copyright (C) 2006 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. -- Summary: std::uncaught_exception() returns wrong value after entering terminate() in some cases Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tsyvarev at ispras dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37477
[Bug libstdc++/37477] std::uncaught_exception() returns wrong value after entering terminate() in some cases
--- Comment #1 from tsyvarev at ispras dot ru 2008-09-11 10:18 --- Created an attachment (id=16292) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16292action=view) test.tar Reproduce situations when terminate is called implicitly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37477
[Bug libstdc++/37477] std::uncaught_exception() returns wrong value after entering terminate() in some cases
--- Comment #2 from paolo dot carlini at oracle dot com 2008-09-11 10:29 --- Note this is a libsupc++ issue, we don't have a specific Bugzilla component, but as a matter of fact the code has been mostly implemented and maintained by different people than the libstdc++ maintainers... I'm afraid it will take some time to review the issue and in case work on the code. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37477
[Bug libstdc++/37475] codecvt::do_in/do_out functions return ok when the output sequence has zero length
--- Comment #2 from paolo dot carlini at oracle dot com 2008-09-11 10:31 --- http://gcc.gnu.org/ml/libstdc++/2008-09/msg00090.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
[Bug c/37476] New: Initialising a union member of a struct without braces
Compiling:
typedef struct t {
char *d;
union {
int aa;
float ab;
} a;
} T;
int f() {
T s = {one, 1};
return s.a.aa;
}
with -Wall --std=c99 yields:
structinit.c: In function 'f':
structinit.c:10: warning: missing braces around initializer
structinit.c:10: warning: (near initialization for 's.a')
However, my understanding of C99[/TC3] section 6.7.8, point 17 and in
particular footnote 129 suggests that this initialisation is quite valid.
(Tested here against gcc version 4.2.1 20070719 [FreeBSD]; 3.2.3 on redhat
produced the same warning.)
--
Summary: Initialising a union member of a struct without braces
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stl at koffein dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37476
[Bug libstdc++/37478] New: undefined reference to `ctypewchar_t const use_facetctypewchar_t(locale const)'
Compiling anything I get: undefined reference to `std::ctypewchar_t const std::use_facetstd::ctypewchar_t (std::locale const)@GLIBCXX_3.4' -- Summary: undefined reference to `ctypewchar_t const use_facetctypewchar_t(locale const)' Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chris dot fairles at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37478
[Bug libstdc++/37478] undefined reference to `ctypewchar_t const use_facetctypewchar_t(locale const)'
--- Comment #1 from paolo dot carlini at oracle dot com 2008-09-11 11:12 --- Hey Chris, it's something on your side, because as you can see on testresults nobody has any problem (myself included ;) -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37478
[Bug bootstrap/37441] [4.4 regression] dwarf2 unwind info patches produce undefined symbols
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2008-09-11 11:23 --- Subject: Re: [4.4 regression] dwarf2 unwind info patches produce undefined symbols jakub at gcc dot gnu dot org writes: references undefined label. I'm afraid at least until some support is added to gas to handle that, we should: #ifdef MIPS_DEBUGGING_INFO return false; #endif early in dwarf2out_do_cfi_asm. Wonder why alpha defines MIPS_DEBUGGING_INFO too and if e.g. alpha-linux needs to emit DW_AT_MIPS_fde attributes. The following patch Index: gcc/dwarf2out.c === --- gcc/dwarf2out.c (revision 140226) +++ gcc/dwarf2out.c (working copy) @@ -139,6 +139,9 @@ dwarf2out_do_cfi_asm (void) if (!flag_dwarf2_cfi_asm || !dwarf2out_do_frame ()) return false; +#ifdef MIPS_DEBUGGING_INFO + return false; +#endif if (!eh_personality_libfunc) return true; if (!HAVE_GAS_CFI_PERSONALITY_DIRECTIVE) allowed for the bootstrap to complete. The testsuite is still running; when it's done, I'll submit it to gcc-patches. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37441
[Bug c++/37480] New: GCC Allows null-references in C++
It's possible to create null references which contradicts the standard:
Assume simple structs:
templatetypename T
struct null_val {
null_val(T t = T()) : value(t) {}
T value;
};
templatetypename T
struct null_ref : null_valT {};
Now it's possible to use 'null_refint().value' which is null reference!
--
Summary: GCC Allows null-references in C++
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rarut at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37480
[Bug fortran/37472] bad output on default-format write of double in common block with -m64 flag i
--- Comment #3 from dominiq at lps dot ens dot fr 2008-09-11 11:37 --- I cannot reproduce it on ppc/intel Darwin9, however the following code: PROGRAM bug IMPLICIT NONE DOUBLE PRECISION r COMMON /91/ r DOUBLE PRECISION x x = 1000 write(6,*) 'x = ', x r = 1000 write(6,*) 'r = ', r x = 1001 write(6,*) 'x = ', x r = 1001 write(6,*) 'r = ', r END gives x =1000.000 r =1000.000 x =1001.000 r =1001.000 with gfortran 4.2.3 and x = 1000.00 r = 1000.00 x =1001.0 r =1001.0 with 4.3.2 and 4.4.0 (trunk). Is this expected? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37472
[Bug web/37479] New: -fdwarf2-cfi-asm is undocumented
I just noticed that the new -fdwarf2-cfi-asm option isn't documented in gcc/doc/invoke.texi. Filing as component other since there seems to be noc doc component. -- Summary: -fdwarf2-cfi-asm is undocumented Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: any GCC host triplet: any GCC target triplet: any http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37479
[Bug tree-optimization/36881] [4.4 Regression] Creating runtime relocations for code which does not need it
--- Comment #5 from jamborm at gcc dot gnu dot org 2008-09-11 11:42 --- I guess this is mine. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-11 11:42:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36881
[Bug c++/37480] GCC Allows null-references in C++
--- Comment #1 from rarut at mail dot ru 2008-09-11 11:45 --- Generally reference members when used like this seem to behaive like pointers: - have default constructor (making null reference) - store garbage when when left uninitialized -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37480
[Bug objc/37460] [4.4 Regression]: objc.dg/super-class-2.m objc.dg/zero-link-1.m objc.dg/zero-link-2.m ICE
--- Comment #2 from dominiq at lps dot ens dot fr 2008-09-11 11:45 --- I see the same errors (a lot of them) on Darwin (see also http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00938.html). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37460
[Bug c++/37480] GCC Allows null-references in C++
--- Comment #2 from paolo dot carlini at oracle dot com 2008-09-11 12:01 --- This is already fixed in mainline and 4_3-branch. I bet this PR is a duplicate... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37480
[Bug tree-optimization/37474] [4.4 Regression] vect_supported_slp_permutation_p memory corruption
--- Comment #5 from irar at gcc dot gnu dot org 2008-09-11 12:09 --- Subject: Bug 37474 Author: irar Date: Thu Sep 11 12:08:01 2008 New Revision: 140276 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140276 Log: PR tree-optimization/37474 * tree-vect-analyze.c (vect_supported_load_permutation_p): Check the length of load permutation. Added: trunk/gcc/testsuite/gcc.dg/vect/pr37474.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-analyze.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37474
[Bug middle-end/37448] [4.3 Regression] gcc 4.3.1 cannot compile big function
--- Comment #10 from hubicka at gcc dot gnu dot org 2008-09-11 12:36 --- Subject: Bug 37448 Author: hubicka Date: Thu Sep 11 12:34:53 2008 New Revision: 140281 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140281 Log: PR middle-end/37448 * tree-inline.c (add_lexical_block): Replace with ... (prepend_lexical_block): ... prepend at begginig. (remap_blocks): Use it and reverse later. (expand_call_inline): Use prepend_lexical_block. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
[Bug middle-end/37448] [4.3 Regression] gcc 4.3.1 cannot compile big function
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-09-11 12:40 --- Subject: Bug 37448 Author: hubicka Date: Thu Sep 11 12:38:57 2008 New Revision: 140284 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140284 Log: PR middle-end/37448 * cgraph.c (cgraph_create_edge): Use !cgraph_edge for sanity check. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
[Bug fortran/36599] [4.3 regression] induct.f90 polyhedron benchmark in 4.3.1 on Intel
--- Comment #17 from pault at gcc dot gnu dot org 2008-09-11 13:11 --- I agree with Dominique's last comment and have closed this PR accordingly. Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36599
[Bug tree-optimization/37474] [4.4 Regression] vect_supported_slp_permutation_p memory corruption
--- Comment #6 from jakub at gcc dot gnu dot org 2008-09-11 13:24 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37474
[Bug target/37364] [4.4 Regression] IRA generates inefficient code due to missing regmove pass
--- Comment #15 from bonzini at gnu dot org 2008-09-11 13:46 --- Uros, does your comment #11 apply also to SSE registers (Yi), which could alleviate for PR 37437, or only to MMX (Ym)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
[Bug debug/34037] [4.2/4.3/4.4 Regression] Bounds for VLAs not emitted into debuginfo
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||09/msg00903.html Status|NEW |ASSIGNED Last reconfirmed|2007-11-09 07:32:12 |2008-09-11 13:50:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34037
[Bug fortran/37472] bad output on default-format write of double in common block with -m64 flag i
--- Comment #4 from burnus at gcc dot gnu dot org 2008-09-11 14:27 --- Jerry, do you know why gfortran 4.3/4.4 prints one trailing zero more for 1000 than for other numbers? 4.2 used the same number of trailing digits. 1000.0 1001. for print *, 1000.0 print *, 1001.0 end If one uses 0.2 more, one gets the expected 1000.2000 1001.2000 And for 100.0 it is off by one again. (Maybe you have also an idea about the problem in comment 0.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37472
[Bug c/37476] Initialising a union member of a struct without braces
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-09-11 14:46 --- This is a stylistic warning from -Wall that the code is potentially confusing, not that the code is invalid. If you don't want such warnings, don't use -Wall, or use -Wno-missing-braces. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37476
[Bug middle-end/37053] [4.3/4.4 regression] ICE in reload_cse_simplify_operands, at postreload.c:395
--- Comment #3 from schwab at suse dot de 2008-09-11 15:19 --- Caused by: 2007-07-23 Peter Bergner [EMAIL PROTECTED] Jakub Jelinek [EMAIL PROTECTED] PR middle-end/PR28690 Can be reproduced with gcc.c-torture/execute/20060420-1.c when compiled with -O2. -- schwab at suse dot de changed: What|Removed |Added CC||bergner at vnet dot ibm dot ||com, jakub at redhat dot com OtherBugsDependingO||28690 nThis|| Status|UNCONFIRMED |NEW Component|target |middle-end Ever Confirmed|0 |1 GCC build triplet|m68k-linux-gnu | GCC host triplet|m68k-linux-gnu | Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2008-09-11 15:19:57 date|| Summary|ICE in |[4.3/4.4 regression] ICE in |reload_cse_simplify_operands|reload_cse_simplify_operands |, at postreload.c:395 |, at postreload.c:395 Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
[Bug middle-end/37053] [4.3/4.4 regression] ICE in reload_cse_simplify_operands, at postreload.c:395
--- Comment #4 from bonzini at gnu dot org 2008-09-11 15:29 --- I think there is a missing constrain_operands somewhere, because in (define_insn *addsi3_internal [(set (match_operand:SI 0 nonimmediate_operand =m,?a,?a,d,a) (plus:SI (match_operand:SI 1 general_operand %0,a,rJK,0,0) (match_operand:SI 2 general_src_operand dIKLT,rJK,a,mSrIKLT,mSrIKLs)))] the insn does match the fourth alternative with operands 1 and 2 commuted. -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
[Bug target/37395] [4.4 Regression] Bootstrap fails in stage 2 due to segfault compiling c-parser
--- Comment #6 from tbm at cyrius dot com 2008-09-11 15:36 --- Adding Adam Nemet since I see the segfault on a Cavium Octeon based machine (from Movidis). -- tbm at cyrius dot com changed: What|Removed |Added CC||nemet at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37395
[Bug c/37481] New: -pedantic accepts flexible array member = string initialization
struct Foo { int i; char a[]; } foo = { 1, }; // No warning
struct Bar { int i; char a[]; } bar = { 1, {0} }; // Warning
Line 1 passes -pedantic, but C99 6.7.2.1p16 says it is invalid:
Flexible array members are ignored except with ',', '-',
and for aligning the size of the struct.
Related: Bug 20407: g++ does reject it, even without -pedantic.
--
Summary: -pedantic accepts flexible array member = string
initialization
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37481
[Bug fortran/37319] [4.4 Regression] FAIL: gfortran.dg/function_kinds_5.f90
--- Comment #4 from dominiq at lps dot ens dot fr 2008-09-11 16:33 --- At r140286 with the patch in http://gcc.gnu.org/ml/fortran/2008-09/msg00210.html, the failure is gone!-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37319
[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR
--- Comment #10 from dodji at gcc dot gnu dot org 2008-09-11 16:40 --- Created an attachment (id=16293) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16293action=view) another patch that fixes the problem. This patch proposes a fix for the problem and complies with my comment http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37146#c9 . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37146
[Bug middle-end/37372] [graphite] SCoP detection splits bbs / Define SCoPs with single entry and exit edge
--- Comment #2 from spop at gcc dot gnu dot org 2008-09-11 16:47 --- Jan proposed to switch to a different algorithm for detecting scops based on the fact that scops are single entry, single exit regions. Instead of detecting scops from the innermost to the outermost, we should instead build a tree of SESE regions, then from the outermost SESE ask whether the region contains side effects, in which case we can walk down to an inner SESE region that does not contain side effects. When a SESE does not contain side effects, and does contain interesting code for graphite, i.e. loops, we do build a scop for it. We are working on an implementation of this algorithm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37372
[Bug target/37482] New: [4.4 Regression] definition in block 51 follows the use for SSA_NAME with -maltivec
With current trunk on powerpc (revision 140291) (sid)2635:[EMAIL PROTECTED]: ..4.3-2008-09-11-r140291/gcc] ./cc1 -quiet -O3 -maltivec ~/mednafen-convert.i sexyal/convert.c: In function 'SexiALI_Convert': sexyal/convert.c:42: error: definition in block 51 follows the use for SSA_NAME: vect_var_.1177_3267 in statement: vect_var_.1185_3278 = [vec_unpack_hi_expr] vect_var_.1177_3267; sexyal/convert.c:42: internal compiler error: verify_ssa failed Please submit a full bug report, -- Summary: [4.4 Regression] definition in block 51 follows the use for SSA_NAME with -maltivec Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC build triplet: powerpc-unknown-linux-gnu GCC host triplet: powerpc-unknown-linux-gnu GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37482
[Bug target/37483] New: [4.4 Regression] Segfault in noce_try_sign_mask (ifcvt.c): b_unconditional
With current trunk on powerpc (revision 140291): (sid)2644:[EMAIL PROTECTED]: ..4.3-2008-09-11-r140291/gcc] ./cc1plus -quiet -O3 -maltivec ~/gdc-4.2-constfold.ii ../../src/gcc/d/dmd/constfold.c: In function 'Expression* Ushr(Type*, Expression*, Expression*)': ../../src/gcc/d/dmd/constfold.c:635: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: [4.4 Regression] Segfault in noce_try_sign_mask (ifcvt.c): b_unconditional Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC build triplet: powerpc-unknown-linux-gnu GCC host triplet: powerpc-unknown-linux-gnu GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37483
[Bug target/37483] [4.4 Regression] Segfault in noce_try_sign_mask (ifcvt.c): b_unconditional
--- Comment #1 from tbm at cyrius dot com 2008-09-11 16:55 --- Created an attachment (id=16294) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16294action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37483
[Bug target/37482] [4.4 Regression] definition in block 51 follows the use for SSA_NAME with -maltivec
--- Comment #1 from tbm at cyrius dot com 2008-09-11 16:55 --- Created an attachment (id=16295) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16295action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37482
[Bug c/35712] decimal float literal constant zero loses significant trailing zeroes
-- janis at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-11 16:55:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35712
[Bug c/35712] decimal float literal constant zero loses significant trailing zeroes
--- Comment #3 from janis at gcc dot gnu dot org 2008-09-11 16:56 --- Fixed in mainline. It's not a regression so the fix has not been applied to 4.3. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35712
[Bug target/37483] [4.4 Regression] Segfault in noce_try_sign_mask (ifcvt.c): b_unconditional
--- Comment #2 from tbm at cyrius dot com 2008-09-11 16:57 --- (gdb) run -quiet -O3 -maltivec ~/gdc-4.2-constfold.ii Starting program: /home/tbm/tmp/gcc/4.3-2008-09-11-r140291/gcc/cc1plus -quiet -O3 -maltivec ~/gdc-4.2-constfold.ii Program received signal SIGSEGV, Segmentation fault. noce_try_sign_mask (if_info=0xffe18670) at gcc/ifcvt.c:1905 1905 b_unconditional = (if_info-insn_b == NULL_RTX (gdb) where #0 noce_try_sign_mask (if_info=0xffe18670) at gcc/ifcvt.c:1905 #1 0x108056f8 in noce_process_if_block (if_info=0xffe18670) at gcc/ifcvt.c:2399 #2 0x10808168 in if_convert () at gcc/ifcvt.c:2848 #3 0x10808570 in rest_of_handle_if_after_combine () at gcc/ifcvt.c:4209 #4 0x103f9094 in execute_one_pass (pass=0x10acbe58) at gcc/passes.c:1279 #5 0x103f93c4 in execute_pass_list (pass=0x10acbe58) at gcc/passes.c:1327 #6 0x103f93dc in execute_pass_list (pass=0x10ac7470) at gcc/passes.c:1328 #7 0x10525174 in tree_rest_of_compilation (fndecl=0xf7976b00) at gcc/tree-optimize.c:418 #8 0x106d7e70 in cgraph_expand_function (node=0xf7986600) at gcc/cgraphunit.c:1038 #9 0x106da444 in cgraph_optimize () at gcc/cgraphunit.c:1097 #10 0x100ba4e8 in cp_write_global_declarations () at gcc/cp/decl2.c:3608 #11 0x104c3f28 in toplev_main (argc=value optimized out, argv=value optimized out) at gcc/toplev.c:979 #12 0x101dad50 in main (argc=value optimized out, argv=value optimized out) at gcc/main.c:35 (gdb) -- tbm at cyrius dot com changed: What|Removed |Added Summary|[4.4 Regression] Segfault in|[4.4 Regression] Segfault in |noce_try_sign_mask |noce_try_sign_mask |(ifcvt.c): b_unconditional |(ifcvt.c): b_unconditional http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37483
[Bug c/37481] -pedantic accepts flexible array member = string initialization
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||16989 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-11 16:58:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37481
[Bug target/37483] [4.4 Regression] Segfault in noce_try_sign_mask (ifcvt.c): b_unconditional
--- Comment #3 from tbm at cyrius dot com 2008-09-11 17:08 --- Created an attachment (id=16296) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16296action=view) Preprocessed source Here's another testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37483
[Bug c/37484] [graphite] Valgrind gives invalid reads/writes on CPU2006 403.gcc benchmark
--- Comment #1 from harsha dot jagasia at amd dot com 2008-09-11 17:15 --- Created an attachment (id=16297) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16297action=view) Fixes invalid reads/writes for cpu2006 403.gcc benchmark. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37484
[Bug target/37364] [4.4 Regression] IRA generates inefficient code due to missing regmove pass
--- Comment #16 from ubizjak at gmail dot com 2008-09-11 17:33 --- (In reply to comment #15) Uros, does your comment #11 apply also to SSE registers (Yi), which could alleviate for PR 37437, or only to MMX (Ym)? Comment #11 is also true for Yi SSE registers (for TARGET_INTER_UNIT_MOVES targets, i.e. -march=core2). Under integer register shortage, allocator will start to allocate SSE registers, and reload will later generate various xmm-reg moves to satisfy subsequent instruction constraints. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
[Bug c/37484] New: [graphite] Valgrind gives invalid reads/writes on CPU2006 403.gcc benchmark
Valgrind report
---
valgrind --leak-check=yes ./cc1 -DSPEC_CPU -DNDEBUG -I
~/WORK/benchmarks/cpu2006/benchspec/CPU2006/403.gcc/src -O2 -fgraphite
-floop-block -DSPEC_CPU_LP64
~/WORK/benchmarks/cpu2006/benchspec/CPU2006/403.gcc/src/c-common.c
==23086== Memcheck, a memory error detector.
==23086== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==23086== Using LibVEX rev 1804, a library for dynamic binary translation.
==23086== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==23086== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation
framework.
==23086== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==23086== For more details, rerun with: -v
==23086==
vprintf getchar fgetc_unlocked getc_unlocked getchar_unlocked putchar
fputc_unlocked putc_unlocked putchar_unlocked getline feof_unlocked
ferror_unlocked gnu_dev_major gnu_dev_minor gnu_dev_makedev __strcspn_c1
__strcspn_c2 __strcspn_c3 __strspn_c1 __strspn_c2 __strspn_c3 __strpbrk_c2
__strpbrk_c3 __strtok_r_1c __strsep_1c __strsep_2c __strsep_3c atof atoi atol
atoll stat lstat fstat fstatat mknod mknodat stat64 lstat64 fstat64 fstatat64
{GC 5348k - 4111k} {GC 5348k - 4817k} {GC 6263k - 5814k} c_expand_start_cond
c_finish_then c_expand_end_cond c_expand_start_else c_finish_else
c_begin_if_stmt c_begin_while_stmt c_finish_while_stmt_cond start_fname_decls
finish_fname_decls fname_as_string fname_string fname_decl combine_strings
constant_expression_warning overflow_warning unsigned_conversion_warning
constant_fits_type_p convert_and_check new_tlist add_tlist merge_tlist
warn_for_collisions_1 warn_for_collisions warning_candidate_p verify_tree
verify_sequence_points c_expand_expr_stmt check_case_value type_for_size
type_for_mode unsigned_type signed_type signed_or_unsigned_type {GC 7615k -
6939k} min_precision binary_op_error shorten_compare pointer_int_sum
truthvalue_conversion c_build_qualified_type c_apply_type_quals_to_decl
c_common_get_alias_set c_alignof c_alignof_expr c_common_nodes_and_builtins {GC
14498k - 8593k} build_va_arg disable_builtin_function
builtin_function_disabled_p builtin_function_2 c_promoting_integer_type_p
simple_type_promotes_to self_promoting_args_p strip_array_types
expand_tree_builtin statement_code_p walk_stmt_tree case_compare
c_add_case_label finish_label_address_expr mark_stmt_tree c_mark_lang_decl
mark_c_language_function c_expand_expr c_safe_from_p c_unsafe_for_reeval
c_staticp add_c_tree_codes c_expand_builtin is_valid_printf_arglist
c_expand_builtin_printf c_expand_builtin_fprintf boolean_increment
c_common_init_options c_common_post_options c_common_init c_common_finish
c_init_attributes c_common_insert_default_attributes shadow_warning
Analyzing compilation unit
{GC 11173k - 8824k}Performing interprocedural optimizations
visibility early_local_cleanups summary generate cp inline
static-var pure-constAssembling functions:
c_expand_start_else c_finish_while_stmt_cond fname_as_string fname_string
type_for_size signed_or_unsigned_type signed_type unsigned_type
c_promoting_integer_type_p simple_type_promotes_to self_promoting_args_p {GC
11474k - 7633k} strip_array_types statement_code_p walk_stmt_tree
c_mark_lang_decl c_unsafe_for_reeval c_staticp overflow_warning shadow_warning
start_fname_decls c_init_attributes c_common_insert_default_attributes
c_common_finish c_common_init c_common_post_options c_common_init_options
boolean_increment add_c_tree_codes c_safe_from_p c_apply_type_quals_to_decl
binary_op_error is_valid_printf_arglist c_expand_builtin_fprintf mark_stmt_tree
mark_c_language_function {GC 9930k - 6927k} constant_expression_warning
finish_label_address_expr build_va_arg case_compare expand_tree_builtin
disable_builtin_function type_for_mode c_build_qualified_type
builtin_function_2 c_common_nodes_and_builtins c_alignof {GC 9005k - 6033k}
c_alignof_expr c_common_get_alias_set truthvalue_conversion pointer_int_sum
shorten_compare min_precision check_case_value {GC 7846k - 5463k}
c_finish_else c_expand_end_cond c_finish_then c_begin_while_stmt
c_begin_if_stmt new_tlist warn_for_collisions_1 warn_for_collisions merge_tlist
add_tlist verify_tree c_expand_expr_stmt unsigned_conversion_warning
convert_and_check c_add_case_label {GC 7103k - 5110k} combine_strings==23086==
Invalid write of size 1
==23086==at 0x5CA9647: _IO_default_xsputn (in /lib/libc-2.7.so)
==23086==by 0x5C7EBD2: vfprintf (in /lib/libc-2.7.so)
==23086==by 0x5C9EBC8: vsprintf (in /lib/libc-2.7.so)
==23086==by 0x5C87007: sprintf (in /lib/libc-2.7.so)
==23086==by 0xAA0388: find_transform (graphite.c:1985)
==23086==by 0xAA6BA9: graphite_transform_loops (graphite.c:4784)
==23086==by 0x7AA9B6: graphite_transforms (tree-ssa-loop.c:298)
==23086==by 0x6398FC: execute_one_pass (passes.c:1279)
==23086==by 0x639AF0: execute_pass_list (passes.c:1327)
==23086==by 0x639B04: execute_pass_list (passes.c:1328)
==23086==by 0x639B04:
[Bug target/35620] ICE passing dereferenced pointer to _Decimal32
--- Comment #3 from janis at gcc dot gnu dot org 2008-09-11 17:35 --- Fixed on mainline. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35620
[Bug libstdc++/37475] [DR 382] codecvt::do_in/do_out functions return ok when the output sequence has zero length
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-11 17:39:18 date|| Summary|codecvt::do_in/do_out |[DR 382] |functions return ok when |codecvt::do_in/do_out |the output sequence has zero|functions return ok when |length |the output sequence has zero ||length http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
[Bug libstdc++/37475] [DR 382] codecvt::do_in/do_out functions return ok when the output sequence has zero length
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
[Bug target/37096] conditional evaluation incorrect with -O3
--- Comment #7 from ubizjak at gmail dot com 2008-09-11 17:57 --- There is a runtime difference between -O1 and -O2: g++ -O1 pr37096.cpp main.o ./a.out nz: 3 g++ -O2 pr37096.cpp main.o ./a.out nz: 3 98 Target: x86_64-unknown-linux-gnu gcc version 4.4.0 20080911 (experimental) [trunk revision 140293] (GCC) Probably target issue, I will look into it. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|WAITING |ASSIGNED Component|middle-end |target Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-11 17:57:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37096
[Bug target/37096] conditional evaluation incorrect with -O3
--- Comment #8 from ubizjak at gmail dot com 2008-09-11 18:16 ---
Hm, with -O2 -fno-strict-aliasing, it works fine.
Is there an aliasing issue involved?
short Transform4x4(short *pMatrix)
{
__m128i r4, r5;
__m128i r0 = _mm_loadl_epi64((__m128i *)(pMatrix + 0 * 16));
__m128i r1 = _mm_loadl_epi64((__m128i *)(pMatrix + 1 * 16));
__m128i r2 = _mm_loadl_epi64((__m128i *)(pMatrix + 2 * 16));
__m128i r3 = _mm_loadl_epi64((__m128i *)(pMatrix + 3 * 16));
... stuff ...
_mm_storel_epi64((__m128i *)(pMatrix + 0 * 16), r0);
_mm_storel_epi64((__m128i *)(pMatrix + 1 * 16), r1);
_mm_storel_epi64((__m128i *)(pMatrix + 2 * 16), r2);
_mm_storel_epi64((__m128i *)(pMatrix + 3 * 16), r3);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37096
[Bug fortran/37199] array assignment from function writes out of bounds
--- Comment #8 from domob at gcc dot gnu dot org 2008-09-11 19:15 --- Subject: Bug 37199 Author: domob Date: Thu Sep 11 19:13:59 2008 New Revision: 140296 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140296 Log: 2008-09-08 Daniel Kraft [EMAIL PROTECTED] PR fortran/37199 * trans-expr.c (gfc_add_interface_mapping): Set new_sym-as. (gfc_map_intrinsic_function): Added checks against NULL bounds in array specs. 2008-09-08 Daniel Kraft [EMAIL PROTECTED] PR fortran/37199 * gfortran.dg/array_function_2.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/array_function_2.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/trans-expr.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37199
[Bug fortran/37199] array assignment from function writes out of bounds
--- Comment #9 from domob at gcc dot gnu dot org 2008-09-11 19:15 --- Fixed on 4.3 branch. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37199
[Bug fortran/37355] Request runtime preconnected buffer option for gfortran
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-09-11 19:30 --- (In reply to comment #2) Yes, FLUSH works, but * I don't think it was part of standards until 2003, * I need to place it several places in my code, * I really didn't want gfortran specific code if I could avoid it * There isn't a problem with buffering on our other compilers on HP-UX. c89 + HP F90 work fine for buffer synchronization. I guess I will have to assume my feature request is denied. Actually, it's not :-) Confirmed. I'll think about this a little bit. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-11 19:30:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37355
[Bug fortran/18584] --std=f would be nice
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-09-11 19:48 --- Do we really want to do this any more? I nobody objects, I'll close this as WONTFIX in a few days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18584
[Bug fortran/37468] error when combining -i8 with .F files
--- Comment #2 from charles at schwieters dot org 2008-09-11 19:51 --- thanks for pointing that out. -fdefault-integer-8 works fine. However, the -i8 behavior *is* confusing: % gfortran -c -i8 t.f % gfortran -c -i8 t.F cc1: error: unrecognized command line option -i8 i.e. it *seems* to work for .f files, but not for .F files. -- charles at schwieters dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37468
[Bug c/37485] New: [graphite] Disconnecting exit edge in process of code generation
In tranlate_clast when clast stmt is a stmt_user, we can end up disconnecting the edge that is the exit_edge of the scop that is transformed. This state creates problems because the exit_edge no longer has a destination. Hence when after translate_clast, the exit_edge is redirected with redirect_edge_succ, the edge is already disconnected. -- Summary: [graphite] Disconnecting exit edge in process of code generation Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: harsha dot jagasia at amd dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37485
[Bug middle-end/37485] [graphite] Disconnecting exit edge in process of code generation
--- Comment #1 from harsha dot jagasia at amd dot com 2008-09-11 20:05 --- Created an attachment (id=16298) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16298action=view) Reduced test case for bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37485
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- Comment #19 from joel at gcc dot gnu dot org 2008-09-11 20:08 --- Now merged on SVN trunk. Closing. Thanks Arnaud. -- joel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug ada/21327] gnat_ugn.texi invalid @direntry
--- Comment #4 from joel at gcc dot gnu dot org 2008-09-11 20:12 --- ping. Still not fixed as of 20080910 [trunk revision 140246] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21327
[Bug target/37482] [4.4 Regression] definition in block 51 follows the use for SSA_NAME with -maltivec
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37482
[Bug target/37483] [4.4 Regression] Segfault in noce_try_sign_mask (ifcvt.c): b_unconditional
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37483
[Bug tree-optimization/37482] [4.4 Regression] definition in block 51 follows the use for SSA_NAME with -maltivec
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-11 20:23 --- Reducing ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37482
[Bug tree-optimization/37482] [4.4 Regression] definition in block 51 follows the use for SSA_NAME with -maltivec
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-11 20:30 ---
Nice reduced testcase:
void SexiALI_Convert(void *vdest, void *vsrc, unsigned int frames)
{
unsigned int x;
short *src = vsrc;
unsigned char *dest = vdest;
for(x=0;xframes;x++)
{
int tmp;
tmp = *src;
src++;
tmp += *src;
src++;
*dest++ = tmp;
*dest++ = tmp;
}
}
--- CUT ---
This is caused by the vectorizer.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||dorit at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-09-11 20:30:49
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37482
[Bug fortran/18584] --std=f would be nice
--- Comment #7 from burnus at gcc dot gnu dot org 2008-09-11 20:49 --- Do we really want to do this any more? I nobody objects, I'll close this as WONTFIX in a few days. I think some are still interested in F; however, as it is does not support the new Fortran 2003/2008 features, I see it as dead end similar to HPF (high-performance Fortran). [Well, seemingly not even F90's namelists are supported :-(] Thus I'm in favour for WONTFIX - especially as even the bug reporter is no longer interested ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18584
[Bug fortran/37486] New: alignment of data in COMMON blocks
Currently, gfortran automatically aligns data in COMMON blocks, as in the following example: implicit none integer(kind=4) :: n real(kind=8) :: p common /foo/ n,p end This gives the warning: COMMON 'foo' at (1) requires 4 bytes of padding at start This automatic padding can result in unexpected results, as demonstrated by the following code: subroutine one() implicit none integer :: n1,n2,n3,n4 common /foo/ n1,n2(2),n3,n4 print *, n3, n4 end subroutine one program prog implicit none integer :: n1,n2,n3 real(8) :: r1 common /foo/ n1,r1,n2,n3 n2 = 2 n3 = 3 call one() end program prog The output of this program is 0 2 instead of 2 3. Therefore gfortran should have an option to suppress automatic alignment. Preferrably this option should be enabled by default. See also http://gcc.gnu.org/ml/fortran/2008-09/msg00221.html -- Summary: alignment of data in COMMON blocks Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37486
[Bug c++/37487] New: invalid return by value optimization
For return by value optimization, instead of calling the copy constructor or
the assignment operator, gcc decides to optimize and push the address of the
lhs of the expression into the rhs.
Foo createFoo() { Foo f2; return f2; }
int main(){
Foo f1 = createFoo();
return 0;
}
OPTIMIZED TO
void createFoo( Foo f2 ) {...}
int main() {
Foo f1;
createFoo(f1);
return 0;
}
This is a problem when you want to explicitly define the copy constructor or
assignment operator to do something other than deep copying.
--
Summary: invalid return by value optimization
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: khoaduynguyen at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37487
[Bug c++/37487] invalid return by value optimization
--- Comment #1 from khoaduynguyen at gmail dot com 2008-09-11 21:00 --- Created an attachment (id=16299) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16299action=view) Reproduction -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37487
[Bug target/37395] [4.4 Regression] Bootstrap fails in stage 2 due to segfault compiling c-parser
--- Comment #7 from nemet at gcc dot gnu dot org 2008-09-11 21:00 --- I was able to reproduce this with 140295. Assigning to myself. -- nemet at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nemet at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-11 21:00:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37395
[Bug c++/37487] invalid return by value optimization
--- Comment #2 from khoaduynguyen at gmail dot com 2008-09-11 21:02 --- -bash-3.1$ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20070626 (Red Hat 4.1.2-14) [EMAIL PROTECTED] ~]$ g++ test2.cpp [EMAIL PROTECTED] ~]$ ./a.out In main Base(int), id=0, this=0x7946c390 Base(const Base k), id=1, this=0x7946c2e0 Derived(const Base), id=1, this=0x7946c2e0 Test1 -- d.id=0 Base(int), id=2, this=0x7946c3a0 Base(const Base k), id=3, this=0x7946c260 Derived(const Base), id=3, this=0x7946c260 Test2 -- d2.id=3 int Derived.test() Base(int), id=4, this=0x7946c1e0 Derived(), id=4, this0x7946c1e0 Test3 -- d3.id=4 int Derived.test() Base(int), id=5, this=0x7946c380 Test4 -- b4.id=5, b4=0x7946c380 Base(), id=6, this=0x7946c370 Base(), id=7, this=0x7946c360 Base Operator=(const Base), id=8, this=0x7946c360 Base(const Base k), id=9, this=0x7946c160 Derived(const Base), id=9, this=0x7946c160 Test4 -- b4.id=9, b4=0x7946c160 -- khoaduynguyen at gmail dot com changed: What|Removed |Added Summary|invalid return by value |invalid return by value |optimization|optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37487
[Bug c++/37487] invalid return by value optimization
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-11 21:02 --- This is allowed by the standard. THe compiler can elide constructors as defined by the C++ standard. If you want not this behavior use -fno-elide-constructors. -- 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=37487
[Bug target/37483] [4.4 Regression] Segfault in noce_try_sign_mask (ifcvt.c): b_unconditional
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-11 21:15 ---
Here is a simple reduced testcase for the first one:
typedef unsigned long long int uint64_t;
uint64_t Ushr( unsigned count,int i)
{
uint64_t value;
if (i==0)
value = (value 0x) count;
return value;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-09-11 21:15:14
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37483
[Bug target/37395] [4.4 Regression] Bootstrap fails in stage 2 due to segfault compiling c-parser
--- Comment #8 from nemet at gcc dot gnu dot org 2008-09-11 21:46 --- It's caused by this http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02376.html. In this hunk: @@ -1901,7 +1904,8 @@ noce_try_sign_mask (struct noce_if_info INSN_B which can happen for e.g. conditional stores to memory. */ b_unconditional = (if_info-insn_b == NULL_RTX || BLOCK_FOR_INSN (if_info-insn_b) == if_info-test_bb); - if (rtx_cost (t, SET) = COSTS_N_INSNS (2) + if (rtx_cost (t, SET, optimize_bb_for_speed_p (BLOCK_FOR_INSN (if_info-insn_b))) + = COSTS_N_INSNS (2) (!b_unconditional || t != if_info-b)) return FALSE; if_info-insn_b is allowed to be null. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37395
[Bug target/37395] [4.4 Regression] Bootstrap fails in stage 2 due to segfault compiling c-parser
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-09-11 21:48 --- I think this is the same bug as PR 37483. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37395
[Bug target/37483] [4.4 Regression] Segfault in noce_try_sign_mask (ifcvt.c): b_unconditional
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-09-11 22:11 ---
And the other:
typedef struct {
short rbearing;
short width;
} XCharStruct;
typedef long I32;
typedef I32 Bool;
typedef unsigned long Handle;
typedef struct _Point {
int x;
int y;
} Point, *PPoint;
static Point
gp_get_text_overhangs( Handle self, const char *text, int len, Bool wide)
{
Point ret;
if ( len 0)
{
XCharStruct * cs;
cs = prima_char_struct( );
ret. x = ( cs- rbearing 0) ? - cs- rbearing: 0;
ret. y = (( cs- width - cs- rbearing) 0) ? cs- rbearing - cs- width
: 0;
}
else
ret. x = ret. y = 0;
return ret;
}
void gp_get_text_box( Handle self, const char * text, int len, Bool wide)
{
Point * pt = ( Point *) malloc( sizeof( Point) * 5);
int x;
Point ovx;
ovx = gp_get_text_overhangs( self, text, len, wide);
pt[2]. x = x + ovx. y;
pt[1]. x = - ovx. x;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37483
[Bug c/37488] New: register allocation spills floats needlessly
In the provided testcase, gcc spills an xmm register onto the stack even though
there is only one register being used. This does not occur with similar code
using general purpose registers.
BEGIN TESTCASE
const void* test(int action, void* ptr)
{
static void * const addrs[] = {L1, L2};
if (action == 0) {
return addrs;
} else {
char* ip = ptr;
register double reg_f_a;
double reg_f[1];
reg_f_a = 0.0;
reg_f[0] = 0.0;
goto *ip;
L1: {
int t1 = *(int*)(++ip);
reg_f_a = reg_f_a + reg_f[t1];
goto *(++ip);
}
L2:
*(double*)ptr = reg_f_a;
}
return 0;
}
END TESTCASE
The above code compiled with -O3 -march=i686 -msse2 -mfpmath=sse produces the
following bit of assembly
BEGIN OUTPUT
movl1(%ebx), %eax
addl$2, %ebx
movsd -32(%ebp), %xmm0
addsd -16(%ebp,%eax,8), %xmm0
movl%ebx, %eax
movsd %xmm0, -32(%ebp)
jmp *%eax
END OUTPUT
The xmm0 register should remain the home register for reg_f_a, so there should
be no need for the store/load. Other usages of xmm0 should be placed in xmm1.
So the output should read:
BEGIN MODIFIED 1
movl1(%ebx), %eax
addl$2, %ebx
addsd -16(%ebp,%eax,8), %xmm0
movl%ebx, %eax
jmp *%eax
END MODIFIED 1
As a possibly related issue, there is also no reason why a copy of %ebx is made
prior to performing the jump. This could just as easily be
BEGIN MODIFIED 2
movl1(%ebx), %eax
addl$2, %ebx
addsd -16(%ebp,%eax,8), %xmm0
jmp *%ebx
END MODIFIED 2
So, as you can see, three out of the seven instructions can be removed, as well
as two of four memory references.
The version of gcc is 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
--
Summary: register allocation spills floats needlessly
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jstrother9109 at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37488
[Bug c/37488] register allocation spills floats needlessly
--- Comment #1 from jstrother9109 at gmail dot com 2008-09-11 23:15 --- Created an attachment (id=16300) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16300action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37488
[Bug rtl-optimization/37489] New: In cse.c:fold_rtx(), true is represented in floating-point modes as const_true_rtx, if FLOAT_STORE_FLAG_VALUE is undefined.
Consider the c++ code:
--
class StatVal {
public:
StatVal(double ev, double va)
: m(ev),
v(va) {}
StatVal(const StatVal other)
: m(other.m),
v(other.v) {}
StatVal operator*=(const StatVal other) {
double A = m == 0 ? 1.0 : v / (m * m);
double B = other.m == 0 ? 1.0 : other.v / (other.m * other.m);
m = m * other.m;
v = m * m * (A + B);
return *this;
}
double m;
double v;
};
extern C void abort (void);
const StatVal two_dot_three(2, 0.3);
int main(int argc, char **argv) {
StatVal product3(two_dot_three);
product3 *= two_dot_three;
if (product3.v 2.5)
abort();
}
--
In the above code, product3.v should be 2.4, and the program aborts if this
value is greater than 2.5.
Compiled with the trunk gcc, the program aborts if options -O1
-fno-guess-branch-probability -fcse-follow-jumps -fgcse -frerun-cse-after-loop
are used. Lets call these baseOptions.
On the gcc-4.3 branch, this program aborts if compiled with those options, and
also if compiled with simply -O2.
Lets look at interesting snippets of assembley code generated with the trunk
compiler:
(1) First, with using baseOptions -fno-if-conversion
-fno-rerun-cse-after-loop (the test program passes with these options):
...snip...
ucomisd %xmm3, %xmm0
jne .L12
.p2align 4,,3
.p2align 3
jp .L12
movsd .LC3(%rip), %xmm0
jmp .L7
.L12:
movapd %xmm2, %xmm0
.L7:
mulsd %xmm1, %xmm1
...
(2) Second, with using baseOptions -fno-rerun-cse-after-loop (the test
program passes with these options):
...snip...
cmpneqsd%xmm3, %xmm0
movapd %xmm2, %xmm3
andpd %xmm0, %xmm3
movsd .LC3(%rip), %xmm4
andnpd %xmm4, %xmm0
orpd%xmm3, %xmm0
...
Comparing (1) and (2), the if-conversion gets rid of a few branches by
converting:
if (condX) x=a; else x = b;
into:
maskX = condX ? 0xfff.. : 0; // cmpneqsd %xmm3, %xmm0
x1 = a maskX; // andpd%xmm0, %xmm3
x2 = b ~maskX; // andnpd %xmm4, %xmm0
x = x1 | x2; // orpd %xmm3, %xmm0
(3) Lastly, with using baseOptions (the test program fails now):
...snip...
cmpneqsd%xmm3, %xmm0
movapd %xmm2, %xmm3
andpd %xmm0, %xmm3
movapd %xmm3, %xmm0
movsd .LC3(%rip), %xmm3
orpd%xmm0, %xmm3
...
What has happened is that the cse2 phase has deleted the andnpd
instruction.
We will have to look at the (.cse2) dump file to figure out why:
snip
(insn 69 15 70 3 /home/raksit/bug-test.C:17 (set (reg:DF 77)
(mem/u/c/i:DF (symbol_ref/u:DI (*.LC3) [flags 0x2]) [0 S8 A64])) 103
{*movdf_integer_rex64} (expr_list:REG_EQUAL (const_double:DF 1.0e+0 [0x0.8p+1])
(nil)))
(insn 70 69 71 3 /home/raksit/bug-test.C:17 (set (reg:DF 78)
(ne:DF (reg:DF 61 [ D.2927 ])
(reg:DF 68))) 615 {*sse_setccdf} (expr_list:REG_EQUAL (const_int 1
[0x1])
(nil)))
(insn 71 70 73 3 /home/raksit/bug-test.C:17 (set (reg:DF 79)
(and:DF (reg/v:DF 60 [ B ])
(reg:DF 78))) 1277 {*anddf3} (nil))
(insn 73 71 31 3 /home/raksit/bug-test.C:17 (set (reg/v:DF 58 [ B.25 ])
(ior:DF (reg:DF 77)
(reg:DF 79))) 1278 {*iordf3} (nil))
--
The interesting part is:
(insn 70 69 71 3 /home/raksit/bug-test.C:17 (set (reg:DF 78)
(ne:DF (reg:DF 61 [ D.2927 ])
(reg:DF 68))) 615 {*sse_setccdf} (expr_list:REG_EQUAL (const_int 1
[0x1])
(nil)))
This instruction corresponds to:
maskX = condX ? 0xfff.. : 0; // cmpneqsd %xmm3, %xmm0
Gcc is able to figure out that condX evaluates to true at compile-time -- and
this is conveyed by the REG_EQUAL (const_int 1 [0x1]) note on the
instruction.
This note which says that maskX is equal to const_int 1, is added by
cse.c:fold_rtx(). It is this REG_EQUAL note that ultimately results in the CSE
phase deleting the andnpd instruction (because, given the generated code
sequence, maskX should be folded into 0x..., not const_int 1).
The problem is in cse.c:fold_rtx(), when it folds the given floating-point-mode
RTX into a true/false value. The code in fold_rtx() checks the
FLOAT_STORE_FLAG_VALUE macro to find the correct representation of true in
floating-point modes. But if this macro is not defined (its not for the i386
target), it uses const_true_rtx, which is equal to const_int 1.
This is different behavior from something closely related in simplify-rtx.c.
In simplify-rtx.c:simplify_relational_operation():
snip
tem = simplify_const_relational_operation (code, cmp_mode, op0, op1);
if (tem)
{
if (SCALAR_FLOAT_MODE_P (mode))
{
if (tem == const0_rtx)
return CONST0_RTX (mode);
#ifdef FLOAT_STORE_FLAG_VALUE
{
REAL_VALUE_TYPE val;
val = FLOAT_STORE_FLAG_VALUE (mode);
return
[Bug rtl-optimization/37490] [4.4 Regression] IRA causes FP code to have more spills
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37490
[Bug rtl-optimization/37490] [4.4 Regression] IRA causes FP code to have more spills
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-11 23:47 --- I forgot to mention, not choosing a FLOAT_REG causes a reload to happen which did not happen before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37490
[Bug target/37489] In cse.c:fold_rtx(), true is represented in floating-point modes as const_true_rtx, if FLOAT_STORE_FLAG_VALUE is undefined.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-11 23:53 --- This is a target bug really since it is SSE which needs to set FLOAT_STORE_FLAG_VALUE correctly. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|rtl-optimization|target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37489
[Bug bootstrap/37424] [4.4 regression] IRA merge breaks Solaris/SPARC bootstrap
--- Comment #4 from hjl at gcc dot gnu dot org 2008-09-11 23:53 --- Subject: Bug 37424 Author: hjl Date: Thu Sep 11 23:52:12 2008 New Revision: 140303 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140303 Log: 2008-09-11 Eric Botcazou [EMAIL PROTECTED] PR rtl-optimization/37424 * ira-color.c (coalesced_pseudo_reg_slot_compare): Untie by comparing the regnos instead of the addresses. Modified: branches/ira-merge/gcc/ChangeLog.ira branches/ira-merge/gcc/ira-color.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37424
[Bug rtl-optimization/37490] [4.4 Regression] IRA causes FP code to have more spills
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-11 23:54 --- The exact revision I was using is: gcc version 4.4.0 20080910 (experimental) [trunk revision 140245] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37490
[Bug target/37489] In cse.c:fold_rtx(), true is represented in floating-point modes as const_true_rtx, if FLOAT_STORE_FLAG_VALUE is undefined.
--- Comment #2 from hjl dot tools at gmail dot com 2008-09-12 00:45 --- (In reply to comment #1) This is a target bug really since it is SSE which needs to set FLOAT_STORE_FLAG_VALUE correctly. How can you define FLOAT_STORE_FLAG_VALUE only for float/double when SSE math is used? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37489
[Bug target/37489] In cse.c:fold_rtx(), true is represented in floating-point modes as const_true_rtx, if FLOAT_STORE_FLAG_VALUE is undefined.
--- Comment #3 from raksit at gcc dot gnu dot org 2008-09-12 01:08 --- (In reply to comment #1) This is a target bug really since it is SSE which needs to set FLOAT_STORE_FLAG_VALUE correctly. In that case, I think simplify-rtx.c:simplify_relational_operation() is being overly conservative; and its behavior should be changed to match that of cse.c:fold_rtx() in this regard. -- raksit at gcc dot gnu dot org changed: What|Removed |Added CC||raksit at gcc dot gnu dot ||org AssignedTo|raksit at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37489
[Bug fortran/37472] bad output on default-format write of double in common block with -m64 flag i
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-09-12 03:52 --- I will have to explore a bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37472
[Bug bootstrap/37424] [4.4 regression] IRA merge breaks Solaris/SPARC bootstrap
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-09-12 05:26 --- Subject: Bug 37424 Author: ebotcazou Date: Fri Sep 12 05:24:41 2008 New Revision: 140312 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140312 Log: PR rtl-optimization/37424 * ira-color.c (coalesced_pseudo_reg_slot_compare): Untie by comparing the regnos instead of the addresses. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-color.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37424
