[Bug tree-optimization/77387] Value range not computed in some cases for ABS_EXPR

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #2 from Andrew Pinski  ---
TYPE_UNSIGNED here is most likely not the correct check.  TYPE_OVERFLOW_WRAPS
is the more correct one so for -fwrapv, you get the check still.

[Bug tree-optimization/77387] Value range not computed in some cases for ABS_EXPR

[kugan at gcc dot gnu.org]

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

--- Comment #1 from kugan at gcc dot gnu.org ---
With :

diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index e4d789b..2d1f4c8 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -3416,6 +3416,17 @@ extract_range_from_unary_expr_1 (value_range *vr,
  return;
}

+  /* If SIGNED and VARYING set [0, TYPE_MAX].  */
+  if (!TYPE_UNSIGNED (type)
+ && vr0.type == VR_VARYING)
+   {
+ set_value_range (vr, VR_RANGE,
+  build_int_cst (type, 0),
+  vrp_val_max (type),
+  NULL);
+ return;
+   }
+
   /* For the remaining varying or symbolic ranges we can't do anything
 useful.  */
   if (vr0.type == VR_VARYING


vrp1 dump becomes:
Value ranges after VRP:

_1: [0, 127]  EQUIVALENCES: { x_4 } (1 elements)
i_2(D): VARYING
x_3: [0, +INF]
x_4: [0, 127]
x_7: [0, 127]  EQUIVALENCES: { x_4 } (1 elements)


Folding predicate x_4 > 256 to 0
Removing basic block 5
Merging blocks 2 and 3
Merging blocks 2 and 4
foo (int i)
{
  int x;

  :
  x_3 = ABS_EXPR ;
  x_4 = x_3 >> 24;
  return x_4;

}

[Bug tree-optimization/77387] New: Value range not computed in some cases for ABS_EXPR

[kugan at gcc dot gnu.org]

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

Bug ID: 77387
   Summary: Value range not computed in some cases for ABS_EXPR
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kugan at gcc dot gnu.org
  Target Milestone: ---

For testcase:

int foo (int i)
{
  int x = i;
  x = __builtin_abs (i);
  x >>= 24;
  if (x > 256)
return 0;
  return x;
}

vrp1 dump is:
Value ranges after VRP:

_1: [-INF, 256]
i_2(D): VARYING
x_3: [0, +INF(OVF)]
x_4: VARYING
x_6: [257, +INF]  EQUIVALENCES: { x_4 } (1 elements)
x_7: [-INF, 256]  EQUIVALENCES: { x_4 } (1 elements)


Removing basic block 3
foo (int i)
{
  int x;
  int _1;

  :
  x_3 = ABS_EXPR ;
  x_4 = x_3 >> 24;
  if (x_4 > 256)
goto ;
  else
goto ;

  :

  :
  # _1 = PHI <0(3), x_4(2)>
  return _1;

}


Note:
x_3: [0, +INF(OVF)]
x_4: VARYING

[Bug c++/77386] New: Explicit constructor is allowed causing ambiguous initialization call when it shouldn't be allowed

[hpmv at google dot com]

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

Bug ID: 77386
   Summary: Explicit constructor is allowed causing ambiguous
initialization call when it shouldn't be allowed
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hpmv at google dot com
  Target Milestone: ---

Using g++ 4.8.4, compiling the following code

struct X{
  X(int, int) {}
};

struct Y {
 explicit Y(X) {}
 explicit Y(int, int) {}
};

int main() {
  Y({1, 2});
}


with the command line

  g++ -Wall -Wextra --std=c++11 main.cpp

fails with the errors

main.cpp: In function ‘int main()’:
main.cpp:11:11: error: call of overloaded ‘Y()’ is ambiguous
   Y({1, 2});
   ^
main.cpp:11:11: note: candidates are:
main.cpp:6:11: note: Y::Y(X)
  explicit Y(X) {}
   ^
main.cpp:5:8: note: constexpr Y::Y(const Y&)
 struct Y {
^
main.cpp:5:8: note: constexpr Y::Y(Y&&)



This doesn't make sense because the overload Y::Y(const Y&) and Y::Y(Y&&)
should not be considered since it's not possible to interpret {1, 2} as Y(1, 2)
due to that constructor being marked explicit.

The code compiles in clang 3.4.

[Bug fortran/77382] ICE: verify_gimple failed -- expand_expr_real_1, at expr.c:9651

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-25
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/77381] ICE in resolve_equivalence, at fortran/resolve.c:15149

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-25
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/77385] New: "Unclassifiable statement" from gfortran

[andrew at fluidgravity dot co.uk]

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

Bug ID: 77385
   Summary: "Unclassifiable statement" from gfortran
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew at fluidgravity dot co.uk
  Target Milestone: ---

Created attachment 39500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39500=edit
Fortran code that won't compile with gfortran

I get the above error when I attempt to compile the attached code. The Intel
and PGI Fortran compilers both compile the code without error.

> gfortran -c code.f90
code.f90:31:15:

l(1) = k(1)%e()
   1
Error: Unclassifiable statement at (1)

[Bug fortran/77380] ICE in gfc_check_dependency, at fortran/dependency.c:1255

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-25
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #2 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/dependency.c
===
--- gcc/fortran/dependency.c(revision 239762)
+++ gcc/fortran/dependency.c(working copy)
@@ -1252,6 +1252,12 @@ gfc_check_dependency (gfc_expr *expr1, g
   gfc_constructor *c;
   int n;

+  /* -fcoarray=lib can end up here with expr1->expr_type set to EXPR_FUNCTION
+ and a reference to _F.caf_get, so skip the assert.  */
+  if (expr1->expr_type == EXPR_FUNCTION
+  && strcmp (expr1->value.function.name, "_F.caf_get") == 0)
+return 0;
+
   gcc_assert (expr1->expr_type == EXPR_VARIABLE);

   switch (expr2->expr_type)

[Bug fortran/77327] AddressSanitizer: heap-use-after-free gcc-trunk-239276/gcc/fortran/interface.c:403 in compare_components

[zeccav at gmail dot com]

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

--- Comment #8 from Vittorio Zecca  ---
Yes, it seems to me that import4.f90 is sufficient to trigger the asan
memory checker.

How strange, even without "implicit none" the loader should have complained
that "sub2" was referenced but undefined. This is how I find the bug.

It is not that trivial to build a sanitized version of
gcc/g++/gfortran but nonetheless
it is possible.

Once you have a sanitized gfortran and f951 then you can check it
against the gcc testsuite
Fortran files, as I did.

[Bug c++/77379] New: incorrect mangling for non-virtual adjustor thunk (missing abi tag)

[richard-gccbugzilla at metafoo dot co.uk]

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

Bug ID: 77379
   Summary: incorrect mangling for non-virtual adjustor thunk
(missing abi tag)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

GCC does not emit ABI tags from a function return type when mangling an
adjustor thunk (see example in https://llvm.org/bugs/show_bug.cgi?id=28997).

If this is intentional, and there's some good reason to omit the abi_tag
mangling here, let us know and we'll suppress them from Clang too.

[Bug gcov-profile/77378] [7 Regression] tree-profile and libgcov assume long long atomic operations are supported

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
-ftree-profile and gcov don't link against libatomic.

[Bug fortran/77382] New: ICE: verify_gimple failed -- expand_expr_real_1, at expr.c:9651

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

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

Bug ID: 77382
   Summary: ICE: verify_gimple failed -- expand_expr_real_1, at
expr.c:9651
   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: ---

With invalid code, and configured with --enable-checking=yes :


$ cat z1.f90
subroutine s
entry f(s)
end
call s
end


$ cat z2.f90
program p
call s
end
subroutine s
entry f(s)
end


$ gfortran-7-20160821 z1.f90
z1.f90:4:0:

 call s

Error: Local declaration from a different function
s
z1.f90:4:0:

 call s

note: in statement
s ();
z1.f90:4:0:

 call s

internal compiler error: verify_gimple failed
0xc5ed96 verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5212
0xb4a363 execute_function_todo
../../gcc/passes.c:1964
0xb4ac95 execute_todo
../../gcc/passes.c:2014

[Bug fortran/77382] ICE: verify_gimple failed -- expand_expr_real_1, at expr.c:9651

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

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

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

With official releases (configured with --enable-checking=release),
down to at least 4.8 :


$ gfortran-6 z1.f90
z1.f90:4:0:

 call s

internal compiler error: in expand_expr_real_1, at expr.c:9651

[Bug fortran/77351] ICE in remove_trim, at frontend-passes.c:1145

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #5 from kargl at gcc dot gnu.org ---
Fixed on trunk.

[Bug fortran/77381] New: ICE in resolve_equivalence, at fortran/resolve.c:15149

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

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

Bug ID: 77381
   Summary: ICE in resolve_equivalence, at fortran/resolve.c:15149
   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: ---

For versions down to at least 4.8 :


$ cat z1.f90
module m
   character(3) :: a(2), b(2)
   equivalence (a(2)(1:2), b(1)(2:3))
end
program p
   use m
end


$ cat z2.f90
module m
   character(3) :: a(2), b(2)
   equivalence (a(2)(1:3), b(1)(1:3))
end
program p
   use m
end


$ cat z3.f90## similar to z2.f90, no ICE
module m
   character(3) :: a(2), b(2)
   equivalence (a(2)(:), b(1)(:))
end
program p
   use m
end


$ gfortran-7-20160821 z1.f90
f951: internal compiler error: in resolve_equivalence, at
fortran/resolve.c:15149
0x6f3717 resolve_equivalence
../../gcc/fortran/resolve.c:15149
0x6f3717 resolve_types
../../gcc/fortran/resolve.c:15515
0x6eee7c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15593
0x6da1aa resolve_all_program_units
../../gcc/fortran/parse.c:5855
0x6da1aa gfc_parse_file()
../../gcc/fortran/parse.c:6107
0x71c622 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/77351] ICE in remove_trim, at frontend-passes.c:1145

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Aug 25 19:35:46 2016
New Revision: 239763

URL: https://gcc.gnu.org/viewcvs?rev=239763=gcc=rev
Log:
2016-08-25  Steven g. Kargl  

PR fortran/77351
* frontend-passes.c (remove_trim,combine_array_constructor): Check for
NULL pointer.

2016-08-25  Steven g. Kargl  

PR fortran/77351
* gfortran.dg/pr77351.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr77351.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/77380] ICE in gfc_check_dependency, at fortran/dependency.c:1255

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

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

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

No ICE with -fcoarray=single :

$ gfortran-7-20160821 -O2 -fcoarray=single z1.f90
z1.f90:3:14:

z(:)[1] = z(:)[*]
  1
Error: Coindex of codimension 1 must be a scalar at (1)



Bailed out with 5, 6 (official, --enable-checking=release) :

$ gfortran-6 -O2 -fcoarray=lib z1.f90
z1.f90:3:14:

z(:)[1] = z(:)[*]
  1
Error: Coindex of codimension 1 must be a scalar at (1)
(null):0: confused by earlier errors, bailing out

[Bug fortran/77380] New: ICE in gfc_check_dependency, at fortran/dependency.c:1255

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

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

Bug ID: 77380
   Summary: ICE in gfc_check_dependency, at
fortran/dependency.c:1255
   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: ---

Invalid code, compiled at level -Og, -Os, -O1 or higher,
with debugging compiler (--enable-checking=yes) :


$ cat  z1.f90
program p
   integer :: z(2)[*] = 1
   z(:)[1] = z(:)[*]
end


$ gfortran-7-20160821 -O2 -fcoarray=lib z1.f90
z1.f90:3:14:

z(:)[1] = z(:)[*]
  1
Error: Coindex of codimension 1 must be a scalar at (1)
f951: internal compiler error: in gfc_check_dependency, at
fortran/dependency.c:1255
0x714b59 gfc_check_dependency(gfc_expr*, gfc_expr*, bool)
../../gcc/fortran/dependency.c:1255
0x7b0a2b optimize_assignment
../../gcc/fortran/frontend-passes.c:1181
0x7b0a2b optimize_code
../../gcc/fortran/frontend-passes.c:221
0x7b3459 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:3392
0x7b44b4 optimize_namespace
../../gcc/fortran/frontend-passes.c:1005
0x7b4670 gfc_run_passes(gfc_namespace*)
../../gcc/fortran/frontend-passes.c:132
0x6eeeb7 gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15601
0x6da1aa resolve_all_program_units
../../gcc/fortran/parse.c:5855
0x6da1aa gfc_parse_file()
../../gcc/fortran/parse.c:6107
0x71c622 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug c++/67737] [C++1z] ICE in make_decl_rtl, at varasm.c:1299

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Vittorio Zecca from comment #7)
> With gcc 6.1.0, maybe a shorter reproducer
> /* gcc -fcheck-pointer-bounds -mmpx p.c */

That is a different issue and should be filed separately if not already.

[Bug target/67733] illumos needs a new target triple

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|*-*-solaris*|
Summary|elfdump and readelf in perl |illumos needs a new target
   |scripts should to use env   |triple
   |vars ELFDUMP and READELF|
   Severity|normal  |enhancement

--- Comment #5 from Andrew Pinski  ---
Confirmed though as I mentioned illumos needs a fully new target triplet as it
is incompatible with Solaris now.

[Bug c++/77384] New: Assembler error - std::forward(decimal64) already declared

[danielberger at gmail dot com]

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

Bug ID: 77384
   Summary: Assembler error - std::forward(decimal64) already
declared
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danielberger at gmail dot com
  Target Milestone: ---

while compiling with no extra flags i get:
/tmp/cceuJGN0.s: Assembler messages:
1543 : Error: symbol `_ZSt7forwardIDdEOT_RNSt16remove_referenceIS0_E4typeE' is
already defined
1565 : Error: symbol `_ZNSt4pairIiDdEC1IiDdLb1EEEOT_OT0_' is already defined
Compilation failed


after some investigation it looks like the codegen is emitting this function
twice:
decimal64&& std::forward(std::remove_reference::type&)

perhaps it's the mix of explicit and implicit constructor or something.

minimal code - problem.cpp:
--
#include 
#include 
using std::decimal::decimal64;
std::pair x = { 1, 1.5dd };
std::pair u = { 1, decimal64(1.5dd) };
--


live demonstration: https://godbolt.org/g/xgCliN


if needed i'm happy to upload more intermediate files

[Bug middle-end/61409] [5/6/7 regression] -Wmaybe-uninitialized false-positive with -O2

[aldyh at gcc dot gnu.org]

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

--- Comment #22 from Aldy Hernandez  ---
Created attachment 39499
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39499=edit
untested patch v1

I think I see what Jeff is getting at.

Here is an untested patch exploring the idea of ignoring unguarded uses if we
can prove that the guards for such uses are invalidated by the uninitialized
operand paths being executed.

Preliminary tests show that it fixes the testcase in the PR without introducing
any regressions in the rest of the uninit tests:

 make check-gcc RUNTESTFLAGS=dg.exp=uninit*

As the "NOTE:" in the code states, we could be much smarter when invalidating
predicates, but for now let's do straight negation which works for the simple
case.

Does this seem like a reasonable approach?

[Bug c++/67776] No warning when using asm with non-static variable

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
(In reply to David from comment #0)
> While not particularly interesting of itself, this makes me wonder what
> other c error checking might be getting skipped in c++.

Or rather the code is in the C front-end but not in the C++ front-end.  The C
and C++ front-ends don't share all code; just some of it.

[Bug c/77383] New: -fcheck-pointer-bounds -mmpx ICE in make_decl_rtl at varasm.c

[zeccav at gmail dot com]

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

Bug ID: 77383
   Summary: -fcheck-pointer-bounds -mmpx ICE in make_decl_rtl at
varasm.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

/* gcc -fcheck-pointer-bounds -mmpx */
int main ()
{
  int size = 10;
  typedef struct
{
  char val[size];
} block;
  block b;
  block retframe_block () {}
  retframe_block ();
}
/* gccerr37.c: In function ‘main.chkp’:
 * gccerr37.c:12:3: internal compiler error: in make_decl_rtl, at varasm.c:1310
 *retframe_block ();
 *   ^~
 * 0xe3219d make_decl_rtl(tree_node*)
 *  /home/vitti/1tb/vitti/gcc-7/gcc/varasm.c:1306
 * 0x82cf32 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
 *  /home/vitti/1tb/vitti/gcc-7/gcc/expr.c:9755
 *0xe9d807 expand_normal
 *  /home/vitti/1tb/vitti/gcc-7/gcc/expr.h:285
 * 0xe9d807 ix86_expand_builtin
 *  /home/vitti/1tb/vitti/gcc-7/gcc/config/i386/i386.c:41212
 * 0x707354 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
 *  /home/vitti/1tb/vitti/gcc-7/gcc/builtins.c:5801
 * 0x82cf69 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
 *  /home/vitti/1tb/vitti/gcc-7/gcc/expr.c:10733
 * 0x71272c initialize_argument_information
 *  /home/vitti/1tb/vitti/gcc-7/gcc/calls.c:1204
 * 0x714f01 expand_call(tree_node*, rtx_def*, int)
 *  /home/vitti/1tb/vitti/gcc-7/gcc/calls.c:2857
 * 0x82cb4d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
 *  /home/vitti/1tb/vitti/gcc-7/gcc/expr.c:10736
 * 0x83838b store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
 *  /home/vitti/1tb/vitti/gcc-7/gcc/expr.c:5547
 * 0x839e13 expand_assignment(tree_node*, tree_node*, bool)
 *  /home/vitti/1tb/vitti/gcc-7/gcc/expr.c:5316
 * 0x729b45 expand_call_stmt
 *  /home/vitti/1tb/vitti/gcc-7/gcc/cfgexpand.c:2665
 * 0x729b45 expand_gimple_stmt_1
 *  /home/vitti/1tb/vitti/gcc-7/gcc/cfgexpand.c:3580
 * 0x729b45 expand_gimple_stmt
 *  /home/vitti/1tb/vitti/gcc-7/gcc/cfgexpand.c:3746
 * 0x72c740 expand_gimple_basic_block
 *  /home/vitti/1tb/vitti/gcc-7/gcc/cfgexpand.c:5753
 * 0x7314ee execute
 *  /home/vitti/1tb/vitti/gcc-7/gcc/cfgexpand.c:6367
 * 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++/67737] [C++1z] ICE in make_decl_rtl, at varasm.c:1299

[zeccav at gmail dot com]

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

--- Comment #9 from Vittorio Zecca  ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Vittorio Zecca from comment #7)
> > With gcc 6.1.0, maybe a shorter reproducer
> > /* gcc -fcheck-pointer-bounds -mmpx p.c */
> 
> That is a different issue and should be filed separately if not already.

Bug 77383 submitted.
Thank you for the suggestion.

[Bug fortran/77327] AddressSanitizer: heap-use-after-free gcc-trunk-239276/gcc/fortran/interface.c:403 in compare_components

[fritzoreese at gmail dot com]

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

--- Comment #7 from Fritz Reese  ---
(In reply to Vittorio Zecca from comment #5)
> The test case you propose, dec_structure_13.f90, does not trigger the asan
> memory checker.
Sorry if it was unclear, the new testcase dec_structure_13.f90 tests a separate
regression that is also fixed by the patch (see the comments in my post on the
mailing list).

(In reply to Vittorio Zecca from comment #5)
> (In reply to Fritz Reese from comment #3)
> > I would appreciate
> > ideas for a testcase I can commit with the aforementioned patch to
> > ensure this PR isn't regressed.
> As I wrote before, the test case gfortran.dg/import4.f90 does trigger
> the asan memory checker.
Is that sufficient then to test the regression, or need I add another testcase
to my patch?

(In reply to Vittorio Zecca from comment #5)
> In your test case I do not understand the final statement "call
> sub2(u2)" because
> sub2 is not defined.
That is a typo - "sub3" from dec_structure_13.f90 line 40 should be named
"sub2". That's what I get for forgetting "implicit none"...

(In reply to Vittorio Zecca from comment #6)
> Fritz, do you have a -fsanitize=address version of gfortran, in
> particular of f951?
I was not aware of the capability. I will build one.

[Bug gcov-profile/77378] [7 Regression] tree-profile and libgcov assume long long atomic operations are supported

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
libatomic should provide the functions.

[Bug gcov-profile/77378] [7 Regression] tree-profile and libgcov assume long long atomic operations are supported

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-25
 CC||hubicka at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||seurer at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug gcov-profile/77378] New: [7 Regression] tree-profile and libgcov assume long long atomic operations are supported

[dje at gcc dot gnu.org]

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

Bug ID: 77378
   Summary: [7 Regression] tree-profile and libgcov assume long
long atomic operations are supported
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: link-failure
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc*-*-*

The "Various GCOV/PGO improvements" in August 2016 implicitly assume that 64
bit atomic operations are supported in 32 bit mode.

tree-profile.c:
  /* __atomic_fetch_add (, 1, MEMMODEL_RELAXED); */
  tree addr = tree_coverage_counter_addr (GCOV_COUNTER_ARCS, edgeno);
  tree f = builtin_decl_explicit (LONG_LONG_TYPE_SIZE > 32
  ? BUILT_IN_ATOMIC_FETCH_ADD_8:
  BUILT_IN_ATOMIC_FETCH_ADD_4);

libgcov.h:
#if LONG_LONG_TYPE_SIZE > 32
typedef signed gcov_type __attribute__ ((mode (DI)));
typedef unsigned gcov_type_unsigned __attribute__ ((mode (DI)));
#else
typedef signed gcov_type __attribute__ ((mode (SI)));
typedef unsigned gcov_type_unsigned __attribute__ ((mode (SI)));
#endif

libgcov-profiler.c:
__atomic_fetch_add (...)


LONG_LONG_TYPE_SIZE is defined as 64 on PPC32 (both PPC32 Linux and AIX), but
64 bit atomic operations are not supported. GCC emits libcalls, but no library
provides the definition, so profiled programs fail to link.

[Bug target/69427] gcc-4.9.3 compilation for the cross target m68k-rtems4.11 in i686-Cygwin

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-08-25
 Ever confirmed|0   |1

--- Comment #5 from Andrew Pinski  ---
Does this still happen with newer versions of GCC?

[Bug target/72863] Powerpc64le: redundant swaps when using vec_vsx_ld/st

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #9 from Bill Schmidt  ---
Work is complete.

[Bug target/72863] Powerpc64le: redundant swaps when using vec_vsx_ld/st

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Aug 25 16:12:23 2016
New Revision: 239762

URL: https://gcc.gnu.org/viewcvs?rev=239762=gcc=rev
Log:
[gcc]

2016-08-25  Bill Schmidt  

Backport from mainline (minus test for POWER9 support)
2016-08-11  Bill Schmidt  

PR target/72863
* vsx.md (vsx_load_): For P8LE, emit swaps at expand time.
(vsx_store_): Likewise.

[gcc/testsuite]

2016-08-25  Bill Schmidt  

Backport from mainline
2016-08-11  Bill Schmidt  

PR target/72863
* gcc.target/powerpc/pr72863.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/pr72863.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/vsx.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/77377] [7 Regression] c-c++-common/pr59037.c ICEs with -fpic -msse on i686

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #2 from H.J. Lu  ---
It may be caused by r236630.

Re: ia64-elf and i386-elf fail to build

[Nick Clifton]

Hi Joseph,

>>  * config/ia64/ia64.c (ia64_init_builtins): Initialise the
>>  float128_type_node if that has not been done already.
>>  * config/i386/i386.c (ix86_init_builtin_types): Likewise.
> 
> No, this is wrong.  The global node must remain as NULL when the type is 
> not fully supported.  You need a different name for the local node, e.g. 
> i386_float128_type_node (and then update all back-end uses to use the 
> local node).

Oh, OK - new patch in the works.

Cheers
  Nick

Re: ia64-elf and i386-elf fail to build

[Joseph Myers]

On Thu, 25 Aug 2016, Nick Clifton wrote:

> gcc/ChangeLog
> 2016-08-25  Nick Clifton  
> 
>   * config/ia64/ia64.c (ia64_init_builtins): Initialise the
>   float128_type_node if that has not been done already.
>   * config/i386/i386.c (ix86_init_builtin_types): Likewise.

No, this is wrong.  The global node must remain as NULL when the type is 
not fully supported.  You need a different name for the local node, e.g. 
i386_float128_type_node (and then update all back-end uses to use the 
local node).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: ia64-elf and i386-elf fail to build

[Nick Clifton]

Hi Guys,

> I think this indicates that i386 and ia64 need their own local version of 
> float128_type_node, set up like float80_type_node (i.e. copied from the 
> global one if that isn't NULL, otherwise set up locally) instead of using 
> the global one unconditionally, because of the existence of i386 and ia64 
> targets where the TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P hook can return 
> false for TFmode (in which case __float128 still exists, but not 
> _Float128).

OK - that I can do.

> Though preferable would be to fix all the targets with 
> IX86_NO_LIBGCC_TFMODE / IX86_MAYBE_NO_LIBGCC_TFMODE / 
> IA64_NO_LIBGCC_TFMODE so that they include the relevant support code in 
> libgcc and so no longer need the TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P 
> hook overridden at all.

I would prefer to leave this to the maintainers as I do not want to get target
greping wrong.

So - Jan, Uros, Jim, Steve - are these ia64 and i386 backend patches OK ?
 
Cheers
  Nick

gcc/ChangeLog
2016-08-25  Nick Clifton  

* config/ia64/ia64.c (ia64_init_builtins): Initialise the
float128_type_node if that has not been done already.
* config/i386/i386.c (ix86_init_builtin_types): Likewise.

Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c	(revision 239761)
+++ gcc/config/i386/i386.c	(working copy)
@@ -33341,9 +33341,19 @@
 }
   lang_hooks.types.register_builtin_type (float80_type_node, "__float80");
 
-  /* The __float128 type.  The node has already been created as
- _Float128, so we only need to register the __float128 name for
- it.  */
+  /* The __float128 type.  If TFmode is supported by libgcc then the node
+ has already been created as _Float128, so we only need to register the
+ __float128 name for  it.  Otherwise we have to create the float128
+ type first.  */
+#if defined IX86_NO_LIBGCC_TFMODE || defined IX86_MAYBE_NO_LIBGCC_TFMODE
+  if (float128_type_node == NULL)
+{
+  float128_type_node = make_node (REAL_TYPE);
+  TYPE_PRECISION (float128_type_node) = 128;
+  layout_type (float128_type_node);
+  SET_TYPE_MODE (float128_type_node, TFmode);
+}
+#endif
   lang_hooks.types.register_builtin_type (float128_type_node, "__float128");
 
   const_string_type_node
Index: gcc/config/ia64/ia64.c
===
--- gcc/config/ia64/ia64.c	(revision 239761)
+++ gcc/config/ia64/ia64.c	(working copy)
@@ -10368,6 +10368,13 @@
   tree const_string_type
 	= build_pointer_type (build_qualified_type
 			  (char_type_node, TYPE_QUAL_CONST));
+#ifdef IA64_NO_LIBGCC_TFMODE
+  gcc_assert (float128_type_node == NULL);
+  float128_type_node = make_node (REAL_TYPE);
+  TYPE_PRECISION (float128_type_node) = 128;
+  layout_type (float128_type_node);
+  SET_TYPE_MODE (float128_type_node, TFmode);
+#endif
 
   (*lang_hooks.types.register_builtin_type) (float128_type_node,
 		 "__float128");

[Bug target/72863] Powerpc64le: redundant swaps when using vec_vsx_ld/st

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Aug 25 14:24:17 2016
New Revision: 239761

URL: https://gcc.gnu.org/viewcvs?rev=239761=gcc=rev
Log:
[gcc]

2016-08-25  Bill Schmidt  

Backport from mainline
2016-08-11  Bill Schmidt  

PR target/72863
* vsx.md (vsx_load_): For P8LE, emit swaps at expand time.
(vsx_store_): Likewise.

[gcc/testsuite]

2016-08-25  Bill Schmidt  

Backport from mainline
2016-08-11  Bill Schmidt  

PR target/72863
* gcc.target/powerpc/pr72863.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr72863.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/vsx.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug libgomp/71959] [OpenACC] #pragma acc parallel leads to segfault in x86_64-pc-linux-gnu-accel-nvptx-none-gcc

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #6 from Nathan Sidwell  ---
The code is ill-formed, for (at least) 3 reasons:

1) only one of the member functions is marked as 'acc routine', before being
called in an offloaded region. the 'pi' function is marked, but the iterator
members, _DummyRed member and the function invoker are not.

2) the loop itself does not contain independent iterations

3) the 'copy(__thread_results[1]...) is copying a single element array, but
then indexing it incorrectly.

Now, openacc doesn't appear to provide any mechanism for marking (say) all the
member fns of a class as routines, and apparently in-class use of 'pragma acc
routine' is not permitted.

Openacc  doesn't appear to address non-pod data objects or member functions.
Let alone the complexities of using the STL.

The compiler shouldn't blow up of course ...

Re: ia64-elf and i386-elf fail to build

[Joseph Myers]

On Thu, 25 Aug 2016, Joseph Myers wrote:

> _Float128).  Though preferable would be to fix all the targets with 
> IX86_NO_LIBGCC_TFMODE / IX86_MAYBE_NO_LIBGCC_TFMODE / 
> IA64_NO_LIBGCC_TFMODE so that they include the relevant support code in 
> libgcc and so no longer need the TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P 
> hook overridden at all.

Which, I should say, should actually be very simple to do in a mechanical 
way (changing the long list of targets near the bottom of 
libgcc/config.host that use soft-fp for i386/x86_64 to i[34567]86-*-* 
x86_64-*-* would almost do the right thing for x86, except you'd need to 
exclude i[34567]86-*-elfiamcu and update the code for i[34567]86-*-rtems* 
because they also use soft-fp for SFmode and DFmode).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: ia64-elf and i386-elf fail to build

[Joseph Myers]

On Thu, 25 Aug 2016, Nick Clifton wrote:

>   The cause appears to be an attempt to register a builtin type using
>   the float128_type_node, which is NULL for these particular targets:
> 
> gcc/config/ia64/ia64.c:10373
> gcc/config/i386/i386.c:33347
> 
>   Presumably float128_type_node should not be NULL, but I am not sure
>   how to fix this.  Any suggestions ?

I think this indicates that i386 and ia64 need their own local version of 
float128_type_node, set up like float80_type_node (i.e. copied from the 
global one if that isn't NULL, otherwise set up locally) instead of using 
the global one unconditionally, because of the existence of i386 and ia64 
targets where the TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P hook can return 
false for TFmode (in which case __float128 still exists, but not 
_Float128).  Though preferable would be to fix all the targets with 
IX86_NO_LIBGCC_TFMODE / IX86_MAYBE_NO_LIBGCC_TFMODE / 
IA64_NO_LIBGCC_TFMODE so that they include the relevant support code in 
libgcc and so no longer need the TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P 
hook overridden at all.

-- 
Joseph S. Myers
jos...@codesourcery.com

ia64-elf and i386-elf fail to build

[Nick Clifton]

Hi Guys,

  The ia64-elf and i386-elf targets currently fail to build for me using
  the mainline sources.  The symptom is a seg-fault when running the
  self tests:

./xgcc <...> -xc -S -c /dev/null -fself-test
: internal compiler error: Segmentation fault

  The cause appears to be an attempt to register a builtin type using
  the float128_type_node, which is NULL for these particular targets:

gcc/config/ia64/ia64.c:10373
gcc/config/i386/i386.c:33347

  Presumably float128_type_node should not be NULL, but I am not sure
  how to fix this.  Any suggestions ?

Cheers
  Nick

[Bug middle-end/77377] [7 Regression] c-c++-common/pr59037.c ICEs with -fpic -msse on i686

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
It looks that cse2 pass attaches wrong REG_EQUAL note:

(insn 8 4 13 2 (set (reg:SI 93)
(mem/u/j:SI (plus:SI (reg:SI 87)
(const:SI (plus:SI (unspec:SI [
(symbol_ref/u:SI ("*.LC0") [flags 0x2])
] UNSPEC_GOTOFF)
(const_int 16 [0x10] [1  S4 A128])) 82
{*movsi_internal}
 (expr_list:REG_EQUAL (const_vector:V4SI [
(const_int 3 [0x3])
(const_int 2 [0x2])
(const_int 1 [0x1])
(const_int 0 [0])
])
(expr_list:REG_DEAD (reg:SI 87)
(nil
(insn 13 8 14 2 (set (reg/i:SI 0 ax)
(reg:SI 93)) pr59037.c:12 82 {*movsi_internal}
 (expr_list:REG_EQUAL (const_vector:V4SI [
(const_int 3 [0x3])
(const_int 2 [0x2])
(const_int 1 [0x1])
(const_int 0 [0])
])
(expr_list:REG_DEAD (reg:SI 93)
(nil

[Bug middle-end/77377] [7 Regression] c-c++-common/pr59037.c ICEs with -fpic -msse on i686

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-25
  Component|rtl-optimization|middle-end
 Ever confirmed|0   |1

[Bug tree-optimization/69047] memcpy is not as optimized as union is

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Created attachment 39498
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39498=edit
patch

Patch queued for testing

[Bug tree-optimization/71506] [5 Regression] ICE with libvpx with -floop-interchange: isl_constraint.c:627: expecting integer value

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
(In reply to Tom de Vries from comment #6)
> Hmm, at r225942 I read:

Patch applies cleanly to 5 branch and fixes ICEs for original and minimal
test-cases.

[Bug tree-optimization/69047] memcpy is not as optimized as union is

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Let's see what is missing here.

[Bug c++/77375] [5/6/7 Regression] constant object with mutable subobject allocated in read-only memory

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||4.6.4
Summary|constant object with|[5/6/7 Regression] constant
   |mutable subobject allocated |object with mutable
   |in read-only memory |subobject allocated in
   ||read-only memory

--- Comment #1 from Jonathan Wakely  ---
This started with 4.7.0

[Bug c++/77375] constant object with mutable subobject allocated in read-only memory

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-25
 Ever confirmed|0   |1

[Bug c++/77373] __attribute__((vector_size(N))) fails on AIX

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #2 from Richard Biener  ---
g++.dg/ext/vector32.C for anyone searching, not sure what it has to do with the
cgraph though.  A backtrace would have been nice to be able to classify this
... ;)

[Bug fortran/77374] [6/7 Regression] ICE in resolve_omp_atomic, at fortran/openmp.c:3949

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.3

[Bug rtl-optimization/77377] [7 Regression] c-c++-common/pr59037.c ICEs with -fpic -msse on i686

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug c++/77369] incorrect noexcept specification deduction

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Richard Smith realized that it uses the noexceptness of the first type it's
instantiated with, because if you reverse the order of the calls, it produces
false, false

[Bug tree-optimization/71506] [5 Regression] ICE with libvpx with -floop-interchange: isl_constraint.c:627: expecting integer value

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries  ---
Hmm, at r225942 I read:
...
[graphite] fix pr61929

This fixes bootstrap of GCC with BOOT_CFLAGS="-g -O2 -fgraphite-identity
-floop-nest-optimize -floop-block -floop-interchange -floop-strip-mine".  It
passes regstrap on amd64-linux.  A previous change
(https://gcc.gnu.org/viewcvs/gcc?view=revision=213816), replaced
isl_int with isl_val because isl_int would be deprecated. Since isl_val has
stricter checks, it exposed the bug.  In the test case (isl_set_max_val) would
return infinity which would remain unchecked.  We now check if the value
returned is an integer or not, and bail out if it isn't.
...

This seems to be a duplicate of PR61929.[ If we mark this as a duplicate, we
should re-open PR61929 and mark it as 5 regression. ]

[Bug rtl-optimization/77377] New: [7 Regression] c-c++-common/pr59037.c ICEs with -fpic -msse on i686

[ubizjak at gmail dot com]

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

Bug ID: 77377
   Summary: [7 Regression] c-c++-common/pr59037.c ICEs with -fpic
-msse on i686
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Recent 7.0 regression:

~/gcc-build/gcc/cc1 -O3 -fpic -m32 -msse -quiet pr59037.c 

pr59037.c: In function ‘main’:
pr59037.c:12:1: internal compiler error: Segmentation fault
 }
 ^
0xb1f25f crash_signal
../../git/gcc/gcc/toplev.c:335
0x7f2c38 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../git/gcc/gcc/tree.h:3148
0x7f2c38 make_tree(tree_node*, rtx_def*)
../../git/gcc/gcc/expmed.c:5085
0x7f2d26 make_tree(tree_node*, rtx_def*)
../../git/gcc/gcc/expmed.c:5111
0xe1ef70 force_const_mem(machine_mode, rtx_def*)
../../git/gcc/gcc/varasm.c:3722
0x96cb86 setup_reg_equiv
../../git/gcc/gcc/ira.c:3933
0x96cb86 ira
../../git/gcc/gcc/ira.c:5196
0x96cb86 execute
../../git/gcc/gcc/ira.c:5526
Please submit a full bug report,


gdb session:

Program received signal SIGSEGV, Segmentation fault.
make_tree (type=type@entry=0x0, x=0x2e7b0480) at
../../git/gcc/gcc/expmed.c:5085
5085  t = wide_int_to_tree (type, std::make_pair (x, TYPE_MODE
(type)));
(gdb) bt
#0  make_tree (type=type@entry=0x0, x=0x2e7b0480) at
../../git/gcc/gcc/expmed.c:5085
#1  0x007f2d27 in make_tree (type=0x2e7ac7e0, x=0x2e8b0890) at
../../git/gcc/gcc/expmed.c:5111
#2  0x00e1ef71 in force_const_mem (mode=SImode, x=0x2e8b0890) at
../../git/gcc/gcc/varasm.c:3722
#3  0x0096cb87 in setup_reg_equiv () at ../../git/gcc/gcc/ira.c:3933
#4  ira (f=) at ../../git/gcc/gcc/ira.c:5196
#5  (anonymous namespace)::pass_ira::execute (this=) at
../../git/gcc/gcc/ira.c:5526
#6  0x00a509fe in execute_one_pass (pass=pass@entry=0x20d9db0) at
../../git/gcc/gcc/passes.c:2340
#7  0x00a50ff8 in execute_pass_list_1 (pass=0x20d9db0) at
../../git/gcc/gcc/passes.c:2429
#8  0x00a5100a in execute_pass_list_1 (pass=0x20d8d90) at
../../git/gcc/gcc/passes.c:2430
#9  0x00a51055 in execute_pass_list (fn=,
pass=) at ../../git/gcc/gcc/passes.c:2440
#10 0x00736e54 in cgraph_node::expand (this=0x2e8c9000) at
../../git/gcc/gcc/cgraphunit.c:1985
#11 0x007387f7 in expand_all_functions () at
../../git/gcc/gcc/cgraphunit.c:2121
#12 symbol_table::compile (this=0x2e7ac0a8) at
../../git/gcc/gcc/cgraphunit.c:2478
#13 0x0073aaa8 in compile (this=0x2e7ac0a8) at
../../git/gcc/gcc/cgraphunit.c:2571
#14 symbol_table::finalize_compilation_unit (this=0x2e7ac0a8) at
../../git/gcc/gcc/cgraphunit.c:2568
#15 0x00b1f4eb in compile_file () at ../../git/gcc/gcc/toplev.c:490
#16 0x00b21155 in do_compile () at ../../git/gcc/gcc/toplev.c:2003
#17 toplev::main (this=0x7fffc1a0, argc=, argv=) at ../../git/gcc/gcc/toplev.c:2137
#18 0x012eae67 in main (argc=6, argv=0x7fffc2a8) at
../../git/gcc/gcc/main.c:39

(gdb) list
5080
5081  switch (GET_CODE (x))
5082{
5083case CONST_INT:
5084case CONST_WIDE_INT:
5085  t = wide_int_to_tree (type, std::make_pair (x, TYPE_MODE
(type)));
5086  return t;
5087
5088case CONST_DOUBLE:
5089  STATIC_ASSERT (HOST_BITS_PER_WIDE_INT * 2 <=
MAX_BITSIZE_MODE_ANY_INT);

(gdb) p type
$1 = (tree) 0x0

(gdb) p debug_rtx (x)
(const_int 0 [0])

[Bug tree-optimization/71506] [5 Regression] ICE with libvpx with -floop-interchange: isl_constraint.c:627: expecting integer value

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Target Milestone|--- |5.5

[Bug middle-end/71700] [5 Regression] wrong code with struct assignment with sub-word signed bitfields

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Fixed for 5.5, 6.3, 7.0

[Bug middle-end/71700] [5 Regression] wrong code with struct assignment with sub-word signed bitfields

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Aug 25 09:26:15 2016
New Revision: 239754

URL: https://gcc.gnu.org/viewcvs?rev=239754=gcc=rev
Log:
[expr.c] PR middle-end/71700: zero-extend sub-word value when widening
constructor element

Backport from mainline
2016-07-12  Kyrylo Tkachov  

PR middle-end/71700
* expr.c (store_constructor): Mask sign-extended bits when widening
sub-word constructor element at the start of a word.

* gcc.c-torture/execute/pr71700.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/pr71700.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/expr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/71506] [5 Regression] ICE with libvpx with -floop-interchange: isl_constraint.c:627: expecting integer value

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
(In reply to Martin Liška from comment #2)
> Current trunk, as well as GCC 6.1.1 works fine.

This is a problem in loop-interchange.c, which was removed in the 6 release
(https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01651.html).

[Bug tree-optimization/71506] [5 Regression] ICE with libvpx with -floop-interchange: isl_constraint.c:627: expecting integer value

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
At the first call to build_linearized_memory_access, at the 3rd loop iteration
we have:
...
(gdb) 
133   subsize = isl_set_max_val (pdr->extent, aff);
(gdb) call (char *)
isl_printer_get_str(isl_printer_print_set(isl_printer_to_str(ctx),
pdr->extent))
$5 = 0x30f6b90 "{ [1, i1, i2, i3, i4] : i4 >= 0 and i1 >= 0 and i2 >= 0 and i3
>= 0 and i4 <= 1 and i3 <= 1 }"
(gdb) call (char *)
isl_printer_get_str(isl_printer_print_aff(isl_printer_to_str(ctx), aff))
$6 = 0x30f5e30 "{ [i0, i1, i2, i3, i4] -> [(i2)] }"
(gdb) n
134   isl_aff_free (aff);
(gdb) call (char *)
isl_printer_get_str(isl_printer_print_val(isl_printer_to_str(ctx), subsize))
$7 = 0x30f8f00 "infty"
...

The infinity in subsize is propagated to size, and then 'res =
isl_constraint_set_coefficient_val (res, isl_dim_out, offset + i, size)' ICEs
because isl_constraint_set_coefficient_val expects the last argument to be an
int.


In 5.0, subsize is an isl_val:
...
  isl_val *subsize;
  ...
  subsize = isl_set_max_val (pdr->extent, aff);
...

But in 4.9, subsize is an isl_int:
...
  isl_int subsize;
  ...
  isl_set_max (pdr->extent, aff, );
...
And at the same point in execution, subsize is 1 instead of infty (which seems
to be caused by subsize being 1 before the call, and isl_set_max not having an
effect, which sound fishy).

[Bug c++/77363] [5/6/7 Regression] Missing debug information in DWARF

[EngyCZ at gmail dot com]

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

--- Comment #3 from Jiří Engelthaler  ---
This pr68162 breaks the function

[Bug c++/77363] [5/6/7 Regression] Missing debug information in DWARF

[EngyCZ at gmail dot com]

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

Jiří Engelthaler  changed:

   What|Removed |Added

  Known to work||5.3.0

--- Comment #2 from Jiří Engelthaler  ---
Investigating the bug I found that GCC 5.3.0 is partially correct, same way as
4.8 and 4.9.

The bug was introduced by this revision
https://gcc.gnu.org/viewcvs/gcc?view=revision=231673

GIT 0c4341e59b724e51deb033a64e057159f27de7dd

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #10 from Vittorio Zecca  ---
(In reply to Gerhard Steinmetz from comment #1)
> While playing around, one example from ./gcc/testsuite/gfortran.dg/
> shows the same error with v6.0.0, but not with v5.3.1 :
> 
> 
> $ gfortran-6 -c complex_intrinsic_6.f90
> internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159
> 
> 
> $ gfortran-5 -c complex_intrinsic_6.f90
> # no ICE
> 
> 
> ---
> 
> Please correct : last line was cut away for example z4.f90 -- add "end"

Here it still fails with gcc trunk version 7.

[Bug tree-optimization/71506] ICE with libvpx with -floop-interchange: isl_constraint.c:627: expecting integer value

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #3 from Tom de Vries  ---
Further reduced example (at -O2 -floop-interchange):

enum enums { PLANE_TYPES };

struct RD_COUNTS
{
  enum enums coef_counts[2][2];
};

struct A
{
  struct RD_COUNTS rd_counts;
};

int j;

struct A *fn1_td;

void
fn1 (void)
{
  int i;

  for (i = 0; i < 2; i++)
for (j = 0; j < 2; j++)
  fn1_td->rd_counts.coef_counts[i][j] = PLANE_TYPES;
}

[Bug fortran/77351] ICE in remove_trim, at frontend-passes.c:1145

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
Hi steve,

> Thou shalt not derefernce NULL pointers.

Correct.

The patch is pre-approved (alternatively, it could be
considered obvious and simple).

Thanks!

Regards

Thomas

[Bug c/77323] Bad "defaults to 'int'" warning for unsupported types

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c/77323] Bad "defaults to 'int'" warning for unsupported types

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Thu Aug 25 08:22:56 2016
New Revision: 239752

URL: https://gcc.gnu.org/viewcvs?rev=239752=gcc=rev
Log:
PR c/77323
* c-decl.c (declspecs_add_type): Set typespec_word even when __intN
or _FloatN or _FloatNx is not supported.
(finish_declspecs): Set type to integer_type_node when _FloatN or
_FloatNx is not supported.

* gcc.dg/pr77323.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr77323.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/61636] generic lambda: segfault / "cannot call member function without object"

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||trippels at gcc dot gnu.org
Summary|generic lambda  "cannot |generic lambda: segfault /
   |call member function|"cannot call member
   |without object" |function without object"

--- Comment #20 from Markus Trippelsdorf  ---
Reduced testcase from PR77376:

struct a {
  void b();
  void c(void *, int);
};
void a::b() {
  auto d = [&](auto asdf) { c(asdf, 0); };
  d(nullptr);
}