[Bug target/71733] ICE in vmx test cases with -mcpu=power9

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||amodra at gmail dot com
 Resolution|--- |FIXED
   Target Milestone|7.0 |6.2

--- Comment #8 from Alan Modra  ---
Fixed for gcc-7 and gcc-6.

[Bug c++/71604] [6/7 Regression] ICE on valid C++11 code with range-based for loop: in pop_binding, at cp/name-lookup.c:376

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
This seems not to be valid. [stmt.ranged]p2: "The decl-specifier-seq shall not
define a class or enumeration."

Still shouldn't ICE, of course.

[Bug target/71733] ICE in vmx test cases with -mcpu=power9

[amodra at gcc dot gnu.org]

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

--- Comment #7 from Alan Modra  ---
Author: amodra
Date: Thu Jul 14 04:28:25 2016
New Revision: 238327

URL: https://gcc.gnu.org/viewcvs?rev=238327=gcc=rev
Log:
[RS6000] -mno-vsx should force -mno-power9-dform

PR target/71733
gcc/
* config/rs6000/rs6000.c (rs6000_option_override_internal): Deal
with p9_vector override before power9-dform override.
gcc/testsuite/
* gcc.target/powerpc/p9-novsx.c: New.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/71733] ICE in vmx test cases with -mcpu=power9

[amodra at gcc dot gnu.org]

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

--- Comment #6 from Alan Modra  ---
Author: amodra
Date: Thu Jul 14 04:26:36 2016
New Revision: 238326

URL: https://gcc.gnu.org/viewcvs?rev=238326=gcc=rev
Log:
[RS6000] -mno-vsx should force -mno-power9-dform

PR target/71733
gcc/
* config/rs6000/rs6000.c (rs6000_option_override_internal): Deal
with p9_vector override before power9-dform override.
gcc/testsuite/
* gcc.target/powerpc/p9-novsx.c: New.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/p9-novsx.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/71872] ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant

[gary at intrepid dot com]

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

--- Comment #1 from Gary Funck  ---
(In reply to Gary Funck from comment #0)
> See also PR 70683.
> 
> When the attached test case is compiled with -O3 and gcc checks are enabled,
> the following ICE is triggered.
> 
> It looks like this check was added by trunk revision r23546.

Edit: that should be trunk revision 235469.

[Bug sanitizer/71872] New: ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant

[gary at intrepid dot com]

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

Bug ID: 71872
   Summary: ICE in inchash::add_expr, at tree.c:7782 -
OEP_ADDRESS_OF asserted for ADDR_EXPR applied to
constant
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gary at intrepid dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Created attachment 38895
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38895=edit
Non-reduced, pre-processed, test case for ICE in inchash::add_expr

See also PR 70683.

When the attached test case is compiled with -O3 and gcc checks are enabled,
the following ICE is triggered.

It looks like this check was added by trunk revision r23546.

ice-hash-expr.i: In function ‘main’:
ice-hash-expr.i:300:1: internal compiler error: in add_expr, at tree.c:7782
 main ()
 ^~~~
0xde5865 inchash::add_expr(tree_node const*, inchash::hash&, unsigned int)
/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree.c:7782
0xde65d3 inchash::add_expr(tree_node const*, inchash::hash&, unsigned int)
/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree.c:7997
0xba4406 iterative_hash_expr
/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree.h:4786
0xba4406 innermost_loop_behavior_hash::hash(innermost_loop_behavior* const&)
/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-if-conv.c:150
0xba4406
simple_hashmap_traits::hash(innermost_loop_behavior* const&)
/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/hash-map-traits.h:48
0xba4406 hash_map >::get_or_insert(innermost_loop_behavior* const&, bool*)
/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/hash-map.h:161
0xba4406 hash_memrefs_baserefs_and_store_DRs_read_written_info
/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-if-conv.c:693
0xba4406 if_convertible_loop_p_1
/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-if-conv.c:1410
0xba4406 if_convertible_loop_p
/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-if-conv.c:1490
0xba6e41 tree_if_conversion
/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-if-conv.c:2647
0xba6e41 execute
/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-if-conv.c:2749

The offending tree expression looks like this:


unit size 
align 32 symtab 0 alias set -1 canonical type 0x7fffefe0c888
precision 32 min  max  context 
pointer_to_this >
public unsigned DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x7fffefe2d930>
constant
arg 0  constant 1>>

The assertion check is at line 7782.

   identity.  */
7778case VOID_CST:
7779  hstate.merge_hash (0);
7780  return;
7781case INTEGER_CST:
7782  gcc_checking_assert (!(flags & OEP_ADDRESS_OF));
7783  for (i = 0; i < TREE_INT_CST_EXT_NUNITS (t); i++)
7784hstate.add_wide_int (TREE_INT_CST_ELT (t, i));
7785  return;
7786case REAL_CST:

[Bug c++/71867] Optimizer generates code dereferencing a null pointer

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #1 from Andrew Pinski  ---
Can you provide the preprocessed source?

[Bug c++/71871] ICE on mixing templates and vector extensions ternary operator

[mirq-gccboogs at rere dot qmqm.pl]

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

--- Comment #1 from Micha³ Miros³aw  ---
Created attachment 38894
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38894=edit
test case 2

Small change (second variable instead of constant) changes the ICE to:

$ g++  -c b.cc
b.cc: In function ‘void foo() [with unsigned int N = 0u]’:
b.cc:7:2: internal compiler error: in make_decl_rtl, at varasm.c:1313
  x = x ? x : y;
  ^
0x94b229 make_decl_rtl(tree_node*)
../../src/gcc/varasm.c:1309
0xea0272 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../src/gcc/expr.c:9581
0xea17b8 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../src/gcc/expr.c:8018
0xea17b8 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, tree_node*)
../../src/gcc/expr.c:5382
0xea0fbc expand_assignment(tree_node*, tree_node*, bool)
../../src/gcc/expr.c:5154
0xdfbf10 expand_gimple_stmt_1
../../src/gcc/cfgexpand.c:3426
0xdfbf10 expand_gimple_stmt
../../src/gcc/cfgexpand.c:3522
0xdf4f18 expand_gimple_basic_block
../../src/gcc/cfgexpand.c:5534
0xdf4f18 execute
../../src/gcc/cfgexpand.c:6152
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/71871] New: ICE on mixing templates and vector extensions ternary operator

[mirq-gccboogs at rere dot qmqm.pl]

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

Bug ID: 71871
   Summary: ICE on mixing templates and vector extensions ternary
operator
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mirq-gccboogs at rere dot qmqm.pl
  Target Milestone: ---

Created attachment 38893
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38893=edit
test case

Attached causes an ICE.

$ g++ -c a.cc
a.cc: In function ‘void foo() [with unsigned int N = 0u]’:
a.cc:7:2: internal compiler error: in gimplify_expr, at gimplify.c:8858
  x = x ? x : -1;
  ^
0x74c6d9 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../src/gcc/gimplify.c:8858
0xefc41c internal_get_tmp_var
../../src/gcc/gimplify.c:555
0x12b62d1 get_initialized_tmp_var(tree_node*, gimple_statement_base**,
gimple_statement_base**)
../../src/gcc/gimplify.c:598
0x12b62d1 gimplify_save_expr
../../src/gcc/gimplify.c:4887
0xef8d54 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../src/gcc/gimplify.c:8412
0xef80cf gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../src/gcc/gimplify.c:8228
0x7516c5 gimplify_init_constructor
../../src/gcc/gimplify.c:4103
0xefbeb0 gimplify_modify_expr_rhs
../../src/gcc/gimplify.c:4274
0xefb4a9 gimplify_modify_expr
../../src/gcc/gimplify.c:4603
0xef778f gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../src/gcc/gimplify.c:8126
0xefc82b gimplify_stmt(tree_node**, gimple_statement_base**)
../../src/gcc/gimplify.c:5545
0xefc82b gimplify_and_add(tree_node*, gimple_statement_base**)
../../src/gcc/gimplify.c:423
0xefc82b internal_get_tmp_var
../../src/gcc/gimplify.c:568
0xef7c8c get_formal_tmp_var(tree_node*, gimple_statement_base**)
../../src/gcc/gimplify.c:589
0xef7c8c gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../src/gcc/gimplify.c:9050
0x74b6d6 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../src/gcc/gimplify.c:8844
0xefb54b gimplify_modify_expr
../../src/gcc/gimplify.c:4644
0xef778f gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../src/gcc/gimplify.c:8126
0xef716e gimplify_stmt(tree_node**, gimple_statement_base**)
../../src/gcc/gimplify.c:5545
0xef8570 gimplify_cleanup_point_expr
../../src/gcc/gimplify.c:5321
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.4.0-6'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,jau
Thread model: posix
gcc version 5.4.0 20160609 (Debian 5.4.0-6) 

also fails on:

$ g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++-4.9.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --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 4.9.2 (Debian 4.9.2-10)

[Bug c/71870] wrong location of "%n$" directive in -Wformat

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
The following output with my WIP patch for bug 49905 shows that at least in C
the correct location information is available (the second warning):

$ cat xyz.c && /build/gcc-49905/gcc/xgcc -B /build/gcc-49905/gcc -O2 -S -Wall
-Wextra -Wpedantic xyz.c
char d [4];

void f (void)
{
  __builtin_sprintf (d, "%3$i%1$i", 1, 234);
}
xyz.c: In function ‘f’:
xyz.c:5:3: warning: ISO C does not support %n$ operand number formats
[-Wformat]
   __builtin_sprintf (d, "%3$i%1$i", 1, 234);
   ^
xyz.c:5:3: warning: operand number out of range in format [-Wformat=]
xyz.c:5:27: warning: numbered argument value ‘3’ exceeds the number of provided
arguments ‘2’ [-Wformat-length=]
   __builtin_sprintf (d, "%3$i%1$i", 1, 234);
   ^

[Bug bootstrap/66319] [6 Regression] gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const c har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)'

[jim.wilson at linaro dot org]

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

--- Comment #18 from jim.wilson at linaro dot org ---
On 07/12/2016 09:36 AM, bugzilla-gcc at thewrittenword dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66319
>
> --- Comment #16 from The Written Word  com> ---
> (In reply to John David Anglin from comment #15)
>> Steve Ellcey used to support HP-UX/IA64 but he moved on to MIPS.  Don't
>> know Jim Wilson's status.

I've never had access to HP-UX/IA64.  I've only used ia64-linux.  I no 
longer have an IA-64 machine at home.  I don't have access to IA-64 at 
work, and there is no IA-64 hardware in the gcc compile farm.  I retain 
a lot of knowledge about how IA-64 works, but with no hardware access, 
and no HP-UX access, there isn't much I can do to help.

Jim

[Bug c/71870] New: wrong location of "%n$" directive in -Wformat

[msebor at gcc dot gnu.org]

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

Bug ID: 71870
   Summary: wrong location of "%n$" directive in -Wformat
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When encountering an invalid format specifier, the GCC -Wformat checker issues
a warning pointing to the specifier in the format string.  However, when it
encounters the dollar sign in an otherwise valid POSIX format directive, GCC
issues a warning that doesn't point to the directive.  Modulo the difficulties
discussed in bug 52952 and related there should be no problem pointing to the
'$' in the basic cases similarly to what's done for the 'r' in the test case
below.

$ cat xyz.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S
-Wall -Wextra -Wpedantic xyz.c
char d [4];

void f (void)
{
  __builtin_sprintf (d, "%r");

  __builtin_sprintf (d, "%2$i%1$i", 1, 234);
}
xyz.c: In function ‘f’:
xyz.c:5:27: warning: unknown conversion type character ‘r’ in format
[-Wformat=]
   __builtin_sprintf (d, "%r");
   ^
xyz.c:7:3: warning: ISO C does not support %n$ operand number formats
[-Wformat]
   __builtin_sprintf (d, "%2$i%1$i", 1, 234);
   ^

[Bug c++/56856] the location of Wformat warnings points *after* the format string

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Thanks for the background and the pointer.  Is this report then a duplicate of
bug 43486?

[Bug c/71869] New: __builtin_isgreater raises an invalid exception on PPC64 using __float128 inputs.

[murphyp at linux dot vnet.ibm.com]

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

Bug ID: 71869
   Summary: __builtin_isgreater raises an invalid exception on
PPC64 using __float128 inputs.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: murphyp at linux dot vnet.ibm.com
  Target Milestone: ---

#include 
volatile __float128 qnan = __builtin_nanq("");
int main()
{
feclearexcept(FE_INVALID);
if (__builtin_isgreater(1.0Q, qnan)) puts("isgreater is broken");
if (fetestexcept(FE_INVALID)) puts("invalid wrongly set for quiet
comparison");
return 0;
}

Using a recent gcc-6-branch checkout:
gcc -mfloat128 -mcpu=power8

I assume this also the case for the other __builtin_is{ordering} functions too.

This causes a substantial number of test failures for float128 when shoehorned
into the glibc libm test suite. (Note, this is much hacked up local copy of
glibc to verify the compiler support for float128 is sufficient for glibc).

x86 appears to stick a call to __unordtf2 before attempting to call the
comparison function.  I assume PPC64 should be doing a similar for KFmode.

[Bug c/71868] internal compiler error: in compute_working_sets, at gcov-io.c:1006

[nghia.huynh at nxp dot com]

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

--- Comment #1 from nghia.huynh at nxp dot com ---
Created attachment 38892
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38892=edit
gcc info and log

preprocessed files size exceed 1kb size limit

[Bug c/71868] New: internal compiler error: in compute_working_sets, at gcov-io.c:1006

[nghia.huynh at nxp dot com]

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

Bug ID: 71868
   Summary: internal compiler error: in compute_working_sets, at
gcov-io.c:1006
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nghia.huynh at nxp dot com
  Target Milestone: ---

Got the following error while building nginx 1.8.1 with -lgcov

internal compiler error: in compute_working_sets, at gcov-io.c:1006

[Bug c++/70926] Libiberty Demangler segfaults (5)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #1 from Jeffrey A. Law  ---
Fixed by commit on trunk

[Bug c++/70926] Libiberty Demangler segfaults (5)

[law at gcc dot gnu.org]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #1 from Jeffrey A. Law  ---
Fixed by commit on trunk

--- Comment #2 from Jeffrey A. Law  ---
Author: law
Date: Wed Jul 13 22:06:09 2016
New Revision: 238313

URL: https://gcc.gnu.org/viewcvs?rev=238313=gcc=rev
Log:
PR c++/70926
* cplus-dem.c: Handle large values and overflow when demangling
length variables.
(demangle_template_value_parm): Read only until end of mangled string.
(do_hpacc_template_literal): Likewise.
(do_type): Handle overflow when demangling array indices.

Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/cplus-dem.c
trunk/libiberty/testsuite/demangle-expected

[Bug c++/71711] [6/7 Regression] ICE on valid C++1z code with fold expression: tree check: expected tree_vec, have expr_pack_expansion in tsubst_unary_left_fold, at cp/pt.c:10792

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/71867] New: Optimizer generates code dereferencing a null pointer

[vz-gcc at zeitlins dot org]

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

Bug ID: 71867
   Summary: Optimizer generates code dereferencing a null pointer
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vz-gcc at zeitlins dot org
  Target Milestone: ---

First of all, I'd like to say that I'm reporting this bug because it looks like
a rather bad problem in gcc to me, but I don't have any simple example
reproducing it because I couldn't produce one even in spite of spending some
time on this, so please feel free to close if you're not interested in
debugging this.

The problem in question is that, according to the original bug report (see
http://trac.wxwidgets.org/ticket/17483), code generated by gcc -O2 for this
method (omitting parts of the class, you can see the full version at
https://github.com/wxWidgets/wxWidgets/blob/v3.1.0/include/wx/rtti.h#L86):

class wxClassInfo {
public:
...
bool IsKindOf(const wxClassInfo *info) const
{
return info != 0 &&
   ( info == this ||
 ( m_baseInfo1 && m_baseInfo1->IsKindOf(info) ) ||
 ( m_baseInfo2 && m_baseInfo2->IsKindOf(info) ) );
}

private:
const wxClassInfo   *m_baseInfo1;
const wxClassInfo   *m_baseInfo2;
};

generates the code which crashes during run-time because
m_baseInfo1->IsKindOf() call is done even when m_baseInfo1 is null. The crash
doesn't happen with -O0 or even with an attribute optimize("O0") applied to
just this function.

Unfortunately, extracting this class and compiling just it with -O2 doesn't
show the problem, there must be something else triggering it and making the
optimizer assume that the pointers can never be null (which is true for almost
all classes, but not for the root class of the hierarchy, which is constructed
with null base class info pointer). And, again, I tried, but I couldn't find
what it was.

Rewriting the expression as a sequence of statements, as done in
https://github.com/wxWidgets/wxWidgets/commit/aa3acfdd15eff1519a41b48a2babe4cba75660f9,
fixes the bug, so from my point of view this particular problem is solved, but,
again, I find it rather worrying if the optimizer can miscompile quite
straightforward code like above, so I still wanted to report it. If you'd like
to look at it, please get any version of wxWidgets prior to the commit above
(e.g. 3.1.0 release) and build it under Windows. Of course, please let me know
if you need any more information -- other than a simple reproducible test case
which I, unfortunately, just can't make.

Thanks in advance!

[Bug fortran/70842] [4.9/5/6/7 Regression] internal compiler error with character members within a polymorphic pointer

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Gerhard Steinmetz from comment #4)
> ICE for both release and experimental :
> 
> 
> $ gfortran-6 pr70842.f90
> f951: internal compiler error: in gfc_add_component_ref, at
> fortran/class.c:241
> 

With the patch I posted earlier today and code in comment #1, I see

 gfc7 -c a.f90
a.f90:14:30:

 print*, len(me%string)
  1
Error: Data transfer element at (1) cannot be polymorphic unless it
is processed by a defined input/output procedure

I don't use CLASS and know little about its expected behavior.
Is the above even remotely right?

[Bug target/71731] incorrect result for vectorized char rotate with -mcpu=power9

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #4 from Bill Schmidt  ---
Thus closing.  Thanks, Aaron!

*** This bug has been marked as a duplicate of bug 71805 ***

[Bug target/71805] incorrect code for test pr45752.c with -mcpu=power9

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from Bill Schmidt  ---
*** Bug 71731 has been marked as a duplicate of this bug. ***

[Bug target/71731] incorrect result for vectorized char rotate with -mcpu=power9

[acsawdey at gcc dot gnu.org]

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

--- Comment #3 from acsawdey at gcc dot gnu.org ---
This appears to be fixed by the fix for PR71805.

[Bug target/69880] Linking Windows resource + implicit 'default-manifest.o' creates bad .exe

[vsz.bugzilla at emailuser dot net]

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

--- Comment #11 from vsz.bugzilla at emailuser dot net ---
Thank you, Nick.

I'd be glad to make tests with a binary pre-built using your patches, but
building binutils from source myself, appears to be a too long shot at this
point.

Is there someone who could help out with test binutils binaries?

[Bug c++/56856] the location of Wformat warnings points *after* the format string

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Martin Sebor from comment #5)
> I thought I'd look into this bug since it affects the testing of my patch
> for bug 49905 and I'm finding out that it seems to be a general problem with
> C++ and function arguments.  From what I can see, the C front end tracks the
> locations of function arguments through the parser, passing them from
> function to function, while the C++ front end doesn't.  Sadly, it doesn't
> look like a simple fix...

This happens for "expressions" that don't have a location (such as constants,
variable uses, etc.). I'm not even sure that passing the location is enough,
since the C++ parser will do a lot of tentative parsing and, by the time you
call the function, input_location is too far away and the original location of
the argument is lost. You may need to store the locations together with the
arguments when they are parsed and somehow keep them together throughout the
C++ FE. Which is of course redundant when the expressions actually have a
location.


At the end, everything comes back to fixing PR43486

[Bug middle-end/70159] missed CSE optimization

[anton at samba dot org]

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

--- Comment #18 from Anton Blanchard  ---
Urgh too early in the morning for me. PR71866 created, with the correct
backtrace.

[Bug tree-optimization/71866] New: gcc locks up after fix for PR70159

[anton at samba dot org]

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

Bug ID: 71866
   Summary: gcc locks up after fix for PR70159
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton at samba dot org
  Target Milestone: ---

Created attachment 38891
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38891=edit
Test case

The attached testcase is locking up on ppc64le when run with -O2.

#0  0x10733df8 in iterative_hash_hashval_t (val=2902752560,
val2=2655680748) at ../../gcc/gcc/inchash.h:156
#1  0x10ac2004 in phi_trans_add (pred=0x3fffb57d8818, e=0x11b553c0,
entry=0x3fffe3f8)
at ../../gcc/gcc/tree-ssa-pre.c:620
#2  phi_translate (expr=0x11b553c0, set1=0x11b369a8, set2=0x0,
pred=0x3fffb57d8818, phiblock=0x3fffb57d6f50)
at ../../gcc/gcc/tree-ssa-pre.c:1815
#3  0x10ac4744 in do_pre_regular_insertion (dom=0x3fffb57d6e80,
block=0x3fffb57d6f50)
at ../../gcc/gcc/tree-ssa-pre.c:3266
#4  insert_aux (block=0x3fffb57d6f50, do_pre=true, do_hoist=true) at
../../gcc/gcc/tree-ssa-pre.c:3679
#5  0x10ac43e0 in insert_aux (block=0x3fffb57d6e80, do_pre=true,
do_hoist=true)
at ../../gcc/gcc/tree-ssa-pre.c:3693
#6  0x10ac43e0 in insert_aux (block=0x3fffb57d6db0, do_pre=, do_hoist=)
at ../../gcc/gcc/tree-ssa-pre.c:3693
#7  0x10ac74b4 in insert () at ../../gcc/gcc/tree-ssa-pre.c:3717
#8  (anonymous namespace)::pass_pre::execute (this=,
fun=0x3fffb5848b20)
at ../../gcc/gcc/tree-ssa-pre.c:5082
#9  0x107b9fe4 in execute_one_pass (pass=0x11950c30) at
../../gcc/gcc/passes.c:2344
#10 0x107ba6d8 in execute_pass_list_1 (pass=0x11950c30) at
../../gcc/gcc/passes.c:2428
#11 0x107ba6f0 in execute_pass_list_1 (pass=0x1194fbb0) at
../../gcc/gcc/passes.c:2429
#12 0x107ba798 in execute_pass_list (fn=,
pass=)
at ../../gcc/gcc/passes.c:2439
#13 0x103bea34 in cgraph_node::expand (this=0x3fffb5861870) at
../../gcc/gcc/cgraphunit.c:1983
#14 0x103c0b6c in expand_all_functions () at
../../gcc/gcc/cgraphunit.c:2119
#15 symbol_table::compile (this=0x3fffb563) at
../../gcc/gcc/cgraphunit.c:2475
#16 0x103c3914 in symbol_table::compile (this=0x3fffb563) at
../../gcc/gcc/cgraphunit.c:2380
#17 symbol_table::finalize_compilation_unit (this=0x3fffb563) at
../../gcc/gcc/cgraphunit.c:2565
#18 0x108c4a1c in compile_file () at ../../gcc/gcc/toplev.c:490
#19 0x101b12fc in do_compile () at ../../gcc/gcc/toplev.c:1998
#20 toplev::main (this=0x30d6, argc=3, argv=0x34f8) at
../../gcc/gcc/toplev.c:2132
#21 0x101b3344 in main (argc=, argv=0x34f8) at
../../gcc/gcc/main.c:39

[Bug c/71858] Surprising suggestions for misspellings

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
--- gcc/c/c-decl.c.jj   2016-06-24 12:59:22.0 +0200
+++ gcc/c/c-decl.c  2016-07-13 22:40:23.410658411 +0200
@@ -4021,7 +4021,7 @@ lookup_name_fuzzy (tree name, enum looku
   for (c_scope *scope = current_scope; scope; scope = scope->outer)
 for (c_binding *binding = scope->bindings; binding; binding =
binding->prev)
   {
-   if (!binding->id)
+   if (!binding->id || binding->invisible)
  continue;
/* Don't use bindings from implicitly declared functions,
   as they were likely misspellings themselves.  */

indeed fixes this.  Well, it suggests:
pr71858.c: In function ‘main’:
pr71858.c:4:10: warning: implicit declaration of function ‘bar’; did you mean
‘char’? [-Wimplicit-function-declaration]
   return bar ();
  ^~~
  char
instead.  Which actually also isn't a very good suggestion for C (unlike C++),
it would be useful to consider only FUNCTION_DECLs in this case.

[Bug c/71858] Surprising suggestions for misspellings

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Indeed, DECL_ANTICIPATED (for C++) decls and for C b->invisible bindings should
not be considered.

[Bug middle-end/70159] missed CSE optimization

[pinskia at gcc dot gnu.org]

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

--- Comment #17 from Andrew Pinski  ---
(In reply to Anton Blanchard from comment #16)
> I'm seeing a lockup in gcc with this patch on ppc64le. Run as:
> 
> gcc -O2 -c testcase.i

Can you file a new bug for this?  Also your backtrace is just for the driver.

[Bug middle-end/70159] missed CSE optimization

[anton at samba dot org]

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

--- Comment #16 from Anton Blanchard  ---
I'm seeing a lockup in gcc with this patch on ppc64le. Run as:

gcc -O2 -c testcase.i

It gets stuck in:

#0  0x3fffb7e5e3e8 in __waitpid_nocancel ()
at ../sysdeps/unix/syscall-template.S:84
#1  0x10088c58 in pex_wait (obj=, time=0x0, 
status=0x1015f080, pid=)
at ../../gcc/libiberty/pex-unix.c:134
#2  pex_unix_wait (obj=, pid=, 
status=0x1015f080, time=0x0, done=, errmsg=0x3fffd750, 
err=0x3fffd74c) at ../../gcc/libiberty/pex-unix.c:738
#3  0x1008762c in pex_get_status_and_time (obj=, 
done=, errmsg=, err=)
at ../../gcc/libiberty/pex-common.c:534
#4  0x10088630 in pex_get_status (obj=0x1015efc0, 
count=, vector=0x3fffd7e0)
at ../../gcc/libiberty/pex-common.c:554
#5  0x100101dc in execute () at ../../gcc/gcc/gcc.c:3107
#6  0x10010f04 in do_spec_1 (
spec=0x1015ec20 "-o %|.s |\n as %(asm_options) %m.s %A", inswitch=0, 
soft_matched_part=0x0) at ../../gcc/gcc/gcc.c:5145
#7  0x100139e4 in process_brace_body (matched=, 
starred=0, end_atom=0x1015ed3c ":-o %|.s |\n as %(asm_options) %m.s %A }", 
atom=0x1015ed3b "S:-o %|.s |\n as %(asm_options) %m.s %A }", 
p=0x1015ed62 "}") at ../../gcc/gcc/gcc.c:6431
#8  handle_braces (p=) at ../../gcc/gcc/gcc.c:6345
#9  0x10011604 in do_spec_1 (
spec=0x1015ecf0 "  
%{fcompare-debug=*|fdump-final-insns=*:%:compare-debug-dump-opt()}   %{!S:-o
%|.s |\n as %(asm_options) %m.s %A }", inswitch=0, 
soft_matched_part=0x0) at ../../gcc/gcc/gcc.c:5802
#10 0x100139e4 in process_brace_body (matched=, 
starred=1, 
end_atom=0x100a877f "*:  
%{fcompare-debug=*|fdump-final-insns=*:%:compare-debug-dump-opt()}   %{!S:-o
%|.s |\n as %(asm_options) %m.s %A }  }", 
atom=0x100a877b "fwpa*:  
%{fcompare-debug=*|fdump-final-insns=*:%:compare-debug-dump-opt()}   %{!S:-o
%|.s |\n as %(asm_options) %m.s %A }  }", 
p=0x100a87f6 "}") at ../../gcc/gcc/gcc.c:6431
#11 handle_braces (p=) at ../../gcc/gcc/gcc.c:6345
#12 0x10011604 in do_spec_1 (
spec=0x100a8778 "%{!fwpa*:  
%{fcompare-debug=*|fdump-final-insns=*:%:compare-debug-dump-opt()}   %{!S:-o
%|.s |\n as %(asm_options) %m.s %A }  }", 
inswitch=0, soft_matched_part=0x0) at ../../gcc/gcc/gcc.c:5802
#13 0x10011228 in do_spec_1 (spec=0x1015ec90 "%(invoke_as)", 
inswitch=0, soft_matched_part=0x0) at ../../gcc/gcc/gcc.c:5917
#14 0x100139e4 in process_brace_body (matched=, 
starred=0, end_atom=0x1015ec04 ":%(invoke_as)}", 
atom=0x1015ebf8 "fsyntax-only:%(invoke_as)}", p=0x1015ec11 "}")
at ../../gcc/gcc/gcc.c:6431
#15 handle_braces (p=) at ../../gcc/gcc/gcc.c:6345
#16 0x10011604 in do_spec_1 (
spec=0x1015ebd0 "cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)}", inswitch=0, soft_matched_part=0x0) at
../../gcc/gcc/gcc.c:5802
#17 0x100139e4 in process_brace_body (matched=, 
starred=0, 
end_atom=0x1015eb74 ":cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)}}", 
atom=0x1015eb73 "E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)}}", p=0x1015ebb7 "}") at ../../gcc/gcc/gcc.c:6431
#18 handle_braces (p=) at ../../gcc/gcc/gcc.c:6345
#19 0x10011604 in do_spec_1 (
spec=0x1015eb70 "%{!E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)}}", inswitch=0, soft_matched_part=0x0) at
../../gcc/gcc/gcc.c:5802
#20 0x100139e4 in process_brace_body (matched=, 
starred=0, 
end_atom=0x1015eb15 ":%{!E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)}}}", 
atom=0x1015eb13 "MM:%{!E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)}}}", p=0x1015eb5e "}") at ../../gcc/gcc/gcc.c:6431
#21 handle_braces (p=) at ../../gcc/gcc/gcc.c:6345
#22 0x10011604 in do_spec_1 (
spec=0x1015eb10 "%{!MM:%{!E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)}}}", inswitch=0, soft_matched_part=0x0)
at ../../gcc/gcc/gcc.c:5802
#23 0x100139e4 in process_brace_body (matched=, 
starred=0, 
end_atom=0x100a789c ":%{!MM:%{!E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)", 
atom=0x100a789b "M:%{!MM:%{!E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)", p=0x100a78ec "}") at
../../gcc/gcc/gcc.c:6431
#24 handle_braces (p=) at ../../gcc/gcc/gcc.c:6345
#25 0x10011604 in do_spec_1 (
spec=0x100a7898 "%{!M:%{!MM:%{!E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)", inswitch=0, soft_matched_part=0x0)
at ../../gcc/gcc/gcc.c:5802
#26 0x10012878 in do_spec_2 (spec=)
at ../../gcc/gcc/gcc.c:4841
#27 0x10014514 in do_spec (spec=)
at ../../gcc/gcc/gcc.c:4808
#28 0x1001479c in driver::do_spec_on_infiles (this=0x3108)
at ../../gcc/gcc/gcc.c:8076
#29 0x10003138 in driver::main 

[Bug middle-end/70159] missed CSE optimization

[anton at samba dot org]

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

Anton Blanchard  changed:

   What|Removed |Added

 CC||anton at samba dot org

--- Comment #15 from Anton Blanchard  ---
Created attachment 38890
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38890=edit
test case

[Bug testsuite/71865] New: [7 regression] test case gcc.dg/diagnostic-token-ranges.c fails starting with r237714

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 71865
   Summary: [7 regression] test case
gcc.dg/diagnostic-token-ranges.c fails starting with
r237714
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

FAIL: gcc.dg/diagnostic-token-ranges.c (test for excess errors)
Excess errors:
   bool


The text of some of the diagnostic messages changed and this test case needs to
be updated to better match.

One example (there are a couple) with r237713 a message was

/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/diagnostic-token-ranges.c:20:3:
error: unknown type name 'foo'
   foo bar; /* { dg-error "unknown type name 'foo'" } */
   ^~~


And then after r237714

home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/diagnostic-token-ranges.c:21:3:
error: unknown type name 'foo'; did you mean 'bool'?
   foo bar; /* { dg-error "unknown type name 'foo'" } */
   ^~~
   bool

The "bool" on the last line seems to be causing the problem.

[Bug debug/71864] x86_64-w64-mingw32, ICE when '-Og' & '-mssse3' are used simultaneously

[i.nixman at autistici dot org]

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

--- Comment #1 from niXman  ---
This error does not occur if '-Og' is excluded. Also this error does not occur
when '-O0' is used.

[Bug fortran/71862] [4.9/5/6/7 Regression] ICE in gfc_add_component_ref, at fortran/class.c:241

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-13
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |4.9.4
Summary|ICE in  |[4.9/5/6/7 Regression] ICE
   |gfc_add_component_ref, at   |in gfc_add_component_ref,
   |fortran/class.c:241 |at fortran/class.c:241
 Ever confirmed|0   |1

--- Comment #4 from Martin Liška  ---
The ICE started with GCC 4.7

[Bug fortran/71861] [4.9/5/6/7 Regression] ICE in write_symbol(): bad module symbol

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-13
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |4.9.4
Summary|ICE in write_symbol(): bad  |[4.9/5/6/7 Regression] ICE
   |module symbol   |in write_symbol(): bad
   ||module symbol
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, started with GCC 4.9 branch.

[Bug fortran/71860] [4.9/5/6/7 Regression] ICE on pointing to null(mold), verify_gimple failed

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-13
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |4.9.4
Summary|ICE on pointing to  |[4.9/5/6/7 Regression] ICE
   |null(mold), verify_gimple   |on pointing to null(mold),
   |failed  |verify_gimple failed
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with GCC 4.8.x

[Bug debug/71864] New: x86_64-w64-mingw32, ICE when '-Og' & '-mssse3' are used simultaneously

[i.nixman at autistici dot org]

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

Bug ID: 71864
   Summary: x86_64-w64-mingw32, ICE when '-Og' & '-mssse3' are
used simultaneously
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i.nixman at autistici dot org
  Target Milestone: ---

#include 

__attribute__ ((__sysv_abi__))
int foo(__m128i a)
{
return(0);
}


This error occurs when this code compiled as C and C++.

>gcc -Og -mssse3 foo.c
> foo.c: In function 'foo':
> foo.c:8:1: internal compiler error: in ix86_compute_frame_layout, at 
> config/i386/i386.c:11401

[Bug fortran/71862] ICE in gfc_add_component_ref, at fortran/class.c:241

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
F08:C407 An entity declared with the CLASS keyword shall be a dummy argument
 or have the ALLOCATABLE or POINTER attribute.

[Bug c++/56856] the location of Wformat warnings points *after* the format string

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
I thought I'd look into this bug since it affects the testing of my patch for
bug 49905 and I'm finding out that it seems to be a general problem with C++
and function arguments.  From what I can see, the C front end tracks the
locations of function arguments through the parser, passing them from function
to function, while the C++ front end doesn't.  Sadly, it doesn't look like a
simple fix...

$ cat xyz.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S
-Wall -Wextra -Wpedantic -Wformat -xc++ xyz.c
void f (int, int, int);

void g (void)
{
  f (0, "", 1);
}
xyz.c: In function ‘void g()’:
xyz.c:5:14: error: invalid conversion from ‘const char*’ to ‘int’
[-fpermissive]
   f (0, "", 1);
  ^
xyz.c:1:6: note:   initializing argument 2 of ‘void f(int, int, int)’
 void f (int, int, int);
  ^

[Bug fortran/71862] ICE in gfc_add_component_ref, at fortran/class.c:241

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Gerhard Steinmetz from comment #0)
> Release versions (5, 6, 7) are bailed out, with no backtrace.
> Experimental versions (6, 7 tested) give a backtrace.
> 
> 
> $ cat z1.f90
> program p
>type t
>   integer :: n = 0
>   integer, pointer :: q => null()
>end type
>type(t) :: x
>print *, associated(x%q)
>x = f()
>print *, associated(x%q)
> contains
>function f() result (z)
>   class(t) :: z
>   print *, associated(z%q)
>end
> end
> 
> 
> 
> $ gfortran-6 z1.f90
> z1.f90:11:26:
> 
> function f() result (z)
>   1
> Error: CLASS variable 'z' at (1) must be dummy, allocatable or pointer
> (null):0: confused by earlier errors, bailing out
> 
> 
> 
> $ gfortran-7-20160710 z1.f90
> z1.f90:11:26:
> 
> function f() result (z)
>   1
> Error: CLASS variable 'z' at (1) must be dummy, allocatable or pointer

Index: resolve.c
===
--- resolve.c   (revision 238185)
+++ resolve.c   (working copy)
@@ -11440,8 +11440,9 @@ resolve_fl_var_and_proc (gfc_symbol *sym
 and excepted from the test.  */
   if (!sym->attr.class_ok && !sym->attr.use_assoc && !sym->assoc)
{
- gfc_error ("CLASS variable %qs at %L must be dummy, allocatable "
-"or pointer", sym->name, >declared_at);
+ gfc_error ("CLASS variable %qs at %L shall be a dummy argument "
+"or have the POINTER or ALLOCATABLE attribute",
+sym->name, >declared_at);
  return false;
}
 }
Index: class.c
===
--- class.c (revision 238185)
+++ class.c (working copy)
@@ -238,12 +238,14 @@ gfc_add_component_ref (gfc_expr *e, cons
 /* Avoid losing memory.  */
 gfc_free_ref_list (*tail);
   c = gfc_find_component (derived, name, true, true, tail);
-  gcc_assert (c);
-  for (ref = *tail; ref->next; ref = ref->next)
-;
-  ref->next = next;
-  if (!next)
-e->ts = c->ts;
+
+  if (c) {
+for (ref = *tail; ref->next; ref = ref->next)
+  ;
+ref->next = next;
+if (!next)
+  e->ts = c->ts;
+  }
 }

[Bug c++/56856] the location of Wformat warnings points *after* the format string

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-13
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.1.0, 7.0

--- Comment #4 from Martin Sebor  ---
Confirmed.  See the duplicate bug 71863 for another test case.

[Bug c++/71863] wrong column location in -Wformat in C++

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Sebor  ---
Bug 56856 already tracks this problem.

*** This bug has been marked as a duplicate of bug 56856 ***

[Bug c++/56856] the location of Wformat warnings points *after* the format string

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
*** Bug 71863 has been marked as a duplicate of this bug. ***

[Bug c++/71863] New: wrong column location in -Wformat in C++

[msebor at gcc dot gnu.org]

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

Bug ID: 71863
   Summary: wrong column location in -Wformat in C++
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When compiled in C mode, the following test emits warnings that point at each
of the problem directives:

$ cat xyz.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S
-Wformat xyz.c
void f (void)
{
  __builtin_printf ("%s%s", 0, 0);
}
xyz.c: In function ‘f’:
xyz.c:3:23: warning: format ‘%s’ expects argument of type ‘char *’, but
argument 2 has type ‘int’ [-Wformat=]
   __builtin_printf ("%s%s", 0, 0);
   ^
xyz.c:3:25: warning: format ‘%s’ expects argument of type ‘char *’, but
argument 3 has type ‘int’ [-Wformat=]
   __builtin_printf ("%s%s", 0, 0);
 ^

However, when compiled in C++ mode, the column information is wrong:

$ cat xyz.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S
-Wformat -xc++ xyz.c
void f (void)
{
  __builtin_printf ("%s%s", 0, 0);
}
xyz.c: In function ‘void f()’:
xyz.c:3:33: warning: format ‘%s’ expects argument of type ‘char*’, but argument
2 has type ‘int’ [-Wformat=]
   __builtin_printf ("%s%s", 0, 0);
 ^
xyz.c:3:33: warning: format ‘%s’ expects argument of type ‘char*’, but argument
3 has type ‘int’ [-Wformat=]

The same problem occurs with other directives.  I found a long discussion of
some of the issues in bug 52952 but based on the patches referenced from there
it looks like they have been resolved (as least for C).

[Bug fortran/71862] ICE in gfc_add_component_ref, at fortran/class.c:241

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---

Works when "class" is changed to "type" ...


$ cat z2.f90
program p
   type t
  integer :: n = 0
  integer, pointer :: q => null()
   end type
   type(t) :: x
   print *, associated(x%q)
   x = f()
   print *, associated(x%q)
contains
   function f() result (z)
  type(t) :: z
  print *, associated(z%q)
   end
end


$ gfortran-7-20160710 z2.f90
$ a.out
 F
 F
 F

[Bug fortran/71862] New: ICE in gfc_add_component_ref, at fortran/class.c:241

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 71862
   Summary: ICE in gfc_add_component_ref, at fortran/class.c:241
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Release versions (5, 6, 7) are bailed out, with no backtrace.
Experimental versions (6, 7 tested) give a backtrace.


$ cat z1.f90
program p
   type t
  integer :: n = 0
  integer, pointer :: q => null()
   end type
   type(t) :: x
   print *, associated(x%q)
   x = f()
   print *, associated(x%q)
contains
   function f() result (z)
  class(t) :: z
  print *, associated(z%q)
   end
end



$ gfortran-6 z1.f90
z1.f90:11:26:

function f() result (z)
  1
Error: CLASS variable 'z' at (1) must be dummy, allocatable or pointer
(null):0: confused by earlier errors, bailing out



$ gfortran-7-20160710 z1.f90
z1.f90:11:26:

function f() result (z)
  1
Error: CLASS variable 'z' at (1) must be dummy, allocatable or pointer
f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:241
0x66ac54 gfc_add_component_ref(gfc_expr*, char const*)
../../gcc/fortran/class.c:241
0x6ead24 resolve_ordinary_assign
../../gcc/fortran/resolve.c:9751
0x6ead24 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10570
0x6eb272 resolve_codes
../../gcc/fortran/resolve.c:15667
0x6eb361 gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15701
0x6d668a resolve_all_program_units
../../gcc/fortran/parse.c:5853
0x6d668a gfc_parse_file()
../../gcc/fortran/parse.c:6105
0x718d12 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/71861] ICE in write_symbol(): bad module symbol

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
Side note :


$ cat z0.f90
module m
   abstract interface
  function abs(x)
 real :: abs, x
  end
   end interface
end


$ gfortran-6 -Wall z0.f90
z0.f90:3:6:

   function abs(x)
  1
Warning: 'abs' declared at (1) may shadow the intrinsic of the same name.  In
order to call the intrinsic, explicit INTRINSIC declarations may be required.
[-Wintrinsic-shadow]

[Bug fortran/71861] New: ICE in write_symbol(): bad module symbol

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 71861
   Summary: ICE in write_symbol(): bad module symbol
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

An interface with an alienated intrinsic name (or any other) :


$ cat z1.f90
module m
   intrinsic abs
   abstract interface
  function abs(x)
 real :: abs, x
  end
   end interface
end

$ cat z2.f90
module m
   abstract interface
  function abs(x)
 real :: abs, x
  end
   end interface
   intrinsic abs
end

$ cat z3.f90
module m
   abstract interface
  function f(x)
 real :: f, x
  end
   end interface
   intrinsic f
end


$ gfortran-6 z1.f90
f951: internal compiler error: write_symbol(): bad module symbol 'x'

#...

$ gfortran-7-20160710 z3.f90
f951: internal compiler error: write_symbol(): bad module symbol 'x'
0x6842f1 gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1312
0x6bc312 write_symbol
../../gcc/fortran/module.c:5563
0x6bc35b write_symbol1_recursion
../../gcc/fortran/module.c:5790
0x6bf185 write_symbol1
../../gcc/fortran/module.c:5823
0x6bf185 write_module
../../gcc/fortran/module.c:5967
0x6bf185 dump_module
../../gcc/fortran/module.c:6094
0x6bf3f7 gfc_dump_module(char const*, int)
../../gcc/fortran/module.c:6137
0x6d6d06 gfc_parse_file()
../../gcc/fortran/parse.c:6068
0x718d12 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/71859] ICE on same variable/subroutine name (verify_gimple failed)

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Gerhard Steinmetz from comment #0)
> When using the same name for a variable and a subroutine (invalid),
> experimental (--enable-checking=yes) versions 7, 6 and maybe older
> ones (not tested) give an ICE.
> No ICE for release versions 4.9, 5, 6, 7.
> 
> 
> $ cat z1.f90
> program p
>call s(1)
>x = abs(s)
> end
> subroutine s(n)
>print *, n
> end
> 

Index: check.c
===
--- check.c (revision 238185)
+++ check.c (working copy)
@@ -72,6 +72,11 @@ type_check (gfc_expr *e, int n, bt type)
 static bool
 numeric_check (gfc_expr *e, int n)
 {
+  /* Users sometime use a subroutine designator as an actual argument to
+ an intrinsic subprogram that expects an argument with a numeric type.  */
+  if (e->symtree->n.sym->attr.subroutine)
+goto bandaid;
+
   if (gfc_numeric_ts (>ts))
 return true;

@@ -86,6 +91,8 @@ numeric_check (gfc_expr *e, int n)
   return true;
 }

+bandaid:
+
   gfc_error ("%qs argument of %qs intrinsic at %L must be a numeric type",
 gfc_current_intrinsic_arg[n]->name, gfc_current_intrinsic,
 >where);

[Bug fortran/70842] [4.9/5/6/7 Regression] internal compiler error with character members within a polymorphic pointer

[gerhard.steinmetz.fort...@t-online.de]

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

Gerhard Steinmetz  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #4 from Gerhard Steinmetz  
---
ICE for both release and experimental :


$ gfortran-6 pr70842.f90
f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:241


$ gfortran-7-20160710 pr70842.f90
f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:241
0x66ac54 gfc_add_component_ref(gfc_expr*, char const*)
../../gcc/fortran/class.c:241
0x66ad47 gfc_get_len_component(gfc_expr*)
../../gcc/fortran/class.c:585
0x694cb9 do_simplify
../../gcc/fortran/intrinsic.c:4150
0x69e60c gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:4506
0x6e3e66 resolve_unknown_f
../../gcc/fortran/resolve.c:2718
0x6e3e66 resolve_function
../../gcc/fortran/resolve.c:3020
0x6e3e66 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6353
0x6e8a91 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10469
0x6e87eb gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:9520
0x6e8b9e gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10459
0x6eb272 resolve_codes
../../gcc/fortran/resolve.c:15667
0x6eb361 gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15701
0x6e9943 gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:6236
0x6e9943 resolve_block_construct
../../gcc/fortran/resolve.c:9405
0x6e9943 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10682
0x6e87eb gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:9520
0x6f2c67 resolve_select_type
../../gcc/fortran/resolve.c:8625
0x6e9261 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10678
0x6eb272 resolve_codes
../../gcc/fortran/resolve.c:15667
0x6eb177 resolve_codes
../../gcc/fortran/resolve.c:15652

[Bug fortran/71859] ICE on same variable/subroutine name (verify_gimple failed)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-13
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
> When using the same name for a variable and a subroutine (invalid),
> experimental (--enable-checking=yes) versions 7, 6 and maybe older
> ones (not tested) give an ICE.

Confirmed also for 4.9 and 5.

[Bug fortran/71860] New: ICE on pointing to null(mold), verify_gimple failed

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 71860
   Summary: ICE on pointing to null(mold), verify_gimple failed
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

ICE with experimental (--enable-checking=yes) versions 7, 6,
and maybe older.


$ cat z1.f90
program p
   class(*), pointer :: z
   z => null(z)
end


$ gfortran-6 -g -O0 -Wall -fcheck=all -fno-frontend-optimize z1.f90
$ a.out


$ gfortran-7 z1.f90# release
$ a.out


$ gfortran-7-20160710 z1.f90   # experimental
z1.f90:1:0:

 program p

Error: conversion of register to a different size
VIEW_CONVERT_EXPR(_1);

z = VIEW_CONVERT_EXPR(_1);
z1.f90:1:0: internal compiler error: verify_gimple failed
0xc48e8d verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.c:4879
0x9c9ec2 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:11710
0x9ca256 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:11798
0x8360b7 cgraph_node::analyze()
../../gcc/cgraphunit.c:625
0x839443 analyze_functions
../../gcc/cgraphunit.c:1086
0x83a128 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2543

[Bug fortran/71859] ICE on same variable/subroutine name (verify_gimple failed)

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #2 from Gerhard Steinmetz  
---
For completeness another ICE, only with dedicated option -ff2c.


$ gfortran-6 -ff2c z1.f90
z1.f90:2:0:

call s(1)

internal compiler error: in fold_convert_loc, at fold-const.c:2292



$ gfortran-7-20160710 -ff2c z1.f90
z1.f90:2:0:

call s(1)

internal compiler error: in fold_convert_loc, at fold-const.c:2289
0x943323 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2289
0x758a7f gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.c:6072
0x798674 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
../../gcc/fortran/trans-stmt.c:407
0x71c28a trans_code
../../gcc/fortran/trans.c:1755
0x74ac88 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6171
0x6d6860 translate_all_program_units
../../gcc/fortran/parse.c:5914
0x6d6860 gfc_parse_file()
../../gcc/fortran/parse.c:6120
0x718d12 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/71859] ICE on same variable/subroutine name (verify_gimple failed)

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---

Somehow detected when being a bit more explicit :


$ cat z3.f90
program p
   implicit none
   real :: s = 1.0
   real :: x
   call s(1)
   x = abs(s)
   print *, x
end
subroutine s(n)
   implicit none
   integer :: n
   print *, n
end


$ gfortran-7-20160710 z3.f90
z3.f90:3:12:

real :: s = 1.0
1
Error: 's' at (1) is not a VALUE
z3.f90:3:12:

real :: s = 1.0
1
z3.f90:5:12:

call s(1)
2
Error: 's' at (1) has a type, which is not consistent with the CALL at (2)
z3.f90:6:11:

x = abs(s)
   1
Error: 'a' argument of 'abs' intrinsic at (1) must be a numeric type

[Bug fortran/71859] New: ICE on same variable/subroutine name (verify_gimple failed)

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 71859
   Summary: ICE on same variable/subroutine name (verify_gimple
failed)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

When using the same name for a variable and a subroutine (invalid),
experimental (--enable-checking=yes) versions 7, 6 and maybe older
ones (not tested) give an ICE.
No ICE for release versions 4.9, 5, 6, 7.


$ cat z1.f90
program p
   call s(1)
   x = abs(s)
end
subroutine s(n)
   print *, n
end



$ gfortran-6 -g -O0 -Wall -fcheck=all -fno-frontend-optimize z1.f90
$ a.out
   1


$ gfortran-7-20160710 z1.f90
z1.f90:1:0:

 program p

Error: invalid types in conversion to floating point
real(kind=8)
void (*) (integer(kind=4) & restrict)
x = (real(kind=8)) s;
z1.f90:1:0: internal compiler error: verify_gimple failed
0xc48e8d verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.c:4879
0x9c9ec2 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:11710
0x9ca256 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:11798
0x8360b7 cgraph_node::analyze()
../../gcc/cgraphunit.c:625
0x839443 analyze_functions
../../gcc/cgraphunit.c:1086
0x83a128 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2543

[Bug fortran/71623] [5/6/7 Regression] Segfault when allocating deferred-length characters to size of a pointer

[vehre at gcc dot gnu.org]

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

--- Comment #9 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Wed Jul 13 17:30:58 2016
New Revision: 238308

URL: https://gcc.gnu.org/viewcvs?rev=238308=gcc=rev
Log:
gcc/fortran/ChangeLog:

2016-07-13  Andre Vehreschild  

Backport from trunk:
PR fortran/71623
* trans-stmt.c (gfc_trans_allocate): Add code of pre block of typespec
in allocate to parent block.

gcc/testsuite/ChangeLog:

2016-07-13  Andre Vehreschild  

Backport from trunk:
PR fortran/71623
* gfortran.dg/deferred_character_18.f90: New test.



Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_18.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-stmt.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/71856] [6/7 Regression] _GLIBCXX_DEBUG-mode breaks GNU parallel extension

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||5.3.0
   Target Milestone|--- |6.2
Summary|_GLIBCXX_DEBUG-mode breaks  |[6/7 Regression]
   |GNU parallel extension  |_GLIBCXX_DEBUG-mode breaks
   ||GNU parallel extension

--- Comment #6 from Jonathan Wakely  ---
(In reply to Michael Hamann from comment #4)
> Sorry for not including a test case, I thought from the description and the
> provided links the problem was clear enough but of course I should have
> known better. I've attached a minimal test case.

I'm better at understanding C++ than words sometimes :-)

I've changed  to do:

// Debug Mode implies checking assertions.
#ifdef _GLIBCXX_DEBUG
# define _GLIBCXX_ASSERTIONS 1
#endif

Which solves the missing expression with "#if _GLIBCXX_ASSERTIONS"

I've also changed  to use _GLIBCXX_PARALLEL_ASSERTIONS instead, so
those headers won't unintentionally enable assertions in the rest of the
library.

I'll make the same change on the gcc-6 branch shortly.

[Bug libstdc++/71856] _GLIBCXX_DEBUG-mode breaks GNU parallel extension

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Wed Jul 13 17:22:57 2016
New Revision: 238307

URL: https://gcc.gnu.org/viewcvs?rev=238307=gcc=rev
Log:
libstdc++/71856 Define _GLIBCXX_PARALLEL_ASSERTIONS

PR libstdc++/71856
* include/bits/c++config (_GLIBCXX_ASSERTIONS): Define to 1 not empty.
* include/parallel/compiletime_settings.h (_GLIBCXX_ASSERTIONS):
Rename to _GLIBCXX_PARALLEL_ASSERTIONS and make default value depend
on _GLIBCXX_ASSERTIONS.
* include/parallel/balanced_quicksort.h: Rename _GLIBCXX_ASSERTIONS.
Include  for sleep.
* include/parallel/losertree.h: Rename _GLIBCXX_ASSERTIONS.
* include/parallel/merge.h: Likewise.
* include/parallel/multiway_merge.h: Likewise.
* include/parallel/partition.h: Likewise.
* include/parallel/queue.h: Likewise.
* include/parallel/sort.h: Likewise.
* testsuite/25_algorithms/headers/algorithm/
parallel_algorithm_assert.cc: New.

Added:
   
trunk/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/parallel_algorithm_assert.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/c++config
trunk/libstdc++-v3/include/parallel/balanced_quicksort.h
trunk/libstdc++-v3/include/parallel/compiletime_settings.h
trunk/libstdc++-v3/include/parallel/losertree.h
trunk/libstdc++-v3/include/parallel/merge.h
trunk/libstdc++-v3/include/parallel/multiway_merge.h
trunk/libstdc++-v3/include/parallel/partition.h
trunk/libstdc++-v3/include/parallel/queue.h
trunk/libstdc++-v3/include/parallel/sort.h

[Bug libstdc++/71856] _GLIBCXX_DEBUG-mode breaks GNU parallel extension

[michael.hamann at kit dot edu]

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

--- Comment #4 from Michael Hamann  ---
Created attachment 38889
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38889=edit
Test case, try compiling with g++ -D_GLIBCXX_DEBUG testcase.cpp

Sorry for not including a test case, I thought from the description and the
provided links the problem was clear enough but of course I should have known
better. I've attached a minimal test case.

[Bug preprocessor/71851] Get more time granularity at preprocessing

[daniel.gutson at intel dot com]

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

--- Comment #8 from Daniel Gutson  ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to Daniel Gutson from comment #5)
> > This macro would change break reproduceability as much as __TIME__ does.
> 
> __TIME__ is now being warned on if requested (-Wdate-time), and can be
> changed
> through environment variables - SOURCE_DATE_EPOCH env var - and for
> -fcompare-debug SOURCE_DATE_EPOCH is set by the driver for both invocations
> the same.
> So, as you can see, there is a strong shift away from __DATE__/__TIME__.

OK, granted. I complain that build reproduceability is a specific requirement
for a particular audience of users; other users may need just the opposite and
IMVHO I think have the same right to claim it. This is of course a dead end
discussion we won't have here. We will implement this as a cpp plugin, so feel
free to close the issue.

[Bug target/71153] aarch64 LSE __atomic_fetch_and() generates inversion for constants

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
> I have not done a bootstrap/test yet but I can do it on a machine which has
> LSE support in a few minutes.

Note this patch causes many failures but none in gcc testing, only in libgomp
testing and in glibc itself.

[Bug preprocessor/71851] Get more time granularity at preprocessing

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Daniel Gutson from comment #5)
> This macro would change break reproduceability as much as __TIME__ does.

__TIME__ is now being warned on if requested (-Wdate-time), and can be changed
through environment variables - SOURCE_DATE_EPOCH env var - and for
-fcompare-debug SOURCE_DATE_EPOCH is set by the driver for both invocations the
same.
So, as you can see, there is a strong shift away from __DATE__/__TIME__.

[Bug preprocessor/71851] Get more time granularity at preprocessing

[daniel.gutson at intel dot com]

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

--- Comment #6 from Daniel Gutson  ---
(In reply to Richard Biener from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > Any kind of such code goes strongly against build reproduceability,
> > -fcompare-debug etc., so not sure it would be really appreciated, it is a
> > direction against various changes done in gcc lately.
> > I think if you need something like that just pass
> > -DRANDOM=`dd if=/dev/random bs=8 count=1 2>/dev/null | md5sum | awk '{print
> > $1}'`
> > or something similar.
> 
> I think he wants to have a new random value each time __RANDOM is "evaluated"
> (during C++ template instantiation - thus a preprocessor macro isn't really
> apppropriate).

Actually I don't. As I mention in my last comment, the macro should have the
same value during all compilation. I already wrote a compile-time PRNG (and
another layer that uses it), but please don't get biased by this fact.

[Bug preprocessor/71851] Get more time granularity at preprocessing

[daniel.gutson at intel dot com]

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

--- Comment #5 from Daniel Gutson  ---
The idea is that the macro expands always to the same value.
The final usage of this facility should not be of any matter to gcc, it will be
just another program.
This macro would change break reproduceability as much as __TIME__ does.
IOW, just another predefined macro that will be used in the program.
Anecdotically it will be used for randomization seeding.
Richard, what would __RANDOM__ expand to? Please see that I try to maintain
separated the use case from the functionality, a functionality that is already
present (getting time during preprocessing but with more precision).

[Bug c/71858] New: Surprising suggestions for misspellings

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 71858
   Summary: Surprising suggestions for misspellings
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

(from email)


$ cat /tmp/a.c
int main(int argc, char **argv)
{
  return bar();
}

$ ./xgcc -B. /tmp/a.c
/tmp/a.c: In function ‘main’:
/tmp/a.c:3:10: warning: implicit declaration of function ‘bar’; did you mean
‘carg’? [-Wimplicit-function-declaration]
   return bar();
  ^~~
  carg

Which is a bit misleading as I do not include any header file. Looks it finds a
builtin:
(gdb) p debug_tree(m_best_candidate)
 
QI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x768adc78
arg-types 
chain >>>
readonly nothrow public external built-in decl_6 QI file 
line 0 col 0
align 8 built-in BUILT_IN_NORMAL:BUILT_IN_CARG attributes >>

Well, I would expect it should consider __builtin_carg, but not carg.



I'm inclined to agree; I'll see if I can filter this better.

[Bug fortran/71623] [5/6/7 Regression] Segfault when allocating deferred-length characters to size of a pointer

[vehre at gcc dot gnu.org]

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

--- Comment #8 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Wed Jul 13 16:09:57 2016
New Revision: 238304

URL: https://gcc.gnu.org/viewcvs?rev=238304=gcc=rev
Log:
gcc/fortran/ChangeLog:

2016-07-13  Andre Vehreschild  

Backport from trunk:
PR fortran/71623
* trans-stmt.c (gfc_trans_allocate): Add code of pre block of typespec
in allocate to parent block.

gcc/testsuite/ChangeLog:

2016-07-13  Andre Vehreschild  

Backport from trunk:
PR fortran/71623
* gfortran.dg/deferred_character_17.f90: New test.



Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/deferred_character_17.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/trans-stmt.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug testsuite/71489] [7 regression] gcc.dg/tree-ssa/attr-hotcold-2.c FAILs

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
After r237605, the issues should be fixed? I can't reproduce it on
x86_64-linux.

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[boris at kolpackov dot net]

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

--- Comment #21 from Boris Kolpackov  ---
Speaking of possible fixes, I had this crazy idea, not sure if it is
technically possible though: what if libstdc++ throws some custom exception
that derives from both version of ios::failure? This way both old and new ABI
users will be able to catch it via the respective bases.

[Bug tree-optimization/71857] [7 Regression] gcc.dg/tree-ssa/ivopt_mult_4.c FAILs

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||amker.cheng at gmail dot com

--- Comment #3 from Martin Liška  ---
The difference is caused by increased average number of loop iterations (from 5
to 10), which caused a different selection of candidates:

before:
Selected IV set for loop 1 at
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_4.c:19, 5
avg niters, 0 expressions, 2 IVs:
Candidate 7:
  Var befor: p2_27
  Var after: p2_14
  Incr POS: orig biv
  IV struct:
Type:   long int *
Base:   p2_11(D) + 8
Step:   8
Object: (void *) p2_11(D)
Biv:N
Overflowness wrto loop niter:   Overflow
Candidate 9:
  Var befor: i_28
  Var after: i_15
  Incr POS: orig biv
  IV struct:
Type:   long unsigned int
Base:   16
Step:   16
Biv:N
Overflowness wrto loop niter:   No-overflow

after:
Selected IV set for loop 1 at
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_4.c:19,
10 avg niters, 0 expressions, 2 IVs:
Candidate 7:
  Var befor: p2_27
  Var after: p2_14
  Incr POS: orig biv
  IV struct:
Type:   long int *
Base:   p2_11(D) + 8
Step:   8
Object: (void *) p2_11(D)
Biv:N
Overflowness wrto loop niter:   Overflow
Candidate 10:
  Var befor: ivtmp.11_21
  Var after: ivtmp.11_29
  Incr POS: before exit test
  IV struct:
Type:   unsigned long
Base:   (unsigned long) (p_16(D) + 128)
Step:   128
Object: (void *) p_16(D)
Biv:N
Overflowness wrto loop niter:   Overflow

Replacing exit test: if (_22 > i_28)

Should I just amend the dump scan to cover the 'Replacing exit test' ?

[Bug tree-optimization/71857] [7 Regression] gcc.dg/tree-ssa/ivopt_mult_4.c FAILs

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 3
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3=edit
IVOPTS dump after the commit

[Bug tree-optimization/71857] [7 Regression] gcc.dg/tree-ssa/ivopt_mult_4.c FAILs

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 38887
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38887=edit
IVOPTS dump before the commit

[Bug tree-optimization/71857] New: [7 Regression] gcc.dg/tree-ssa/ivopt_mult_4.c FAILs

[marxin at gcc dot gnu.org]

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

Bug ID: 71857
   Summary: [7 Regression] gcc.dg/tree-ssa/ivopt_mult_4.c FAILs
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

It's caused by my commit r238252.

[Bug tree-optimization/71490] [7 regression] gcc.dg/tree-ssa/slsr-8.c FAILs

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
The r237185 revision really caused that one slsr opportunity is gone, however
there's still one remaining (-fno-tree-slsr vs -ftree-slsr) show:

   :
-  a2_15 = s_11(D) * 4;
-  _4 = (long unsigned int) a2_15;
-  _5 = _4 * 4;
-  _6 = -_5;
-  x2_16 = c_13(D) + _6;
+  x2_16 = x1_14 + _3;
   goto ;

I'm going to send patch to ML.

[Bug libstdc++/71856] _GLIBCXX_DEBUG-mode breaks GNU parallel extension

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-13
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
Ah I see. A testcase would have helped clarify that, as requested by
https://gcc.gnu.org/bugs

[Bug tree-optimization/24574] a!=0?a/10:0 is not reduced to a/10

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Wed Jul 13 13:57:05 2016
New Revision: 238299

URL: https://gcc.gnu.org/viewcvs?rev=238299=gcc=rev
Log:
2016-07-13  Richard Biener  

PR tree-optimization/24574
* tree-ssa-phiopt.c (absorbing_element_p): Pass in argument
position and add shift, rotate, divison and modulo support
for left zero.
(value_replacement): Pass in argument position to absorbing_element_p.

* gcc.dg/pr24574.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr24574.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-phiopt.c

[Bug tree-optimization/24574] a!=0?a/10:0 is not reduced to a/10

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

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

[Bug tree-optimization/24568] [meta-bug] Missed optimization: trivialization of silly code

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24568
Bug 24568 depends on bug 24574, which changed state.

Bug 24574 Summary: a!=0?a/10:0 is not reduced to a/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24574

   What|Removed |Added

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

[Bug target/71652] [4.9/5/6/7 Regression] ICE in in ix86_target_macros_internal, at config/i386/i386-c.c:187

[marxin at gcc dot gnu.org]

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

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

[Bug libstdc++/71856] _GLIBCXX_DEBUG-mode breaks GNU parallel extension

[michael.hamann at kit dot edu]

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

--- Comment #2 from Michael Hamann  ---
This is not about activating parallel mode, this is about using individual
parallel algorithms by directly including e.g.  and using
the namespace __gnu_parallel explicitly. There I do not get the error you
mention. Is this not supported, too?

[Bug target/71652] [4.9/5/6/7 Regression] ICE in in ix86_target_macros_internal, at config/i386/i386-c.c:187

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Thank you very much Jakub with the suggested hint.

I applied basically what you suggested and I'm wondering whether target macro
can really produce insane options that would eventually cause an ICE or another
misleading error?

As I've been playing with x86 target options I came to multiple question
(probably something we should fix):

1)
https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html#x86-Function-Attributes
section does no document all accepted values of target attribute:

fma
avx512f
avx512er
avx512cd
avx512pf
avx512dq
avx512bw
avx512vl
avx512ifma
avx512vbmi
3dnow
bmi
bmi2
lzcnt
hle
fxsr
rdseed
prfchw
adx
tbm
sha
fsgsbase
rdrnd
f16c
rtm
xsave
xsaveopt
prefetchwt1
clflushopt
xsavec
xsaves
clwb
pcommit
mwaitx

Suggestion: let's document them

2) on the other hand, ‘fused-madd’ and ‘no-fused-madd’ are document, but we
reject them:
tc.cc:2:33: error: attribute(target("fused-madd")) is unknown

probably because of:
./xg++ -B. tc.cc -mfused-madd
xg++: warning: ‘-mfused-madd’ is deprecated; use ‘-ffp-contract=’ instead

Suggestion: remove the option from documentation

3) There are ISA options that are not accepted:

3dnowa
movbe
crc32
mpx
clzero
pku

Suggestion: accept them?

[Bug libstdc++/71856] _GLIBCXX_DEBUG-mode breaks GNU parallel extension

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
You can't mix Debug Mode and Parallel Mode anyway. With previous versions you
get

In file included from /usr/include/c++/5.3.1/utility:68:0,
 from /usr/include/c++/5.3.1/algorithm:60,
 from par.cc:1:
/usr/include/c++/5.3.1/x86_64-redhat-linux/bits/c++config.h:2092:4: error:
#error illegal use of multiple inlined namespaces
 #  error illegal use of multiple inlined namespaces
^

Now you get that followed by a cascade of other errors, which should be fixed,
but you'll never be able to mix them.

[Bug libstdc++/71856] New: _GLIBCXX_DEBUG-mode breaks GNU parallel extension

[michael.hamann at kit dot edu]

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

Bug ID: 71856
   Summary: _GLIBCXX_DEBUG-mode breaks GNU parallel extension
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michael.hamann at kit dot edu
  Target Milestone: ---

When _GLIBCXX_DEBUG is defined, the recently introduced macro
_GLIBCXX_ASSERTIONS (see #56109) is defined as empty (see
https://github.com/gcc-mirror/gcc/blob/55174bb97660bbd9c27262bc48b6da88a1b4a18f/libstdc%2B%2B-v3/include/bits/c%2B%2Bconfig#L415).

Unfortunately, the new macro (_GLIBCXX_ASSERTIONS) was already in use in the
GNU parallel extension where it is always defined (see
https://github.com/gcc-mirror/gcc/blob/edd716b6b1caa1a5cb320a8cd7f626f30198e098/libstdc%2B%2B-v3/include/parallel/compiletime_settings.h#L58).
There almost all checks for it use a simple #if (without "defined"), see e.g.
https://github.com/gcc-mirror/gcc/blob/edd716b6b1caa1a5cb320a8cd7f626f30198e098/libstdc%2B%2B-v3/include/parallel/balanced_quicksort.h#L54.

When enabling _GLIBCXX_DEBUG, _GLIBCXX_ASSERTIONS is defined as empty, which
makes it impossible to compile code that uses the GNU parallel extension
(error: #if with no expression).

Further, the define of _GLIBCXX_ASSERTIONS to 0 in the GNU parallel extension
might enable assertions in other parts of the standard library unintentionally.

I encountered the bug in GCC 6.1.1, but the affected code seems to be unchanged
in the current trunk version (all code links point to the trunk version).

[Bug c/71855] duplicate unspecified_parameters DIE in DWARF for functions with variable arguments

[woodard at redhat dot com]

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

--- Comment #1 from Ben Woodard  ---
I just discovered (by mistake) that the problem does not seem to happen with
GCC 4.4.7.

[Bug preprocessor/71851] Get more time granularity at preprocessing

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Then command line macro + __COUNTER__ ?

[Bug preprocessor/71851] Get more time granularity at preprocessing

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #2)
> Any kind of such code goes strongly against build reproduceability,
> -fcompare-debug etc., so not sure it would be really appreciated, it is a
> direction against various changes done in gcc lately.
> I think if you need something like that just pass
> -DRANDOM=`dd if=/dev/random bs=8 count=1 2>/dev/null | md5sum | awk '{print
> $1}'`
> or something similar.

I think he wants to have a new random value each time __RANDOM is "evaluated"
(during C++ template instantiation - thus a preprocessor macro isn't really
apppropriate).

[Bug target/69880] Linking Windows resource + implicit 'default-manifest.o' creates bad .exe

[nickc at gcc dot gnu.org]

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

--- Comment #10 from Nick Clifton  ---
Created attachment 38885
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38885=edit
Proposed patch

[Bug target/69880] Linking Windows resource + implicit 'default-manifest.o' creates bad .exe

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-07-13
   Assignee|unassigned at gcc dot gnu.org  |nickc at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #9 from Nick Clifton  ---
Created attachment 38884
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38884=edit
Proposed patch

Hi,

  Thanks for the test case.  With that I was able to reproduce the problem
  and I think that I have a patch that can fix it.  Please could you test it
  for yourself and let me know if it works.  (I have uploaded two versions,
  one for the current FSF binutils mainline development sources, and one for
  the 2.25.1 release sources).

Cheers
  Nick

[Bug ipa/71624] [6 regression][CHKP] internal compiler error: in duplicate_thunk_for_node

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #5 from Ilya Enkovich  ---
Fixed

[Bug ipa/71624] [6 regression][CHKP] internal compiler error: in duplicate_thunk_for_node

[ienkovich at gcc dot gnu.org]

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

--- Comment #4 from Ilya Enkovich  ---
Author: ienkovich
Date: Wed Jul 13 12:19:44 2016
New Revision: 238295

URL: https://gcc.gnu.org/viewcvs?rev=238295=gcc=rev
Log:
gcc/

Backport from mainline r238086.
2016-07-07  Ilya Enkovich  

PR ipa/71624
* ipa-inline-analysis.c (compute_inline_parameters): Set
local.can_change_signature to false for intrumentation
thunk callees.

gcc/testsuite/

Backport from mainline r238086.
2016-07-07  Ilya Enkovich  

PR ipa/71624
* g++.dg/pr71624.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/pr71624.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/ipa-inline-analysis.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c/71855] New: duplicate unspecified_parameters DIE in DWARF for functions with variable arguments

[woodard at redhat dot com]

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

Bug ID: 71855
   Summary: duplicate unspecified_parameters DIE in DWARF for
functions with variable arguments
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: woodard at redhat dot com
  Target Milestone: ---

I was looking at the DWARF generated by GCC 6.1 for M4 and it emits two DIEs
for unspecified parameters. Before Dodji added special code to ignore this, it
confused libabigail and may confuse other DWARF consumers.

[  1a33]subprogram
 external (flag_present) 
 name (strp) "m4_error"
 decl_file(data1) 1
 decl_line(data1) 94
 prototyped   (flag_present) 
 low_pc   (addr) 0x00402d10 
 high_pc  (data8) 194 (0x00402dd2)
 frame_base   (exprloc) 
  [   0] call_frame_cfa
 GNU_all_call_sites   (flag_present) 
 sibling  (ref4) [  1aab]
 [  1a50]  formal_parameter
   name (strp) "status"
   decl_file(data1) 1
   decl_line(data1) 94
   type (ref4) [58]
   location (sec_offset) location list [   78e]
 [  1a5f]  formal_parameter
   name (strp) "errnum"
   decl_file(data1) 1
   decl_line(data1) 94
   type (ref4) [58]
   location (sec_offset) location list [   7c7]
 [  1a6e]  formal_parameter
   name (strp) "format"
   decl_file(data1) 1
   decl_line(data1) 94
   type (ref4) [d8]
   location (sec_offset) location list [   800]
 [  1a7d]  unspecified_parameters
 [  1a7e]  variable
   name (strp) "args"
   decl_file(data1) 1
   decl_line(data1) 96
   type (ref4) [   410]
   location (exprloc) 
[   0] fbreg -216
 [  1a8d]  unspecified_parameters
 [  1a8e]  GNU_call_site
   low_pc   (addr) 0x00402dad 
   abstract_origin  (ref4) [  1fba]
 [  1a9b]GNU_call_site_parameter
 location (exprloc) 
  [   0] reg8
 GNU_call_site_value  (exprloc) 
  [   0] GNU_entry_value:
[   0] reg1
 [  1aa2]GNU_call_site_parameter
 location (exprloc) 
  [   0] reg9
 GNU_call_site_value  (exprloc) 
  [   0] fbreg -216

See 1a7d 1a8d.

This was generated from compiling m4 from
ftp://ftp.gnu.org/gnu/m4/m4-1.4.17.tar.gz with GCC 6.1

I will work on making a smaller reproducer.

[Bug ipa/71633] [7 regression][CHKP] internal compiler error: in inline_call

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #3 from Ilya Enkovich  ---
Fixed

[Bug ipa/71633] [7 regression][CHKP] internal compiler error: in inline_call

[ienkovich at gcc dot gnu.org]

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

--- Comment #2 from Ilya Enkovich  ---
Author: ienkovich
Date: Wed Jul 13 11:02:15 2016
New Revision: 238290

URL: https://gcc.gnu.org/viewcvs?rev=238290=gcc=rev
Log:
gcc/

PR ipa/71633
* ipa-inline-transform.c (inline_call): Support
instrumented thunks.

gcc/testsuite/

PR ipa/71633
* g++.dg/pr71633.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr71633.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline-transform.c
trunk/gcc/testsuite/ChangeLog

[Bug preprocessor/71851] Get more time granularity at preprocessing

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Any kind of such code goes strongly against build reproduceability,
-fcompare-debug etc., so not sure it would be really appreciated, it is a
direction against various changes done in gcc lately.
I think if you need something like that just pass
-DRANDOM=`dd if=/dev/random bs=8 count=1 2>/dev/null | md5sum | awk '{print
$1}'`
or something similar.

[Bug tree-optimization/24574] a!=0?a/10:0 is not reduced to a/10

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
(In reply to rguent...@suse.de from comment #4)
> Yeah, but folding would happily create undefined behavior from, say,
> 
>  if (x != INT_MIN)
>x = x * -1;
> 
> as folding folds INT_MIN * -1 to INT_MIN (ok, maybe with TREE_OVERFLOW 
> set, but I'm not sure we want to rely on that).

The C++ front-end already relies on constant folding detecting undefined
behavior, so at least this case seems fine. But there may indeed be symbolic
cases where we would simplify the operation assuming that some undefined
behavior doesn't occur, while that is precisely what the condition was
protecting against... (though I have a hard time coming up with an example that
works with a single stmt) So fold may not be quite the right interface. Maybe
we should mark in some way the transformations that assume a restricted range,
so we can generate a limited version of fold where the reverse transformation
is safe. Not something for right now anyway.

[Bug preprocessor/71851] Get more time granularity at preprocessing

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
seeding from the current time sounds like a bad idea from a security
perspective.
why not __RANDOM__ or __SECURE_RANDOM__?

[Bug rtl-optimization/11832] Optimization of common stores in switch statements

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Note the testcase is flawed because c might point to b and thus the stores to
c[b] might clobber b itself.  Similar c might point to c itself and thus
clobber the pointer value.  This causes us to re-load both b and c after
each store.

Making b local and c a parameter avoids these issues:

int a, e;
void foo(unsigned char *c)
{
  int d = 13;
  int b = -1;
  switch (e) {
case 1:
b++; c[b] = (unsigned char)d;
break;
case 2:
b++; c[b] = (unsigned char)d;
b++; c[b] = (unsigned char)d;
break;
case 3:
b++; c[b] = (unsigned char)d;
b++; c[b] = (unsigned char)d;
b++; c[b] = (unsigned char)d;
break;
default:
a = 1;
b++; c[b] = (unsigned char)d;
b++; c[b] = (unsigned char)d;
b++; c[b] = (unsigned char)d;
b++; c[b] = (unsigned char)d;
  }
}

I have a patch to do some store merging during SSA code sinking but it doesn't
handle this case because the 1) the stores are ordered in the wrong way,
2) the CFG is not in proper form (I only handle common stores appearing in
all predecessors)

[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #13 from Richard Biener  ---
*** Bug 71736 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/71736] [7 Regression] ICE in verify_ssa

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from Richard Biener  ---
dup.

*** This bug has been marked as a duplicate of bug 71104 ***