[Bug middle-end/71690] some integer conversions defeat memcpy optimizaton

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
In addition to the data in comment #4, the script below extracts VRP ranges for
an argument passed via the ellipsis to __builtin_snprintf.  The script output
shows that despite the same bounds on a variable, VRP exposes different ranges
for different types of the variable, and the ranges sometimes differ between C
and C++.  Unfortunately, the ranges only correspond to the actual bounds in the
relatively rare cases of char and short in C, and only in the signed forms of
those types in C++.  Cells with anything but [0, 9] in them indicate a
suboptimal result.

That the correct range be made available is important to me because of a patch
for bug 49905 I'm testing because it would help reduce false positives.

$ (cat vrp.c && for t in signed unsigned; do for u in char short int long 'long
long'; do printf "%-20s " "$t $u"; for l in c c++; do
/build/gcc-6-branch/gcc/xgcc -B/build/gcc-6-branch/gcc -DT="$t $u" -O2 -S -Wall
-Wextra -Wpedantic -fdump-tree-vrp=vrp.out -x$l vrp.c 2>/dev/null; v=$(sed -n
"s/ *__builtin_snprintf.*, *\([^ ,]*\));/\1/p" vrp.out); r=$(sed -n "s/^$v:
*\(.*\)/\1/p" vrp.out | tail -n1); printf "%-20s" "$r"; done; echo; done; done)
char d [10];
char s [10];

void f (T n)
{
  if (n < 0 || n >= 10) return;

  __builtin_snprintf (d, 10, "%i", n);
}

signed char  [0, 9]  [0, 9]
signed short [0, 9]  [0, 9]
signed int   VARYING VARYING
signed long  VARYING VARYING
signed long long VARYING VARYING
unsigned char[0, 9]  [0, 255]
unsigned short   [0, 9]  [0, 65535]
unsigned int VARYING VARYING
unsigned longVARYING VARYING
unsigned long long   VARYING VARYING

[Bug fortran/71686] ICE on broken character continuation

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-29
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jerry DeLisle  ---
I will take this one.

[Bug fortran/71686] ICE on broken character continuation

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #1 from Jerry DeLisle  ---
With this patch:

diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c
index 6a7a5b68..be9c5091 100644
--- a/gcc/fortran/scanner.c
+++ b/gcc/fortran/scanner.c
@@ -1416,7 +1416,8 @@ restart:
{
  if (in_string)
{
- gfc_current_locus.nextc--;
+ if (gfc_current_locus.nextc)
+   gfc_current_locus.nextc--;
  if (warn_ampersand && in_string == INSTRING_WARN)
gfc_warning (OPT_Wampersand, 
 "Missing %<&%> in continued character "
@@ -1427,7 +1428,10 @@ restart:
  /* Both !$omp and !$ -fopenmp continuation lines have & on the
 continuation line only optionally.  */
  else if (openmp_flag || openacc_flag || openmp_cond_flag)
-   gfc_current_locus.nextc--;
+   {
+ if (gfc_current_locus.nextc)
+ gfc_current_locus.nextc--;
+   }
  else
{
  c = ' ';


I get:

$ gfc bug1.f90 
bug1.f90:3:8:

z = 'abc&
1
Error: Unterminated character constant beginning at (1)
f951: Error: Unexpected end of file in ‘bug1.f90’
$ gfc bug2.f90 
bug2.f90:2:24:

character(8) :: z = 'abc&
1
Error: Unterminated character constant beginning at (1)
f951: Error: Unexpected end of file in ‘bug2.f90’

[Bug middle-end/71690] some integer conversions defeat memcpy optimizaton

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|absence of integer  |some integer conversions
   |conversion defeats memcpy   |defeat memcpy optimizaton
   |optimizaton |

--- Comment #4 from Martin Sebor  ---
While debugging this I noticed other cases where VRP either doesn't make the
range information available at all, or makes a "super-range" of the actual
range available.  I used the script below to see what types defeat the
optimization in what languages (C in the second column and C++ in the third). 
Based on the results a more accurate description of the problem might be that
some integer conversions (including the identity conversion if there were such
a thing) defeat VRP.  An interesting case is unsigned short in C++ where VRP
misses the value range altogether but exposes the range of the type instead.

$ cat vrp.c && for t in signed unsigned; do for u in char short int long 'long
long'; do printf "%-20s " "$t $u"; for l in c c++; do
m=$(/build/gcc-6-branch/gcc/xgcc -B/build/gcc-6-branch/gcc -DT="$t $u" -O2 -S
-Wall -Wextra -Wpedantic -o/dev/stdout -x$l vrp.c 2>/dev/null | grep memcpy);
if [ "$m" ]; then printf "%-8s" call; else printf "%-8s" inline; fi; done;
echo; done; done
char d [10];
char s [10];

void f (T n)
{
  if (n < 0 || n >= 10) return;

  __builtin_memcpy (d, s, n);
}

signed char  inline  inline  
signed short inline  inline  
signed int   inline  inline  
signed long  callcall
signed long long callcall
unsigned charinline  inline  
unsigned short   inline  call
unsigned int inline  inline  
unsigned longcallcall
unsigned long long   callcall

[Bug c/71685] [6 Regression] Segmentation fault in gcc when compiling the attached file.

[wilson at gcc dot gnu.org]

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

--- Comment #7 from Jim Wilson  ---
An early exit if type_quals is 0 does not work, as there is at least one place
that deliberately calls c_build_qualified_type with no type qualifiers to
create an unqualified type from a qualified type.  Likewise, my earlier
suggestion of a check for var_type != type can't work as it fails in this case
too.

I can see another possible fix, checking for type_quals non-zero before
clearing the C_TYPE_INCOMPLETE_VARS, but given how complicated this code is
turning out to be, the check for a type main variant is the safest fix.  And I
see that Jakub has just checked in a patch for that solution, so I'm assuming I
don't need to do anymore work on this.

[Bug c/71685] [6 Regression] Segmentation fault in gcc when compiling the attached file.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression]|[6 Regression] Segmentation
   |Segmentation fault in gcc   |fault in gcc when compiling
   |when compiling the attached |the attached file.
   |file.   |

--- Comment #6 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug middle-end/71690] absence of integer conversion defeats memcpy optimizaton

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
To fix this, would mean we keep around copies and PHInodes longer.  I don't
know if we want to do that because it causes code generation to be very bad
really.

[Bug c/71685] [6/7 Regression] Segmentation fault in gcc when compiling the attached file.

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 28 22:30:04 2016
New Revision: 237830

URL: https://gcc.gnu.org/viewcvs?rev=237830=gcc=rev
Log:
PR c/71685
* c-typeck.c (c_build_qualified_type): Don't clear
C_TYPE_INCOMPLETE_VARS for the main variant.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr71685.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/71690] absence of integer conversion defeats memcpy optimizaton

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Martin Sebor from comment #1)
> See also C++ bug 71654 for the "inverse" of the problem where VRP
> successfully provides range information in the absence of a conversion but
> fails with it.

That is a totally different issue.
The issue here is that range information has to be correct for all places where
the name is used.  Without a cast the name is used in both the comparison and
in the memcpy so the range needs to be empty so the comparison is not removed.

[Bug middle-end/71654] [6/7 Regression] missing VRP optimization on c++ unsigned char and short expressions

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
Don't have the time to thoroughly test at the moment but this seems to fix it
on the VRP side:

diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index c2115f4..1a0aa42 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -5298,7 +5298,7 @@ register_edge_assert_for_1 (tree name, edge e,
gimple_stmt_iterator bsi,
  if (CONVERT_EXPR_CODE_P (rhs_code)
  && INTEGRAL_TYPE_P (TREE_TYPE (name2))
  && TYPE_UNSIGNED (TREE_TYPE (name2))
- && prec == TYPE_PRECISION (TREE_TYPE (name2))
+ && prec >= TYPE_PRECISION (TREE_TYPE (name2))
  && (comp_code == LE_EXPR || comp_code == GT_EXPR
  || !tree_int_cst_equal (val,
  TYPE_MIN_VALUE (TREE_TYPE (val

[Bug fortran/70524] [5/6/7 Regression] ICE when using -frepack-arrays -Warray-temporaries

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Gerhard Steinmetz from comment #5)
> There is a different ICE for a subset of the above group.

It is probably a similar issue: gfortran is passing a wrong location. You need
to figure out using gdb what loc and offset is being passed to
linemap_position_for_loc_and_offset, where do they come from and what should be
passed instead.

The ICEs should only happen with --enabled-checking. Released compilers do not
ICE but give a wrong location.

[Bug middle-end/71690] integer conversion defeats memcpy optimizaton

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
See also C++ bug 71654 for the "inverse" of the problem where VRP successfully
provides range information in the absence of a conversion but fails with it.

[Bug middle-end/71690] New: integer conversion defeats memcpy optimizaton

[msebor at gcc dot gnu.org]

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

Bug ID: 71690
   Summary: integer conversion defeats memcpy optimizaton
   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: ---

Both functions in the following program are expected to result in comparably
efficient code.  In expand_builtin_memcpy, GCC decides whether an invocation of
__builtin_memcpy will be expanded inline or result in a library call.  Among
the factors it uses to make that decision is the range of sizes of the copy. 
The range is obtained from the result of the Value Range Propagation
optimization for the size argument, provided the argument is constrained to a
subrange of its type.  When the argument's type is other than size_t, VRP makes
the range available, and the call to memcpy may be expanded inline (this is the
case with the function g below).  But when the argument's type is size_t, VRP
does not make its range available, and the expansion results in a library call,
thus defeating the optimization.  This seems to be a general problem with VRP,
not one limited to memcpy (I just used memcpy as an example).  Any built-in
whose expansion depends on the result of VRP of one of its arguments may be
affected.

char d [10];
char s [10];

void f (int);

void g (unsigned n)
{
  if (n >= sizeof d) return;

  __builtin_memcpy (d, s, n);
}

void h (unsigned long n)
{
  if (n >= sizeof d) return;

  __builtin_memcpy (d, s, n);
}



The problem can be seen in the generated assembly and also in the vrp dump for
the program (see the <<< annotations):

Value ranges after VRP:

...
_1: [0, 9]
.MEM_2: VARYING
n_3(D): VARYING
n_6: [0, 9]  EQUIVALENCES: { n_3(D) } (1 elements)


g (unsigned int n)
{
  long unsigned int _1;

  :
  if (n_3(D) > 9)
goto ;
  else
goto ;

  :
  _1 = (long unsigned int) n_3(D);   <<< constrained to [0, 9]
  __builtin_memcpy (, , _1);

  :
  return;
}
...
Value ranges after VRP:

.MEM_1: VARYING
n_2(D): VARYING
n_5: [0, 9]  EQUIVALENCES: { n_2(D) } (1 elements)


h (long unsigned int n)
{
  :
  if (n_2(D) > 9)
goto ;
  else
goto ;

  :
  __builtin_memcpy (, , n_2(D));   <<< n_2(D) is VARYING

  :
  return;

}

[Bug c++/71671] g++: internal compiler error: Killed (program cc1plus)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #11 from Markus Trippelsdorf  ---
Yeah. And we still have no testcase. 
Closing.

[Bug c++/71671] g++: internal compiler error: Killed (program cc1plus)

[tiago at skewed dot de]

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

Tiago de Paula Peixoto  changed:

   What|Removed |Added

 CC||tiago at skewed dot de

--- Comment #10 from Tiago de Paula Peixoto  ---
Just chiming in here: This code makes heavy use of templates, and indeed takes
many gigs of RAM to compile. Although it would be nice if GCC were able to
compile it using less memory, I do not believe this is really a bug at all.

[Bug c/71552] Confusing error for incorrect struct initialization

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Fixed in r237829.

[Bug c/71552] Confusing error for incorrect struct initialization

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Tue Jun 28 20:09:36 2016
New Revision: 237829

URL: https://gcc.gnu.org/viewcvs?rev=237829=gcc=rev
Log:
PR c/71552 - Confusing error for incorrect struct initialization

gcc/c/ChangeLog:

PR c/71552
* c-typeck.c (output_init_element): Diagnose incompatible types
before non-constant initializers.

gcc/testsuite/ChangeLog:

PR c/71552
* gcc.dg/init-bad-9.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/init-bad-9.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c/71689] New: Missing dwarf info when using nested function

[asnast at gmail dot com]

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

Bug ID: 71689
   Summary: Missing dwarf info when using nested function
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asnast at gmail dot com
  Target Milestone: ---

Hello,

The following piece of code will fail to correctly generate dwarf function
signature information:

void outer(int *x)
{
*x *= 2;
void inner(void) { *x += 1; }
}

int main()
{
return 0;
}

When compiling with "gcc -g " a DW_TAG_formal_parameter DIE is not
generated for 'x' parameter for outer function above:

dwarfdump -a ./a.out:
LOCAL_SYMBOLS:
< 1><0x002d>DW_TAG_subprogram
  DW_AT_external  yes(1)
  DW_AT_name  "outter"
  DW_AT_decl_file 0x0001 /home/alexsn/tst.c
  DW_AT_decl_line 0x0001
  DW_AT_prototypedyes(1)
  DW_AT_low_pc0x00400566
  DW_AT_high_pc   68
  DW_AT_frame_baselen 0x0001: 9c:
DW_OP_call_frame_cfa
  DW_AT_GNU_all_tail_call_sitesyes(1)
  DW_AT_sibling   <0x005e>
< 2><0x004a>  DW_TAG_subprogram
...

Note that this only occurs if 'x' parameter if used from both outer and inner
function and removing either will correctly generate the missing DIE:

void outer(int *x)
{
void inner(void) { *x += 1; }
}

or

void outer(int *x)
{
*x *= 2;
void inner(void) { }
}

Will generate:
LOCAL_SYMBOLS:
< 1><0x002d>DW_TAG_subprogram
  DW_AT_external  yes(1)
  DW_AT_name  "outter"
  DW_AT_decl_file 0x0001 /home/alexsn/tst.c
  DW_AT_decl_line 0x0001
  DW_AT_prototypedyes(1)
  DW_AT_low_pc0x00400566
  DW_AT_high_pc   58
  DW_AT_frame_baselen 0x0001: 9c:
DW_OP_call_frame_cfa
  DW_AT_GNU_all_tail_call_sitesyes(1)
  DW_AT_sibling   <0x005e>
< 2><0x004a>  DW_TAG_formal_parameter
DW_AT_name  "x"
DW_AT_decl_file 0x0001
/home/alexsn/tst.c
DW_AT_decl_line 0x0001
DW_AT_type  <0x005e>

I've tested this on gcc 4.8.4 and gcc 5.3.1 both of which havethis issue.

Thanks, Alex.

[Bug target/58655] [avr] -mfract-convert-truncate not documented

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

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

--- Comment #2 from Georg-Johann Lay  ---
Done.

[Bug middle-end/71626] [4.9/5/6 regression] ICE at -O1 and above on x86_64-linux-gnu (in output_constant_pool_2, at varasm.c:3837)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.9/5/6/7 regression] ICE  |[4.9/5/6 regression] ICE at
   |at -O1 and above on |-O1 and above on
   |x86_64-linux-gnu (in|x86_64-linux-gnu (in
   |output_constant_pool_2, at  |output_constant_pool_2, at
   |varasm.c:3837)  |varasm.c:3837)

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug fortran/71688] ICE in analyze, at cgraphunit.c:632

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

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

--- Comment #1 from Gerhard Steinmetz  
---
Modified a bit :


$ cat z2.f90
program p
   call s
contains
   subroutine s
  real :: x[*] = 1
  block
  end block
  x = 2
   end
end


$ gfortran-6 -fcoarray=lib z2.f90
z2.f90:1:0:

 program p

internal compiler error: in analyze, at cgraphunit.c:632

[Bug fortran/71688] New: ICE in analyze, at cgraphunit.c:632

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

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

Bug ID: 71688
   Summary: ICE in analyze, at cgraphunit.c:632
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Aborting with gfortran-7-20160626, 6.1, 5.4, 4.9 :


$ cat z1.f90
program p
   call s
contains
   subroutine s
  real, save :: x[*]
  x = 2
  block
  end block
   end
end


$ gfortran-6 -fcoarray=single z1.f90
$ gfortran-6 -fcoarray=lib z1.f90
z1.f90:1:0:

 program p

internal compiler error: in analyze, at cgraphunit.c:632

[Bug fortran/71687] ICE in omp_add_variable, at gimplify.c:5821

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

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

--- Comment #1 from Gerhard Steinmetz  
---
As known, case above works with "workshare" :


$ cat z2.f90
subroutine s (n, x)
   integer :: n
   real :: x(n)
!$omp parallel workshare
   x(1:n) = x(n:1:-1)
!$omp end parallel workshare
end

[Bug fortran/71687] New: ICE in omp_add_variable, at gimplify.c:5821

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

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

Bug ID: 71687
   Summary: ICE in omp_add_variable, at gimplify.c:5821
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Using -fopenmp together with -fstack-arrays or -Ofast
for a test similar to pr49792 (also related to pr69281) :


$ cat z1.f90
subroutine s (n, x)
   integer :: n
   real :: x(n)
!$omp parallel
   x(1:n) = x(n:1:-1)
!$omp end parallel
end


$ gfortran-6 -fopenmp -fstack-arrays -c z1.f90
z1.f90:5:0:

x(1:n) = x(n:1:-1)

internal compiler error: in omp_add_variable, at gimplify.c:5821

[Bug fortran/71686] New: ICE on broken character continuation

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

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

Bug ID: 71686
   Summary: ICE on broken character continuation
   Product: gcc
   Version: 6.1.1
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 a broken character continuation :

$ cat z1.f90
program p
   character(8) :: z
   z = 'abc&
!end

$ cat z2.f90
program p
   character(8) :: z = 'abc&
!end


$ gfortran-6 z1.f90
f951: internal compiler error: Segmentation fault

$ gfortran-6 z2.f90
f951: internal compiler error: Segmentation fault

---

Whereas :

$ cat z3.f90
program p
   character(8) :: z = 'abc&


$ gfortran-6 z3.f90
z3.f90:2:24:

character(8) :: z = 'abc&
1
Error: Unterminated character constant beginning at (1)

[Bug middle-end/71626] [4.9/5/6/7 regression] ICE at -O1 and above on x86_64-linux-gnu (in output_constant_pool_2, at varasm.c:3837)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 28 18:31:42 2016
New Revision: 237826

URL: https://gcc.gnu.org/viewcvs?rev=237826=gcc=rev
Log:
PR middle-end/71626
* config/i386/i386.c (ix86_expand_vector_move): For SUBREG of
a constant, force its SUBREG_REG into memory or register instead
of whole op1.

* gcc.c-torture/execute/pr71626-1.c: New test.
* gcc.c-torture/execute/pr71626-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr71626-1.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr71626-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/70524] [5/6/7 Regression] ICE when using -frepack-arrays -Warray-temporaries

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

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

Gerhard Steinmetz  changed:

   What|Removed |Added

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

--- Comment #5 from Gerhard Steinmetz  
---
There is a different ICE for a subset of the above group.
A selection of affected files from gfortran testsuite :

   character_array_constructor_1.f90
   char_pack_2.f90
   missing_optional_dummy_6.f90
   optional_absent_1.f90
   pr43793.f90
   pr48636.f90
   whole_file_9.f90


For example :

$ gfortran-7-20160626 -frepack-arrays -Warray-temporaries -c pr43793.f90
pr43793.f90:11:31:

rq(1:rcount(pos),pos) = rs(1:rcount(pos),pos)
   1
Warning: Creating array temporary at (1) [-Warray-temporaries]

pr43793.f90:5:0:

   subroutine sparse_alltoall (rs, rq, rcount)

in linemap_position_for_loc_and_offset, at libcpp/line-map.c:897
0x138c523 linemap_position_for_loc_and_offset(line_maps*, unsigned int,
unsigned int)
../../libcpp/line-map.c:897
0x6822fc gfc_format_decoder
../../gcc/fortran/error.c:943
0x13771f8 pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:643
0x13720f0 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:827
0x68205f gfc_warning
../../gcc/fortran/error.c:792
0x682ce6 gfc_warning(int, char const*, ...)
../../gcc/fortran/error.c:823
0x72a291 gfc_trans_dummy_array_bias(gfc_symbol*, tree_node*,
gfc_wrapped_block*)
../../gcc/fortran/trans-array.c:6177
0x7466ec gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*)
../../gcc/fortran/trans-decl.c:4268
0x749223 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6275
0x71ea79 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2056
0x6d4bfd translate_all_program_units
../../gcc/fortran/parse.c:5830
0x6d4bfd gfc_parse_file()
../../gcc/fortran/parse.c:6049
0x717142 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:201

[Bug target/58655] [avr] -mfract-convert-truncate not documented

[denisc at gcc dot gnu.org]

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

--- Comment #1 from denisc at gcc dot gnu.org ---
Author: denisc
Date: Tue Jun 28 17:56:37 2016
New Revision: 237825

URL: https://gcc.gnu.org/viewcvs?rev=237825=gcc=rev
Log:
PR target/58655
* config/avr/avr.opt (-mfract-convert-truncate): Update description.
* doc/invoke.texi (AVR Options): Document it.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.opt
trunk/gcc/doc/invoke.texi

[Bug tree-optimization/71683] [7 Regression] ICE in gen_phi_arg_condition, at tree-if-conv.c:1705 w/ -ftree-vectorize -O2 (and above)

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha  ---
(In reply to Jakub Jelinek from comment #1)
> Started wutg r235808.

Must be a duplicate of PR71503, then.

[Bug target/70814] atomic store of __int128 is not lock free on aarch64

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Richard Earnshaw from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > Closing as invalid.  Though for v8.4 or so it would be nice if there was
> > 128bit atomic loads.
> 
> That probably wouldn't help.  It would require a new ABI before you could
> use them, since all code has to swap to that mechanism.  Iff you could
> guarantee that an application had exactly one instance of
> __atomic_{load,store}_16 (ie that it isn't a private function in each DSO
> component), then you *might* be able to re-implement those routines using
> the new instructions, but otherwise you're stuck with the requirement to
> retain backwards compatibility.

On x86, they use ifuncs for this purpose inside libatomic. Basically the
requirement is only one libatomic can be used at a time.

[Bug target/70814] atomic store of __int128 is not lock free on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #8 from Richard Earnshaw  ---
(In reply to Andrew Pinski from comment #7)
> Closing as invalid.  Though for v8.4 or so it would be nice if there was
> 128bit atomic loads.

That probably wouldn't help.  It would require a new ABI before you could use
them, since all code has to swap to that mechanism.  Iff you could guarantee
that an application had exactly one instance of __atomic_{load,store}_16 (ie
that it isn't a private function in each DSO component), then you *might* be
able to re-implement those routines using the new instructions, but otherwise
you're stuck with the requirement to retain backwards compatibility.

[Bug c/71685] [6/7 Regression] Segmentation fault in gcc when compiling the attached file.

[wilson at gcc dot gnu.org]

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

--- Comment #4 from Jim Wilson  ---
The problem here is that I assumed that c_build_qualified_type would only be
called when we want to create a variant type.  However, there are a number of
places that call it without checking to see if we have any type qualifiers
first.  These places can call it with no qualifiers, in which case it returns
the original type, which may be a main variant type.  So we need to avoid
clearing C_TYPE_INCOMPLETE_TYPE in that case.  Perhaps with an early exit at
the top if type_quals is 0.  Or alternatively, at the bottom, we can clear
C_TYPE_INCOMPLETE_TYPE only if var_type != type.

[Bug target/70814] atomic store of __int128 is not lock free on aarch64

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Richard Earnshaw from comment #5)
> I don't think so.  It's to do with whether the CPU is permitted to 'crack'
> the operation into multiple micro-ops that proceed independently down the
> pipeline.  LDAXP could still be cracked in this way provided that from that
> CPU's perspective other memory operations from that core were not re-ordered
> with respect to that operation in an incompatible manner.  However, external
> memory operations could still cause the separate micro-ops to see different
> values.

Makes sense (and I Know of one micro arch which will doing that for casp).

So closing as invalid.

Note the locks used in libatomic are no where near fair and can cause sometimes
not progressing on one thread (but that is a separate bug and is recorded as
bug 59305).

[Bug libstdc++/71684] Memory leak with std::mutex and std::lock_guard on freebsd

[nsz at gcc dot gnu.org]

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

--- Comment #5 from nsz at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to nsz from comment #1)
> > on a posix platform pthread_mutex_destroy should be called for a mutex if
> > its life time ends, so the ifdef logic seems wrong (the initializer does not
> > make a difference).
> 
> I don't think that's clear from the POSIX spec. In previous versions
> PTHREAD_MUTEX_INITIALIZER was only specified to be valid for statically
> allocated objects, which live for the lifetime of the program and so there's
> typically no need (or sensible time) to destroy them.
> 
> http://austingroupbugs.net/view.php?id=70#c127 changed the rules
> so now you can use the initializer for automatic objects, and structure
> members, but it's unclear whether you do need to use pthread_mutex_destroy
> on them.
> Maybe POSIX should clarify.
> 

i see.

> On some older versions of FreeBSD using PTHREAD_MUTEX_INITIALIZER and then
> pthread_mutex_destroy would segfault, see
> http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004905.html
> 
> So it's not clear to me that using that combination is a good idea.

in the current spec PTHREAD_MUTEX_INITIALIZER must have the same effect as
pthread_mutex_init(,0) without error checks, which means
pthread_mutex_destroy should work accordingly (and indeed pthread_mutex_lock
should not fail with ENOMEM either).

so this may need platform specific workarounds.

[Bug target/70814] atomic store of __int128 is not lock free on aarch64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Andrew Pinski  ---
Closing as invalid.  Though for v8.4 or so it would be nice if there was 128bit
atomic loads.

[Bug tree-optimization/71683] [7 Regression] ICE in gen_phi_arg_condition, at tree-if-conv.c:1705 w/ -ftree-vectorize -O2 (and above)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-28
 CC||amker at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started wutg r235808.

[Bug target/70814] atomic store of __int128 is not lock free on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #5 from Richard Earnshaw  ---
I don't think so.  It's to do with whether the CPU is permitted to 'crack' the
operation into multiple micro-ops that proceed independently down the pipeline.
 LDAXP could still be cracked in this way provided that from that CPU's
perspective other memory operations from that core were not re-ordered with
respect to that operation in an incompatible manner.  However, external memory
operations could still cause the separate micro-ops to see different values.

[Bug c/71685] [6/7 Regression] Segmentation fault in gcc when compiling the attached file.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|mpolacek at gcc dot gnu.org|jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Created attachment 38783
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38783=edit
gcc7-pr71685.patch

Untested fix.

[Bug c++/71675] __atomic_compare_exchange_n returns wrong type for typed enum

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01896.html

[Bug target/70814] atomic store of __int128 is not lock free on aarch64

[yyc1992 at gmail dot com]

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

--- Comment #4 from Yichao Yu  ---
Thanks for the explanation. I didn't realize that the load is the problem. Just
curious (since I somehow can't find documentation about it), would `ldaxp`
provide the right semantics without the corresponding store?

[Bug c/71685] [6/7 Regression] Segmentation fault in gcc when compiling the attached file.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug target/71656] ICE in reload when generating code for -mcpu=power9 -mpower9-dform-vector

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner  ---
Author: bergner
Date: Tue Jun 28 15:49:10 2016
New Revision: 237823

URL: https://gcc.gnu.org/viewcvs?rev=237823=gcc=rev
Log:
PR target/71656
* gcc.target/powerpc/pr71656-2.c: Fix syntax errors.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/pr71656-2.c

[Bug c++/71679] gcc silently accepts parameter number mismatch in template redeclaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-28
 Ever confirmed|0   |1

[Bug libstdc++/71684] Memory leak with std::mutex and std::lock_guard on freebsd

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #3)
> On some older versions of FreeBSD using PTHREAD_MUTEX_INITIALIZER and then
> pthread_mutex_destroy would segfault, see
> http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004905.html

I misremembered, it aborts. Still not good though.

[Bug libstdc++/71684] Memory leak with std::mutex and std::lock_guard on freebsd

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to nsz from comment #1)
> on a posix platform pthread_mutex_destroy should be called for a mutex if
> its life time ends, so the ifdef logic seems wrong (the initializer does not
> make a difference).

I don't think that's clear from the POSIX spec. In previous versions
PTHREAD_MUTEX_INITIALIZER was only specified to be valid for statically
allocated objects, which live for the lifetime of the program and so there's
typically no need (or sensible time) to destroy them.

http://austingroupbugs.net/view.php?id=70#c127 changed the rules
so now you can use the initializer for automatic objects, and structure
members, but it's unclear whether you do need to use pthread_mutex_destroy on
them.
Maybe POSIX should clarify.

On some older versions of FreeBSD using PTHREAD_MUTEX_INITIALIZER and then
pthread_mutex_destroy would segfault, see
http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004905.html

So it's not clear to me that using that combination is a good idea.

[Bug libstdc++/71684] Memory leak with std::mutex and std::lock_guard on freebsd

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-28
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
(In reply to Phil Longstaff from comment #0)
> std::lock_guard constructor calls gthread_mutex_lock() which calls
> pthread_mutex_lock(), a 'struct pthread_mutex' will be created using
> calloc() and then locked.

I was made aware of this behaviour of FreeBSD recently, but I'm not sure that
it's conforming. pthread_mutex_lock() isn't allowed to fail with ENOMEM (and
EAGAIN is supposed to mean too many locks are held, not that memory couldn't be
allocated).

Conforming or not, we need to deal with it.

[Bug libstdc++/71684] Memory leak with std::mutex and std::lock_guard on freebsd

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nsz at gcc dot gnu.org

--- Comment #1 from nsz at gcc dot gnu.org ---
on a posix platform pthread_mutex_destroy should be called for a mutex if its
life time ends, so the ifdef logic seems wrong (the initializer does not make a
difference).

[Bug c/71685] [6/7 Regression] Segmentation fault in gcc when compiling the attached file.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org,
   ||wilson at gcc dot gnu.org
   Target Milestone|--- |6.2
Summary|Segmentation fault in gcc   |[6/7 Regression]
   |when compiling the attached |Segmentation fault in gcc
   |file.   |when compiling the attached
   ||file.

--- Comment #2 from Jakub Jelinek  ---
Started with r229505.

[Bug c/71685] Segmentation fault in gcc when compiling the attached file.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-28
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Reduced testcase:
extern struct S v, s;
struct S { int t; int p[]; } v = { 4, 0 };

[Bug target/70814] atomic store of __int128 is not lock free on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #3 from Richard Earnshaw  ---
Atomic loads and stores have to use the same policy for a single object, you
can't have loads using one model and stores another.

Atomic loads have to work even if the object is marked const.

C/C++ permit a non-const object pointer to be cast to a const object pointer. 
That means that any mechanism used for atomic loads has to work with const
objects, in particular with objects that are immutable (would trap if
modification were attempted).

The v8 ARM ARM says that the way to perform a 128-bit atomic read using ldxp is
to read the value and then attempt to store it back using a stxp; if the store
succeeds, then the read was atomic, otherwise it was not and must be retried. 
This model doesn't work if the object was immutable, since the store will
fault.

The consequence of this is that ldxp cannot be used for atomic 128-bit reads. 
And the consequence of that is that stxp cannot be used for 128-bit stores. 
Ergo, the only way to perform 128-bit atomic accesses is by using locks.  So I
think the existing code is correct.

I'll leave this open for the moment for further discussion, but I'm minded to
reject as INVALID.

[Bug c/71685] New: Segmentation fault in gcc when compiling the attached file.

[vtselfa at gmail dot com]

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

Bug ID: 71685
   Summary: Segmentation fault in gcc when compiling the attached
file.
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vtselfa at gmail dot com
  Target Milestone: ---

Created attachment 38782
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38782=edit
Reduced file that triggers the segfault

[Bug rtl-optimization/67037] [4.9 Regression] Wrong code at -O1 and above on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #10 from Bernd Edlinger  ---
(In reply to Richard Earnshaw from comment #9)
> Any plans to backport to 4.9, or should this be closed?

I won't have time/resources for the necessary regression testing.
However the patch is quite simple, and will certainly work as-is.

[Bug libstdc++/71684] New: Memory leak with std::mutex and std::lock_guard on freebsd

[plongstaff at sandvine dot com]

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

Bug ID: 71684
   Summary: Memory leak with std::mutex and std::lock_guard on
freebsd
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: plongstaff at sandvine dot com
  Target Milestone: ---

On freebsd, pthread_mutex_t is a pointer to 'struct pthread_mutex'.
PTHREAD_MUTEX_INITIALIZER is defined as NULL. On freebsd, the code:

{
std::mutex m;
std::lock_guard lg(m);
}

will leak. 'm' will have _M_mutex initialized to NULL. When the std::lock_guard
constructor calls gthread_mutex_lock() which calls pthread_mutex_lock(), a
'struct pthread_mutex' will be created using calloc() and then locked. The
std::lock_guard destructor will unlock the mutex. However, since
std::mutex_base has:

  // Common base class for std::mutex and std::timed_mutex
  class __mutex_base
  {
  protected:
typedef __gthread_mutex_t   __native_type;

#ifdef __GTHREAD_MUTEX_INIT
__native_type  _M_mutex = __GTHREAD_MUTEX_INIT;

constexpr __mutex_base() noexcept = default;
#else
__native_type  _M_mutex;

__mutex_base() noexcept
{
  // XXX EAGAIN, ENOMEM, EPERM, EBUSY(may), EINVAL(may)
  __GTHREAD_MUTEX_INIT_FUNCTION(&_M_mutex);
}

~__mutex_base() noexcept { __gthread_mutex_destroy(&_M_mutex); }
#endif

__mutex_base(const __mutex_base&) = delete;
__mutex_base& operator=(const __mutex_base&) = delete;
  };

and __GTHREAD_MUTEX_INIT is defined as NULL, there is no destructor to destroy
the mutex. Therefore, that memory is leaked.

[Bug rtl-optimization/70030] [LRA]ICE when reload insn with output scratch operand

[renlin at gcc dot gnu.org]

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

--- Comment #8 from Renlin Li  ---
(In reply to Vladimir Makarov from comment #6)
> Created attachment 38033 [details]
> A patch
> 
> Here is the patch which might solve the problem.

Hi Vladimir,

Do you have plan to check this patch in?

Thanks!

[Bug c++/71675] __atomic_compare_exchange_n returns wrong type for typed enum

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Testing a fix.

[Bug tree-optimization/71683] [7 Regression] ICE in gen_phi_arg_condition, at tree-if-conv.c:1705 w/ -ftree-vectorize -O2 (and above)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug c++/71350] [4.9/5/6/7 regression] ICE on trailing return type declaration with initializer list

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4
Summary|[4.8/4.9/5/6/7 regression]  |[4.9/5/6/7 regression] ICE
   |ICE on trailing return type |on trailing return type
   |declaration with|declaration with
   |initializer list|initializer list

[Bug middle-end/71682] [7 Regression] Several libjava failures on x86_64-apple-darwin15 with -m32 after r237556

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug c++/71675] __atomic_compare_exchange_n returns wrong type for typed enum

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords|documentation   |rejects-valid

--- Comment #3 from Martin Sebor  ---
You're right.  I was mistaken in comment #1 about the return value: the
function does return a true/false result, but it appears to be of the wrong
type.  So the documentation is correct (it matches C11 atomic_compare_exchange)
and the bug is in the compiler.

The root cause seems to be the resolve_overloaded_builtin function in
builtins.c calling sync_resolve_return to convert the bool result to the enum,
which the C++ front end then rejects.

[Bug tree-optimization/71683] New: [7 Regression] ICE in gen_phi_arg_condition, at tree-if-conv.c:1705 w/ -ftree-vectorize -O2 (and above)

[asolokha at gmx dot com]

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

Bug ID: 71683
   Summary: [7 Regression] ICE in gen_phi_arg_condition, at
tree-if-conv.c:1705 w/ -ftree-vectorize -O2 (and
above)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-7.0.0-alpha20160626 ICEs when compiling the following reduced testcase w/
-ftree-vectorize -O2 (-O3, -Ofast):

short unsigned int ve;

void
u1 (void)
{
  int oq = 0;

  while (ve != 0)
{
  int j4, w7 = oq;

  oq = 0 / oq;
  ve %= oq;
  j4 = ve ^ 1;
  ve ^= oq;
  if (j4 != 0 ? j4 : ve)
oq = ve;
  else
if (w7 != 0)
  oq = ve;
}
}

% gcc-7.0.0-alpha20160626 -c -O2 -ftree-vectorize h0j2boji.c
h0j2boji.c: In function 'u1':
h0j2boji.c:4:1: internal compiler error: in gen_phi_arg_condition, at
tree-if-conv.c:1705

[Bug rtl-optimization/69886] ICE: in process_insert_insn, at gcse.c:1976 with --param=gcse-unrestricted-cost=0 @ aarch64

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.1.0
 Resolution|--- |FIXED

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Fixed for GCC 6.1.
Not planning backports as it's not a regression

[Bug target/69187] ICE: Aborted when native compiling neon code with __builtin_neon_vmlals_lanev4hi

[rearnsha at gcc dot gnu.org]

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

--- Comment #15 from Richard Earnshaw  ---
Any plans to backport this further?

[Bug c++/71639] [5.2.0] c++11 list initializer and std::transform - error?

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Right. Debug mode identifies a problem:

/home/jwakely/gcc/7/include/c++/7.0.0/debug/safe_iterator.h:297:
Error: attempt to increment a singular iterator.

Objects involved in the operation:
iterator "this" @ 0x0x7ffca3d04820 {
  type = __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator >, std::__debug::vector > (mutable iterator);
  state = singular;
  references sequence with type 'std::__debug::vector' @ 0x0x7ffca3d047a0
}
Aborted (core dumped)

[Bug rtl-optimization/67037] [4.9 Regression] Wrong code at -O1 and above on ARM

[rearnsha at gcc dot gnu.org]

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

--- Comment #9 from Richard Earnshaw  ---
Any plans to backport to 4.9, or should this be closed?

[Bug tree-optimization/66917] [4.9 regression] ARM: NEON: memcpy compiles to vst1 with incorrect alignment

[rearnsha at gcc dot gnu.org]

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

--- Comment #23 from Richard Earnshaw  ---
Any plans to backport to 4.9, or should this be closed?

[Bug c++/71679] gcc silently accepts parameter number mismatch in template redeclaration

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
The testcase can be further reduced:

template  struct A;
struct B {
  template  friend struct ::A;
};

When using A instead of ::A it works fine and gcc errors out:

llvm.ii:3:37: error: redeclared with 2 template parameters
   template  friend struct A;
 ^
llvm.ii:1:23: note: previous declaration ‘template > struct A’
used 1 template parameter
 template  struct A;
   ^

[Bug jit/64810] jit not working on armv7hl ("ld: error: /tmp/libgccjit-ZGemdr/fake.so uses VFP register arguments, /tmp/ccJFCBsE.o does not")

[rearnsha at gcc dot gnu.org]

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

--- Comment #27 from Richard Earnshaw  ---
(In reply to David Malcolm from comment #26)
> (In reply to Ramana Radhakrishnan from comment #25)
> > Fixed presumably ?
> 
> Mostly.  The remaining issue with configure-time options reaching the jit is
> when gcc is configured with:
>   --with-arch=native
> I attempted to fix that, but it appeared to be non-trivial, so I think I'll
> open that as a separate (non-arm) bug (sorry, have been on vacation in the
> meantime, and need to page it all back in to my brain...)

Is there anything further to be done on this?

[Bug lto/63607] run fail with -flto -mfloat-abi=softfp for armeb-linux-gnueabi-gcc

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Earnshaw  ---
No feedback in over a year

[Bug target/60882] [ARM] Execution fail on spec2K/197.parser

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Earnshaw  ---
No feedback in over 18 months

[Bug tree-optimization/71625] missing strlen optimization on different array initialization style

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization
Version|tree-ssa|7.0
   Target Milestone|--- |7.0

[Bug target/71680] [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
We have an insn:

(insn 32 33 34 3 (set (reg:DI 165)
(unspec:DI [
(fix:SI (subreg:SF (reg:SI 160 [ a ]) 0))
] UNSPEC_FCTIWZ)) 71680.c:11 334 {fctiwz_sf}
 (expr_list:REG_DEAD (reg:SI 160 [ a ])
(nil)))

160 is allocated memory by IRA.  LRA does:

Changing pseudo 160 in operand 1 of insn 32 on equiv [r162:SI]
  Creating newreg=167, assigning class ALL_REGS to subreg reg r167
   32: r165:DI=unspec[fix(r167:SI#0)] 7
  REG_DEAD r160:SI
Inserting subreg reload before:
   37: r167:SI=[r162:SI]

and from then on it keeps loading 167 into another (new) SImode reg,
which never magically becomes a float reg ;-)

[Bug c++/71675] __atomic_compare_exchange_n returns wrong type for typed enum

[js at alien8 dot de]

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

--- Comment #2 from Julian Stecklina  ---
Return bool actually makes sense, because that is the result from the "compare"
part of compare/exchange. I am not sure what the meaning of 'type' as a result
would be.

[Bug target/71680] [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Yes, but it fails with -m32 too.

[Bug target/71680] [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra

[asolokha at gmx dot com]

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

--- Comment #5 from Arseny Solokha  ---
(In reply to Segher Boessenkool from comment #4)
> Oh never mind, I forgot -mlra, duh.
> 
> Confirmed, also on BE, -O2 -mlra fails already.

I can't make it fail on 32-bit BE, though. Segher, is your machine powerpc64?

[Bug target/71680] [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-28
 Ever confirmed|0   |1

--- Comment #4 from Segher Boessenkool  ---
Oh never mind, I forgot -mlra, duh.

Confirmed, also on BE, -O2 -mlra fails already.

[Bug target/71680] [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
anton: What flags for your test case?  I fail to reproduce it.

[Bug target/71680] [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

 CC||jiwang at gcc dot gnu.org

--- Comment #2 from Jiong Wang  ---
Does a revert of r237277 fix this issue?

[Bug middle-end/71682] New: [7 Regression] Several libjava failures on x86_64-apple-darwin15 with -m32 after r237556

[dominiq at lps dot ens.fr]

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

Bug ID: 71682
   Summary: [7 Regression] Several libjava failures on
x86_64-apple-darwin15 with -m32 after r237556
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: iains at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin15
Target: x86_64-apple-darwin15
 Build: x86_64-apple-darwin15

Revision r237556 causes the following failures on x86_64-apple-darwin15 with
-m32

FAIL: InvokeReturn execution - source compiled test
FAIL: InvokeReturn -findirect-dispatch execution - source compiled test
FAIL: InvokeReturn -O3 output - source compiled test
FAIL: InvokeReturn -O3 -findirect-dispatch execution - source compiled test
FAIL: PR3096 execution - source compiled test
FAIL: PR3096 -findirect-dispatch execution - source compiled test
FAIL: PR3096 -O3 execution - source compiled test
FAIL: PR3096 -O3 -findirect-dispatch execution - source compiled test
FAIL: Serialization execution - source compiled test
FAIL: Serialization -findirect-dispatch execution - source compiled test
FAIL: Serialization -O3 execution - source compiled test
FAIL: Serialization -O3 -findirect-dispatch execution - source compiled test
FAIL: md5test execution - source compiled test
FAIL: md5test -findirect-dispatch execution - source compiled test
FAIL: md5test -O3 execution - source compiled test
FAIL: md5test -O3 -findirect-dispatch execution - source compiled test
FAIL: negzero output - source compiled test
FAIL: negzero -findirect-dispatch output - source compiled test
FAIL: negzero -O3 output - source compiled test
FAIL: negzero -O3 -findirect-dispatch output - source compiled test
FAIL: pr21785 execution - source compiled test
FAIL: pr21785 -findirect-dispatch execution - source compiled test
FAIL: pr21785 -O3 execution - source compiled test
FAIL: pr21785 -O3 -findirect-dispatch execution - source compiled test
FAIL: pr25676 output - source compiled test
FAIL: pr25676 -findirect-dispatch output - source compiled test
FAIL: pr25676 -O3 output - source compiled test
FAIL: pr25676 -O3 -findirect-dispatch output - source compiled test
FAIL: shatest execution - source compiled test
FAIL: shatest -findirect-dispatch execution - source compiled test
FAIL: shatest -O3 execution - source compiled test
FAIL: shatest -O3 -findirect-dispatch execution - source compiled test

[Bug target/71680] [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra

[anton at samba dot org]

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

Anton Blanchard  changed:

   What|Removed |Added

 CC||anton at samba dot org

--- Comment #1 from Anton Blanchard  ---
I'm hitting this on powerpc64le with the following test case:

#pragma pack(1)
struct {
float f0;
} a;

void foo(int);

int main(void)
{
for (;;)
foo((int)a.f0);
}

[Bug middle-end/66867] Suboptimal code generation for atomic_compare_exchange

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Hopefully fixed for 7+.

[Bug target/71680] [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
   Target Milestone|--- |7.0

[Bug rtl-optimization/71673] [7 Regression] FAIL: c-c++-common/torture/builtin-arith-overflow-p-19.c -O2 (internal compiler error)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Hopefully fixed now.

[Bug rtl-optimization/70751] [7 Regression] FAIL: gcc.target/arm/eliminate.c scan-assembler-times r0,[\\t ]*sp 3 since r235184

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

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

--- Comment #7 from Dominik Vogt  ---
This commit triggers an ICE with s390x.  See
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01810.html
for details.

[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
> Thank you for the suggested workaround. This can certainly be helpful in the
> short term.  However, we would not want to rely on tuning compiler
> optimization switches in the future to ensure correct code operation.  ...

You can do the inlining in your code, e.g.,

--- pr71544.f90 2016-06-15 18:54:59.0 +0200
+++ pr71544_db.f90  2016-06-28 10:06:17.0 +0200
@@ -7,10 +7,12 @@ end module store_cptr

 subroutine init()
 use, intrinsic :: iso_c_binding
+use store_cptr
 implicit none
 integer(c_int), pointer :: a
 allocate(a)
-call save_cptr(c_loc(a))
+!call save_cptr(c_loc(a))
+cptr = c_loc(a)
 a = 100
 end subroutine init

[Bug preprocessor/71681] header.gcc file lookup is broken for -remap

[andris.pavenis at iki dot fi]

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

--- Comment #1 from Andris Pavenis  ---
Created attachment 38781
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38781=edit
Fix for problem

[Bug rtl-optimization/71673] [7 Regression] FAIL: c-c++-common/torture/builtin-arith-overflow-p-19.c -O2 (internal compiler error)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 28 08:29:11 2016
New Revision: 237815

URL: https://gcc.gnu.org/viewcvs?rev=237815=gcc=rev
Log:
PR rtl-optimization/71673
* internal-fn.c (expand_arith_overflow_result_store): Use
OPTAB_LIB_WIDEN instead of OPTAB_DIRECT as last argument to
expand_simple_binop.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/internal-fn.c

[Bug c++/71658] User-defined conversion operator from a wrapper class to the wrapped type does not compile.

[ulrichmutze at gmx dot de]

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

--- Comment #3 from Ulrich Mutze  ---
(In reply to Martin Sebor from comment #1)
> I believe the test case is invalid.
> 
> In a call to an operator, operator overload resolution in [over.match.oper]
> considers three sets of candidate functions:
> 1) member candidates (operators defined as members one of the operands)
> 2) non-member candidates (only non-member functions are considered)
> 3) built-in candidates (operators that take types to which the operands can
> be converted)
> 
> In the test case, sets (1) and (2) are obviously empty.  Set (3) is also
> empty because there is no well-formed implicit conversion sequence
> ([over.best.ics]) from Z1 to int (the conversion exists but would require
> two user-defined conversions, one from Z1 to Z and another from Z to int;
> such conversions are not well-formed).
> 
> Like GCC, both Clang 3.8 and EDG eccp 3.11 also reject the program.
> 
> The expression "Z(x0)+Z(x1)" is valid because the types of the operands are
> Z and thus do not require the second implicit user-defined conversion that
> makes set (3) above empty.

I believe that (3) is not empty since Z + Z is defined by a member function
in Z and the arguments of Z1 + Z1 can be implicitly converted to Z in a single 
step.

The type int is not in the game when Z sum=x0+x1; is under consideration.

The implicit conversion Z --> int was enabled simply to allow my function
main to return a reasonable value (which is required to be of type int).
Sorry for this misleading and superfluous complication in my code.

[Bug middle-end/66867] Suboptimal code generation for atomic_compare_exchange

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 28 08:27:18 2016
New Revision: 237814

URL: https://gcc.gnu.org/viewcvs?rev=237814=gcc=rev
Log:
PR middle-end/66867
* builtins.c (expand_ifn_atomic_compare_exchange_into_call,
expand_ifn_atomic_compare_exchange): New functions.
* internal-fn.c (expand_ATOMIC_COMPARE_EXCHANGE): New function.
* tree.h (build_call_expr_internal_loc): Rename to ...
(build_call_expr_internal_loc_array): ... this.  Fix up type of
last argument.
* internal-fn.def (ATOMIC_COMPARE_EXCHANGE): New internal fn.
* predict.c (expr_expected_value_1): Handle IMAGPART_EXPR of
ATOMIC_COMPARE_EXCHANGE result.
* builtins.h (expand_ifn_atomic_compare_exchange): New prototype.
* gimple-fold.h (optimize_atomic_compare_exchange_p,
fold_builtin_atomic_compare_exchange): New prototypes.
* gimple-fold.c (optimize_atomic_compare_exchange_p,
fold_builtin_atomic_compare_exchange): New functions..
* tree-ssa.c (execute_update_addresses_taken): If
optimize_atomic_compare_exchange_p, ignore  in 2nd argument
of call when finding addressable vars, and if such var becomes
non-addressable, call fold_builtin_atomic_compare_exchange.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/builtins.h
trunk/gcc/gimple-fold.c
trunk/gcc/gimple-fold.h
trunk/gcc/internal-fn.c
trunk/gcc/internal-fn.def
trunk/gcc/predict.c
trunk/gcc/tree-ssa.c
trunk/gcc/tree.h

[Bug preprocessor/71681] New: header.gcc file lookup is broken for -remap

[andris.pavenis at iki dot fi]

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

Bug ID: 71681
   Summary: header.gcc file lookup is broken for -remap
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andris.pavenis at iki dot fi
  Target Milestone: ---

Looking up header.gcc files in sub-directories (for example in case of
'#include ') is broken as directory separator is missing in
generated file names.

Added simple debugging output to static method remap_filename() in
libcpp/files.c. Some examples illustrating missing directory separator from
debug output are given below.

remap_filename() finds header file in top directories of include search path
but not in subdirectories in part of cases (one is getting
new_dir='/usr/includesys/' where name should have been './usr/include/sys/')

Test example foo.c:

#include "foo/bar/baz.h"
#include 

Used gcc version 7.0.0-20160628. Problem present also in several earlier GCC
versions. Problem actually detected for DJGPP, but can easily be reproduced
under Linux as done in this case)

[andris@localhost test]$ ../xgcc -B ../ -c -remap foo.c 
remap_filename: fname='foo.c'
remap_filename: fname='stdc-predef.h'
remap_filename: fname='stdc-predef.h'
remap_filename: fname='stdc-predef.h'
remap_filename: fname='stdc-predef.h'
remap_filename: fname='foo/bar/baz.h'
remap_filename: new_dir='foo/'
remap_filename: new_dir='foo/bar/'
remap_filename: fname='sys/stat.h'
remap_filename: new_dir='../includesys/'
remap_filename: fname='sys/stat.h'
remap_filename: new_dir='../include-fixedsys/'
remap_filename: fname='sys/stat.h'
remap_filename: new_dir='/usr/local/includesys/'
remap_filename: fname='sys/stat.h'
remap_filename: new_dir='/usr/includesys/'
remap_filename: fname='features.h'
remap_filename: fname='features.h'
remap_filename: fname='features.h'
remap_filename: fname='features.h'
remap_filename: fname='sys/cdefs.h'
remap_filename: new_dir='../includesys/'
remap_filename: fname='sys/cdefs.h'
remap_filename: new_dir='../include-fixedsys/'
remap_filename: fname='sys/cdefs.h'

[Bug c++/71386] Wrong code on c++14 (GCC trunk)

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
ISTR a similar bug in C++ lambda support related how we map them to nested
functions.  PR69756.

[Bug tree-optimization/70032] tree-ssa-tail-merge engine replacement

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Yes, tail-merging needs to utilize a "value-numbering" like IPA ICF (in fact,
just re-use its implementation - I think this is what Martins patch set does).

My cleanup comment was supposed to be the first cleanup _after_ that patch-set
is merged.

[Bug c++/71658] User-defined conversion operator from a wrapper class to the wrapped type does not compile.

[ulrichmutze at gmx dot de]

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

--- Comment #2 from Ulrich Mutze  ---
Created attachment 38780
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38780=edit
This is a shortened version of the first attachment. It avoids a superfluous
complication.

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2015-10/msg02907.ht
   ||ml

--- Comment #12 from Richard Biener  ---
See patch at https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02907.html, yes I
think
even the latest variant regressed at least the tail-recursion testcase and I
didn't have time to review Josephs last comment and change the exceptions
accordingly.

That said, I believe the transform would be best done in the reassoc pass
but that has to be enhanced to handle types with non-wrapping overflow
characteristics first.

[Bug target/71680] New: [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra

[asolokha at gmx dot com]

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

Bug ID: 71680
   Summary: [7 Regression] ICE: Max. number of generated reload
insns per insn is achieved (90) w/ -Os -mlra
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ra
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-e500v2-linux-gnuspe

gcc-7.0.0-alpha20160626 snapshot fails to compile the following testcase w/ -Os
-mlra:

int om, iz, te;
long long int wm, j6;
short int nd;

void
o1 (void)
{
  short int *m9 = 
  int ty, kc = 2;
  long long int gi = 0;

  while (gi != 0)
{
  long long int *dk;
  int rl = 0;

 yn:
  if (j6 / kc != 0)
{
  *m9 = 2;
  while (*m9 != 0)
{
  m9 = 
  *m9 = 1;
}
  goto yn;
}
  m9 = 
  dk = (om != 0) ?  : 
  while (rl != 0)
while (te < 1)
  {
while (wm != 0)
  {
ty /= (kc & 1);
if (((j6 != 0) + ty) != 0)
  {
nd = rl;
if (nd != 0)
  gi = om = (wm != gi);
  }
while (j6 != 0)
  {
if (wm != 0 && *dk != 0)
  *dk = kc = 0;
wm |= (rl != 0) ? ty : (ty || 0);
++j6;
  }
iz = 2;
  }
rl /= gi;
++te;
  }
}
}

% powerpc-e500v2-linux-gnuspe-gcc-7.0.0-alpha20160626 -w -c -Os -mlra
en3q71xb.c 
en3q71xb.c: In function 'o1':
en3q71xb.c:55:1: internal compiler error: Max. number of generated reload insns
per insn is achieved (90)

[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
  Component|tree-optimization   |fortran

--- Comment #9 from Richard Biener  ---
Confirmed as fortran FE bug.  The FE manages to set ".r" as fn spec attribute
on save_cptr which specifies that its first argument does not escape.

It's trans-types.c:create_fn_spec that does this by doing

  for (f = gfc_sym_get_dummy_args (sym); f; f = f->next)
if (spec_len < sizeof (spec))
  {
if (!f->sym || f->sym->attr.pointer || f->sym->attr.target
|| f->sym->attr.external || f->sym->attr.cray_pointer
|| (f->sym->ts.type == BT_DERIVED
&& (f->sym->ts.u.derived->attr.proc_pointer_comp
|| f->sym->ts.u.derived->attr.pointer_comp))
|| (f->sym->ts.type == BT_CLASS
&& (CLASS_DATA (f->sym)->ts.u.derived->attr.proc_pointer_comp
|| CLASS_DATA (f->sym)->ts.u.derived->attr.pointer_comp)))
  spec[spec_len++] = '.';
else if (f->sym->attr.intent == INTENT_IN)
  spec[spec_len++] = 'r';
else if (f->sym)
  spec[spec_len++] = 'w';
  }

and it looks like the side-effect of marking arguments as not escaping as soon
as you specify anything else than . was overlooked.

Or Fortran really doesn't allow args to be stored away but has an exception for
C binding types which needs handling above.

[Bug ada/71674] missing overflow detection in Ada.Strings.Search

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-28
 CC||ebotcazou at gcc dot gnu.org
Summary|An exception is thrown on a |missing overflow detection
   |valid code  |in Ada.Strings.Search
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
Compiling a-strsea.adb with overflow checking enabled yields:

raised CONSTRAINT_ERROR : a-strsea.adb:102 overflow check failed

  if Mapping'Address = Maps.Identity'Address then
 while Ind <= Source'Last - PL1 loop
if Pattern = Source (Ind .. Ind + PL1) then
   Num := Num + 1;
   Ind := Ind + Pattern'Length;
else
   Ind := Ind + 1;  <=== 102
end if;
 end loop;

[Bug tree-optimization/71544] gfortran compiler optimization bug when dealing with c-style pointers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|WAITING |ASSIGNED
  Component|fortran |tree-optimization

--- Comment #8 from Richard Biener  ---
So it's "easy" to explain.  The initialization gets optimized away because
appearantly points-to analysis concludes that the allocated storage does
not escape:

a_3 = (10)
CALLUSED(12) = 
_4 = a_3
D.3422 = a_3
callarg(19) = 
callarg(19) = *callarg(19) + UNKNOWN
CALLUSED(17) = callarg(19)
derefaddrtmp(20) = 
*a_3 = derefaddrtmp(20)

-> ESCAPED, points-to non-local, points-to vars: { }

but this should have included HEAP(10).

Let me investigate.  It might be still a FE issue.