[Bug middle-end/77515] New: GCC fusing of multiply-add ["FMA"] occurring at "-O3" withOUT "-ffast-math" and withOUT "-ffp-contract=fast"

[abe_skolnik at yahoo dot com]

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

Bug ID: 77515
   Summary: GCC fusing of multiply-add ["FMA"] occurring at "-O3"
withOUT "-ffast-math" and withOUT "-ffp-contract=fast"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
          Reporter: abe_skolnik at yahoo dot com
  Target Milestone: ---

In GCC, on both x86_64 and AArch64, fusing of multiply-add ["FMA"] is occurring
at "-O3" withOUT "-ffast-math" and withOUT "-ffp-contract=fast".  This seems to
be in violation of preservation of exactly the same results as "-O2" and lower
without those "-f<...>" flags, since the fusing may result in higher precision
and therefor different results.

Clang/LLVM without "-f<...>" flags, on both x86_64 and AArch64, only performs
fusing at "-Ofast", not at "-O3".



fma_test.c
--
double fma(double a, double b, double c) {
  return a*b+c;
}



example console log
---
> clang_amd64 -march=haswell -O3fma_test.c -S -o - |  grep -c fmadd
0
> clang_amd64 -march=haswell -O3fma_test.c -S -o - | egrep -c 
> '(addsd|mulsd)'
2

> clang_amd64 -march=haswell -Ofast fma_test.c -S -o - |  grep -c fmadd
1
> clang_amd64 -march=haswell -Ofast fma_test.c -S -o - | egrep -c 
> '(addsd|mulsd)'
0

> clang_aarch64  -O3fma_test.c -S -o - |  grep -c fmadd
0
> clang_aarch64  -O3fma_test.c -S -o - | egrep -c '(fadd|fmul)'
2

> clang_aarch64  -Ofast fma_test.c -S -o - |  grep -c fmadd
1
> clang_aarch64  -Ofast fma_test.c -S -o - | egrep -c '(fadd|fmul)'
0

> gcc_aarch64-O3fma_test.c -S -o - |  grep -c fmadd
1
> gcc_aarch64-O3fma_test.c -S -o - | egrep -c '(fadd|fmul)'
0

> gcc_amd64   -march=haswell -O3fma_test.c -S -o - | grep -c fmadd
1
> gcc_amd64   -march=haswell -O3fma_test.c -S -o - | egrep -c 
> '(addsd|mulsd)'
0

[Bug middle-end/69234] New: recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC

[abe_skolnik at yahoo dot com]

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

Bug ID: 69234
   Summary: recent GCC trunk compilers miscompile the V8
JavaScript interpreter/JITC
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abe_skolnik at yahoo dot com
  Target Milestone: ---

Recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC such
that the compiled V8 [sans Chrome/Chromium] crashes when running the
included-with-V8 benchmarks.  Compiling the exact same V8 source code using GCC
5.2.0 or 5.3.0 results in correct execution.  We have tested execution on both
AMD64 [AKA "x86_64"] and AArch64 [AKA "ARM64"].  For the AMD64-targeting
compilers, the compiler was bootstrapped.  The AArch64-targeting compilers were
cross-compilers.

With lots of help from my teammate Kevin Hu, we have isolated that the first
commit that breaks V8 seems to be trunk Subversion r226861; GCC from trunk
r226860 compiles V8 such that it runs its own benchmarks OK.  [Please note that
the fork known as "Octane" of the V8 benchmarks was not used.]

We have determined that the location of the crash --
"IncrementalMarking::ActivateIncrementalWriteBarrier(NewSpace*)" -- is not
compiled any differently by the two different revisions of the compiler [at
least when targeting AMD64].  However, we _have_ been able to determine that
replacing only the object file containing that method --
"incremental-marking.o" -- and using that file while manually relinking the V8
build that was otherwise compiled with the earlier-revision compiler _does_
produce a crashing V8 "shell" program.  Therefor, logically, at least one
subroutine in this ".o" file was miscompiled.

The same crash has been found on AMD64 in r232207 from today [January 11 2016].

We are still working on reducing the test case further; we will post a smaller
test case later.



Steps to reproduce
--
* build GCC trunk r226860 for either AMD64 or AArch64

* build GCC trunk r226861 for either AMD64 or AArch64

* check out V8 version 4.9.274 from
<https://chromium.googlesource.com/v8/v8.git/+/refs/heads/4.9.274>

* build V8 with GCC trunk r226860 using either "make x64.release" or "make
arm64.release",
  "cd" into "benchmarks", execute "../out//shell run.js"

* build V8 with GCC trunk r226861 using either "make x64.release" or "make
arm64.release",
  "cd" into "benchmarks", execute "../out//shell run.js"

[Bug middle-end/69234] recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC

[abe_skolnik at yahoo dot com]

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

--- Comment #1 from Abe  ---
The file "incremental-marking.o" is compiled from the source code at "/src/heap/incremental-marking.cc".

[Bug middle-end/69234] recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC

[abe_skolnik at yahoo dot com]

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

Abe  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |---

--- Comment #8 from Abe  ---
Attaching the preprocessed source, compressed b/c it`s big...

FYI, I _did_ try searching for "V8" before submitting the bug.  The search
engine found nothing relevant.  It did _not_, for example, find bug #68853  :-(

[Bug middle-end/69234] recent GCC trunk compilers miscompile the V8 JavaScript interpreter/JITC

[abe_skolnik at yahoo dot com]

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

--- Comment #9 from Abe  ---
Created attachment 37309
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37309&action=edit
preprocessed part of V8

I will attach a compressed form of the relevant file --
"incremental-marking.cc" from V8, preprocessed on AMD64 Ubuntu 14.04.3 LTS
using GCC built from trunk revision 226861; analysis showed that preprocessing
the same source on the same machine using GCC built from trunk revision 226860
produced the same preprocessor output modulo lines starting in '#'.

[Bug target/69438] New: ICE while trying to cross-compile V8 for AArch64

[abe_skolnik at yahoo dot com]

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

Bug ID: 69438
   Summary: ICE while trying to cross-compile V8 for AArch64
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abe_skolnik at yahoo dot com
  Target Milestone: ---

Created attachment 37441
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37441&action=edit
V8 AArch64 ICE reduced test case preprocessed on Ubuntu 14 host

The essence of this bug is:
  try to:
compile V8 using bleeding-edge GCC for trunk
cross-compiled on an AMD64-ISA PC to AArch64
  expected result is:
either good compilation or an error message
  actual result is:
compiler ICEs while trying to compile AArch64-specific part of V8


Details:
  using GCC 5.3.0 vanilla for host compilers, only using bleeding-edge for
cross-compilation

  GCC trunk as of 2015-Oct.-01, with Git hash 2438858: still good
  GCC trunk as of 2015-Nov.-11, with Git hash 3f12088: bad
  GCC trunk as of 2015-Dec.-03, with Git hash 2438858: still bad

  V8 version: 4.9.274


Re-tested  with GCC from 2016-Jan.-12 with Git hash "e1a390d"  and V8
version 4.9.354,
as well as with GCC from 2016-Jan.-22 with Git hash "a44dd069" and V8
version 4.9.354;
the result is still the same ICE for both.

GREPable string for the ICE: "src/arm64/frames-arm64.cc:.* internal compiler
error: in assign_temp, at function.c:961"

Attaching a reduced test case that was reduced automatically by the
"multidelta" program from <http://delta.tigris.org/>.



The essence of the V8 build invocation is:
  GCC_V8_KLUDGE_FLAGS="-Wno-error -fno-delete-null-pointer-checks" # kludges
for badness in V8 source code
  export  CFLAGS="$GCC_V8_KLUDGE_FLAGS"
  export CXXFLAGS="$GCC_V8_KLUDGE_FLAGS"
  export CC_host=<  ... as needed as per your installation ...>
  export CXX_host=<  ... as needed as per your installation ...>
  export CC_target=< ... as needed as per your installation ...>
  export CXX_target=<... as needed as per your installation ...>
  make V=1 GYPFLAGS='-Dclang=0 -Dhost_clang=0' arm64.release



URLs

https://github.com/v8/v8/releases/tag/4.9.354
https://github.com/v8/v8/blob/4.9.354/src/arm64/frames-arm64.cc#L20



Full ICE result
---
../src/arm64/frames-arm64.cc: In static member function 'static
v8::internal::Register
v8::internal::JavaScriptFrame::constant_pool_pointer_register()':
../src/arm64/frames-arm64.cc:20:10: internal compiler error: in assign_temp,
at function.c:961
Register JavaScriptFrame::constant_pool_pointer_register() {
  ^~~

0xa2215c assign_temp(tree_node*, int, int)
../../gcc/function.c:961
0x8b2611 expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.c:2559
0x9b72d2 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10575
0x8c350c expand_expr
../../gcc/expr.h:256
0x8c350c expand_call_stmt
../../gcc/cfgexpand.c:2648
0x8c350c expand_gimple_stmt_1
../../gcc/cfgexpand.c:3536
0x8c350c expand_gimple_stmt
../../gcc/cfgexpand.c:3702
0x8c5801 expand_gimple_tailcall
../../gcc/cfgexpand.c:3749
0x8c5801 expand_gimple_basic_block
../../gcc/cfgexpand.c:5685
0x8cac06 execute
../../gcc/cfgexpand.c:6323
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

[Bug target/69438] [6 Regression] ICE with noreturn and function that return non-POD

[abe_skolnik at yahoo dot com]

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

--- Comment #3 from Abe  ---
Great job!  Thanks for your contribution[s].

— Abe






- Original Message -
From: pinskia at gcc dot gnu.org 
To: abe_skol...@yahoo.com
Sent: Friday, January 22, 2016 5:12 PM
Subject: [Bug target/69438] [6 Regression] ICE with noreturn and function that
return non-POD

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[6 Regression] ICE while|[6 Regression] ICE with
   |building V8 for AArch64 |noreturn and function that
   ||return non-POD

[Bug target/69438] [6 Regression] ICE with noreturn and function that return non-POD

[abe_skolnik at yahoo dot com]

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

--- Comment #4 from Abe  ---
(In reply to Andrew Pinski from comment #2)
> Confirmed, reduced testcase:
> __attribute__((noreturn)) void V8_Fatal(int);
> struct Register {
> Register(const Register& r) {}
> };
> Register fp_register() {
>V8_Fatal(0);
> }
> Register constant_pool_pointer_register() {
>V8_Fatal(0);
> }

Very interesting...  I was able to reduce this to:

  __attribute__((noreturn)) void V(int);
  struct R{R(const R&r){}};
  R f(){V(0);}
  R c(){V(0);}

... which still ICEs, with sufficient "-O", but removing the last line, i.e.
trying the following:

  __attribute__((noreturn)) void V(int);
  struct R{R(const R&r){}};
  R f(){V(0);}

... does _not_ ICE.

[Bug target/69438] [6 Regression] ICE with noreturn and function that return non-POD

[abe_skolnik at yahoo dot com]

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

--- Comment #5 from Abe  ---
Further analysis shows that the ICE is still present after adding a trivial
default constructor to the type and making the functions "go through the
motions" of creating an object of the requisite type and "return"ing it at
their ends even though they call a "noreturn" callee before arriving at their
"proper" return statements.

Also, this ICE is present at "-Os" in addition to "-O2" and "-O3" [and _not_
present at "-O0" and "-O1"].



__attribute__((noreturn)) void V(int);
struct R{R(){} R(const R&r){}};
R f(){R x; V(0); return x;}
R c(){R x; V(0); return x;}

[Bug target/69438] [6 Regression] ICE with noreturn and function that return non-POD

[abe_skolnik at yahoo dot com]

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

--- Comment #6 from Abe  ---
Further analysis shows that the ICE "needs" _both_ of the "V(0)" calls;
removing either one from the following eliminates the ICE.



__attribute__((noreturn)) void V(int);
struct R{R(){} R(const R&r){}};
R f(){V(0); return R();}
R c(){V(0); return R();}

[Bug target/69438] [6 Regression] ICE with noreturn and function that return non-POD

[abe_skolnik at yahoo dot com]

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

--- Comment #7 from Abe  ---
Further analysis shows that the ICE "needs" the user-provided copy ctor;
eliminating it, as shown below, eliminates the ICE too.



__attribute__((noreturn)) void V(int);
struct R{R(){}};
R f(){V(0); return R();}
R c(){V(0); return R();}

[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD

[abe_skolnik at yahoo dot com]

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

--- Comment #8 from Abe  ---
Slightly more reduced [2 bytes less? ;-)]...

__attribute__((noreturn))void V(int);
struct R{R(const R&){}};
R f(){V(0);}
R c(){V(0);}



This might be the most-reduced-possible form of this test case. 
Experimentation shows that:

  * removing the second function definition removes the ICE
  * removing the user-defined copy ctor removes the ICE
  * removing the int param. from 'V'removes the ICE

[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD

[abe_skolnik at yahoo dot com]

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

--- Comment #9 from Abe  ---
Further-reduced test case [13 bytes shorter: 76 bytes with 1-byte line
endings]...



[[noreturn]]void V(int);
struct R{R(const R&){}};
R f(){V(0);}
R c(){V(0);}



Additional notes:

  * removing "__attribute__((noreturn))" from the original reduction removes
the ICE

  * removing "[[noreturn]]"  from the abovereduction removes
the ICE

  * compiling with "-O0" or "-O1" is OK [no ICE]; "-O2", "-O3", and "-Os" all
lead to ICE

[Bug ipa/69241] [6 Regression] ICE with noreturn and function that return non-POD

[abe_skolnik at yahoo dot com]

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

--- Comment #10 from Abe  ---
Adding either of the following flags to "-O1" causes the compiler to ICE on the
most-reduced test case; adding any of the other "-f<...>" flags I tested [39 of
them including the following 2] did not enable the ICE:

  -fipa-icf
  -fipa-icf-functions


Using either of those flags results in exactly the same ICE with exactly the
same output...



C++11_v1_.cpp: In function ‘R f()’:
C++11_v1_.cpp:3:3: internal compiler error: in assign_temp, at function.c:961
 R f(){V(0);}
   ^

0xa2215c assign_temp(tree_node*, int, int)
../../gcc/function.c:961
0x8b2611 expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.c:2559
0x9b72d2 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10575
0x8c350c expand_expr
../../gcc/expr.h:256
0x8c350c expand_call_stmt
../../gcc/cfgexpand.c:2648
0x8c350c expand_gimple_stmt_1
../../gcc/cfgexpand.c:3536
0x8c350c expand_gimple_stmt
../../gcc/cfgexpand.c:3702
0x8c5801 expand_gimple_tailcall
../../gcc/cfgexpand.c:3749
0x8c5801 expand_gimple_basic_block
../../gcc/cfgexpand.c:5685
0x8cac06 execute
../../gcc/cfgexpand.c:6323
Please submit a full bug report,
with preprocessed source if appropriate.



Of note, "-fipa-icf-variables" is one of those that does _not_ trigger the ICE
when added to "-O1".

[Bug translation/66928] Typos in translatable strings

[abe_skolnik at yahoo dot com via Gcc-bugs]

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

Abe  changed:

   What|Removed |Added

 CC||abe_skolnik at yahoo dot com

--- Comment #2 from Abe  ---
from a recent ["Mon Apr 1 19:18:36 2024 +0100"] Git revision
["4bd2f59af4a78cdc80039cffa51c1d9ad91081a3"], and including line numbers on the
left...

———

gcc/gcov-tool.cc

183 /* Print merge usage and exit.  */
184
185 static void ATTRIBUTE_NORETURN
186 merge_usage (void)
187 {
188   fnotice (stderr, "Merge subcommand usage:");
189   print_merge_usage_message (true);
190   exit (FATAL_EXIT_CODE);
191 }

...

505 /* Print overlap usage and exit.  */
506
507 static void ATTRIBUTE_NORETURN
508 overlap_usage (void)
509 {
510   fnotice (stderr, "Overlap subcommand usage:");
511   print_overlap_usage_message (true);
512   exit (FATAL_EXIT_CODE);
513 }



———



fortran/lang.opt

384 faggressive-function-elimination
385 Fortran Var(flag_aggressive_function_elimination)
386 Eliminate multiple function invocations also for impure functions.

...

431 Enum
432 Name(gfc_convert) Type(enum gfc_convert) UnknownError(Unrecognized option
to endianness value: %qs)



———

... so my conclusion is "no to all 4": all 4 of the reported bugs are dead at
least of roughly April 1 2024 [no joke ;-)].

[Bug translation/66928] Typos in translatable strings

[abe_skolnik at yahoo dot com via Gcc-bugs]

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

--- Comment #3 from Abe  ---
(In reply to Eric Gallager from comment #1)
> are these still there?

"No" to all four [please see comment #2, i.e.
].

[Bug target/79646] Typos in vax.opt

[abe_skolnik at yahoo dot com via Gcc-bugs]

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

Abe  changed:

   What|Removed |Added

 CC||abe_skolnik at yahoo dot com

--- Comment #2 from Abe  ---
I fixed the English as indicated, then did my best with the language
translations.  In at least one case [Dutch], where the translation was empty
before, I left it empty.  In at least one case [Greek], where the translation
was empty before, I filled it in.

[Bug target/79646] Typos in vax.opt

[abe_skolnik at yahoo dot com via Gcc-bugs]

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

--- Comment #3 from Abe  ---
Created attachment 58032
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58032&action=edit
patch for VAX messages, including localization

Squashed patch based on my local Git for this PR.

[Bug target/79646] Typos in vax.opt

[abe_skolnik at yahoo dot com via Gcc-bugs]

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

--- Comment #4 from Abe  ---
Anybody who wants to chime in, but especially Eric Gallager: please let me know
whether or not my patch looks good enough for submission to the gcc-patches
mailing list, and if not then _why_ not [please].