[Bug c/60090] New: For expression without ~, gcc -O1 emits comparison of promoted ~unsigned with unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60090
Bug ID: 60090
Summary: For expression without ~, gcc -O1 emits comparison of
promoted ~unsigned with unsigned
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
For the expression (l ^ a) != b, gcc -O0 emits no warning, but gcc -O1 emits
a warning comparison of promoted ~unsigned with unsigned. After checking the
gimple code, I found the optimization transforms the expression to a bitwise
not expression.
However, in a syntactic perspective, the warning message is confusing, given
the fact that there is no '~' in this expression.
$: cat s.c
int fn1(unsigned char a, unsigned char b) {
const unsigned l = 4294967295u;
return (l ^ a) != b;
}
$: gcc-trunk -c -Wsign-compare s.c
$: gcc-trunk -c -Wsign-compare s.c -O1
s.c: In function ‘fn1’:
s.c:3:18: warning: comparison of promoted ~unsigned with unsigned
[-Wsign-compare]
return (l ^ a) != b;
^
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 --- Comment #45 from Jan Hubicka hubicka at gcc dot gnu.org --- The bug here is that lto-cgraph.c still checks DECL_COMDAT as a condition if symbol is duplicated or partitioned. We really need to get the logic into lto-cgraph.c and use same test at both places... Will do that tomorrow.
[Bug fortran/60091] New: Misleading error messages in rank-2 pointer assignment to rank-1 target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60091 Bug ID: 60091 Summary: Misleading error messages in rank-2 pointer assignment to rank-1 target Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: loximann at gmail dot com Compiler version: 4.9.0 20130917 (experimental) [trunk revision 202647] Test program: program test real, target :: a(9)=1. real, pointer :: p(:,:) p(:,:)=a ! (a) Error: Lower bound has to be present at (1) p(1:,1:)=a! (b) Error: Different ranks in pointer assignment at (1) p(1:3,1:)=a ! (c) Error: Either all or none of the upper bounds must be specified at (1) p(1:3,1:3)=a end program According to Note 7.48, It is possible to obtain different-rank views of parts of an object by specifying upper bounds in pointer assignment statements. In my opinion, the error in all (a), (b) and (c) should be in the lines of Different ranks in pointer assignment at (1). All lower and upper bounds must be specified.
[Bug c/60090] For expression without ~, gcc -O1 emits comparison of promoted ~unsigned with unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60090 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-06 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- This (and a bunch of other related PRs) is about early folding in the FE. c_fully_fold when optimize calls fold_build2 - fold_binary_loc that transforms the expression and then we issue those seemingly unrelated warnings. I'd say that while we want the exprs to be folded, we should issue diagnostics for the unfolded exprs. (I think it's been discussed numerous times in the past.) Nothing for stage4, but we/I should address this in gcc 5.0.
[Bug rtl-optimization/60086] suboptimal asm generated for a loop (store/load false aliasing)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60086
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-02-06
CC||abel at gcc dot gnu.org,
||jakub at gcc dot gnu.org,
||uros at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
GCC right now only handles __restrict on function parameters, so in this case
the aliasing info isn't known. While the loop is versioned for aliasing at
runtime, the info about that is only known during the vectorizer, therefore
e.g. scheduler can hardly know it. The pointers to overaligned memory is
something you should generally avoid, __builtin_assume_aligned is what can be
used to tell the compiler about the alignment instead, overaligned types often
actually hurt generated code instead of improving it. And the way you are
calling posix_memalign is IMHO a strict aliasing violation.
Perhaps GCC could handle posix_memalign specially as builtin if declared with
the right prototype (and optionally some new attribute) and derive both the
aliasing and alignment info from it, like the taking of the address of the
pointer in it isn't really an escape site of any kind, all the call does is
return two values instead of just one, so it could be folded into passing an
address of some temporary to the call instead and then loading from the
temporary and using some special pass-thru builtin that would tell GCC that the
pointer is really malloc-like (non-aliasing anything else) and also
use__builtin_assume_aligned. The GNU memalign is far better than
posix_memalign from this POV.
Anyway, if I rewrite your testcase as:
#include stdlib.h
#include stdio.h
__attribute__((noinline)) void
foo (double *__restrict__ a, double *__restrict__ b, double *__restrict__ c,
double *__restrict__ d, unsigned long NSIZE)
{
unsigned long i, j;
a = __builtin_assume_aligned (a, 32);
b = __builtin_assume_aligned (b, 32);
c = __builtin_assume_aligned (c, 32);
d = __builtin_assume_aligned (d, 32);
// initialize memory
for(i=0; iNSIZE; i++){
a[i] = 0;
b[i] = 0;
c[i] = 0;
d[i] = 0;
}
// outer loop - repeat short tests
for(j=0; j1; j++){
// inner loop - do the work
for(i=0; iNSIZE; i++){
a[i] += b[i];
c[i] += d[i];
}
// dummy - prevent loop interchange
if(a[NSIZE/2]0) printf(%lf\n, a[NSIZE/2]);
}
}
int main(int argc, char*argv[])
{
unsigned long NSIZE = atol(argv[1]);
void *a, *b, *c, *d;
// allocate starting from page boundary
posix_memalign(a, 4096, sizeof(double)*(NSIZE));
posix_memalign(b, 4096, sizeof(double)*(NSIZE));
posix_memalign(c, 4096, sizeof(double)*(NSIZE));
posix_memalign(d, 4096, sizeof(double)*(NSIZE));
foo ((double *) a, (double *) b, (double *) c, (double *) d, NSIZE);
return 0;
}
we don't do versioning for alias and also (as before) assume sufficient
alignment, but still the scheduler doesn't reorder the loads vs. the store,
unless -O3 -mavx -fschedule-insns. The reason why the second scheduler doesn't
reorder those is that RA allocates the same register. With -O3 -mavx
-fselective-scheduling2 the stores are also changed, but we end up with a
weird:
.L9:
movq-136(%rbp), %rdx
vmovapd (%r9,%rax), %ymm0
addq$1, %rdi
vmovapd (%r10,%rax), %ymm8
vaddpd (%rdx,%rax), %ymm0, %ymm0
movq-144(%rbp), %rdx
vaddpd (%rdx,%rax), %ymm8, %ymm9
vmovapd %ymm0, (%r9,%rax)
vmovapd %ymm8, %ymm0
vmovapd %ymm9, %ymm0
vmovapd %ymm0, (%r10,%rax)
addq$32, %rax
cmpq%rdi, -152(%rbp)
ja .L9
Why there is the vmovapd %ymm8, %ymm0 is a mystery, and vmovapd %ymm9, %ymm0
could be very well merged with the store into vmovapd %ymm9, (%r10,%rax).
[Bug c/60090] For expression without ~, gcc -O1 emits comparison of promoted ~unsigned with unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60090 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- C++ folds while parsing and here for both -O0 -O we get y.c: In function ‘int fn1(unsigned char, unsigned char)’: y.c:3:18: warning: comparison of promoted ~unsigned with unsigned [-Wsign-compare] return (l ^ a) != b; ^
[Bug c/60090] For expression without ~, gcc -O1 emits comparison of promoted ~unsigned with unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60090 --- Comment #3 from Chengnian Sun chengniansun at gmail dot com --- Thanks, Marek. May I ask another question on the Gcc optimizations and warnings? Is there a policy that the warnings should be independent of the optimization levels? That is, for all optimization levels, Gcc should always emit consistent warnings. I know that Clang has such a policy. But based on what I have observed on Gcc, it seems that Gcc does not have this policy.
[Bug middle-end/60013] [4.9 Regression] Build of 176.gcc from CPU2000 loops in cc1 starting with r207231
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60013 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 --- Comment #14 from Siddhesh Poyarekar siddhesh at redhat dot com --- I spoke to Jason last week and have now confirmed that the first fragment indeed works correctly with 4.8. Declaring a variable threadprivate *after* it is defined is not yet supported, but it should not be very difficult to work around that limitation. I also have confirmation that the glibc support in place for threadprivate/thread_local is sufficient and complete, so I'm closing out the glibc TODO item.
[Bug target/60077] [4.9 regression] gcc.target/i386/pr35767-5.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60077 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r206947.
[Bug ada/60078] acats c761007 fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078 --- Comment #6 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Eric, could it be that the Finalize procedure is missing some sort of spin lock? ed@w-ed:~/gnu/gcc-build/gcc/testsuite/ada/acats/tests/c7/c761007$ cat c761007_0.adb -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- with TCTouch; package body C761007_0 is procedure Finalize( I : in out Internal ) is Previous_Side_Effect : Boolean := False; begin -- look to see if this character has been finalized yet for SEI in 1..Side_Effect_Finger loop Previous_Side_Effect := Previous_Side_Effect or Side_Effect(Side_Effect_Finger) = I.Effect; end loop; delay 0.01; -- = additional delay here -- if not, then tack it on to the string, and touch the character if not Previous_Side_Effect then Side_Effect_Finger := Side_Effect_Finger +1; Side_Effect(Side_Effect_Finger) := I.Effect; TCTouch.Touch(I.Effect); end if; end Finalize; end C761007_0; ed@w-ed:~/gnu/gcc-build/gcc/testsuite/ada/acats/tests/c7/c761007$ ./c761007 ,.,. C761007 ACATS 2.5 14-02-06 10:05:45 C761007 Check that if a finalize procedure invoked by a transfer of control or selection of a terminate alternative attempts to propagate an exception, the exception is ignored, but any other finalizations due to be performed are performed. * C761007 Asynchronously aborted operation Expecting: GHIJ Got: GHHIJ. C761007 FAILED .
[Bug rtl-optimization/60086] suboptimal asm generated for a loop (store/load false aliasing)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60086 --- Comment #2 from Marcin Krotkiewski marcin.krotkiewski at gmail dot com --- Jakub, thank you for your comments. GCC right now only handles __restrict on function parameters, so in this case the aliasing info isn't known. While the loop is versioned for aliasing at runtime, the info about that is only known during the vectorizer, therefore e.g. scheduler can hardly know it. Does it mean that __restrict is not necessary in order to have a vectorized code path? I see that if I compile your modified test.c, the loop is vectorized regardless of whether I use __restrict, or not (runtime versioning). On the other hand, using __restrict causes gcc to invoke memset for initialization, while leaving it out results in two paths with a loop. On the interesting side. Your test.c works indeed if compiled with additional -fschedule-insns flag. However, if I now remove the __restrict keyword from function arguments, I do see a vectorized path, but the flag has no effect and instructions are again not reordered. The pointers to overaligned memory is something you should generally avoid, __builtin_assume_aligned is what can be used to tell the compiler about the alignment instead, overaligned types often actually hurt generated code instead of improving it. Thanks. Could you suggest what is the preferred way to use it in a portable manner? e.g. make it suitable for icc, which has a __assume_aligned builtin? Should I wrap it in a macro? And the way you are calling posix_memalign is IMHO a strict aliasing violation. Could be, gcc des not show a warning with -Wall. Thanks for pointing it out.
[Bug c/60090] For expression without ~, gcc -O1 emits comparison of promoted ~unsigned with unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60090 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- I believe we strive for the warnings be independent of the optimization level, but it's not always possible, we have tons of bugs where -Wuninitialized depends on the optimization level, sometimes -Warray-bounds warns only on -O3, some warnings depend on VRP or SRA, on -O some uses are constant-propagated etc. In the middle-end we often warn only about variables in SSA form which are made, as a part of some optimization, non-addressable.
[Bug rtl-optimization/60086] suboptimal asm generated for a loop (store/load false aliasing)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60086 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Marcin Krotkiewski from comment #2) Thanks. Could you suggest what is the preferred way to use it in a portable manner? e.g. make it suitable for icc, which has a __assume_aligned builtin? Should I wrap it in a macro? I think you could wrap it in a macro that is defined based on: #ifdef __INTEL__ # define ... #elif defined __GNUC__ # define ... #endif
[Bug middle-end/60089] Complex arithmetic instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60089 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-06 Component|rtl-optimization|middle-end Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- You'd need to disable complex lowering at the GIMPLE level and see what support is missing from RTL expansion for example. For the disabling I'd suggest adding a target hook (if it at any point is supposed to go upstream).
[Bug rtl-optimization/60086] suboptimal asm generated for a loop (store/load false aliasing)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60086 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- As of posix_memalign the issue is not so much that of alias analysis (we could handle it but we don't have a builtin right now) but that of alignment analysis which doesn't implement alignment tracking of pointers stored in memory. We could lower posix_memalign (ptr, align, size); to posix_memalign (ptr, align, size); ptr = __builtin_assume_algined (ptr, align); and hope for FRE to fix things up enough to make that useful. I have opened PR60092.
[Bug middle-end/60092] New: posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092 Bug ID: 60092 Summary: posix_memalign not recognized to derive alias and alignment info Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: alias, missed-optimization Severity: enhancement Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-02-06 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- As of posix_memalign the issue is not so much that of alias analysis (we could handle it but we don't have a builtin right now) but that of alignment analysis which doesn't implement alignment tracking of pointers stored in memory. We could lower posix_memalign (ptr, align, size); to posix_memalign (ptr, align, size); ptr = __builtin_assume_algined (ptr, align); and hope for FRE to fix things up enough to make that useful.
[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #12 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Paulo J. Matos from comment #10)
(In reply to Paulo J. Matos from comment #8)
Made a mistake. With the attached test, the final gimple before expand for
the loop basic block is:
;; basic block 5, loop depth 0
;;pred: 5
;;4
# i_26 = PHI i_1(5), 0(4)
# ivtmp.24_18 = PHI ivtmp.24_12(5), ivtmp.24_29(4)
_28 = (void *) ivtmp.24_18;
_13 = MEM[base: _28, offset: 0B];
x.4_14 = x;
_15 = _13 ^ x.4_14;
MEM[base: _28, offset: 0B] = _15;
ivtmp.24_12 = ivtmp.24_18 + 4;
temp_ptr.5_17 = (Sample *) ivtmp.24_12;
_11 = (unsigned short) i_26;
_2 = _11 + 1;
i_1 = (short int) _2;
_10 = (int) i_1;
if (_10 _25)
goto bb 5;
else
goto bb 6;
;;succ: 5
;;6
However, the point is the same. IVOPTS should probably generate an int IV
instead of a short int IV to avoid the sign extend since removing the sign
extend during RTL seems to be quite hard.
What do you think?
For = 4.8 the scalar evolution of _10 is deemed not simple, because it
looks like the following:
nop_expr 0x2acd9ee0
type integer_type 0x2ab16690 int public SI
size integer_cst 0x2ab12c60 constant 32
unit size integer_cst 0x2ab12c80 constant 4
align 32 symtab 0 alias set 3 canonical type 0x2ab16690
precision 32 min integer_cst 0x2ab12f80 -2147483648 max integer_cst
0x2ab12fa0 2147483647 context translation_unit_decl 0x2ab29c00
D.2881
pointer_to_this pointer_type 0x2ab23348
arg 0 polynomial_chrec 0x2acdb090
type integer_type 0x2ab16540 short int sizes-gimplified public
HI
size integer_cst 0x2ab12f20 constant 16
unit size integer_cst 0x2ab12f40 constant 2
align 16 symtab 0 alias set 4 canonical type 0x2ab16540
precision 16 min integer_cst 0x2ab12ec0 -32768 max integer_cst
0x2ab12ee0 32767
pointer_to_this pointer_type 0x2aca1f18
arg 0 integer_cst 0x2ab1f260 constant 1
arg 1 integer_cst 0x2acc9140 constant 1 arg 2 integer_cst
0x2acc9140 1
This is something like: (int) (short int) {1, +, 1}_1. Since these are
signed integers, we can assume they don't overflow, can't we simplify the
scalar evolution to a polynomial_chrec over 32bit integers and forget the
nop_expr that represents the sign extend?
Note that {1, +, 1}_1 is unsigned. The issue is that while i is short
i++ is really i = (short)((int) i + 1) and thus only the operation in
type 'int' is known to not overflow and thus the IV in short _can_
overflow and the loop can loop infinitely for example for loopCount
== SHORT_MAX + 1.
The fix to SCEV analysis was to still be able to analyze the evolution at all.
The testcase is simply very badly written (unsigned short upper bound,
signed short IV and IV comparison against upper bound in signed int).
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
Well, the problem with doing it this way is that ptr is still considered
address taken and the assume aligned then really can result in a noop move.
What I meant is expand:
ret = posix_memalign (ptr, align, size);
as
{
void *temp;
ret = posix_memalign (temp, align, size);
void *temp2 = __builtin_passthru_attribute_malloc_size (temp, size);
ptr = __typeof (ptr) __builtin_assume_aligned (temp2, align);
temp ={v}{CLOBBER};
}
The advantages of doing it this way would be that (if ptr is not address taken
for other reasons) that it would not need to be address taken, escape and all
the like, I think posix_memalign is not reading the old content of the pointer
nor storing it anywhere, it just fills it in as another result, just by
reference.
And the optimizers would know it doesn't alias anything, like if it came from
malloc (size);, and is aligned to align bytes at least.
The disadvantage would be that if ptr is addressable for other reasons, we
wouldn't reuse it's address for posix_memalign, but pass address of another
temporary and then copied the mem.
[Bug middle-end/60093] New: ICE on testsuite/c-c++-common/ubsan/overflow-*.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60093 Bug ID: 60093 Summary: ICE on testsuite/c-c++-common/ubsan/overflow-*.c Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de spawn /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc -B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/c-c++-common/ubsan/overflow-2.c -B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/armv7l-unknown-linux-gnueabihf/./libsanitizer/ -B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/armv7l-unknown-linux-gnueabihf/./libsanitizer/ubsan/ -L/home/ed/gnu/gcc-build-arm-linux-gnueabihf/armv7l-unknown-linux-gnueabihf/./libsanitizer/ubsan/.libs -fno-diagnostics-show-caret -fdiagnostics-color=never -Os -fsanitize=signed-integer-overflow -lm -o ./overflow-2.exe^M In file included from /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/c-c++-common/ubsan/overflow-2.c:8:0:^M /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/c-c++-common/ubsan/overflow-1.c: In function 'main':^M /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/c-c++-common/ubsan/overflow-1.c:81:40: internal compiler error: in simplify_subreg, at simplify-rtx.c:5903^M /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/c-c++-common/ubsan/overflow-1.c:12:29: note: in definition of macro 'CHECK'^M /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/c-c++-common/ubsan/overflow-1.c:81:10: note: in expansion of macro 'FN1'^M 0x57f3e3 simplify_subreg(machine_mode, rtx_def*, machine_mode, unsigned int)^M ../../gcc-4.9-20140202/gcc/simplify-rtx.c:5902^M 0x57f793 simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, unsigned int)^M ../../gcc-4.9-20140202/gcc/simplify-rtx.c:6123^M 0x2ded5b operand_subword_force(rtx_def*, unsigned int, machine_mode)^M ../../gcc-4.9-20140202/gcc/emit-rtl.c:1455^M 0x4da013 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*, int, optab_methods)^M ../../gcc-4.9-20140202/gcc/optabs.c:1813^M 0x2efc2b expand_shift_1^M ../../gcc-4.9-20140202/gcc/expmed.c:2287^M 0x402b2f ubsan_expand_si_overflow_mul_check(gimple_statement_base*)^M ../../gcc-4.9-20140202/gcc/internal-fn.c:649^M 0x228667 expand_call_stmt^M ../../gcc-4.9-20140202/gcc/cfgexpand.c:2188^M 0x228667 expand_gimple_stmt_1^M ../../gcc-4.9-20140202/gcc/cfgexpand.c:3157^M 0x228667 expand_gimple_stmt^M ../../gcc-4.9-20140202/gcc/cfgexpand.c:3309^M 0x22998b expand_gimple_basic_block^M ../../gcc-4.9-20140202/gcc/cfgexpand.c:5149^M 0x22b88b gimple_expand_cfg^M ../../gcc-4.9-20140202/gcc/cfgexpand.c:5715^M 0x22b88b execute^M ../../gcc-4.9-20140202/gcc/cfgexpand.c:5935^M Please submit a full bug report,^M with preprocessed source if appropriate.^M Please include the complete backtrace with any bug report.^M See http://gcc.gnu.org/bugs.html for instructions.^M same for FAIL: c-c++-common/ubsan/overflow-mul-3.c -Os (internal compiler error) FAIL: c-c++-common/ubsan/overflow-mul-4.c -Os (internal compiler error)
[Bug middle-end/60089] Complex arithmetic instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60089
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
CC||ubizjak at gmail dot com
--- Comment #2 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Richard Biener from comment #1)
For the disabling I'd suggest adding a target hook (if it at any point is
supposed to go upstream).
This target hook would be handy also for x86_64, which passes packed complex
SFmode values to and from function:
Following test:
_Complex float testf (_Complex float a, _Complex float b)
{
return a + b;
}
produces (-O2):
testf:
movq%xmm0, -8(%rsp)
movq%xmm1, -16(%rsp)
movss -4(%rsp), %xmm0
movss -8(%rsp), %xmm1
addss -12(%rsp), %xmm0
addss -16(%rsp), %xmm1
movss %xmm0, -20(%rsp)
movss %xmm1, -24(%rsp)
movq-24(%rsp), %xmm0
ret
Yes, indeed.
[Bug middle-end/60093] ICE on testsuite/c-c++-common/ubsan/overflow-*.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60093 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added Target||armv7l-unknown-linux-gnueab ||ihf --- Comment #1 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Target: armv7l-unknown-linux-gnueabihf Configured with: ../gcc-4.9-20140202/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf --enable-languages=c,c++,objc,obj-c++,fortran,ada,go --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
[Bug middle-end/59150] [4.9 Regression] ICE: in expand_one_var, at cfgexpand.c:1242 with -fopenmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59150 --- Comment #7 from Sebastian Huber sebastian.hu...@embedded-brains.de --- Your patch fixed the problem on arm-rtems: http://gcc.gnu.org/ml/gcc-testresults/2014-02/msg00303.html
[Bug target/60077] [4.9 regression] gcc.target/i386/pr35767-5.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60077 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32063 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32063action=edit gcc49-pr60077.patch Untested fix.
[Bug target/60094] New: gcc.target/arm/ftest-armv7em-thumb.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60094 Bug ID: 60094 Summary: gcc.target/arm/ftest-armv7em-thumb.c fails Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de spawn /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc -B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-armv7em-thumb.c -fno-diagnostics-show-caret -fdiagnostics-color=never -mthumb -march=armv7e-m -mthumb -S -o ftest-armv7em-thumb.s^M In file included from /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-armv7em-thumb.c:37:0:^M /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-support.h:108:4: error: #error __ARM_FEATURE_DSP is not defined but should be^M /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-support.h:122:4: error: #error __ARM_FEATURE_SIMD32 is not defined but should be^M compiler exited with status 1 almost the same: FAIL: gcc.target/arm/ftest-armv7m-thumb.c (test for excess errors) spawn /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc -B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-armv7m-thumb.c -fno-diagnostics-show-caret -fdiagnostics-color=never -mthumb -march=armv7-m -mthumb -S -o ftest-armv7m-thumb.s^M In file included from /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-armv7m-thumb.c:31:0:^M /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-support.h:28:4: error: #error __ARM_ARCH_ISA_ARM is defined but should not be^M /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-support.h:49:5: error: #error __ARM_ARCH_PROFILE has unexpected value^M /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-support.h:77:5: error: #error __ARM_FEATURE_LDREX has unexpected value^M /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-support.h:112:4: error: #error __ARM_FEATURE_DSP is defined but should not be^M /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-support.h:126:4: error: #error __ARM_FEATURE_SIMD32 is defined but should not be^M compiler exited with status 1 root@socfpga_cyclone5:/home/ed/gnu/arm-linux-gnueabihf/bin# ./gcc -v Using built-in specs. COLLECT_GCC=./gcc COLLECT_LTO_WRAPPER=/home/ed/gnu/arm-linux-gnueabihf/libexec/gcc/armv7l-unknown-linux-gnueabihf/4.9.0/lto-wrapper Target: armv7l-unknown-linux-gnueabihf Configured with: ../gcc-4.9-20140202/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf --enable-languages=c,c++,objc,obj-c++,fortran,ada,go --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard Thread model: posix gcc version 4.9.0 20140202 (experimental) (GCC)
[Bug target/60094] gcc.target/arm/ftest-armv7em-thumb.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60094 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added Target||armv7l-unknown-linux-gnueab ||ihf --- Comment #1 from Bernd Edlinger bernd.edlinger at hotmail dot de --- this one's probably also related: spawn /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc -B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-armv7r-arm.c -fno-diagnostics-show-caret -fdiagnostics-color=never -marm -march=armv7-r -S -o ftest-armv7r-arm.s^M In file included from /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-armv7r-arm.c:40:0:^M /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-support.h:49:5: error: #error __ARM_ARCH_PROFILE has unexpected value^M compiler exited with status 1 spawn /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc -B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-armv7ve-arm.c -fno-diagnostics-show-caret -fdiagnostics-color=never -marm -march=armv7ve -S -o ftest-armv7ve-arm.s^M xgcc: error: unrecognized argument in option '-march=armv7ve'^M xgcc: note: valid arguments to '-march=' are: armv2 armv2a armv3 armv3m armv4 armv4t armv5 armv5e armv5t armv5te armv6 armv6-m armv6j armv6k armv6s-m armv6t2 armv6z armv6zk armv7 armv7-a armv7-m armv7-r armv7e-m armv8-a armv8-a+crc iwmmxt iwmmxt2 native^M compiler exited with status 1 spawn /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc -B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-armv8a-arm.c -fno-diagnostics-show-caret -fdiagnostics-color=never -marm -march=armv8-a -S -o ftest-armv8a-arm.s^M /home/ed/gnu/gcc-4.9-20140202/gcc/testsuite/gcc.target/arm/ftest-armv8a-arm.c:1:0: error: target CPU does not support ARM mode^M compiler exited with status 1
[Bug target/60062] [4.7/4.9 Regression] wrong code (for code with the optimize attribute) at -O1 and above on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60062 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Feb 6 10:54:20 2014 New Revision: 207549 URL: http://gcc.gnu.org/viewcvs?rev=207549root=gccview=rev Log: PR target/60062 * tree.h (opts_for_fn): New inline function. (opt_for_fn): Define. * config/i386/i386.c (ix86_function_regparm): Use opt_for_fn (decl, optimize) instead of optimize. * gcc.c-torture/execute/pr60062.c: New test. * gcc.c-torture/execute/pr60072.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr60062.c trunk/gcc/testsuite/gcc.c-torture/execute/pr60072.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.h
[Bug middle-end/59150] [4.9 Regression] ICE: in expand_one_var, at cfgexpand.c:1242 with -fopenmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59150 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Feb 6 10:59:30 2014 New Revision: 207551 URL: http://gcc.gnu.org/viewcvs?rev=207551root=gccview=rev Log: PR middle-end/59150 * tree-vect-data-refs.c (vect_analyze_data_refs): For clobbers, call free_data_ref on the dr first, and before goto again also set dr to the next dr. For simd_lane_access, free old datarefs[i] before overwriting it. For get_vectype_for_scalar_type failure, don't free_data_ref if simd_lane_access. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug middle-end/60089] Complex arithmetic instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60089 --- Comment #3 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) You'd need to disable complex lowering at the GIMPLE level and see what support is missing from RTL expansion for example. For the disabling I'd suggest adding a target hook (if it at any point is supposed to go upstream). Couldn't the complex lowering pass check optab, like vector lowering does?
[Bug target/60088] Segfault when using quad precision and -march=native on gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-02-06 Ever confirmed|0 |1 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr --- The test works for me on x86_64-apple-darwin13 on trunk configured with ../work/configure --prefix=/opt/gcc/gcc4.9w --enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto --with-gmp=/opt/mp --with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin --with-arch=corei7 --with-cpu=corei7 for the different tests I have done: separate files/one file, -m64 (default) or -m32, -O3/-Ofast, -static. It works also with gfortran 4.7.4 and 4.8.2/3. Note that I had to user the clang assembler since the as provided by apple is too old, but it should not matter. I have similar results on x86_64-apple-darwin10 (core2) with less accepted options. valgrind reports no error with '-std=f95 -Wall -Wextra -Ofast -march=native -ggdb', but is not happy if I add -m32, though the executable still works outside valgrind. One comment about you configure: you should NEVER use --disable-werror: if your are unable to bootstrap without it, it means you are likely to have problems later. What happens if you configure without graphite, i.e., no cloog stuff?
[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #13 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to Richard Biener from comment #12)
Note that {1, +, 1}_1 is unsigned. The issue is that while i is short
i++ is really i = (short)((int) i + 1) and thus only the operation in
type 'int' is known to not overflow and thus the IV in short _can_
overflow and the loop can loop infinitely for example for loopCount
== SHORT_MAX + 1.
The fix to SCEV analysis was to still be able to analyze the evolution at
all.
The testcase is simply very badly written (unsigned short upper bound,
signed short IV and IV comparison against upper bound in signed int).
I thought any signed operation cannot overflow, independently on its width,
therefore (short) (int + 1) shouldn't overflow.
I agree with you on the testcase, however, that's taken from customer code and
it's even if badly written, it's acceptable C. GCC 4.5.4 generates the scalar
evolution for the integer variable: {1, +, 1}_1 without the casts (therefore a
simple_iv). This allows GCC to use an int for an IV which helps discard the
sign extend in the loop body and later on allows the zero overhead loop being
generated. This case happens again and again and causes serious performance
regression on customer code.
[Bug target/60094] gcc.target/arm/ftest-armv7em-thumb.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60094 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- Bernd, which revision is this? I thought this would have been fixed with r207418
[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #14 from Paulo J. Matos pa...@matos-sorge.com ---
Something like this which looks much simpler hits the same problem:
extern int arr[];
void
foo32 (int limit)
{
short i;
for (i = 0; (int)i limit; i++)
arr[i] += 1;
}
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 32064 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32064action=edit part #1, aliasing I've implemented the aliasing parts (and the builtin obviously). It's true that doing posix_memalign (ptr, ); ptr = __builtin_assume_aligned (ptr, ...); will keep ptr address-taken - but isn't it kept address-taken anyway because it's passed to posix_memalign? I think you are mixing the possible optimization we can do to posix_memalign in general with the alignment issue, no? Thus, we could transform posix_memalign (ptr, ); to void *tem; posix_memalign (tem, ); ptr = tem; independently. Doing it as part of the alignment stuff of course makes sense. But as you say, eventually we'd just use an extra stack slot for no good reason. I've long thought of teaching some more tricks to update_address_taken - basically ignore some of the address-takens and apply simple transforms on the stmts causing them if that would make the var non-address-taken (memcpy comes to my mind as well here).
[Bug ada/60078] acats c761007 fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org --- could it be that the Finalize procedure is missing some sort of spin lock? There are already explicit delays in the test, so very likely not.
[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #15 from rguenther at suse dot de rguenther at suse dot de ---
On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #14 from Paulo J. Matos pa...@matos-sorge.com ---
Something like this which looks much simpler hits the same problem:
extern int arr[];
void
foo32 (int limit)
{
short i;
for (i = 0; (int)i limit; i++)
arr[i] += 1;
}
Exactly the same problem. C integral type promotion rules make
that i = (short)((int)i + 1) again. Note that (int)i + 1
does not overflow, (short) ((int)i + 1) invokes implementation-defined
behavior which in our case is modulo-2 reduction.
Nothing guarantees that (short)i + 1 does not overflow.
[Bug target/60094] gcc.target/arm/ftest-armv7em-thumb.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60094 --- Comment #3 from Bernd Edlinger bernd.edlinger at hotmail dot de --- trunk revision 207409 Well, in this case, I'll repeat this test next week.(In reply to ktkachov from comment #2) Bernd, which revision is this? I thought this would have been fixed with r207418 trunk revision 207409 Well, in this case, I'll repeat this test next week. Thanks.
[Bug middle-end/60080] gcc.dg/vect/vect-nop-move.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60080 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #1 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Richard, how about this? --- gcc/cfgexpand.c.jj2014-01-09 21:12:36.0 +0100 +++ gcc/cfgexpand.c2014-02-06 13:01:09.280392442 +0100 @@ -2678,8 +2678,9 @@ expand_asm_operands (tree string, tree o ASM_OPERANDS_INPUT (body, i) = op; ASM_OPERANDS_INPUT_CONSTRAINT_EXP (body, i) -= gen_rtx_ASM_INPUT (TYPE_MODE (type), - ggc_strdup (constraints[i + noutputs])); += gen_rtx_ASM_INPUT_loc (TYPE_MODE (type), + ggc_strdup (constraints[i + noutputs]), + locus); if (tree_conflicts_with_clobbers_p (val, clobbered_regs)) clobber_conflict_found = 1; @@ -2701,7 +2702,7 @@ expand_asm_operands (tree string, tree o sprintf (buffer, %d, j); ASM_OPERANDS_INPUT_CONSTRAINT_EXP (body, ninputs - ninout + i) -= gen_rtx_ASM_INPUT (inout_mode[i], ggc_strdup (buffer)); += gen_rtx_ASM_INPUT_loc (inout_mode[i], ggc_strdup (buffer), locus); } /* Copy labels to the vector. */
[Bug c++/60095] New: Dubious diagnostics for attempted surrogate call function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60095
Bug ID: 60095
Summary: Dubious diagnostics for attempted surrogate call
function
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Using ‘gcc version 4.9.0 20140123 (experimental) (GCC)’ with the following
snippet:
//
struct foo {
typedef void(*ptr)(int);
operator ptr() const;
};
int main()
{
foo f;
void* p = 0;
f(p);
}
//
$ g++-trunk -std=c++03 main.cpp
main.cpp: In function 'int main()':
main.cpp:10:8: error: no match for call to '(foo) (void*)'
f(p);
^
main.cpp:1:8: note: candidate is:
struct foo {
^
main.cpp:10:8: note: foo::ptr {aka void (*)(int)} conversion
f(p);
^
main.cpp:10:8: note: candidate expects 2 arguments, 2 provided
Same output for all -std=c++{03,11,1y} modes. If e.g. foo has a call operator
instead, then the appropriate ‘no known conversion for argument 1 from 'void*'
to 'int'’ is produced.
[Bug ada/60078] acats c761007 fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078 --- Comment #8 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Eric Botcazou from comment #7) could it be that the Finalize procedure is missing some sort of spin lock? There are already explicit delays in the test, so very likely not. I added the line delay 0.01; -- = additional delay here and the result was the test fails on X86_64. If I rewrite both Finalize methods to use protected data like this the test starts to pass again with the delays. $ cat c761007_0.ads with Ada.Finalization; package C761007_0 is type Internal is new Ada.Finalization.Controlled with record Effect : Character; end record; procedure Finalize( I: in out Internal ); protected Data is procedure Add( Effect : Character ); private Side_Effect : String(1..80); -- way bigger than needed Side_Effect_Finger : Natural := 0; end Data; end C761007_0; $ cat c761007_0.adb: with TCTouch; package body C761007_0 is procedure Finalize( I : in out Internal ) is begin Data.Add(I.Effect); end Finalize; protected body Data is procedure Add( Effect : Character ) is Previous_Side_Effect : Boolean := False; begin -- look to see if this character has been finalized yet for SEI in 1..Side_Effect_Finger loop Previous_Side_Effect := Previous_Side_Effect or Side_Effect(Side_Effect_Finger) = Effect; end loop; delay 0.01; -- = additional delay here -- if not, then tack it on to the string, and touch the character if not Previous_Side_Effect then Side_Effect_Finger := Side_Effect_Finger +1; Side_Effect(Side_Effect_Finger) := Effect; TCTouch.Touch(Effect); end if; end Add; end Data; end C761007_0;
[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #16 from Paulo J. Matos pa...@matos-sorge.com --- (In reply to rguent...@suse.de from comment #15) Exactly the same problem. C integral type promotion rules make that i = (short)((int)i + 1) again. Note that (int)i + 1 does not overflow, (short) ((int)i + 1) invokes implementation-defined behavior which in our case is modulo-2 reduction. Nothing guarantees that (short)i + 1 does not overflow. OK, that makes sense. But in GCC 4.8 that doesn't seem to be what happens. It seems to be i = (short) ((unsigned short) i + 1) Later i is cast to int for comparison. Before ivopts this is the end of the loop body: i.7_19 = (unsigned short) i_26; _20 = i.7_19 + 1; i_21 = (short intD.8) _20; _10 = (intD.1) i_21; if (_10 _25) goto bb 7; else goto bb 6; i is initially a short, then moved to unsigned short. The addition is performed and returned to short. Then cast to int for the comparison. For GCC 4.5.4 the end of loop body is: iD.2767_18 = iD.2767_26 + 1; D.5046_9 = (intD.0) iD.2767_18; if (D.5046_9 D.5047_25) goto bb 5; else goto bb 6; Here the addition is made in short int and then there's only one cast to int.
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092 --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org --- Hack: when the return value of posix_memalign is ignored, if the platform supports it, replace with a call to aligned_alloc (C11), which has an easier interface.
[Bug c/60090] For expression without ~, gcc -O1 emits comparison of promoted ~unsigned with unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60090 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Marek Polacek from comment #1) This (and a bunch of other related PRs) is about early folding in the FE. c_fully_fold when optimize calls fold_build2 - fold_binary_loc that transforms the expression and then we issue those seemingly unrelated warnings. I'd say that while we want the exprs to be folded, we should issue diagnostics for the unfolded exprs. (I think it's been discussed numerous times in the past.) Nothing for stage4, but we/I should address this in gcc 5.0. I think this should be the plan: http://gcc.gnu.org/ml/gcc/2013-11/msg00253.html but someone has to implement it ;-) In those cases where folding helps to avoid false positives, it would be nice to be able to still fold on-demand or to delay the warnings until folding can happen.
[Bug ada/60078] acats c761007 fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078 --- Comment #9 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 32065 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32065action=edit possible fix well, I don't know if the Finalize method are supposed to be called in a sequential manner, which GNAT does obviously not guarantee. But how about this, for a fix?
[Bug c/59984] OpenMP and Cilk Plus SIMD pragma makes loop incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59984 --- Comment #3 from Igor Zamyatin izamyatin at gmail dot com --- Vectorizer dump snippet for main: foo.simdclone.0 (vect__12.7_3, vect_cst_.8_53, vect_cst_.8_53, vect_cst_.9_51, vect_cst_.9_51); GIMPLE_NOP vect_v1.12_37 = MEM[(int *)vectp_v1.10_39]; (1) v1.0_14 = v1; vect_v2.16_60 = MEM[(int *)vectp_v2.14_58]; (2) v2.1_15 = v2; vect__16.18_63 = vect_cst_.13_7 * vect_cst_.17_62; --- constants instead of _16 = v1.0_14 * v2.1_15; vect_v1.12_37 and MEM[(int *)vectp_a.19_65] = vect__16.18_63; vect_v2.16_60 Then DCE destroys (1) and (2) and later LIM hoists the multiplication away from the loop.
[Bug c/60090] For expression without ~, gcc -O1 emits comparison of promoted ~unsigned with unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60090 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #5) http://gcc.gnu.org/ml/gcc/2013-11/msg00253.html Exactly. I hope I can tackle at least a part of it in next stage 1. In those cases where folding helps to avoid false positives, it would be nice to be able to still fold on-demand or to delay the warnings until folding can happen. Sure.
[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #17 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to rguent...@suse.de from comment #15)
On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #14 from Paulo J. Matos pa...@matos-sorge.com ---
Something like this which looks much simpler hits the same problem:
extern int arr[];
void
foo32 (int limit)
{
short i;
for (i = 0; (int)i limit; i++)
arr[i] += 1;
}
Exactly the same problem. C integral type promotion rules make
that i = (short)((int)i + 1) again. Note that (int)i + 1
does not overflow, (short) ((int)i + 1) invokes implementation-defined
behavior which in our case is modulo-2 reduction.
Nothing guarantees that (short)i + 1 does not overflow.
I am being thick... indeed I forgot to notice that i++ also invokes undefined
behaviour. I guess then GCC sorts that out by casting i into unsigned short for
the addition and all the remaining issues then unfold.
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 32066 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32066action=edit part #2, C11 aligned_alloc It was noted that aligned_alloc is standard enough to be supported (and with nicer interface albeit possibly clobbering errno ...).
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Marc Glisse from comment #4)
Hack: when the return value of posix_memalign is ignored, if the platform
supports it, replace with a call to aligned_alloc (C11), which has an easier
interface.
The question is if posix_memalign is allowed to change errno. If it is, then
making glibc contains say something like:
extern int __REDIRECT_NTH (__posix_memalign_alias,
(void ** __ptr, size_t __alignment, size_t __size),
posix_memalign) __nonnull ((1)) __wur;
extern void *__REDIRECT_NTH (__memalign_alias,
(size_t __alignment, size_t __size),
memalign) __attribute__ ((__malloc__,
__alloc_size__ (2)));
__extern_inline int
posix_memalign (void **__ptr, size_t __alignment, size_t __size)
{
if (__builtin_constant_p (__alignment))
{
if (__alignment == 0
|| __alignment (__alignment - 1)) != 0
|| __alignment % sizeof (void *))
return EINVAL;
void *__res = __memalign_alias (__alignment, __size);
if (__res == NULL)
return ENOMEM;
*__ptr = __res;
return 0;
}
return __posix_memalign_alias (__ptr, __alignment, __size);
}
But looking at glibc sources, even posix_memalign actually changes errno.
Tbe problem with this inline version is that user aliasing bugs will trigger
people more often, and that some hack will need to be find out for the EINVAL
and ENOMEM values (because, stdlib.h is not supposed to include errno.h I
guess, so it would need to be some __EINVAL/__ENOMEM value determined by
configure or something).
[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #18 from rguenther at suse dot de rguenther at suse dot de ---
On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #17 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to rguent...@suse.de from comment #15)
On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #14 from Paulo J. Matos pa...@matos-sorge.com ---
Something like this which looks much simpler hits the same problem:
extern int arr[];
void
foo32 (int limit)
{
short i;
for (i = 0; (int)i limit; i++)
arr[i] += 1;
}
Exactly the same problem. C integral type promotion rules make
that i = (short)((int)i + 1) again. Note that (int)i + 1
does not overflow, (short) ((int)i + 1) invokes implementation-defined
behavior which in our case is modulo-2 reduction.
Nothing guarantees that (short)i + 1 does not overflow.
I am being thick... indeed I forgot to notice that i++ also invokes undefined
behaviour. I guess then GCC sorts that out by casting i into unsigned short
for
the addition and all the remaining issues then unfold.
No, i++ doesn't invoke undefined behavior - that's the whole point
and GCC got this wrong until it was fixed (4.5 is still broken).
The whole point is that limit == SHORT_MAX + 1 and the loop being
endless is _valid_ (well, apart from arr[i] then overflowing - looks
like an opportunity to derive that i can _not_ overflow ... ;))
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #7 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #6)
(In reply to Marc Glisse from comment #4)
Hack: when the return value of posix_memalign is ignored, if the platform
supports it, replace with a call to aligned_alloc (C11), which has an easier
interface.
The question is if posix_memalign is allowed to change errno. If it is,
then making glibc contains say something like:
extern int __REDIRECT_NTH (__posix_memalign_alias,
(void ** __ptr, size_t __alignment, size_t
__size),
posix_memalign) __nonnull ((1)) __wur;
extern void *__REDIRECT_NTH (__memalign_alias,
(size_t __alignment, size_t __size),
memalign) __attribute__ ((__malloc__,
__alloc_size__ (2)));
__extern_inline int
posix_memalign (void **__ptr, size_t __alignment, size_t __size)
{
if (__builtin_constant_p (__alignment))
{
if (__alignment == 0
|| __alignment (__alignment - 1)) != 0
|| __alignment % sizeof (void *))
return EINVAL;
void *__res = __memalign_alias (__alignment, __size);
if (__res == NULL)
return ENOMEM;
*__ptr = __res;
return 0;
}
return __posix_memalign_alias (__ptr, __alignment, __size);
}
But looking at glibc sources, even posix_memalign actually changes errno.
Tbe problem with this inline version is that user aliasing bugs will trigger
people more often, and that some hack will need to be find out for the
EINVAL and ENOMEM values (because, stdlib.h is not supposed to include
errno.h I guess, so it would need to be some __EINVAL/__ENOMEM value
determined by configure or something).
According to the specification this is wrong. Note that changing errno
is hindering optimization. For example
int foo (int *p)
{
*p = 1;
malloc (4);
return *p;
}
cannot CSE *p because p may point to errno. (works for float *p and
works when using posix_memalign with my patch)
[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #19 from rguenther at suse dot de rguenther at suse dot de --- On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #16 from Paulo J. Matos pa...@matos-sorge.com --- (In reply to rguent...@suse.de from comment #15) Exactly the same problem. C integral type promotion rules make that i = (short)((int)i + 1) again. Note that (int)i + 1 does not overflow, (short) ((int)i + 1) invokes implementation-defined behavior which in our case is modulo-2 reduction. Nothing guarantees that (short)i + 1 does not overflow. OK, that makes sense. But in GCC 4.8 that doesn't seem to be what happens. It seems to be i = (short) ((unsigned short) i + 1) Later i is cast to int for comparison. Before ivopts this is the end of the loop body: i.7_19 = (unsigned short) i_26; _20 = i.7_19 + 1; i_21 = (short intD.8) _20; _10 = (intD.1) i_21; if (_10 _25) goto bb 7; else goto bb 6; i is initially a short, then moved to unsigned short. The addition is performed and returned to short. Then cast to int for the comparison. For GCC 4.5.4 the end of loop body is: iD.2767_18 = iD.2767_26 + 1; D.5046_9 = (intD.0) iD.2767_18; if (D.5046_9 D.5047_25) goto bb 5; else goto bb 6; Here the addition is made in short int and then there's only one cast to int. Yes, and thus GCC 4.5 still contains the bug that i++ invokes undefined behavior when overflowing (which it does not).
Re: [Bug ada/60078] acats c761007 fails on ARM
well, I don't know if the Finalize method are supposed to be called in a sequential manner, which GNAT does obviously not guarantee. But how about this, for a fix? That can't be a fix, only a workaround hiding a potential issue. Your patch is completely changing the semantic and purpose of the test, which is basically equivalent to removing the test altogether. Furthermore, you can't put a delay statement inside a protected procedure, it's a potentially blocking operation. Arno
[Bug target/60032] [4.9 regression] ICE in reload_cse_simplify_operands, at postreload.c:411
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032 --- Comment #4 from Alan Modra amodra at gcc dot gnu.org --- Author: amodra Date: Thu Feb 6 13:25:38 2014 New Revision: 207553 URL: http://gcc.gnu.org/viewcvs?rev=207553root=gccview=rev Log: PR target/60032 gcc/ * config/rs6000/rs6000.c (rs6000_secondary_memory_needed_mode): Only change SDmode to DDmode when lra_in_progress. gcc/testsuite/ * gcc.target/powerpc/pr60032.c: New. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr60032.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog
[Bug ada/60078] acats c761007 fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078 --- Comment #10 from charlet at adacore dot com charlet at adacore dot com --- well, I don't know if the Finalize method are supposed to be called in a sequential manner, which GNAT does obviously not guarantee. But how about this, for a fix? That can't be a fix, only a workaround hiding a potential issue. Your patch is completely changing the semantic and purpose of the test, which is basically equivalent to removing the test altogether. Furthermore, you can't put a delay statement inside a protected procedure, it's a potentially blocking operation. Arno
[Bug c++/60096] New: c++11 lambda reference capture mistake
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60096
Bug ID: 60096
Summary: c++11 lambda reference capture mistake
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: feng.w...@uni-ulm.de
considering the following code:
[code]
#include iostream
int main()
{
std::cout
[]( int x )
{
return [](int y)
{
return x+y;
}(2);
}(5)
\n;
std::cout []( int x )
{
return [x](int y)
{
return x+y;
};
}(2)(5)
\n;
std::cout []( int x )
{
return [x](int y)
{
return x+y;
};
}(2)(5)
\n;
return 0;
}
[/code]
the output produced by g++4.8 and g++4.9 is
[output]
7
10
7
[/output]
while the expected output is
[output]
7
7
7
[/output]
[Bug ada/60078] acats c761007 fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078 --- Comment #11 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to char...@adacore.com from comment #10) well, I don't know if the Finalize method are supposed to be called in a sequential manner, which GNAT does obviously not guarantee. But how about this, for a fix? That can't be a fix, only a workaround hiding a potential issue. Your patch is completely changing the semantic and purpose of the test, which is basically equivalent to removing the test altogether. Furthermore, you can't put a delay statement inside a protected procedure, it's a potentially blocking operation. Arno Hmm, thanks. of course the delay was only meant to bring it to the point. And it generates a warning when it is in a protected block, I know. The point is, even with a short delay here the test should pass, right? What is the test supposed to do? could you explain, why the test fails when the delay is added to the unmodified test case?
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Richard Biener from comment #7)
According to the specification this is wrong. Note that changing errno
is hindering optimization. For example
int foo (int *p)
{
*p = 1;
malloc (4);
return *p;
}
cannot CSE *p because p may point to errno. (works for float *p and
works when using posix_memalign with my patch)
Well, e.g.
http://pubs.opengroup.org/onlinepubs/007904975/functions/posix_memalign.html
says nothing about errno, I think only functions which explicitly document not
to clobber errno may not, all other functions may, but it's value is undefined
after the call. For calls that are documented to change errno in some cases,
it is again defined only if those calls return a particular value (e.g. -1),
otherwise errno is still undefined.
Re: [Bug ada/60078] acats c761007 fails on ARM
What is the test supposed to do? Looks at the top of c761007.a, you'll find answers to this question. could you explain, why the test fails when the delay is added to the unmodified test case? Sorry, I'm not following you here, I do not know which delay you would add where (and why). Arno
[Bug ada/60078] acats c761007 fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078 --- Comment #12 from charlet at adacore dot com charlet at adacore dot com --- What is the test supposed to do? Looks at the top of c761007.a, you'll find answers to this question. could you explain, why the test fails when the delay is added to the unmodified test case? Sorry, I'm not following you here, I do not know which delay you would add where (and why). Arno
[Bug c++/60097] New: spurious warning about command line option -Wno-mismatched-tags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60097
Bug ID: 60097
Summary: spurious warning about command line option
-Wno-mismatched-tags
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dan at math dot uiuc.edu
int x;
char y;
void f () { y=x; }
/*
compile with
g++ -c -Wconversion -Wno-mismatched-tags
get this:
foo.cc: In function 'void f()':
foo.cc:3:14: warning: conversion to 'char' from 'int' may alter its value
[-Wconversion]
void f () { y=x; }
^
At global scope:
cc1plus: warning: unrecognized command line option -Wno-mismatched-tags
[enabled by default]
the warning about -Wno-mismatched-tags is false, because it is not issued when
compiling with
g++ -c -Wno-mismatched-tags
info:
happens under Mac OS X with the compiler below, and also under Ubuntu
with an older compiler
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc48/4.8.2/libexec/gcc/x86_64-apple-darwin13.0.2/4.8.2/lto-wrapper
Target: x86_64-apple-darwin13.0.2
Configured with: ../configure --build=x86_64-apple-darwin13.0.2
--prefix=/usr/local/Cellar/gcc48/4.8.2 --enable-languages=c,c++,objc,obj-c++
--program-suffix=-4.8 --with-gmp=/usr/local/opt/gmp4
--with-mpfr=/usr/local/opt/mpfr2 --with-mpc=/usr/local/opt/libmpc08
--with-cloog=/usr/local/opt/cloog018 --with-isl=/usr/local/opt/isl011
--with-system-zlib --enable-version-specific-runtime-libs
--enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release
--enable-lto --disable-werror --enable-plugin --disable-nls --disable-multilib
Thread model: posix
gcc version 4.8.2 (GCC)
*/
[Bug middle-end/60080] gcc.dg/vect/vect-nop-move.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60080 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- I just tried the patch on i386-pc-solaris2.10 and the SEGVs are gone. Thanks for the quick fix. Rainer
[Bug c/60087] Incorrect column number for -Wsign-compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60087 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Thu Feb 6 13:57:37 2014 New Revision: 207554 URL: http://gcc.gnu.org/viewcvs?rev=207554root=gccview=rev Log: PR c/60087 c-family/ * c-common.c (warn_for_sign_compare): Call warning_at with location instead of warning. testsuite/ * gcc.dg/pr60087.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr60087.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog
[Bug c/60087] Incorrect column number for -Wsign-compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60087 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug c++/60096] c++11 lambda reference capture mistake
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60096 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- This looks invalid to me, you return a closure that holds a dangling reference to a function parameter that has gone out of scope.
[Bug ada/60078] acats c761007 fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078 --- Comment #13 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to char...@adacore.com from comment #12) could you explain, why the test fails when the delay is added to the unmodified test case? Sorry, I'm not following you here, I do not know which delay you would add where (and why). Arno I am here, because this test seems to fail on a Dual-Core ARM running Linux version 3.7.0. What it looks like for me, is this is executed on two cores in parallel: -- look to see if this character has been finalized yet for SEI in 1..Side_Effect_Finger loop Previous_Side_Effect := Previous_Side_Effect or Side_Effect(Side_Effect_Finger) = I.Effect; end loop; -- if not, then tack it on to the string, and touch the character if not Previous_Side_Effect then Side_Effect_Finger := Side_Effect_Finger +1; Side_Effect(Side_Effect_Finger) := I.Effect; TCTouch.Touch(I.Effect); end if; and both try to add G to Side_Effect. Both execute the for loop, and both don't see each other, thus Previous_Side_Effect := False. Then both enter the if statement, and end up with GGHIJ = test FAILED. To make it reproducible, I added a delay 0.01 between for and if statement and this made the test fail every time, even on X86_64. If the test is OK as it is, then it is probably the responsibility of the runtime to ony execute one Finalize method at the time? So is it a bug in the Test Case or in the GNAT or on my hardware? Bernd.
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #9 from rguenther at suse dot de rguenther at suse dot de ---
On Thu, 6 Feb 2014, jakub at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Richard Biener from comment #7)
According to the specification this is wrong. Note that changing errno
is hindering optimization. For example
int foo (int *p)
{
*p = 1;
malloc (4);
return *p;
}
cannot CSE *p because p may point to errno. (works for float *p and
works when using posix_memalign with my patch)
Well, e.g.
http://pubs.opengroup.org/onlinepubs/007904975/functions/posix_memalign.html
says nothing about errno, I think only functions which explicitly document not
to clobber errno may not, all other functions may, but it's value is undefined
after the call. For calls that are documented to change errno in some cases,
it is again defined only if those calls return a particular value (e.g. -1),
otherwise errno is still undefined.
Ok, my manpage says
RETURN VALUE
aligned_alloc(), memalign(), valloc(), and pvalloc() return a
pointer
to the allocated memory, or NULL if the request fails.
posix_memalign() returns zero on success, or one of the error
values
listed in the next section on failure. Note that errno is not set.
so that must be incorrect.
If the value of errno is undefined after posix_memalign that doesn't
help us as we then still cannot CSE.
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #9) Ok, my manpage says RETURN VALUE aligned_alloc(), memalign(), valloc(), and pvalloc() return a pointer to the allocated memory, or NULL if the request fails. posix_memalign() returns zero on success, or one of the error values listed in the next section on failure. Note that errno is not set. so that must be incorrect. If the value of errno is undefined after posix_memalign that doesn't help us as we then still cannot CSE. Linux man pages are often incorrect, better look at the 3p ones ;).
[Bug c++/19377] Using declaration in private part causes protected diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377
Andrey Belevantsev abel at gcc dot gnu.org changed:
What|Removed |Added
CC||abel at gcc dot gnu.org,
||amonakov at gcc dot gnu.org
--- Comment #9 from Andrey Belevantsev abel at gcc dot gnu.org ---
Another test case of the same issue (both clang and icc compile this fine):
namespace ns {
class Base {
public:
int i;
};
class Derived : public Base {
using Base::i;
};
}
class DerivedDerived : public ns::Derived {
using ns::Base::i;
};
we get
/tmp/ns.C:4:9: error: ‘int ns::Base::i’ is inaccessible
/tmp/ns.C:10:7: error: within this context
It is indeed rejects-valid but I cannot claim this is a regression as I can't
find the version that did that correctly. It's 9 years of the original
bugreport, maybe rise a priority?..
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092 --- Comment #11 from Andreas Schwab sch...@linux-m68k.org --- If a function is not allowed to change errno this must be explicitly documented.
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092 --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Andreas Schwab from comment #11) If a function is not allowed to change errno this must be explicitly documented. That means Index: gcc/tree-ssa-alias.c === --- gcc/tree-ssa-alias.c.orig 2014-02-06 15:43:42.138266256 +0100 +++ gcc/tree-ssa-alias.c2014-02-06 15:43:33.046266882 +0100 @@ -1847,7 +1847,9 @@ call_may_clobber_ref_p_1 (gimple call, a ao_ref dref; ao_ref_init_from_ptr_and_size (dref, ptrptr, TYPE_SIZE_UNIT (ptr_type_node)); - return refs_may_alias_p_1 (dref, ref, false); + return (refs_may_alias_p_1 (dref, ref, false) + || (flag_errno_math +targetm.ref_may_alias_errno (ref))); } /* Freeing memory kills the pointed-to memory. More importantly the call has to serve as a barrier for moving loads and stores is necessary.
[Bug c++/60096] c++11 lambda reference capture mistake
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60096
--- Comment #2 from Feng Wang feng.w...@uni-ulm.de ---
(In reply to Jonathan Wakely from comment #1)
This looks invalid to me, you return a closure that holds a dangling
reference to a function parameter that has gone out of scope.
Sorry, my fault. I should have been using a const reference
[]( int const x )
{
return [x](int const y)
{
return x+y;
};
}
(2)(5);
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Richard Biener from comment #12) (In reply to Andreas Schwab from comment #11) If a function is not allowed to change errno this must be explicitly documented. That means Index: gcc/tree-ssa-alias.c === --- gcc/tree-ssa-alias.c.orig 2014-02-06 15:43:42.138266256 +0100 +++ gcc/tree-ssa-alias.c2014-02-06 15:43:33.046266882 +0100 @@ -1847,7 +1847,9 @@ call_may_clobber_ref_p_1 (gimple call, a ao_ref dref; ao_ref_init_from_ptr_and_size (dref, ptrptr, TYPE_SIZE_UNIT (ptr_type_node)); - return refs_may_alias_p_1 (dref, ref, false); + return (refs_may_alias_p_1 (dref, ref, false) + || (flag_errno_math +targetm.ref_may_alias_errno (ref))); } /* Freeing memory kills the pointed-to memory. More importantly the call has to serve as a barrier for moving loads and stores is necessary. For posix_memalign? I think errno can contain any value, except that library is not allowed to clear errno. So, IMHO *p = 1; posix_memalign (...); return *p; can be still optimized into return 1;, because if p = errno; then *p after the call has undefined value (just known not to be zero).
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092 --- Comment #14 from rguenther at suse dot de rguenther at suse dot de --- On Thu, 6 Feb 2014, jakub at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Richard Biener from comment #12) (In reply to Andreas Schwab from comment #11) If a function is not allowed to change errno this must be explicitly documented. That means Index: gcc/tree-ssa-alias.c === --- gcc/tree-ssa-alias.c.orig 2014-02-06 15:43:42.138266256 +0100 +++ gcc/tree-ssa-alias.c2014-02-06 15:43:33.046266882 +0100 @@ -1847,7 +1847,9 @@ call_may_clobber_ref_p_1 (gimple call, a ao_ref dref; ao_ref_init_from_ptr_and_size (dref, ptrptr, TYPE_SIZE_UNIT (ptr_type_node)); - return refs_may_alias_p_1 (dref, ref, false); + return (refs_may_alias_p_1 (dref, ref, false) + || (flag_errno_math +targetm.ref_may_alias_errno (ref))); } /* Freeing memory kills the pointed-to memory. More importantly the call has to serve as a barrier for moving loads and stores is necessary. For posix_memalign? I think errno can contain any value, except that library is not allowed to clear errno. So, IMHO *p = 1; posix_memalign (...); return *p; can be still optimized into return 1;, because if p = errno; then *p after the call has undefined value (just known not to be zero). But on allocation failure posix_memalign may set it to 2, no? So for errno = 0; posix_memalign () errno = 0; ptr = malloc (); if (!ptr) perror (); we may not DSE the 2nd errno = 0 store. Richard.
[Bug c++/60096] c++11 lambda reference capture mistake
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60096 Feng Wang feng.w...@uni-ulm.de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Feng Wang feng.w...@uni-ulm.de --- mark as invalid.
[Bug tree-optimization/60098] DSE fails to DSE errno settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60098 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-02-06 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I have a patch.
[Bug tree-optimization/60098] New: DSE fails to DSE errno settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60098
Bug ID: 60098
Summary: DSE fails to DSE errno settings
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: rguenth at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
void *foo (int *p)
{
void *q;
*p = 0;
q = __builtin_malloc (4);
*p = 0;
return q;
}
the first *p = 0 store is dead.
[Bug debug/59992] [4.9 Regression] Compilation of insn-recog.c too slow due to var-tracking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59992 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Feb 6 15:47:12 2014 New Revision: 207562 URL: http://gcc.gnu.org/viewcvs?rev=207562root=gccview=rev Log: PR debug/59992 * var-tracking.c (adjust_mems): Before adding a SET to amd-side_effects, adjust it's SET_SRC using simplify_replace_fn_rtx. * gcc.dg/pr59992.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr59992.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/var-tracking.c
[Bug debug/59575] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59575 --- Comment #32 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Feb 6 15:52:17 2014 New Revision: 207563 URL: http://gcc.gnu.org/viewcvs?rev=207563root=gccview=rev Log: PR target/59575 * config/arm/arm.c (emit_multi_reg_push): Add dwarf_regs_mask argument, don't record in REG_FRAME_RELATED_EXPR registers not set in that bitmask. (arm_expand_prologue): Adjust all callers. (arm_unwind_emit_sequence): Allow saved, but not important for unwind info, registers also at the lowest numbered registers side. Use gcc_assert instead of abort, and SET_SRC/SET_DEST macros instead of XEXP. * gcc.target/arm/pr59575.c: New test. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog
[Bug debug/59575] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59575 --- Comment #33 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Feb 6 15:52:36 2014 New Revision: 207564 URL: http://gcc.gnu.org/viewcvs?rev=207564root=gccview=rev Log: PR target/59575 * config/arm/arm.c (emit_multi_reg_push): Add dwarf_regs_mask argument, don't record in REG_FRAME_RELATED_EXPR registers not set in that bitmask. (arm_expand_prologue): Adjust all callers. (arm_unwind_emit_sequence): Allow saved, but not important for unwind info, registers also at the lowest numbered registers side. Use gcc_assert instead of abort, and SET_SRC/SET_DEST macros instead of XEXP. * gcc.target/arm/pr59575.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr59575.c
[Bug debug/59575] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59575 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #34 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug debug/59992] [4.9 Regression] Compilation of insn-recog.c too slow due to var-tracking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59992 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- The testcase has been fixed, but unfortunately --enable-checking=yes,rtl insn-recog.c still takes about an hour to var-track.
[Bug target/60032] [4.9 regression] ICE in reload_cse_simplify_operands, at postreload.c:411
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- So fixed?
[Bug c/59984] OpenMP and Cilk Plus SIMD pragma makes loop incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59984 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Keywords||openmp CC||jakub at gcc dot gnu.org Target Milestone|--- |4.9.0
[Bug c++/19377] Using declaration in private part causes protected diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377
--- Comment #10 from fabien at gcc dot gnu.org ---
(In reply to Andrey Belevantsev from comment #9)
Another test case of the same issue (both clang and icc compile this fine):
It is not the same issue as the protected keyword is not involved. (And Clang
and ICC should be fixed instead, see below).
namespace ns {
class Base {
public:
int i;
};
class Derived : public Base {
using Base::i;
};
}
class DerivedDerived : public ns::Derived {
using ns::Base::i;
};
we get
/tmp/ns.C:4:9: error: ‘int ns::Base::i’ is inaccessible
/tmp/ns.C:10:7: error: within this context
It is indeed rejects-valid but I cannot claim this is a regression as I
can't find the version that did that correctly.
The testcase is not valid, as a using declaration shall refer to a direct base
class, which is not the case in 'using ns::Base::i' (the namespace ns does not
seem to be relevant here). It is invalid for a second reason, 'using Base::i'
is declared (implicitly) in a private section, so inaccessible in
DerivedDerived.
It's 9 years of the
original bugreport, maybe rise a priority?..
Raising the priority would not make me fix this bug more quickly. This bug is
not a regression, and not a high priority in my opinion. Thought, it is in my
TODO list. I gave it a try two years ago, and it was not obvious to fix. Feel
free to take over if you have more free time than I have.
[Bug sanitizer/59585] Tests failing due to trailing newline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59585 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Presumably fixed ?
[Bug target/58784] [ARM] LRA legitimate address issue with misalign neon_store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58784 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- This is now fixed.
[Bug rtl-optimization/60079] [LRA] ICE when compiling attached case.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60079 Vladimir Makarov vmakarov at gcc dot gnu.org changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #2 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to Tejas Belagod from comment #1) Created attachment 32053 [details] Reduced test case for LRA ICE. Sorry, I can not reproduce it on the today trunk (I tried -O[0-3] including -O2).
[Bug target/58699] ARM: emit PLDW instruction for prefetch with write intent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58699 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-06 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- confirmed.
[Bug middle-end/60089] Complex arithmetic instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60089 --- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot com --- Is the complex multiplication instruction C99 Annex G-conforming, or could it only be used for -fcx-limited-range?
[Bug sanitizer/59585] Tests failing due to trailing newline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59585 --- Comment #4 from Yuri Gribov tetra2005 at gmail dot com --- Yup, thanks.
[Bug middle-end/59776] [4.8/4.9 Regression] gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59776 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Priority|P2 |P1 Version|4.8.2 |4.9.0 Target Milestone|4.8.4 |4.9.0
[Bug other/60099] New: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60099
Bug ID: 60099
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: nheghathivhistha at gmail dot com
I can't build Seamonkey with rev.
x86_64-pc-linux-gnu-g++ -DMOZ_GLUE_IN_PROGRAM -DMOZILLA_INTERNAL_API
-DIMPL_LIBXUL -DSTATIC_EXPORTABLE_JS_API -DNO_NSPR_10_SUPPORT -fPIC
-DMOZILLA_CLIENT -ggdb -pipe -march=native -mtune=native -mno-avx
-fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno
-std=gnu++0x -pthread -DNDEBUG -DTRIMMED -Os -freorder-blocks
-fomit-frame-pointer -c testcase.ii
C-reduced testcase:
typedef enum
{ }
nsresult;
struct nsID
{
};
typedef nsID nsCID;
typedef nsID nsIID;
class nsISupports
{
};
class nsCOMPtr_helper
{
public:
virtual nsresult operator () (const nsIID , void **) const;
};
template class T class nsRefPtr
{
public:
T element_type;
nsRefPtr operator= (const nsCOMPtr_helper helper)
{
helper (T::template COMTypeInfo int ::kIID, 0);
}
};
class nsIURI:nsISupports
{
public:
template class struct COMTypeInfo
{
static nsIID kIID;
};
};
extern C
{
#pragma GCC visibility push(default)
}
class nsCreateInstanceByCID:public nsCOMPtr_helper
{
public:
nsCreateInstanceByCID (nsCID aCID, nsISupports *, nsresult *):mCID
(aCID),
mErrorPtr ()
{
} nsresult operator () (const nsIID , void **) const;
nsCID mCID;
nsresult *mErrorPtr;
};
nsCID kSimpleURICID;
inline nsCreateInstanceByCID
do_CreateInstance (nsCID aCID, nsresult *)
{
return nsCreateInstanceByCID (aCID, 0, 0);
}
void
nsDataHandlerNewURI ()
{
nsRefPtr nsIURI uri;
uri = do_CreateInstance (kSimpleURICID, 0);
}
[Bug other/60099] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60099 --- Comment #1 from David Kredba nheghathivhistha at gmail dot com --- I am sorry, revision 207472.
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 --- Comment #46 from Jan Hubicka hubicka at gcc dot gnu.org --- Created attachment 32067 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32067action=edit Path I am testing Hi, this is patch I am testing. It synchronizes the logic in lto-cgraph.c and ipa-partition.c It seems I also forgot to commit very old patch for setting used_from_other_partition flag correctly, with current code we probably can trigger undefined symbol with COMDAT and cross-partition devirtualization. I will try to look into that next.
[Bug other/60099] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60099 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Weird, I can't reproduce it neither with r207472, nor with revision around that.
[Bug target/58785] [ARM] LRA issue in Thumb mode with movhi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58785 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-02-06 CC||ramana at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Looks to me like this is fixed. Trying for a variety of cores for Thumb-2 shows no ICE. Yvan ? Ramana
[Bug target/58847] ARM: emit NEON alignment hints for 32/16-bit accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58847 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-06 Ever confirmed|0 |1
[Bug other/60099] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60099 --- Comment #3 from David Kredba nheghathivhistha at gmail dot com --- Here it shows line number too. ./testcase.i:62:1: internal compiler error Going to attach original ii file. In check.sh I used in addition -I and -include that I deleted from the command before sending here, can it be that? x86_64-pc-linux-gnu-g++ -o nsDataHandler.o -c -I../../../dist/stl_wrappers -I../../../dist/system_wrappers -include /var/tmp/portage/www-client/seamonkey-2.24/work/comm-release/mozilla/config/gcc_hidden.h -DMOZ_GLUE_IN_PROGRAM -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -DSTATIC_EXPORTABLE_JS_API -DNO_NSPR_10_SUPPORT -I/var/tmp/portage/www-client/seamonkey-2.24/work/comm-release/mozilla/netwerk/protocol/data/../../base/src -I/var/tmp/portage/www-client/seamonkey-2.24/work/comm-release/mozilla/netwerk/protocol/data -I. -I../../../dist/include -I/usr/include/nspr -I/usr/include/nss -fPIC -DMOZILLA_CLIENT -ggdb -pipe -march=native -mtune=native -mno-avx -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -DNDEBUG -DTRIMMED -Os -freorder-blocks -fomit-frame-pointer -c ./testcase.i
