[Bug tree-optimization/93004] New: Suspicious code in tree-ssa-loop-ivopts.c

[fxue at os dot amperecomputing.com]

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

Bug ID: 93004
   Summary: Suspicious code in tree-ssa-loop-ivopts.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at os dot amperecomputing.com
  Target Milestone: ---

In function determine_group_iv_cost_address(),

  /* Uses in a group can share setup code, so only add setup cost once.  */
  cost -= cost.scratch;
  /* Compute and add costs for rest uses of this group.  */
  for (i = 1; i < group->vuses.length () && !sum_cost.infinite_cost_p (); i++)
{
  struct iv_use *next = group->vuses[i];

  /* TODO: We could skip computing cost for sub iv_use when it has the
 same cost as the first iv_use, but the cost really depends on the
 offset and where the iv_use is.  */
cost = get_computation_cost (data, next, cand, true,
 NULL, &can_autoinc, &inv_expr);
if (inv_expr)
  {
if (!inv_exprs)
  inv_exprs = BITMAP_ALLOC (NULL);

bitmap_set_bit (inv_exprs, inv_expr->id);
  }
  sum_cost += cost;
}

Change to "cost" ahead of loop is meaningless, since it will be refreshed
inside the loop. According to comment, I guess "cost -= cost.scratch" might be
placed after "cost = get_computation_cost()".

[Bug debug/93000] [gdb] gdb failed to break on an executed address

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
This seems like a GDB bug which should be reported there:
http://sourceware.org/bugzilla .

[Bug fortran/93003] internal compiler error: Segmentation fault

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from kargl at gcc dot gnu.org ---
This is not what you wanted to send.

[Bug fortran/93003] New: internal compiler error: Segmentation fault

[vijayan at cmmacs dot ernet.in]

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

Bug ID: 93003
   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vijayan at cmmacs dot ernet.in
  Target Milestone: ---

Created attachment 47524
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47524&action=edit
Bug report

[Bug target/93002] while(i--) optimization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu

--- Comment #1 from Andrew Pinski  ---
With -fno-ivopts we get:
movl$1000, %edx
movl$999, %eax
.p2align 4,,10
.p2align 3
.L2:
movl%eax, sink(%rip)
subl$1, %eax
subl$1, %edx
jne .L2
ret

[Bug ipa/92794] [10 Regression] ICE in decide_about_value, at ipa-cp.c:5186

[fxue at gcc dot gnu.org]

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

--- Comment #7 from fxue at gcc dot gnu.org ---
I tested it locally, passed. You can have a try to confirm that.

[Bug c/93002] New: while(i--) optimization

[getchar_gnu at hotmail dot com]

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

Bug ID: 93002
   Summary: while(i--) optimization
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: getchar_gnu at hotmail dot com
  Target Milestone: ---

while (i--) can be compiled into `sub ecx, 1 / jnc code` rather than `dec ecx /
cmp ecx, -1 / jne code`.

See https://stackoverflow.com/questions/54278070/ for discussion (I'm asker)

[Bug ipa/92794] [10 Regression] ICE in decide_about_value, at ipa-cp.c:5186

[asolokha at gmx dot com]

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

--- Comment #6 from Arseny Solokha  ---
Can this PR be fixed now?

[Bug c++/93001] bogus is private within this context error with scoped enum

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
I think the problem is in dfs_accessible_post:
 757   tree scope = current_nonlambda_scope ();
will for this line:
  enum class S::E : S::T { X };
give "::" so dfs_accessible_post returns NULL_TREE.  But if it were a function,
its scope would be "S".

[Bug c++/93001] New: bogus is private within this context error with scoped enum

[mpolacek at gcc dot gnu.org]

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

Bug ID: 93001
   Summary: bogus is private within this context error with scoped
enum
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

class S {
  using T = int;
  enum class E : T;
};

enum class S::E : S::T { X };

gives

pr.C:6:22: error: ‘using T = int’ is private within this context
6 | enum class S::E : S::T { X };
  |  ^
pr.C:2:9: note: declared private here
2 |   using T = int;
  | ^

but since S::E is a member of class S, this is valid.

[Bug ipa/92794] [10 Regression] ICE in decide_about_value, at ipa-cp.c:5186

[fxue at gcc dot gnu.org]

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

--- Comment #5 from fxue at gcc dot gnu.org ---
Author: fxue
Date: Thu Dec 19 02:54:40 2019
New Revision: 279561

URL: https://gcc.gnu.org/viewcvs?rev=279561&root=gcc&view=rev
Log:
Handle aggregate pass-through for self-recursive call (PR ipa/92794)

2019-12-19  Feng Xue  

PR ipa/92794
* ipa-cp.c (self_recursive_agg_pass_through_p): New function.
(intersect_with_plats): Use error_mark_node as place holder
when aggregate jump function is simple pass-through for
self-recursive call.
(intersect_with_agg_replacements): Likewise.
(intersect_aggregates_with_edge): Likewise.
(find_aggregate_values_for_callers_subset): Likewise.

2019-12-19  Feng Xue  

PR ipa/92794
* gcc.dg/ipa/92794.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/ipa/pr92794.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/92980] [miss optimization]redundant load missed by fre.

[crazylht at gmail dot com]

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

--- Comment #5 from Hongtao.liu  ---
(In reply to Andrew Pinski from comment #4)

> But that is not true any more.  So I think this optimization can be removed
> as it is too early.  Just double check the above testcase and the C++
> testcase (g++.dg/opt/ptrintsum1.C) to make sure they still work and post
> that removal.

Removal works fines with those 2 testcases.

[Bug debug/93000] [gdb] gdb failed to break on an executed address

[yangyibiao at hust dot edu.cn]

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

--- Comment #1 from Yibiao Yang  ---
the compilation command is as follows:

$ gcc -w -g -O0 small.c -o small.obj

[Bug debug/93000] New: [gdb] gdb failed to break on an executed address

[yangyibiao at hust dot edu.cn]

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

Bug ID: 93000
   Summary: [gdb] gdb failed to break on an executed address
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at hust dot edu.cn
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8.3.0-6ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1~18.04.1)



 test program 

$ cat small.c
/* { dg-do run } */
/* { dg-options "-fsanitize=undefined -fsanitize-undefined-trap-on-error" } */

int __attribute__((noinline,noclone))
h(int a)
{
  return 2 * (a * (__INT_MAX__/2 + 1));
}
int __attribute__((noinline,noclone))
i(int a)
{
  return (2 * a) * (__INT_MAX__/2 + 1);
}
int __attribute__((noinline,noclone))
j(int a, int b)
{
  return (b * a) * (__INT_MAX__/2 + 1);
}
int __attribute__((noinline,noclone))
k(int a, int b)
{
  return (2 * a) * b;
}
int main()
{
  volatile int tem = h(-1);
  tem = i(-1);
  tem = j(-1, 2);
  tem = k(-1, __INT_MAX__/2 + 1);
  return 0;
}



 gdb commands 

$ cat cmds1
break *i+0x0
run
kill
q



$ cat cmds2
break *j+0x0
run
kill
q



 execute commands 


$ gdb -batch -x cmds1 ./small.obj
Breakpoint 1 at 0x5e6: file small.c, line 11.

[7]+  Stopped gdb -batch -x cmds ./small.obj


$ gdb -batch -x cmds2 ./small.obj
Breakpoint 1 at 0x5f7: file small.c, line 16.

Breakpoint 1, j (a=-1, b=0) at small.c:16
16  {
Kill the program being debugged? (y or n) [answered Y; input not from terminal]
[Inferior 1 (process 15108) killed]




 problem 

gdb failed to break at address "*i+0x0" while it breaks at address "*j+0x0"

function "i" and "j" are both executed functions called by "main" function in
the test program.

[Bug c/92999] New: [armhf] struct with adjacent __fp16's copies wrongly

[jimreesma at gmail dot com]

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

Bug ID: 92999
   Summary: [armhf] struct with adjacent __fp16's copies wrongly
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jimreesma at gmail dot com
  Target Milestone: ---

Created attachment 47523
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47523&action=edit
Reproducer source

Discovered on "cc (Raspbian 8.3.0-6+rpi1) 8.3.0"

-dumpmachine ==> arm-linux-gnueabihf

Copying a struct with two adjacent __fp16's effectively copies the second
__fp16 onto the first.

See attached reproducer code.

Upon examining the assembly, it seems to be expecting to return the structure
in a single-precision floating point register -- the copy function converts the
2nd field to the single-precision register, then the caller treats that result
as the value from both fields.

The bug is consistent with -O0 through -O3.   The copy function must not be
inlined, else the compiler bypasses the copy entirely, so this is an issue with
structure copy semantics.

[Bug c++/91165] [10 Regression] error: location references block not in block tree

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  ---
Author: jason
Date: Thu Dec 19 00:10:47 2019
New Revision: 279557

URL: https://gcc.gnu.org/viewcvs?rev=279557&root=gcc&view=rev
Log:
PR c++/91165 follow-on tweak

I talked in the PR about possibly stripping the location from the args in
the hash table, since if we use the cache the locations would be wrong, but
didn't actually do anything about that.  Then I noticed that there's already
unshare_expr_without_location...

* constexpr.c (cxx_eval_call_expression): Use
unshare_expr_without_location.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug fortran/92977] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3526

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec 18 23:33:54 2019
New Revision: 279554

URL: https://gcc.gnu.org/viewcvs?rev=279554&root=gcc&view=rev
Log:
PR fortran/92977
* frontend-passes.c (in_omp_atomic): New variable.
(cfe_expr_0, matmul_to_var_expr, matmul_temp_args,
inline_matmul_assign, call_external_blas): Don't optimize in
EXEC_OMP_ATOMIC.
(optimize_namespace): Clear in_omp_atomic.
(gfc_code_walker): Set in_omp_atomic for EXEC_OMP_ATOMIC, save/restore
it around.

* gfortran.dg/gomp/pr92977.f90: New test.

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

[Bug middle-end/86416] [OpenMP] Offloading - better lto1 error message if mode not supported on offloading target

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec 18 23:27:28 2019
New Revision: 279552

URL: https://gcc.gnu.org/viewcvs?rev=279552&root=gcc&view=rev
Log:
PR middle-end/86416
* testsuite/libgomp.c/pr86416-1.c (main): Use L suffixes rather than
q or none.
* testsuite/libgomp.c/pr86416-2.c (main): Use Q suffixes rather than
L or none.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.c/pr86416-1.c
trunk/libgomp/testsuite/libgomp.c/pr86416-2.c

[Bug middle-end/86416] [OpenMP] Offloading - better lto1 error message if mode not supported on offloading target

[tschwinge at gcc dot gnu.org]

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

--- Comment #12 from Thomas Schwinge  ---
(In reply to Jakub Jelinek from comment #11)
> because e.g. for x86_64-intelmicemul-linux-gnu offloading the error will not
> be emitted.  If nvptx or gcn offloading is configured, it will be, for hsa
> offloading no idea.

Uh, more explicitly: for x86_64-intelmicemul-linux-gnu offloading the error
will not be emitted *unless* nvptx or gcn offloading is also configured. 
That's because for OpenMP libgomp testing we don't cycle through the different
offload targets individually (via '-foffload', as done for OpenACC libgomp
testing), but compile once, for all offload targets.

Each approach has its pros and cons; I'm not yet decided on which is best.

(What I am decided on, though, is that it's not ideal that by default OpenMP
offloading testing is only testing execution with one offload target, the first
configured/available.  Again there are different solutions possible to this
issue, again each with its pros and cons, and this is, of course a separate
discussion.)

[Bug middle-end/86416] [OpenMP] Offloading - better lto1 error message if mode not supported on offloading target

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Indeed, the q and L suffixes are swapped, I believe Tobias meant:
--- libgomp/testsuite/libgomp.c/pr86416-1.c.jj  2019-12-18 21:25:02.856131826
+0100
+++ libgomp/testsuite/libgomp.c/pr86416-1.c 2019-12-18 21:28:06.275349386
+0100
@@ -16,7 +16,7 @@ long double foo (long double x)

 int main()
 {
-  long double v = foo (10.0q) - 20.0q;
-  if (v > 1.0e-5 || v < -1.0e-5) abort();
+  long double v = foo (10.0L) - 20.0L;
+  if (v > 1.0e-5L || v < -1.0e-5L) abort();
   return 0;
 }
--- libgomp/testsuite/libgomp.c/pr86416-2.c.jj  2019-12-18 21:25:02.855131842
+0100
+++ libgomp/testsuite/libgomp.c/pr86416-2.c 2019-12-18 21:28:41.708811864
+0100
@@ -16,7 +16,7 @@ __float128 foo(__float128 y)

 int main()
 {
-  __float128 v = foo (5.0L) - 20.0L;
-  if (v > 1.0e-5 || v < -1.0e-5) abort();
+  __float128 v = foo (5.0Q) - 20.0Q;
+  if (v > 1.0e-5Q || v < -1.0e-5Q) abort();
   return 0;
 }

and will test that momentarily.  That said, I think that isn't enough, because
e.g. for x86_64-intelmicemul-linux-gnu offloading the error will not be
emitted.  If nvptx or gcn offloading is configured, it will be, for hsa
offloading no idea.

[Bug preprocessor/92987] -finput-charset is only usable with encodings that are supersets of ASCII

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
On Wed, 18 Dec 2019, lhyatt at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92987
> 
> --- Comment #2 from Lewis Hyatt  ---
> (In reply to jos...@codesourcery.com from comment #1)
> > I think -finput-charset may only be usable for character sets that are 
> > valid locale character sets (we don't implement the POSIX rule of 
> > interpreting source files in the locale encoding), which does mean 
> > supersets of ASCII.  And headers provided by one project for use by 
> > another indeed do practically need to be ASCII to be maximally portable.
> 
> OK thanks. I guess I am confused why charset.c implements conversion functions
> for UTF-16 and UTF-32, that can never actually be used without an error, but
> sounds like this use case is not important in any case?

I'd expect that's for use with -fwide-exec-charset.

[Bug testsuite/92998] aarch64/sve/acle/general/dupq_1.c fails on big-endian linux

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
gcc.target/aarch64/torture/simd-abi-8.c fails simular but due to arm_neon.h
instead.

[Bug testsuite/92998] New: aarch64/sve/acle/general/dupq_1.c fails on big-endian linux

[pinskia at gcc dot gnu.org]

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

Bug ID: 92998
   Summary: aarch64/sve/acle/general/dupq_1.c fails on big-endian
linux
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64_be-linux-gnu

aarch64/sve/acle/general/dupq_1.c fails as it used -mlittle-endian but
stubs-lp64.h does not exist normally (only stubs-lp64_be.h). 

Maybe it is best only test on big-endian target or have a way to include
arm_sve.h without any glibc header.

[Bug preprocessor/92919] invalid memory access in wide_str_to_charconst when running ucn2.C testcase (caught by hwasan)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/86416] [OpenMP] Offloading - better lto1 error message if mode not supported on offloading target

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||tschwinge at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #10 from Thomas Schwinge  ---
Thanks for your work on this.


(In reply to Tobias Burnus from comment #8)
> New Revision: 279528

> Added:
> trunk/libgomp/testsuite/libgomp.c/pr86416-1.c
> trunk/libgomp/testsuite/libgomp.c/pr86416-2.c

On powerpc64le-unknown-linux-gnu without offloading, I see both these FAIL,
because: "error: __float128 and long double cannot be used in the same
expression".  ;-O

[Bug fortran/92568] OpenMP 5 - implicit mapping of scalar with TARGET/ALLOCATABLE/POINTER attribute: shall be 'tofrom' mapped

[tschwinge at gcc dot gnu.org]

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

Bug 86416 Summary: [OpenMP] Offloading - better lto1 error message if mode not 
supported on offloading target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86416

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

[Bug preprocessor/92987] -finput-charset is only usable with encodings that are supersets of ASCII

[lhyatt at gmail dot com]

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

--- Comment #2 from Lewis Hyatt  ---
(In reply to jos...@codesourcery.com from comment #1)
> I think -finput-charset may only be usable for character sets that are 
> valid locale character sets (we don't implement the POSIX rule of 
> interpreting source files in the locale encoding), which does mean 
> supersets of ASCII.  And headers provided by one project for use by 
> another indeed do practically need to be ASCII to be maximally portable.

OK thanks. I guess I am confused why charset.c implements conversion functions
for UTF-16 and UTF-32, that can never actually be used without an error, but
sounds like this use case is not important in any case?

[Bug fortran/92996] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7590

[kargl at gcc dot gnu.org]

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

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 ---
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 279444)
+++ gcc/fortran/match.c (working copy)
@@ -3104,9 +3104,9 @@ gfc_match_stopcode (gfc_statement st)
  goto cleanup;
}

-  if (e->rank != 0)
+  if (e->rank != 0 || e->expr_type == EXPR_ARRAY)
{
- gfc_error ("STOP code at %L must be scalar", &e->where);
+ gfc_error ("STOP code at %C must be scalar");
  goto cleanup;
}

[Bug fortran/92996] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7590

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/92996] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7590

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-18
 CC||anlauf at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Funny. Setting a breakpoint in match.c, after

3086  /* Use the machinery for an initialization expression to reduce
the
3087 stop-code to a constant.  */
3088  gfc_init_expr_flag = true;
3089  gfc_reduce_init_expr (e);
3090  gfc_init_expr_flag = false;

I get for case 0 (a(:) is variable):

(gdb) p e->expr_type
$5 = EXPR_VARIABLE
(gdb) p e->rank
$6 = 1

whereas for case 1 (a(:) is parameter):

(gdb) p e->expr_type
$7 = EXPR_ARRAY
(gdb) p e->rank
$8 = 0

How can that happen?

This is the reason it later misses the part:

3107  if (e->rank != 0)
3108{
3109  gfc_error ("STOP code at %L must be scalar", &e->where);
3110  goto cleanup;
3111}

[Bug middle-end/92952] [10 regression] gfortran.dg/lto/pr87689 FAILs at -O2

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

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

[Bug other/92958] [10 regression] gfortran.dg/lto/pr87689_0.f fails starting with r279392

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Martin Sebor  ---
Okay, so let's resolve this as a dupe of pr92952.

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

[Bug target/92905] [10 Regression] Spills float-int union to memory

[vmakarov at gcc dot gnu.org]

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

--- Comment #5 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #3)
> Note, it isn't about , using rm in the first alternative of the
> reverted define_insn works well too, as well as swapping the alternatives
> (that is in that case basically what the trunk has, except in the second
> alternative the second input is rm instead of m.  If the second
> alternative of second input is m,
> it works the same as current trunk (unnecessary spill), if it is rm, it
> works well.
> Now, no idea if this isn't a bug in LRA or if there are some rules that the
> seemingly redundant constraints actually aren't redundant.

The culprit is 'g' vs 'm'.  When we have 'g' matching pseudo assigned to hard
register, LRA ignores memory in 'g' when considering preferred_reload_class.

Reload also treats such situation in analogous way.  And actually LRA adapted
the reload code.

So I can try to solve this PR.  But it will take some time.  Mostly any patch
in this sensitive area should be tested and benchmarked well.

[Bug other/92958] [10 regression] gfortran.dg/lto/pr87689_0.f fails starting with r279392

[seurer at gcc dot gnu.org]

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

--- Comment #3 from seurer at gcc dot gnu.org ---
I don't see the failure in my most current test run

[Bug other/92997] New: [10 regression] gcc.dg/torture/ftrapv-1.c fails starting with r279523

[seurer at gcc dot gnu.org]

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

Bug ID: 92997
   Summary: [10 regression] gcc.dg/torture/ftrapv-1.c fails
starting with r279523
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

# of expected passes15
# of unexpected failures1
FAIL: gcc.dg/torture/ftrapv-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test


Running the failing one in gdb I see:

(gdb) where
#0  0x77c2e98c in __libc_signal_restore_set (set=0x7fffe8e8) at
../sysdeps/unix/sysv/linux/nptl-signals.h:80
#1  __GI_raise (sig=) at ../sysdeps/unix/sysv/linux/raise.c:48
#2  0x77c30be0 in __GI_abort () at abort.c:79
#3  0x16bc in main () at
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/ftrapv-1.c:35


executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/ftrapv-1.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never-O0  -ftrapv
-fno-ipa-vrp  -lm  -o ./ftrapv-1.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/ftrapv-1.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O0 -ftrapv -fno-ipa-vrp -lm
-o ./ftrapv-1.exe
Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/ exceptions_enabled25736.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never  -S -o
exceptions_enabled25736.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/ exceptions_enabled25736.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -S -o
exceptions_enabled25736.s
exceptions_enabled25736.c: In function 'foo':
exceptions_enabled25736.c:4:7: error: 'throw' undeclared (first use in this
function)
exceptions_enabled25736.c:4:7: note: each undeclared identifier is reported
only once for each function it appears in
exceptions_enabled25736.c:4:12: error: expected ';' before numeric constant
compiler exited with status 1
PASS: gcc.dg/torture/ftrapv-1.c   -O0  (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test2/gcc::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.4.0/lib64
Execution timeout is: 300
spawn [open ...]
PASS: gcc.dg/torture/ftrapv-1.c   -O0  execution test
Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/ftrapv-1.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never-O1  -ftrapv
-fno-ipa-vrp  -lm  -o ./ftrapv-1.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/ftrapv-1.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O1 -ftrapv -fno-ipa-vrp -lm
-o ./ftrapv-1.exe
PASS: gcc.dg/torture/ftrapv-1.c   -O1  (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test2/gcc::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.4.0/lib64
Execution timeout is: 300
spawn [open ...]
PASS: gcc.dg/torture/ftrapv-1.c   -O1  execution test
Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/ftrapv-1.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-col

[Bug bootstrap/92661] [10 Regression] Bootstrap failure with builtin-types.def change

[bergner at gcc dot gnu.org]

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

--- Comment #14 from Peter Bergner  ---
Author: bergner
Date: Wed Dec 18 18:46:05 2019
New Revision: 279542

URL: https://gcc.gnu.org/viewcvs?rev=279542&root=gcc&view=rev
Log:
Fix POWER dfp test case target tests.

PR bootstrap/92661
* gcc.target/powerpc/pr92661.c: New test.
* gcc.target/powerpc/dfp-dd.c: Add dg-require-effective-target
hard_dfp.
Remove unneeded powerpc_fprs test.
* gcc.target/powerpc/dfp-td.c: Likewise.
* gcc.target/powerpc/dfp-dd-2.c: Add dg-require-effective-target dfp.
* gcc.target/powerpc/dfp-td-2.c: Likewise.
* gcc.target/powerpc/dfp-td-3.c: Likewise.
* gcc.target/powerpc/dfp/dfp.exp: Remove rs6000-*-* and
powerpc*-*-darwin* target tests.  Add check_effective_target_dfp test.
* gcc.target/powerpc/dfp/dtstsfi-0.c: Remove unneeded target test.
Remove unneeded dg-skip-if.
* gcc.target/powerpc/dfp/dtstsfi-1.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-10.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-11.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-12.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-13.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-14.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-15.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-16.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-17.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-18.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-19.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-2.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-20.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-21.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-22.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-23.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-24.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-25.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-26.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-27.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-28.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-29.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-3.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-30.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-31.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-32.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-33.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-34.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-35.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-36.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-37.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-38.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-39.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-4.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-40.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-41.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-42.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-43.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-44.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-45.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-46.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-47.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-48.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-49.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-5.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-50.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-51.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-52.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-53.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-54.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-55.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-56.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-57.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-58.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-59.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-6.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-60.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-61.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-62.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-63.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-64.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-65.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-66.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-67.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-68.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-69.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-7.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-70.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-71.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-72.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-73.c: Likewise.

[Bug fortran/92996] New: ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7590

[gs...@t-online.de]

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

Bug ID: 92996
   Summary: ICE in gfc_conv_array_constructor_expr, at
fortran/trans-expr.c:7590
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Parameter attribute prevents a check down to at least gcc-5 :


$ cat z0.f90
program p
   integer :: a(2) = [1, 2]
   stop a
end

$ gfortran-10-20191215 -c z0.f90
z0.f90:3:7:

3 |stop a
  |   1
Error: STOP code at (1) must be scalar



$ cat z1.f90
program p
   integer, parameter :: a(2) = [1, 2]
   stop a
end


$ gfortran-10-20191215 -c z1.f90
z1.f90:3:0:

3 |stop a
  |
internal compiler error: in gfc_conv_array_constructor_expr, at
fortran/trans-expr.c:7590
0x75310d gfc_conv_array_constructor_expr
../../gcc/fortran/trans-expr.c:7590
0x75310d gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8681
0x7a4c37 gfc_trans_stop(gfc_code*, bool)
../../gcc/fortran/trans-stmt.c:650
0x70b302 trans_code
../../gcc/fortran/trans.c:1912
0x7424cd gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6801
0x6bc426 translate_all_program_units
../../gcc/fortran/parse.c:6302
0x6bc426 gfc_parse_file()
../../gcc/fortran/parse.c:6541
0x70742f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug c/92995] New: -Wmisleading-indentation and multiline string literals

[palves at redhat dot com]

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

Bug ID: 92995
   Summary: -Wmisleading-indentation and multiline string literals
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: palves at redhat dot com
  Target Milestone: ---

clang 10 caught a misleading indentation in gdb that GCC missed:
  https://sourceware.org/ml/gdb-patches/2019-12/msg00733.html

It appears that the issue is the line continuation in the string literal.
Here's a minimal reproducer:

$ cat indentation.c 
void g (const char *);

void f1 (void)
{
  if (1)
g ("hello\n");
g ("\n"); // warns
}

void f2 (void)
{
  if (1)
g ("hello\
\n");
g ("\n"); // does not warn
}

$ /opt/gcc/bin/gcc -c -Wall indentation.c 
indentation.c: In function ‘f1’:
indentation.c:5:3: warning: this ‘if’ clause does not guard...
[-Wmisleading-indentation]
5 |   if (1)
  |   ^~
indentation.c:7:5: note: ...this statement, but the latter is misleadingly
indented as if it were guarded by the ‘if’
7 | g ("\n"); // warns
  | ^

$ /opt/gcc/bin/gcc --version
gcc (GCC) 10.0.0 20191218 (experimental)

[Bug fortran/92994] [10 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:486

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---

Also related :


$ cat z6.f90
subroutine s
   associate (y => (s))
   end associate
end


$ cat z7.f90
program p
   associate (y => (p))
   end associate
end


They are older (down to gcc-7), and produce different backtraces, e.g.

$ gfortran-6 -c z6.f90
z6.f90:2:14:

associate (y => (s))
  1
Error: Expected association at (1)
z6.f90:3:6:

end associate
  1
Error: Expecting END SUBROUTINE statement at (1)


$ gfortran-10-20191215 -c z6.f90
z6.f90:2:20:

2 |associate (y => (s))
  |1
Warning: Non-RECURSIVE procedure 's' at (1) is possibly calling itself
recursively.  Declare it RECURSIVE or use '-frecursive'
z6.f90:2:0:

2 |associate (y => (s))
  |
internal compiler error: in fold_convert_loc, at fold-const.c:2436
0x8cee27 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2435
0x705ac9 gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:9667
0x7170cd gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:11051
0x743b7c trans_associate_var
../../gcc/fortran/trans-stmt.c:2170
0x74a221 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:2283
0x6d6d37 trans_code
../../gcc/fortran/trans.c:1960
0x700124 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6801
0x6891b6 translate_all_program_units
../../gcc/fortran/parse.c:6302
0x6891b6 gfc_parse_file()
../../gcc/fortran/parse.c:6541
0x6d365f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/92994] New: [10 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:486

[gs...@t-online.de]

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

Bug ID: 92994
   Summary: [10 Regression] ICE in gfc_get_class_from_expr, at
fortran/trans-expr.c:486
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Followup of pr92780, changed between 20190922 and 20190929 :


$ cat z1.f90
function f() result(z)
   associate (y => f)
   end associate
end


$ cat z2.f90
program p
   type t
   end type
   type(t) :: z = t()
   associate (y => t)
   end associate
end


$ cat z3.f90
program p
   procedure() :: g
   associate (y => g)
   end associate
end


$ cat z4.f90
program p
   external :: g
   associate (y => g)
   end associate
end


$ cat z5.f90
subroutine s
   associate (y => s)
   end associate
end


$ gfortran-10-20190922 -c z2.f90  # accepts invalid
$
$ gfortran-10-20191215 -c z2.f90
z2.f90:2:0:

2 |type t
  |
internal compiler error: tree check: expected class 'expression', have
'declaration' (function_decl) in tree_operand_check, at tree.h:3771
0x5eebfa tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.c:9735
0x7473d9 expr_check(tree_node*, char const*, int, char const*)
../../gcc/tree.h:3442
0x7473d9 tree_operand_check(tree_node*, int, char const*, int, char const*)
../../gcc/tree.h:3771
0x7473d9 gfc_get_class_from_expr(tree_node*)
../../gcc/fortran/trans-expr.c:484
0x7a0c82 trans_associate_var
../../gcc/fortran/trans-stmt.c:2100
0x7a7519 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:2283
0x70b137 trans_code
../../gcc/fortran/trans.c:1960
0x7424cd gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6801
0x6bc426 translate_all_program_units
../../gcc/fortran/parse.c:6302
0x6bc426 gfc_parse_file()
../../gcc/fortran/parse.c:6541
0x70742f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/87908] [PDT] ICE in check_interface0, at fortran/interface.c:1841

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
   Last reconfirmed|2018-11-06 00:00:00 |2019-12-18
 CC||anlauf at gcc dot gnu.org
Summary|ICE in check_interface0, at |[PDT] ICE in
   |fortran/interface.c:1841|check_interface0, at
   ||fortran/interface.c:1841
  Known to fail||10.0

--- Comment #3 from anlauf at gcc dot gnu.org ---
I think this is an ICE-on-valid.

Moving subroutine s after g makes the ICE go away.

One of several resolution issues?

[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #7)
> So, are you going to post a patch for that?

I dont have time to work on it right now.

[Bug fortran/92993] New: ICE in maybe_canonicalize_comparison_1, at fold-const.c:8845

[gs...@t-online.de]

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

Bug ID: 92993
   Summary: ICE in maybe_canonicalize_comparison_1, at
fold-const.c:8845
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With an interface mismatch, down to at least version 5 :


$ cat z1.f90
function f(x)
   integer, intent(in) :: x
   integer :: f
   f = x
end
program p
   interface
  function f(x)
 integer, intent(in) :: x
 integer, pointer :: f
  end
   end interface
   integer :: a(2) = [1, 2]
   if ( a(2) /= f(a(2)) ) stop
end


$ gfortran-10-20191215 -c z1.f90
z1.f90:8:6:

8 |   function f(x)
  |  1
Warning: Interface mismatch in global procedure 'f' at (1): POINTER attribute
mismatch in function result
z1.f90:14:0:

   14 |if ( a(2) /= f(a(2)) ) stop
  |
internal compiler error: Segmentation fault
0xb8147f crash_signal
../../gcc/toplev.c:328
0x8d2884 maybe_canonicalize_comparison_1
../../gcc/fold-const.c:8845
0x8d2f05 maybe_canonicalize_comparison
../../gcc/fold-const.c:8935
0x8d2f05 fold_comparison
../../gcc/fold-const.c:9354
0x8c7516 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:11144
0x8cccfa fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:12883
0x707469 gfc_conv_expr_op
../../gcc/fortran/trans-expr.c:3627
0x707469 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8653
0x70a013 gfc_conv_expr_val(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8710
0x7421e9 gfc_trans_if_1
../../gcc/fortran/trans-stmt.c:1442
0x749cca gfc_trans_if(gfc_code*)
../../gcc/fortran/trans-stmt.c:1480
0x6d6cc7 trans_code
../../gcc/fortran/trans.c:1952
0x700124 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6801
0x6891b6 translate_all_program_units
../../gcc/fortran/parse.c:6302
0x6891b6 gfc_parse_file()
../../gcc/fortran/parse.c:6541
0x6d365f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
So, are you going to post a patch for that?

[Bug other/92958] [10 regression] gfortran.dg/lto/pr87689_0.f fails starting with r279392

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-12-18
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
This looks the same as pr92952 that I fixed just yesterday.  The test passed in
my x86_64-linux build and I don't see it fail in today's posts to
gcc-testresults (either powerpc64* or x86_64*).  Can you confirm it really
still fails?

[Bug preprocessor/92987] -finput-charset is only usable with encodings that are supersets of ASCII

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
On Wed, 18 Dec 2019, lhyatt at gmail dot com wrote:

> I was about to work on adding support for -finput-charset into diagnostics
> infrastructure (it currently ignores it), however it seems like this issue
> should probably be dealt with first, since it may entail adding the notion 
> that
> different source files have a different input encoding. I am not sure what
> would be the desired way to address it. Are there use cases where it is
> desirable that -finput-charset applies to the #includes too (I guess systems

Presumably headers in the user's own project might be in the specified 
character set.

> could exist where the system headers are not ASCII)? Would it make sense to 
> add
> a new option that changed the charset only for source files, and not the
> #includes? Or maybe it should be kept for "..." includes and not for <...> or
> something like this?

Plenty of code does e.g. #include "stdio.h" rather than using <>.

I think -finput-charset may only be usable for character sets that are 
valid locale character sets (we don't implement the POSIX rule of 
interpreting source files in the locale encoding), which does mean 
supersets of ASCII.  And headers provided by one project for use by 
another indeed do practically need to be ASCII to be maximally portable.

[Bug other/92958] [10 regression] gfortran.dg/lto/pr87689_0.f fails starting with r279392

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Thomas Koenig  ---
Also seen on x86_64-pc-linux-gnu.

[Bug c++/92992] Side-effects dropped when decltype(nullptr) typed expression is passed to ellipsis

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 47522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47522&action=edit
gcc10-pr92992.patch

Untested fix.

[Bug c++/92666] [10 Regression] bogus -Wunused-but-set-variable in gcov.c with -Wno-restrict

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Created attachment 47521
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47521&action=edit
gcc10-pr92666.patch

Untested fix.  Code inspection revealed a wrong-code bug too.

[Bug fortran/92785] expressions passed as real arguments to a dummy polymorphic argument fail with indexing error

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-18
 CC||anlauf at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||10.0, 7.4.1, 8.3.1, 9.2.1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

I think there are related PRs where the passed array descriptor is not
set correctly.

[Bug other/92958] [10 regression] gfortran.dg/lto/pr87689_0.f fails starting with r279392

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org
   Target Milestone|--- |10.0

[Bug c++/92986] ODR violation not detected

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
We could in theory save the tokens of each method and compare them, but it
would be quite costly.
Normally people don't cut'n'paste classes between TUs, but rather just declare
them once in a header they include multiple times, so it is certainly not a
common scenario.

[Bug c++/92992] Side-effects dropped when decltype(nullptr) typed expression is passed to ellipsis

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-12-18
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/92992] New: Side-effects dropped when decltype(nullptr) typed expression is passed to ellipsis

[jakub at gcc dot gnu.org]

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

Bug ID: 92992
   Summary: Side-effects dropped when decltype(nullptr) typed
expression is passed to ellipsis
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

GCC 4.6 and later miscompiles:
int a;

void
bar (int, ...)
{
}

decltype (nullptr)
baz ()
{
  a++;
  return nullptr;
}

int
main ()
{
  bar (0, baz ());
  if (a != 1)
__builtin_abort ();
}

We replace the baz () call with nullptr even when it has side-effects.

[Bug c++/92986] ODR violation not detected

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
Yes, this is a vague linkage function so as jakub mentioned, comparing the ir
even between optimization levels is hard.  Yes we could in theory it could be
done but for gcc, it would mean ripping up most of the compiler

[Bug preprocessor/92982] cpp_string_location_reader :: m_line_table seems redundant ?

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Thanks; should be fixed on trunk by r279541.

[Bug c++/92986] ODR violation not detected

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Yes, you haven't read my comment which explained what -Wodr does and doesn't
and why.

[Bug preprocessor/92982] cpp_string_location_reader :: m_line_table seems redundant ?

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Author: dmalcolm
Date: Wed Dec 18 17:26:01 2019
New Revision: 279541

URL: https://gcc.gnu.org/viewcvs?rev=279541&root=gcc&view=rev
Log:
Drop unused member from cpp_string_location_reader (PR preprocessor/92982)

libcpp/ChangeLog:
PR preprocessor/92982
* charset.c
(cpp_string_location_reader::cpp_string_location_reader): Delete
initialization of m_line_table.
* include/cpplib.h (cpp_string_location_reader::m_line_table):
Delete unused member.


Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/charset.c
trunk/libcpp/include/cpplib.h

[Bug c++/92986] ODR violation not detected

[geeteshmore at gmail dot com]

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

--- Comment #4 from Geetesh More  ---
I tried with -flto, but I'm not seeing any warning messages:
g++ -std=c++0x -g -flto -Wodr main.cpp file2.cpp

Am I missing anything here?

[Bug testsuite/92991] New: [10 regression] g++.dg/ubsan/vptr-4.C fails starting with r279473

[seurer at gcc dot gnu.org]

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

Bug ID: 92991
   Summary: [10 regression] g++.dg/ubsan/vptr-4.C fails starting
with r279473
   Product: gcc
   Version: 10.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/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ubsan/vptr-4.C
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test/powerpc64-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 -fmessage-length=0 -O0
-std=c++11 -fsanitize=vptr -S -o vptr-4.s
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ubsan/vptr-4.C: In member
function 'constexpr const T* T::foo() const':
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ubsan/vptr-4.C:18:49: error:
'reinterpret_cast' is not a constant expression
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ubsan/vptr-4.C: At global scope:
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ubsan/vptr-4.C:22:30: error:
'constexpr const T* T::foo() const' called in a constant expression
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ubsan/vptr-4.C:18:22: note:
'constexpr const T* T::foo() const' declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ubsan/vptr-4.C:42:35: error:
'constexpr const W* W::foo() const [with U = int]' called in a constant
expression
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ubsan/vptr-4.C:38:25: note:
'constexpr const W* W::foo() const [with U = int]' is not usable as a
'constexpr' function because:
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ubsan/vptr-4.C:38:55: error:
'reinterpret_cast' is not a constant expression
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ubsan/vptr-4.C: In instantiation
of 'int foo() [with U = char]':
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ubsan/vptr-4.C:54:21:   required
from here
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ubsan/vptr-4.C:48:39: error:
'constexpr const T* T::foo() const' called in a constant expression
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ubsan/vptr-4.C:18:22: note:
'constexpr const T* T::foo() const' declared here
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ubsan/vptr-4.C:50:42: error:
'constexpr const W* W::foo() const [with U = char]' called in a constant
expression
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ubsan/vptr-4.C:38:25: note:
'constexpr const W* W::foo() const [with U = char]' is not usable as a
'constexpr' function because:
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ubsan/vptr-4.C:38:55: error:
'reinterpret_cast' is not a constant expression
compiler exited with status 1
PASS: g++.dg/ubsan/vptr-4.C   -O0   (test for errors, line 18)
PASS: g++.dg/ubsan/vptr-4.C   -O0   (test for errors, line 22)
PASS: g++.dg/ubsan/vptr-4.C   -O0   (test for errors, line 42)
PASS: g++.dg/ubsan/vptr-4.C   -O0   (test for errors, line 48)
PASS: g++.dg/ubsan/vptr-4.C   -O0   (test for errors, line 50)
Executing on host: /home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../
exceptions_enabled9250.c-fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never 
-fdiagnostics-urls=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test/powerpc64-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 -fmessage-length=0  -S
-o exceptions_enabled9250.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../
exceptions_enabled9250.c -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test/powerpc64-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 -fmessage-length=0 -S
-o exceptions_enabled9250.s
FAIL: g++.dg/ubsan/vptr-4.C  

[Bug c++/92986] ODR violation not detected

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
-Wodr only works with -flto.

Anything is too hard to implement and get right.

[Bug tree-optimization/92765] [10 Regression] Wrong code caused by folding of -Wstring-compare since r276773

[law at redhat dot com]

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

--- Comment #19 from Jeffrey A. Law  ---
Note that while the code in this BZ may or may not be valid, there is certainly
code in the wild which is incorrectly compiled as a result of Qing's patch
which uses TYPE_SIZE.  In particular the flatbuffers and acpica-tools package
in Fedora is mis-compiled due to this issue (there may be others).   See the
link in c#8.

[Bug libgomp/92984] [OpenACC] Semantics of 'acc_delete' etc. with size zero

[tschwinge at gcc dot gnu.org]

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

--- Comment #2 from Thomas Schwinge  ---
Author: tschwinge
Date: Wed Dec 18 17:01:11 2019
New Revision: 279532

URL: https://gcc.gnu.org/viewcvs?rev=279532&root=gcc&view=rev
Log:
[PR92726, PR92970, PR92984] [OpenACC] Clarify 'acc_delete' etc. for 'NULL'-in,
non-present data, or size zero

PR92970 "OpenACC 2.5: 'acc_delete' etc. on non-present data is a no-op" is an
actual bug fix, and the other ones are fall-out, currently undefined behavior.

libgomp/
PR libgomp/92726
PR libgomp/92970
PR libgomp/92984
* oacc-mem.c (delete_copyout): No-op behavior if 'lookup_host'
fails.
(GOACC_enter_exit_data): Simplify accordingly.
* testsuite/libgomp.oacc-c-c++-common/pr92970-1.c: New file,
subsuming...
* testsuite/libgomp.oacc-c-c++-common/lib-17.c: ... this file...
* testsuite/libgomp.oacc-c-c++-common/lib-18.c: ..., and this
file.
* testsuite/libgomp.oacc-c-c++-common/pr92984-1.c: New file,
subsuming...
* testsuite/libgomp.oacc-c-c++-common/lib-21.c: ... this file...
* testsuite/libgomp.oacc-c-c++-common/lib-29.c: ..., and this
file.
* testsuite/libgomp.oacc-c-c++-common/pr92726-1.c: New file,
subsuming...
* testsuite/libgomp.oacc-c-c++-common/lib-28.c: ... this file.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92726-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92970-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92984-1.c
Removed:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-17.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-18.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-21.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-28.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-29.c
Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/oacc-mem.c

[Bug libgomp/92970] OpenACC 2.5: 'acc_delete' etc. on non-present data is a no-op

[tschwinge at gcc dot gnu.org]

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

--- Comment #2 from Thomas Schwinge  ---
Author: tschwinge
Date: Wed Dec 18 17:01:11 2019
New Revision: 279532

URL: https://gcc.gnu.org/viewcvs?rev=279532&root=gcc&view=rev
Log:
[PR92726, PR92970, PR92984] [OpenACC] Clarify 'acc_delete' etc. for 'NULL'-in,
non-present data, or size zero

PR92970 "OpenACC 2.5: 'acc_delete' etc. on non-present data is a no-op" is an
actual bug fix, and the other ones are fall-out, currently undefined behavior.

libgomp/
PR libgomp/92726
PR libgomp/92970
PR libgomp/92984
* oacc-mem.c (delete_copyout): No-op behavior if 'lookup_host'
fails.
(GOACC_enter_exit_data): Simplify accordingly.
* testsuite/libgomp.oacc-c-c++-common/pr92970-1.c: New file,
subsuming...
* testsuite/libgomp.oacc-c-c++-common/lib-17.c: ... this file...
* testsuite/libgomp.oacc-c-c++-common/lib-18.c: ..., and this
file.
* testsuite/libgomp.oacc-c-c++-common/pr92984-1.c: New file,
subsuming...
* testsuite/libgomp.oacc-c-c++-common/lib-21.c: ... this file...
* testsuite/libgomp.oacc-c-c++-common/lib-29.c: ..., and this
file.
* testsuite/libgomp.oacc-c-c++-common/pr92726-1.c: New file,
subsuming...
* testsuite/libgomp.oacc-c-c++-common/lib-28.c: ... this file.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92726-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92970-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92984-1.c
Removed:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-17.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-18.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-21.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-28.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-29.c
Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/oacc-mem.c

[Bug libgomp/92726] OpenACC: 'NULL'-in -> no-op, and/or 'NULL'-out

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Wed Dec 18 17:01:11 2019
New Revision: 279532

URL: https://gcc.gnu.org/viewcvs?rev=279532&root=gcc&view=rev
Log:
[PR92726, PR92970, PR92984] [OpenACC] Clarify 'acc_delete' etc. for 'NULL'-in,
non-present data, or size zero

PR92970 "OpenACC 2.5: 'acc_delete' etc. on non-present data is a no-op" is an
actual bug fix, and the other ones are fall-out, currently undefined behavior.

libgomp/
PR libgomp/92726
PR libgomp/92970
PR libgomp/92984
* oacc-mem.c (delete_copyout): No-op behavior if 'lookup_host'
fails.
(GOACC_enter_exit_data): Simplify accordingly.
* testsuite/libgomp.oacc-c-c++-common/pr92970-1.c: New file,
subsuming...
* testsuite/libgomp.oacc-c-c++-common/lib-17.c: ... this file...
* testsuite/libgomp.oacc-c-c++-common/lib-18.c: ..., and this
file.
* testsuite/libgomp.oacc-c-c++-common/pr92984-1.c: New file,
subsuming...
* testsuite/libgomp.oacc-c-c++-common/lib-21.c: ... this file...
* testsuite/libgomp.oacc-c-c++-common/lib-29.c: ..., and this
file.
* testsuite/libgomp.oacc-c-c++-common/pr92726-1.c: New file,
subsuming...
* testsuite/libgomp.oacc-c-c++-common/lib-28.c: ... this file.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92726-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92970-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92984-1.c
Removed:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-17.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-18.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-21.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-28.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-29.c
Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/oacc-mem.c

[Bug libgomp/92848] [OpenACC] Memory leak for simple 'acc_create', 'acc_delete' sequence

[tschwinge at gcc dot gnu.org]

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

--- Comment #8 from Thomas Schwinge  ---
Author: tschwinge
Date: Wed Dec 18 17:00:39 2019
New Revision: 279530

URL: https://gcc.gnu.org/viewcvs?rev=279530&root=gcc&view=rev
Log:
[PR92848] [OpenACC] Use 'GOMP_MAP_VARS_ENTER_DATA' for dynamic data lifetimes

libgomp/
PR libgomp/92848
* oacc-mem.c (acc_map_data, present_create_copy)
(goacc_insert_pointer): Use 'GOMP_MAP_VARS_ENTER_DATA'.
(acc_unmap_data, delete_copyout, goacc_remove_pointer): Adjust.
* testsuite/libgomp.oacc-c-c++-common/lib-50.c: Remove.
* testsuite/libgomp.oacc-c-c++-common/pr92848-1-d-a.c: New file
* testsuite/libgomp.oacc-c-c++-common/pr92848-1-d-p.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/pr92848-1-r-a.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/pr92848-1-r-p.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/subset-subarray-mappings-1-r-p.c:
Remove "XFAIL"s.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92848-1-d-a.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92848-1-d-p.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92848-1-r-a.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92848-1-r-p.c
Removed:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-50.c
Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/oacc-mem.c
   
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/subset-subarray-mappings-1-r-p.c

[Bug middle-end/86416] [OpenMP] Offloading - better lto1 error message if mode not supported on offloading target

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #9 from Tobias Burnus  ---
First issue was:
   lto1: fatal error: unsupported mode TF

Namely, a not that readable error message if a mode is not supported. (Here:
'complex(kind=16)' which is a float128-type complex number, which is only
supported on the host but not on the device (nvptx/Nvidia).)

[Side remark: The user intended complex*16 = complex(kind=8) = double-precision
complex.]

This now gives a message such as:

lto1: fatal error: nvptx-none - 128-bit-precision floating-point numbers
unsupported (mode 'TF')

Which is better readable. → FIXED by the commit r279528 of comment 8.


The second issue was:
  CHARACTER default mapping didn't match the spec for 'scalar'

Well, OpenMP's terminology states that Fortran CHARACTER aren't scalars. Hence:
→ INVALID

As all issues are resolved, I close the bug. – Thanks for implicit suggestion
to improve the error message!

[Bug fortran/92568] OpenMP 5 - implicit mapping of scalar with TARGET/ALLOCATABLE/POINTER attribute: shall be 'tofrom' mapped

[burnus at gcc dot gnu.org]

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

Bug 86416 Summary: [OpenMP] Offloading - better lto1 error message if mode not 
supported on offloading target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86416

   What|Removed |Added

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

[Bug middle-end/86416] [OpenMP] Offloading - better lto1 error message if mode not supported on offloading target

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  ---
Author: burnus
Date: Wed Dec 18 16:51:08 2019
New Revision: 279528

URL: https://gcc.gnu.org/viewcvs?rev=279528&root=gcc&view=rev
Log:
PR 86416 – improve lto1 diagnostic if a mode does not exist

PR middle-end/86416
*  Makefile.in (CFLAGS-lto-streamer-in.o): Pass target_noncanonical on.
* lto-streamer-in.c (lto_input_mode_table): Improve unsupported-mode
diagnostic.

PR middle-end/86416
* testsuite/libgomp.c/pr86416-1.c: New.
* testsuite/libgomp.c/pr86416-2.c: New.


Added:
trunk/libgomp/testsuite/libgomp.c/pr86416-1.c
trunk/libgomp/testsuite/libgomp.c/pr86416-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/lto-streamer-in.c
trunk/libgomp/ChangeLog

[Bug fortran/92990] New: INVALID code with NULLIFY – partially misleading error message "If bounds remapping is specified at (1), the pointer target shall not be NULL"

[burnus at gcc dot gnu.org]

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

Bug ID: 92990
   Summary: INVALID code with NULLIFY – partially misleading error
message "If bounds remapping is specified at (1), the
pointer target shall not be NULL"
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: anlauf at gcc dot gnu.org
  Target Milestone: ---

Follow up to https://gcc.gnu.org/ml/fortran/2019-12/msg00161.html / patch for
PR70853 (r279527):

The following variant now no longer gives an ICE, but there is room for
improvement for the error message. Internally "=> NULL()" and NULLIFY are the
same – and the issue is also the same. Still, the message is somewhat puzzling.

Possibly, this can already be handled in gfc_match_nullify?

x.f90:2:8:

2 | nullify(x(1:1))
  |1
Error: If bounds remapping is specified at (1), the pointer target shall
not be NULL

As Harald wrote: "For a better error message, we'd need to know that we come
here from a NULLIFY statement."


Test case:

integer, pointer, contiguous :: x(:)
nullify(x(1:1))
end

[Bug fortran/70853] ICE on pointing to null, in gfc_add_block_to_block, at fortran/trans.c:1599

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Fixed.  Thanks for the report!

As Tobias Burnus noticed, this fixes a related ICE with NULLIFY.

[Bug fortran/70853] ICE on pointing to null, in gfc_add_block_to_block, at fortran/trans.c:1599

[anlauf at gcc dot gnu.org]

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Wed Dec 18 16:34:06 2019
New Revision: 279527

URL: https://gcc.gnu.org/viewcvs?rev=279527&root=gcc&view=rev
Log:
2019-12-18  Harald Anlauf  

PR fortran/70853
* trans-expr.c (gfc_trans_pointer_assignment): Reject bounds
remapping if pointer target is NULL().

PR fortran/70853
* gfortran.dg/pr70853.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr70853.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug inline-asm/92597] std::fma gives nan using -march=sandybridge+ with asm volatile

[leppkes at stce dot rwth-aachen.de]

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

--- Comment #16 from Klaus Leppkes  ---
So after reading a bit more, from my understanding, +g should be used for all
integral/floating point/vector types and +m for other (aggregate types) which
cannot end up in an register.

Still, it might be possible for an aggregate type like
struct mycomplex {
 double v1;
 double v2;
};

to end up in SSE register, right?

[Bug rtl-optimization/92989] New: The mips-mti-linux-gnu fails to build after r276327

[dragan.mladjeno...@rt-rk.com]

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

Bug ID: 92989
   Summary: The mips-mti-linux-gnu fails to build after r276327
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: build, ice-checking
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dragan.mladjeno...@rt-rk.com
CC: richard.sandiford at arm dot com
  Target Milestone: ---
Target: mips-mti-linux-gnu

Created attachment 47520
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47520&action=edit
Prepossessed reproducer

Failure happens during mips16 multilib libstdc++ build. It can be reproduced in
a quick way via mipsisa64-elf on current trunk(r279523):

~./gcc/xgcc -B./gcc  -std=gnu++98 -fno-implicit-templates  -O2  -mips16  -x c++
locale.i -fPIC -mabi=32 -mabicalls  -mexplicit-relocs -mno-gpopt -c -o 
locale.o
during RTL pass: reload
/media/draganm/NewDisk/workarea_back/src/gcc/libstdc++-v3/src/c++98/locale.cc:
In member function ‘void std::locale::_Impl::_M_install_cache(const
std::locale::facet*, std::size_t)’:
/media/draganm/NewDisk/workarea_back/src/gcc/libstdc++-v3/src/c++98/locale.cc:471:3:
internal compiler error: in lra_assign, at lra-assigns.c:1646
  471 |   }
  |   ^
0xccc370 lra_assign(bool&)
../../src/gcc/gcc/lra-assigns.c:1646
0xcc6574 lra(_IO_FILE*)
../../src/gcc/gcc/lra.c:2487
0xc78069 do_reload
../../src/gcc/gcc/ira.c:5518
0xc78069 execute
../../src/gcc/gcc/ira.c:5704
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/70853] ICE on pointing to null, in gfc_add_block_to_block, at fortran/trans.c:1599

[anlauf at gcc dot gnu.org]

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Patch with slightly more user-friendly error message:

https://gcc.gnu.org/ml/fortran/2019-12/msg00159.html

[Bug ipa/92971] Suspicious code in cgraph_edge_brings_all_agg_vals_for_node(), ipa-cp.c

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Jambor  ---
Fixed.

[Bug ipa/92971] Suspicious code in cgraph_edge_brings_all_agg_vals_for_node(), ipa-cp.c

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
Author: jamborm
Date: Wed Dec 18 16:08:09 2019
New Revision: 279525

URL: https://gcc.gnu.org/viewcvs?rev=279525&root=gcc&view=rev
Log:
IPA-CP: Remove bogus static keyword (PR 92971)

2019-12-18  Martin Jambor  

PR ipa/92971
* ipa-cp.c (cgraph_edge_brings_all_agg_vals_for_node): Fix
  definition of values, release memory on exit.

testsuite/
* gcc.dg/ipa/ipcp-agg-12.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/ipa/ipcp-agg-12.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/testsuite/ChangeLog

[Bug libgcc/92988] New: crtstuff.c:387:21: error: '__dso_handle' undeclared (first use in this function)

[danglin at gcc dot gnu.org]

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

Bug ID: 92988
   Summary: crtstuff.c:387:21: error: '__dso_handle' undeclared
(first use in this function)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: jozef.l at somniumtech dot com
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

/test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/
-B/opt/gnu64/gcc/g
cc-10/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-10/hppa64-hp-hpux11.11/lib/
-isystem /opt/gnu64/gcc/gcc-10/hppa64-hp-hpux11.11/include -isystem
/opt/gnu64/g
cc/gcc-10/hppa64-hp-hpux11.11/sys-include   -fno-checking -g -O2 -O2 -g -O2
-DIN
_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wstrict
-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include 
-I.
 -I. -I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/.
-I../../../gcc/
libgcc/../gcc -I../../../gcc/libgcc/../include   -g0  -finhibit-size-directive
-fno-inline -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder
-fno-tree-vectorize -fbuilding-libgcc -fno-stack-protector-I. -I.
-I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/.
-I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include  -o crtbeginS.o
-MT crtbeginS.o -MD -MP -MF crtbeginS.dep  -c ../../../gcc/libgcc/crtstuff.c
-DCRT_BEGIN -DCRTSTUFFS_O
../../../gcc/libgcc/crtstuff.c: In function '__do_global_dtors_aux':
../../../gcc/libgcc/crtstuff.c:386:7: warning: the address of '__cxa_finalize'
will always evaluate as 'true' [-Waddress]
  386 |   if (__cxa_finalize)
  |   ^~
../../../gcc/libgcc/crtstuff.c:387:21: error: '__dso_handle' undeclared (first
use in this function)
  387 | __cxa_finalize (__dso_handle);
  | ^~~~
../../../gcc/libgcc/crtstuff.c:387:21: note: each undeclared identifier is
reported only once for each function it appears in
../../../gcc/libgcc/crtstuff.c:430:7: warning: the address of
'__deregister_frame_info' will always evaluate as 'true' [-Waddress]
  430 |   if (__deregister_frame_info)
  |   ^~~
../../../gcc/libgcc/crtstuff.c: In function 'frame_dummy':
../../../gcc/libgcc/crtstuff.c:482:7: warning: the address of
'__register_frame_info' will always evaluate as 'true' [-Waddress]
  482 |   if (__register_frame_info)
  |   ^
Makefile:1031: recipe for target 'crtbeginS.o' failed
make[3]: *** [crtbeginS.o] Error 1

[Bug c++/92986] ODR violation not detected

[geeteshmore at gmail dot com]

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

--- Comment #2 from Geetesh More  ---
But compiler should be throwing some message/warning about declaration of same
class in multiple files. This is common scenario in cases where a class is
copied in multiple files.

[Bug preprocessor/92987] New: -finput-charset is only usable with encodings that are supersets of ASCII

[lhyatt at gmail dot com]

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

Bug ID: 92987
   Summary: -finput-charset is only usable with encodings that are
supersets of ASCII
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lhyatt at gmail dot com
  Target Milestone: ---

-finput-charset supports converting all encodings supported by iconv, and also
UTF-32 and UTF-16 are supported directly with routines in libcpp/charset.c.
However, -finput-charset does not seem to actually be usable unless the chosen
encoding is a superset of ASCII, because it applies to all header files
included from the source as well. Even an empty source file implicitly includes
/usr/include/stdc-predef.h, and so there is nothing that can be compiled with
say -finput-charset=UTF-32LE:

$ echo -n > t.c
$ gcc -S -finput-charset=UTF-32LE t.c
cc1: error: failure to convert UTF-32LE to UTF-8

The error comes while processing stdc-predef.h.

I was about to work on adding support for -finput-charset into diagnostics
infrastructure (it currently ignores it), however it seems like this issue
should probably be dealt with first, since it may entail adding the notion that
different source files have a different input encoding. I am not sure what
would be the desired way to address it. Are there use cases where it is
desirable that -finput-charset applies to the #includes too (I guess systems
could exist where the system headers are not ASCII)? Would it make sense to add
a new option that changed the charset only for source files, and not the
#includes? Or maybe it should be kept for "..." includes and not for <...> or
something like this?

-Lewis

[Bug preprocessor/92982] cpp_string_location_reader :: m_line_table seems redundant ?

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-12-18
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Good catch; I think this must be a hangover from when I was developing this
code.

[Bug c++/92986] ODR violation not detected

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The compiler doesn't see both TUs at the same time, so how could it warn?  The
standard certainly doesn't require diagnostics for this.
Even if the compiler sees both, such as with -flto, it will warn with -Wodr
about cases where e.g. classes have the same name and different content, but it
can't really check whether the content of the methods is the same - at the
point where the bodies are streamed they are through several optimization
passes and so quite impossible to detect if they originally were the same (they
could be built with different optimization options ...).

[Bug c++/88848] member ambiguous in multiple inheritance lattice

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-18
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Confirmed, still doesn't compile.

[Bug target/92865] [10 Regression] error: unrecognizable insn: in extract_insn, at recog.c:2294 since r279107

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

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

[Bug c++/92986] New: ODR violation not detected

[geeteshmore at gmail dot com]

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

Bug ID: 92986
   Summary: ODR violation not detected
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geeteshmore at gmail dot com
  Target Milestone: ---

Hi,

I've a testcase where a class with same name is called in multiple files.
However, depending on the order of compile, output is different.

Compiler is unable to detect the One Defination Rule Violation here.

Testcase:

++File2.cpp
//file2.cpp

#include 
using namespace std; 

class Radiator
{
public:
string fileName()
{   
return "File2.cpp";
}   
};

void print()
{
Radiator rad;
cout<<" Calling Class Radiator from File: " << rad.fileName() << endl;
}
main.cpp++

// The main module

#include 
using namespace std; 

class Radiator
{
public:
string fileName()
{   
return "Main.cpp";
}   
};

void main_print()
{
Radiator rad;
cout<<" Calling Class Radiator from File: " << rad.fileName() << endl;
}

int main()
{
main_print();
return 0;
}
+

Now when i compile :
g++ -std=c++0x -g file2.cpp main.cpp
 I get following Output, which is not what I expected:
Calling Class Radiator from File: File2.cpp

But when i compile :
g++ -std=c++0x -g main.cpp file2.cpp
 I get following correct Outputd:
Calling Class Radiator from File: Main.cpp

I tried using "-Wodr" but still i got no warnings.

[Bug fortran/92977] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3526

[jakub at gcc dot gnu.org]

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

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 47519
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47519&action=edit
gcc10-pr92977.patch

Untested fix.  For atomic, in some cases it might work to actually insert the
BLOCK around the whole atomic, but it would be quite non-trivial with the way
it works now.

[Bug c++/92985] missed optimization opportunity for switch linear transformation

[pdimov at gmail dot com]

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

--- Comment #2 from Peter Dimov  ---
Two more reformulations that activate the linear transformation are:

int operator[]( std::size_t i ) const noexcept
{
std::ptrdiff_t offset;

switch( i )
{
case 0: offset = offsetof(X, x); break;
case 1: offset = offsetof(X, y); break;
case 2: offset = offsetof(X, z); break;
default: __builtin_unreachable();
}

return *(int const*)((char const*)this + offset);
}

(https://godbolt.org/z/cJDB_m)

and

int operator[]( std::size_t i ) const noexcept
{
int X::* p;

switch( i )
{
case 0: p = &X::x; break;
case 1: p = &X::y; break;
case 2: p = &X::z; break;
default: __builtin_unreachable();
}

return this->*p;
}

(https://godbolt.org/z/xfsKh5)

[Bug c++/92985] missed optimization opportunity for switch linear transformation

[pdimov at gmail dot com]

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

--- Comment #1 from Peter Dimov  ---
Reformulating the switch in terms of integral offsets

struct X2
{
int x, y, z;

int operator[]( std::size_t i ) const noexcept
{
std::ptrdiff_t k0 = &x - &x;
std::ptrdiff_t k1 = &y - &x;
std::ptrdiff_t k2 = &z - &x;

std::ptrdiff_t k;

switch( i )
{
case 0: k = k0; break;
case 1: k = k1; break;
case 2: k = k2; break;
default: __builtin_unreachable();
}

return *( &x + k );
}
};

results in the desired

f2(X2 const&, unsigned long):
mov eax, DWORD PTR [rdi+rsi*4]
ret

(https://godbolt.org/z/YxhNSx)

[Bug c++/92985] New: missed optimization opportunity for switch linear transformation

[barry.revzin at gmail dot com]

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

Bug ID: 92985
   Summary: missed optimization opportunity for switch linear
transformation
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

From Peter Dimov on Slack:

#include 

struct X
{
int x, y, z;

int operator[]( std::size_t i ) const noexcept
{
switch( i )
{
case 0: return x;
case 1: return y;
case 2: return z;
default: __builtin_unreachable();
}
}
};

int f( X const& x, std::size_t i )
{
return x[ i ];
}

compiled with -O2 (or -O3) emits:

f(X const&, unsigned long):
cmp rsi, 1
je  .L2
cmp rsi, 2
jne .L6
mov eax, DWORD PTR [rdi+8]
ret
.L2:
mov eax, DWORD PTR [rdi+4]
ret
.L6:
mov eax, DWORD PTR [rdi]
ret

But it should be able to just emit:
mov eax, DWORD PTR [rdi+rsi*4]
ret

[Bug fortran/92977] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3526

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code

--- Comment #2 from Jakub Jelinek  ---
Oops, sorry, thought it is update rather than write, with write it is valid.

[Bug libgomp/92984] [OpenACC] Semantics of 'acc_delete' etc. with size zero

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

Summary|[OpenACC] 'exit data' with  |[OpenACC] Semantics of
   |size zero fails due to  |'acc_delete' etc. with size
   |'GOMP_MAP_ZERO_LEN_ARRAY_SE |zero
   |CTION'  |

--- Comment #1 from Thomas Schwinge  ---
Well, let's use this PR to generally clarify the semantics, also for
'acc_delete' etc.

[Bug c++/12333] [DR 272] Explicit call to MyClass::~MyClass() not allowed

[jason at gcc dot gnu.org]

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

--- Comment #19 from Jason Merrill  ---
Author: jason
Date: Wed Dec 18 12:44:34 2019
New Revision: 279522

URL: https://gcc.gnu.org/viewcvs?rev=279522&root=gcc&view=rev
Log:
PR c++/12333 - X::~X() with implicit this->.

this->X::~X() is handled by finish_class_member_access_expr and its
lookup_destructor subroutine; let's use it in cp_parser_lookup_name for the
case where this-> is implicit.

I tried replacing the other destructor code here with just the call to
lookup_destructor, but that regressed handling of naming the destructor
outside a non-static member function.

* parser.c (cp_parser_lookup_name): Use lookup_destructor.
* typeck.c (lookup_destructor): No longer static.

Added:
trunk/gcc/testsuite/g++.dg/lookup/dtor1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/parser.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/g++.dg/parse/dtor3.C

[Bug libgomp/92984] New: [OpenACC] 'exit data' with size zero fails due to 'GOMP_MAP_ZERO_LEN_ARRAY_SECTION'

[tschwinge at gcc dot gnu.org]

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

Bug ID: 92984
   Summary: [OpenACC] 'exit data' with size zero fails due to
'GOMP_MAP_ZERO_LEN_ARRAY_SECTION'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

For example:

#pragma acc exit data copyout (a[0:0])

libgomp:  GOACC_enter_exit_data UNHANDLED kind 0x0f

Similar to PR92970, this probably should be a no-op?  Clarifying that with
OpenACC Technical Committee.

[Bug debug/92983] [8/9/10 Regression] Debug info regression since PR87428 changes

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
To correct myself, task DW_TAG_formal_parameter in the
DW_TAG_inlined_subroutine does have actually DW_AT_location, but at least in
the 8.3 version starts with DW_OP_GNU_entry_value.
That said, it is still very wrong to assume the partial inlined function
(especially when inlined back into itself) is the entry point of the function.
And the rest is just kernel screw-up of
KBUILD_CFLAGS   += $(call cc-option, -fno-var-tracking-assignments)

[Bug lto/92972] gcc/lto-wrapper.c:443: identical branches ?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug lto/92972] gcc/lto-wrapper.c:443: identical branches ?

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec 18 11:15:43 2019
New Revision: 279520

URL: https://gcc.gnu.org/viewcvs?rev=279520&root=gcc&view=rev
Log:
PR lto/92972
* lto-wrapper.c (merge_and_complain): Use just "-fno-pie" instead of
big ? "-fno-pie" : "-fno-pie".  Formatting fixes.  Fix comment typo.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-wrapper.c

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

[palves at redhat dot com]

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

--- Comment #36 from Pedro Alves  ---
(In reply to Jason Merrill from comment #33)
> (In reply to Pedro Alves from comment #32)
> > Usually maybe-uninit warnings point to false positives involving scalars,
> > and initializing them is practically free.  But here the size of T may be
> > significant, which could lead to e.g., calling memset in loops.
> 
> Using optional with a large T sounds like a strange choice to me, since it
> means you have to allocate the space even if you don't have a value.

I see it as a perfectly viable approach to avoiding the heap, or avoiding heap
fragmentation and have better cache locality.  For example, instead of:

struct F
{
  A *a = nullptr;
  B* b = nullptr;
};

and then allocating a / b on the heap as separate allocations, with pointer
nullness indicating whether you have the field, you can have:

struct F
{
  ...
  std::optional a;
  std::optional b;
  ...
};

and allocate the whole thing as one block.  gdb's lookup_name_info object uses
this pattern, for example.

[Bug debug/92983] [8/9/10 Regression] Debug info regression since PR87428 changes

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
The assembler diff between r264593 and r264594, when ignoring offsets etc., is:
-   .uleb128 0x27   # (DIE (0x4b6) DW_TAG_lexical_block)
+   .uleb128 0x27   # (DIE (0x4b6) DW_TAG_inlined_subroutine)
.long   0x1ee   # DW_AT_abstract_origin
.quad   .LBB53  # DW_AT_low_pc
.quad   .LBE53-.LBB53   # DW_AT_high_pc
-   .long   0x4ef   # DW_AT_sibling
-   .uleb128 0x1e   # (DIE (0x4cf) DW_TAG_formal_parameter)
+   .byte   0x1 # DW_AT_call_file (nfs3proc.i)
+   .byte   0x4b# DW_AT_call_line
+   .byte   0xc # DW_AT_call_column
+   .long   0x4f2   # DW_AT_sibling
+   .uleb128 0x1e   # (DIE (0x4d2) DW_TAG_formal_parameter)
.long   0x1ff   # DW_AT_abstract_origin
.long   .LLST8  # DW_AT_location

[Bug debug/92983] [8/9/10 Regression] Debug info regression since PR87428 changes

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |8.4

[Bug debug/92983] New: [8/9/10 Regression] Debug info regression since PR87428 changes

[jakub at gcc dot gnu.org]

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

Bug ID: 92983
   Summary: [8/9/10 Regression] Debug info regression since
PR87428 changes
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org, hubicka at gcc dot gnu.org,
jason at gcc dot gnu.org, mark at gcc dot gnu.org,
rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-linux

Created attachment 47518
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47518&action=edit
nfs3proc.i

On the following testcase distilled from Linux kernel nfs3proc.c, when compiled
on x86_64-linux e.g. with -g -O2 -dA, the nfs3_commit_done function is split by
the fnsplit pass and later inlined into itself, furthermore, the "cold" part
doesn't have the task parameter passed to it.
Before PR87428 (on the trunk r264594, but backported to release branches) we
used to emit DW_TAG_subprogram for the abstract instance and then
DW_TAG_subprogram with DW_AT_abstract_origin pointing to that with
DW_AT_location for the task DW_TAG_formal_parameter and then weirdo
DW_TAG_lexical_block with DW_TAG_formal_parameter for the inlined copy of the
rest of the function.  The DW_TAG_formal_parameter for task in that
DW_TAG_lexical_block didn't have any DW_AT_location.
Now, the above mentioned changes make it to some extent more correct by using
DW_TAG_inlined_subroutine instead of DW_TAG_lexical_block, but break tools like
systemtap when e.g. asked to print the task parameter on the first line of the
nfs3_commit_done function, because that will try to put a breakpoint both at
the
start of the nfs3_commit_done function where it will find the argument, and at
the start of the DW_TAG_inlined_subroutine because it says it is another copy
of the function, and task isn't available there.
Ideally, we'd try to undo all the damage done to debug info when inlining
fnsplit body back into itself.
If that can't be done, we should at least tell the debug info consumers that
this is happening, I know Alex posted a partial inlining specific patch for
that
and I've wanted something that would be more specific on the why it is a
partially outlined function, see e.g.
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01941.html
Until that is done, wonder especially for release branches if we couldn't note
this somewhere during fnsplit + inlining it back and represent as
DW_TAG_lexical_block rather than DW_TAG_inlined_subroutine, plus perhaps use
DW_TAG_variable rather than DW_TAG_formal_parameter for the "parameters".