[Bug fortran/27304] gfortran: Warn/abort when format in write does not fit passed arguments
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-04-27 06:02 --- Tobias, I hope this is what you were looking for. I don't really think we need a compile time check. That would be pretty involved to do and the error is caught at runtime. What do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27304
[Bug testsuite/27274] execution test of gcc.dg/i386-sse-9.c fails on non-SSE CPU
--- Comment #3 from hjl at gcc dot gnu dot org 2006-04-27 06:13 --- Subject: Bug 27274 Author: hjl Date: Thu Apr 27 06:13:40 2006 New Revision: 113296 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113296 Log: 2006-04-26 H.J. Lu [EMAIL PROTECTED] PR testsuite/27274: * gcc.target/i386/sse-9.c: Include ../../gcc.dg/i386-cpuid.h. (main): Exit if processor doesn't support SSE. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/sse-9.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27274
[Bug rtl-optimization/27291] [4.2 regression] verify_flow_info failed: too many outgoing branch edges from bb 4
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-04-25 01:30:12 |2006-04-27 06:26:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27291
[Bug bootstrap/27334] gcc/Makefile.in:s-macro_list sed fails with make 3.81 due to POSIX support changes
--- Comment #1 from debian-gcc at lists dot debian dot org 2006-04-27 07:33 --- thanks for pointing that out, my mistake to check that in. Mark, ok keep that change and document that change in the existing changelog entry? * Makefile.in (s-macro_list): Conform to POSIX rules in single quoted strings Matthias -- debian-gcc at lists dot debian dot org changed: What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27334
[Bug fortran/27304] gfortran: Warn/abort when format in write does not fit passed arguments
--- Comment #8 from burnus at net-b dot de 2006-04-27 08:09 ---
Subject: Re: gfortran: Warn/abort when format in write
does not fit passed arguments
(In reply to comment #7)
Tobias, I hope this is what you were looking for. I don't really
think we need
a compile time check. That would be pretty involved to do and the
error is
caught at runtime.
I think it is ok (though Brooks wording is probably better).
Still it would be nice if it would be detected during compile time. In
my case it was burried in an
if(something that rarely happens) write(*,'(''n'')') n
which I wouldn't have found easily without the compile-time warning of
the NAG compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27304
[Bug tree-optimization/25148] compare_values assumes that CST in a + CST (and a - CST) is always postive
--- Comment #8 from patchapp at dberlin dot org 2006-04-27 08:40 --- Subject: Bug number PR25148 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01030.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25148
[Bug tree-optimization/27335] New: [4.0/4.1 regression] ICE in get_loop_body
extern void bar () __attribute__ ((noreturn));
inline double
baz (double *x, unsigned int y)
{
if (y = 6)
bar ();
return x[y];
}
double *a, *b;
void
foo ()
{
unsigned int r, s, t;
for (r = 0; r 2; r++)
for (t = 0; t 2; t++)
{
for (s = 0; s 3; s++)
b[r * 2 + t] += baz (a, 3 * s + t);
}
}
ICEs with -O2 -funroll-loops in get_loop_body, loop-num_nodes is 0.
--
Summary: [4.0/4.1 regression] ICE in get_loop_body
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27335
[Bug tree-optimization/27335] [4.0/4.1 regression] ICE in get_loop_body
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-27 09:38 --- Confirmed. Also with -O -funroll-loops (or -fpeel-loops, or -fprofile-use). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-27 09:38:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27335
[Bug tree-optimization/27335] [4.0/4.1 regression] ICE in get_loop_body
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-27 09:44 ---
Note that loop information looks corrupt:
(gdb) print *loop
$2 = {num = 144085752, header = 0xb7fbb178, latch = 0xb7e4c3c0,
lpt_decision = {decision = LPT_NONE, times = 0}, ninsns = 0, av_ninsns = 0,
num_nodes = 0, depth = -1, pred = 0x0, level = 2, outer = 0x0, inner = 0x0,
next = 0x0, copy = 0x0, aux = 0x0, nb_iterations = 0x0,
estimated_nb_iterations = 0x69, bounds = 0xb7fbb178,
single_exit = 0x894, parallel_p = 1 '\001'}
(gdb) print *loop-header
$3 = {stmt_list = 0x0, preds = 0x0, succs = 0x896ad70, aux = 0x894,
loop_father = 0x896d608, dom = {0x896d608, 0xb7fbb188},
prev_bb = 0xb7fbb188, next_bb = 0xb7fbb190, il = {rtl = 0xb7fbb190},
phi_nodes = 0x896d750, predictions = 0x8947938,
count = -5189358841774755424, index = -1208241752, loop_depth = -1208241752,
frequency = -1208241744, flags = -1208241744}
The loop walking in peel_loops_completely looks bogus, as we're modifying
the loop tree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27335
[Bug fortran/25681] ICE with len of array of derived type
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-04-27 09:49 --- (In reply to comment #5) This bug is one of the issues preventing cp2k from compiling. I get this error in timings.f90:335. This bug is still there. With mainline, on i686-linux, it seems to be the only remaining bug preventing cp2k from building. I might have an idea for a partial patch. I'll try to clean it up a bit and post it to the list soon. [Adding Joost in CC list] -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org, jv244 at cam dot ac dot ||uk Last reconfirmed|2006-02-06 18:30:57 |2006-04-27 09:49:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25681
[Bug tree-optimization/27218] [4.1 regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1515, inlining produces non-gimple
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-04-27 09:58 --- Fixed on the mainline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||patch Known to fail|4.2.0 |4.1.1 Known to work||4.2.0 Last reconfirmed|2006-04-19 15:53:29 |2006-04-27 09:58:43 date|| Summary|[4.1/4.2 regression] ICE in |[4.1 regression] ICE in |get_indirect_ref_operands, |get_indirect_ref_operands, |at tree-ssa-operands.c:1515,|at tree-ssa-operands.c:1515, |inlining produces non-gimple|inlining produces non-gimple http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27218
[Bug tree-optimization/27151] [4.1/4.2 Regression] ICE with -ftree-vectorize with mixed types
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-27 10:16 --- The vectorizer doesn't seem to handle differing types for COND_EXPRs. So something along *** tree-vect-transform.c (revision 113296) --- tree-vect-transform.c (working copy) *** vectorizable_condition (tree stmt, block *** 2115,2120 --- 2115,2125 then_clause = TREE_OPERAND (op, 1); else_clause = TREE_OPERAND (op, 2); + /* We do not handle two different vector types for the condition + and the values. */ + if (TREE_TYPE (TREE_OPERAND (cond_expr, 0)) != TREE_TYPE (vectype)) + return false; + if (!vect_is_simple_cond (cond_expr, loop_vinfo)) return false; should fix it. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-04-14 01:01:38 |2006-04-27 10:16:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27151
[Bug tree-optimization/26969] [4.1/4.2 Regression] ICE with -O1 -funswitch-loops -ftree-vectorize
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-27 10:38 --- We ICE in rename_use_op on if (TREE_CODE (USE_FROM_PTR (op_p)) != SSA_NAME) return; because *op_p-use is NULL and the stmt is broken: (gdb) call debug_generic_expr(op_p-stmt) SMT.6D.1867_40 = PHI (13); #0 0x081ed569 in rename_use_op (op_p=0xb7de40a0) at /space/rguenther/src/svn/trunk/gcc/tree-vectorizer.c:201 #1 0x081ed840 in rename_variables_in_bb (bb=0xb7d35a50) at /space/rguenther/src/svn/trunk/gcc/tree-vectorizer.c:243 #2 0x081ee0d4 in rename_variables_in_loop (loop=0x896e8f0) at /space/rguenther/src/svn/trunk/gcc/tree-vectorizer.c:259 #3 0x081eff18 in slpeel_tree_peel_loop_to_edge (loop=0x8961658, loops=0x8948690, e=0xb7dd6820, first_niters=0xb7de3138, niters=0xb7dded68, update_first_loop_count=1 '\001') at /space/rguenther/src/svn/trunk/gcc/tree-vectorizer.c:1135 #4 0x08203066 in vect_do_peeling_for_alignment (loop_vinfo=0x895ff18, loops=0x8948690) at /space/rguenther/src/svn/trunk/gcc/tree-vect-transform.c:2813 #5 0x08203978 in vect_transform_loop (loop_vinfo=0x895ff18, loops=0x8948690) at /space/rguenther/src/svn/trunk/gcc/tree-vect-transform.c:3045 #6 0x081f29e5 in vectorize_loops (loops=0x8948690) at /space/rguenther/src/svn/trunk/gcc/tree-vectorizer.c:2046 #7 0x081dbdf1 in tree_vectorize () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
[Bug fortran/27324] Initialized module equivalence member causes assembler error
--- Comment #1 from paul dot thomas at jet dot uk 2006-04-27 10:44 --- This one is marvelous - it's one of Sherlock Holme's three pipers. If the initialization is removed, all works correctly. If the module is compiled separately and the object file linked with the main program, it works correctly, as it stands. The root of the problem is in build_common_decl, where the backend_decl for the equivalence union seems to get lost for some reason. In consequence, two decls get made, which possess ASSEMBLER_DECL_NAMEs. For some reason that I do not yet see, it matters if they are initilized or not. This latter is slightly academic, in that the solution will be to get the existing backend_decl to subsequent calls. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27324
[Bug tree-optimization/26969] [4.1/4.2 Regression] ICE with -O1 -funswitch-loops -ftree-vectorize
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-27 11:05 --- slpeel_update_phis_for_duplicate_loop does not do its job properly. It fails to update the PHI nodes of at least the new loops latch block: (gdb) call debug_bb (new_loop-latch) ;; basic block 14, loop depth 1, count 0 ;; prev block 13, next block 4 ;; pred: 13 [98.8%] (dfs_back,true,exec) ;; succ: 13 [100.0%] (fallthru,exec) # SMT.6_40 = PHI (13); # j_41 = PHI (13); L23:; goto bb 13 (L24); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
[Bug middle-end/26729] [4.0/4.1 regression] bad bitops folding
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-04-27 11:21 --- This is fixed on the mainline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|3.3.6 3.4.3 4.0.2 4.1.0 |3.3.6 3.4.3 4.0.2 4.1.0 |4.2.0 | Known to work|2.95.4 |2.95.4 4.2.0 Summary|[4.0/4.1/4.2 regression] bad|[4.0/4.1 regression] bad |bitops folding |bitops folding http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26729
[Bug tree-optimization/26719] [4.1/4.2 Regression] Computed (integer) table changes with -O
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-27 11:23 --- Still happens. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Last reconfirmed|2006-03-16 18:24:54 |2006-04-27 11:23:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
[Bug c++/27336] New: this pointer is not assumed to be not null
I noticed that GCC tends to litter the assembly code with null checks and jumps
(especially for dynamic casts) even when the pointer cannot be null. This is
especially true for this: unless I am mistaken, calling a nonstatic member
with this not pointing to an object of the correct type (or a derived type)
is undefined behavior. So GCC should assume it is not null. I tried the
following testcase with 3.4.6, 4.0.3, and 4.1.0; GCC was never able to optimize
the return value to true when compiling with -O3.
struct A { bool g(); };
bool A::g() { return this; }
--
Summary: this pointer is not assumed to be not null
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27336
[Bug awt/22163] scrollbars appear and disappear
-- gnu_andrew at member dot fsf dot org changed: What|Removed |Added Target Milestone|--- |0.91 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22163
[Bug fortran/25681] ICE with len of array of derived type
--- Comment #7 from patchapp at dberlin dot org 2006-04-27 11:50 --- Subject: Bug number PR fortran/25681 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01033.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25681
[Bug fortran/25681] ICE with len of array of derived type
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-04-27 11:50 --- Patch (at least partial) submitted for approval. The patch allows CP2K to compile. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||04/msg01033.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25681
[Bug crypto/27111] SecureRandom isn't seeded on creation
-- gnu_andrew at member dot fsf dot org changed: What|Removed |Added Target Milestone|--- |0.91 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27111
[Bug libgomp/27337] New: OpenMP ICE in expand_expr_real_1 at expr.c:6814
Hi,
I have obtained an ICE in expand_expr_real_1, at expr.c:6814 when trying to
build my code using OpenMP. I am using gcc version 4.2.0 20060422
(experimental) on target x86_64-unknown-linux-gnu.
The problem appears also in the FC5 gcc4.1.0 version gcc (GCC) 4.1.0 20060304
(Red Hat 4.1.0-3).
Below you find to pieces of code which produce the problem, as well as the
output of gcc -v -save-temps.
The ICE disapears when removing all openmp directives and headerfiles. The ICE
disapears also when the function is a void instead of T1, and also if T1 is a
normal 'old' type.
If you need more info, just contact me.
With kind regards,
Klaas
BEGIN code.cpp
#include t1.h
#include omp.h
T1 function (void) {
int ii,N;
T1 temp(N);
#pragma omp parallel for
for (ii = 0; ii N; ii++) {
temp(ii,ii) = ii;
}
return temp;
}
END code.cpp
BEGIN t1.h
#ifndef LINALG_H
#define T1_H
class T1 {
public :
T1(int);
~T1(void);
double operator()(int, int) const;
private :
double *a;
};
#endif
END t1.h
[EMAIL PROTECTED] src]$ /usr/local/gcc4.2/bin/x86_64-unknown-linux-gnu-g++ -v
-save-temps -fopenmp -c code.cpp
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /usr/local/src/gcc-4.2-20060422/configure
--prefix=/usr/local/gcc4.2 --enable-languages=c,c++
Thread model: posix
gcc version 4.2.0 20060422 (experimental)
/usr/local/gcc4.2/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/cc1plus -E -quiet
-v -D_GNU_SOURCE -D_REENTRANT code.cpp -mtune=generic -fopenmp -fpch-preprocess
-o code.ii
ignoring nonexistent directory
/usr/local/gcc4.2/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/gcc4.2/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../include/c++/4.2.0
/usr/local/gcc4.2/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../include/c++/4.2.0/x86_64-unknown-linux-gnu
/usr/local/gcc4.2/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../include/c++/4.2.0/backward
/usr/local/include
/usr/local/gcc4.2/include
/usr/local/gcc4.2/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/include
/usr/include
End of search list.
/usr/local/gcc4.2/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/cc1plus
-fpreprocessed code.ii -quiet -dumpbase code.cpp -mtune=generic -auxbase code
-version -fopenmp -o code.s
GNU C++ version 4.2.0 20060422 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.2.0 20060422 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 99a2733c59c8f6d329de89f75af46282
code.cpp: In function âT1 function()â:
code.cpp:6: internal compiler error: in expand_expr_real_1, at expr.c:6814
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions
--
Summary: OpenMP ICE in expand_expr_real_1 at expr.c:6814
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Klaas dot Vantournhout at UGent dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27337
[Bug classpath/24632] java.util.HashMap$HashIterator.hasNext throws ConcurrentModificationException
-- gnu_andrew at member dot fsf dot org changed: What|Removed |Added Target Milestone|--- |0.91 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24632
[Bug classpath/26707] lib/Makefile.am should ignore .svn directories
-- gnu_andrew at member dot fsf dot org changed: What|Removed |Added Target Milestone|--- |0.91 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26707
[Bug libgomp/27337] OpenMP ICE in expand_expr_real_1 at expr.c:6814
--- Comment #1 from Klaas dot Vantournhout at UGent dot be 2006-04-27 12:19 --- I forgot to state that in the FC5 version gcc (GCC) 4.1.0 20060304 (Red Hat 4.1.0-3) the ICE appears in expand_expr_real_1, at expr.c:6694. Klaas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27337
[Bug middle-end/27337] OpenMP ICE in expand_expr_real_1 at expr.c:6814
--- Comment #2 from jakub at gcc dot gnu dot org 2006-04-27 12:22 ---
OMP gimplification and lowering needs to handle RESULT_DECLs.
Simplified testcases e.g.:
struct S
{
S ();
~S ();
double operator* () const;
};
S
foo ()
{
int i;
S ret;
#pragma omp parallel for
for (i = 0; i 2; i++)
*ret += i;
return ret;
}
or
struct S
{
S ();
~S ();
int i;
};
S
foo ()
{
int i;
S ret;
#pragma omp parallel for firstprivate (ret) lastprivate (ret)
for (i = 0; i 2; i++)
ret.i += i;
return ret;
}
--
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
Component|libgomp |middle-end
Ever Confirmed|0 |1
Keywords||openmp
Last reconfirmed|-00-00 00:00:00 |2006-04-27 12:22:43
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27337
[Bug tree-optimization/24609] [4.1/4.2 regression] Same value duplicated in two different registers
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-27 12:36 --- I cannot reproduce this anymore on 4.1 or mainline. (I can however see the const duplication by PRE) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24609
[Bug classpath/26688] Classpath Makefiles assume CVS source control
-- gnu_andrew at member dot fsf dot org changed: What|Removed |Added Target Milestone|--- |0.91 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26688
[Bug tree-optimization/27151] [4.1/4.2 Regression] ICE with -ftree-vectorize with mixed types
--- Comment #7 from patchapp at dberlin dot org 2006-04-27 12:50 --- Subject: Bug number PR27151 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01034.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27151
[Bug fortran/25681] ICE with len of array of derived type
--- Comment #9 from jv244 at cam dot ac dot uk 2006-04-27 12:53 --- [Adding Joost in CC list] Thanks. Any idea if it runs properly with the patch in place (have a look at the script cp2k/tools/do_regtest for setting up a testing run) ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25681
[Bug rtl-optimization/26685] [4.1/4.2 regression] documentation refer to nonexisting --param max-cse-insns
--- Comment #2 from patchapp at dberlin dot org 2006-04-27 12:55 --- Subject: Bug number PR26685 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01035.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26685
[Bug middle-end/27337] OpenMP ICE in expand_expr_real_1 at expr.c:6814
--- Comment #3 from Klaas dot Vantournhout at UGent dot be 2006-04-27 13:09 --- The first test case gives me the same error when using the flags -fopenmp -c. When I don't use -fopenmp, the code will compile. The second test case gives me an other ICE. code2.c: In function S foo(): code2.c:14: internal compiler error: tree check: expected tree that contains decl common structure, have indirect_ref in omp_add_variable, at gimplify.c:4286 I don't know if this comment was usefull, or if these errors were obvious. Greets Klaas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27337
[Bug c++/27336] this pointer is not assumed to be not null
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-27 13:10 --- Confirmed. The frontend needs to tell the middle-end that the argument is non-NULL. Like by making the methods __attribute__((nonnull(1))). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Known to fail||4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-04-27 13:10:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27336
[Bug target/27338] New: Violation of mips o64 ABI
According to http://gcc.gnu.org/projects/mipso64-abi.html
if the first and second arguments floating-point arguments
to a function are 32-bit values, they are passed in $f12
and $f14. The assembler file obtained as a result of
compilation with mips64-none-elf-gcc-4.1.0 of the following
file (o64.c), shows that a pair of float parameters is
passed on $f12 and $f13 instead of $f12 and $f14.
When I compile the same file with mips64-none-elf-gcc-3.4.5,
I get assembler code where the parameters are passed on
$f12 and $f14.
extern float g01f;
int checkf (float x, float v)
{ if (x != v + 90.0)
{ return 1; }
else
{ return 0; }
}
void checkgf (void) {
checkf (g01f, 1);
}
void initf (float *p, float v)
{ *p = v + 90.0; }
--
Summary: Violation of mips o64 ABI
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: niva at niisi dot msk dot ru
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: mips64-none-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27338
[Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2006-04-27 13:14 --- (In reply to comment #11) The only solution in these cases it to remove the assert and let it generate bad code, but I want to fix other issues first before removing the assert. What's the status on this? It makes libgfortran build crash with a patch I'd like to submit. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2006-03-09 22:52:29 |2006-04-27 13:14:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug fortran/27324] Initialized module equivalence member causes assembler error
--- Comment #2 from paul dot thomas at jet dot uk 2006-04-27 13:24 --- Holmes was wrong - it was a one piper. The symbol for the module equivalence was being scrubbed for the lack of a gfc_commit_symbols. Interchanging lines 1061 and 1064 in trans-common.c does the job. Thus: /* Translate local equivalence. */ finish_equivalences (ns); /* Commit the newly created symbols for common blocks and module equivalences. */ gfc_commit_symbols (); This regtests together with the fix for pr27269 on Cygwin_NT. As soon as I figure out why I cannot free the gfc_expr's in this latter fix, I will submit a combined patch and testcase. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27324
[Bug tree-optimization/25148] compare_values assumes that CST in a + CST (and a - CST) is always postive
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-04-27 13:52 --- Subject: Bug 25148 Author: rguenth Date: Thu Apr 27 13:52:44 2006 New Revision: 113298 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113298 Log: 2006-04-27 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/25148 * tree-vrp.c (compare_values): Remove code dealing with comparisons against type min/max value. Honour overflow and negative constants in code dealing with comparisons of plus and minus expressions. (value_inside_range): Use fold_binary with LE_EXPR and GE_EXPR rather than compare_values. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25148
[Bug tree-optimization/25148] compare_values assumes that CST in a + CST (and a - CST) is always postive
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-27 13:53 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25148
[Bug rtl-optimization/26685] [4.1/4.2 regression] documentation refer to nonexisting --param max-cse-insns
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-27 14:24 --- Subject: Bug 26685 Author: rguenth Date: Thu Apr 27 14:24:15 2006 New Revision: 113299 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113299 Log: 2006-04-27 Richard Guenther [EMAIL PROTECTED] PR rtl-optimization/26685 * params.def (PARAM_MAX_CSE_INSNS): Correct typo that named this one max-flow-memory-locations. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/params.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26685
[Bug rtl-optimization/26685] [4.1/4.2 regression] documentation refer to nonexisting --param max-cse-insns
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-27 14:25 --- Subject: Bug 26685 Author: rguenth Date: Thu Apr 27 14:25:49 2006 New Revision: 113300 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113300 Log: 2006-04-27 Richard Guenther [EMAIL PROTECTED] PR rtl-optimization/26685 * params.def (PARAM_MAX_CSE_INSNS): Correct typo that named this one max-flow-memory-locations. Modified: trunk/gcc/ChangeLog trunk/gcc/params.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26685
[Bug rtl-optimization/26685] [4.1/4.2 regression] documentation refer to nonexisting --param max-cse-insns
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-27 14:26 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26685
[Bug tree-optimization/27283] [4.2 regression] ICE: SSA corruption - Conflict across an abnormal edge
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-04-27 15:00 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01044.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||04/msg01044.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27283
[Bug middle-end/27226] Compiler looses track of alignment for emit_block_move
--- Comment #10 from amylaar at gcc dot gnu dot org 2006-04-27 15:35 --- (In reply to comment #6) Created an attachment (id=11305) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11305action=view) [edit] proposed patch for 4.1 The assignment inner = max_align; must come before the if (handled_component_p (exp)) test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
[Bug middle-end/27328] ICE with -fopenmp and goto
--- Comment #2 from jakub at gcc dot gnu dot org 2006-04-27 15:38 --- This is not specific to goto, any OMP structured block which the initial cfg pass proves it will never return is a problem. In that case, the corresponding OMP_RETURN is optimized out as unreachable. The first ICE is fairly easy to fix: --- omp-low.c.jj2 2006-04-27 16:35:04.0 +0200 +++ omp-low.c 2006-04-27 17:29:32.0 +0200 @@ -2231,6 +2231,11 @@ remove_exit_barrier (struct omp_region * exit_bb = region-exit; + /* If the parallel region doesn't return, we don't have REGIOn-EXIT + block at all. */ + if (! exit_bb) +return; + /* The last insn in the block will be the parallel's OMP_RETURN. The workshare's OMP_RETURN will be in a preceding block. The kinds of statements that can appear in between are extremely limited -- no but with this, we ICE in move_sese_region_to_fn and there it will be harder to deal with it. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org, ||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27328
[Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
--- Comment #16 from dberlin at gcc dot gnu dot org 2006-04-27 15:39 --- Subject: Re: [4.2 Regression] ICE in in add_virtual_operand What's the status on this? It makes libgfortran build crash with a patch I'd like to submit. Uh, okay, so, until someone debugs the other real problems this exposes, i'm not going to remove the assert. In particular, whenever that assert triggers, it's going to generate bad code because somebody somewhere (either user or compiler pass, it varies) has done something wrong. So if it's triggering during your libgfortran builds with a patch, you really need to examine where it's triggering. If it is triggering because there is a bare NMT there, then something has screwed up aliasing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug tree-optimization/26726] -fivopts producing out of bounds array refs
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-27 15:47 ---
One thing is, that find_interesting_uses_address () produces bases that look
like (a[0])-s. I.e. they are not folded during IV base insertion via
if (!for_each_index (base, idx_find_step, ifs_ivopts_data)
|| zero_p (step))
goto fail;
Also we don't see that *a[0] is an ARRAY_REF in idx_find_step, which may cause
other problems.
Another problem is that we record both
(const Foo*)a[0]
and
a[0]
as biv's which confuses IVOPTs a lot.
Stripping useless type conversions during biv discovery and folding after the
substitution above fixes the two problems. What remains is the use of an
out-of-bound array index and a (useless) offset:
bb 2:
ivtmp.39_2 = x[1];
# ivtmp.39_4 = PHI ivtmp.39_1(4), ivtmp.39_2(2);
L0:;
D.2068_10 = (int *) ivtmp.39_4;
MEM[base: D.2068_10, offset: -4B]{this-s} = 1;
ivtmp.39_1 = ivtmp.39_4 + 4B;
if (ivtmp.39_1 != x[5]) goto L5; else goto L2;
here I do not see how IVOPTs decided that using x[1] as base is better
than x[0] (well, the cost for the former is 1 while for the latter is 2(!?)
I have a patch for the first two problems in testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug tree-optimization/26726] -fivopts producing out of bounds array refs
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-04-27 15:59 --- The offset causes the assembler to be sub-optimal: .LCFI2: leal-12(%ebp), %eax leal4(%ebp), %edx .p2align 4,,7 .L2: movl$1, -4(%eax) addl$4, %eax cmpl%edx, %eax jne .L2 and I can imagine on auto-decrement targets it would be even worse (though I didn't check). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug tree-optimization/26726] -fivopts producing out of bounds array refs
--- Comment #9 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-27 16:02 ---
Subject: Re: -fivopts producing out of bounds array refs
One thing is, that find_interesting_uses_address () produces bases that look
like (a[0])-s. I.e. they are not folded during IV base insertion via
if (!for_each_index (base, idx_find_step, ifs_ivopts_data)
|| zero_p (step))
goto fail;
Also we don't see that *a[0] is an ARRAY_REF in idx_find_step, which may
cause
other problems.
Another problem is that we record both
(const Foo*)a[0]
and
a[0]
as biv's which confuses IVOPTs a lot.
Stripping useless type conversions during biv discovery and folding after the
substitution above fixes the two problems.
I also have some patches for similar problems (in killloop-branch),
unfortunately
they mostly depend on http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00345.html
that seems hopelessly stuck.
What remains is the use of an
out-of-bound array index and a (useless) offset:
bb 2:
ivtmp.39_2 = x[1];
# ivtmp.39_4 = PHI ivtmp.39_1(4), ivtmp.39_2(2);
L0:;
D.2068_10 = (int *) ivtmp.39_4;
MEM[base: D.2068_10, offset: -4B]{this-s} = 1;
ivtmp.39_1 = ivtmp.39_4 + 4B;
if (ivtmp.39_1 != x[5]) goto L5; else goto L2;
here I do not see how IVOPTs decided that using x[1] as base is better
than x[0] (well, the cost for the former is 1 while for the latter is 2(!?)
Welcome to the wonderful world of cost arithmetics :-) x86 backend
pretends that more complicated memory addressing modes are cheaper,
in order to persuade CSE to create them. Thus, given several equally
costly ways how to express a memory reference, ivopts will choose the
most complicated one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug tree-optimization/27144] [4.2 regression] segfault with -O2 on x86_64 (and powerpc64)
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-04-13 17:01:44 |2006-04-27 16:04:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27144
[Bug tree-optimization/26726] -fivopts producing out of bounds array refs
--- Comment #10 from rguenther at suse dot de 2006-04-27 16:09 ---
Subject: Re: -fivopts producing out of bounds
array refs
On Thu, 27 Apr 2006, rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
Stripping useless type conversions during biv discovery and folding after
the
substitution above fixes the two problems.
I also have some patches for similar problems (in killloop-branch),
unfortunately
they mostly depend on http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00345.html
that seems hopelessly stuck.
I thought there was consensus and approval on the generic parts. Maybe
it's time to ping these again, as they were clearly submitted before
stage3.
What remains is the use of an
out-of-bound array index and a (useless) offset:
bb 2:
ivtmp.39_2 = x[1];
# ivtmp.39_4 = PHI ivtmp.39_1(4), ivtmp.39_2(2);
L0:;
D.2068_10 = (int *) ivtmp.39_4;
MEM[base: D.2068_10, offset: -4B]{this-s} = 1;
ivtmp.39_1 = ivtmp.39_4 + 4B;
if (ivtmp.39_1 != x[5]) goto L5; else goto L2;
here I do not see how IVOPTs decided that using x[1] as base is better
than x[0] (well, the cost for the former is 1 while for the latter is 2(!?)
Welcome to the wonderful world of cost arithmetics :-) x86 backend
pretends that more complicated memory addressing modes are cheaper,
in order to persuade CSE to create them. Thus, given several equally
costly ways how to express a memory reference, ivopts will choose the
most complicated one.
*sigh* :/
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug bootstrap/27334] [4.0/4.1 onlly] gcc/Makefile.in:s-macro_list sed fails with make 3.81 due to POSIX support changes
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-27 16:11 --- I should note that this is not a regression and maybe someone over at GNU make should have tested building GCC. Note also this is going to be another poltical mess. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Summary|gcc/Makefile.in:s-macro_list|[4.0/4.1 onlly] |sed fails with make 3.81 due|gcc/Makefile.in:s-macro_list |to POSIX support changes|sed fails with make 3.81 due ||to POSIX support changes Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27334
[Bug target/27333] internal compiler error: Segmentation fault
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-27 16:26 --- This works for me and many other people. Make sure you don't have bad memory or hardware. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27333
[Bug c++/27339] New: defining out-of-class specialization of value template parameter with private type
Following code does not compile with gcc 4.1.
It compiles with gcc 3.4.0 and gcc 4.0.2 and comeau online.
=
class A
{
private:
enum private_enum {a};
templateA::private_enum v // OK
struct B
{
void bm();
};
public:
void am()
{
Ba instance; //OK
instance.bm();
}
};
templateA::private_enum v // FAIL
void
A::Bv::bm(){}
=
The error message is:
a.cc:4: error: 'enum A::private_enum' is private
a.cc:19: error: within this context
If the member template function gets defined inline, the code compiles.
I don't have the c++ standard available, but a technicality like an
inline/outline definition should have no impact on the validity of the code
imho.
The same error occurrs if the enum gets replaced by a function template
typedef, or if the inner-class gets replaced by a member-function-template.
A related bug is 10849
--
Summary: defining out-of-class specialization of value template
parameter with private type
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dirkmoermans at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27339
[Bug target/25514] [m68k] internal consistency failure
--- Comment #5 from rsandifo at gcc dot gnu dot org 2006-04-27 16:41 --- Subject: Bug 25514 Author: rsandifo Date: Thu Apr 27 16:41:51 2006 New Revision: 113312 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113312 Log: PR rtl-optimization/25514 * combine.c (replaced_rhs_insn): New variable. (combine_instructions): Set replaced_rhs_insn when trying to replace a SET_SRC with a REG_EQUAL note. (distribute_notes): Use replaced_rhs_insn when determining the live range of a REG_DEAD register. gcc/testsute * gcc.c-torture/compile/pr25514.c: New test. Modified: branches/csl/coldfire-4_1/ChangeLog.csl branches/csl/coldfire-4_1/gcc/combine.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25514
[Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-04-27 16:43 --- As followup to comment #9, copyprop propagates pretmp.23_2 into rv.0_1-d, and in may_propagate_copy we see that rv.0_1 has both an SMT and NMT associated with, while pretmp.23_2 has none of the two. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug target/25514] [m68k] internal consistency failure
--- Comment #6 from rsandifo at gcc dot gnu dot org 2006-04-27 16:43 --- Subject: Bug 25514 Author: rsandifo Date: Thu Apr 27 16:43:10 2006 New Revision: 113313 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113313 Log: PR rtl-optimization/25514 * combine.c (replaced_rhs_insn): New variable. (combine_instructions): Set replaced_rhs_insn when trying to replace a SET_SRC with a REG_EQUAL note. (distribute_notes): Use replaced_rhs_insn when determining the live range of a REG_DEAD register. gcc/testsute * gcc.c-torture/compile/pr25514.c: New test. Added: branches/csl/coldfire-4_1/gcc/testsuite/gcc.c-torture/compile/pr25514.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25514
[Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
--- Comment #18 from dberlin at gcc dot gnu dot org 2006-04-27 16:55 --- Subject: Re: [4.2 Regression] ICE in in add_virtual_operand On Thu, 2006-04-27 at 16:43 +, rguenth at gcc dot gnu dot org wrote: --- Comment #17 from rguenth at gcc dot gnu dot org 2006-04-27 16:43 --- As followup to comment #9, copyprop propagates pretmp.23_2 into rv.0_1-d, and in may_propagate_copy we see that rv.0_1 has both an SMT and NMT associated with, while pretmp.23_2 has none of the two. Except that may_alias is rerun right after PRE, so it should have the same symbols :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-04-27 16:56
---
This one ICEs the same way, already during the first copyprop pass:
typedef union {
int d;
} U;
int rv;
void breakme()
{
U *rv0;
U *pretmp = (U*)rv;
rv0 = pretmp;
rv0-d = 42;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-04-27 17:08 --- Happens with -O -quiet t.c -dumpbase t.c -fdump-tree-alias1-vops -fstrict-aliasing -fno-tree-fre -fno-tree-ccp -fdump-tree-all -fno-tree-dce -fno-tree-copyrename -fno-tree-salias and manually disabled forwprop. So that leaves may_alias and copyprop itself to blame. -fno-strict-aliasing fixes it, too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug tree-optimization/27144] [4.2 regression] segfault with -O2 on x86_64 (and powerpc64)
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-04-27 17:42 --- This is more or less dup of PR23434 (the fix for it is not quite correct). I am testing a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27144
Re: Typecast bug
[EMAIL PROTECTED] writes: | On 26 Apr 2006, Gabriel Dos Reis wrote: | | [EMAIL PROTECTED] writes: | | | It is gcc 4.1.0, --target=arm-elf compiled on an Intel platform and | | GNU/Linux. | | | | The following construct: | | | | void *p; | | | | ((char *)p)++; | | | | makes the compiler to issue an error message, namely | | invalid lvalue in increment | | | | The ((char *)p) construct is perfectly valid object, a char pointer which | | can be lvalue and rvalue alike. For some reason gcc 4.1.0 (and 4.0.2 as | | well) treats ((SOME_TYPE *)p) as if it could not be an lvalue; | | indeed, it is not; in any ISO C version I know of. | | OK - my bad. Wrote first thought later. Old gcc accepted the construct and | legacy code broke on the new compiler. My sincere apologies. | | The question, however, remains: (how) can I tell the compiler to treat a | pointer declared as void *p; as if it was a SOME_TYPE *p pointer without | introducing temporaries? You have to use a cast, and the result is not an lvalue. Period. Or, use the original pointer SOME_TYPE *p. -- Gaby
[Bug libstdc++/27340] New: valarray uses __cos which may conflict with libm functions
valarray defines structs with names like __cos, __sin, etc. It is often the
case (glibc, solaris) that the libc declares functions with those same names.
In the current situation we are lucky because the structs are in namespace std
and the functions in the global namespace. But playing around with namespace
std soon brings something like this:
namespace std {
double __cos(double);
struct __cos
{
templatetypename _Tp
_Tp operator()(const _Tp __t) const;
};
}
template class T struct A {};
int main(){
Astd::__cos a;
}
which results in:
error: type/value mismatch at argument 1 in template parameter list for
'templateclass T struct A'
error: expected a type, got 'std::__cos'
error: invalid type in declaration before ';' token
It would be preferable to use a less conflict-prone name.
--
Summary: valarray uses __cos which may conflict with libm
functions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27340
[Bug c++/27102] [4.0/4.1 regression] ICE with invalid class name in function template
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-04-27 19:03 --- Subject: Bug 27102 Author: mmitchel Date: Thu Apr 27 19:02:54 2006 New Revision: 113320 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113320 Log: PR c++/27102 * typeck2.c (cxx_incomplete_type_diagnostic): Handle TYPENAME_TYPE. PR c++/27102 * g++.dg/template/crash47.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/crash47.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27102
[Bug c++/27102] [4.0/4.1 regression] ICE with invalid class name in function template
--- Comment #11 from mmitchel at gcc dot gnu dot org 2006-04-27 19:06 --- The problem in Comment #9 has been resolved in 4.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27102
[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-27 19:07 --- Both libc and libstdc++ are considered part of the implementation which means both are valid to use this name space. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27340
[Bug middle-end/19466] [meta-bug] bit-fields are non optimal
--- Comment #2 from steven at gcc dot gnu dot org 2006-04-27 19:10 --- Patches addressing some of the issues: http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00969.html http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01049.html I'm linking them from here for reference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19466
[Bug tree-optimization/27341] New: [4.2 Regression] ICE in in add_virtual_operand with complex types
Reduced testcase (-O2 to invoke the ICE):
void zgemm_ (const int*, const double*);
extern void matmul_c8 (_Complex double * dest)
{
const int ldc = 0;
const double zero = 0;
zgemm_ ( zero, ldc);
dest[1] += 1 ;
}
-
Unlike PR26626, the code above is not questionable code if it is undefined or
not.
--
Summary: [4.2 Regression] ICE in in add_virtual_operand with
complex types
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27341
[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27341
[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-27 19:11 --- Confirmed, since this is a reducetion from PR 26626 #13. -- 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 |2006-04-27 19:11:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27341
[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-27 19:14 --- Note fixing the prototype of zgemm_ to: void zgemm_ (const double*, const int*); We Still ICE (I had messed the order up before). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27341
[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-27 19:17 --- And this is fully complex types related, the ICE comes right after cplxlower, most likely caused by the complex type getting split up into two different loads. (I have not checked that theory yet). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27341
[Bug c++/27339] [4.1/4.2 Regression]defining out-of-class specialization of value template parameter with private type
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |normal Keywords||rejects-valid Summary|defining out-of-class |[4.1/4.2 Regression]defining |specialization of value |out-of-class specialization |template parameter with |of value template parameter |private type|with private type Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27339
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #15 from amacleod at redhat dot com 2006-04-27 20:22 --- Subject: Bug 26854 Author: amacleod Date: Thu Apr 27 20:22:17 2006 New Revision: 113321 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113321 Log: Implement new immediate use iterators. 2006-04-27 Andrew MacLeod [EMAIL PROTECTED] PR tree-optimization/26854 * tree-vrp.c (remove_range_assertions): Use new Immuse iterator. * doc/tree-ssa.texi: Update immuse iterator documentation. * tree-ssa-math-opts.c (execute_cse_reciprocals_1): Use new iterator. * tree-ssa-dom.c (propagate_rhs_into_lhs): Use new iterator. * tree-flow-inline.h (end_safe_imm_use_traverse, end_safe_imm_use_p, first_safe_imm_use, next_safe_imm_use): Remove. (end_imm_use_stmt_p): New. Check for end of immuse stmt traversal. (end_imm_use_stmt_traverse): New. Terminate immuse stmt traversal. (move_use_after_head): New. Helper function to sort immuses in a stmt. (link_use_stmts_after): New. Link all immuses in a stmt consescutively. (first_imm_use_stmt): New. Get first stmt in an immuse list. (next_imm_use_stmt): New. Get next stmt in an immuse list. (first_imm_use_on_stmt): New. Get first immuse on a stmt. (end_imm_use_on_stmt_p): New. Check for end of immuses on a stmt. (next_imm_use_on_stmt): New. Move to next immuse on a stmt. * tree-ssa-forwprop.c (forward_propagate_addr_expr): Use new iterator. * lambda-code.c (lambda_loopnest_to_gcc_loopnest): Use new iterator. (perfect_nestify): Use new iterator. * tree-vect-transform.c (vect_create_epilog_for_reduction): Use new iterator. * tree-flow.h (struct immediate_use_iterator_d): Add comments. (next_imm_name): New field in struct immediate_use_iterator_d. (FOR_EACH_IMM_USE_SAFE, BREAK_FROM_SAFE_IMM_USE): Remove. (FOR_EACH_IMM_USE_STMT, BREAK_FROM_IMM_USE_STMT, FOR_EACH_IMM_USE_ON_STMT): New immediate use iterator macros. * tree-cfg.c (replace_uses_by): Use new iterator. * tree-ssa-threadedge.c (lhs_of_dominating_assert): Use new iterator. * tree-ssa-operands.c (correct_use_link): Remove. (finalize_ssa_use_ops): No longer call correct_use_link. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/tree-ssa.texi trunk/gcc/lambda-code.c trunk/gcc/tree-cfg.c trunk/gcc/tree-flow-inline.h trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-dom.c trunk/gcc/tree-ssa-forwprop.c trunk/gcc/tree-ssa-math-opts.c trunk/gcc/tree-ssa-operands.c trunk/gcc/tree-ssa-threadedge.c trunk/gcc/tree-vect-transform.c trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug c/27342] New: GCC-bootstrap using ./xgcc on libgcov.c with -DL_gcov (1st of several libgcov.c
./xgcc -v -save-temps -B./ -B/usr/i686-pc-linux-gnu/bin/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -L/slackw/gcc-r41/gcc.build.lnx9/gcc/../ld -O2 -O2 -O2 -pipe -fomit-frame-pointer -march=pentium3 -fno-strict-aliasing -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc-4.1.1/gcc -I../../gcc-4.1.1/gcc/. -I../../gcc-4.1.1/gcc/../include -I../../gcc-4.1.1/gcc/../libcpp/include -I/usr/lib/include -I/usr/lib/include -I/l3/gmp-4.2 -DL_gcov -c libgcov.c -o libgcov.i 21 |tee rmg.out xgcc: warning: -pipe ignored because -save-temps specified Reading specs from ./specs Target: i686-pc-linux-gnu Configured with: ../gcc-4.1.1/configure --prefix=/usr --enable-version-specific-runtime-libs --with-java-home=/usr --infodir=/usr/share/gcc-420 --datadir=/usr/share/gcc-420 --mandir=/usr/share/gcc-420 --program-suffix=-420 --enable-shared --enable-gomp --enable-mudflap --enable-libgfortran --enable-threads=posix --enable-__cxa_atexit --disable-checking --disable-multilib --disable-nls --disable-werror --with-gnu-ld --enable-libgcc-math --with-mpfr-dir=/l3/mpfr-2.2.0 --with-mpfr=/usr/lib --with-gmp-dir=/l3/gmp-4.2 --with-gmp=/usr/lib --enable-languages=c,c++,fortran,java,objc --with-cpu=pentium3 --enable-clocale=gnu Thread model: posix gcc version 4.1.1 20060427 (prerelease) ./cc1 -E -quiet -v -I. -I. -I../../gcc-4.1.1/gcc -I../../gcc-4.1.1/gcc/. -I../../gcc-4.1.1/gcc/../include -I../../gcc-4.1.1/gcc/../libcpp/include -I/usr/lib/include -I/usr/lib/include -I/l3/gmp-4.2 -iprefix /slackw/gcc-r41/gcc.build.lnx9/gcc/../lib/gcc/i686-pc-linux-gnu/4.1.1/ -isystem ./include -DIN_GCC -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DL_gcov -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -isystem ./include libgcov.c -march=pentium3 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -fomit-frame-pointer -fno-strict-aliasing -fPIC -fworking-directory -O2 -O2 -O2 -fpch-preprocess -o libgcov.i ignoring nonexistent directory /usr/i686-pc-linux-gnu/include ignoring nonexistent directory /usr/i686-pc-linux-gnu/sys-include ignoring duplicate directory ./include ignoring nonexistent directory /slackw/gcc-r41/gcc.build.lnx9/gcc/../lib/gcc/i686-pc-linux-gnu/4.1.1/include ignoring nonexistent directory /slackw/gcc-r41/gcc.build.lnx9/gcc/../lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include ignoring nonexistent directory /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include ignoring nonexistent directory /usr/lib/gcc/../../i686-pc-linux-gnu/include ignoring duplicate directory . ignoring duplicate directory ../../gcc-4.1.1/gcc/. ignoring nonexistent directory /usr/lib/include ignoring nonexistent directory /usr/lib/include #include ... search starts here: #include ... search starts here: . ../../gcc-4.1.1/gcc ../../gcc-4.1.1/gcc/../include ../../gcc-4.1.1/gcc/../libcpp/include /l3/gmp-4.2 ./include /usr/local/include /usr/include End of search list. ./cc1 -fpreprocessed libgcov.i -quiet -dumpbase libgcov.c -march=pentium3 -auxbase-strip libgcov.i -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fomit-frame-pointer -fno-strict-aliasing -fPIC -o libgcov.s GNU C version 4.1.1 20060427 (prerelease) (i686-pc-linux-gnu) compiled by GNU C version 4.1.0 20060226 (prerelease). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 3c1c0ca8dc7131f4b263707b4c318e14 libgcov.c: In function 'gcov_exit': libgcov.c:161: error: 'else' label does not match edge at end of bb 140 libgcov.c:161: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: GCC-bootstrap using ./xgcc on libgcov.c with -DL_gcov (1st of several libgcov.c Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: malitzke at metronets 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=27342
[Bug c/27342] GCC-bootstrap using ./xgcc on libgcov.c with -DL_gcov (1st of several libgcov.c
--- Comment #1 from malitzke at metronets dot com 2006-04-27 20:40 --- Created an attachment (id=11341) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11341action=view) Preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27342
[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level
--- Comment #5 from steven at gcc dot gnu dot org 2006-04-27 20:46 ---
So I asked myself, why are we not catching this in vrp? I know we can derive
ranges from types, so why don't we derive a [0,1] range from the bitfield load?
It turns out that we make _all_ loads VARYING right away, so we end up with:
Value ranges after VRP:
b_1: ~[0B, 0B] EQUIVALENCES: { b_2 } (1 elements)
b_2: VARYING
D.1882_3: VARYING
D.1883_4: [0, 1] EQUIVALENCES: { } (0 elements)
D.1884_5: [0, +INF] EQUIVALENCES: { } (0 elements)
D.1885_6: [0, 127] EQUIVALENCES: { } (0 elements)
D.1886_7: [0, +INF] EQUIVALENCES: { } (0 elements)
ior (b)
{
unnamed type D.1886;
unsigned char D.1885;
signed char D.1884;
signed char D.1883;
unnamed type D.1882;
bb 2:
D.1882_3 = b_2-bit;
D.1883_4 = (signed char) D.1882_3;
D.1884_5 = D.1883_4 | 1;
D.1885_6 = (unsigned char) D.1884_5;
D.1886_7 = (unnamed type) D.1885_6;
b_2-bit = D.1886_7;
return;
}
where, at least so it seems to me, we could find something like,
D.1882_3: [0, 1] (etc.)
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2006-02-18 18:24:49 |2006-04-27 20:46:04
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18031
[Bug c/27342] GCC-bootstrap using ./xgcc on libgcov.c with -DL_gcov (1st of several libgcov.c
--- Comment #2 from malitzke at metronets dot com 2006-04-27 20:49 --- I got it once and did a svn update to 113320 for good measure but still got apparently the same segmentation fault. However, libgcov.c is processed about 14 times with a different -DLgcove_xxx each time and the error message does not specify which. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27342
[Bug middle-end/27342] GCC-bootstrap using ./xgcc on libgcov.c with -DL_gcov (1st of several libgcov.c
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-27 21:02 --- if you run the preprocessed source again, do you run into the segfault/error? If so then this is a hardware problem with your machine. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27342
[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-27 21:14 ---
(In reply to comment #5)
So I asked myself, why are we not catching this in vrp? I know we can derive
ranges from types, so why don't we derive a [0,1] range from the bitfield
load?
D.1883_4: [0, 1] EQUIVALENCES: { } (0 elements)
D.1884_5: [0, +INF] EQUIVALENCES: { } (0 elements)
D.1884_5 = D.1883_4 | 1;
Shouldn't we find that D.1884_5 is 1 at this point because _4 was [0,1]
and [0, 1] | 1 is just 1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18031
[Bug c/27342] GCC-bootstrap using ./xgcc on libgcov.c with -DL_gcov (1st of several libgcov.c
--- Comment #4 from malitzke at metronets dot com 2006-04-27 21:25 --- Well, Andy, not so fast. Doing: ./xgcc -B./ -c libgcov,i I get no message and a get a libgcov,o Anyhow that machine is a four processor server with 2G error corrected memory. Also I have about 13 other commands processing libgcov.c, but each time with a different -DLgcov_xxx and none of them turns up any errors. -- malitzke at metronets dot com changed: What|Removed |Added Component|middle-end |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27342
[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level
--- Comment #7 from steven at gcc dot gnu dot org 2006-04-27 21:32 --- Yes, BIT_IOR_EXPR is also not handled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18031
[Bug c/27342] GCC-bootstrap using ./xgcc on libgcov.c with -DL_gcov (1st of several libgcov.c
--- Comment #5 from malitzke at metronets dot com 2006-04-27 22:03 --- Further: I started the gcc-4.1.1 bootstrap with a different gcc (atually now a earlier 4.2.0) and it come up with the same else label does not match edge. The xgcc now was generated by a different version of gcc. While this boot was going on I retried the earlier ./xgcc to most likely hit a different processor and a different memory region; same thing as before. Most likely that particular define is triggering some otherwise hidden bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27342
[Bug rtl-optimization/27291] [4.2 regression] verify_flow_info failed: too many outgoing branch edges from bb 4
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-04-27 22:21 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01058.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||04/msg01058.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27291
[Bug libgcj/27330] natSystemProperties.cc:213: error: 'getpwuid_r' was not declared in this scope
--- Comment #3 from andreast at gcc dot gnu dot org 2006-04-27 22:33 --- I'll submit the patch tommorow. It has been in my queue for a longer time. Index: configure.ac === --- configure.ac(revision 113320) +++ configure.ac(working copy) @@ -811,6 +811,14 @@ THREADLIBS='-lpthread -lrt' THREADSPEC='-lpthread -lrt' ;; + hppa*-hp-hpux*) +THREADCXXFLAGS=-pthread + # boehm-gc needs some functions from librt, so link that too. + THREADLIBS='-lpthread -lrt' + THREADSPEC='-lpthread -lrt' + # HPUX needs REENTRANT for the _r calls. + AC_DEFINE(_REENTRANT, 1, [Required define if using POSIX threads]) + ;; *) THREADLIBS=-lpthread THREADSPEC=-lpthread -- andreast at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |andreast at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-27 22:33:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27330
[Bug c++/27344] New: associativity of * operator incorrect when compiled without optimization
Here is the version and system info:
% g++ -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.5/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)
Here is the output from the test program (which is included below)
% g++ -o associativityTest -O3 associativityTest.cpp
% ./associativityTest
neg_50 = -50
% g++ -o associativityTest associativityTest.cpp
% ./associativityTest
neg_50 = 50
You can see the different answers above, as a result of compiling with and
without optimization. The answer of -50 is correct, based on the left to right
associativity of the * operator.
Here is the test file associativityTest.cpp:
#include iostream
using namespace std;
class Int
{
public:
explicit Int(int value)
: _value(value)
{
}
Int neg()
{
_value *= -1;
return *this;
}
int value()
{
return _value;
}
Int operator*(Int right)
{
return Int(_value*right._value);
}
private:
int _value;
};
Int operator*(Int I, int i)
{
return I*Int(i);
}
Int operator*(int i, Int I)
{
return I*i;
}
int main()
{
Int five(5);
Int neg_50 = (five * 2 * five.neg());
cout neg_50 = neg_50.value() endl;
}
--
Summary: associativity of * operator incorrect when compiled
without optimization
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mike dot clarkson at spacedev dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27344
[Bug c++/27344] associativity of * operator incorrect when compiled without optimization
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-28 00:00 --- (five * 2 * five.neg()); This is equivlant to: (five * 2) * (five.neg()) but the C and C++ standard do not specify which expression is evulated first. In that (five * 2) might be evulated first or five.neg(). five.neg() has a side effect of changing five (_value *= -1;) which makes the above statement undefined as five is accessed and written to without a sequence point inbetween. And it makes it a duplicate of PR 11751. *** This bug has been marked as a duplicate of 11751 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27344
[Bug c/11751] wrong evaluation order of an expression
--- Comment #71 from pinskia at gcc dot gnu dot org 2006-04-28 00:00 --- *** Bug 27344 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mike dot clarkson at ||spacedev dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
[Bug c++/27292] [4.2 regression] ICE on casts on bitfields
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-04-28 02:41 --- Subject: Bug 27292 Author: mmitchel Date: Fri Apr 28 02:40:58 2006 New Revision: 113339 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113339 Log: PR c++/27292 * tree.c (rvalue): Convert bitfields to their declared types. PR c++/27292 * g++.dg/conversion/bitfield4.C: New test. Added: trunk/gcc/testsuite/g++.dg/conversion/bitfield4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27292
[Bug c++/27292] [4.2 regression] ICE on casts on bitfields
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-04-28 02:42 --- Fixed in 4.2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27292
[Bug testsuite/27274] execution test of gcc.dg/i386-sse-9.c fails on non-SSE CPU
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-28 03:31 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27274
[Bug middle-end/27095] [4.1 Regression] O2 produces duplicate code
--- Comment #9 from amodra at gcc dot gnu dot org 2006-04-28 03:36 --- Subject: Bug 27095 Author: amodra Date: Fri Apr 28 03:36:15 2006 New Revision: 113340 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113340 Log: PR middle-end/27095 * gcc.dg/pr27095.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr27095.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27095
[Bug middle-end/27260] [4.1/4.2 Regression] ICE in expand_expr_real_1, at expr.c:6750
--- Comment #9 from amodra at gcc dot gnu dot org 2006-04-28 03:41 --- Subject: Bug 27260 Author: amodra Date: Fri Apr 28 03:41:34 2006 New Revision: 113341 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113341 Log: gcc/ PR middle-end/27260 * builtins.c (expand_builtin_memset): Expand val in original mode. gcc/testsuite/ PR middle-end/27260 * gcc.c-torture/execute/pr27260.c: New. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr27260.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27260
[Bug bootstrap/27334] [4.0/4.1 onlly] gcc/Makefile.in:s-macro_list sed fails with make 3.81 due to POSIX support changes
--- Comment #3 from mark at codesourcery dot com 2006-04-28 05:02 --- Subject: Re: gcc/Makefile.in:s-macro_list sed fails with make 3.81 due to POSIX support changes debian-gcc at lists dot debian dot org wrote: --- Comment #1 from debian-gcc at lists dot debian dot org 2006-04-27 07:33 --- thanks for pointing that out, my mistake to check that in. Mark, ok keep that change and document that change in the existing changelog entry? * Makefile.in (s-macro_list): Conform to POSIX rules in single quoted strings Yes, that's OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27334
