[Bug target/54589] struct offset add should be folded into address calculation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Fixed for GCC9 and later.

[Bug sanitizer/88289] [9 regression] r266664 causes asan to fail on many/most tests on BE

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Sat Dec  1 07:31:56 2018
New Revision: 266708

URL: https://gcc.gnu.org/viewcvs?rev=266708=gcc=rev
Log:
PR sanitizer/88289
* asan.c (asan_redzone_buffer::flush_redzone_payload): Fix up
an off-by-one for BYTES_BIG_ENDIAN.

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

[Bug target/54589] struct offset add should be folded into address calculation

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Sat Dec  1 07:27:58 2018
New Revision: 266707

URL: https://gcc.gnu.org/viewcvs?rev=266707=gcc=rev
Log:
PR target/54589
* combine.c (find_split_point): For invalid memory address
nonobj + obj + const, if reg + obj + const is valid addressing
mode, split at nonobj.  Use if rather than else if for the
fallback.  Comment fixes.

* gcc.target/i386/pr54589.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr54589.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug demangler/87675] Stack Overflow in function next_is_type_qual() in cp-demangle.c, as demonstrated by "nm -C"

[N1705695H at e dot ntu.edu.sg]

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

--- Comment #4 from N1705695H at e dot ntu.edu.sg ---
(In reply to Scott Gayou from comment #3)
> My last comment was a bit confusing. I can reproduce 2/3 on a standard
> system, and the other 1/3 requires dropping ulimit -s down a bit. (to 4096).

Hi，

I don't think you've made a clear analysis of the problem. This has nothing to
do with how much stack memory you set up. No matter how big your stack memory
is, it can still run out. The test case only give a small number of characters.
As you can imagine, you can still run out of memory by giving a lot of
characters.

In detail, the program requires the amount of resource such as time, memory,
power, etc. Memory exhaustion problems in the server can occur circumstantially
when programs are provided with inputs that exhibit worst-case behavior.
However, the high space complexity of the algorithm or poorly-designed programs
consume much more memory than necessary under well-conceived inputs. In
particular, stack memory is very limited. An attacker may use own function call
or multiple functions to call each other, exhausting stack memory. In other
words, no matter how large your stack memory is, it will always run out(by
given more "Z" or "U"). No matter how big you set it up, it's ultimately
limited. 

The problem itself is very difficult to fix. The problem is that C++ mangled
names have a recursive structure. Simple restriction cycles are not necessarily
good. Moreover, these examples give different stack frames. This is cause by
giving different string input. Some are call itself. Some are call different
function. In fact, it's hard to set recursive limits on every function.
Recursion limit would not fix all of these hence they are different root
cause(Loop calls involving six functions in a finite function stack frame).

[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp

[sandra at gcc dot gnu.org]

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

--- Comment #32 from sandra at gcc dot gnu.org ---
New patch posted for review here:

https://gcc.gnu.org/ml/gcc-patches/2018-12/msg4.html

spare parts & equipment for steel mill

[fullmart]

Dear Sir/Madam,

  

Glad to hear that you’re in loop of metallurgy business. We specialize in this 
field for years with strength of roll providing, hot-rolled steel section and 
cold rolling service of technical upgrading of metallurgical factory all over 
the world. 

 

As a excellent service provider for technical upgrading of metallurgical 
factory and metallurgical spare parts, Shanghai Full Mart Co., Ltd focus on 
good quality products and perfect services to satisfy your procurement 
requirements and guarantee your factory running smoothly. Please visit our 
website www.sfmsupply.com for more products information.

 

For best quote of your inquiry, please do not hesitate to contact us. 





--

Best regards,
Liwei Sun
Shanghai Full Mart Co.,Ltd   
Website: http://www.sfmsupply.com 
Email: fullm...@vip.163.com
Add: No.58, Wuhe Rd, Minhang District, Shanghai, China

[Bug fortran/88048] [8/9 Regression] ICE in check_data_variable, at fortran/resolve.c:15491

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #1)
> Invalid code nearby, down to at least gcc-5 :
> 
> 
> $ cat z4.f90
> subroutine s(x)
>integer, allocatable :: x(:)
>data x(1:2) /3, 4/
> end 

Unrelated bug.

[Bug fortran/88048] [8/9 Regression] ICE in check_data_variable, at fortran/resolve.c:15491

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> With invalid code  :
> 
> 
> $ cat z1.f90
> program p
>integer, parameter :: a(2) = 1
>data a(2) /a(1)/
>print *, a
> end
> 
> 
> $ gfortran-7 -g -O0 -Wall -Wextra -fcheck=all z1.f90
> $ a.out
>1   1
> 
> 
> $ gfortran-9-2018 -c z1.f90
> f951: internal compiler error: check_data_variable(): Bad expression

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 266386)
+++ gcc/fortran/resolve.c   (working copy)
@@ -15492,7 +15492,10 @@ check_data_variable (gfc_data_variable *var, locus *wh
 e = e->value.function.actual->expr;

   if (e->expr_type != EXPR_VARIABLE)
-gfc_internal_error ("check_data_variable(): Bad expression");
+{
+  gfc_error ("Expecting definable entity near %L", where);
+  return false;
+}

   sym = e->symtree->n.sym;

@@ -15500,6 +15503,7 @@ check_data_variable (gfc_data_variable *var, locus *wh
 {
   gfc_error ("BLOCK DATA element %qs at %L must be in COMMON",
 sym->name, >declared_at);
+  return false;
 }

   if (e->ref == NULL && sym->as)

[Bug fortran/88079] warn about procedure arguments without INTENT

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5
   Severity|normal  |enhancement

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Vivek Rao from comment #0)
> I think all new Fortran code should have the INTENT specified for the
> arguments of all procedures. I request that gfortran add a warning for code
> not doing this. If a warning is added, users who agree with my style
> recommendation can use a -Werror flag to force them to fix code without
> INTENTs for all arguments.
> 
> This is, of course, an enhancement request, not a bug report.

How does gfortran differential between new Fortran code and
old Fortran code.  It is the programmer's responsibility to 
know what he or she is doing.

[Bug fortran/88080] Add warning if IMPLICIT NONE is missing

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5
   Severity|normal  |enhancement

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Vivek Rao from comment #0)
> I think new Fortran code should have IMPLICIT NONE in every procedure or
> preferably at the beginning of a program or MODULE. I request that gfortran
> add an option that warns when this is not the case. Users who want IMPLICIT
> NONE in all code can convert such a warning to an error.
> 
> This is, of course, an enhancement request and not a bug report.

How does gfortran differentiate between new Fortran code and old
Fortran code?  I think it is the programmer's responsibility to
learn how to use the tools given to them to his/hers advantage.

[Bug fortran/88139] ICE in get_c_type_name, at fortran/dump-parse-tree.c:3047

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/dump-parse-tree.c
===
--- gcc/fortran/dump-parse-tree.c   (revision 266386)
+++ gcc/fortran/dump-parse-tree.c   (working copy)
@@ -3259,6 +3259,14 @@ write_proc (gfc_symbol *sym)
 {
   gfc_symbol *s;
   s = f->sym;
+
+  if (!s)
+   {
+ gfc_error_now ("At %L, \"Nous sommes tous nes pour le mal\"",
+>declared_at);
+ return;
+   }
+
   rok = get_c_type_name (&(s->ts), NULL, , _name, ,
 , false);
   if (rok == T_ERROR)

[Bug fortran/88205] ICE in gfc_wide_strncasecmp, at fortran/scanner.c:249

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c(revision 266386)
+++ gcc/fortran/io.c(working copy)
@@ -2161,6 +2161,12 @@ gfc_match_open (void)

   if (!open->file && open->status)
 {
+ if (open->status->ts.type != BT_CHARACTER)
+   {
+gfc_error ("STATUS must be a default character type at %C");
+goto cleanup;
+   }
+
  if (open->status->expr_type == EXPR_CONSTANT
 && gfc_wide_strncasecmp (open->status->value.character.string,
   "scratch", 7) != 0)

[Bug fortran/88206] [7/8/9 Regression] ICE in gfc_match_type_spec, at fortran/match.c:2229

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> Affects versions 7,8,9 :
> 
> 
> $ cat z1.f90
> program p
>integer, parameter :: z(4) = [1,2,3,4]
>integer :: k = 2
>print *, [real(z(k))]
> end
> 
> 
> $ gfortran-6 -c z1.f90
> $
> $ gfortran-9-20181125 -c z1.f90
> f951: internal compiler error: Segmentation fault
> 0xb2bcff crash_signal
> ../../gcc/toplev.c:326
> 0x64ba3f gfc_match_type_spec(gfc_typespec*)
> ../../gcc/fortran/match.c:2229

Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 266386)
+++ gcc/fortran/match.c (working copy)
@@ -2225,6 +2225,9 @@ found:
  return MATCH_NO;
}

+ if (e->expr_type != EXPR_CONSTANT)
+   goto ohno;
+
  gfc_next_char (); /* Burn the ')'. */
  ts->kind = (int) mpz_get_si (e->value.integer);
  if (gfc_validate_kind (ts->type, ts->kind , true) == -1)
@@ -2238,6 +2241,8 @@ found:
  return MATCH_YES;
}
 }
+
+ohno:

   /* If a type is not matched, simply return MATCH_NO.  */
   gfc_current_locus = old_locus;

[Bug fortran/88228] ICE in check_null, at fortran/expr.c:2691

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c  (revision 266386)
+++ gcc/fortran/expr.c  (working copy)
@@ -2688,6 +2688,9 @@ check_transformational (gfc_expr *e)
 static match
 check_null (gfc_expr *e)
 {
+  if (e->expr_type == EXPR_CONSTANT)
+   return MATCH_NO;
+
   if (strcmp ("null", e->symtree->n.sym->name) != 0)
 return MATCH_NO;

@@ -2793,10 +2796,15 @@ gfc_check_init_expr (gfc_expr *e)
&& (m = check_transformational (e)) == MATCH_NO
&& (m = check_elemental (e)) == MATCH_NO)
  {
-   gfc_error ("Intrinsic function %qs at %L is not permitted "
-  "in an initialization expression",
-  e->symtree->n.sym->name, >where);
-   m = MATCH_ERROR;
+   if (e->expr_type == EXPR_CONSTANT)
+ return true;
+   else
+ {
+   gfc_error ("Intrinsic function %qs at %L is not permitted "
+  "in an initialization expression",
+  e->symtree->n.sym->name, >where);
+   m = MATCH_ERROR;
+ }
  }

if (m == MATCH_ERROR)

[Bug testsuite/85368] [8 regression] phi-opt-11 test fails on IBM Z

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9 regression] phi-opt-11 |[8 regression] phi-opt-11
   |test fails on IBM Z |test fails on IBM Z

--- Comment #15 from Jakub Jelinek  ---
Hopefully fixed on the trunk now.

[Bug tree-optimization/88274] ICE in check, at tree-vrp.c:188

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 30 23:27:23 2018
New Revision: 266701

URL: https://gcc.gnu.org/viewcvs?rev=266701=gcc=rev
Log:
PR tree-optimization/88274
* tree-ssa-reassoc.c (optimize_range_tests_xor,
optimize_range_tests_diff): If type has smaller precision than
corresponding mode or if it has non-standard min/max, compute
everything in a standard type for the precision.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug testsuite/85368] [8/9 regression] phi-opt-11 test fails on IBM Z

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 30 23:26:41 2018
New Revision: 266700

URL: https://gcc.gnu.org/viewcvs?rev=266700=gcc=rev
Log:
PR testsuite/85368
* params.def (PARAM_LOGICAL_OP_NON_SHORT_CIRCUIT): New param.
* tree-ssa-ifcombine.c (ifcombine_ifandif): If
--param logical-op-non-short-circuit is present, override
LOGICAL_OP_NON_SHORT_CIRCUIT value from the param.
* fold-const.c (fold_range_test, fold_truth_andor): Likewise.

* lib/target-supports.exp (logical_op_short_circuit): Remove.
* gcc.dg/builtin-bswap-7.c: Remove logical_op_short_circuit
effective target, drop -mbranch-cost= options from the test and
instead pass --param logical-op-non-short-circuit=0 or
--param logical-op-non-short-circuit=1 depending on what the
tests meant to test.
* gcc.dg/pr21643.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-2.c: Likewise.
* gcc.dg/tree-ssa/phi-opt-11.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-1.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-4.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-3.c: Likewise.
* gcc.dg/tree-ssa/ssa-thread-14.c: Likewise.
* gcc.dg/tree-ssa/vrp47.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-11.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-16.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-14.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-5.c: Likewise.
* gcc.dg/tree-ssa/vrp87.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-6.c: Likewise.
* gcc.dg/tree-ssa/phi-opt-2.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-13.c: Likewise.
* gcc.dg/tree-ssa/ssa-thread-11.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-4.c: Likewise.
* gcc.dg/tree-ssa/forwprop-28.c: Likewise.
* gcc.dg/binop-xor1.c: Likewise.
* gcc.dg/pr46309.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-18.c: New test.
* gcc.dg/tree-ssa/reassoc-32.c: Add
--param logical-op-non-short-circuit=1 to dg-options.
* gcc.dg/tree-ssa/reassoc-33.c: Likewise.
* gcc.dg/tree-ssa/reassoc-34.c: Likewise.
* gcc.dg/tree-ssa/reassoc-35.c: Likewise.
* gcc.dg/tree-ssa/reassoc-36.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-18.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/params.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/binop-xor1.c
trunk/gcc/testsuite/gcc.dg/builtin-bswap-7.c
trunk/gcc/testsuite/gcc.dg/pr21643.c
trunk/gcc/testsuite/gcc.dg/pr46309.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-28.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-11.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-32.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-33.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-34.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-35.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-36.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-11.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-14.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-16.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-13.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-5.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-11.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-14.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp47.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp87.c
trunk/gcc/testsuite/lib/target-supports.exp
trunk/gcc/tree-ssa-ifcombine.c

[Bug fortran/88249] ICE in gfc_resolve_filepos, at fortran/io.c:2853

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
Better.

Index: gcc/fortran/gfortran.h
===
--- gcc/fortran/gfortran.h  (revision 266386)
+++ gcc/fortran/gfortran.h  (working copy)
@@ -3374,7 +3374,7 @@ bool gfc_resolve_open (gfc_open *);
 void gfc_free_close (gfc_close *);
 bool gfc_resolve_close (gfc_close *);
 void gfc_free_filepos (gfc_filepos *);
-bool gfc_resolve_filepos (gfc_filepos *);
+bool gfc_resolve_filepos (gfc_filepos *, locus *);
 void gfc_free_inquire (gfc_inquire *);
 bool gfc_resolve_inquire (gfc_inquire *);
 void gfc_free_dt (gfc_dt *);
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 266386)
+++ gcc/fortran/resolve.c   (working copy)
@@ -11544,7 +11544,7 @@ start:
case EXEC_ENDFILE:
case EXEC_REWIND:
case EXEC_FLUSH:
- if (!gfc_resolve_filepos (code->ext.filepos))
+ if (!gfc_resolve_filepos (code->ext.filepos, >loc))
break;

  resolve_branch (code->ext.filepos->err, code);
Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c(revision 266386)
+++ gcc/fortran/io.c(working copy)
@@ -2834,22 +2834,21 @@ cleanup:


 bool
-gfc_resolve_filepos (gfc_filepos *fp)
+gfc_resolve_filepos (gfc_filepos *fp, locus *where)
 {
   RESOLVE_TAG (_unit, fp->unit);
   RESOLVE_TAG (_iostat, fp->iostat);
   RESOLVE_TAG (_iomsg, fp->iomsg);
-  if (!gfc_reference_st_label (fp->err, ST_LABEL_TARGET))
-return false;

-  if (!fp->unit && (fp->iostat || fp->iomsg))
+  if (!fp->unit && (fp->iostat || fp->iomsg || fp->err))
 {
-  locus where;
-  where = fp->iostat ? fp->iostat->where : fp->iomsg->where;
-  gfc_error ("UNIT number missing in statement at %L", );
+  gfc_error ("UNIT number missing in statement at %L", where);
   return false;
 }

+  if (!gfc_reference_st_label (fp->err, ST_LABEL_TARGET))
+return false;
+
   if (fp->unit->expr_type == EXPR_CONSTANT
   && fp->unit->ts.type == BT_INTEGER
   && mpz_sgn (fp->unit->value.integer) < 0)

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[law at redhat dot com]

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

Bug 79768 Summary: `-Wmaybe-uninitialized' false positive with optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79768

   What|Removed |Added

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

[Bug middle-end/79768] `-Wmaybe-uninitialized' false positive with optimisation

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #10 from Jeffrey A. Law  ---
Per c#9.

[Bug rtl-optimization/88179] [9 regression][MIPS] pr84941.c ICE in lra_eliminate_reg_if_possible at lra-eliminations.c:1393 start with r266385

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #3 from Jeffrey A. Law  ---
Fixed by Vlad's patch on the trunk.

[Bug middle-end/64242] Longjmp expansion incorrect

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #6 from Jeffrey A. Law  ---
Fixed on trunk by Wilco's patch.

[Bug middle-end/64242] Longjmp expansion incorrect

[law at gcc dot gnu.org]

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

--- Comment #5 from Jeffrey A. Law  ---
Author: law
Date: Fri Nov 30 23:06:51 2018
New Revision: 266697

URL: https://gcc.gnu.org/viewcvs?rev=266697=gcc=rev
Log:
PR middle-end/64242
* builtins.c (expand_builtin_longjmp): Use a temporary when restoring
the frame pointer.
(expand_builtin_nonlocal_goto): Likewise.

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

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr64242.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/88289] [9 regression] r266664 causes asan to fail on many/most tests on BE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-30
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug sanitizer/88289] [9 regression] r266664 causes asan to fail on many/most tests on BE

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
E.g. on x86_64 in user-after-scope-5.c I see:
.string "1 48 40 9 values:10"
Partition 0: size 40 align 16
values
Flushing rzbuffer at offset -128 with: f1 f1 f1 f1
Flushing rzbuffer at offset -96 with: f1 f1 00 00
Flushing rzbuffer at offset -64 with: 00 00 00 f3
Flushing rzbuffer at offset -32 with: f3 f3 f3 f3
(wonder why the var is at offset 48 bytes rather than just 32 bytes).\

But on powerpc64 I see:
.string "1 48 40 9 values:10"
Partition 0: size 40 align 8
values
Flushing rzbuffer at offset -128 with: 00 f1 f1 f1
Flushing rzbuffer at offset -96 with: 00 00 00 f1
Flushing rzbuffer at offset -64 with: 00 f3 00 00
Flushing rzbuffer at offset -32 with: 00 f3 f3 f3

There is a clear off-by-one for BIG_ENDIAN, with following patch I get:

--- gcc/asan.c.jj   2018-11-30 19:59:59.675789930 +0100
+++ gcc/asan.c  2018-11-30 23:19:55.336780260 +0100
@@ -1326,7 +1326,7 @@ asan_redzone_buffer::flush_redzone_paylo
   for (unsigned i = 0; i < RZ_BUFFER_SIZE; i++)
 {
   unsigned char v
-   = m_shadow_bytes[BYTES_BIG_ENDIAN ? RZ_BUFFER_SIZE - i : i];
+   = m_shadow_bytes[BYTES_BIG_ENDIAN ? RZ_BUFFER_SIZE - i - 1 : i];
   val |= (unsigned HOST_WIDE_INT)v << (BITS_PER_UNIT * i);
   if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "%02x ", v);

Partition 0: size 40 align 8
values
Flushing rzbuffer at offset -128 with: f1 f1 f1 f1
Flushing rzbuffer at offset -96 with: 00 00 f1 f1
Flushing rzbuffer at offset -64 with: f3 00 00 00
Flushing rzbuffer at offset -32 with: f3 f3 f3 f3
Unpoisoning shadow stack for variable: values (40 B)

instead, which looks correct.

[Bug fortran/88249] ICE in gfc_resolve_filepos, at fortran/io.c:2853

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-30
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> With a missing file-unit-number, down to at least gcc-5 :
> 
> 
> $ cat z1.f90
> program p
>backspace (err=1)
>endfile (err=1)
>flush (err=1)
>rewind (err=1)
> end
> 
> 
> $ gfortran-9-20181125 -c z1.f90
> f951: internal compiler error: Segmentation fault
> 0xb2bcff crash_signal
> ../../gcc/toplev.c:326
> 0x63f696 gfc_resolve_filepos(gfc_filepos*)
> ../../gcc/fortran/io.c:2853
> 0x6850ab gfc_resolve_code(gfc_code*, gfc_namespace*)
> ../../gcc/fortran/resolve.c:11547
> 0x68702f resolve_codes


Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 266386)
+++ gcc/fortran/resolve.c   (working copy)
@@ -11544,7 +11544,7 @@ start:
case EXEC_ENDFILE:
case EXEC_REWIND:
case EXEC_FLUSH:
- if (!gfc_resolve_filepos (code->ext.filepos))
+ if (!gfc_resolve_filepos (code->ext.filepos, >loc))
break;

  resolve_branch (code->ext.filepos->err, code);
Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c(revision 266386)
+++ gcc/fortran/io.c(working copy)
@@ -2834,22 +2834,21 @@ cleanup:


 bool
-gfc_resolve_filepos (gfc_filepos *fp)
+gfc_resolve_filepos (gfc_filepos *fp, locus *where)
 {
   RESOLVE_TAG (_unit, fp->unit);
   RESOLVE_TAG (_iostat, fp->iostat);
   RESOLVE_TAG (_iomsg, fp->iomsg);
-  if (!gfc_reference_st_label (fp->err, ST_LABEL_TARGET))
-return false;

-  if (!fp->unit && (fp->iostat || fp->iomsg))
+  if (!fp->unit && (fp->iostat || fp->iomsg || fp->err))
 {
-  locus where;
-  where = fp->iostat ? fp->iostat->where : fp->iomsg->where;
-  gfc_error ("UNIT number missing in statement at %L", );
+  gfc_error ("UNIT number missing in statement at %L", where);
   return false;
 }

+  if (!gfc_reference_st_label (fp->err, ST_LABEL_TARGET))
+return false;
+
   if (fp->unit->expr_type == EXPR_CONSTANT
   && fp->unit->ts.type == BT_INTEGER
   && mpz_sgn (fp->unit->value.integer) < 0)

[Bug testsuite/88290] New: [9 regression] 23_containers/deque/erasure.cc fails after r266672

[seurer at gcc dot gnu.org]

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

Bug ID: 88290
   Summary: [9 regression] 23_containers/deque/erasure.cc fails
after r266672
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/./gcc/xg++ -shared-libgcc
-B/home/seurer/gcc/build/gcc-test/./gcc -nostdinc++
-L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/ -isystem
/home/seurer/gcc/install/gcc-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
-B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/util
/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/23_containers/deque/erasure.cc
-std=gnu++2a -fno-diagnostics-show-caret -fdiagnostics-color=never
./libtestc++.a -Wl,--gc-sections
-L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/filesystem/.libs
-lm -o ./erasure.exe
/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/23_containers/deque/erasure.cc:
In function 'void test01()':
/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/23_containers/deque/erasure.cc:30:
error: 'void num' has incomplete type
/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/23_containers/deque/erasure.cc:
In function 'void test02()':
/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/23_containers/deque/erasure.cc:40:
error: 'void num' has incomplete type
compiler exited with status 1
FAIL: 23_containers/deque/erasure.cc (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/23_containers/deque/erasure.cc:30:
error: 'void num' has incomplete type
/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/23_containers/deque/erasure.cc:40:
error: 'void num' has incomplete type

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  ---
This could also be a gold linker issue too.

But then again this is not the right place to report a gold or glibc issue. 
Try https://sourceware.org/bugzilla/ instead.

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||aarch64-*-linux-gnu
 CC||pinskia at gcc dot gnu.org

--- Comment #9 from Andrew Pinski  ---
(In reply to jos...@codesourcery.com from comment #8)
> On Fri, 30 Nov 2018, stephen.kim at oracle dot com wrote:
> 
> > The glibc commit that triggered this bug is:
> >  bfff8b1becd7d01c074177df7196ab327cd8c844 
> 
> That's the copyright date updates for 2017.

I was going to say that too.
Maybe:
https://sourceware.org/git/?p=glibc.git;a=commit;h=14d886edbd3d80b771e1c42fbd9217f9074de9c6

[Bug fortran/88269] ICE in gfc_format_decoder, at fortran/error.c:947

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-30
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> With invalid code, down to at least gcc-5 :
> 
> 
> $ cat z1.f90
> program p
>write (end=1e1)
>write (end=1d1)
>write (end=1q1)
> end
> 
> 
> $ gfortran-9-20181125 -c z1.f90
> 0x619a5e gfc_format_decoder
> ../../gcc/fortran/error.c:947
> 0x131c83e pp_format(pretty_printer*, text_info*)
> ../../gcc/pretty-print.c:1390
> 0x13121e5 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
> ../../gcc/diagnostic.c:1015
> 0x6198fc gfc_error_opt
> ../../gcc/fortran/error.c:1313
> 0x61aea0 gfc_error(char const*, ...)
> ../../gcc/fortran/error.c:1342
> 0x63c9b2 check_io_constraints
> ../../gcc/fortran/io.c:3755


Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c(revision 266386)
+++ gcc/fortran/io.c(working copy)
@@ -3681,7 +3681,10 @@ check_io_constraints (io_kind k, gfc_dt *dt, gfc_code 
 #define io_constraint(condition,msg,arg)\
 if (condition) \
   {\
-gfc_error(msg,arg);\
+if ((arg)->lb != NULL) \
+  gfc_error(msg,arg);\
+else \
+  gfc_error(msg,_current_locus);\
 m = MATCH_ERROR;\
   }

@@ -3741,11 +3744,14 @@ if (condition) \
   if (expr && expr->ts.type != BT_CHARACTER)
 {

-  io_constraint (gfc_pure (NULL) && (k == M_READ || k == M_WRITE),
-"IO UNIT in %s statement at %C must be "
+  if (gfc_pure (NULL) && (k == M_READ || k == M_WRITE))
+   {
+ gfc_error ("IO UNIT in %s statement at %C must be "
 "an internal file in a PURE procedure",
 io_kind_name (k));
-
+ return MATCH_ERROR;
+   }
+ 
   if (k == M_READ || k == M_WRITE)
gfc_unset_implicit_pure (NULL);
 }

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com  ---
On Fri, 30 Nov 2018, stephen.kim at oracle dot com wrote:

> The glibc commit that triggered this bug is:
>  bfff8b1becd7d01c074177df7196ab327cd8c844 

That's the copyright date updates for 2017.

[Bug libgomp/88288] [OpenACC, libgomp] Adjust offsets for present data clauses

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-30
 Ever confirmed|0   |1

--- Comment #3 from Thomas Schwinge  ---
(In reply to cesar from comment #2)
> Why not update goacc_parallel_keyed to use gomp_map_val instead computing
> devaddrs manually? That would help reduce the number of duplicate mystery
> formulas in libgomp.

Right, that's something to look into (as I had just earlier mentioned in email,
too), but for now, the objective has been to actually get the bug fix
committed, using the patch that you had written in 2016 (when "gomp_map_val"
already existed, by the way).

[Bug libgomp/88288] [OpenACC, libgomp] Adjust offsets for present data clauses

[cesar at gcc dot gnu.org]

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

--- Comment #2 from cesar at gcc dot gnu.org ---
Why not update goacc_parallel_keyed to use gomp_map_val instead computing
devaddrs manually? That would help reduce the number of duplicate mystery
formulas in libgomp.

[Bug debug/85550] [7/8/9 Regression] -fdebug-types-section broken with DW_OP_addr in DW_AT_location

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Dup.

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

[Bug debug/87462] [7/8 Regression] undefined reference error occurs when -g, -fdebug-types-section and -O2 are used at the same time

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
*** Bug 85550 has been marked as a duplicate of this bug. ***

[Bug debug/85550] [7/8/9 Regression] -fdebug-types-section broken with DW_OP_addr in DW_AT_location

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 30 20:55:41 2018
New Revision: 266689

URL: https://gcc.gnu.org/viewcvs?rev=266689=gcc=rev
Log:
PR debug/85550
* g++.dg/debug/dwarf2/pr85550.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr85550.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c/87924] OpenACC wait clauses without async-arguments

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Nov 30 20:39:30 2018
New Revision: 266686

URL: https://gcc.gnu.org/viewcvs?rev=266686=gcc=rev
Log:
[PR87924] Add (XFAILed) test cases for OpenACC wait clauses without
async-arguments

gcc/testsuite/
PR c/87924
* c-c++-common/goacc/asyncwait-5.c: Update.
* gfortran.dg/goacc/asyncwait-5.f: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/asyncwait-5.c
trunk/gcc/testsuite/gfortran.dg/goacc/asyncwait-5.f

[Bug libgomp/88288] [OpenACC, libgomp] Adjust offsets for present data clauses

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Nov 30 20:39:49 2018
New Revision: 266688

URL: https://gcc.gnu.org/viewcvs?rev=266688=gcc=rev
Log:
[PR88288, OpenACC, libgomp] Adjust offsets for present data clauses

Make libgomp respect the on device offset of subarrays which may arise in
present data clauses.

libgomp/
PR libgomp/88288
* oacc-parallel.c (GOACC_parallel_keyed): Add offset to devaddrs.
* testsuite/libgomp.oacc-c-c++-common/pr88288.c: New test.

Reviewed-by: Thomas Schwinge 

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr88288.c
Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/oacc-parallel.c

[Bug sanitizer/88289] New: [9 regression] r266664 causes asan to fail on many/most tests on BE

[seurer at gcc dot gnu.org]

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

Bug ID: 88289
   Summary: [9 regression] r24 causes asan to fail on
many/most tests on BE
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

This appears to only cause it to fail on BE.

FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_AllocDeallocMismatch
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_AtoiAndFriendsOOBTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2 
AddressSanitizer_AttributeNoSanitizeAddressTest execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_BitFieldNegativeTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_BitFieldPositiveTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2 
AddressSanitizer_BufferOverflowAfterManyFrees execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_CallocReturnsZeroMem
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_CxxExceptionTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2 
AddressSanitizer_FileNameInGlobalReportTest execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_GlobalStringConstTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_GlobalTest execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeOOBInMemset
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeOOBRightTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LargeStructCopyTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LongDoubleNegativeTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_LongJmpTest execution
test
FAIL: g++.dg/asan/asan_test.C   -O2  AddressSanitizer_MallocUsableSizeTest
execution test
FAIL: g++.dg/asan/asan_test.C   -O2  

[Bug rtl-optimization/88179] [9 regression][MIPS] pr84941.c ICE in lra_eliminate_reg_if_possible at lra-eliminations.c:1393 start with r266385

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Nov 30 20:15:56 2018
New Revision: 266682

URL: https://gcc.gnu.org/viewcvs?rev=266682=gcc=rev
Log:
2018-11-30  Vladimir Makarov  

PR rtl-optimization/88179
* lra-constraints.c (address_eliminator::address_eliminator):
Don't eleminate regs in illegitimate address.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c

[Bug target/85220] [meta-bug, nvptx] Run trunk with og7 openacc testcases and analyze execution failures

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openacc

--- Comment #5 from Thomas Schwinge  ---
(In reply to Tom de Vries from comment #1)
> FAIL: data_offset.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0 
> execution test
> FAIL: data_offset.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2 
> execution test

Filed PR88288.

[Bug sanitizer/88277] ASAN stack poisoning is using unaligned stores on e.g. x86_64

[andi-gcc at firstfloor dot org]

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

Andi Kleen  changed:

   What|Removed |Added

 CC||andi-gcc at firstfloor dot org

--- Comment #2 from Andi Kleen  ---
FWIW modern x86 CPUs are fairly good at unaligned accesses, so it might not be
worth it for performance.

[Bug libgomp/88288] New: [OpenACC, libgomp] Adjust offsets for present data clauses

[tschwinge at gcc dot gnu.org]

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

Bug ID: 88288
   Summary: [OpenACC, libgomp] Adjust offsets for present data
clauses
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc, patch
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: tschwinge at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: cesar at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

As reported in ,
libgomp "is not respecting the on device offset of subarrays which may arise in
present data clauses", "causing SPEC_ACCEL 304.olbm to generate bogus results",
for example.

This will likely need to be fixed on all active release branches.

[Bug target/88287] [9 Regression] aarch64/sve/vcond_1.C fails since r266620

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
BTW, it is unclear to me how to reproduce it, I've tried
./cc1plus -quiet -O -msve-vector-bits=256 vcond_1.C -o vcond_1.s -nostdinc
-march=armv8.4-a+simd
with the match.pd changes reverted and the same without the reversion and the
generated assembly is identical.

[Bug target/88287] [9 Regression] aarch64/sve/vcond_1.C fails since r266620

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
FAILs just because it has too much scan-assembler in it and expects something
in particular, or do we generate worse code?
The patch certainly added some canonicalization that was previously done only
for scalar comparisons.

[Bug target/88287] New: [9 Regression] aarch64/sve/vcond_1.C fails since r266620

[clyon at gcc dot gnu.org]

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

Bug ID: 88287
   Summary: [9 Regression] aarch64/sve/vcond_1.C fails since
r266620
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Since r266620, I have noticed that g++.target/aarch64/sve/vcond_1.C now fails.

[Bug tree-optimization/88285] [9 Regression] gcc.dg/predict-22.c fails on arm

[clyon at gcc dot gnu.org]

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

--- Comment #1 from Christophe Lyon  ---
However, this same commit also introduced a regression:
FAIL: gcc.c-torture/execute/20040709-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test

with gcc configured
--target arm-none-linux-gnueabihf
--with-mode arm
--with-cpu cortex-a9
--with-fpu neon-fp16

[Bug target/88282] ICE in df_install_refs at gcc/df-scan.c:2379

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov  ---
(In reply to Tamar Christina from comment #3)
> This is caused by the change in r266385 for PR87718.
> 
> That causes the cost model to go completely off the rail and also changes
> the register classes.
> 

  Sorry for this. It was a very sensitive code change and I think it will take
some time until the code stabilize.  But I believe that what patch for PR87718
solves is the right direction for RA.

> Previously out costs were 0 in most cases, now we have large numbers like
> 65540004.
> 
> ```

  I'll investigate this too. The biggest problem with RA cost calculations is
that machine-dependent code for register move cost is not defined correctly for
all combinations of mode, regclass, regclass.  Unfortunately, the documentation
says nothing about it.  RA tries to solve this in some ways but not always
successfully. 

  In the current case the combination is DImode, SP_REG, GENERAL_REGS.

  I'll see what can I do in RA.  I have an idea. If it works the patch will be
ready on the next week.

[Bug target/87496] ICE in aggregate_value_p at gcc/function.c:2046

[bergner at gcc dot gnu.org]

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

--- Comment #8 from Peter Bergner  ---
Author: bergner
Date: Fri Nov 30 18:57:33 2018
New Revision: 266680

URL: https://gcc.gnu.org/viewcvs?rev=266680=gcc=rev
Log:
gcc/testsuite/
PR target/87496
* gcc.target/powerpc/pr86324-1.c: Add dg-skip-if selector.
Add -mcpu=power7 option.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/pr86324-1.c

[Bug fortran/88286] gfortran reports conflicting intent(in) with an intent(in) declared class variable

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-30
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from at least 4.8 up to trunk (9.0).

Workaroud: use

CLASS(BT), INTENT(IN) ::b

[Bug rtl-optimization/87246] [7/8/9 Regression] ICE in decompose_normal_address, at rtlanal.c:6379

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
And that hook indeed returns the need for secondary reload there, so looks like
LRA bug for not honoring it?

[Bug fortran/88286] New: gfortran reports conflicting intent(in) with an intent(in) declared class variable

[aluaces at udc dot es]

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

Bug ID: 88286
   Summary: gfortran reports conflicting intent(in) with an
intent(in) declared class variable
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aluaces at udc dot es
  Target Milestone: ---

I get the error

test_bug.f90:19:16:

 INTENT(IN) b
1
Error: INTENT (IN) conflicts with INTENT(IN) at (1)

with the attached minimal working example.  The error is issued at the last
function, but it is not triggered if I remove either the first or the second.

If the parameter "b" is not a CLASS reference but a base type, the test passes
as well, so I think it has to be something regarding polymorphic types.

MODULE MOD_BUG
  IMPLICIT NONE

  TYPE BT
 INTEGER I
  END TYPE BT

CONTAINS

  FUNCTION si_p_loc(b)
CLASS(BT)::b
LOGICAL si_p_loc
INTENT(IN) b
  END FUNCTION si_p_loc

  FUNCTION si_v_loc(b)
CLASS(BT)::b
LOGICAL si_v_loc
INTENT(IN) b
  END FUNCTION si_v_loc

END MODULE MOD_BUG

[Bug testsuite/85368] [8/9 regression] phi-opt-11 test fails on IBM Z

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #45129|0   |1
is obsolete||

--- Comment #13 from Jakub Jelinek  ---
Created attachment 45132
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45132=edit
gcc9-pr85368.patch

Updated patch with those reassoc-3[23456].c tests adjusted.

[Bug fortran/88137] BACKTRACE seems to have a memory leak

[jb at gcc dot gnu.org]

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

--- Comment #5 from Janne Blomqvist  ---
Author: jb
Date: Fri Nov 30 16:46:55 2018
New Revision: 266678

URL: https://gcc.gnu.org/viewcvs?rev=266678=gcc=rev
Log:
Initialize backtrace state once

From backtrace.h for backtrace_create_state:

   Calling this function allocates resources that can not be freed.
   There is no backtrace_free_state function.  The state is used to
   cache information that is expensive to recompute.  Programs are
   expected to call this function at most once and to save the return
   value for all later calls to backtrace functions.

So instead of calling backtrace_create_state every time we wish to
show a backtrace, do it once and store the result in a static
variable.  libbacktrace allows multiple threads to access the state,
so no need to use TLS.

Regtested on x86_64-pc-linux-gnu.

Backport from trunk.

libgfortran/ChangeLog:

2018-11-30  Janne Blomqvist  

PR libfortran/88137
* runtime/backtrace.c (show_backtrace): Make lbstate a static
variable, initialize once.

Modified:
branches/gcc-8-branch/libgfortran/ChangeLog
branches/gcc-8-branch/libgfortran/runtime/backtrace.c

[Bug rtl-optimization/87718] [9 Regression] FAIL: gcc.target/i386/avx512dq-concatv2si-1.c

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #9 from Tamar Christina  ---
This change has quite a negative effect on the cost model in AArch64 an ICE due
to the new costs and register classes it picks.

See PR88282

Thanks,
Tamar

[Bug fortran/88137] BACKTRACE seems to have a memory leak

[jb at gcc dot gnu.org]

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

--- Comment #4 from Janne Blomqvist  ---
Author: jb
Date: Fri Nov 30 16:44:27 2018
New Revision: 266677

URL: https://gcc.gnu.org/viewcvs?rev=266677=gcc=rev
Log:
Initialize backtrace state once

From backtrace.h for backtrace_create_state:

   Calling this function allocates resources that can not be freed.
   There is no backtrace_free_state function.  The state is used to
   cache information that is expensive to recompute.  Programs are
   expected to call this function at most once and to save the return
   value for all later calls to backtrace functions.

So instead of calling backtrace_create_state every time we wish to
show a backtrace, do it once and store the result in a static
variable.  libbacktrace allows multiple threads to access the state,
so no need to use TLS.

Regtested on x86_64-pc-linux-gnu.

libgfortran/ChangeLog:

2018-11-30  Janne Blomqvist  

PR libfortran/88137
* runtime/backtrace.c (show_backtrace): Make lbstate a static
variable, initialize once.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/runtime/backtrace.c

[Bug target/88282] ICE in df_install_refs at gcc/df-scan.c:2379

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #3 from Tamar Christina  ---
This is caused by the change in r266385 for PR87718.

That causes the cost model to go completely off the rail and also changes the
register classes.

Previously out costs were 0 in most cases, now we have large numbers like
65540004.

```
  r93 costs: GENERAL_REGS:0 FP_LO_REGS:1 FP_REGS:1
POINTER_AND_FP_REGS:1 MEM:8000
  r92 costs: GENERAL_REGS:0 FP_LO_REGS:1 FP_REGS:1
POINTER_AND_FP_REGS:1 MEM:8000
```

was before and now

```
  r93 costs: GENERAL_REGS:65540004 FP_LO_REGS:65544004 FP_REGS:65544004
POINTER_AND_FP_REGS:65544004 MEM:8000
  r92 costs: TAILCALL_ADDR_REGS:131074004 GENERAL_REGS:131074004
FP_LO_REGS:131074004 FP_REGS:131074004 POINTER_AND_FP_REGS:131074004 MEM:8000
```

The reason this crashes with stack clash enabled is because the alloca code
emits a probe at SP.

The costing now makes it think it has to spill the hard register

  Creating newreg=98 from oldreg=92, assigning class GENERAL_REGS to r98
   16: sp:DI=r98:DI
  REG_DEAD r92:DI
  REG_ARGS_SIZE 0
Inserting insn reload before:
   27: r98:DI=r92:DI


 it can't do it so it crashes in reload.

[Bug testsuite/85368] [8/9 regression] phi-opt-11 test fails on IBM Z

[clyon at gcc dot gnu.org]

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

--- Comment #12 from Christophe Lyon  ---
Hi Jakub, thanks for doing this.
I tested on many combination of arm* targets, and it was OK except for some of
them:
--target arm-none-eabi
--with-mode thumb
--with-cpu cortex-m3
--with-fpu default

--target arm-none-linux-gnueabihf
--with-mode thumb
--with-cpu cortex-a5
--with-fpu vfpv3-d16-fp16

Executed from: gcc.dg/tree-ssa/tree-ssa.exp
FAIL:gcc.dg/tree-ssa/reassoc-33.c scan-tree-dump-times reassoc1 "Optimizing
range tests" 3
FAIL:gcc.dg/tree-ssa/reassoc-34.c scan-tree-dump-times reassoc1 "Optimizing
range tests" 1
FAIL:gcc.dg/tree-ssa/reassoc-35.c scan-tree-dump-times reassoc1 "Optimizing
range tests" 1
FAIL:gcc.dg/tree-ssa/reassoc-36.c scan-tree-dump-times reassoc1 "Optimizing
range tests" 1

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

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

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #7 from Andreas Schwab  ---
If you think you have found a bug in glibc, then this is not the right place to
report it.

[Bug tree-optimization/88285] New: [9 Regression] gcc.dg/predict-22.c fails on arm

[clyon at gcc dot gnu.org]

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

Bug ID: 88285
   Summary: [9 Regression] gcc.dg/predict-22.c fails on arm
   Product: gcc
   Version: 6.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

It's not really a regression, but a new failure since this test was added
(r266587).

On arm targets, I'm seeing:
cc1: note: -freorder-blocks-and-partition not supported on this architecture
PASS: gcc.dg/predict-22.c (test for excess errors)
PASS: gcc.dg/predict-22.c scan-tree-dump-times optimized "Invalid sum" 0
PASS: gcc.dg/predict-22.c scan-tree-dump-times optimized "count 0," 1
gcc.dg/predict-22.c: dump file does not exist
UNRESOLVED: gcc.dg/predict-22.c scan-rtl-dump-times bbpart "COLD_PARTITION" 1

[Bug target/88278] Fails to elide zeroing of upper vector register

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On November 30, 2018 4:28:54 PM GMT+01:00, "jakub at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88278
>
>--- Comment #6 from Jakub Jelinek  ---
>I wonder about something like:
>--- gcc/config/i386/sse.md.jj   2018-11-29 23:16:06.481301632 +0100
>+++ gcc/config/i386/sse.md  2018-11-30 16:21:21.480379008 +0100
>@@ -7248,6 +7248,17 @@
>(set_attr "prefix" "orig,maybe_evex,orig,maybe_evex")
>(set_attr "mode" "V4SF,V4SF,V2SF,V2SF")])
>
>+(define_insn "*vec_concatv4sf_0"
>+  [(set (match_operand:V4SF 0 "register_operand"   "=v")
>+   (vec_concat:V4SF
>+ (match_operand:V2SF 1 "nonimmediate_operand" "xm")
>+ (match_operand:V2SF 2 "const0_operand"   " C")))]
>+  "TARGET_SSE2"
>+  "%vmovq\t{%1, %0|%0, %1}"
>+  [(set_attr "type" "ssemov")
>+   (set_attr "prefix" "maybe_vex")
>+   (set_attr "mode" "DF")])
>+
>;; Avoid combining registers from different units in a single
>alternative,
> ;; see comment above inline_secondary_memory_needed function in i386.c
> (define_insn "vec_set_0"
>@@ -14409,6 +14420,23 @@
>(set_attr "prefix" "orig,maybe_evex,orig,orig,maybe_evex")
>(set_attr "mode" "TI,TI,V4SF,V2SF,V2SF")])
>
>+(define_insn "*vec_concatv4si_0"
>+  [(set (match_operand:V4SI 0 "register_operand"   "=v,x")
>+   (vec_concat:V4SI
>+ (match_operand:V2SI 1 "nonimmediate_operand" "vm,?!*y")
>+ (match_operand:V2SI 2 "const0_operand"   " C,C")))]
>+  "TARGET_SSE2"
>+  "@
>+   %vmovq\t{%1, %0|%0, %1}
>+   movq2dq\t{%1, %0|%0, %1}"
>+  [(set_attr "type" "ssemov")
>+   (set_attr "prefix" "maybe_vex,orig")
>+   (set_attr "mode" "TI")
>+   (set (attr "preferred_for_speed")
>+ (if_then_else (eq_attr "alternative" "1")
>+   (symbol_ref "TARGET_INTER_UNIT_MOVES_FROM_VEC")
>+   (symbol_ref "true")))])
>+
> ;; movd instead of movq is required to handle broken assemblers.
> (define_insn "vec_concatv2di"
>   [(set (match_operand:V2DI 0 "register_operand"
>
>but the #c0 testcases don't compile for me with -O2 -msse2 -fgimple
>(nor
>-mavx), so I can't easily verify.

I have committed the prerequisite for that now. 

>I don't see how we could get rid of those for the v <- v,C cases,
>unless we
>analyze whatever instruction generated it and prove that it leaves all
>the
>higher bits set to zero.  E.g. one could have a v4si to v2si downcast
>(just
>picking the lowpart subreg) followed by concatenating it with zero, and
>if we
>blindly drop the movq instruction, the upper bits might be non-zero.

Yeah, I'm looking for a way to do low part loads from memory with zeroing the
rest.

[Bug preprocessor/88257] [9 Regression] ICE in linemap_position_for_line_and_column, at libcpp/line-map.c:842

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #7 from David Malcolm  ---
Should be fixed by r266671.

[Bug tree-optimization/88044] [9 regression] gfortran.dg/transfer_intrinsic_3.f90 hangs after r266171

[seurer at gcc dot gnu.org]

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

--- Comment #4 from seurer at gcc dot gnu.org ---
Any progress on this?  It really slows down test runs as it hangs twice and has
to wait for the timeout to occur to continue.

[Bug c++/87897] [9 Regression] ICE in maybe_constant_value, at cp/constexpr.c:5255 since r265788

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Slightly cleaned up testcase:
typedef struct A {} B;
A const a = B ();

The problem is that we have a TARGET_EXPR with B type and an empty CONSTRUCTOR
with B type, then cxx_eval_outermost_constant_expr is processing it,
5111  if (TREE_CODE (r) == CONSTRUCTOR && CLASS_TYPE_P (TREE_TYPE (r)))
5112{
5113  r = adjust_temp_type (type, r);
5114  if (TREE_CODE (t) == TARGET_EXPR
5115  && TARGET_EXPR_INITIAL (t) == r)
5116return t;
5117  else if (TREE_CODE (t) != CONSTRUCTOR)
5118{
5119  r = get_target_expr (r);
5120  TREE_CONSTANT (r) = true;
5121}
and then in the caller
5259  r = cxx_eval_outermost_constant_expr (t, true, true, false, decl);
5260  gcc_checking_assert (r == t
5261   || CONVERT_EXPR_P (t)
5262   || TREE_CODE (t) == VIEW_CONVERT_EXPR
5263   || (TREE_CONSTANT (t) && !TREE_CONSTANT (r))
5264   || !cp_tree_equal (r, t));

For A const a = A (); adjust_temp_type returns the passed r and thus r == t in
the caller, but for A const a = B (); adjust_temp_type creates a new
CONSTRUCTOR (with A type), also a new TARGET_EXPR because of that, but both are
cp_tree_equal, as it doesn't care about exact type as long as it has
same_type_p.

So, shall adjust_temp_type not bother if it is same_type_p, or shall the assert
be adjusted, or shall we adjust the type earlier already?  The assert is there
already since r166166.

[Bug preprocessor/88257] [9 Regression] ICE in linemap_position_for_line_and_column, at libcpp/line-map.c:842

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
Author: dmalcolm
Date: Fri Nov 30 15:57:37 2018
New Revision: 266671

URL: https://gcc.gnu.org/viewcvs?rev=266671=gcc=rev
Log:
Fix ICE in substring locations from macros in header files (PR
preprocessor/88257)

PR preprocessor/88257 reports an ICE on gcc.dg/format/pr78304.c
when compiled using g++:

void test (const char *msg)
{
  printf ("size: %" PRIu32 "\n", msg);
}

due to mismatching files (and line maps) between
linemap_resolve_location and expand_location_to_spelling_point
when PRIu32 is defined in a system header.

The root cause is that expand_location_to_spelling_point stops
unwinding locations when it reaches a system header, whereas
linemap_resolve_location can resolve into a system header,
which can lead to locations within get_substring_ranges_for_loc
getting out of sync, and using the wrong line map.

This patch fixes the issue by checking that the files are the
same.

gcc/ChangeLog:
PR preprocessor/88257
* input.c (get_substring_ranges_for_loc): Fix indentation.
Bulletproof against getting a different files back from
linemap_resolve_location and expand_location_to_spelling_point.

gcc/testsuite/ChangeLog:
PR preprocessor/88257
* c-c++-common/Wformat-pr88257.c: New test.
* c-c++-common/Wformat-pr88257.h: New test header.
* c-c++-common/empty.h: New test header.


Added:
trunk/gcc/testsuite/c-c++-common/Wformat-pr88257.c
trunk/gcc/testsuite/c-c++-common/Wformat-pr88257.h
trunk/gcc/testsuite/c-c++-common/empty.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/input.c
trunk/gcc/testsuite/ChangeLog

[Bug target/88278] Fails to elide zeroing of upper vector register

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
I wonder about something like:
--- gcc/config/i386/sse.md.jj   2018-11-29 23:16:06.481301632 +0100
+++ gcc/config/i386/sse.md  2018-11-30 16:21:21.480379008 +0100
@@ -7248,6 +7248,17 @@
(set_attr "prefix" "orig,maybe_evex,orig,maybe_evex")
(set_attr "mode" "V4SF,V4SF,V2SF,V2SF")])

+(define_insn "*vec_concatv4sf_0"
+  [(set (match_operand:V4SF 0 "register_operand"   "=v")
+   (vec_concat:V4SF
+ (match_operand:V2SF 1 "nonimmediate_operand" "xm")
+ (match_operand:V2SF 2 "const0_operand"   " C")))]
+  "TARGET_SSE2"
+  "%vmovq\t{%1, %0|%0, %1}"
+  [(set_attr "type" "ssemov")
+   (set_attr "prefix" "maybe_vex")
+   (set_attr "mode" "DF")])
+
 ;; Avoid combining registers from different units in a single alternative,
 ;; see comment above inline_secondary_memory_needed function in i386.c
 (define_insn "vec_set_0"
@@ -14409,6 +14420,23 @@
(set_attr "prefix" "orig,maybe_evex,orig,orig,maybe_evex")
(set_attr "mode" "TI,TI,V4SF,V2SF,V2SF")])

+(define_insn "*vec_concatv4si_0"
+  [(set (match_operand:V4SI 0 "register_operand"   "=v,x")
+   (vec_concat:V4SI
+ (match_operand:V2SI 1 "nonimmediate_operand" "vm,?!*y")
+ (match_operand:V2SI 2 "const0_operand"   " C,C")))]
+  "TARGET_SSE2"
+  "@
+   %vmovq\t{%1, %0|%0, %1}
+   movq2dq\t{%1, %0|%0, %1}"
+  [(set_attr "type" "ssemov")
+   (set_attr "prefix" "maybe_vex,orig")
+   (set_attr "mode" "TI")
+   (set (attr "preferred_for_speed")
+ (if_then_else (eq_attr "alternative" "1")
+   (symbol_ref "TARGET_INTER_UNIT_MOVES_FROM_VEC")
+   (symbol_ref "true")))])
+
 ;; movd instead of movq is required to handle broken assemblers.
 (define_insn "vec_concatv2di"
   [(set (match_operand:V2DI 0 "register_operand"

but the #c0 testcases don't compile for me with -O2 -msse2 -fgimple (nor
-mavx), so I can't easily verify.

I don't see how we could get rid of those for the v <- v,C cases, unless we
analyze whatever instruction generated it and prove that it leaves all the
higher bits set to zero.  E.g. one could have a v4si to v2si downcast (just
picking the lowpart subreg) followed by concatenating it with zero, and if we
blindly drop the movq instruction, the upper bits might be non-zero.

[Bug target/88278] Fails to elide zeroing of upper vector register

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Note, we also have vec_concatv2di pattern that handles:
(set (match_operand:V2DI 0 ("register_operand") ("=Yr,*x,x ,v ,v,v ,x  
,x,v ,x,x,v"))
(vec_concat:V2DI (match_operand:DI 1 ("nonimmediate_operand") (" 
0, 0,x ,Yv,r,vm,?!*y,0,Yv,0,0,v"))
(match_operand:DI 2 ("nonimm_or_0_operand") (" rm,rm,rm,rm,C ,C
,C ,x,Yv,x,m,m"
and then *vec_concatv4si which handles far less than that, just the last 5
alternatives.  Conceptually, both operations do the same thing, on the other
side not sure if it is a good idea to say to RA that it could put V2SImode
pseudos into GPRs.  So, that leaves us at the first pinsrq alternatives with
just "m" for them, not really sure they are worth it.  Then there is one v <-
r, C alternative, again, I think we shouldn't put V2SImode into GPRs, v <- vm,
C alternative that we definitely want, but it could be a separate
*vec_concatv4si_0
pattern two, as nonimmediate_operand and const0_operand don't overlap and last
x <- ?!*y, C, that's MMXish, maybe, maybe not.

[Bug target/88278] Fails to elide zeroing of upper vector register

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #2)
> All these use something like:
> (insn 7 6 13 2 (set (reg:V8SI 87)
> (unspec:V8SI [
> (mem:V4SI (reg:DI 90) [0 *x_3(D)+0 S16 A128])
> ] UNSPEC_CAST)) "include/avxintrin.h":1484:20 4813 {avx_si256_si}
>  (expr_list:REG_DEAD (reg:DI 90)
> (nil)))
> Not really sure why UNSPEC_CAST rather than representing it with something
> natural like VEC_CONCAT of nonimmediate_operand and const0_operand.

I tried to get rid of the UNSPEC_CAST in PR 50829... VEC_CONCAT with 0 may be
fine when loading from memory, but we don't want it when the argument is in a
register.

[Bug gcov-profile/88279] [9 Regression] unresolvable R_X86_64_DTPOFF32 relocation against symbol `__gcov_indirect_call'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug gcov-profile/88279] [9 Regression] unresolvable R_X86_64_DTPOFF32 relocation against symbol `__gcov_indirect_call'

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Fri Nov 30 15:06:22 2018
New Revision: 26

URL: https://gcc.gnu.org/viewcvs?rev=26=gcc=rev
Log:
Call decl_default_tls_model with a proper type (PR gcov-profile/88279).

2018-11-30  Alexander Monakov  

PR gcov-profile/88279
* tree-profile.c (init_ic_make_global_vars): Call
decl_default_tls_model for variable and not it's type.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-profile.c

[Bug target/88278] Fails to elide zeroing of upper vector register

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Fri, 30 Nov 2018, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88278
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2018-11-30
>  Ever confirmed|0   |1
> 
> --- Comment #2 from Jakub Jelinek  ---
> I guess
> #include 
> 
> __m128i
> foo (__m64 *x)
> {
>   return _mm_movpi64_epi64 (*x);
> }
> is what intrinsic users would write for this case, and that is optimized
> properly:
> (insn 7 6 12 2 (set (reg:V2DI 87)
> (vec_concat:V2DI (mem:DI (reg:DI 89) [0 *x_3(D)+0 S8 A64])
> (const_int 0 [0]))) "include/emmintrin.h":592:24 3956
> {vec_concatv2di}
>  (expr_list:REG_DEAD (reg:DI 89)
> (nil)))
> 
> Similarly e.g.
> #include 
> 
> __m256
> foo (__m128 *x)
> {
>   return _mm256_castps128_ps256 (*x);
> }
> which is conceptually closest to this case.
> Or
> #include 
> 
> __m256i
> foo (__m128i *x)
> {
>   return _mm256_castsi128_si256 (*x);
> }
> 
> All these use something like:
> (insn 7 6 13 2 (set (reg:V8SI 87)
> (unspec:V8SI [
> (mem:V4SI (reg:DI 90) [0 *x_3(D)+0 S16 A128])
> ] UNSPEC_CAST)) "include/avxintrin.h":1484:20 4813 {avx_si256_si}
>  (expr_list:REG_DEAD (reg:DI 90)
> (nil)))
> Not really sure why UNSPEC_CAST rather than representing it with something
> natural like VEC_CONCAT of nonimmediate_operand and const0_operand.

OK, it indeed seems to "work" when punning via integers:

typedef unsigned long v2di __attribute__((vector_size(16)));

v2di __GIMPLE baz (unsigned long *p)
{
  unsigned long _2;
  v2di _3;

bb_2:
  _2 = __MEM  (p_1(D));
  _3 = _Literal (v2di) { _2, _Literal (unsigned long) 0 };
  return _3;
}

looks like for this combine can do

Successfully matched this instruction:
(set (reg:V2DI 87)
(vec_concat:V2DI (mem:DI (reg:DI 89) [1 *p_1(D)+0 S8 A64])
(const_int 0 [0])))

which means the vector variants could be handled similarly
by macroizing on vector modes with matching sizes?  Or is
this undesirable?  If we declare the above canonical RTL
for zero-"extending" loads into vector registers then we
can handle this during RTL expansion I guess.

[Bug target/88278] Fails to elide zeroing of upper vector register

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-30
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
I guess
#include 

__m128i
foo (__m64 *x)
{
  return _mm_movpi64_epi64 (*x);
}
is what intrinsic users would write for this case, and that is optimized
properly:
(insn 7 6 12 2 (set (reg:V2DI 87)
(vec_concat:V2DI (mem:DI (reg:DI 89) [0 *x_3(D)+0 S8 A64])
(const_int 0 [0]))) "include/emmintrin.h":592:24 3956
{vec_concatv2di}
 (expr_list:REG_DEAD (reg:DI 89)
(nil)))

Similarly e.g.
#include 

__m256
foo (__m128 *x)
{
  return _mm256_castps128_ps256 (*x);
}
which is conceptually closest to this case.
Or
#include 

__m256i
foo (__m128i *x)
{
  return _mm256_castsi128_si256 (*x);
}

All these use something like:
(insn 7 6 13 2 (set (reg:V8SI 87)
(unspec:V8SI [
(mem:V4SI (reg:DI 90) [0 *x_3(D)+0 S16 A128])
] UNSPEC_CAST)) "include/avxintrin.h":1484:20 4813 {avx_si256_si}
 (expr_list:REG_DEAD (reg:DI 90)
(nil)))
Not really sure why UNSPEC_CAST rather than representing it with something
natural like VEC_CONCAT of nonimmediate_operand and const0_operand.

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #36 from Martin Liška  ---
Implemented on trunk.

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[marxin at gcc dot gnu.org]

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

--- Comment #35 from Martin Liška  ---
Author: marxin
Date: Fri Nov 30 14:25:15 2018
New Revision: 24

URL: https://gcc.gnu.org/viewcvs?rev=24=gcc=rev
Log:
Make red zone size more flexible for stack variables (PR sanitizer/81715).

2018-11-30  Martin Liska  

PR sanitizer/81715
* asan.c (asan_shadow_cst): Remove, partially transform
into flush_redzone_payload.
(RZ_BUFFER_SIZE): New.
(struct asan_redzone_buffer): New.
(asan_redzone_buffer::emit_redzone_byte): Likewise.
(asan_redzone_buffer::flush_redzone_payload): Likewise.
(asan_redzone_buffer::flush_if_full): Likewise.
(asan_emit_stack_protection): Use asan_redzone_buffer class
that is responsible for proper aligned stores and flushing
of shadow memory payload.
* asan.h (ASAN_MIN_RED_ZONE_SIZE): New.
(asan_var_and_redzone_size): Likewise.
* cfgexpand.c (expand_stack_vars): Use smaller alignment
(ASAN_MIN_RED_ZONE_SIZE) in order to make shadow memory
for automatic variables more compact.
2018-11-30  Martin Liska  

PR sanitizer/81715
* c-c++-common/asan/asan-stack-small.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/asan/asan-stack-small.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/asan.c
trunk/gcc/asan.h
trunk/gcc/cfgexpand.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/88220] LTO ICE with GNU inline and alias's

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
So the issue is that in WPA we mix:
void a() __asm__("open64");

and

void open64() {}

Then we stream out:
*open64/0 (a) @0x7698f5a0
  Type: function definition analyzed
  Visibility: externally_visible prevailing_def_ironly_exp public
  Address is taken.
  References: 
  Referring: e/2 (addr)
  Read from file: open64.o
  Availability: overwritable
  Function flags: count:1073741824 (estimated locally)
  Called by: 
  Calls: c/4 (1073741824 (estimated locally),1.00 per call) b/3 (1073741824
(estimated locally),1.00 per call) 

and in ltrans the function body of the cgraph node looks as follows:
$2 = void
(gdb) p debug_function(fn_decl, 0)
a ()
{
   [local count: 1073741824]:
  return;

}

which has no calls, thus the discrepancy in cgraph edges. I think it's the same
issue as PR87525. So Honza's turn.

[Bug tree-optimization/88280] missing folding of logical and bitwise AND

[denis.campredon at gmail dot com]

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

--- Comment #2 from denis.campredon at gmail dot com ---
I don't know if I should create a separate bug report or not, since it looks
kind of related.
I've tried to replace the operator of the function e with other and it
generates a branch with the following operators
--
int b_and(int i, int a) {
   return i && i & a;
}
int b_or(int i, int a) {
   return i && i | a;
}
int add(int i, int a) {
   return i && i + a;
}
int mult(int i, int a) {
   return i && i * a;
}
int left(int i, int a) {
   return i && i << a;
}
int right(int i, int a) {
   return i && i >> a;
}
int l_or(int i, int a) {
   return i && (i || a);
}
--
But does not with :
--
int b_xor(int i, int a) {
   return i && i ^ a;
}
int sub(int i, int a) {
   return i && i - a;
}

[Bug target/88284] New: nios2: pessimistic ldw-to-stwio scheduling

[already5chosen at yahoo dot com]

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

Bug ID: 88284
   Summary: nios2: pessimistic ldw-to-stwio scheduling
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: already5chosen at yahoo dot com
  Target Milestone: ---

Created attachment 45131
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45131=edit
demonstration of bad scheduling

Compiler generates bad scheduling for memory-to-io copy loops.
It seems that Nios2 instruction scheduler somehow don't understand that stwio
instruction depends on the value it is going to store.

I have no idea why, instead of producing random schedule, the compiler
consistently generates the worst possible schedule. Possibly, it is a result of
unfortunate interaction with one of the middle-end heuristics (attempt of
prefetch?). 
But the reason is less important than the outcome.

My demonstration code consists of four examples of good scheduling for cases of
memory-to-memory copies and four examples of bad scheduling for cases of
memory-to-io copies. An optimal scheduling for memory-to-io copies (ldw
followed by stwio) is exactly the same as for memory-to-memory copies (ldw
followed by stw).
In both cases in order to avoid pipeline stall ldw and an instruction that
depends on loaded values shell be separated by at least two unrelated
instructions.

Compiled with 'nios2-elf-gcc -c -Wall -ffreestanding -O2 --save-temps'
gcc version 8.2.0

[Bug target/88282] ICE in df_install_refs at gcc/df-scan.c:2379

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-30
   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Tamar Christina  ---
Confirmed, something broke in between upstreaming and now. Taking a look.

[Bug middle-end/88279] [9 Regression] unresolvable R_X86_64_DTPOFF32 relocation against symbol `__gcov_indirect_call'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
I can confirm it resolves the issue, let me prepare changelog for it.
Thanks Alexander!

[Bug middle-end/88279] [9 Regression] unresolvable R_X86_64_DTPOFF32 relocation against symbol `__gcov_indirect_call'

[amonakov at gcc dot gnu.org]

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

--- Comment #4 from Alexander Monakov  ---
To clarify, the decl/type mixup is causing the compiler to use local-dynamic
TLS references where general-dynamic are intended (and were used prior to the
patch).

[Bug libgcc/88267] A new flag in GCC causes a divergence in crtbegin.o file

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
(In reply to Richard Biener from comment #1)
> But it's hidden, so I'm not sure we care. 

I noticed that using objdump -d where the tools assigns names to locations of
which it knows name.

> OTOH not sure why options.h is being pulled in.

This should be investigated ;)

[Bug middle-end/88279] [9 Regression] unresolvable R_X86_64_DTPOFF32 relocation against symbol `__gcov_indirect_call'

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
The patch changed the argument to decl_default_tls_model from a decl to a type
node, which is probably wrong. This line:

set_decl_tls_model (ic_tuple_var, decl_default_tls_model (tuple_type));

should have used ic_tuple_var instead of the tuple_type?

[Bug c++/88258] [9 Regression] Infinite loop emitting diagnostics in the C++ front-end

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug target/88282] ICE in df_install_refs at gcc/df-scan.c:2379

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
One related testcase that fails:

$ aarch64-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41470.c
-fstack-clash-protection -O2 -fno-tree-ccp
during RTL pass: reload
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41470.c: In function ‘bf’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41470.c:22:1: internal
compiler error: Segmentation fault
   22 | }
  | ^
0xa88a2f crash_signal
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/toplev.c:326
0x76bc310f ???
   
/usr/src/debug/glibc-2.27-6.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7329b1 df_install_refs
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2379
0x732a94 df_install_refs
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2425
0x732a94 df_refs_add_to_chains
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2425
0x738fae df_bb_refs_record(int, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:3350
0x7391bc df_scan_blocks()
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:588
0x8f127d do_reload
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/ira.c:5533
0x8f127d execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/ira.c:5653

[Bug tree-optimization/88283] New: ICE in try_improve_iv_set, at tree-ssa-loop-ivopts.c:6677

[marxin at gcc dot gnu.org]

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

Bug ID: 88283
   Summary: ICE in try_improve_iv_set, at
tree-ssa-loop-ivopts.c:6677
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: amker at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-linux-gnu

Probably something graphite-related:

$ gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/graphite/interchange-8.c
-fgraphite-identity -fnon-call-exceptions -fexceptions -Ofast -mabi=ilp32
during GIMPLE pass: ivopts
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/graphite/interchange-8.c: In
function ‘foo’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/graphite/interchange-8.c:10:1:
internal compiler error: in try_improve_iv_set, at tree-ssa-loop-ivopts.c:6677
   10 | foo (void)
  | ^~~
0x5c26ec try_improve_iv_set
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-loop-ivopts.c:6677
0x5c26ec find_optimal_iv_set_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-loop-ivopts.c:6707
0xba3ee1 find_optimal_iv_set
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-loop-ivopts.c:6729
0xba3ee1 tree_ssa_iv_optimize_loop
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-loop-ivopts.c:7586
0xba3ee1 tree_ssa_iv_optimize()
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-loop-ivopts.c:7628
0xbbfad0 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-loop.c:513

[Bug target/88282] New: ICE in df_install_refs at gcc/df-scan.c:2379

[marxin at gcc dot gnu.org]

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

Bug ID: 88282
   Summary: ICE in df_install_refs at gcc/df-scan.c:2379
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: ktkachov at gcc dot gnu.org, ramana at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-linux-gnu

Following causes ICE:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41470.c --param
large-stack-frame=0 -Ofast -fstack-clash-protection
during RTL pass: reload
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41470.c: In function ‘bf’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41470.c:22:1: internal
compiler error: Segmentation fault
   22 | }
  | ^
0xa88a2f crash_signal
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/toplev.c:326
0x76bc310f ???
   
/usr/src/debug/glibc-2.27-6.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7329b1 df_install_refs
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2379
0x732a94 df_install_refs
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2425
0x732a94 df_refs_add_to_chains
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2425
0x738fae df_bb_refs_record(int, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:3350
0x7391bc df_scan_blocks()
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:588
0x8f127d do_reload
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/ira.c:5533
0x8f127d execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/ira.c:5653

[Bug middle-end/88279] [9 Regression] unresolvable R_X86_64_DTPOFF32 relocation against symbol `__gcov_indirect_call'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug tree-optimization/88280] missing folding of logical and bitwise AND

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-30
Version|unknown |9.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  g and h end up like this before RTL expansion (initial folding
produces this):

  j_6 = i_4(D) & a_5(D);
  _1 = i_4(D) != 0;
  _2 = j_6 != 0;
  _3 = _1 & _2;
  _7 = (int) _3;
  return _7;

and for e we do not combine the i != 0 check.

   [local count: 1073741824]:
  if (i_3(D) != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  _1 = i_3(D) & a_4(D);
  _6 = _1 != 0;
  _7 = (int) _6;

   [local count: 1073741824]:
  # iftmp.0_2 = PHI <_7(3), i_3(D)(2)>
  return iftmp.0_2;

[Bug target/88278] Fails to elide zeroing of upper vector register

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-* i?86-*-*
 CC||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Hmm, it looks like *movdi_internal and friends to not represent the implicit
zeroing of the upper part?

I guess RTL in general (before reload) doesn't know that V2SI is the low
part of a V4SI register.  But after reload we see (split2)

(insn 7 5 8 2 (set (reg:V8QI 20 xmm0 [orig:88 MEM[(unsigned char *)p_1(D)] ]
[88])
(mem:V8QI (reg:DI 5 di [91]) [0 MEM[(unsigned char *)p_1(D)]+0 S8 A8]))
1078 {*movv8qi_internal}
 (nil))
(insn 8 7 9 2 (set (reg:V2SI 21 xmm1 [90])
(const_vector:V2SI [
(const_int 0 [0]) repeated x2
])) 1080 {*movv2si_internal}
 (expr_list:REG_EQUIV (const_vector:V2SI [
(const_int 0 [0]) repeated x2
])
(nil)))
(insn 9 8 16 2 (set (reg:V4SI 20 xmm0 [89])
(vec_concat:V4SI (reg:V2SI 20 xmm0 [orig:88 MEM[(unsigned char
*)p_1(D)] ] [88])
(reg:V2SI 21 xmm1 [90]))) 3955 {*vec_concatv4si}
 (expr_list:REG_EQUAL (vec_concat:V4SI (subreg:V2SI (reg:V8QI 20 xmm0
[orig:88 MEM[(unsigned char *)p_1(D)] ] [88]) 0)
(const_vector:V2SI [
(const_int 0 [0]) repeated x2
]))
(nil)))

where the pattern is probably easier to optimize (but we then fail to elide
the xmm1 register as not needed eventually)?

[Bug tree-optimization/88274] ICE in check, at tree-vrp.c:188

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Fri, 30 Nov 2018, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88274
> 
> --- Comment #11 from Eric Botcazou  ---
> > It's the opposite, we need to hide TYPE_MIN/MAX_VALUE to preserve checks in
> > Ada, otherwise the optimizer happily removes them.
> 
> To be more explicit: in Ada, you can check at run time whether a value is 
> valid
> for its nominal subtype (i.e. you can check if it's within the range) so you
> cannot have the obvious TYPE_MIN/MAX_VALUE on this nominal subtype, otherwise
> these checks will be elided by VRP.

OK, so we don't have coverage for VRP optimizations on such types
from Ada.  That leaves us with -fstrict-enums, defaulted to off.

I seriously question the value of VRP trying to look at
TYPE_MIN/MAX_VALUE then.

[Bug tree-optimization/88281] SLP permutation check fails to fall back to strided loads

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-30
 Blocks||53947
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/88281] New: SLP permutation check fails to fall back to strided loads

[rguenth at gcc dot gnu.org]

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

Bug ID: 88281
   Summary: SLP permutation check fails to fall back to strided
loads
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

The following is not vectorized due to a group size of 17 and unsupported load
permutation:

typedef unsigned char uint8_t;
static int x264_pixel_sad_8x8( uint8_t *pix1, int i_stride_pix1, uint8_t *pix2,
int i_stride_pix2 )
{
  int i_sum = 0;
  for( int y = 0; y < 8; y++ )
{
  for( int x = 0; x < 8; x++ )
i_sum += __builtin_abs( pix1[x] - pix2[x] );
  pix1 += 17;
  pix2 += i_stride_pix2;
}
  return i_sum;
}
void x264_pixel_sad_x4_8x8( uint8_t *fenc, uint8_t *pix0, uint8_t *pix1,
uint8_t *pix2, uint8_t *pix3, int i_stride, int scores[4] )
{
  *scores = x264_pixel_sad_8x8( fenc, 16, pix0, i_stride );
}

[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib

[stephen.kim at oracle dot com]

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

Stephen Kim  changed:

   What|Removed |Added

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

--- Comment #6 from Stephen Kim  ---
This bug is reproducible only on arm64. Sorry for missing the info. That was my
bad. 

Besides, it is reproducible with a particular patch in glibc, which was made
this year. 

And, the reason that glibc test did not detect this issue is because Debian gcc
seems to default pie. I.e. it might be configured with --enable-default-pie.
Gentoo does the same. Thus, they are giving Scrt1.o.

As of today, the gcc I got after running Debian:latest docker container and
executing "apt-get update," shows this on "gcc -v":
 $ gcc -v  2>&1 | egrep -o "enable-default-pie"
 enable-default-pie

Oracle Linux on arm64 is the environment that meets the requirements for the
bug. It has the glibc patch, and the gcc is not configured to default PIE. 

Thus, if not being reproducible was the reason that the bug is closed, I would
say that it is reproducible. Please, use oraclelinux:latest docker container on
aarch64.

If this bug is closed because it is indeed user's fault not a compiler driver
error, please, close this bug again.

[Bug testsuite/85368] [8/9 regression] phi-opt-11 test fails on IBM Z

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
It is enough to test it with:
cd build-dir/gcc
make check-gcc RUNTESTFLAGS="dg.exp='binop-xor1.c builtin-bswap-7.c pr21643.c
pr46309.c' tree-ssa.exp='forwprop-28.c phi-opt-11.c phi-opt-2.c reassoc-32.c
reassoc-33.c reassoc-34.c reassoc-35.c reassoc-36.c ssa-dom-thread-11.c
ssa-dom-thread-14.c ssa-dom-thread-16.c ssa-dom-thread-4.c ssa-dom-thread-18.c
ssa-ifcombine-13.c ssa-ifcombine-ccmp-1.c ssa-ifcombine-ccmp-2.c
ssa-ifcombine-ccmp-3.c ssa-ifcombine-ccmp-4.c ssa-ifcombine-ccmp-5.c
ssa-ifcombine-ccmp-6.c ssa-thread-11.c ssa-thread-14.c vrp47.c vrp87.c'"
apply patch
make cc1
repeat above make check-gcc

[Bug testsuite/85368] [8/9 regression] phi-opt-11 test fails on IBM Z

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-30
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #10 from Jakub Jelinek  ---
Created attachment 45129
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45129=edit
gcc9-pr85368.patch

Untested fix through a new param.

Can folks test it before/after this patch please on various targets (powerpc,
arm non-cortex-m, arm cortex-m, s390x)?  I've tested it on x86_64-linux so far.

[Bug tree-optimization/88280] New: missing folding of logical and bitwise AND

[denis.campredon at gmail dot com]

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

Bug ID: 88280
   Summary: missing folding of logical and bitwise AND
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.campredon at gmail dot com
  Target Milestone: ---

The following functions should all produce the same code with optimisations on
(it is the same if `a' is replaced with a constant) 
-
int e(int i, int a) {
return i && i & a;
}

int f(int i, int a) {
return i & a && i;
}

int g(int i, int a) {
int j = i & a;

return j && i;
}

int h(int i, int a) {
int j = i & a;

return i && j;
}
-

But currently only f produces good assembly:

f(int, int):
xor eax, eax
testedi, esi
setne   al
ret

[Bug middle-end/88279] [9 Regression] unresolvable R_X86_64_DTPOFF32 relocation against symbol `__gcov_indirect_call'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-30
 CC||marxin at gcc dot gnu.org
  Known to work||8.2.0
Summary|unresolvable|[9 Regression] unresolvable
   |R_X86_64_DTPOFF32   |R_X86_64_DTPOFF32
   |relocation against symbol   |relocation against symbol
   |`__gcov_indirect_call'  |`__gcov_indirect_call'
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #2 from Martin Liška  ---
Confirmed with my revision r264840 where I changed:

void * __gco-void *__gcov_indirect_call_topn_callee ATTRIBUTE_HIDDEN;
gcov_type * __gcov_indirect_call_counters;

into:

struct indirect_call_tuple
{
  /* Callee function.  */
  void *callee;

  /* Pointer to counters.  */
  gcov_type *counters;
};

struct indirect_call_tuple __gcov_indirect_call;

[Bug tree-optimization/88274] ICE in check, at tree-vrp.c:188

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  ---
> It's the opposite, we need to hide TYPE_MIN/MAX_VALUE to preserve checks in
> Ada, otherwise the optimizer happily removes them.

To be more explicit: in Ada, you can check at run time whether a value is valid
for its nominal subtype (i.e. you can check if it's within the range) so you
cannot have the obvious TYPE_MIN/MAX_VALUE on this nominal subtype, otherwise
these checks will be elided by VRP.

[Bug tree-optimization/88272] warning: iteration 9223372036854775807 invokes undefined behavior

[hubicka at ucw dot cz]

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

--- Comment #2 from Jan Hubicka  ---
> Where do we set the cut-off? ;)
-fuser-patience=

I would cut it off for things that are obviously derived from sign of
64bit value :)) Those are most common.

Honza

[Bug middle-end/88279] unresolvable R_X86_64_DTPOFF32 relocation against symbol `__gcov_indirect_call'

[hubicka at gcc dot gnu.org]

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

--- Comment #1 from Jan Hubicka  ---
GNU ld (GNU Binutils for Debian) 2.28