[Bug tree-optimization/18501] [7/8/9/10 Regression] Missing 'used uninitialized' warning (CCP)

[vlad at ispras dot ru]

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

--- Comment #91 from Vladislav Ivanishin  ---
> --- Comment #90 from Eric Gallager  ---
> At Cauldron, Vladislav Ivanishin said in his lightning talk that ISP
> RAS has a patch to fix this.

Well, I also said that this patch is not meant to go into the mainline
compiler, because it trades off compiler speed for fixing this
(actually, for suppressing tons of false positives that inevitably arise
from doing that; see comment 32 by Richi).  Adding / moving around
transformation passes also affects the resulting code, and I have no
data to see what the actual impact is.

We did this to have as few false negatives as possible (and a sane
number of false positives) - and GCC is prioritizing not having false
positives a.k.a. spurious warnings.

One possible solution would be to teach the CCP pass to lay off of
uninitialized values and not merge them into constants (I don't know
whether that's desirable and also I don't have a patch for that, though
it would be interesting to try).

Anyway, you are right in that this kind of effort should be documented
in this bug.  I've already sent the slides to Simon.  They should appear
shortly on the cauldron's wiki page.

Thanks

[Bug middle-end/89921] New: The dom pass does not respect size of an 'asm' when duplicating BBs

[vlad at ispras dot ru]

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

Bug ID: 89921
   Summary: The dom pass does not respect size of an 'asm' when
duplicating BBs
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vlad at ispras dot ru
  Target Milestone: ---

// sizeof-asm-dom.c:

#define LARGE_ASM "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
\
"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
\
"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
\
"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
\
"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
\
"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
\
"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
\
"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
\
"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
\
"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
\
"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
\
"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
\
"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"

extern unsigned bar (void);

unsigned foo (unsigned v)
{
  unsigned u;
  unsigned o;
  if (v > 10)
u = bar ();

  asm (LARGE_ASM:"=g"(o)::); // a non-volatile asm.

  if (v < 5)
return u;

  return 0;
}

// EOF

gcc -O -fdump-tree-dom -c sizeof-asm-dom.c
grep asm sizeof-asm*dom2 | wc -l

This yields 2, i.e. the large asm has been duplicated.

My understanding (without having read the actual code of the dom pass) is that
the dom pass relies on a cost model to decide whether to perform the
duplication
(inserting a simple loop in place of the asm prevents it).  Also, at some point
GCC computes an estimate of inline asm sizes based on the number of
instructions
they contain (as per "Size of an 'asm'" section of the manual).  It seems, the
dom pass could use that information to avoid bloating the resulting code.

Is it just an unimplemented thing that needs fixing?

[Bug tree-optimization/90394] [10 Regression] ICE in is_value_included_in, at tree-ssa-uninit.c:1055

[vlad at ispras dot ru]

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

--- Comment #6 from Vladislav Ivanishin  ---
(In reply to Richard Biener from comment #2)
> Vlad, likely caused by your change - can you investigate please?

Sure, I'll investigate and report back next week (we're on national holidays
until Monday).

[Bug c++/91011] g++ -Q --help=warning,c++ outputs from C point of view

[vlad at ispras dot ru]

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

Vladislav Ivanishin  changed:

   What|Removed |Added

 CC||vlad at ispras dot ru

--- Comment #1 from Vladislav Ivanishin  ---
(In reply to Adam Badura from comment #0)

> Is there any workaround for versions older than trunk?

Using the executable for the appropriate language frontend directly:

`gcc --print-file-name cc1plus`  -Wnon-virtual-dtor --help=warning,c++

(I think, --print-file-name is the portable way to get the path, but I see that
it is only documented to work for libraries:

'-print-file-name=LIBRARY'
 Print the full absolute name of the library file LIBRARY ...)

[Bug c++/91011] g++ -Q --help=warning,c++ outputs from C point of view

[vlad at ispras dot ru]

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

--- Comment #2 from Vladislav Ivanishin  ---
I already did some debugging (Adam asked on Stackoverflow prior to opening this
PR: https://stackoverflow.com/q/56753102/2104472). Re-posting here what I've
found out.

For the trunk, the problem is that in the absence of input files, a dummy file
is always created with C extension

gcc.c:

  if (n_infiles == 0
  && (print_subprocess_help || print_help_list || print_version))
{
  /* Create a dummy input file, so that we can pass
 the help option on to the various sub-processes.  */
  add_infile ("help-dummy", "c");
}

consequently, cc1 is called:

driver::do_spec_on_infiles () const
{
  ...
  for (i = 0; (int) i < n_infiles; i++)
{
  ...
  /* Figure out which compiler from the file's suffix.  */

  input_file_compiler
= lookup_compiler (infiles[i].name, input_filename_length,
   infiles[i].language);

  if (input_file_compiler)
{
  ...
  value = do_spec (input_file_compiler->spec);

[Bug lto/87076] New: -mpcu/-march not propagated through LTO bytecode (ice/segfault if arch flags do not match)

[vlad at ispras dot ru]

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

Bug ID: 87076
   Summary: -mpcu/-march not propagated through LTO bytecode
(ice/segfault if arch flags do not match)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vlad at ispras dot ru
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

# run.sh:

cat << EOF > 1.c
typedef int i1 __attribute__((aligned(1)));
int f(i1 *p)
{
  return *p;
}
EOF

# base=/usr/lib/gcc/arm-none-eabi/8.2.0/

case $1 in
ice|"")
$base/cc1 1.c -march=armv7-r -mthumb -flto
arm-none-eabi-as 1.s -o 1.o
# Next line yields a warning. Also note Tag_CPU_unaligned_access in 2.s
$base/lto1 -munaligned-access -fverbose-asm 1.o -o 2.s
;;
segfault)
$base/cc1 1.c -mthumb -flto
arm-none-eabi-as 1.s -o 1.o
$base/lto1 -march=armv7-r 1.o
;;
esac

# end of run.sh

FWIW, having -mcpu=cortex-r4 in place of -march=armv7-r in this script doesn't
change anything.

$ ./run.sh ice

Looks like it has always given the

 warning: target CPU does not support unaligned accesses

(I tested on gcc-{5,6,7,8,trunk}.) 

This is because -march=armv7-r (which would cause unaligned_access to be set)
is not visible in lto1 -- it seems neither -march/-mcpu, nor
Tag_CPU_unaligned_access is serialized.

Also, since r231114 -- gcc-6 and above -- lto1 throws an ICE:

1.c: In function 'f':
1.c:5:1: internal compiler error: output_operand: invalid %-code
 }
 ^
0x89b17a output_operand_lossage(char const*, ...)
/mnt/co/gcc/gcc/final.c:3409
0x89bcdb output_asm_insn(char const*, rtx_def**)
/mnt/co/gcc/gcc/final.c:3774
0x89a796 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/mnt/co/gcc/gcc/final.c:3015
0x898a44 final(rtx_insn*, _IO_FILE*, int)
/mnt/co/gcc/gcc/final.c:2045
0x89d237 rest_of_handle_final
/mnt/co/gcc/gcc/final.c:4441
0x89d436 execute
/mnt/co/gcc/gcc/final.c:4516

Probably because this 
-  if (unaligned_access)
-builtin_define ("__ARM_FEATURE_UNALIGNED");
+  def_or_undef_macro (pfile, "__ARM_FEATURE_UNALIGNED", unaligned_access);
changed the semantics: it used to only define, now it also undefs the macro.
But it only made the underlying problem surface.

$ ./run.sh segfault

segfaults with gcc-8 and trunk:

In function 'f':
lto1: internal compiler error: Segmentation fault
0xec8f1c crash_signal
/mnt/co/gcc/gcc/toplev.c:325
0x1aa3dca arm_parse_arch_option_name(arch_option const*, char const*, char
const*, bool)
/mnt/co/gcc/gcc/common/config/arm/arm-common.c:394
0x133e85c arm_configure_build_target(arm_build_target*, cl_target_option*,
gcc_options*, bool)
/mnt/co/gcc/gcc/config/arm/arm.c:3123
0x133e3dd arm_option_restore
/mnt/co/gcc/gcc/config/arm/arm.c:2989
0xd7328e cl_target_option_restore(gcc_options*, cl_target_option*)
/mnt/bld/gcc-trunk-arm/gcc-gomp-host/gcc/options-save.c:3749
0x138ddec arm_set_current_function
/mnt/co/gcc/gcc/config/arm/arm.c:30609
0xaa339d invoke_set_current_function_hook
/mnt/co/gcc/gcc/function.c:4616
0xaa36d1 allocate_struct_function(tree_node*, bool)
/mnt/co/gcc/gcc/function.c:4729
0xaa39d8 push_struct_function(tree_node*)
/mnt/co/gcc/gcc/function.c:4792
0xccbbbd input_function
/mnt/co/gcc/gcc/lto-streamer-in.c:1065
0xccc668 lto_read_body_or_constructor
/mnt/co/gcc/gcc/lto-streamer-in.c:1295
0xccc97c lto_input_function_body(lto_file_decl_data*, cgraph_node*, char
const*)
/mnt/co/gcc/gcc/lto-streamer-in.c:1343
0x8d1084 cgraph_node::get_untransformed_body()
/mnt/co/gcc/gcc/cgraph.c:3548
0x8de11b cgraph_node::expand()
/mnt/co/gcc/gcc/cgraphunit.c:2091
0x8ded39 output_in_order
/mnt/co/gcc/gcc/cgraphunit.c:2365
0x8df479 symbol_table::compile()
/mnt/co/gcc/gcc/cgraphunit.c:2609
0x7ee5d3 lto_main()
/mnt/co/gcc/gcc/lto/lto.c:3428

Of course, none of this happens if the user specifies same arch flags for lto1
as they did for cc1. But my understanding is that

a. the compiler should not segfault;
b. it could store this information in the bytecode as it does for other
function attributes. And it probably should: consider what happens if we
specify __attribute__ ((__target__ ("arch=armv7-r"))) for f [for some reason,
this feature doesn't work for me without LTO either, but that's a separate
issue], or what happens if different TUs were compiled with different -march's;
c. from the usability standpoint, this would allow the lazy user to forget to
specify the flags for LTO link and still have the correct ones deduced for
them.

[Bug target/87076] -mpcu/-march not propagated through LTO bytecode (ice/segfault if arch flags do not match)

[vlad at ispras dot ru]

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

--- Comment #4 from Vladislav Ivanishin  ---
"rguenth at gcc dot gnu.org"  writes:

> On x86_64 the actual -march switch isn't serialized but it is decomposed into
> individual -mFEATURE switches by the driver which are serialized.
>
>
> The -march switch also appears in the lto_opts LTO section and should be
> handed off to the linker by lto-wrapper as well.
>
> You can check that by looking at -v output of the link command and/or
> looking at the lto_opts section in the object files.

Indeed, the -march switch makes it into .gnu.lto_.opts.  However, when
lto-wrapper constructs the argument string in run_gcc(), it takes those
options (append_compiler_options()) and then appends the contents of
COLLECT_GCC_OPTIONS (append_linker_options()) to them.
COLLECT_GCC_OPTIONS is set by the topmost gcc driver to

... -mcpu=arm7tdmi -marm -march=armv4t

(these options come from evaluation of the DRIVER_SELF_SPECS spec
string).

So the LTO compiler is then invoked with something like

... -march=armv7-r  ... -mcpu=arm7tdmi -marm -march=armv4t

The last -march takes effect.  The ARM backend seems to infer -mFEATUREs
from -mcpu and -march rather than trying to deserialize from the file.
I drew this conclusion from looking at

gcc/config/arm/arm.c: arm_configure_build_target():
  ...
  if (arm_selected_arch)
  {
  arm_initialize_isa (target->isa, arm_selected_arch->common.isa_bits);
  ...
  if (arm_selected_cpu)
  {
  arm_initialize_isa (cpu_isa, arm_selected_cpu->common.isa_bits);