[Bug fortran/58007] ICE -- free_pi_tree(): Unresolved fixup, depends on order of module inclusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus --- Created attachment 30565 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30565&action=edit Patch to make it compile with GCC 4.8 and 4.9 (In reply to shapero from comment #0) > git clone https://github.com/danshapero/fempack.git > git checkout e7547abe131b5c0e137fb0327069a75fcfed5d90 > make libs To underline the elusiveness: With 4.7.3 (release build), it builds without running into the ICE. With GCC 4.9 (and GCC 4.8) it doesn't build: src/linalg/matrix_formats/csr.f90:24.13: procedure :: subset_matrix_add => csr_subset_matrix_add 1 Error: Argument mismatch for the overriding procedure 'subset_matrix_add' at (1): Type mismatch in argument 'b' (CLASS(csr_matrix)/CLASS(sparse_matrix)) However, if I apply the attached patch, it builds with gcc 4.9 - and I can reproduce the "free_pi_tree(): Unresolved fixup".
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #63 from Oleg Endo --- Created attachment 30566 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30566&action=edit Reduced test (In reply to Laurent Aflonsi from comment #58) > Created attachment 30524 [details] > functional regression This is a stripped down test case.
[Bug c++/52844] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52844 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #9 from Paolo Carlini --- Looking into it.
[Bug rtl-optimization/58008] New: ICE: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58008
Bug ID: 58008
Summary: ICE: Max. number of generated reload insns per insn is
achieved (90)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: antoine.balestrat at gmail dot com
Hello !
With GCC 4.9.0 as of 20130728 :
$ cat max.c
int a, b, c, d, e;
void f(void)
{
if(c)
goto lbl;
for(; 0; c++)
{
short f;
lbl:
for(; a; a++)
e *= f += b ? : (d = 0);
}
}
$ xgcc -march=corei7 -O2 -funswitch-loops -ftree-vectorize -funroll-loops max.c
max.c: In function ‘f’:
max.c:15:1: internal compiler error: Max. number of generated reload insns per
insn is achieved (90)
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug fortran/58007] ICE -- free_pi_tree(): Unresolved fixup, depends on order of module inclusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007
--- Comment #2 from Tobias Burnus ---
Created attachment 30567
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30567&action=edit
Reduced test case
Reduced test case, which fails at least on my 86-64-gnu-linux system with a
recent GCC 4.9. Compile as:
$ gfortran matrix.f90 ellpack.f90 bsr.f90 matrix_c.f90
matrix_c.f90:4.8:
use bsr
1
Internal Error at (1):
free_pi_tree(): Unresolved fixup
* * *
The triggered assert is:
221 free_pi_tree (pointer_info *p)
222 {
223 if (p == NULL)
224 return;
225
226 if (p->fixup != NULL)
227 gfc_internal_error ("free_pi_tree(): Unresolved fixup");
For the failing case, one has:
(gdb) p *p->fixup
$4 = {pointer = 0x1678e08, next = 0x16780a0}
(gdb) p *p
$2 = {priority = 38379, left = 0x1609dd0, right = 0x1606b20, integer = 6, type
= P_COMPONENT, fixup = 0x1678f80, u = {pointer = 0x0, rsym = {sym = 0x0,
true_name = 0x0, module = 0x0, binding_label = 0x0, stfixup = 0x0, symtree =
0x0, state = UNUSED, ns = 0, referenced = 0, renamed = 0, where = {column = 0,
line = 0, pos = 0}}, wsym = {sym = 0x0, state = UNREFERENCED}}}
Here, *(p->fixup->pointer) == NULL and *p->fixup->next->pointer == NULL.
Debugging shows that p->fixup->pointer is the address of the "cp" argument in
the call to mio_pointer_ref in mio_component_ref for sym ==
__class_bsr_Bsr_matrix and the component name "max_degreemio_pointer_ref".
And p->fixup->next->pointer is sym='__class_bsr_Bsr_matrix' and component name
max_degreemio_pointer_ref
(i.e. the same, except that "cp" has a different pointer address.)
* * *
read_cleanup takes care of resolve_fixups - but only for p->type == P_SYMBOL.
However, we have here a p->type == P_COMPONENT.
[Bug fortran/58007] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007 Tobias Burnus changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-28 Summary|ICE -- free_pi_tree(): |ICE in free_pi_tree(): |Unresolved fixup, depends |Unresolved fixup - |on order of module |resolve_fixups does not |inclusion |fixup component of ||__class_bsr_Bsr_matrix Ever confirmed|0 |1
[Bug fortran/58009] New: Elements with same value in vector subscript in variable definition context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58009 Bug ID: 58009 Summary: Elements with same value in vector subscript in variable definition context Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org The following is illegal: program main real, dimension(4) :: a,b read (*,*) a b([1,2,3,2]) = a print *,b end See F 2008, 6.5.3.3.2: If a vector subscript has two or more elements with the same value, an array section with that vector subscript shall not appear in a variable definition context (16.6.7)
[Bug tree-optimization/58010] New: ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4378
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58010
Bug ID: 58010
Summary: ICE in vect_create_epilog_for_reduction, at
tree-vect-loop.c:4378
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: antoine.balestrat at gmail dot com
Hello !
Using GCC 4.9.0 as of 20130728 :
$ cat vect.c
short a, b, c, d;
void f(void)
{
short e;
for(; e; e++)
for(; b; b++);
for(d = 0; d < 4; d++)
a ^= (e ^= 1) || c ? : e;
}
$ xgcc -O2 -funswitch-loops -ftree-vectorize vect.c
vect.c: In function ‘f’:
vect.c:3:6: internal compiler error: in vect_create_epilog_for_reduction, at
tree-vect-loop.c:4378
void f(void)
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug fortran/58009] Elements with same value in vector subscript in variable definition context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58009 Thomas Koenig changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Thomas Koenig --- ... and it would be nice to diagnose it (with a hard error) whenever possible.
[Bug fortran/58009] Elements with same value in vector subscript in variable definition context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58009 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-28 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > ... and it would be nice to diagnose it (with a hard > error) whenever possible. Indeed! I can think of an O(N**2) algorithm with a scalar temporary or an O(N) one with an O(N) temporary. Do you have better ideas?
[Bug tree-optimization/58011] New: GCC segfaults at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58011
Bug ID: 58011
Summary: GCC segfaults at -O1
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: antoine.balestrat at gmail dot com
Using GCC 4.9.0 as of 20130728 :
$ cat seg.c
int a, b;
void f(unsigned p)
{
unsigned *pp = &p;
if(!a)
p = 0;
for(b = 0; b < 1; b++)
if(3 * p + 5 * *pp)
a = 0;
}
$ xgcc -O1 seg.c
seg.c: In function ‘f’:
seg.c:3:6: internal compiler error: Segmentation fault
void f(unsigned p)
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug fortran/58009] Elements with same value in vector subscript in variable definition context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58009 --- Comment #3 from Thomas Koenig --- I also want to catch a([i,j,i]) = ... for which I cannot think of an algorithm which is O(n), so I guess it will have to be O(n**2).
[Bug fortran/58009] Elements with same value in vector subscript in variable definition context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58009 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus --- (In reply to Thomas Koenig from comment #3) > a([i,j,i]) = ... > for which I cannot think of an algorithm which is O(n), > so I guess it will have to be O(n**2). Given that most code has either no or only very few vector subscripts, it shouldn't matter too much. Additionally, I expect that one either has only very few elements - or one uses A([array]) which is not compile-time checkable. The only case where one might have a lot of elements in the vector is in generated code - but that looks as a very, very special case for which one does not need to performance optimize, I'd guess. Side note: I tried your example with NAG f95 5.1 (of 2007) - and it does not detect the issue - neither at compile nor at runtime (-C=all).
[Bug tree-optimization/58006] [4.8/4.9 Regression] ICE compiling VegaStrike with -ffast-math -ftree-parallelize-loops=2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58006
--- Comment #5 from Marc Glisse ---
extern "C" float sqrtf (float);
extern int a;
extern int b;
struct Vector {
float i;
float j;
float Magnitude() const {
return sqrtf( i*i+j*j );
}
};
void f(){
int i = a;
int end = b;
for (; i != end; ++i) {
float tmag = Vector().Magnitude();
}
}
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #64 from Oleg Endo ---
(In reply to Laurent Aflonsi from comment #61)
>
> The movt(L2) and the tst(L3) are both removed, and that's coherent for that
> run path, because it is preceded by the tst r2,r2.
> But that makes the first path incoherent because L3 can be reached by the
> very first block. I have written a first fix, too restrictive ("pr25869-19.c
> scan-assembler-not movt" is failing) :
>
> --- ./gcc/gcc/config/sh/sh.md.orig
> +++ ./gcc/gcc/config/sh/sh.md
> @@ -8523,7 +8523,8 @@
>T bit. Notice that some T bit stores such as negc also modify
>the T bit. */
> if (modified_between_p (get_t_reg_rtx (), s1.insn, testing_insn)
> - || modified_in_p (get_t_reg_rtx (), s1.insn))
> + || modified_in_p (get_t_reg_rtx (), s1.insn)
> + || !no_labels_between_p(s1.insn, testing_insn))
> operands[2] = NULL_RTX;
>
> break;
>
> The idea would be to check if "s1.insn block dominates testing_insn block",
> but I don't know how to write it at this stage.
The proper way would be to find all basic blocks that set the tested reg. With
the reduced test case, just right before the split1 pass there are two basic
blocks that set reg 167 which is then tested for '== 0' before the conditional
branch:
(note 13 12 14 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
<...>
(insn 15 14 16 3 (set (reg:SI 147 t)
(eq:SI (reg:SI 173 [ MEM[(int *)q_3(D) + 4B] ])
(const_int 0 [0]))) sh_tmp.cpp:84 17 {cmpeqsi_t}
(expr_list:REG_DEAD (reg:SI 173 [ MEM[(int *)q_3(D) + 4B] ])
(nil)))
(insn 16 15 17 3 (set (reg:SI 175)
(const_int -1 [0x])) sh_tmp.cpp:84 250 {movsi_ie}
(nil))
(note 17 16 18 3 NOTE_INSN_DELETED)
(insn 18 17 71 3 (parallel [
(set (reg:SI 167 [ D.1424 ])
(xor:SI (reg:SI 147 t)
(const_int 1 [0x1])))
(set (reg:SI 147 t)
(const_int 1 [0x1]))
(use (reg:SI 175))
]) sh_tmp.cpp:84 394 {movrt_negc}
(expr_list:REG_DEAD (reg:SI 175)
(expr_list:REG_UNUSED (reg:SI 147 t)
(nil
(jump_insn 71 18 72 3 (set (pc)
(label_ref 27)) -1
(nil)
-> 27)
(barrier 72 71 21)
(code_label 21 72 22 4 2 "" [1 uses])
(note 22 21 23 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
<...>
(insn 24 23 26 4 (set (reg:SI 147 t)
(eq:SI (reg:SI 177 [ *q_3(D) ])
(const_int 0 [0]))) sh_tmp.cpp:85 17 {cmpeqsi_t}
(expr_list:REG_DEAD (reg:SI 177 [ *q_3(D) ])
(nil)))
(insn 26 24 27 4 (set (reg:SI 167 [ D.1424 ])
(reg:SI 147 t)) sh_tmp.cpp:85 392 {movt}
(expr_list:REG_DEAD (reg:SI 147 t)
(nil)))
(code_label 27 26 28 5 3 "" [1 uses])
(note 28 27 29 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 29 28 30 5 (set (reg:SI 147 t)
(eq:SI (reg:SI 167 [ D.1424 ])
(const_int 0 [0]))) sh_tmp.cpp:91 17 {cmpeqsi_t}
(expr_list:REG_DEAD (reg:SI 167 [ D.1424 ])
(nil)))
(jump_insn 30 29 31 5 (set (pc)
(if_then_else (ne (reg:SI 147 t)
(const_int 0 [0]))
(label_ref:SI 50)
(pc))) sh_tmp.cpp:91 295 {*cbranch_t}
(expr_list:REG_DEAD (reg:SI 147 t)
(expr_list:REG_BR_PROB (const_int 400 [0x190])
(nil)))
-> 50)
Here it starts walking up the insns from insn 29 [bb 5] and finds insn 26 [bb
4], but it should also check [bb 3].
The question then is, what to do with the collected basic blocks. Ideally it
should look at all the T bit paths in every basic block and try to eliminate
redundant T bit flipping in each basic block so that in this case [bb 5] can
start with the conditional branch.
Then this ...
mov.l @(4,r4),r1
tst r1,r1 // T = @(4,r4) == 0
mov #-1,r1
negcr1,r1 // r1 = @(4,r4) != 0
.L3:
tst r1,r1 // T = @(4,r4) == 0
bt/s.L5
mov #1,r1
cmp/hi r1,r5
bf/s.L9
mov #0,r0
rts
nop
.L2:
mov.l @r4,r1
tst r1,r1 // T = @(r4) == 0
bra .L3
movtr1 // r1 = @(r4) == 0
would be simplified to this:
mov.l @(4,r4),r1
tst r1,r1 // T = @(4,r4) == 0
.L3:
bt/s.L5
mov #1,r1
cmp/hi r1,r5
bf/s.L9
mov #0,r0
rts
nop
.L2:
mov.l @r4,r1
bra .L3
tst r1,r1 // T = @(r4) == 0
Maybe if BImode was used for the T bit, combine could do better at folding T
bit flipping. However, it would not do cross BB analysis, so I think it's
pointless to try out BImode.
I'm not sure whether there is already something in the compiler that could do
this kind of optimization. According to my observations it should happen after
the combine pass and before register allocation to get useful results.
Until then I think the following should be applied to 4.9 and 4.
[Bug fortran/58009] Elements with same value in vector subscript in variable definition context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58009 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #5 from Thomas Koenig --- I have a patch.
[Bug fortran/57435] [4.8 Regression] Ice on invalid: check_for_ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57435 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Summary|[4.8/4.9 Regression] Ice on |[4.8 Regression] Ice on |invalid:|invalid: |check_for_ambiguous |check_for_ambiguous --- Comment #8 from Paul Thomas --- Hi Tobias, Were you going to backport the patch now that 4.8.1 has been released? Cheers Paul
[Bug fortran/55789] [4.7 Regression] Needless realloc with array constructor.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55789 --- Comment #15 from Paul Thomas --- No, it does not work on 4.7. I am inclined to say that it should be a WONTFIX. Cheers Paul
[Bug fortran/57435] [4.8 Regression] Ice on invalid: check_for_ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57435 --- Comment #9 from Tobias Burnus --- Author: burnus Date: Sun Jul 28 14:13:17 2013 New Revision: 201293 URL: http://gcc.gnu.org/viewcvs?rev=201293&root=gcc&view=rev Log: 2013-07-28 Tobias Burnus Backport from mainline 2013-05-28 Dominique d'Humieres PR fortran/57435 * module.c (check_for_ambiguous): Avoid null pointer deref. 2013-07-28 Tobias Burnus Backport from mainline 2013-05-28 Tobias Burnus PR fortran/57435 * gfortran.dg/use_29.f90: New. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/use_29.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/module.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/57435] [4.8 Regression] Ice on invalid: check_for_ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57435 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Tobias Burnus --- (In reply to Paul Thomas from comment #8) > Were you going to backport the patch now that 4.8.1 has been released? Good point! I did so now. Close as FIXED. Lorenz: Thanks for the bug report!
[Bug fortran/31016] Use __buildin_memcpy and __memcpy for array assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31016 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #8 from Eric Botcazou --- > Disclaimer: The example above should be correct. However, I have not fully > understood how RANGE_REF works, i.e. what the last two arguments (here: > NULL_TREE) do. It works exactly like ARRAY_REF as far as they are concerned.
[Bug tree-optimization/58012] New: Gcc bootstrap failed with cloog-isl: undefined reference to std::istream::ignore(long)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58012 Bug ID: 58012 Summary: Gcc bootstrap failed with cloog-isl: undefined reference to std::istream::ignore(long) Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: goughost at yahoo dot com.cn ../gcc-4.8.1/libstdc++-v3/src/c++98/istream.cc:116: error: undefined reference to 'std::istream::ignore(long)' ../gcc-4.8.1/libstdc++-v3/src/c++98/istream.cc:521: error: undefined reference to 'std::basic_istream >::ignore(long)' Build failed with system cloog/isl (version 0.18.0 and 0.11.1), when making cc1 in ./gcc/ in stage2. Without cloog/isl, build is ok. It's configured this way: ../gcc-4.8.1/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-lto --disable-multilib --enable-shared --disable-static --enable-__cxa_atexit --enable-threads=posix --enable-languages=c,c++,fortran --enable-plugin --with-system-zlib When making cc1, `-static-libstdc++' is passed to bootstrap compiler, and `libstdc++.a' (a copy of `libstdc++convenience.a') is used. On the other hand, `libstdc++convenience.a' is an incomplete library. At least `std::istream::ignore(long)' (in compatibility.cc) is not included. Without cloog/isl, linking succeeds, since no linked object refers to istream. With cloog/isl, graphite*.c files includes isl headers. In , there is a function: `std::ostream &operator<<(std::ostream &os, isl_int i)'. Remove this function definition, recompile graphite*.c, and link: succeed. I'm not sure whether this is a bug in Gcc or there's something wrong with my compile environment.
[Bug fortran/57992] Pointless packing of contiguous arrays for simply contiguous functions results as actual arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57992
--- Comment #1 from Tobias Burnus ---
Draft patch:
* Handles POINTER (-> temporary), POINTER, CONTIGUOUS (-> no temporary) and
ALLOCATABLE (->no temporary)
TODO
* Nonpointers, nonallocatables (like f3) are *not* handled (why?)
* Check whether TBP or PPC are handled correctly
* Check whether sym == sym->result and sym != sym->result are handled
* Check whether CLASS is handled correctly
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -7012,6 +7012,11 @@ gfc_conv_array_parameter (gfc_se * se, gfc_expr * expr,
bool g77,
if (expr->expr_type == EXPR_VARIABLE && ref && !ultimate_ptr_comp)
full_array_var = gfc_full_array_ref_p (ref, &contiguous);
+ else if (expr->expr_type == EXPR_FUNCTION)
+{
+ symbol_attribute attr = gfc_expr_attr (expr);
+ contiguous = !attr.pointer || attr.contiguous;
+}
sym = full_array_var ? expr->symtree->n.sym : NULL;
[Bug tree-optimization/57994] Constant folding of infinity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #11 from joseph at codesourcery dot com ---
On Sat, 27 Jul 2013, glisse at gcc dot gnu.org wrote:
> Yeah, any of those. I was inspired by glibc, which has for instance:
>
> double
> __fdim (double x, double y)
> {
> int clsx = fpclassify (x);
> int clsy = fpclassify (y);
>
> if (clsx == FP_NAN || clsy == FP_NAN
> || (y < 0 && clsx == FP_INFINITE && clsy == FP_INFINITE))
> /* Raise invalid flag. */
> return x - y;
>
> which looks like it expects QNaN-QNaN to set the invalid flag.
Such comments must be understood to be written on the assumption that the
reader is familiar with the desired IEEE semantics - that is, that the
flags is raised if and only if a NaN argument is a signaling NaN (and such
arithmetic patterns on input NaNs, to ensure that "invalid" is raised if
either NaN is signaling, and otherwise that an input NaN's significand is
preserved, are very common in glibc).
[Bug fortran/58007] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007
--- Comment #3 from shapero at uw dot edu ---
(In reply to Tobias Burnus from comment #2)
> Created attachment 30567 [details]
> Reduced test case
>
> Reduced test case, which fails at least on my 86-64-gnu-linux system with a
> recent GCC 4.9. Compile as:
>
> $ gfortran matrix.f90 ellpack.f90 bsr.f90 matrix_c.f90
> matrix_c.f90:4.8:
> use bsr
> 1
> Internal Error at (1):
> free_pi_tree(): Unresolved fixup
>
> * * *
>
> The triggered assert is:
> 221 free_pi_tree (pointer_info *p)
> 222 {
> 223 if (p == NULL)
> 224 return;
> 225
> 226 if (p->fixup != NULL)
> 227 gfc_internal_error ("free_pi_tree(): Unresolved fixup");
>
> For the failing case, one has:
>
> (gdb) p *p->fixup
> $4 = {pointer = 0x1678e08, next = 0x16780a0}
>
> (gdb) p *p
> $2 = {priority = 38379, left = 0x1609dd0, right = 0x1606b20, integer = 6,
> type = P_COMPONENT, fixup = 0x1678f80, u = {pointer = 0x0, rsym = {sym =
> 0x0, true_name = 0x0, module = 0x0, binding_label = 0x0, stfixup = 0x0,
> symtree = 0x0, state = UNUSED, ns = 0, referenced = 0, renamed = 0, where =
> {column = 0, line = 0, pos = 0}}, wsym = {sym = 0x0, state = UNREFERENCED}}}
>
> Here, *(p->fixup->pointer) == NULL and *p->fixup->next->pointer == NULL.
>
>
> Debugging shows that p->fixup->pointer is the address of the "cp" argument
> in the call to mio_pointer_ref in mio_component_ref for sym ==
> __class_bsr_Bsr_matrix and the component name "max_degreemio_pointer_ref".
>
> And p->fixup->next->pointer is sym='__class_bsr_Bsr_matrix' and component
> name max_degreemio_pointer_ref
>
> (i.e. the same, except that "cp" has a different pointer address.)
>
> * * *
>
> read_cleanup takes care of resolve_fixups - but only for p->type ==
> P_SYMBOL. However, we have here a p->type == P_COMPONENT.
I should have specified in my post but I'm using gfortran 4.7.2; your reduced
test case also fails for me. Could it be due to the explicit shape of the
return argument for bsr_get_neighbors?
Also, in reply to your first comment: should I be getting a type mismatch error
for the code I've written and my version of the compiler isn't working right,
or is my code compliant and versions 4.8/4.9 have a problem?
[Bug c++/58013] New: main() not generated in assembler output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58013 Bug ID: 58013 Summary: main() not generated in assembler output Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++ -B/test/gnu/gcc/objdir/g cc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/opt/pr56999.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/ gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -O2 -fpic -L/tes t/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -B/test/gnu/gcc/ob jdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -lm -o ./pr56999.exe ld: (Warning) Potential unresolved symbol "main": shared library reference is resolved to non-exported definition in file "/var/tmp//ccUra9KR.o". FAIL: g++.dg/opt/pr56999.C -std=gnu++98 (test for excess errors)
[Bug fortran/58003] internal compiler error: in convert_mpz_to_unsigned, at fortran/simplify.c:165
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58003 --- Comment #3 from Chris Gilbreth --- Thanks
[Bug tree-optimization/58006] [4.8/4.9 Regression] ICE compiling VegaStrike with -ffast-math -ftree-parallelize-loops=2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58006 --- Comment #6 from Paolo Carlini --- Thanks Marc.
[Bug c++/58014] New: vshuf-v2si.C fails at -O3 on hppa64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58014 Bug ID: 58014 Summary: vshuf-v2si.C fails at -O3 on hppa64 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 FAIL: g++.dg/torture/vshuf-v2sf.C -O3 -fomit-frame-pointer execution test FAIL: g++.dg/torture/vshuf-v2sf.C -O3 -g execution test FAIL: g++.dg/torture/vshuf-v2si.C -O3 -fomit-frame-pointer execution test FAIL: g++.dg/torture/vshuf-v2si.C -O3 -g execution test Introduced between 197667 and 198496.
[Bug libfortran/58015] New: FAIL: gfortran.dg/round_4.f90: Unsatisfied symbol "nextafterl"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58015 Bug ID: 58015 Summary: FAIL: gfortran.dg/round_4.f90: Unsatisfied symbol "nextafterl" Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B/test/gnu/gcc /objdir/gcc/testsuite/gfortran/../../ -B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/round_4.f90 -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -pedantic-errors -B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs -B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs -lm -o ./round_4.exe ld: Unsatisfied symbol "nextafterl" in file /var/tmp//ccSPc0rP.o 1 errors.collect2: error: ld returned 1 exit statuscompiler exited with status 1output is:ld: Unsatisfied symbol "nextafterl" in file /var/tmp//ccSPc0rP.o1 errors.collect2: error: ld returned 1 exit status FAIL: gfortran.dg/round_4.f90 -O0 (test for excess errors)
[Bug tree-optimization/57994] Constant folding of infinity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994 --- Comment #12 from Vincent Lefèvre --- (In reply to Marc Glisse from comment #9) > I believe there are far fewer special cases (and thus > risks) with MPFR, but that would indeed require a suitable testsuite for all > functions for which we enable it (at least if MPFR doesn't already have such > a testsuite, and maybe even then, to make sure we call it properly). MPFR's testsuite is just against the MPFR implementation. These are actually non-regression tests. For comparisons with the functions from the C library, there's mpcheck: https://gforge.inria.fr/projects/mpcheck/ but I don't know whether it includes special values (it wasn't its goal). Note that we tried to follow C99's Annex F when this made sense. MPFR also supports some special functions that are not in ISO C (yet), but may be provided by the C library on some platforms (e.g. Bessel functions, which are also specified in POSIX). Don't forget that the specific rules for signed zeroes are also concerned; again, we tried to follow C99's Annex F, IIRC, even when the specification was rather inconsistent (e.g. under the rounding mode toward negative infinity, the subtraction 1 - 1 returns -0, but log(1) is required to return +0).
[Bug c/58016] New: stdatomic.h missing in 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016
Bug ID: 58016
Summary: stdatomic.h missing in 4.8.1
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jeff.science at gmail dot com
GCC 4.8.1 provides a -std=c11 option that defines __STDC_VERSION__ >= 201112L
and does not define __STDC_NO_ATOMICS__, hence is required to provide
stdatomic.h. This requirement is not met.
This ticket is closely related to 53769 but I am not reporting the fact that
the macros aren't defined, but rather the missing header.
> cat test-c11-atomics.c
#if __STDC_VERSION__ >= 201112L
# ifdef __STDC_NO_ATOMICS__
# error Your C11 compiler is not required to provide stdatomic.h
# else
# include
# endif
#else
# error Your C compiler isn't providing C11.
#endif
int main(int argc, char * argv[])
{
return 0;
}
> gcc-mp-4.8 -g -Wall -std=c11 test-c11-atomics.c
test-c11-atomics.c:4:23: fatal error: stdatomic.h: No such file or directory
#include
^
compilation terminated.
> gcc-mp-4.8 -v
Using built-in specs.
COLLECT_GCC=gcc-mp-4.8
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper
Target: x86_64-apple-darwin11
Configured with: ../gcc-4.8.1/configure --prefix=/opt/local
--build=x86_64-apple-darwin11
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-4.8
--with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local
--with-cloog=/opt/local --enable-cloog-backend=isl
--disable-cloog-version-check --enable-stage1-checking --disable-multilib
--enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as
--with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar
--with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts
gcc48 4.8.1_0'
Thread model: posix
gcc version 4.8.1 (MacPorts gcc48 4.8.1_0)
> uname -a
Darwin Jeffs-MacBook-Pro.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23
16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
[Bug target/58017] New: [SH] Use shift and test for unsigned compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58017
Bug ID: 58017
Summary: [SH] Use shift and test for unsigned compare
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
On SH unsigned int comparisons against some constants can be converted to shift
and test sequences to potentially save one register.
For example:
int test_00 (unsigned int a, int b, int c)
{
if (a == 0 || a == 1)
return 50;
return 0;
}
compiled with -O2:
mov #1,r1
cmp/hi r1,r4 // T = r4 > r1 (unsigned)
bf/s.L7
mov #0,r0
rts
nop
.L7:
rts
mov #50,r0
can also be written as:
shlrr4 // r4 >>= 1
tst r4,r4 // T = r4 == 0
bt .L7
mov #0,r0
rts
nop
.L7:
rts
mov #50,r0
In this case it doesn't save much, but if register pressure is high and the
compared value is not used anywhere else, this can avoid using one register for
the comparison constant. This is probably only going to be beneficial for
right shift patterns that can be done in 1 or 2 insns and if the inverted
comparison result can be handled by a following conditional branch.
If the comparison constant does not fit into an imm8 it will be loaded from the
constant pool:
mov.l .L7,r1
cmp/hi r1,r4
bf .L3
mov #50,r0
rts
nop
.L3:
rts
mov #0,r0
.L8:
.align 2
.L7:
.long 65535
In this case it might always be beneficial to replace the comparison with
shlr16 r4
tst r4,r4
especially if the compared reg is dead after the comparison.
[Bug c/58016] stdatomic.h missing in 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016 Paolo Carlini changed: What|Removed |Added Severity|blocker |normal
[Bug middle-end/56791] [4.8/4.9 Regression] Segmentation fault in stage2 gengenrtl -- Incorrect instruction sequence generated by reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56791 John David Anglin changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #3 from John David Anglin --- I think this issue was latent and exposed by r195702. It didn't change the way auto increment/decrement instructions were handled. Problem can be worked around on hppa1.1 as follows: Index: pa.c === --- pa.c(revision 198081) +++ pa.c(working copy) @@ -513,6 +513,12 @@ write_symbols = NO_DEBUG; } +#ifdef AUTO_INC_DEC + /* FIXME: Disable auto increment and decrement processing until reload + is completed. See PR middle-end 56791. */ + flag_auto_inc_dec = reload_completed; +#endif + /* We only support the "big PIC" model now. And we always generate PIC code when in 64bit mode. */ if (flag_pic == 1 || TARGET_64BIT) Problem can duplicated on hpux11 by configuring for hppa1.1. However, I can't see any way to fix this in the PA backend.
[Bug middle-end/56668] FAIL: gcc.dg/pr56494.c: ICE in simplify_subreg, at simplify-rtx.c:5725
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56668 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from John David Anglin --- Fixed.
[Bug debug/56307] FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra "Created a debug-only replacement for s"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56307 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #17 from John David Anglin --- Fixed.
[Bug tree-optimization/55625] FAIL: gcc.dg/tree-prof/tracer-1.c scan-tree-dump-times tracer "c =" 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55625 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from John David Anglin --- Fixed.
[Bug tree-optimization/55626] FAIL: gcc.dg/tree-prof/val-prof-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55626 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from John David Anglin --- Fixed.
[Bug rtl-optimization/9702] [ARM] Constant pools are not shared among functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9702 Oleg Endo changed: What|Removed |Added Target|arm*-* |arm*-* sh*-*-* CC||olegendo at gcc dot gnu.org --- Comment #8 from Oleg Endo --- The same applies to SH and probably other targets that use constant pools in the text sections.
[Bug c/58016] stdatomic.h missing in 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016 --- Comment #1 from joseph at codesourcery dot com --- I don't know whether Andrew intends stdatomic.h to go in GCC or glibc, but in any case I consider this a duplicate of bug 53769, which in turn I don't really consider a useful bug report at all (incompleteness of the implementation of an option documented in the manual as incomplete should not be considered a bug).
[Bug tree-optimization/58011] GCC segfaults at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58011 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-28 CC||eraman at google dot com, ||olegendo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Oleg Endo --- With SVN rev 201282, SH cross compiler and -O2 I get: internal compiler error: Segmentation fault void f(unsigned p) ^ 0x87a4250 crash_signal ../../gcc-trunk2/gcc/toplev.c:334 0x88f60c4 build_and_add_sum ../../gcc-trunk2/gcc/tree-ssa-reassoc.c:4473 0x88feb46 undistribute_ops_list ../../gcc-trunk2/gcc/tree-ssa-reassoc.c:1462 0x88ff334 reassociate_bb ../../gcc-trunk2/gcc/tree-ssa-reassoc.c:4244 0x88ff0e6 reassociate_bb ../../gcc-trunk2/gcc/tree-ssa-reassoc.c:4324 0x88ff0e6 reassociate_bb ../../gcc-trunk2/gcc/tree-ssa-reassoc.c:4324 0x88ff0e6 reassociate_bb ../../gcc-trunk2/gcc/tree-ssa-reassoc.c:4324 0x890118e do_reassoc ../../gcc-trunk2/gcc/tree-ssa-reassoc.c:4358 0x890118e execute_reassoc ../../gcc-trunk2/gcc/tree-ssa-reassoc.c:4440 Please submit a full bug report, CC'ing Easwaran Raman who was the last to touch tree-ssa-reassoc.c according to the changelog.
[Bug ada/52280] FAIL: c974013 -- C974013 Abortable part did not execute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52280 John David Anglin changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from John David Anglin --- Still fails on and off.
[Bug c/58016] stdatomic.h missing in 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016 --- Comment #2 from Jeff Hammond --- If GCC doesn't support C11, it should not claim to support C11 via __STDC_VERSION__. The C11 standard definition isn't a recommendation from which implementers can pick and choose based upon their priorities. Documentation an implementations failure to comply with a standard does not absolve an implementation from lying about its features with ISO standard macros. The macro is part of the standard; the documentation is not. In any case, there is an absolutely trivial way for GCC to satisfy the C11 standard with respect to stdatomic.h, and it involves __STDC_NO_ATOMICS__. The failure to define this macro or to provide stdatomic.h make GCC non-compliant with C11, in which case __STDC_VERSION__ is defined improperly.
[Bug fortran/58009] Elements with same value in vector subscript in variable definition context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58009 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Thomas Koenig --- Author: tkoenig Date: Sun Jul 28 21:10:23 2013 New Revision: 201294 URL: http://gcc.gnu.org/viewcvs?rev=201294&root=gcc&view=rev Log: 2013-07-28 Thomas Koenig PR fortran/58009 * expr.c (gfc_check_vardef_context): Check for same values in vector expression subscripts. 2013-07-28 Thomas Koenig PR fortran/58009 * gfortran.dg/vector_subsript_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/vector_subscript_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/58018] New: ICE in tree_ssa_unswitch_loops at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58018
Bug ID: 58018
Summary: ICE in tree_ssa_unswitch_loops at -O3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux in both 32-bit and 64-bit modes. This is a regression from
4.8.x.
$ gcc-trunk -v
gcc version 4.9.0 20130728 (experimental) [trunk revision 201291] (GCC)
$ gcc-trunk -O2 -c small.c
$ gcc-4.8 -O3 -c small.c
$ gcc-trunk -O3 -c small.c
small.c: In function ‘foo’:
small.c:9:6: internal compiler error: Segmentation fault
void foo ()
^
0x7d4c4f crash_signal
../../gcc-trunk/gcc/toplev.c:334
0x7fccdb ssa_default_def(function*, tree_node*)
../../gcc-trunk/gcc/tree-dfa.c:314
0x7fcfa0 get_or_create_ssa_default_def(function*, tree_node*)
../../gcc-trunk/gcc/tree-dfa.c:362
0x81623a get_reaching_def
../../gcc-trunk/gcc/tree-into-ssa.c:1184
0x81c39a maybe_replace_use
../../gcc-trunk/gcc/tree-into-ssa.c:1784
0x81c39a rewrite_update_stmt
../../gcc-trunk/gcc/tree-into-ssa.c:1967
0x81c39a rewrite_update_enter_block
../../gcc-trunk/gcc/tree-into-ssa.c:2136
0xb3670a walk_dominator_tree(dom_walk_data*, basic_block_def*)
../../gcc-trunk/gcc/domwalk.c:210
0x814f43 rewrite_blocks
../../gcc-trunk/gcc/tree-into-ssa.c:2216
0x81b64e update_ssa(unsigned int)
../../gcc-trunk/gcc/tree-into-ssa.c:3303
0xb9da0a tree_unswitch_single_loop
../../gcc-trunk/gcc/tree-ssa-loop-unswitch.c:358
0xb9dff8 tree_ssa_unswitch_loops()
../../gcc-trunk/gcc/tree-ssa-loop-unswitch.c:116
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
-
int a, b, c, d, e;
void bar (int p)
{
int f = b;
e &= p <= (f ^= 0);
}
void foo ()
{
for (; d; d++)
{
bar (a && c);
bar (0);
bar (1);
}
}
