[Bug analyzer/115680] ICE in on_ranges, at analyzer/constraint-manager.cc:3166

[gcc.hall at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115680

Jeremy  changed:

   What|Removed |Added

  Attachment #58530|0   |1
is obsolete||

--- Comment #5 from Jeremy  ---
Created attachment 58532
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58532=edit
Correct .s file with machine details

[Bug analyzer/115680] ICE in on_ranges, at analyzer/constraint-manager.cc:3166

[gcc.hall at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115680

Jeremy  changed:

   What|Removed |Added

  Attachment #58530|a-g.i   |a-g.s
   filename||

--- Comment #4 from Jeremy  ---
Comment on attachment 58530
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58530
.s containing machine details

.arch armv8.2-a+dotprod+crc+crypto+fp16+rcpc
.file   "g.c"

[Bug c/115680] ICE in on_ranges, at analyzer/constraint-manager.cc:3166

[gcc.hall at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115680

--- Comment #3 from Jeremy  ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/aarch64-unknown-linux-gnu/14.1.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../configure --with-cpu=cortex-a76
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.1.0 (GCC)

[Bug c/115680] ICE in on_ranges, at analyzer/constraint-manager.cc:3166

[gcc.hall at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115680

--- Comment #2 from Jeremy  ---
gcc -std=gnu23 g.c -DEDITOR=0 -O3 -Wall -Wextra -Wconversion -Wunused
-Wuninitialized -Wcast-qual -Wcast-align -Werror -march=native -mcpu=native
-mtune=native -pipe -funsigned-char -fwrapv -ffinite-math-only -mcmodel=tiny
-mlittle-endian -momit-leaf-frame-pointer -frename-registers
-mno-low-precision-recip-sqrt -mno-low-precision-sqrt -mno-low-precision-div
-mno-track-speculation -mpc-relative-literal-loads -mbranch-protection=none
-mno-fix-cortex-a53-835769 -mno-fix-cortex-a53-843419 -fcf-protection=none
-mearly-ra=all -mearly-ldp-fusion -mlate-ldp-fusion
--param=aarch64-ldp-policy=always --param=aarch64-stp-policy=always --param
case-values-threshold=6 -fwhole-program -fdelete-null-pointer-checks
-fallow-store-data-races -fno-math-errno -fno-reciprocal-math
-fno-trapping-math -fno-rounding-math -falign-jumps -ffp-contract=fast
-fmerge-all-constants -fomit-frame-pointer -freg-struct-return
-foptimize-strlen -fno-exceptions -fno-unwind-tables
-fno-asynchronous-unwind-tables -fno-stack-protector -Wno-clobbered
-Wno-char-subscripts -Wno-implicit-fallthrough -ftree-vrp -Wduplicated-branches
-Wduplicated-cond -Wpointer-arith -Wnested-externs -Wundef -Wfloat-conversion
-Wsign-conversion -Warith-conversion -Wnarrowing -Wsign-compare -Winline
-Woverflow -Wmissing-include-dirs -Wredundant-decls -Wunused-macros
-Wformat-truncation=2 -Woverlength-strings -Wdisabled-optimization -Wnormalized
-Wformat=2 -Wformat-overflow=2 -Wrestrict -Wshift-overflow=2 -Wpacked
-Wnull-dereference -Wmain -Wstringop-truncation -Wstringop-overflow=4
-Wstringop-overread -Winit-self -Wmultichar -Wstrict-prototypes
-Wreturn-local-addr -Wlogical-op -Wwrite-strings -Warray-bounds=2
-Wformat-signedness -Wstrict-overflow=5 -Walloc-zero -Wdiscarded-qualifiers
-fanalyzer -fstrict-aliasing -Wstrict-aliasing=3 -Wdouble-promotion
-Wunsafe-loop-optimizations -Wtrampolines -Wbad-function-cast
-Wcast-align=strict -Waddress-of-packed-member -Wsuggest-attribute=malloc
-Wsuggest-attribute=const -Wsuggest-attribute=noreturn -fstrict-flex-arrays=3
-Wxor-used-as-pow -Wdiscarded-array-qualifiers -Wenum-int-mismatch
-Wmissing-noreturn -Wflex-array-member-not-at-end -Wno-format-nonliteral
-freport-bug -save-temps -o /dev/null -lm -lreadline
gcc: warning: ‘-pipe’ ignored because ‘-save-temps’ specified
during IPA pass: analyzer
g.c:5629:10: internal compiler error: in on_ranges, at
analyzer/constraint-manager.cc:3166
 5629 |   return c1;
  |  ^~
0x1ab264b ana::merger_fact_visitor::on_ranges(ana::svalue const*,
ana::bounded_ranges const*)
../../gcc/analyzer/constraint-manager.cc:3166
0x1ab264b ana::merger_fact_visitor::on_ranges(ana::svalue const*,
ana::bounded_ranges const*)
../../gcc/analyzer/constraint-manager.cc:3146
0x1aadc33 ana::constraint_manager::for_each_fact(ana::fact_visitor*) const
../../gcc/analyzer/constraint-manager.cc:3252
0x1aadd43 ana::constraint_manager::merge(ana::constraint_manager const&,
ana::constraint_manager const&, ana::constraint_manager*)
../../gcc/analyzer/constraint-manager.cc:3193
0x111c62b ana::region_model::can_merge_with_p(ana::region_model const&,
ana::program_point const&, ana::region_model*, ana::extrinsic_state const*,
ana::program_state const*, ana::program_state const*) const
../../gcc/analyzer/region-model.cc:6222
0x1109dcb ana::program_state::can_merge_with_p(ana::program_state const&,
ana::extrinsic_state const&, ana::program_point const&, ana::program_state*)
const
../../gcc/analyzer/program-state.cc:1468
0x10ea973
ana::exploded_graph::maybe_process_run_of_before_supernode_enodes(ana::exploded_node*)
../../gcc/analyzer/engine.cc:3683
0x10ec2d7 ana::exploded_graph::process_worklist()
../../gcc/analyzer/engine.cc:3385
0x10ee377 ana::impl_run_checkers(ana::logger*)
../../gcc/analyzer/engine.cc:6210
0x10ef2bb ana::run_checkers()
../../gcc/analyzer/engine.cc:6308
0x10dfdef execute
../../gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/ccsQUmhZ.out file, please attach this to
your bugreport.
make: *** [makefile:269: lint] Error 1

[Bug c/115680] ICE in on_ranges, at analyzer/constraint-manager.cc:3166

[gcc.hall at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115680

--- Comment #1 from Jeremy  ---
Created attachment 58531
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58531=edit
.i file from save-temps containing pre-processed source

[Bug c/115680] New: ICE in on_ranges, at analyzer/constraint-manager.cc:3166

[gcc.hall at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115680

Bug ID: 115680
   Summary: ICE in on_ranges, at
analyzer/constraint-manager.cc:3166
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc.hall at gmail dot com
  Target Milestone: ---

Created attachment 58530
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58530=edit
.s containing machine details

[Bug c/90628] __builtin_mul_overflow writes to const qualified integer

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90628

--- Comment #2 from Jeremy  ---
(In reply to Marc Glisse from comment #1)
> Thanks for the report.
> (next time, please include a complete, compilable example, with the
> #includes, int main, etc)

Sorry, here is a complete program:-

#include 

int
main( int argc, const __attribute__ ((unused)) char *argv[] )
{
  const int a = argc;
  const int b = argc;

  if( __builtin_mul_overflow( a, b,  ) )
puts( "overflow" );

  printf( "square = %d\n", a );
}

[Bug c/90628] New: __builtin_mul_overflow writes to const qualified integer

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90628

Bug ID: 90628
   Summary: __builtin_mul_overflow writes to const qualified
integer
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc.hall at gmail dot com
  Target Milestone: ---

The following code compiles without any warning.  The same applies to add and
sub.  It does the multiply correctly.


  const int a = argc;
  const int b = argc;

  if( __builtin_mul_overflow( a, b,  ) )
puts( "overflow" );

  printf( "square = %d\n", a );

[Bug other/86686] ICE Seg fault while building GCC 8.2 (using GCC 8.1) on intel x86_64

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86686

--- Comment #3 from Jeremy  ---
Further investigation revealed that this was due to lack of disk space.
GCC 8.2 seems to need much more than GCC 8.1.

[Bug other/86686] ICE Seg fault while building GCC 8.2 (using GCC 8.1) on intel x86_64

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86686

Jeremy  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug other/86686] ICE Seg fault while building GCC 8.2 (using GCC 8.1) on intel x86_64

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86686

Jeremy  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Jeremy  ---
Believed incorrect config.

[Bug other/86686] New: Seg fault while builing GCC 8.2 (using GCC 8.1) on intel x86_64

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86686

Bug ID: 86686
   Summary: Seg fault while builing GCC 8.2 (using GCC 8.1) on
intel x86_64
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc.hall at gmail dot com
  Target Milestone: ---

g++ -std=gnu++98 -fno-PIE -c  -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -I. -Icp -I../../gcc -I../../gcc/cp
-I../../gcc/../include -I../../gcc/../libcpp/include -I/tmp/gcc-8.2.0/obj/./gmp
-I/tmp/gcc-8.2.0/gmp -I/tmp/gcc-8.2.0/obj/./mpfr/src -I/tmp/gcc-8.2.0/mpfr/src
-I/tmp/gcc-8.2.0/mpc/src  -I../../gcc/../libdecnumber
-I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace
-I/tmp/gcc-8.2.0/obj/./isl/include -I/tmp/gcc-8.2.0/isl/include  -o cp/decl.o
-MT cp/decl.o -MMD -MP -MF cp/.deps/decl.TPo ../../gcc/cp/decl.c
during RTL pass: expand
../../gcc/cp/decl.c: In function 'bool start_preparsed_function(tree, tree,
int)':
../../gcc/cp/decl.c:14941:1: internal compiler error: Segmentation fault
 start_preparsed_function (tree decl1, tree attrs, int flags)
 ^~~~
0xb23d1f crash_signal
../../gcc/toplev.c:325
0xc04740 coalesce_with_default
../../gcc/tree-ssa-coalesce.c:1063
0xc04740 create_outofssa_var_map
../../gcc/tree-ssa-coalesce.c:1259
0xc04f75 coalesce_ssa_name()
../../gcc/tree-ssa-coalesce.c:1802
0xbb030c remove_ssa_form
../../gcc/tree-outof-ssa.c:948
0xbb030c rewrite_out_of_ssa(ssaexpand*)
../../gcc/tree-outof-ssa.c:1174
0x7b9810 execute
../../gcc/cfgexpand.c:6227
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Makefile:1110: recipe for target 'cp/decl.o' failed
make[3]: *** [cp/decl.o] Error 1
make[3]: Leaving directory '/tmp/gcc-8.2.0/obj/gcc'
Makefile:4623: recipe for target 'all-stage1-gcc' failed
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory '/tmp/gcc-8.2.0/obj'
Makefile:26488: recipe for target 'stage1-bubble' failed
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory '/tmp/gcc-8.2.0/obj'
Makefile:951: recipe for target 'all' failed
make: *** [all] Error 2

[Bug c/77332] ICE when building gcc 6.2 (with gcc 6.1.0)

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77332

--- Comment #2 from Jeremy  ---
(In reply to Richard Biener from comment #1)
> I can't reproduce it.  It seems to happen in stage2 (-g -gtoggle) and I'm
> past that trying to reproduce (also that's the only stage where checking
> code is run).
> 
> Can you attach preprocessed source for the failing command source?

No I cant, sorry.
I suspect this may be environmental.
I tried again and it failed somewhere else.  I tried a third time on a
different disk and the build completed fine.  I tried a fourth time on the
original disk and it worked fine too.  So I cant reproduce it any more.  I have
built gcc many times on many machines and don't normally have any trouble.

[Bug other/77332] ICE when building gcc 6.2 (with gcc 6,1.0)

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77332

Jeremy  changed:

   What|Removed |Added

 CC||gcc.hall at gmail dot com
   Severity|normal  |major

[Bug other/77332] New: ICE when building gcc 6.2 (with gcc 6,1.0)

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77332

Bug ID: 77332
   Summary: ICE when building gcc 6.2 (with gcc 6,1.0)
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc.hall at gmail dot com
  Target Milestone: ---

Linux x86_64.

Configured with: ../configure --disable-multilib --enable-languages=c,c++

The build failed with:-  

/tmp/gcc-6.2.0/obj/./prev-gcc/xg++ -B/tmp/gcc-6.2.0/obj/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/tmp/gcc-6.2.0/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/tmp/gcc-6.2.0/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/tmp/gcc-6.2.0/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
 -I/tmp/gcc-6.2.0/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/include 
-I/tmp/gcc-6.2.0/libstdc++-v3/libsupc++
-L/tmp/gcc-6.2.0/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gcc-6.2.0/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I../../gcc/../libcpp/include -I/tmp/gcc-6.2.0/obj/./gmp -I/tmp/gcc-6.2.0/gmp
-I/tmp/gcc-6.2.0/obj/./mpfr -I/tmp/gcc-6.2.0/mpfr -I/tmp/gcc-6.2.0/mpc/src 
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/../libbacktrace -I/tmp/gcc-6.2.0/obj/./isl/include
-I/tmp/gcc-6.2.0/isl/include  -o insn-latencytab.o -MT insn-latencytab.o -MMD
-MP -MF ./.deps/insn-latencytab.TPo insn-latencytab.c
../../gcc/lto/lto-lang.c: In function ‘void lto_define_builtins(tree, tree)’:
../../gcc/lto/lto-lang.c:727:1: internal compiler error: in df_refs_verify, at
df-scan.c:4022
 }
 ^
0xc21563 df_refs_verify
../../gcc/df-scan.c:4022
0xc2175f df_insn_refs_verify
../../gcc/df-scan.c:4102
0xc21928 df_bb_verify
../../gcc/df-scan.c:4131
0xc21e76 df_scan_verify()
../../gcc/df-scan.c:4263
0xc0cc29 df_verify()
../../gcc/df-core.c:1831
0xc0b537 df_analyze_1
../../gcc/df-core.c:1217
0xc0b8d9 df_analyze()
../../gcc/df-core.c:1294
0x19bb34b execute_rtl_cprop
../../gcc/cprop.c:1875
0x19bb44c execute
../../gcc/cprop.c:1914
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.
make[3]: *** [Makefile:1085: lto/lto-lang.o] Error 1
make[3]: *** Waiting for unfinished jobs

[Bug target/63359] aarch64: 32bit registers in inline asm

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359

--- Comment #11 from Jeremy  ---
int32_t n;
asm( "str %1,[%0],#4" : "+r" (ptr) : "r" (n) : "memory" );

Caught me until I just happened to examine the assembler.

Of course %w1 works - but then I need SEPARATE code for 32-bit ARM and for
aarch64.

Now arnv8 has two register sizes, I ask also, please could it work like x86 and
use the operand size to determine which to emit, x or w.

[Bug inline-asm/49611] Inline asm should support input/output of flags

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611

--- Comment #17 from Jeremy gcc.hall at gmail dot com ---
Did you mean stc rather than setc ???

But yes, it looks like its working well.

On 20 July 2015 at 10:05, gccbugzilla at limegreensocks dot com 
gcc-bugzi...@gcc.gnu.org wrote:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611

 --- Comment #16 from David gccbugzilla at limegreensocks dot com ---
 I've tried it now and it seems to do good things.  This code:

 int main(int argc, char *argv[])
 {
char x;

asm(setc : =@ccc(x));

if (!x)
   return 6;
else
   return argc;
 }

 produces this output (-O3):

 movl$6, %eax
 /APP
  # 6 ./r.cpp 1
 setc
  # 0  2
 /NO_APP
 cmovc   %ebx, %eax
 addq$32, %rsp
 popq%rbx
 ret

 Although a minor variation (change return argc to return 7) ends up
 doing
 setc+cmpb, so it's not a perfect solution.

 Still, if I were Richard, I'd be closing this bug.  If someone has
 optimization
 issues with his solution, that's a new bug.

 --
 You are receiving this mail because:
 You are on the CC list for the bug.

[Bug inline-asm/49611] Inline asm should support input/output of flags

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611

--- Comment #15 from Jeremy gcc.hall at gmail dot com ---
Perhaps the optimizer can reduce seta; test; jnz to ja since the
compiler now knows the intention.  In which case this is a great solution.

On 17 July 2015 at 22:24, gccbugzilla at limegreensocks dot com 
gcc-bugzi...@gcc.gnu.org wrote:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611

 --- Comment #14 from David gccbugzilla at limegreensocks dot com ---
 (In reply to Jeremy from comment #12)

  It probably does a setcc on x86 which doesn't really gain much

 I don't have a 6.0 build to test with yet, but I don't believe that's quite
 correct.  Looking at the testsuite that got checked in with it, we see
 both:

 asm-flag-2.c:
 /* { dg-final { scan-assembler seta } } */

 asm-flag-3.c:
 /* { dg-final { scan-assembler ja } } */

 --
 You are receiving this mail because:
 You are on the CC list for the bug.

[Bug inline-asm/49611] Inline asm should support input/output of flags

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611

--- Comment #12 from Jeremy gcc.hall at gmail dot com ---
Hi David,
That's very interesting.  Its not in gcc 5.2.0 released yesterday though.
It probably does a setcc on x86 which doesn't really gain much, but on ARM
it could be useful.
More useful (as of gcc 5.0) is the new __builtin_xxx_overflow which uses
the overflow flag directly.   So for int16_t  operands for example:
if(   __builtin_add_overflow( a, b, result)  )
 printf( overflow);
it would emit addw; jno.

Jeremy



On 17 July 2015 at 06:41, gccbugzilla at limegreensocks dot com 
gcc-bugzi...@gcc.gnu.org wrote:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611

 --- Comment #11 from David gccbugzilla at limegreensocks dot com ---
 Apparently this feature has been checked in:
 https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#FlagOutputOperands

 --
 You are receiving this mail because:
 You are on the CC list for the bug.

[Bug target/66120] New: __builtin_add/sub_overflow for int32_t emit poor code on ARM

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66120

Bug ID: 66120
   Summary: __builtin_add/sub_overflow for int32_t emit poor code
on ARM
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc.hall at gmail dot com
  Target Milestone: ---

Please see related PR66112 for x86
---
#include stdio.h
#include inttypes.h
int
main( int argc, const char *argv[] )
{
  int32_t result, a = (int32_t)atoi(argv[1]), b = (int32_t)atoi( argv[2] );
  if( __builtin_add_overflow( a, b, result ) )
printf( Overflow\n);
 else
printf( Sum is %d\n, result );
}
--
Few instructions on ARM set the overflow flag.  Two that do are 32-bit add and
subtract.  For these two, GCC could just emit adds or subs followed by
bvs.
Instead (from the last atoi() down) it produces:-

bl  atoi@
add r1, r4, r0  @ tmp121, a, b
cmp r0, #0  @ b,
blt .L4 @,
cmp r1, r4  @ tmp121, a
bge .L5 @,
b   .L3 @
.L4:
cmp r1, r4  @ tmp121, a
ble .L5 @,

[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66112

--- Comment #7 from Jeremy gcc.hall at gmail dot com ---
Comment on attachment 35522
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35522
gcc5-pr66112.patch

Done, PR66120

[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66112

--- Comment #3 from Jeremy gcc.hall at gmail dot com ---
Related FYI,
Few instructions on ARM set the overflow flag.  Two that do are 32-bit add and
subtract.  For these two, GCC could just emit adds followed by bvs 
Instead it produces:-

bl  atoi@
add r1, r4, r0  @ tmp121, a, b
cmp r0, #0  @ b,
blt .L4 @,
cmp r1, r4  @ tmp121, a
bge .L5 @,
b   .L3 @
.L4:
cmp r1, r4  @ tmp121, a
ble .L5 @,

[Bug other/66112] New: __builtin_mul_overflow for int16_t emits poor code

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66112

Bug ID: 66112
   Summary: __builtin_mul_overflow for int16_t emits poor code
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc.hall at gmail dot com
  Target Milestone: ---

I am using all the three signed integer overflow builtin's for the four 
types: int8_t, int16_t, int32_t and int64_t on Intel x64.  In all cases except
one this produces optimal code, the operation followed by jo.  See the test
case below.
For the int32_t type, from  the last atoi down:

callatoi#
imull   %eax, %ebx  # b, tmp100
jo  .L3 #,

However, for int16_t this produces much larger code that does a 32 bit multiply
and checks for overflow by hand:

callatoi#
movswl  %bx, %esi   # D.5222, D.5222
cwtl
imull   %esi, %eax  # D.5222, tmp109
movl%eax, %edx  # tmp109, tmp110
movl%eax, %ecx  # tmp109, tmp111
sarl$16, %edx   #, tmp110
sarw$15, %cx#, tmp111
cmpw%dx, %cx# tmp110, tmp111
jne .L7 #,

Even though a simple imulw followed by jo would work.

---
#include stdio.h
#include inttypes.h
int
main( int argc, const char *argv[] )
{
  int16_t result, a = (int16_t)atoi(argv[1]), b = (int16_t)atoi( argv[2] );
  if( __builtin_mul_overflow( a, b, result ) )
printf( Overflow\n);
 else
printf( Product is %d\n, result );
}

[Bug inline-asm/49611] Inline asm should support input/output of flags

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611

--- Comment #8 from Jeremy gcc.hall at gmail dot com ---
Asm goto does not allow any outputs, which does limit its usefulness.

[Bug inline-asm/49611] Inline asm should support input/output of flags

[gcc.hall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611

Jeremy gcc.hall at gmail dot com changed:

   What|Removed |Added

 CC||gcc.hall at gmail dot com

--- Comment #5 from Jeremy gcc.hall at gmail dot com ---
It may not be possible, but perhaps a simpler thing might be for
the asm() to notionally return a single boolean value which
reflects ONE flag only.

By default this could be the ZF flag (which is probably the most
useful).  It would not generate any extra code at all. Thus:

   if( asm( test %%eax,%%eax ))

would emit:

   test eax,eax
   jz

rather than the usual route involving setcc and a second test.

The actual flag notionally returned could be changed with an attribute:

  __attribute__ ((asm_return(cc_carry)))
  __attribute__ ((asm_return(cc_overflow)))
  __attribute__ ((asm_return(cc_zero)))
  __attribute__ ((asm_return(cc_sign)))
  __attribute__ ((asm_return(cc_parity)))

or shorter, for example:

  __attribute__ ((cc_carry))

The inverse condition is simply expressed with  !asm(...)

The new code would also allow:

  bool zero = asm( test %%eax,%%eax );

where the compiler would emit setz.
or

  x = asm( test %%eax,%%eax ) ? 10 : 20;

where the compiler might emit cmovz.

It would not break any existing code because nothing yet expects a return from
an asm,
neither would it preclude exporting all the flags with =cc in the future.

It would be a hard error if a flag is not supported by the current platform as
code cannnot be generated.
GCC does not examine the asm template string, if the flag is not set then the
result is UB, just like use of an undefined variable.

A final, more useful, example:

  // Implement left *= right reporting signed integer overflow
#define checked_multiply(left,right) \
__attribute__ ((asm_return(cc_overflow))) \
asm( imul %1,%0 : +r (left) : r (right) )

allowing an efficient implementation of:

   if( checked_multiply( a, b ) )
   {
  handle overflow
   }


Possible documentation follows... 

Return Value

If you are using the asm_return attribute, you are informing the compiler that
a comparison has already been done in your assembler code, and the flags have
been set appropriately.  The compiler can now use those flags to perform
conditional jumps, conditional assignments, etc.  Which conditional operator
should be used is determined by which value is specified to asm_return.  For
example on i386:

if( __attribute__(asm_return(cc_carry)) asm() )
  printf (Carry yes\n);
else
  printf (Carry no\n);

indicates that the asm template has set a value in the Carry flag, and GCC
should use the jc/jnc instructions to jump to the correct location. Similarly:

int a = __attribute__(asm_return(cc_zero)) asm() ?  23 : 42;

could use the i386 cmovz instruction to perform the assignment.  And

bool DidOverflow = __attribute__(asm_return(cc_overflow)) asm();

could use i386's seto.

Which flags (if any) are supported depend upon your platform (see Asm
Attributes). If no asm_return attribute is specified, it is an error to attempt
to use the return value from the asm.  It is acceptable for code to ignore the
returned flags.

[Bug target/56940] internal compiler error: unrecognizable insn:

[gcc.hall at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56940



--- Comment #2 from Jeremy gcc.hall at gmail dot com 2013-04-13 07:58:24 UTC 
---



 You should report this failure to where you got the binary from really.



Yes, sorry.  They should be distributing a supported version too.



I suspect this is an ARM issue.

The problem does not occur with GCC 4.3.2, 4.7.0 (x86) and 4.8.0 (x64)



I was unable to build GCC on the Raspberry Pi so I cant (yet) test 4.6.4.



Note the problem happens with -O3 and not -O2.

[Bug c/56940] New: internal compiler error: unrecognizable insn:

[gcc.hall at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56940



 Bug #: 56940

   Summary: internal compiler error: unrecognizable insn:

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: gcc.h...@gmail.com





Created attachment 29863

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29863

pre-processed source file



I know this is an old version of GCC, but it is the one distributed with the

current Debian (well, raspbian).



Version

---



pi@raspberrypi ~ $ gcc -v  

Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper

Target: arm-linux-gnueabihf

Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14+rpi1'

--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs

--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr

--program-suffix=-4.6 --enable-shared --enable-linker-build-id

--with-system-zlib --libexecdir=/usr/lib --without-included-gettext

--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6

--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu

--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object

--enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6

--with-fpu=vfp --with-float=hard --enable-checking=release

--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf

--target=arm-linux-gnueabihf

Thread model: posix

gcc version 4.6.3 (Debian 4.6.3-14+rpi1) 



Error

-



gcc -pipe -std=gnu99 -funsigned-char -DFILE_TABS=4 -DSCREEN_TABS=2 -c g.c

-DEDITOR=0 -DLATIN8 -O3 -Wall -Wextra -Wunused -Wunreachable-code

-Wstrict-aliasing=3 -Wredundant-decls -Winline -Wundef -Wwrite-strings

-Wcast-qual -Wmissing-noreturn -Winit-self -Wformat=2 -Woverlength-strings

-Wlogical-op -Wshadow -Wstrict-prototypes -Wstrict-overflow=1

-Wmissing-include-dirs -Wold-style-definition -Wpointer-arith

-Wdisabled-optimization -Wredundant-decls -Wmissing-prototypes

-Wmissing-declarations -Wunused-parameter -Wno-char-subscripts -Wuninitialized

-Wunsafe-loop-optimizations -Waggregate-return -Wmissing-format-attribute

-Wsign-conversion -Wvariadic-macros -Wnormalized=nfc -Wnested-externs

-Wunused-macros -Wconversion -ffast-math -fno-reciprocal-math

-fno-associative-math -fwrapv -mfloat-abi=hard -mfpu=vfp -fwhole-program

-fomit-frame-pointer -fmerge-all-constants -fno-ident -fno-unwind-tables

-fno-asynchronous-unwind-tables -lm -lcurses -ldl -o /dev/null

g.c: In function 'print_val':

g.c:10360:1: error: unrecognizable insn:

(insn 1086 1085 1087 72 (set (subreg:SI (reg/v:DI 252 [ ival ]) 0)

(sign_extend:SI (mem/s/c:QI (plus:SI (reg/f:SI 323)

(const_int 1672 [0x688])) [0 MEM[(const struct VALUE

*)locals + 1248B].v.o+0 S1 A64]))) g.c:6373 -1

 (nil))

g.c:10360:1: internal compiler error: in extract_insn, at recog.c:2109

Please submit a full bug report,

with preprocessed source if appropriate.

See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions.

Preprocessed source stored into /tmp/ccDnsSF8.out file, please attach this to

your bugreport.

[Bug c/55383] New: -Wcast-qual reports incorrect message

[gcc.hall at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383



 Bug #: 55383

   Summary: -Wcast-qual reports incorrect message

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: gcc.h...@gmail.com





--

#include string.h

int

main( int argc, char *argv[] )

{

  volatile double val;

  memset( (void*)val, 0, sizeof(double) );

}

-



 gcc -Wcast-qual bug.c

bug.c: In function 'main':

bug.c:7:11: warning: cast discards '__attribute__((noreturn))' qualifier from

pointer target type [-Wcast-qual]



~/j/ge* gcc -v   

Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper

Target: x86_64-redhat-linux

Configured with: ../configure --prefix=/usr --mandir=/usr/share/man

--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla

--enable-bootstrap --enable-shared --enable-threads=posix

--enable-checking=release --disable-build-with-cxx

--disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit

--disable-libunwind-exceptions --enable-gnu-unique-object

--enable-linker-build-id --with-linker-hash-style=gnu

--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin

--enable-initfini-array --enable-java-awt=gtk --disable-dssi

--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre

--enable-libgcj-multifile --enable-java-maintainer-mode

--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib

--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686

--build=x86_64-redhat-linux

Thread model: posix

gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC)

[Bug c/50975] New: Logical operators evaluated in wrong order if no side effects

[gcc.hall at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50975

 Bug #: 50975
   Summary: Logical operators evaluated in wrong order if no side
effects
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc.h...@gmail.com


gcc 4.6.2  -Os 

If the expressions either side of a logical operator (|| or ) have no
side effects, gcc sometimes evaluates them in the wrong order.See
the example below.  Of course the code works, but the standard is clear,
logical operators GUARANTEE left to right evaluation.  In this case 
people use the feature as a micro optimization, putting the most likely to
succeed case first with || or vice-versa with .

---
#include stdio.h
int
main( int argc, char *argv[] )
{
  char *last = argv[1];

  if( *last == 10 || *last == 13 )
--last;

  printf(last = %p\n, last );
  return 0;
}
-
movb(%eax), %dl # *last_3, D.2517
cmpb$13, %dl#, D.2517
je  .L4 #,
cmpb$10, %dl#, D.2517
jne .L2 #,
.L4:
decl%eax# last
.L2:

[Bug c/50975] Logical operators evaluated in wrong order if no side effects

[gcc.hall at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50975

--- Comment #2 from Jeremy gcc.hall at gmail dot com 2011-11-03 12:37:41 UTC 
---
(In reply to comment #1)
 But ... you can't tell the difference.  So this is a valid optimization.

You can tell the difference in execution time.

And why is this an optimization?  In this case, I cant see how it can improve
the code other than to lose any input from the programmer, who knows when the
data is biased.  I guess it might help in a more complex expression.

I think this is different from the controversy over the handling of signed
integer overflow.  There is no undefined behavior here.  The language standard
from KR to the present day explicitly states the evaluation order is
guaranteed left to right with these operators.

[Bug c/50347] New: unexpected -Wconversion error from gcc builtin

[gcc.hall at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50347

 Bug #: 50347
   Summary: unexpected -Wconversion error from gcc builtin
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc.h...@gmail.com


This message is produced from the code example below.

bug.c: In function 'main':
bug.c:17:2: warning: conversion to 'long long int' from 'long long unsigned
int' may change the sign of the result [-Wsign-conversion]

builtin_ffsll is documented as:-
Built-in Function: int __builtin_ffsll (unsigned long long)

Similar to __builtin_ffs, except the argument type is unsigned long long. 

Note this does not happen with the other similar builtin's (__ctzll for
example)

-
#include stdio.h
#include stdlib.h

int
main( int argc, char *argv[] )
{
  if( argc  1 )
  {
char *tail;
unsigned long long n = strtoull( argv[1], tail, 0 );
if( tail == argv[1] )
  return 1;

int lsb = __builtin_ffsll( n );

printf(lsb = %d\n, lsb );
  }
  return 0;
}
---
* gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.6.1/configure
Thread model: posix
gcc version 4.6.1 (GCC)

[Bug c/50347] unexpected -Wconversion error from gcc builtin

[gcc.hall at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50347

--- Comment #1 from Jeremy gcc.hall at gmail dot com 2011-09-10 10:15:15 UTC 
---
I see this builtin is presumably intended to implement the library function
ffsll() which takes a signed argument.  In which case this is just a
documentation issue.

[Bug c/50347] unexpected -Wconversion error from gcc builtin

[gcc.hall at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50347

--- Comment #2 from Jeremy gcc.hall at gmail dot com 2011-09-10 21:57:59 UTC 
---
I think also the doc needs changing for __builtin_bswap64/32 as it looks like
they accept and return unsigned integers.  uint64_t instead of int64_t.

[Bug gcov-profile/50228] New: Incorrect line execution count.

[gcc.hall at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50228

 Bug #: 50228
   Summary: Incorrect line execution count.
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc.h...@gmail.com


Source line 6625 is reported as having been executed more times than is
possible.

Secondly I saw that all the source lines in the function were executed at least
once, but it says blocks executed 92%

gcov 4.6.1, gcc 4.6.1 (-O0 -ggdb3 --coverage)

function Evaluate called 29903918 returned 100% blocks executed 92%
 29903918: 6610:Evaluate( TOKEN * const expr, const int result_type )
-: 6611:{
 29903918: 6612:  parse( last_result, expr, END_EXP );
call0 returned 29903918
-: 6613:
 29903918: 6614:  if( last_result-fp )
branch  0 taken 1799 (fallthrough)
branch  1 taken 29902119
-: 6615:  {
 1799: 6616:if( result_type == INT )
branch  0 taken 1 (fallthrough)
branch  1 taken 1798
-: 6617:{
1: 6618:  last_result-opval.e = iconv( last_result-opval.r,
expr-errp );
call0 returned 1
1: 6619:  last_result-fp = NO;
-: 6620:}
-: 6621:  }
-: 6622:  else
-: 6623:  {
 29902119: 6624:if( result_type == INT )
branch  0 taken 17342570 (fallthrough)
branch  1 taken 12559549
 34685140: 6625:  last_result-opval.e = itrunc( last_result-opval.i,
expr-errp );
 12559549: 6626:elif( result_type == REAL )
branch  0 taken 1 (fallthrough)
branch  1 taken 12559548
-: 6627:{
1: 6628:  last_result-opval.r = last_result-opval.i;
1: 6629:  last_result-fp = YES;
-: 6630:}
-: 6631:  }
-: 6632:
 29903918: 6633:  return last_result;
-: 6634:}

[Bug middle-end/33349] Redundant zero-extension of registers

[gcc.hall at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33349

Jeremy gcc.hall at gmail dot com changed:

   What|Removed |Added

 CC||gcc.hall at gmail dot com

--- Comment #2 from Jeremy gcc.hall at gmail dot com 2011-06-16 11:27:24 UTC 
---

Another example I came across ...

  unsigned short sw;
  asm( fnstsw %0 : =a (sw) );

  if( sw  FE_DIVBYZERO )
...   
  if( sw  FE_OVERFLOW )
...  
  if( sw  FE_UNDERFLOW )
...

generates:

movzx   eax, ax # D.14460, sw

testal, 1   # D.14460,

testal, 4   # D.14460,

testal, 8   # D.14460,

[Bug inline-asm/49410] New: Internal compiler error in change-stack at reg-stack.c:2540

[gcc.hall at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49410

   Summary: Internal compiler error in change-stack at
reg-stack.c:2540
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc.h...@gmail.com


I saw this while experimenting with the (probably incorrect) inline x87
assembler:

test.c: In function 'main':
test.c:16:1: internal compiler error: in change_stack, at reg-stack.c:2540
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
#include stdio.h

int
main( int argc, char *argv[] )
{
  long double x, n = 1234.0L;

  asm( fldpi; fmulp; fsqrt : =t (x) : u (n) );

  printf(sqrt(pi * n) = %Lg\n, x );
}
--
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.6.0/configure
Thread model: posix
gcc version 4.6.0 (GCC)

[Bug c/47351] Segmentation fault in MinGW

[gcc.hall at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47351

--- Comment #4 from Jeremy gcc.hall at gmail dot com 2011-01-19 13:06:41 UTC 
---
Done.  I can report that the problem does not occur with GCC 4.5.2

[Bug c/47351] New: Segmentation fault in MinGW

[gcc.hall at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47351

   Summary: Segmentation fault in MinGW
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc.h...@gmail.com


Created attachment 23021
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23021
Source file

I had the following crash while creating an assembler listing with MinGW gcc.
It is possible -mtune=generic affected the problem as -mtune=i386 was fine?
The identical run on Linux GCC 4.5.1 does not crash.  Neither does it crash
when I do a normal build with MinGW and the same options.

$ make asm
gcc -pipe -std=c99 -funsigned-char -DFILE_TABS=4 -DSCREEN_TABS=2 -DUSER_TABS=1
g.c -S -masm=intel
 -fverbose-asm -Os -Wall -Wextra -Wno-char-subscripts -ffast-math -mfpmath=387
-mpc80 -mhard-float
 -mieee-fp -s -fno-ident -fshort-enums -fwhole-program -minline-all-stringops
-fmerge-all-constants
 -fomit-frame-pointer -fno-non-call-exceptions -fno-asynchronous-unwind-tables
-fno-exceptions
 -fno-unwind-tables -fira-loop-pressure -fstrict-aliasing -fstrict-overflow
-lcurses -aux-info
 g.info -march=i386 -mtune=generic -o g.s
g.c: In function 'se_execute':
g.c:9275:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make: *** [asm] Error 1
-

$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.0/configure
--enable-languages=c,c++,ada,fortran,objc,obj-c++
  --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp
--disable-win32-registry
  --enable-version-specific-runtime-libs --disable-werror --build=mingw32
--prefix=/mingw
Thread model: win32
gcc version 4.5.0 (GCC)

---

[Bug c/47351] Segmentation fault in MinGW

[gcc.hall at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47351

--- Comment #1 from Jeremy gcc.hall at gmail dot com 2011-01-18 21:08:37 UTC 
---
Created attachment 23022
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23022
the makefile

[Bug c/47351] Segmentation fault in MinGW

[gcc.hall at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47351

--- Comment #2 from Jeremy gcc.hall at gmail dot com 2011-01-18 21:11:23 UTC 
---
Please find attached the source file  g.c  and the makefile.

The target asm causes the crash.  The target win does a successful build.

The program is a small screen editor, it is self contained in this one source
file, and for mingw, needs no extra libraries.

[Bug target/47186] New: -O2 moves invariant address load INTO loop

[gcc.hall at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47186

   Summary: -O2 moves invariant address load INTO loop
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc.h...@gmail.com
  Host: Fedora 14
Target: i?86-*-*
 Build: 4.5.1 20100924 (Red Hat 4.5.1-4)


gcc -O1 try.c -S -masm=intel -o try.s

In the example below, the address load to esi for the movsd is moved into the
loop when -O2 is used.  With -O1 its outside the loop.

Perhaps this is something to do with scheduling?  I tried with various x86
targets and it always happened, although the position of the address load
within the loop changed between atom and core2 for example.

--
#include stdio.h
#include stdlib.h
#include string.h

int mike[100], joe[100];

int main( int argc, char *argv[] )
{
  int i;
  for( i = 0; i  100; ++i )
mike[i] = rand();
  memcpy( joe, mike, sizeof(joe) );
}
--
Compile with -O1 produces ...

.L2:
callrand
mov DWORD PTR mike[0+ebx*4], eax
add ebx, 1
cmp ebx, 100
jne .L2
mov edi, OFFSET FLAT:joe
mov esi, OFFSET FLAT:mike
mov ecx, 100
rep movsd

Now repeat with -O2, and esi is loaded within the loop

.L2:
callrand
mov esi, OFFSET FLAT:mike
mov DWORD PTR mike[0+ebx*4], eax
add ebx, 1
cmp ebx, 100
jne .L2
mov ecx, ebx
mov edi, OFFSET FLAT:joe
rep movsd

[Bug other/46599] New: Possible enhancement for inline stringops with -Os

[gcc.hall at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46599

   Summary: Possible enhancement for inline stringops with -Os
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc.h...@gmail.com
  Host: Fedora 14
Target: Core i7
 Build: GCC 4.5.1 20100924


GCC 4.5.1 20100924 -Os -minline-all-stringops  on Core i7

int
main( int argc, char *argv[] )
{
  int i, a[256], b[256];

  for( i = 0; i  256; ++i )  // discourage optimization
a[i] = rand();

  memcpy( b, a, argc * sizeof(int) );

  printf( %d\n, b[rand()] );  // discourage optimization

  return 0;
}

I wonder if its possible to improve the -Os code generation for inline
stringops when
the length is known to be a multiple of 4 bytes?

That is, instead of:

movsx   rcx, ebp# argc
sal rcx, 2
rep movsb

it would be nice to see:

movsx   rcx, ebp# argc
rep movsd

Note that  memcpy( b, a, 1024 ) generates:

mov ecx, 256
rep movsd

This is for -Os which normally emits a movs, not a loop.  The same applies to
stos.

The reason I think this might be possible is this:-

Use -mstringop-strategy=rep_4byte to force the use of movsd.

For memcpy( b, a, argc * sizeof(int) ) we get:

movsx   rcx, ebp# argc
sal rcx, 2
cmp rcx, 4
jb  .L5 #,
shr rcx, 2
rep movsd
.L5:


For memcpy( b, a, argc ) we get:

movsx   rax, ebp# argc, argc
mov rdi, rsp# tmp76,
lea rsi, [rsp+1024] # tmp77,
cmp rax, 4  # argc,
jb  .L3 #,
mov rcx, rax# tmp78, argc
shr rcx, 2  # tmp78,
rep movsd
.L3:
xor edx, edx# tmp80
testal, 2   # argc,
je  .L4 #,
mov dx, WORD PTR [rsi]  # tmp82,
mov WORD PTR [rdi], dx  #, tmp82
mov edx, 2  # tmp80,
.L4:
testal, 1   # argc,
je  .L5 #,
mov al, BYTE PTR [rsi+rdx]  # tmp85,
mov BYTE PTR [rdi+rdx], al  #, tmp85
.L5:

In the former case memcpy(b, a, argc * sizeof(int)) gcc has omitted all the
code do deal with 1,
2, and 3 bytes so the stringop code generation has apparently spotted that the
length
is a multiple of 4 bytes.

I can see that the expression code for the length is separate from the stringop
stuff.  Though it does do the right thing with a literal.

Incidentally, for the second case, memcpy( b, a, argc ), the Visual Studio
compiler generates code like this:

mov eax, ecx
shr ecx, 2
rep movsd
mov ecx, eax
and ecx, 3
rep movsb

which seems cleaner (no jumps) than the GCC code, though knowing GCC there is
probably a good reason for its choice as it generally seems to have a far more
sophisticated optimizer.

[Bug other/46599] Possible enhancement for inline stringops with -Os

[gcc.hall at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46599

--- Comment #2 from Jeremy gcc.hall at gmail dot com 2010-11-22 12:22:48 UTC 
---
(In reply to comment #1)
 -minline-all-stringops isn't supposed to be used (it's for debugging), and
 probably doesn't mix well with -Os anyway.

OK thanks.  I think in this context its a red herring as I get identical
results without it for the test program.  

In my real app, it only seems to add cmpsb and doesn't affect movs, stos, or
scas anyway.