[Bug c/78517] error: non-trivial conversion at assignment

[prathamesh3492 at gcc dot gnu.org]

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||prathamesh3492 at gcc dot 
gnu.org

--- Comment #1 from prathamesh3492 at gcc dot gnu.org ---
ICE can also be observed with following reduced test-case:

char a;
int fn1() { return a == '[' ? a : 0; }

pr78517.i: In function ‘fn1’:
pr78517.i:2:5: error: non-trivial conversion at assignment
 int fn1() { return a == '[' ? a : 0; }
 ^~~
int
char
iftmp.0 = 91;
pr78517.i:2:5: internal compiler error: verify_gimple failed
0xc09bbd verify_gimple_in_seq(gimple*)
../../gcc/gcc/tree-cfg.c:4926
0x956c52 gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:12445
0x957001 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:12534
0x7cb4a7 cgraph_node::analyze()
../../gcc/gcc/cgraphunit.c:626
0x7ce745 analyze_functions
../../gcc/gcc/cgraphunit.c:1087
0x7cf57c symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2562

Thanks,
Prathamesh

[Bug c++/78522] -O2 optimization confused by enum and pointer usage in constructors.

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #1 from Markus Trippelsdorf  ---
See https://gcc.gnu.org/ for supported releases.
4.8.4 isn't among them anymore.

[Bug c++/78522] New: -O2 optimization confused by enum and pointer usage in constructors.

[huangs at chromium dot org]

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

Bug ID: 78522
   Summary: -O2 optimization confused by enum and pointer usage in
constructors.
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: huangs at chromium dot org
  Target Milestone: ---

Created attachment 40145
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40145=edit
The source file and makefile.

g++ -O2 and -O3 can produce results different from unoptimized and -O1, under a
mixture of:
- enum usage
- pointer usage-  
- class initialization

Bug disappears when attempting to debug using fprintf().

Source and Makefile are attached, but for convenience here's the code:

#include 
#include 

enum ValueType : uint32_t {
  GOOD_VALUE = 0,
  BAD_VALUE
};

class Helper {
 public:
  Helper() {
flag = true;
  }

  void run(uint32_t* value) {
if (flag) {
  *value = GOOD_VALUE;
}
  }

  bool flag;
};

class Runner {
 public:
  Runner() : value_type(BAD_VALUE) {
Helper helper;
helper.run(reinterpret_cast(_type));

if (value_type == GOOD_VALUE) {
  fprintf(stderr, "Good!\n");  // Expected, works if non-optimized.
} else {
  fprintf(stderr, "Bad!\n");  // Unexpected, happens for -O2 and -O3.
}
  }

  // If we make this uint32_t, or make it local variable then bug disappears!
  ValueType value_type;
};

int main() {
  Runner runner;
  return 0;
}

[Bug fortran/70070] ICE on initializing character data beyond min/max bound

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Gerhard Steinmetz from comment #0)
> This code accidentally accesses invalid data :
> 
> 
> $ cat z1.f90
> program p
>integer :: i
>character(1) :: c
>data (c(i:i), i=1,11) /11*'c'/
> end
> 
> $ gfortran-6 z1.f90
> *** Error in `/usr/lib64/gcc/x86_64-suse-linux/6/f951': free(): invalid next
> size (fast): 0x029ac080 ***
> ...

This appears to be fixed on 5, 6, and trunk.  Can you please check
with updated versions of at least trunk?

[Bug fortran/78518] Warning format regression

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5
   Severity|normal  |enhancement

[Bug middle-end/78521] [7 Regression] incorrect byte count in -Wformat-length warning with non-constant width or precision

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Keywords||diagnostic, wrong-code
   Last reconfirmed||2016-11-25
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1
Summary|incorrect byte count in |[7 Regression] incorrect
   |-Wformat-length warning |byte count in
   |with non-constant width or  |-Wformat-length warning
   |precision   |with non-constant width or
   ||precision
   Target Milestone|--- |7.0

[Bug middle-end/78521] New: incorrect byte count in -Wformat-length warning with non-constant width or precision

[msebor at gcc dot gnu.org]

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

Bug ID: 78521
   Summary: incorrect byte count in -Wformat-length warning with
non-constant width or precision
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The gimple-ssa-sprintf pass doesn't correctly handle non-constant width and
precision fields in integer (and likely other) directives.  For example, in
function f below, the width is unknown but the warning indicates that GCC
thinks the function outputs exactly 3 bytes.  Worse, in function g, the
precision is known to be at least 4 but the return value is folded into a
constant 1 by the -fprintf-return-value optimization because GCC fails to take
into consideration that the precision can increase the size of output.

$ cat b.c && /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O2 -S -Wall
-fdump-tree-optimized=/dev/stdout b.c
char d[2];

int f (int w)
{
  return __builtin_sprintf (d, "%*i", w, 123);
}

int g (int p)
{
  if (p < 4)
p = 4;

  return __builtin_sprintf (d, "%.*i", p, 1);
}

b.c: In function ‘f’:
b.c:5:33: warning: ‘%*i’ directive writing 3 bytes into a region of size 2
[-Wformat-length=]
   return __builtin_sprintf (d, "%*i", w, 123);
 ^~~
b.c:5:10: note: format output 4 bytes into a destination of size 2
   return __builtin_sprintf (d, "%*i", w, 123);
  ^~~~

;; Function f (f, funcdef_no=0, decl_uid=1796, cgraph_uid=0, symbol_order=1)

f (int w)
{
  int _4;

   [100.0%]:
  _4 = __builtin_sprintf (, "%*i", w_2(D), 123); [tail call]
  return _4;

}



;; Function g (g, funcdef_no=1, decl_uid=1799, cgraph_uid=1, symbol_order=2)

g (int p)
{
   [100.0%]:
  p_6 = MAX_EXPR ;
  __builtin_sprintf (, "%.*i", p_6, 1);
  return 1;

}

[Bug tree-optimization/78476] snprintf(0, 0, ...) with known arguments not optimized away

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Optimization added in r242854.

[Bug tree-optimization/78476] snprintf(0, 0, ...) with known arguments not optimized away

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Thu Nov 24 22:45:18 2016
New Revision: 242854

URL: https://gcc.gnu.org/viewcvs?rev=242854=gcc=rev
Log:
PR tree-optimization/78476 - snprintf(0, 0, ...) with known arguments not
optimized away

gcc/testsuite/ChangeLog:

PR tree-optimization/78476
* gcc.dg/tree-ssa/builtin-sprintf-5.c: New test.

gcc/ChangeLog:

PR tree-optimization/78476
* gimple-ssa-sprintf.c (struct pass_sprintf_length::call_info):
Add a member.
(handle_gimple_call): Adjust signature.
(try_substitute_return_value): Remove calls to bounded functions
with zero buffer size whose result is known.
(pass_sprintf_length::execute): Adjust call to handle_gimple_call.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/78520] New: missing warning for snprintf with size greater than INT_MAX

[msebor at gcc dot gnu.org]

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

Bug ID: 78520
   Summary: missing warning for snprintf with size greater than
INT_MAX
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Wformat-length option diagnoses calls to snprintf that specify a buffer
size in excess of SIZE_MAX / 2.  But since the function cannot meaningfully
write more output than INT_MAX bytes, specifying a buffer larger than INT_MAX +
1 effectively disables any bounds checking done by it and is therefore likely a
mistake on the part of the caller.  The warning should treat any size greater
than the smaller of INT_MAX + 1 and SIZE_MAX / 2 as too large.

$ cat a.c && gcc -O2 -S -Wall -Wextra -Wpedantic a.c
void f (char *d, const char *s)
{
  __SIZE_TYPE__ n = __SIZE_MAX__ / 2 + 1;

  __builtin_snprintf (d, n, "%-s", s);
}

void g (char *d, const char *s)
{
  __SIZE_TYPE__ n = __INT_MAX__ + 1LU;

  __builtin_snprintf (d, n, "%-s", s);
}

a.c: In function ‘f’:
a.c:5:3: warning: specified destination size 9223372036854775808 too large
[-Wformat-length=]
   __builtin_snprintf (d, n, "%-s", s);
   ^~~

[Bug middle-end/78519] New: missing warning for sprintf %s with null pointer

[msebor at gcc dot gnu.org]

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

Bug ID: 78519
   Summary: missing warning for sprintf %s with null pointer
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In the following program GCC diagnoses with -Wformat the invalid call to
sprintf in f but misses the same problem in g because the checker runs too
early to see the null.  The problem could trivially be detected by the
gimple-ssa-sprintf pass.

$ cat a.c && /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O2 -S -Wall -Wextra
-Wpedantic a.c
char d[2];

void f (void)
{
  __builtin_sprintf (d, "%s", (char*)0);
}

void g (void)
{
  char *s = 0;
  __builtin_sprintf (d, "%s", s);
}

a.c: In function ‘f’:
a.c:5:3: warning: reading through null pointer (argument 3) [-Wformat=]
   __builtin_sprintf (d, "%s", (char*)0);
   ^

[Bug fortran/78518] New: Warning format regression

[physiker at toast2 dot net]

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

Bug ID: 78518
   Summary: Warning format regression
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: physiker at toast2 dot net
  Target Milestone: ---

When compiling the file t.f90 gfortran-7 prints the marker 1 under the second
argument. When the file is compiled by gfortran version 6 or earlier, the
marker is printed under the first argument, a, in the call to the subroutine s.

t.f90
program p
  real(4) a, b
  call s(a, b)
  print *, a, b
end program p
subroutine s(a, b)
  real(8) a, b
  a = 10.0
  b = 2*a
end subroutine s


gfortran-7 -W -Wall t.f90
t.f90:3:14:

   call s(a, b)
  1
Warning: Type mismatch in argument »a« at (1); passed REAL(4) to REAL(8)
[-Wargument-mismatch]

-*- mode: compilation; default-directory: "~/Downloads/linux_diagnose/" -*-
Compilation started at Thu Nov 24 22:37:50

gfortran-fsf-6  -W -Wall t.f90
t.f90:3:9:

   call s(a, b)
 1
Warning: Type mismatch in argument »a« at (1); passed REAL(4) to REAL(8)

[Bug libgomp/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL

[vogt at linux dot vnet.ibm.com]

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

--- Comment #14 from Dominik Vogt  ---
Is the dynamic variable stack area properly aligned?  Since sparc.h does not
define STACK_DYNAMIC_OFFSET it should be aligned to STACK_BONDARY, i.e. 64
bits.

[Bug rtl-optimization/77541] [7 Regression] wrong code with 512bit vectors of int128 @ -O1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug c/78517] New: error: non-trivial conversion at assignment

[dcb314 at hotmail dot com]

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

Bug ID: 78517
   Summary: error: non-trivial conversion at assignment
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 40144
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40144=edit
C source code

The attached C source code doesn't compile with recent revisions
of gcc trunk. It seems fine at revision 242740 and broken at 242818.
Note no optimiser.

$ ../results.242818/bin/gcc -c bug322.c
libcli.c: In function ‘cli_loop’:
libcli.c:1178:5: error: non-trivial conversion at assignment
int
unsigned char
iftmp.43 = 91;
libcli.c:1178:5: internal compiler error: verify_gimple failed
0xc64ffd verify_gimple_in_seq(gimple*)
../../trunk/gcc/tree-cfg.c:4926
0x96a3f4 gimplify_body(tree_node*, bool)
../../trunk/gcc/gimplify.c:12445
0x96a7c9 gimplify_function_tree(tree_node*)
../../trunk/gcc/gimplify.c:12534
0x79306f cgraph_node::analyze()
../../trunk/gcc/cgraphunit.c:626

$ ../results.242740/bin/gcc -c bug322.c
$

[Bug preprocessor/78497] compiling with -save-temps adds -Wimplicit-fallthrough warnings

[aoliva at gcc dot gnu.org]

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

--- Comment #3 from Alexandre Oliva  ---
One aspect to the problem is the extra warnings you get.  As more and more
projects adopt -Werror by default, it means you get a different error with
-save-temps.  That's bad for users and inconvenient for ourselves.

Now the real kicker is that -save-temps is the standard, recommended way for
users to report bugs.  As preprocessing now discards information that feeds
into compiler decisions, the odds of some other divergence that is more likely
to affect small details in the compilation to the point of no longer triggering
hard-to-hit bugs grows.  That would is a very unfortunate outcome for a problem
that has an easy-ish solution described in the bug report description.

[Bug fortran/78500] ICE in gfc_check_vardef_context, at fortran/expr.c:5289

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Fixed on 5-branch, 6-branch, and trunk.

[Bug lto/50147] LTO: Segmentation fault in infinite_empty_loop_p

[d.g.gorbachev at gmail dot com]

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

Dmitry Gorbachev  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from Dmitry Gorbachev  ---
I can't test it. Let's hope that it works well now.

[Bug target/51726] LTO and attribute 'selectany'

[d.g.gorbachev at gmail dot com]

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

Dmitry Gorbachev  changed:

   What|Removed |Added

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

--- Comment #11 from Dmitry Gorbachev  ---
Likely fixed, closing the report.

[Bug fortran/78500] ICE in gfc_check_vardef_context, at fortran/expr.c:5289

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Nov 24 20:11:49 2016
New Revision: 242849

URL: https://gcc.gnu.org/viewcvs?rev=242849=gcc=rev
Log:
2016-11-24  Steven G. Kargl  

PR fortran/78500
* expr.c (gfc_check_vardef_contextm): Fix NULL pointer dereference.
* interface.c (matching_typebound_op): Ditto.

2016-11-24  Steven G. Kargl  

PR fortran/78500
* gfortran.dg/class_result_4.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/class_result_4.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/expr.c
branches/gcc-5-branch/gcc/fortran/interface.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug pch/78508] valgrind error in gt_pch_note_object when compiling C++

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Minimal test-case:

enum { _ISdigit = 8 ? 3 << 8 : 8, _ISpunct };
struct A {
  static const short a = _ISpunct;
};

Reporting:

==85314== Invalid read of size 1
==85314==at 0x4C2B944: strlen (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==85314==by 0xB20BB6: gt_pch_note_object(void*, void*, void (*)(void*,
void*, void (*)(void*, void*), void*)) (ggc-common.c:285)
==85314==by 0xA3DADA: gt_pch_nx (vec.h:1128)
==85314==by 0xA3DADA: gt_pch_nx_vec_dw_attr_node_va_gc_(void*)
(gt-dwarf2out.h:908)
==85314==by 0xA3DB5E: gt_pch_nx_die_struct(void*) (gt-dwarf2out.h:680)
==85314==by 0xA3DB7A: gt_pch_nx_die_struct(void*) (gt-dwarf2out.h:682)
==85314==by 0xA3DB7A: gt_pch_nx_die_struct(void*) (gt-dwarf2out.h:682)
==85314==by 0xA31642: pch_nx (hash-traits.h:242)
==85314==by 0xA31642: gt_pch_nx (hash-table.h:1064)
==85314==by 0xA31642: gt_pch_nx_hash_table_decl_die_hasher_(void*)
(gt-dwarf2out.h:1021)
==85314==by 0xB213BD: gt_pch_save(_IO_FILE*) (ggc-common.c:437)
==85314==by 0x924955: c_common_write_pch() (c-pch.c:183)
==85314==by 0x770CC7: c_parse_final_cleanups() (decl2.c:4462)
==85314==by 0xDD100E: compile_file() (toplev.c:463)
==85314==by 0x65FCBB: do_compile (toplev.c:1983)
==85314==by 0x65FCBB: toplev::main(int, char**) (toplev.c:2117)
==85314==  Address 0x6362122 is not stack'd, malloc'd or (recently) free'd

[Bug rtl-optimization/77541] [7 Regression] wrong code with 512bit vectors of int128 @ -O1

[vmakarov at gcc dot gnu.org]

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

--- Comment #5 from Vladimir Makarov  ---
Author: vmakarov
Date: Thu Nov 24 19:54:27 2016
New Revision: 242848

URL: https://gcc.gnu.org/viewcvs?rev=242848=gcc=rev
Log:
2016-11-24  Vladimir Makarov  

PR rtl-optimization/77541
* lra-constraints.c (struct input_reload): Add field match_p.
(get_reload_reg): Check modes of input reloads to generate unique
value reload pseudo.
(match_reload): Add input reload pseudo for the current insn.

2016-11-24  Vladimir Makarov  

PR rtl-optimization/77541
* gcc.target/i386/pr77541.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr77541.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/78500] ICE in gfc_check_vardef_context, at fortran/expr.c:5289

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Nov 24 19:26:33 2016
New Revision: 242847

URL: https://gcc.gnu.org/viewcvs?rev=242847=gcc=rev
Log:
2016-11-24  Steven G. Kargl  

PR fortran/78500
* expr.c (gfc_check_vardef_contextm): Fix NULL pointer dereference.
* interface.c (matching_typebound_op): Ditto.

2016-11-24  Steven G. Kargl  

PR fortran/78500
* gfortran.dg/class_result_4.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/class_result_4.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/expr.c
branches/gcc-6-branch/gcc/fortran/interface.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

[pinskia at gcc dot gnu.org]

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

Bug 31096 Summary: a*C == b*C where C is a constant is not optimized to a == b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31096

   What|Removed |Added

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

[Bug middle-end/31096] a*C == b*C where C is a constant is not optimized to a == b

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Fixed.

[Bug tree-optimization/39683] -fstrict-overflow misses multiply in comparison

[pinskia at gcc dot gnu.org]

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

Bug 31096 Summary: a*C == b*C where C is a constant is not optimized to a == b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31096

   What|Removed |Added

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

[Bug c/78512] [7 Regression] r242674 miscompiles Linux kernel

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
The show_tx_maxrate and show_trans_timeout functions mentioned in the listing
in comment #1 are defined in Linux's net/core/net-sysfs.c.  They return
"sprintf(buf, "%lu\n", queue->tx_maxrate)"  and "sprintf(buf, "%lu",
trans_timeout)" respectively.  Based on the assembly it looks like GCC
determined their argument to be a positive number less than 10 and substituted
it for the function's actual return value.  I don't see anything wrong with
that and it's unlikely that the implementation of integer formatting in the
kernel is different than what C specifies, or that there's a bug in this area
in GCC.

But the printf code in the kernel (x86/boot/printf.c) that formats pointers
does look like it will produce significantly different output than GCC expects
from Glibc on Linux.  Glibc formats non-null pointers the same as integers
using the "%#zx" directive, and null as "(nil)".  Linux uses "%08zx" for all of
them (in LP64).

The printf implementation elsewhere in Linux (lib/vsprintf.c) has a comment it
follows C99 but has many %p extensions.  When that one is used, GCC should
probably bail when %p is encountered.  Alternatively, GCC could add support for
the kernel %p extensions and provide an option to turn them on.  I count 2,364
occurrences of %p in Linux .c files, and 4,486 integer directives, with 1,135
format strings containing both.  So it seems that to let the kernel fully
benefit from the -Wformat-length and -fprintf-return-value options, we should
consider adding support for the extended %p directives.

[Bug fortran/78500] ICE in gfc_check_vardef_context, at fortran/expr.c:5289

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Nov 24 18:27:58 2016
New Revision: 242846

URL: https://gcc.gnu.org/viewcvs?rev=242846=gcc=rev
Log:
2016-11-24  Steven G. Kargl  

PR fortran/78500
* expr.c (gfc_check_vardef_contextm): Fix NULL pointer dereference.
* interface.c (matching_typebound_op): Ditto.

2016-11-24  Steven G. Kargl  

PR fortran/78500
* gfortran.dg/class_result_4.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/class_result_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/78513] [7 Regression] Failure to build linux kernel with KASAN support

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #2)
> Does kernel enable -fsanitize-use-after-scope now?

Selecting CONFIG_KASAN=y enables -fsanitize=address, which currently be default
enables -fsanitize-address-use-after-scope.

[Bug target/67822] OpenMP offloading to nvptx fails

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||amonakov at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Alexander Monakov  ---
.

[Bug target/67822] OpenMP offloading to nvptx fails

[amonakov at gcc dot gnu.org]

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

--- Comment #3 from Alexander Monakov  ---
Author: amonakov
Date: Thu Nov 24 18:10:42 2016
New Revision: 242842

URL: https://gcc.gnu.org/viewcvs?rev=242842=gcc=rev
Log:
Allow -fopenmp in NVPTX mkoffload

PR target/67822
* config/nvptx/mkoffload.c (main): Allow -fopenmp.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/mkoffload.c

[Bug c/78512] [7 Regression] r242674 miscompiles Linux kernel

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-11-24
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
I have yet to look into the details of this issue but just a quick clarifying
comment:

-fprintf-return-value is almost entirely based on the C requirements, with the
exception of %p where it does make use of its knowledge of the underlying
implementation.  The option cannot match a non-conforming implementation
without a corresponding target hook that describes it so when one is being
targeted the options should not be used  The option should be disabled
automatically when either -fno-builtin-sprintf or its equivalent such
-ffreestanding is specified (if it isn't it's a bug).

That said, I don't think the Linux kernel uses either of these options.  That
suggests that the Linux printf should be conforming and the miscompilation may
be a bug.  Otherwise, it the Linux printf isn't conforming and we want it to
benefit from the option (as I would expect us to since the request for the
related -Wformat-length warning came from someone either contributing to or
building the kernel) GCC might want to add a target hook describing the Linux
printf specifics and a new option and to let the kernel enable it.

[Bug ipa/78515] [7 Regression] ICE: in fold_binary_loc, at fold-const.c:8999 with -Os -mavx512bw

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
I think the bug is in compute_complex_assign_jump_func, it assumes that all 2+
operand GIMPLE_ASSIGNs are arithmetics (doesn't even consider 3 operand ones).
So it happily records BIT_INSERT_EXPR that has 3 operands, but just checks 2 of
those operands.
I've also noticed in tree.def
DEFTREECODE (BIT_INSERT_EXPR, "bit_field_insert", tcc_expression, 3)
I would have expected "bit_insert_expr".

[Bug target/78516] New: [7 Regression] ICE in lra_assign for e500v2

[jsm28 at gcc dot gnu.org]

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

Bug ID: 78516
   Summary: [7 Regression] ICE in lra_assign for e500v2
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-linux-gnuspe

Running gcc and g++ tests for powerpc-linux-gnuspe --enable-e500-double shows
the following ICE (177 times in the logs, but the output of each such failing
test appears more than once in the logs; this appears to be the biggest group
of failures in the test results).  Compile the following reduced test (which
compiles OK with GCC 6 branch) with -O0 or -O1 to see the ICE.

extern void exit (int);
extern void abort (void);

volatile double inf_cst = __builtin_inf ();
volatile double neg0 = -0.0, one = 1.0;

int
main (void)
{
  volatile double r;
  if (!__builtin_isinf (inf_cst))
abort ();
  r = __builtin_copysign (one, neg0);
  exit (0);
}

ice.i: In function 'main':
ice.i:15:1: internal compiler error: in lra_assign, at lra-assigns.c:1612
 }
 ^
0x9bdfb8 lra_assign()
/scratch/jmyers/glibc/many7/src/gcc/gcc/lra-assigns.c:1612
0x9b8b9d lra(_IO_FILE*)
/scratch/jmyers/glibc/many7/src/gcc/gcc/lra.c:2422
0x96deb1 do_reload
/scratch/jmyers/glibc/many7/src/gcc/gcc/ira.c:5381
0x96deb1 execute
/scratch/jmyers/glibc/many7/src/gcc/gcc/ira.c:5565
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/78458] [7 Regression] LRA ICE building libgcc for powerpc-linux-gnuspe e500v2

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #14 from Joseph S. Myers  ---
Fixed by the given commit.

[Bug ipa/78515] [7 Regression] ICE: in fold_binary_loc, at fold-const.c:8999 with -Os -mavx512bw

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-24
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r236501.

[Bug ipa/78515] New: [7 Regression] ICE: in fold_binary_loc, at fold-const.c:8999 with -Os -mavx512bw

[zsojka at seznam dot cz]

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

Bug ID: 78515
   Summary: [7 Regression] ICE: in fold_binary_loc, at
fold-const.c:8999 with -Os -mavx512bw
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 40143
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40143=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Os -mavx512bw testcase.c
testcase.c:23:1: internal compiler error: in fold_binary_loc, at
fold-const.c:8999
 }
 ^
0x8abc6e fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/repo/gcc-trunk/gcc/fold-const.c:8996
0x152f1a5 ipa_get_jf_pass_through_result
/repo/gcc-trunk/gcc/ipa-cp.c:1233
0x1534c46 propagate_vals_accross_pass_through
/repo/gcc-trunk/gcc/ipa-cp.c:1572
0x1534c46 propagate_scalar_accross_jump_function
/repo/gcc-trunk/gcc/ipa-cp.c:1654
0x1534c46 propagate_constants_accross_call
/repo/gcc-trunk/gcc/ipa-cp.c:2257
0x1538900 propagate_constants_topo
/repo/gcc-trunk/gcc/ipa-cp.c:3162
0x1538900 ipcp_propagate_stage
/repo/gcc-trunk/gcc/ipa-cp.c:3272
0x153ad76 ipcp_driver
/repo/gcc-trunk/gcc/ipa-cp.c:5002
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -v   
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-242789-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-242789-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 7.0.0 20161123 (experimental) (GCC)

[Bug c/78512] [7 Regression] r242674 miscompiles Linux kernel

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The problem with -fprintf-return-value is that it pretty much hardcodes the
*printf* implementation details into GCC.  And on Linux it hardcodes them for
glibc, while the kernel has its own *printf* stuff and could behave slightly
differently.

[Bug sanitizer/78513] [7 Regression] Failure to build linux kernel with KASAN support

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Does kernel enable -fsanitize-use-after-scope now?

[Bug preprocessor/78169] internal compiler error: in get_substring_ranges_for_loc, at input.c:1379

[arnd at linaro dot org]

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

Arnd Bergmann  changed:

   What|Removed |Added

 CC||arnd at linaro dot org

--- Comment #4 from Arnd Bergmann  ---
Created attachment 40142
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40142=edit
preprocessed drivers/tty/nozomi.c from linux-4.9-rc5+next

I get the internal compiler error when I first preprocess the source, but not
when I build the same file directly:

$ /home/arnd/cross-gcc/bin/x86_64-linux-gcc-7.0.0 -Wall -O -Wno-pointer-sign -s
nozomi.i  
/git/arm-soc/drivers/tty/nozomi.c: In function 'interrupt_handler':
/git/arm-soc/drivers/tty/nozomi.c:1157:20: internal compiler error: in
get_substring_ranges_for_loc, at input.c:1388
 static irqreturn_t interrupt_handler(int irq, void *dev_id)
^
0x110f22f get_substring_ranges_for_loc
/home/arnd/git/gcc/gcc/input.c:1388
0x110f22f get_source_location_for_substring(cpp_reader*, string_concat_db*,
unsigned int, cpp_ttype, int, int, int, unsigned int*)
/home/arnd/git/gcc/gcc/input.c:1458
0x67230e c_get_substring_location(substring_loc const&, unsigned int*)
/home/arnd/git/gcc/gcc/c-family/c-common.c:865
0xa5ce8f substring_loc::get_location(unsigned int*) const
/home/arnd/git/gcc/gcc/substring-locations.c:194
0xa5ce8f format_warning_va(substring_loc const&, source_range const*, char
const*, int, char const*, __va_list_tag (*) [1])
/home/arnd/git/gcc/gcc/substring-locations.c:112
0xa5d1f4 format_warning_at_substring(substring_loc const&, source_range const*,
char const*, int, char const*, ...)
/home/arnd/git/gcc/gcc/substring-locations.c:179
0x1038159 add_bytes
/home/arnd/git/gcc/gcc/gimple-ssa-sprintf.c:2083
0x1038159 compute_format_length
/home/arnd/git/gcc/gcc/gimple-ssa-sprintf.c:2208
0x1038159 handle_gimple_call
/home/arnd/git/gcc/gcc/gimple-ssa-sprintf.c:2772
0x1038159 execute
/home/arnd/git/gcc/gcc/gimple-ssa-sprintf.c:2799

$ /home/arnd/cross-gcc/bin/x86_64-linux-gcc-7.0.0 --version
x86_64-linux-gcc-7.0.0 (GCC) 7.0.0 20161124 (experimental)

[Bug target/78509] [7 regression] ICE in in excess_precision_type, at tree.c:8875

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #8 from James Greenhalgh  ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to James Greenhalgh from comment #6)
> > None of the logic was there in the original code, so there is not much to
> > compare.
> 
> ??  Since -fexcess-precision=standard has been introduced, gcc has the
> excess precision notion.  So there is something to compare.
> E.g. try
> float foo (float x, float y, float z)
> {
>   return x + y + z;
> }
> before your changes with
> -fdump-tree-gimple -m32 -msse2 -mno-80387 -fexcess-precision=standard
> -fdump-tree-gimple -m32 -msse2 -mfpmath=387+sse -fexcess-precision=standard
> -fdump-tree-gimple -m32 -msse2 -mfpmath=387 -fexcess-precision=standard
> -fdump-tree-gimple -m32 -msse2 -mfpmath=sse -fexcess-precision=standard
> -fdump-tree-gimple -m32 -msse -mno-sse2 -mfpmath=sse
> -fexcess-precision=standard
> to match the different cases in your hook, and compare that to what you get
> with the current trunk.

Right, I think we might have been talking about comparing different things.
That works for a test of observable behaviour.

I've done what I suggested above, tested it as you suggested, and posted a fix
to the mailing list https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02568.html

[Bug sanitizer/78513] [7 Regression] Failure to build linux kernel with KASAN support

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||marxin at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Martin Liška  ---
We added new run-time functions to libsanitizer, which are being implemented by
linux kernel folk:

https://marc.info/?l=linux-mm=147922605130429=2

Thus I'm closing this as invalid.

[Bug target/66358] [5/6/7 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[dcb314 at hotmail dot com]

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

--- Comment #23 from David Binderman  ---
Problem seems to have gone away with gcc version 6.1.1, dated 20160621

[Bug c++/78514] New: ICE in tsubst, at cp/pt.c:13073

[doko at gcc dot gnu.org]

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

Bug ID: 78514
   Summary: ICE in tsubst, at cp/pt.c:13073
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

[forwarded from https://bugs.debian.org/845493]

seen with 4.8.5, 4.9.4, the 5 and 6 branches, and trunk r242638

$ cat index-sequence.cpp 
typedef long unsigned a;
template  struct b;
template  struct b { typedef p c; };
template  using e = typename b::c;
template  struct g;
template  struct h;
template  struct h> { using c = g; };
template  struct j;
template  struct j> {
  using c = g;
};
template  struct k;
template  struct k { using c = g; };
template  struct k {
  using c = typename h::c>::c;
};
template  struct k {
  using c = typename j::c>::c;
};
template  using m = typename k::c;
template  template  using n = g;
template  using o = m;
template  void increasing(n) {
  increasing(o<10>{});
}

$ g++ -c -std=c++11 index-sequence.cpp
index-sequence.cpp: In substitution of 'template void
increasing(n) [with long unsigned int i = 1ul]':
index-sequence.cpp:24:21:   required from here
index-sequence.cpp:23:21: internal compiler error: in tsubst, at cp/pt.c:13213
 template  void increasing(n) {
 ^~
0x682fde tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13213
0x69d1b6 tsubst_template_args
../../src/gcc/cp/pt.c:11410
0x69d362 tsubst_template_args
../../src/gcc/cp/pt.c:11370
0x681681 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13434
0x681af9 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13037
0x69adc2 tsubst_arg_types
../../src/gcc/cp/pt.c:12696
0x69b0ea tsubst_function_type
../../src/gcc/cp/pt.c:12830
0x6812f6 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13573
0x693c4c tsubst_decl
../../src/gcc/cp/pt.c:11991
0x681837 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13011
0x6a2d1f instantiate_template_1
../../src/gcc/cp/pt.c:17805
0x6a2d1f instantiate_template(tree_node*, tree_node*, int)
../../src/gcc/cp/pt.c:17861
0x6ae531 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../src/gcc/cp/pt.c:18241
0x6099f7 add_template_candidate_real
../../src/gcc/cp/call.c:3158
0x60a5bc add_template_candidate
../../src/gcc/cp/call.c:3240
0x60a5bc add_candidates
../../src/gcc/cp/call.c:5475
0x60d071 perform_overload_resolution
../../src/gcc/cp/call.c:4136
0x60f5ce build_new_function_call(tree_node*, vec**, bool, int)
../../src/gcc/cp/call.c:4221
0x7afcb9 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../src/gcc/cp/semantics.c:2440
0x72b1da cp_parser_postfix_expression
../../src/gcc/cp/parser.c:7017
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug target/44685] internal compiler error: in final_scan_insn, at final.c:2650 while compiling program with complex types

[dcb314 at hotmail dot com]

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

--- Comment #5 from David Binderman  ---
Seems fixed in gcc version 6.1.1, dated 20160621

[Bug libgomp/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Yes, sure, there are 2 alloca uses in the parallel region, one is for y
variable, which uses __builtin_alloca_with_align ((p4 - 1 + 1) * 4, 32) and the
other is for a, which uses __builtin_alloca_with_align ((p5 - 1 + 1) * 8, 32).
p4 is 3 and p5 is 4, so the former should be 12 bytes and the latter 32 bytes.
But at least in the *.optimized dump I don't see anything that would attempt to
write more, there is at most y[2].t and for a at most a[127 / 32].t.
So, can you find out how much each alloca actually aligns and if what writes
are to those areas?
Does it fail also with OMP_NUM_THREADS=1?

[Bug c/78512] [7 Regression] r242674 miscompiles Linux kernel

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
I run md5sum on the object files with and without -fno-printf-return-value.
Looking at a few files that differ they show a common pattern:

good vs bad diff:
@@ -312,7 +312,7 @@
movq$.LC1, %rsi
movq%rax, %rdi
callsprintf
-   cltq
+   movl$2, %eax
ret
.size   show_tx_maxrate, .-show_tx_maxrate
.section.rodata.str1.1
@@ -338,8 +338,8 @@
movq$.LC3, %rsi
movq%rbp, %rdi
callsprintf
+   movl$1, %eax
popq%rbx
-   cltq
popq%rbp
ret
.size   show_trans_timeout, .-show_trans_timeout
@@ -749,7 +749,7 @@
movq$fmt_u64, %rsi
movq%rbp, %rdi
callsprintf
-   cltq
+   movl$2, %eax
 .L121:
movl$-256, %edx
etc.

Not sure if this a valid transformation or even the root cause of the issue.

[Bug target/48863] A Bug When Assembler Instructions with C Expression Operands in arm-elf-gcc 4.5

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org
  Known to work||7.0
   Target Milestone|--- |7.0

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Fixed on trunk for GCC 7.
I'll wait for a bit before proposing a backport (if this is needed on the
branches)

[Bug libgomp/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL

[rdapp at linux dot vnet.ibm.com]

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

rdapp at linux dot vnet.ibm.com changed:

   What|Removed |Added

 CC||rdapp at linux dot vnet.ibm.com

--- Comment #12 from rdapp at linux dot vnet.ibm.com ---
(Writing from a colleagues machine ...)

Thinking about it, I'm quite sure the dynamic allocation must come from here:

>  #pragma omp parallel for reduction(*:y[:p4]) reduction(|:a[:p5])
^^  ^^

I.e. the bug should go awaz if you replace either p4 or p5 or both with the
numeric values.

Dominik ^_^  ^_^

[Bug inline-asm/70184] Explicit register variables holding function arguments overwritten by conversion libcall

[ktkachov at gcc dot gnu.org]

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Nov 24 15:22:34 2016
New Revision: 242840

URL: https://gcc.gnu.org/viewcvs?rev=242840=gcc=rev
Log:
[TER] PR target/48863 : Don't replace expressions across local register
variable definitions

PR target/48863
PR inline-asm/70184
* tree-ssa-ter.c (temp_expr_table): Add reg_vars_cnt field.
(new_temp_expr_table): Initialise reg_vars_cnt.
(free_temp_expr_table): Release reg_vars_cnt.
(process_replaceable): Add reg_vars_cnt argument, set reg_vars_cnt
field of TAB.
(find_replaceable_in_bb): Use the above to record register variable
write occurrences and cancel replacement across them.

* gcc.target/arm/pr48863.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/pr48863.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ter.c

[Bug target/48863] A Bug When Assembler Instructions with C Expression Operands in arm-elf-gcc 4.5

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Nov 24 15:22:34 2016
New Revision: 242840

URL: https://gcc.gnu.org/viewcvs?rev=242840=gcc=rev
Log:
[TER] PR target/48863 : Don't replace expressions across local register
variable definitions

PR target/48863
PR inline-asm/70184
* tree-ssa-ter.c (temp_expr_table): Add reg_vars_cnt field.
(new_temp_expr_table): Initialise reg_vars_cnt.
(free_temp_expr_table): Release reg_vars_cnt.
(process_replaceable): Add reg_vars_cnt argument, set reg_vars_cnt
field of TAB.
(find_replaceable_in_bb): Use the above to record register variable
write occurrences and cancel replacement across them.

* gcc.target/arm/pr48863.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/pr48863.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ter.c

[Bug c/78512] [7 Regression] r242674 miscompiles Linux kernel

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |7.0

[Bug sanitizer/78513] [7 Regression] Failure to build linux kernel with KASAN support

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||link-failure
 Target||aarch64-none-linux-gnu
  Known to work||6.2.1
   Target Milestone|--- |7.0
  Known to fail||7.0

[Bug sanitizer/78513] New: [7 Regression] Failure to build linux kernel with KASAN support

[ktkachov at gcc dot gnu.org]

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

Bug ID: 78513
   Summary: [7 Regression] Failure to build linux kernel with
KASAN support
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
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: ---

I'm trying to build the Linux kernel 4.8.10, downloaded from kernel.org using
an aarch64-none-linux-gnu trunk toolchain (r242837).
I'm building a defconfig kernel with the additional:
 CONFIG_KASAN=y
 CONFIG_KASAN_OUTLINE=y

in the .config file to enable KASAN.
This works with a GCC 6 compiler. With trunk this fails to link with many
undefined references, for example:
net/built-in.o: In function `ethtool_set_per_queue':
ncsi-manage.c:(.text+0x5e2a8): undefined reference to
`__asan_unpoison_stack_memory'
ncsi-manage.c:(.text+0x5e398): undefined reference to
`__asan_poison_stack_memory'

I guess this has something to do with the libsanitizer merge?

[Bug libgomp/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL

[vogt at linux dot vnet.ibm.com]

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

--- Comment #11 from Dominik Vogt  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #9)
> > 2) Replace "p7" in foo with just "7".  If it still fails we know the bug is 
> > not
> > triggered by the dynamic allocation of a or b.
> 
> ... but stays this way.

Good, the assembly diff has shrunk a lot:

--
@@ -8,7 +8,7 @@
ld  [%i0+4], %g4
add %g4, 1, %i3
sll %i3, 2, %g1
-   add %g1, 10, %g1
+   add %g1, 7, %g1 <--- add (8 - 1) bytes
and %g1, -8, %g1<--- round down to multiple of 8
mov 0, %g2
sub %sp, %g1, %sp
@@ -25,7 +25,6 @@
 add%g1, 4, %g1
add %g3, 1, %i2
sll %i2, 3, %g1
-   add %g1, 8, %g1 < -- what was this good for?
mov 0, %g2
sub %sp, %g1, %sp
add %sp, 96, %i5
--

The marked instructions in the first chunk do look like the calculations of the
dynamic stack area's address.  The reduced source code does not have dynamic
stack allocation, so that must come from libgomp.  The next step is to figure
out how libgomp generates instructions.  Can you provide tree dumps for both
Gccs?

[Bug middle-end/78153] strlen return value can be assumed to be less than PTRDIFF_MAX

[sch...@linux-m68k.org]

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

--- Comment #3 from Andreas Schwab  ---
Program received signal SIGSEGV, Segmentation fault.
vrp_val_max (type=0x0) at ../../gcc/tree-vrp.c:156
156   if (!INTEGRAL_TYPE_P (type))

[Bug rtl-optimization/78437] [7 Regression] invalid sign-extend conversion in REE pass

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #8 from Eric Botcazou  ---
Thanks for distilling the reduced testcase.

[Bug rtl-optimization/78437] [7 Regression] invalid sign-extend conversion in REE pass

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Nov 24 15:01:32 2016
New Revision: 242839

URL: https://gcc.gnu.org/viewcvs?rev=242839=gcc=rev
Log:
PR rtl-optimization/78437
* ree.c (get_uses): New function.
(combine_reaching_defs): When a copy is needed, return false if any
reaching use of the source register reads it in a mode larger than
the mode it is set in and WORD_REGISTER_OPERATIONS is true.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ree.c

[Bug middle-end/78153] strlen return value can be assumed to be less than PTRDIFF_MAX

[sch...@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab <sch...@linux-m68k.org> ---
This breaks ada on aarch64:

/opt/gcc/gcc-20161124/Build/./prev-gcc/xgcc
-B/opt/gcc/gcc-20161124/Build/./prev-gcc/ -B/usr/aarch64-suse-linux/bin/
-B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem
/usr/aarch64-suse-linux/include -isystem /usr/aarch64-suse-linux/sys-include   
-c -g -O2 -gtoggle  -gnatpg -gnata -W -Wall -nostdinc -I- -I. -Iada/generated
-Iada -I../../gcc/ada -I../../gcc/ada/gcc-interface ../../gcc/ada/osint.adb -o
ada/osint.o

raised STORAGE_ERROR : stack overflow or erroneous memory access
make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:119: ada/osint.o] Error
1

[Bug bootstrap/78493] profiledbootstrap failure: error: attempt to free a non-heap object 'names' in ../../gcc/cp/parser.c:11482:23

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed.

[Bug c/78512] New: [7 Regression] r242674 miscompiles Linux kernel

[trippels at gcc dot gnu.org]

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

Bug ID: 78512
   Summary: [7 Regression] r242674 miscompiles Linux kernel
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

Since r242674 the Linux kernel hits a BUG() during boot:

Kernel bug at net/core/skbuff.c:105
invalid opcode 
...

Adding -fno-printf-return-value to the CFLAGS "solves" the issue.

Not sure which file gets miscompiled, I only did a quick gcc bisection.

[Bug libgomp/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL

[ro at gcc dot gnu.org]

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

--- Comment #10 from Rainer Orth  ---
Created attachment 40141
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40141=edit
reduced testcase and assembler output

I've managed at least some reduction of the testcase: as you can see, one stack
allocation is reduced, the other has vanished completely.

  Rainer

[Bug libgomp/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #8 from Dominik Vogt  ---
> Some things to try with reduction-10.c:
>
> 1) Remove all OMP pragmas from the code.  If it still fails it's not a 
> limbgomp
> bug.

The failure goes away if I do this...

> 2) Replace "p7" in foo with just "7".  If it still fails we know the bug is 
> not
> triggered by the dynamic allocation of a or b.

... but stays this way.

Rainer

[Bug c/78408] C loop initial declarations generate wrong code

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #10)
> (In reply to Jakub Jelinek from comment #9)
> > Note in the testcase a = (struct buf) {}, b = (struct buf) {} generates
> > significantly more efficient code than a = b = (struct buf) {} - the former
> > is 2x memset, the latter 1x memset + 1x memcpy.
> > So, shall we for large aggregates gimplify those differently as an
> > optimization?
> 
> I believe the gimplifier is not a good place to do optimization.  You can
> pattern-match
> 
>   memset (, ..., N);
>   memcpy (, , N);
> 
> and transform it to two times memset.

Even the *.optimized dump contains:
  b = {};
  a = b;
  d = {};
  c = d;
Can match.pd handle these, or would it need to be special folding code (where? 
gimple-fold.c, tree dse, what other passes have good framework for that)?

[Bug c/78408] C loop initial declarations generate wrong code

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #9)
> Note in the testcase a = (struct buf) {}, b = (struct buf) {} generates
> significantly more efficient code than a = b = (struct buf) {} - the former
> is 2x memset, the latter 1x memset + 1x memcpy.
> So, shall we for large aggregates gimplify those differently as an
> optimization?

I believe the gimplifier is not a good place to do optimization.  You can
pattern-match

  memset (, ..., N);
  memcpy (, , N);

and transform it to two times memset.

[Bug target/70118] UBSan claims misaligned access in SSE instrinsics

[linux at carewolf dot com]

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

Allan Jensen  changed:

   What|Removed |Added

  Attachment #40130|0   |1
is obsolete||

--- Comment #5 from Allan Jensen  ---
Created attachment 40140
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40140=edit
Patch

Updated patch confirmed to work

[Bug pch/78508] valgrind error in gt_pch_note_object when compiling C++

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-24
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, I'll try to reduce that, but I guess it would take ages. Let's see.

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #57 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #56 from Jakub Jelinek  ---
> So, is this resolved now?

The bootstrap failures are AFAIK, but perhaps we should keep it open for
the fixinclude fix backports discovered?

Rainer

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[jakub at gcc dot gnu.org]

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

--- Comment #56 from Jakub Jelinek  ---
So, is this resolved now?

[Bug c++/78511] New: ICE on using concept name as a "requires" parameter

[gcc-bugzilla at minijackson dot 33mail.com]

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

Bug ID: 78511
   Summary: ICE on using concept name as a "requires" parameter
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at minijackson dot 33mail.com
  Target Milestone: ---

GCC version and system:

gcc (Gentoo 6.2.0-r1 p1.1) 6.2.0


Compilation options:

-altivec -awt -cilk cxx -debug -doc -fixed-point fortran gcj -go -graphite
-hardened -jit -libssp -mpx multilib nls nptl -objc -objc++ -objc-gc openmp pch
-pie -regression-test sanitize -ssp -vanilla vtv


Example program (test.cpp):

template 
concept bool A = true;

template 
concept bool B = requires(A a) {
a;
}


Command line:

g++ -fconcepts -std=c++1z test.cpp


Error:

test.cpp:5:27: internal compiler error: in synthesize_implicit_template_parm,
at cp/parser.c:37866
 concept bool B = requires(A a) {
   ^


test.ii generated file:

# 1 "test.cpp"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "test.cpp"
template 
concept bool A = true;

template 
concept bool B = requires(A a) {
 a;
}

[Bug c++/78282] [6/7 Regression] Overload resolution failure, in parameter pack expansion, inside a template class

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This is rejected since r229722.

[Bug target/62180] (RX600) - compiler doesn't honor -fstrict-volatile-bitfields and generates incorrect machine code for I/O register access

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #7 from Oleg Endo  ---
(In reply to Oleg Endo from comment #6)
> (In reply to DJ Delorie from comment #4)
> > Perhaps you need this patch:
> > 
> > https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00993.html
> 
> DJ, did you actually commit that patch?

Just checked the source.  That patch went in as r216844.  Closing the issue as
fixed.

[Bug target/78460] [7 Regression] [SH] OOM building glibc string tst-cmp.c

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #2 from Oleg Endo  ---
(In reply to Martin Liška from comment #1)
> 
> Apart from that, I wondering why there's no limit, as for instance:
> strncmp (left, right, 1000); emits battalion of instructions.

Oh yeah, that's PR 67712.

[Bug target/78012] -mfpxx produces assembly code using odd FP registers on MIPS

[ma...@linux-mips.org]

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

Maciej W. Rozycki  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-24
 Ever confirmed|0   |1

[Bug tree-optimization/71595] [7 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:704

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Thu Nov 24 12:25:22 2016
New Revision: 242835

URL: https://gcc.gnu.org/viewcvs?rev=242835=gcc=rev
Log:
2016-11-24  Richard Biener  

PR tree-optimization/71595
* cfgloopmanip.h (remove_path): Add irred_invalidated and
loop_closed_ssa_invalidated parameters, defaulted to NULL.
* cfgloopmanip.c (remove_path): Likewise, pass them along to
called functions.  Only fix irred flags if the caller didn't
request state.
* tree-ssa-loop-ivcanon.c (unloop_loops): Use add_bb_to_loop.
(unloop_loops): Pass irred_invalidated and loop_closed_ssa_invalidated
to remove_path.

* gcc.dg/torture/pr71595.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr71595.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgloopmanip.c
trunk/gcc/cfgloopmanip.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-ivcanon.c

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

[bernds at gcc dot gnu.org]

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

--- Comment #12 from Bernd Schmidt  ---
Author: bernds
Date: Thu Nov 24 12:22:16 2016
New Revision: 242834

URL: https://gcc.gnu.org/viewcvs?rev=242834=gcc=rev
Log:
PR rtl-optimization/78120
* ifcvt.c (noce_conversion_profitable_p): Check original cost in all
cases, and additionally test against max_seq_cost for speed
optimization.
(noce_process_if_block): Compute an estimate for the original cost when
optimizing for speed, using the minimum of then and else block costs.

testsuite/
PR rtl-optimization/78120
* gcc.target/i386/pr78120.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr78120.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ifcvt.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/71595] [7 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:704

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

[bernds at gcc dot gnu.org]

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

--- Comment #11 from Bernd Schmidt  ---
Author: bernds
Date: Thu Nov 24 12:17:52 2016
New Revision: 242833

URL: https://gcc.gnu.org/viewcvs?rev=242833=gcc=rev
Log:
PR rtl-optimization/78120
* rtlanal.c (insn_rtx_cost): Use set_rtx_cost.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/rtlanal.c

[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed

[bernds at gcc dot gnu.org]

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

--- Comment #10 from Bernd Schmidt  ---
Author: bernds
Date: Thu Nov 24 12:16:47 2016
New Revision: 242832

URL: https://gcc.gnu.org/viewcvs?rev=242832=gcc=rev
Log:
PR rtl-optimization/78120
* config/i386/i386.c (ix86_rtx_costs): Fully handle SETs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug target/78509] [7 regression] ICE in in excess_precision_type, at tree.c:8875

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to James Greenhalgh from comment #6)
> None of the logic was there in the original code, so there is not much to
> compare.

??  Since -fexcess-precision=standard has been introduced, gcc has the excess
precision notion.  So there is something to compare.
E.g. try
float foo (float x, float y, float z)
{
  return x + y + z;
}
before your changes with
-fdump-tree-gimple -m32 -msse2 -mno-80387 -fexcess-precision=standard
-fdump-tree-gimple -m32 -msse2 -mfpmath=387+sse -fexcess-precision=standard
-fdump-tree-gimple -m32 -msse2 -mfpmath=387 -fexcess-precision=standard
-fdump-tree-gimple -m32 -msse2 -mfpmath=sse -fexcess-precision=standard
-fdump-tree-gimple -m32 -msse -mno-sse2 -mfpmath=sse
-fexcess-precision=standard
to match the different cases in your hook, and compare that to what you get
with the current trunk.

[Bug middle-end/78429] [6/7 Regression] ICE in set_value_range, at tree-vrp.c on non-standard boolean

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #19 from Eric Botcazou  ---
Thanks for reporting the problem.

[Bug middle-end/78429] [6/7 Regression] ICE in set_value_range, at tree-vrp.c on non-standard boolean

[ebotcazou at gcc dot gnu.org]

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

--- Comment #18 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Nov 24 12:05:40 2016
New Revision: 242830

URL: https://gcc.gnu.org/viewcvs?rev=242830=gcc=rev
Log:
PR middle-end/78429
* tree.h (wi::fits_to_boolean_p): New predicate.
(wi::fits_to_tree_p): Use it for boolean types.
* tree.c (int_fits_type_p): Likewise.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.c-torture/compile/20161124-1.c
  - copied unchanged from r242829,
trunk/gcc/testsuite/gcc.c-torture/compile/20161124-1.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree.c
branches/gcc-6-branch/gcc/tree.h

[Bug middle-end/78429] [6/7 Regression] ICE in set_value_range, at tree-vrp.c on non-standard boolean

[ebotcazou at gcc dot gnu.org]

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

--- Comment #17 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Nov 24 12:02:53 2016
New Revision: 242829

URL: https://gcc.gnu.org/viewcvs?rev=242829=gcc=rev
Log:
PR middle-end/78429
* tree.h (wi::fits_to_boolean_p): New predicate.
(wi::fits_to_tree_p): Use it for boolean types.
* tree.c (int_fits_type_p): Likewise.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20161124-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug middle-end/78509] [7 regression] ICE in in excess_precision_type, at tree.c:8875

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #6 from James Greenhalgh  ---
None of the logic was there in the original code, so there is not much to
compare.

The question for the backend when TYPE is EXCESS_PRECISION_TYPE_FAST or
EXCESS_PRECISION_TYPE_STANDARD is, does it wants tree.c to insert operations to
guarantee explicit excess precision for the types, or does it wants tree.c to
keep them as their native types.

The assert exists because it makes no sense to ask the front-end to explicitly
make the operations unpredictable.

The fix which most closely maps to the semantics I think i386 wants is...

For EXCESS_PRECISION_TYPE_FAST:
  Always return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT

For EXCESS_PRECISION_TYPE_STANDARD:
  If we're in a mode which should never promote, or we're in a mode which will
be implicitly unpredictable, return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT
  If we're in the mode which should explicitly promote to LONG_DOUBLE, do that.

For EXCESS_PRECISION_TYPE_IMPLICIT:
  Keep the current logic.

I'll write a patch along those lines, and test it as well as I can, but I don't
really know how to get good -m32 testing out of my x86_64 box, which doesn't
have a good multilib environment set up. If you can point me at a machine in
the compile farm I can use I'd be happy to test more extensively.

[Bug c/78510] [7 Regression] ICE on invalid C code at -O2 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: verify_gimple failed)

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from amker at gcc dot gnu.org ---
Mine, I will investigate.
Thanks.

[Bug bootstrap/78493] profiledbootstrap failure: error: attempt to free a non-heap object 'names' in ../../gcc/cp/parser.c:11482:23

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Thu Nov 24 11:26:12 2016
New Revision: 242828

URL: https://gcc.gnu.org/viewcvs?rev=242828=gcc=rev
Log:
cp_parser_range_for: use safe_push instead of quick_push (PR

PR bootstrap/78493
* parser.c (cp_parser_range_for): Use safe_push instead of quick_push.
PR bootstrap/78493
* g++.dg/cpp1z/decomp18.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/decomp18.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/78509] [7 regression] ICE in in excess_precision_type, at tree.c:8875

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
I guess you should look at what the compiler did before your changes in these
cases (mixed sse and i387 e.g.) and match that in the new hook.

[Bug c/78510] [7 Regression] ICE on invalid C code at -O2 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: verify_gimple failed)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-24
 CC||amker.cheng at gmail dot com,
   ||marxin at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|ice on invalid C code at|[7 Regression] ICE on
   |-O2 and above in both   |invalid C code at -O2 and
   |32-bit and 64-bit modes on  |above in both 32-bit and
   |x86_64-linux-gnu (internal  |64-bit modes on
   |compiler error: |x86_64-linux-gnu (internal
   |verify_gimple failed)   |compiler error:
   ||verify_gimple failed)
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r242751.

[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #19 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #18)
> Comment on attachment 40139 [details]
> fix formatting of patch in comment 13
> 
> LGTM.

Thanks, I have started bootstrap on x86_64-unknown-linux-gnu
with --enable-languages=all,ada and will post it on patches list
after the build completes.

Thanks,
Prathamesh

[Bug target/65496] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2318 with -O3 -fsched2-use-superblocks -mavx512dq --param=max-pending-list-length=0

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

  Known to fail||7.0

--- Comment #4 from Zdenek Sojka  ---
Another testcase:
$ cat testcase.c
int c;
__int128 x;

void
foo ()
{
  if (c)
x /= 5;
}
$ powerpc64-unknown-linux-gnu-gcc -O2 -fsched2-use-superblocks -g
--param=max-pending-list-length=0 testcase.c  
testcase.c: In function 'foo':
testcase.c:9:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2328
 }
 ^
0x78d4b0 maybe_record_trace_start
/repo/gcc-trunk/gcc/dwarf2cfi.c:2328
0x78e360 scan_trace
/repo/gcc-trunk/gcc/dwarf2cfi.c:2510
0x78ebca create_cfi_notes
/repo/gcc-trunk/gcc/dwarf2cfi.c:2664
0x78ebca execute_dwarf2_frame
/repo/gcc-trunk/gcc/dwarf2cfi.c:3022
0x78ebca execute
/repo/gcc-trunk/gcc/dwarf2cfi.c:3502
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/78509] [7 regression] ICE in in excess_precision_type, at tree.c:8875

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-11-24
   Assignee|unassigned at gcc dot gnu.org  |jgreenhalgh at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #4 from James Greenhalgh  ---
Well, certainly this comment and assert in tree.c:

  /* The target should not ask for unpredictable float evaluation (though
 it might advertise that implicitly the evaluation is unpredictable,
 but we don't care about that here, it will have been reported
 elsewhere).  If it does ask for unpredictable evaluation, we have
 nothing to do here.  */
  gcc_assert (target_flt_eval_method != FLT_EVAL_METHOD_UNPREDICTABLE);

Suggest that the implementation I've put in for TARGET_C_EXCESS_PRECISION on
i386 is wrong (or the assert needs to be weakened).

  static enum flt_eval_method
  ix86_excess_precision (enum excess_precision_type type)
  {
switch (type)
  {
case EXCESS_PRECISION_TYPE_FAST:
  /* The fastest type to promote to will always be the native type,
 whether that occurs with implicit excess precision or
 otherwise.  */
  return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT;
case EXCESS_PRECISION_TYPE_STANDARD:
case EXCESS_PRECISION_TYPE_IMPLICIT:
  /* Otherwise, the excess precision we want when we are
 in a standards compliant mode, and the implicit precision we
 provide can be identical.  */
  if (!TARGET_80387)
return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT;
  else if (TARGET_MIX_SSE_I387)
return FLT_EVAL_METHOD_UNPREDICTABLE;
  else if (!TARGET_SSE_MATH)
return FLT_EVAL_METHOD_PROMOTE_TO_LONG_DOUBLE;
  else if (TARGET_SSE2)
return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT;
  else
return FLT_EVAL_METHOD_UNPREDICTABLE;
default:
  gcc_unreachable ();
  }

return FLT_EVAL_METHOD_UNPREDICTABLE;
  }

I think the right fix is probably to return FLT_METHOD_PROMOTE_TO_FLOAT for
EXCESS_PRECISION_TYPE_STANDARD, but I'll need to think about that.

Sorry again for the break, by inspection it is obvious how you hit that assert.

[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
Comment on attachment 40139
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40139
fix formatting of patch in comment 13

LGTM.

[Bug middle-end/78507] [7 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in int_fits_type_p, at tree.c:9153

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Types of @2/@3 are guarded by INTEGER_CST@2/INTEGER_CST@3, but type of @1 is
not checked.  Should check INTEGRAL_TYPE_P for it before calling
int_fits_type_p.

[Bug driver/77497] [5/6/7 Regression] Setting DWARF level and debug level together has flag-ordering-dependent results

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Still I'd classify the change as intentational, -gdwarf-N isn't unrelated
option to -gN, but implies -g2 unless the level is already -g3.

[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #17 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #15)
> For the tests, I think they would just pass on VMS.  In one case you are
> comparing if 0x7fffULL <= (unsigned int) something, that is for
> 32-bit int clearly never true and should be folded.  And in the other case,
> you are assigning 32-bit unsigned value into 64-bit signed var and then
> testing if it is negative, again, that is never true.
Ah right, thanks for pointing it out!

Regards,
Prathamesh

[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #16 from prathamesh3492 at gcc dot gnu.org ---
Created attachment 40139
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40139=edit
fix formatting of patch in comment 13

Done formatting changes in this version.
Does it look OK ?

Thanks,
Prathamesh

[Bug c++/77581] [5/6/7 Regression] ICE: instantiate_template_1, cp/pt.c:17391

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
  Known to work|5.4.0   |
Summary|[6/7 Regression] ICE:   |[5/6/7 Regression] ICE:
   |instantiate_template_1, |instantiate_template_1,
   |cp/pt.c:17391   |cp/pt.c:17391

--- Comment #2 from Jakub Jelinek  ---
Started to ICE with r192448 (before that it has been rejected, because C++11
inheriting ctors weren't supported.

[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
For the tests, I think they would just pass on VMS.  In one case you are
comparing if 0x7fffULL <= (unsigned int) something, that is for
32-bit int clearly never true and should be folded.  And in the other case, you
are assigning 32-bit unsigned value into 64-bit signed var and then testing if
it is negative, again, that is never true.

[Bug testsuite/77634] some vectorized testcases fail with -mcpu=thunderx

[hs.naveen2u at gmail dot com]

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

hs.naveen2u at gmail dot com changed:

   What|Removed |Added

 CC||hs.naveen2u at gmail dot com

--- Comment #1 from hs.naveen2u at gmail dot com ---
Fixed.
https://gcc.gnu.org/ml/gcc-cvs/2016-11/msg01096.html

[Bug c/78510] New: ice on invalid C code at -O2 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: verify_gimple failed)

[chengniansun at gmail dot com]

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

Bug ID: 78510
   Summary: ice on invalid C code at -O2 and above in both 32-bit
and 64-bit modes on x86_64-linux-gnu (internal
compiler error: verify_gimple failed)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161124 (experimental) [trunk revision 242818] (GCC)
$
$ gcc-trunk -O3 small.c
small.c: In function ‘main’:
small.c:17:5: error: type mismatch in conditional expression
 int main() { fn2(); return 0; }
 ^~~~
short int
int
short int
iftmp.1_11 = _6 == 4 ? 4 : 0;
small.c:17:5: internal compiler error: verify_gimple failed
0xc317f6 verify_gimple_in_cfg(function*, bool)
../../gcc-source-trunk/gcc/tree-cfg.c:5258
0xb0f84a execute_function_todo
../../gcc-source-trunk/gcc/passes.c:1965
0xb10285 execute_todo
../../gcc-source-trunk/gcc/passes.c:2015
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
$ cat small.c
int a, b, c, e, f;
char d;
short g, h;
char fn1(int p1) {
  for (;;) {
h = p1 << 2;
int i = h;
g = i > 32767 >> 13 ? i : i << 3;
f = a ?: c;
if (e)
  return d;
  }
}

static int fn2() { fn1(0 || b); }

int main() { fn2(); return 0; }