[Bug target/82820] [arm32]ldm/stm instructions Bus error while running with 64bit kernel

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
ldm/stm should not be used with unaligned memory.  Yes it was emulated when
using the arm kernel but the arm64 kernel does not emulate them.

[Bug c/82820] New: [arm32]ldm/stm instructions Bus error on AARCH64

[zwzhangwen.zhang at huawei dot com]

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

Bug ID: 82820
   Summary: [arm32]ldm/stm instructions Bus error on AARCH64
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zwzhangwen.zhang at huawei dot com
  Target Milestone: ---

[Bug target/82788] wrong code with -fstack-clash-protection --param=stack-clash-protection-probe-interval=10 on simple code

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-03
  Component|tree-optimization   |target
 Ever confirmed|0   |1

[Bug target/82820] [arm32]ldm/stm instructions Bus error while running with 64bit kernel

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Andrew Pinski  ---
>B *pb = (B *)(buf + 1);

You are causing pb to be unaligned so this code is undefined which is why it
crashes on arm32 while running on the arm64 kernel.

[Bug target/82820] [arm32]ldm/stm instructions Bus error while running with 64bit kernel

[zwzhangwen.zhang at huawei dot com]

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

--- Comment #2 from zwzhangwen.zhang at huawei dot com ---
Hi,
   I have a testcase for example:
typedef struct structA{
int a;
int b;
int c;
}A;

typedef struct structB{
int iData;
A a;
}B;

int test(A aa)
{
aa.a = 123;
aa.b = 321;
aa.c = 213;
printf("\r\n line:%d func:%s [%d][%d][%d]\r\n", __LINE__, __FUNCTION__,
aa.a, aa.b, aa.c);
}

int main()
{
char buf[1024];
A aaa = {1,2,3};

B *pb = (B *)(buf + 1);
pb->a = aaa;
test(pb->a);
return 0;
}
compiling with the command "arm32-linux-gnueabi-gcc -O0 test.c "
Then objdump assemble is as follows:
...
85ac:   e51b3008ldr r3, [fp, #-8]
85b0:   e2833004add r3, r3, #4
85b4:   e24b2e41sub r2, fp, #1040   ; 0x410
85b8:   e2422004sub r2, r2, #4
85bc:   e8920007ldm r2, {r0, r1, r2}
85c0:   e8830007stm r3, {r0, r1, r2}
85c4:   e51b3008ldr r3, [fp, #-8]
85c8:   e2833004add r3, r3, #4
85cc:   e8930007ldm r3, {r0, r1, r2}
85d0:   ebcdbl  850c 
...
pb->a is unaligned access but inst. is ldm/stm  and this is a prolem.
The other problem is the elf has bus error on arm64 env,
So anybody help me?
Thank you.

[Bug c++/82818] Bad Codegen, delete does not check for nullptrs

[dark_sylinc at yahoo dot com.ar]

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

--- Comment #2 from dark_sylinc at yahoo dot com.ar ---
Created attachment 42540
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42540=edit
Workaround. Uncomment "//a.~FastArray();" to make the crash come back

[Bug c++/82818] Bad Codegen, delete does not check for nullptrs

[dark_sylinc at yahoo dot com.ar]

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

--- Comment #1 from dark_sylinc at yahoo dot com.ar ---
Update:

1. Confirmed to be broken with gcc 7.2
2. When I said fsanitize; I meant fsanitize=undefined
3. When code is slightly modified as in the new attachment, the crash is gone.
But it appears again if after calling a.destroy(); we add a.~FastArray();

[Bug tree-optimization/82819] New: [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

[asolokha at gmx dot com]

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

Bug ID: 82819
   Summary: [8 Regression] [graphite] ICE in set_codegen_error, at
graphite-isl-ast-to-gimple.c:206
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu*, powerpcspe-*-linux-gnu*

gcc-8.0.0-alpha20171029 snapshot (r254205) ICEs when compiling the following
snippet w/ -O2 (-O3, -Ofast) -floop-nest-optimize for 32-bit BE powerpc target:

short int *ts;

void
c2 (unsigned long long int s4, int ns)
{
  short int *b2 = (short int *)

  while (ns != 0)
{
  int xn;

  for (xn = 0; xn < 3; ++xn)
for (*b2 = 0; *b2 < 2; ++*b2)
  s4 += xn;
  if (s4 != 0)
b2 = ts;
  ++ns;
}
}

% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20171029 -O2 -floop-nest-optimize -c
culmj2ad.c 
during GIMPLE pass: graphite
culmj2ad.c: In function 'c2':
culmj2ad.c:4:1: internal compiler error: in set_codegen_error, at
graphite-isl-ast-to-gimple.c:206
 c2 (unsigned long long int s4, int ns)
 ^~
0x5bb486 translate_isl_ast_to_gimple::set_codegen_error()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171029/work/gcc-8-20171029/gcc/graphite-isl-ast-to-gimple.c:205
0x13c02b5 translate_isl_ast_to_gimple::set_codegen_error()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171029/work/gcc-8-20171029/gcc/graphite-isl-ast-to-gimple.c:311
0x13c02b5
translate_isl_ast_to_gimple::gcc_expression_from_isl_expr_int(tree_node*,
isl_ast_expr*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171029/work/gcc-8-20171029/gcc/graphite-isl-ast-to-gimple.c:308
0x13c04b4 translate_isl_ast_to_gimple::binary_op_to_tree(tree_node*,
isl_ast_expr*, std::map,
std::allocator > >&)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171029/work/gcc-8-20171029/gcc/graphite-isl-ast-to-gimple.c:338
0x13c04b4 translate_isl_ast_to_gimple::binary_op_to_tree(tree_node*,
isl_ast_expr*, std::map,
std::allocator > >&)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171029/work/gcc-8-20171029/gcc/graphite-isl-ast-to-gimple.c:338
0x13c047e translate_isl_ast_to_gimple::binary_op_to_tree(tree_node*,
isl_ast_expr*, std::map,
std::allocator > >&)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171029/work/gcc-8-20171029/gcc/graphite-isl-ast-to-gimple.c:322
0x13c1123 translate_isl_ast_to_gimple::graphite_create_new_guard(edge_def*,
isl_ast_expr*, std::map,
std::allocator > >&)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171029/work/gcc-8-20171029/gcc/graphite-isl-ast-to-gimple.c:845
0x13c3c95 translate_isl_ast_to_gimple::translate_isl_ast_node_if(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171029/work/gcc-8-20171029/gcc/graphite-isl-ast-to-gimple.c:864
0x13c3bc5 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171029/work/gcc-8-20171029/gcc/graphite-isl-ast-to-gimple.c:831
0x13c40af graphite_regenerate_ast_isl(scop*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171029/work/gcc-8-20171029/gcc/graphite-isl-ast-to-gimple.c:1474
0x13be11d graphite_transform_loops()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171029/work/gcc-8-20171029/gcc/graphite.c:384
0x13bf8af graphite_transforms
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171029/work/gcc-8-20171029/gcc/graphite.c:447
0x13bf8af execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171029/work/gcc-8-20171029/gcc/graphite.c:524

I doubt it's target-specific, though.

[Bug c++/82818] New: Bad Codegen, delete does not check for nullptrs

[dark_sylinc at yahoo dot com.ar]

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

Bug ID: 82818
   Summary: Bad Codegen, delete does not check for nullptrs
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dark_sylinc at yahoo dot com.ar
  Target Milestone: ---

Created attachment 42539
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42539=edit
Simple repro of the problem

The attached file, when compiled and run with the following:
c++ -std=c++11 -Wall -Wextra -O2 -g -DNDEBUG -fno-strict-aliasing main.cpp

will crash complaining about a double free; even though:
 * operator delete is guaranteed to check for nullptrs
 * There's also an explicit check for if( mData ). Trying a boolean instead
results in the same problem. The check is just left out.
 * AFAIK it is legal to call the destructor.

Problem does not reproduce without optimizations, and cannot be reproduced in
Clang or MSVC either.
It seems that GCC optimizer cannot deal with code explicitly calling the
destructor.

Info about me:
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 6.3.0-12ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170406 (Ubuntu 6.3.0-12ubuntu2)


I heard the report from another guy who has a much newer version of everything
than me; so it's very possible this problem is still present in newer versions
or even latest gcc.

Running with -fsanitize reports nothing, but the program stops crashing.

[Bug c++/81957] ICE decltype

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
   Target Milestone|--- |8.0

--- Comment #4 from Paolo Carlini  ---
Fixed.

[Bug c++/81957] ICE decltype

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri Nov  3 00:13:06 2017
New Revision: 254361

URL: https://gcc.gnu.org/viewcvs?rev=254361=gcc=rev
Log:
/cp
2017-11-02  Paolo Carlini  

PR c++/81957
* pt.c (make_pack_expansion): Add tsubst_flags_t parameter.
(expand_integer_pack, convert_template_argument, coerce_template_parms,
gen_elem_of_pack_expansion_instantiation, tsubst_pack_expansion,
unify): Adjust calls.
* tree.c (cp_build_qualified_type_real): Likewise.
* cp-tree.h (make_pack_expansion): Adjust declaration.

/testsuite
2017-11-02  Paolo Carlini  

PR c++/81957
* g++.dg/cpp0x/variadic-crash5.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-crash5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug target/79868] aarch64: diagnostic "malformed target %s value" not translateable

[sje at gcc dot gnu.org]

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

--- Comment #10 from Steve Ellcey  ---
Author: sje
Date: Thu Nov  2 21:58:05 2017
New Revision: 254360

URL: https://gcc.gnu.org/viewcvs?rev=254360=gcc=rev
Log:
PR target/79868
* gcc.target/aarch64/spellcheck_1.c: Update dg-error string to match
new format.
* gcc.target/aarch64/spellcheck_2.c: Ditto.
* gcc.target/aarch64/spellcheck_3.c: Ditto.
* gcc.target/aarch64/target_attr_11.c: Ditto.
* gcc.target/aarch64/target_attr_12.c: Ditto.
* gcc.target/aarch64/target_attr_17.c: Ditto.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/spellcheck_1.c
trunk/gcc/testsuite/gcc.target/aarch64/spellcheck_2.c
trunk/gcc/testsuite/gcc.target/aarch64/spellcheck_3.c
trunk/gcc/testsuite/gcc.target/aarch64/target_attr_11.c
trunk/gcc/testsuite/gcc.target/aarch64/target_attr_12.c
trunk/gcc/testsuite/gcc.target/aarch64/target_attr_17.c

[Bug target/79868] aarch64: diagnostic "malformed target %s value" not translateable

[sje at gcc dot gnu.org]

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

--- Comment #9 from Steve Ellcey  ---
Author: sje
Date: Thu Nov  2 21:56:00 2017
New Revision: 254359

URL: https://gcc.gnu.org/viewcvs?rev=254359=gcc=rev
Log:
PR target/79868
* config/aarch64/aarch64-c.c (aarch64_pragma_target_parse):
Remove second argument from aarch64_process_target_attr call.
* config/aarch64/aarch64-protos.h (aarch64_process_target_attr):
Ditto.
* config/aarch64/aarch64.c (aarch64_attribute_info): Change
field type.
(aarch64_handle_attr_arch): Remove second argument.
(aarch64_handle_attr_cpu): Ditto.
(aarch64_handle_attr_tune): Ditto.
(aarch64_handle_attr_isa_flags): Ditto.
(aarch64_process_one_target_attr): Ditto.
(aarch64_process_target_attr): Ditto.
(aarch64_option_valid_attribute_p): Remove second argument.
on aarch64_process_target_attr call.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-c.c
trunk/gcc/config/aarch64/aarch64-protos.h
trunk/gcc/config/aarch64/aarch64.c

[Bug c++/70401] [c++1z on mingw]compile variadic template failed

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #1 from Paolo Carlini  ---
Can you please check gcc-7.x or current trunk? Somebody with access to mingw?
On x86_64-linux both are fine and the issue could be closed.

[Bug c++/57728] Explicit template instantiation with defaulted method causes missing symbol

[jens.maurer at gmx dot net]

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

Jens Maurer  changed:

   What|Removed |Added

 CC||jens.maurer at gmx dot net

--- Comment #13 from Jens Maurer  ---
This bug saw its last activity nearly a year ago, with patches from Jason
applied, but the issue does not seem to be fixed in its entirety (using gcc
7.2).

Specifically, this translation unit:

template
struct C {
  C() = default;
  void f() { }
  int i = 5;
};
template class C;

causes C::f() to be defined, but the defaulted constructor of C is
not defined. (Replacing "= default" with "{}" causes definition of the C
constructor.)

$ nm -C x.o
 W C::f()

The current behavior is obviously not what we want if we choose to use explicit
instantiations.

[Bug c++/82710] [8 Regression] Incorrect warning:unnecessary parentheses in declaration of global friend functions [-Werror=parentheses]

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Nathan Sidwell  ---
Fixed r254349.

[Bug other/81096] [8 regression] test case ttest in libbacktrace fails starting with its introduction in r249111

[wilco at gcc dot gnu.org]

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

--- Comment #7 from Wilco  ---
Is this now fixed on PPC too? If so, it can be closed.

[Bug c++/82710] [8 Regression] Incorrect warning:unnecessary parentheses in declaration of global friend functions [-Werror=parentheses]

[nathan at gcc dot gnu.org]

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

--- Comment #5 from Nathan Sidwell  ---
Author: nathan
Date: Thu Nov  2 18:26:29 2017
New Revision: 254349

URL: https://gcc.gnu.org/viewcvs?rev=254349=gcc=rev
Log:
[PR c++/82710] false positive paren warning

https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00119.html
PR c++/82710
* decl.c (grokdeclarator): Don't warn when parens protect a return
type from a qualified name.

PR c++/82710
* g++.dg/warn/pr82710.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/pr82710.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c/82817] New: C frontend errors on SSA name from REG_EXPR

[thopre01 at gcc dot gnu.org]

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

Bug ID: 82817
   Summary: C frontend errors on SSA name from REG_EXPR
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42538
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42538=edit
unparsable RTL

Hi,

when parsing a __RTL function with expression containing a SSA name of a local
variable (of the form ._, the C parser errors out because
libcpp think it is a floating-point but validation remarks that it is invalid:

error: invalid suffix "_2" on floating constant
   (cinsn 11 (set (reg:SI r3 [orig:111 c.1_2 ] [111])


We could strip the REG_EXPR expression when printing RTL for the frontend via
print_rtx_function but I believe going through libcpp is wrong. Here is how we
get there:

#0  cpp_classify_number (pfile=0x25585b0, token=0x25ac998,
ud_suffix=0x7fffd7d0, 
virtual_location=166019)
at /data/dev/builds/arm-none-eabi/default/src/libcpp/expr.c:685
#1  0x008b68ab in c_lex_with_flags (value=0x7654e010,
loc=0x7654e00c, 
cpp_flags=0x7654e018 "\001", lex_flags=0)
at /data/dev/builds/arm-none-eabi/default/src/gcc/c-family/c-lex.c:415
#2  0x00817b69 in c_lex_one_token (parser=0x7654e000,
token=0x7654e008)
at /data/dev/builds/arm-none-eabi/default/src/gcc/c/c-parser.c:251
#3  0x00817fa4 in c_parser_peek_token (parser=0x7654e000)
at /data/dev/builds/arm-none-eabi/default/src/gcc/c/c-parser.c:438
#4  0x00850852 in c_parser_parse_rtl_body (parser=0x7654e000, 
start_with_pass=0x25f45f0 "shorten")
at /data/dev/builds/arm-none-eabi/default/src/gcc/c/c-parser.c:18639

Looking at the use done of c_parser_peek_token in c_parser_parse_rtl_body, I
wonder why not call a much lower level function that just reads the input file
and parse parenthesis and end of file itself. Tokenization does not seem
necessary here since all the validation for RTL is done outside the C frontend.

I've reduced manually the RTL function I had to the attached function. I'm not
sure it's valid RTL but at least the syntax should be correct. When building it
with arm-none-eabi-gcc -c -march=armv7e-m -mfloat-abi=hard -mfpu=fpv5-sp-d16
one gets the following errors:

prx.c: In function 'fn1':
prx.c:14:44: error: invalid suffix "_2" on floating constant
   (cinsn 11 (set (reg:SI r3 [orig:111 c.1_2 ] [111])
^~~~
prx.c:12:56: error: expected character `[', found `)'
prx.c:12:85: note: following context is ` [0  S4 A32])) "testcase.c":7'

[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)

[yyc1992 at gmail dot com]

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

--- Comment #7 from Yichao Yu  ---
It would be great if `+crc` can work if it's not ambiguous. Requiring
`arch=armv8-a+crc` works for me too, and it'll just require more preprocessor
checks.

[Bug ada/82813] warning: '.builtin_memcpy' writing between 2 and 6 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
> The warning will go away once pr80545 is fixed but I wonder if a better
> (independent) solution in this case is to detect that the code is, in fact,
> unreachable, and avoid emitting it to begin with.

Yes, it's a missed optimization at the GIMPLE level.

> Alternatively, if it is too hard to determine that it's unreachable, it should
> be possible to detect that the memcpy call is invalid earlier and replace it 
> with either __builtin_unreachable or __builtin_trap.

Possibly, 121t.phicprop1 has:

  S117b.276_245 = .builtin_alloca_with_align (0, 8);
  # DEBUG S117b.276 => S117b.276_245
  _46 = (sizetype) j_231;
  _48 = &*sw.246_6[1 ...]{lb: 1 sz: 1};
  _49 = &*S117b.276_245[1 ...]{lb: 1 sz: 1};
  .builtin_memcpy (_49, _48, _46);

[Bug rtl-optimization/82803] Wildly excessive calls to __tls_get_addr with optimizations enabled.

[amohr at amohr dot org]

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

--- Comment #3 from Alex Mohr  ---
FWIW a loop is not required.  This generates 4 calls to __tls_get_addr:

static thread_local int x;
int g();
int f() {
  int *px = 
  if (g()) *px += g();
  if (g()) *px += g();
  if (g()) *px += g();
  return *px;
}

[Bug ada/82813] warning: '.builtin_memcpy' writing between 2 and 6 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Depends on||80545

--- Comment #3 from Martin Sebor  ---
The warning will go away once pr80545 is fixed but I wonder if a better
(independent) solution in this case is to detect that the code is, in fact,
unreachable, and avoid emitting it to begin with.  Alternatively, if it is too
hard to determine that it's unreachable, it should be possible to detect that
the memcpy call is invalid earlier and replace it with either
__builtin_unreachable or __builtin_trap.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80545
[Bug 80545] option -Wstringop-overflow not recognized by Fortran

[Bug tree-optimization/82788] wrong code with -fstack-clash-protection --param=stack-clash-protection-probe-interval=10 on simple code

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Assignee|unassigned at gcc dot gnu.org  |law at redhat dot com

--- Comment #1 from Jeffrey A. Law  ---
Sigh.  Yet more evidence that user-configurable probing intervals is probably a
bad idea...

[Bug tree-optimization/82816] New: ICE on valid code at -Os and above: in find_widening_optab_handler_and_mode, at optabs-query.c:414

[su at cs dot ucdavis.edu]

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

Bug ID: 82816
   Summary: ICE on valid code at -Os and above: in
find_widening_optab_handler_and_mode, at
optabs-query.c:414
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This appears to be a recent regression. 

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20171102 (experimental) [trunk revision 254338] (GCC) 
$ 
$ gcctk -O1 -c small.c
$ gcc-7.2.0 -Os -c small.c
$ 
$ gcctk -Os -c small.c
during GIMPLE pass: widening_mul
small.c: In function ‘f’:
small.c:8:6: internal compiler error: in find_widening_optab_handler_and_mode,
at optabs-query.c:414
 void f ()
  ^
0xb749b8 find_widening_optab_handler_and_mode(optab_tag, machine_mode,
machine_mode, machine_mode*)
../../gcc-source-trunk/gcc/optabs-query.c:414
0xe0b484 insn_code
find_widening_optab_handler_and_mode(optab_tag,
scalar_int_mode const&, scalar_int_mode const&, scalar_int_mode*)
../../gcc-source-trunk/gcc/optabs-query.h:201
0xe0b484 convert_mult_to_widen
../../gcc-source-trunk/gcc/tree-ssa-math-opts.c:3273
0xe0f29f execute
../../gcc-source-trunk/gcc/tree-ssa-math-opts.c:4205
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.
$ 


--


struct A
{
  int b:3;
} d, e;

int c;

void f ()
{
  char g = d.b * e.b;
  c = g;
}

[Bug middle-end/82815] New: RTL frontend errors out on const_double

[thopre01 at gcc dot gnu.org]

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

Bug ID: 82815
   Summary: RTL frontend errors out on const_double
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42537
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42537=edit
Testcase showing bug in read_rtx_operand

read_rtx_operand in read-rtl.c assumes that a format starting with w is an
integer but this can also be a const_double (see real.h). It then tries to
validate the integer constant which fails and errors out with:

error: invalid decimal constant "1.0e+0"

The attached testcase shows the bug when compiled with:

arm-none-eabi-gcc -S foo.c -march=armv7e-m -mfloat-abi=hard -mfpu=fpv5-d16
testcase_read-rtl.c

The RTL is generated from:

double foo (void)
{
  return 1.0;
}

and dumped from arm_reorg. Similar procedure on other targets should lead to
the error as well.

[Bug target/82812] ICE in emit_move_insn, at expr.c:3706

[jkoval at gcc dot gnu.org]

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

jkoval at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jkoval at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jkoval at gcc dot 
gnu.org

--- Comment #1 from jkoval at gcc dot gnu.org ---
This happens, because there were no flags for SSE/AVX requirement in
i386-builtin.def for GFNI. I will fix it soon.

[Bug ada/82813] warning: '.builtin_memcpy' writing between 2 and 6 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]

[ebotcazou at gcc dot gnu.org]

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

--- Comment #2 from Eric Botcazou  ---
It's unreachable code:

   [0.23%] [count: INV]:
  # DEBUG S117b.276 => 
  .builtin_memcpy ([(void *)], pretmp_305, _250);

The only predecessor is:

   [0.32%] [count: INV]:
  L113b_224 = start_130 + _322;
  # DEBUG L114b => 1
  # DEBUG make_util__ensure_absolute_path__B_4__L_5__TTS117bSP1___L => 1
  # DEBUG make_util__ensure_absolute_path__B_4__L_5__TTS117bSP1___U =>
L113b_224
  # DEBUG D.7306 => 1
  # DEBUG iftmp.271 => 1 + 18446744073709551615
  if (L113b_224 != 0)
goto ; [64.00%]
  else
goto ; [36.00%]

whose only predecessor is:

   [0.63%] [count: INV]:
  _37 = parent$P_BOUNDS_1->UB0;
  _38 = parent$P_BOUNDS_1->LB0;
  _330 = iftmp.245_24 - start_130;
  _322 = _330 + 1;
  _250 = (sizetype) j_231;
  pretmp_305 = [(void *)sw.246_6][1 ...]{lb: 1 sz: 1};
  if (_37 >= _38)
goto ; [50.00%]
  else
goto ; [50.00%]

So  is reachable only if parent$P_BOUNDS_1->UB0 < parent$P_BOUNDS_1->LB0
is true.

But this condition is caught by the block just above:

  if Parent'Length = 0 then
 Do_Fail
   ("relative search path switches ("""
& Sw
& """) are not allowed");

   [7.26%] [count: INV]:
  _19 = parent$P_BOUNDS_1->LB0;
  _20 = parent$P_BOUNDS_1->UB0;
  if (_19 > _20)
goto ; [33.00%]
  else
goto ; [67.00%]

 is a dominator of  so  is reachable only if
parent$P_BOUNDS_1->LB0 > parent$P_BOUNDS_1->UB0 is false, which is the opposite
of the above condition, so  is not reachable.

[Bug ada/82813] warning: '.builtin_memcpy' writing between 2 and 6 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-02
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
I can reproduce.

[Bug fortran/82814] New: ICE from submodule character function

[werner.blokbuster at gmail dot com]

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

Bug ID: 82814
   Summary: ICE from submodule character function
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: werner.blokbuster at gmail dot com
  Target Milestone: ---

The following program gives an ICE with gfortran 7.2.0 and 6.4.0. Unfortunately
I do not have version 8 to test.


module u

implicit none

interface unique
module function uniq_char(input) result(uniq)
character(*), intent(in) :: input(:)
character(size(input)), allocatable :: uniq(:)
end function uniq_char
end interface unique

end module u


submodule (u) z

implicit none

contains

module function uniq_char(input) result(uniq)
character(*), intent(in) :: input(:)
character(size(input)), allocatable :: uniq(:)
allocate(uniq(1))
uniq = 'A'
end function uniq_char

end submodule z


program test_uniq
use u, only: unique
implicit none

write(*,*) unique(['1','2','1','2'])

end program test_uniq

ICE:

test_uniq.f:27:0:

 allocate(uniq(1))

internal compiler error: Segmentation fault: 11

test_uniq.f:27:0: internal compiler error: Abort trap: 6


The program compiles and runs if any of:

- character variables are replaced with integer or real variables;
- the submodule is not used and the function is placed within module u;
- the variable 'uniq' is given a fixed length, e.g. character(1).

I'm running on a macbook 10.12.6 using gfortran from macports.

WB

[Bug ipa/82808] [7/8 Regression] LTO clone wrong value

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
(In reply to Richard Biener from comment #7)
> ipa_get_jf_pass_through_result has multiple issues:
> 
> static tree
> ipa_get_jf_pass_through_result (struct ipa_jump_func *jfunc, tree input)
> {
>   tree restype, res;
> 
>   if (ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
> return input;
> 
> we may miss a truncation here (and should check for CONVERT_EXPR_CODE_P).

I admit this is confusing but no.  Until gcc7 we had two kinds of
pass-through jump functions, binary and really_no_operation_at_all.
NOP_EXPR was used to mark that more simple case and still is.
However, despite having unary pass-through jump functions now, we
never construct those with if the operation would be a
CONVERT_EXPR_CODE_P.  Maybe we should use ERROR_MARK or something
instead of NOP_EXPR.

> 
>   if (!is_gimple_ip_invariant (input))
> return NULL_TREE;
> 
>   if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
>   == tcc_unary)
> res = fold_unary (ipa_get_jf_pass_through_operation (jfunc),
>   TREE_TYPE (input), input);
> 
> the bug here is that the operation is type-changing but we use the
> type of the input(!) rather than the type of the output when computing
> the result.  I suppose the output is the type of the current formal
> parameter -- is that available somehow?

The output in the original IL was the actual argument, at IPA level we
generally assume that it is compatible with the callee formal
argument.  That type is now available from the new parameter that
Prathamesh is adding with his patch, but he does not pass them from
all callers.  If the type is required for more than a bunch of
not-likely-important operations, we should try harder and provide it
from everywhere (possibly incrementally).

> 
>   else
> {
>   if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
>   == tcc_comparison)
> restype = boolean_type_node;
>   else
> restype = TREE_TYPE (input);
> 
> same issue for operations like widen_sum_expr but of course less likely
> to hit us here.
> 
>   res = fold_binary (ipa_get_jf_pass_through_operation (jfunc), restype,
>  input, ipa_get_jf_pass_through_operand (jfunc));
> }
>   if (res && !is_gimple_ip_invariant (res))
> return NULL_TREE;
> 
> 
> I think the immediate thing to do is make the list of handled expression
> codes explicit - thus change the tree-code-class checks to
> 
> switch (code)
>  {
>  case handled-unary:
>   fold_unary...
> 
>  case handled-comparison:
>   ...
> 
>  etc.
> 
> or somehow properly get the jf "target" type.

Nowadays it should be possible to do the latter (but people always
frown when I introduce more type handling to WPA, so I would not
necessarily object to the former either).

[Bug ipa/82808] [7/8 Regression] LTO clone wrong value

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
ipa_get_jf_pass_through_result has multiple issues:

static tree
ipa_get_jf_pass_through_result (struct ipa_jump_func *jfunc, tree input)
{
  tree restype, res;

  if (ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
return input;

we may miss a truncation here (and should check for CONVERT_EXPR_CODE_P).

  if (!is_gimple_ip_invariant (input))
return NULL_TREE;

  if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
  == tcc_unary)
res = fold_unary (ipa_get_jf_pass_through_operation (jfunc),
  TREE_TYPE (input), input);

the bug here is that the operation is type-changing but we use the
type of the input(!) rather than the type of the output when computing
the result.  I suppose the output is the type of the current formal
parameter -- is that available somehow?

  else
{
  if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
  == tcc_comparison)
restype = boolean_type_node;
  else
restype = TREE_TYPE (input);

same issue for operations like widen_sum_expr but of course less likely
to hit us here.

  res = fold_binary (ipa_get_jf_pass_through_operation (jfunc), restype,
 input, ipa_get_jf_pass_through_operand (jfunc));
}
  if (res && !is_gimple_ip_invariant (res))
return NULL_TREE;


I think the immediate thing to do is make the list of handled expression
codes explicit - thus change the tree-code-class checks to

switch (code)
 {
 case handled-unary:
  fold_unary...

 case handled-comparison:
  ...

 etc.

or somehow properly get the jf "target" type.

[Bug ada/82813] New: warning: '.builtin_memcpy' writing between 2 and 6 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]

[marxin at gcc dot gnu.org]

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

Bug ID: 82813
   Summary: warning: '.builtin_memcpy' writing between 2 and 6
bytes into a region of size 0 overflows the
destination [-Wstringop-overflow=]
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: charlet at gcc dot gnu.org, msebor at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42536
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42536=edit
optimized tree dump

Hello.

Not being sure whether it's real issue or false positive:

   214elsif Including_RTS then
   215   for J in Start .. Sw'Last loop
   216  if Sw (J) = Directory_Separator then
   217 Switch :=
   218   new String'
   219 (Sw (1 .. Start - 1)
   220  & Parent
   221  & Directory_Separator
   222  & Sw (Start .. Sw'Last));
   223 return;
   224  end if;
   225   end loop;

Optimized dump is in attachment.

[Bug target/82795] [8 Regression] ICE in predicate_mem_writes, at tree-if-conv.c:2251

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug ipa/82808] [7/8 Regression] LTO clone wrong value

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #6 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Martin Jambor from comment #5)
> (In reply to prathamesh3492 from comment #4)
> > Created attachment 42535 [details]
> > Untested fix
> > 
> 
> > Hi,
> > The issue here for propagating value of 'm' from f_c1 to foo() is that the
> > jump function operation is FLOAT_EXPR, and the type of input param 'm' is
> > int, so fold_unary() doesn't do the conversion to real_type.
> 
> Thanks a lot for the quick the analysis.
> 
> > The attached
> > patch fixes that by calling fold_convert if operation is FLOAT_EXPR and
> > converts it to the type of corresponding parameter in callee.
> > Does this look in the right direction ?
> 
> > --- a/gcc/ipa-cp.c  
> > +++ a/gcc/ipa-cp.c  
> > @@ -1233,7 +1234,13 @@ ipa_get_jf_pass_through_result (struct
> > ipa_jump_func *j> func, tree input)
> >if (!is_gimple_ip_invariant (input))
> >  return NULL_TREE;
> >  
> > -  if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
> > +  if (parm_type &&
> > +  ipa_get_jf_pass_through_operation (jfunc) == FLOAT_EXPR)
> > +{
> > +  res = fold_convert (parm_type, input);
> > +  restype = parm_type;
> > +}
> > +  else if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
> 
> I don't think it is correct to make parm_type a parameter with NULL
> default value and then only handle FLOAT_EXPR safely when it arrives
> through paths that actually provide a non-NULL value.
> 
> So either we should just always return NULL for FLOAT_EXPR operation
> or return NULL_TREE when operation is FLOAT_EXPR and param_tree is
> NULL (or provide the type from all callers but I can see that might be
> a bit painful).
Indeed, I will modify the patch to return NULL_TREE when operation is
FLOAT_EXPR and parm_type is NULL.
> 
> DO I assume correctly that we have the same problem with
> FIX_TRUNC_EXPR too?
I suppose yes, I will add case for FIX_TRUNC_EXPR in the patch. I am not sure
though how to write a C test-case for generating FIX_TRUNC_EXPR ?

Thanks,
Prathamesh

[Bug ipa/82808] [7/8 Regression] LTO clone wrong value

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  ---
(In reply to prathamesh3492 from comment #4)
> Created attachment 42535 [details]
> Untested fix
> 

> Hi,
> The issue here for propagating value of 'm' from f_c1 to foo() is that the
> jump function operation is FLOAT_EXPR, and the type of input param 'm' is
> int, so fold_unary() doesn't do the conversion to real_type.

Thanks a lot for the quick the analysis.

> The attached
> patch fixes that by calling fold_convert if operation is FLOAT_EXPR and
> converts it to the type of corresponding parameter in callee.
> Does this look in the right direction ?

> --- a/gcc/ipa-cp.c
> +++ a/gcc/ipa-cp.c
> @@ -1233,7 +1234,13 @@ ipa_get_jf_pass_through_result (struct
> ipa_jump_func *j> func, tree input)
>if (!is_gimple_ip_invariant (input))
>  return NULL_TREE;
>  
> -  if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
> +  if (parm_type &&
> +  ipa_get_jf_pass_through_operation (jfunc) == FLOAT_EXPR)
> +{
> +  res = fold_convert (parm_type, input);
> +  restype = parm_type;
> +}
> +  else if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))

I don't think it is correct to make parm_type a parameter with NULL
default value and then only handle FLOAT_EXPR safely when it arrives
through paths that actually provide a non-NULL value.

So either we should just always return NULL for FLOAT_EXPR operation
or return NULL_TREE when operation is FLOAT_EXPR and param_tree is
NULL (or provide the type from all callers but I can see that might be
a bit painful).

DO I assume correctly that we have the same problem with
FIX_TRUNC_EXPR too?

[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)

[rearnsha at gcc dot gnu.org]

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

--- Comment #6 from Richard Earnshaw  ---
(In reply to Tamar Christina from comment #5)
> My patch adds support for 
> 
> 
> ```
> #pragma GCC push_options
> #pragma GCC target("arch=armv8-a+crc")
> __attribute__((target("arch=armv8-a+crc"))) uint32_t crc32cw(uint32_t crc,
> uint32_t val)
> ```
> 
> and just
> 
> 
> ```
> #pragma GCC push_options
> #pragma GCC target("+crc")
> __attribute__((target("+crc"))) uint32_t crc32cw(uint32_t crc, uint32_t val)
> ```
> 
> if the compiler was invoked with `-march=armv8-a`.
> 
> However it currently doesn't allow
> 
> 
> ```
> #pragma GCC push_options
> #pragma GCC target("armv8-a+crc")
> __attribute__((target("armv8-a+crc"))) uint32_t crc32cw(uint32_t crc,
> uint32_t val)
> ```
> 
> as it doesn't know if you wanted to change the `fpu` or `arch` here.
> Should I support this case as well?


No, I think we should insist on an arch= or fpu= prefix for all but the adding
extensions case.

Note that extensions can only modify the existing architecture if it supports
that extension.  This is because the modifiers are context dependent: for
example the +fp extension (new in gcc-8) will enable floating-point
instructions that come with the specified architecture.

Also note that in the long-term -mfpu and pragma/attribute variants thereof are
likely to be deprecated in favour of specifying all this through the
architecture string.

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[sven.koehler at gmail dot com]

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

--- Comment #35 from Sven  ---
(In reply to Sven from comment #34)
> That is to be
> expected, hence gcc should warn about the fact, and the address of a
> (potentially) unaligned int is assigned to a regular int* pointer.

Sorry, typo:
That is to be expected, hence gcc should warn about the fact that the address
of a (potentially) unaligned int is assigned to a regular int* pointer.

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[sven.koehler at gmail dot com]

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

--- Comment #34 from Sven  ---
(In reply to H.J. Lu from comment #32)
> long long is aligned to 4 bytes in struct for i386.

Understood. So the aligned(4) was just added to explicitly restating the
alignment?

Anyhow, the two warnings added by that commit seem unrelated to this issue. The
warnings added check the alignment of variables and members in memory. When
they fall below the given threshold, a warning is issued.

This bug report however is about a different issue. Every member of a packed
struct has an alignment guarantee of 1 - no more than that. However, a regular
int* variable guarantees, when dereferenced, guarantees an alignment of 4 (on
i386 and arm, for example). So the following code should produce a warning:

struct foo
{
  int i;
} __attribute__((packed));

struct foo *x;
int *y = &(x->i);


The issue becomes more obvious with this struct:

struct foo2
{
  char c;
  int i;
} __attribute__((packed));


However, both foo and foo2 only have an alignment guarantee of at most 1, so
also the int member inside both structs has an alignment guarantee of at most
1.

As mentioned in the initial post, gcc will generate the proper machine code to
read an unaligned int (on arm for example) when using x->i directly. However,
when using *y, gcc will assume 4 byte alignment. That is to be expected, hence
gcc should warn about the fact, and the address of a (potentially) unaligned
int is assigned to a regular int* pointer.

[Bug ipa/82808] [7/8 Regression] LTO clone wrong value

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #4 from prathamesh3492 at gcc dot gnu.org ---
Created attachment 42535
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42535=edit
Untested fix

Hi,
The issue here for propagating value of 'm' from f_c1 to foo() is that the jump
function operation is FLOAT_EXPR, and the type of input param 'm' is int, so
fold_unary() doesn't do the conversion to real_type. The attached patch fixes
that by calling fold_convert if operation is FLOAT_EXPR and converts it to the
type of corresponding parameter in callee.
Does this look in the right direction ?
I will validate the patch and post upstream if there are no regressions.

Thanks,
Prathamesh

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[hjl.tools at gmail dot com]

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

--- Comment #33 from H.J. Lu  ---
[hjl@gnu-skl-1 gcc]$ cat x.c
#include 
#include 
typedef int aligned_int __attribute__((warn_if_not_aligned(4)));
int main(void)
{
struct foo {
char c;
aligned_int x;
} __attribute__((packed));
struct foo arr[2] = { { 'a', 10 }, {'b', 20 } };
int *p0 = [0].x;
int *p1 = [1].x;
printf("sizeof(struct foo) = %d\n",
   (int)sizeof(struct foo));
printf("offsetof(struct foo, c) = %d\n",
   (int)offsetof(struct foo, c));
printf("offsetof(struct foo, x) = %d\n",
   (int)offsetof(struct foo, x));
printf("arr[0].x = %d\n", arr[0].x);
printf("arr[1].x = %d\n", arr[1].x);
printf("p0 = %p\n", (void*)p0);
printf("p1 = %p\n", (void*)p1);
printf("*p0 = %d\n", *p0);
printf("*p1 = %d\n", *p1);
return 0;
}
[hjl@gnu-skl-1 gcc]$ ./xgcc -B./ -S x.c -Wall 
x.c: In function \u2018main\u2019:
x.c:9:5: warning: alignment 1 of \u2018struct foo\u2019 is less than 4
[-Wif-not-aligned]
 } __attribute__((packed));
 ^
x.c:8:14: warning: \u2018x\u2019 offset 1 in \u2018struct foo\u2019 isn't
aligned to 4 [-Wif-not-aligned]
  aligned_int x;
  ^
[hjl@gnu-skl-1 gcc]$

[Bug target/82795] [8 Regression] ICE in predicate_mem_writes, at tree-if-conv.c:2251

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Nov  2 13:13:53 2017
New Revision: 254342

URL: https://gcc.gnu.org/viewcvs?rev=254342=gcc=rev
Log:
2017-11-02  Richard Biener  

PR tree-optimization/82795
* tree-if-conv.c (predicate_mem_writes): Remove bogus assert.

* gcc.target/i386/pr82795.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr82795.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-if-conv.c

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[hjl.tools at gmail dot com]

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

--- Comment #32 from H.J. Lu  ---
(In reply to Sven from comment #31)
> https://gcc.gnu.org/viewcvs/gcc/trunk/?view=log=251180
> 
> I am reading the commit message, and the example doesn't make any sense.
> The aligned attribute is for providing additional alignment guarantees in
> addition to the types default alignment. In particular, the documentation of
> the aligned type attribute specifically states, that this attribute cannot
> decrease alignment. It can only _increase_ alignment.
> 
> In particular, aligned(4) in combination with a 64bit type makes little
> sense.

long long is aligned to 4 bytes in struct for i386.

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[sven.koehler at gmail dot com]

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

--- Comment #31 from Sven  ---
https://gcc.gnu.org/viewcvs/gcc/trunk/?view=log=251180

I am reading the commit message, and the example doesn't make any sense.
The aligned attribute is for providing additional alignment guarantees in
addition to the types default alignment. In particular, the documentation of
the aligned type attribute specifically states, that this attribute cannot
decrease alignment. It can only _increase_ alignment.

In particular, aligned(4) in combination with a 64bit type makes little sense.

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[hjl.tools at gmail dot com]

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

--- Comment #30 from H.J. Lu  ---
(In reply to Eric Gallager from comment #29)
> 
> I don't remember the exact commit number but HJ Lu added it; I added him on
> cc with my previous comment, so maybe he can explain.

It is r251180.

[Bug target/82809] [8 Regression] ICE in in ix86_vector_duplicate_value, at config/i386/i386.c:41242

[rsandifo at gcc dot gnu.org]

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Created attachment 42534
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42534=edit
Candidate fix

This patch seems to fix it.  Only lightly tested so far.

[Bug target/82809] [8 Regression] ICE in in ix86_vector_duplicate_value, at config/i386/i386.c:41242

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-02
 CC||rsandifo at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Looking.

[Bug ipa/82808] [7/8 Regression] LTO clone wrong value

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
(In reply to prathamesh3492 from comment #2)
> Works fine with -O2 -fno-inline, but aborts with -flto -O2 -fno-inline.
> Does this possibly indicate an issue with streaming ?
Oops, no. Changing the definitions to static makes the test-case abort with
-O2. Sorry for the noise.
> 
> Thanks,
> Prathamesh

[Bug ipa/82808] [7/8 Regression] LTO clone wrong value

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #2 from prathamesh3492 at gcc dot gnu.org ---
Works fine with -O2 -fno-inline, but aborts with -flto -O2 -fno-inline.
Does this possibly indicate an issue with streaming ?

Thanks,
Prathamesh

[Bug target/59865] gnu multiversion calculates wrong target

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Eric Gallager from comment #3)
> 
> I can't reproduce this bug due to my target lacking ifunc support. Someone
> with a more capable target will need to test to be able to move this bug out
> of WAITING.

Now that I have access to the gcc compile farm, I have been able to test on
x86_64-pc-linux-gnu, and I get an assemble failure instead of an executable:

egallager@gcc12:~$ /opt/cfarm/gcc-latest/bin/gcc 59865.C -S -Wall -Wextra
egallager@gcc12:~$ /opt/cfarm/gcc-latest/bin/gcc 59865.C -o 59865.exe
/tmp/cc2p5hY8.s: Assembler messages:
/tmp/cc2p5hY8.s:158: Error: unrecognized symbol type "gnu_indirect_function"
egallager@gcc12:~$ grep movl 59865.s | grep foov
movl$_Z3foov.popcnt, %eax
movl$_Z3foov.arch_corei7, %eax
movl$_Z3foov, %eax
egallager@gcc12:~$

[Bug target/82812] ICE in emit_move_insn, at expr.c:3706

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |8.0
   Target Milestone|8.0 |---

[Bug target/82805] [7/8 Regression] SPEC CPU2006 454.calculix ~6% performance deviation in between 6.3 and 7.2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
Version|unknown |7.2.0
   Target Milestone|--- |7.3

[Bug target/82807] [7/8 Regression] SPEC CPU2006 473.astar ~6% performance deviation in between 6.3 and 7.2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
Version|unknown |7.2.0
   Target Milestone|--- |7.3

[Bug ipa/82808] [7/8 Regression] LTO clone wrong value

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/82809] [8 Regression] ICE in in ix86_vector_duplicate_value, at config/i386/i386.c:41242

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |8.0
   Target Milestone|--- |8.0

[Bug fortran/53077] replace "Illegal preprocessor directive" message with "Ignoring preprocessor directive at %C. Use -cpp to enable the C preprocessor" (a patch by Tobias included)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |dominiq at lps dot 
ens.fr

--- Comment #8 from Eric Gallager  ---
(In reply to Eric Gallager from comment #7)
> (In reply to Dominique d'Humieres from comment #6)
> > Is there any objection if I do the testing and packaging for the patch in
> > comment 4?
> 
> No objection seen; go for it!

In fact, I'll even assign it to you since you expressed interest.

[Bug rtl-optimization/57970] segfault in sched-deps.c

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Eric Gallager  ---
(In reply to Eric Gallager from comment #6)
> (In reply to Chris King from comment #5)
> > Would a unit test case be acceptable?  That should be an easy way to evince
> > this bug and I'd be glad to write one.
> 
> It might not've been when you wrote this, but I guess now that David Malcolm
> has added unit testing capabilities to gcc, maybe...
> (See gcc/selftest.h and gcc/selftest.c for info)

Since there's been no response with even a unit-test since then, closing due to
lack of reproducibility.

[Bug target/56412] [4.8] "libtool: cygpath: command not found" for mingw32 host

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |SUSPENDED

--- Comment #8 from Eric Gallager  ---
(In reply to Eric Gallager from comment #7)
> (In reply to Kai Tietz from comment #6)
> > Yes, this is a libtool bug.  If thing is solved on libtool, then we can
> > continue on that.  So long I set bug in status waiting
> 
> If there's an upstream URL for the libtool bug report, we can set it to
> RESOLVED MOVED instead of WAITING.

changing it to SUSPENDED instead for now since no one from gcc is working on
it, but I still want to move it out of the WAITING queue and don't want to
close it either

[Bug target/82795] [8 Regression] ICE in predicate_mem_writes, at tree-if-conv.c:2251

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Well, not really a "regression", it was broken before the original fix.

The assert is simply bogus.

[Bug target/82812] ICE in emit_move_insn, at expr.c:3706

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-02
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

[Bug target/82812] New: ICE in emit_move_insn, at expr.c:3706

[marxin at gcc dot gnu.org]

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

Bug ID: 82812
   Summary: ICE in emit_move_insn, at expr.c:3706
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: julia.koval at intel dot com, kyukhin at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-linux-gnu

A GFNI fails starting from r254250:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/gfni-3.c
-mgfni
during RTL pass: expand
In file included from
/home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/include/immintrin.h:95:0,
 from
/home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/8.0.0/include/x86intrin.h:48,
 from
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/gfni-3.c:6:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/gfni-3.c: In
function ‘avx512vl_test’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/gfni-3.c:15:10:
internal compiler error: in emit_move_insn, at expr.c:3703
 x3 = _mm256_gf2p8affineinv_epi64_epi8(x3, x4, 3);
  ^~~~
0x8d4cba emit_move_insn(rtx_def*, rtx_def*)
../../gcc/expr.c:3702
0x8b7342 copy_to_reg(rtx_def*)
../../gcc/explow.c:591
0xfec6d6 ix86_expand_args_builtin
../../gcc/config/i386/i386.c:34113
0xff96ef ix86_expand_builtin
../../gcc/config/i386/i386.c:37244
0x77d6e5 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/builtins.c:6512
0x8d1269 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10847
0x8dceb3 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
../../gcc/expr.c:5551
0x8de6b7 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5319
0x7ad8ed expand_call_stmt
../../gcc/cfgexpand.c:2672
0x7b0cd8 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3608
0x7b13ce expand_gimple_stmt
../../gcc/cfgexpand.c:3774
0x7b8f02 expand_gimple_basic_block
../../gcc/cfgexpand.c:5779
0x7ba92f execute
../../gcc/cfgexpand.c:6385

[Bug sanitizer/82802] Potential UBSAN error with pointer difference (32-bits mode)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|6.5 |---
  Known to fail||5.4.0, 7.2.0

--- Comment #2 from Richard Biener  ---
I think this was noted by Jakub somewhere - the FE converts the pointers to
signed integer for the subtraction which causes the issue for pointers into
objects that "wrap" around the "half" address-space.

POINTER_DIFF_EXPR is supposed to allow fixing this.

A band-aid would be to perform the subtraction in an unsigned type, then
casting the result to a signed type to do the division by the element size.
I think Jakub did this and there was some fallout.

[Bug target/82804] [7/8 Regression] SPEC CPU2006 470.lbm ~5% performance deviation with r237185

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |7.2.0
   Target Milestone|--- |7.3

[Bug ipa/82801] [6/7/8 Regression] Internal compiler error with Eigen and __attribute__((always_inline, flatten))

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5

[Bug c++/82799] [8 Regression] -Wunused-but-set-variable false positive

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/82797] Suggest -Wshadow suppression for nested if/else

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-02
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug target/82811] New: Assembler error on tic6x-none-elf with march=c64x+

[g.hoogewerf at gmail dot com]

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

Bug ID: 82811
   Summary: Assembler error on tic6x-none-elf with march=c64x+
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g.hoogewerf at gmail dot com
  Target Milestone: ---

The following test case triggers an error on several versions of GCC, including
7.2.0 and 4.9.4. I tried several versions of binutils, including 2.20 and
2.26.1.

long long test(long long a, long long b)
{
long long c = 0;

c |= ((a & 0x) <<  0);
c |= (b << 16);

return c;
}

To trigger the error, the source should be compiled with: "-march=c64x+ -O2".
The error does not occur when building with "-march=c67x+".

When running with -v -save-temps, the output is:

Using built-in specs.
COLLECT_GCC=./tools/i686-pc-linux-gnu/tic6x-none-elf/bin/tic6x-none-elf-gcc
Target: tic6x-none-elf
Configured with: /home/ghoogewerf/GccBuild/src/gcc/configure
--prefix=/home/ghoogewerf/GccBuild/build/tic6x-none-elf-newlib/tools/i686-pc-linux-gnu/tic6x-none-elf
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=tic6x-none-elf
--enable-languages=c,c++ --disable-libssp --disable-wchar_t --disable-multilib
--with-pkgversion='Test G++ 7.2.0-p3' --disable-nls --disable-fixed-point
--disable-decimal-float --with-arch=c64x+ --disable-lto --with-newlib
--with-headers=/home/ghoogewerf/GccBuild/src/newlib/newlib/libc/include
Thread model: single
gcc version 7.2.0 (Test G++ 7.2.0-p3) 
COLLECT_GCC_OPTIONS='-c' '-O2' '-Wall' '-Wextra' '-march=c64x+' '-v'
'-save-temps'

/home/ghoogewerf/GccBuild/build/tic6x-none-elf-newlib/tools/i686-pc-linux-gnu/tic6x-none-elf/libexec/gcc/tic6x-none-elf/7.2.0/cc1
-E -quiet -v pack.c -march=c64x+ -Wall -Wextra -O2 -fpch-preprocess -o pack.i
#include "..." search starts here:
#include <...> search starts here:

/home/ghoogewerf/GccBuild/build/tic6x-none-elf-newlib/tools/i686-pc-linux-gnu/tic6x-none-elf/lib/gcc/tic6x-none-elf/7.2.0/include

/home/ghoogewerf/GccBuild/build/tic6x-none-elf-newlib/tools/i686-pc-linux-gnu/tic6x-none-elf/lib/gcc/tic6x-none-elf/7.2.0/include-fixed

/home/ghoogewerf/GccBuild/build/tic6x-none-elf-newlib/tools/i686-pc-linux-gnu/tic6x-none-elf/lib/gcc/tic6x-none-elf/7.2.0/../../../../tic6x-none-elf/sys-include

/home/ghoogewerf/GccBuild/build/tic6x-none-elf-newlib/tools/i686-pc-linux-gnu/tic6x-none-elf/lib/gcc/tic6x-none-elf/7.2.0/../../../../tic6x-none-elf/include
End of search list.
COLLECT_GCC_OPTIONS='-c' '-O2' '-Wall' '-Wextra' '-march=c64x+' '-v'
'-save-temps'

/home/ghoogewerf/GccBuild/build/tic6x-none-elf-newlib/tools/i686-pc-linux-gnu/tic6x-none-elf/libexec/gcc/tic6x-none-elf/7.2.0/cc1
-fpreprocessed pack.i -quiet -dumpbase pack.c -march=c64x+ -auxbase pack -O2
-Wall -Wextra -version -o pack.s
GNU C11 (Test G++ 7.2.0-p3) version 7.2.0 (tic6x-none-elf)
compiled by GNU C version 4.9.4, GMP version 6.1.0, MPFR version 3.1.3,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (Test G++ 7.2.0-p3) version 7.2.0 (tic6x-none-elf)
compiled by GNU C version 4.9.4, GMP version 6.1.0, MPFR version 3.1.3,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f86a3322b854da36fc325771f0c6992e
COLLECT_GCC_OPTIONS='-c' '-O2' '-Wall' '-Wextra' '-march=c64x+' '-v'
'-save-temps'

/home/ghoogewerf/GccBuild/build/tic6x-none-elf-newlib/tools/i686-pc-linux-gnu/tic6x-none-elf/lib/gcc/tic6x-none-elf/7.2.0/../../../../tic6x-none-elf/bin/as
-march=c64x+ -o pack.o pack.s
pack.s: Assembler messages:
pack.s:15: Error: operand 1 of 'pack2' on wrong side

Thanks,
G. Hoogewerf

[Bug fortran/82796] [6/7/8 Regression] Private+equivalence in used module breaks compilation of pure function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5

[Bug target/82795] [8 Regression] ICE in predicate_mem_writes, at tree-if-conv.c:2251

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
Mine.  *sigh*

[Bug sanitizer/82517] use-after-scope for a variable with big alignment causes a false positive

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work|8.0 |
  Known to fail||8.0

--- Comment #4 from Martin Liška  ---
Reopening for trunk as it should check for:
BITS_PER_UNIT * ASAN_SHADOW_GRANULARITY <= MAX_SUPPORTED_STACK_ALIGNMENT.

[Bug c++/82790] [GCC 5, 6, 7] -Wuseless-cast doesn't detect unnecessary removal of const

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-02
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Confirmed.

[Bug middle-end/82810] New: missed uninitialized variable warning in for/while loop

[jan.smets at nokia dot com]

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

Bug ID: 82810
   Summary: missed uninitialized variable warning in for/while
loop
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

In the following code x clearly is used uninitialized

#include 
int main(void)
{
while (1) 
{   
int x;  
printf("x=%d\n", x); 
x = 0;
}   
return 0;
}

Possibly dup of 82101 ?

[Bug target/82805] [7/8 Regression] SPEC CPU2006 454.calculix ~6% performance deviation in between 6.3 and 7.2

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #4 from Jan Hubicka  ---
Caluculix also sees smaller regression on Haswell due to the vectorization
costmodel change.  I will try to take a look.

[Bug ipa/82808] [7/8 Regression] LTO clone wrong value

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-02
 CC||jamborm at gcc dot gnu.org,
   ||kugan at gcc dot gnu.org
   Target Milestone|--- |7.3
Summary|LTO clone wrong value   |[7/8 Regression] LTO clone
   ||wrong value
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, we really wrongly propagate 0 to x:

$ cat xxx.ltrans0.075i.cp
;; Function foo.constprop (foo.constprop.1, funcdef_no=3, decl_uid=4078,
cgraph_uid=1, symbol_order=5) (executed once)

Modification phase of node foo.constprop/5
Adjusting mask for param 0 to 0x0
Setting nonnull for 0
foo.constprop (double * a)
{
  double x;

   [100.00%] [count: INV]:

   [100.00%] [count: INV]:
  *a_2(D) = x_1(D);
  return;

}

Started with r241990.

[Bug testsuite/82415] FAIL: gcc.target/i386/naked-1.c scan-assembler-not ret

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #4 from Tom de Vries  ---
Test-case fixed, marking resolved-fixed.

[Bug target/82809] New: [8 Regression] ICE in in ix86_vector_duplicate_value, at config/i386/i386.c:41242

[marxin at gcc dot gnu.org]

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

Bug ID: 82809
   Summary: [8 Regression] ICE in in ix86_vector_duplicate_value,
at config/i386/i386.c:41242
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: alan.hayward at arm dot com, david.sherwood at arm dot com,
richard.sandiford at linaro dot org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu

Starting from r254292 we ICE on:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/pr52199.c 
-Ofast -fno-tree-dominator-opts
during RTL pass: expand
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/pr52199.c: In
function ‘time_read’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/pr52199.c:22:24:
internal compiler error: in ix86_vector_duplicate_value, at
config/i386/i386.c:41242
   time->abday[cnt] = "";
   ~^~~~
0xef478e ix86_vector_duplicate_value
../../gcc/config/i386/i386.c:41242
0xf0f479 ix86_expand_vector_init_duplicate
../../gcc/config/i386/i386.c:41365
0xf439b7 ix86_expand_vector_init(bool, rtx_def*, rtx_def*)
../../gcc/config/i386/i386.c:42206
0x117013d gen_vec_initv2sfsf(rtx_def*, rtx_def*)
../../gcc/config/i386/mmx.md:660
0x87bcde insn_gen_fn::operator()(rtx_def*, rtx_def*) const
../../gcc/recog.h:301
0x87bcde store_constructor
../../gcc/expr.c:6709
0x87cda5 expand_constructor
../../gcc/expr.c:8006
0x86a341 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10105
0x86b813 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:9791
0x879da7 expand_expr
../../gcc/expr.h:276
0x879da7 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:4947
0x74fbf8 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3676
0x74fbf8 expand_gimple_stmt
../../gcc/cfgexpand.c:3774
0x751f07 expand_gimple_basic_block
../../gcc/cfgexpand.c:5779
0x758426 execute
../../gcc/cfgexpand.c:6385

[Bug ipa/82808] New: LTO clone wrong value

[npickito at gmail dot com]

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

Bug ID: 82808
   Summary: LTO clone wrong value
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: npickito at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
Target: x86-64

Version: trunk@254336, 7.x
* work on 6.x

Option:
gcc case.c -O2 -fno-inline -flto


How to reproduce:
./a.out
Aborted (core dumped)

Expect:
exited normally

Case:
void foo(double *a, double x)
{
  *a = x;
}

double f_c1(int m, double *a)
{
  foo(a, m);
  return *a;
}

int main(){
  double data;
  double ret = 0 ;

  if ((ret = f_c1(2, )) != 2)
{
  __builtin_abort ();
}
  return 0;
}


Symptom:
`x` in `foo` seems like propagated as 0.

Code gen in x86_64

foo.constprop.1:
.LFB3:
.cfi_startproc
movq$0x0, (%rdi)
ret
.cfi_endproc
.LFE3:
.size   foo.constprop.1, .-foo.constprop.1
.p2align 4,,15
.type   f_c1.constprop.0, @function

[Bug testsuite/82415] FAIL: gcc.target/i386/naked-1.c scan-assembler-not ret

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Author: vries
Date: Thu Nov  2 09:07:27 2017
New Revision: 254338

URL: https://gcc.gnu.org/viewcvs?rev=254338=gcc=rev
Log:
Fix scan-assembler patterns in i386/naked-{1,2}.c

2017-11-02  Tom de Vries  

PR testsuite/82415
* gcc.target/i386/naked-1.c: Make scan patterns more precise.
* gcc.target/i386/naked-2.c: Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/naked-1.c
trunk/gcc/testsuite/gcc.target/i386/naked-2.c

[Bug target/82807] [7/8 Regression] SPEC CPU2006 473.astar ~6% performance deviation in between 6.3 and 7.2

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Created attachment 42533
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42533=edit
perf diff

[Bug target/82807] [7/8 Regression] SPEC CPU2006 473.astar ~6% performance deviation in between 6.3 and 7.2

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Created attachment 42532
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42532=edit
perf report

[Bug target/82807] [7/8 Regression] SPEC CPU2006 473.astar ~6% performance deviation in between 6.3 and 7.2

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 42531
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42531=edit
perf annotate

[Bug target/82807] [7/8 Regression] SPEC CPU2006 473.astar ~6% performance deviation in between 6.3 and 7.2

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 42529
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42529=edit
perf annotate

[Bug target/82807] [7/8 Regression] SPEC CPU2006 473.astar ~6% performance deviation in between 6.3 and 7.2

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 42530
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42530=edit
perf report

[Bug target/82807] New: [7/8 Regression] SPEC CPU2006 473.astar ~6% performance deviation in between 6.3 and 7.2

[marxin at gcc dot gnu.org]

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

Bug ID: 82807
   Summary: [7/8 Regression] SPEC CPU2006 473.astar ~6%
performance deviation in between 6.3 and 7.2
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

We lost about 6% on Zen with -Ofast -mtune=generic in between these 2 releases.
It's quite hard to bisect a single revision.

[Bug target/82805] [7/8 Regression] SPEC CPU2006 454.calculix ~6% performance deviation in between 6.3 and 7.2

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 42528
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42528=edit
perf diff

[Bug driver/82806] New: Stabilize paths in assembler and dumps

[vries at gcc dot gnu.org]

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

Bug ID: 82806
   Summary: Stabilize paths in assembler and dumps
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Recently I've run  into the following issues:

1. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82415 "Bug 82415 - FAIL:
gcc.target/i386/naked-1.c scan-assembler-not ret".
I build and tested gcc in a directory with "ret" in the path, and an assembler
scan triggered on that.

2. https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00055.html.
I build and tested gcc in a directory with "while" in the path, and a tree-dump
scan triggered on that.

I wonder if we can add a gcc option -fstrip-path[=] that strips (or
replaces with a constant string) paths in compiler output such as dumps and
assembler.

By using by default fstrip-path="stripped-path" or some such in the testsuite,
we can stabilize compiler output and reduce noise in the testsuite.

[Bug target/82805] [7/8 Regression] SPEC CPU2006 454.calculix ~6% performance deviation in between 6.3 and 7.2

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 42526
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42526=edit
perf report

[Bug target/82804] [7/8 Regression] SPEC CPU2006 470.lbm ~5% performance deviation with r237185

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Can't be reproduced on Haswell.

[Bug target/82805] [7/8 Regression] SPEC CPU2006 454.calculix ~6% performance deviation in between 6.3 and 7.2

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 42525
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42525=edit
perf report

[Bug target/82805] New: [7/8 Regression] SPEC CPU2006 454.calculix ~6% performance deviation in between 6.3 and 7.2

[marxin at gcc dot gnu.org]

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

Bug ID: 82805
   Summary: [7/8 Regression] SPEC CPU2006 454.calculix ~6%
performance deviation in between 6.3 and 7.2
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

We lost about 6% on Zen with -O2 -mtune=generic in between these 2 releases.
It's quite hard to bisect a single revision.

[Bug c++/82781] [6/7/8 Regression] Vector extension operators return wrong result in constexpr

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/82804] [7/8 Regression] SPEC CPU2006 470.lbm ~5% performance deviation with r237185

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Created attachment 42524
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42524=edit
perf report

[Bug target/82804] [7/8 Regression] SPEC CPU2006 470.lbm ~5% performance deviation with r237185

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Created attachment 42523
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42523=edit
perf annotate

[Bug target/82804] [7/8 Regression] SPEC CPU2006 470.lbm ~5% performance deviation with r237185

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 42522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42522=edit
perf diff

[Bug target/82804] [7/8 Regression] SPEC CPU2006 470.lbm ~5% performance deviation with r237185

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 42521
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42521=edit
perf report

[Bug target/82804] [7/8 Regression] SPEC CPU2006 470.lbm ~5% performance deviation with r237185

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 42520
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42520=edit
perf annotate

[Bug rtl-optimization/82778] crash: insn does not satisfy its constraints

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Richard Biener  ---
Fixed then.

[Bug tree-optimization/82776] Unable to optimize the loop when iteration count is unavailable.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-02
Version|unknown |8.0
 Ever confirmed|0   |1

[Bug hsa/82771] FAIL: brig.dg/test/gimple/packed.hsail (internal compiler error)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Richard Biener  ---
Fixed I assume.

[Bug fortran/82774] [6/7/8 Regression] Structure constructor and deferred type parameter character component

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5