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

[crazylht at gmail dot com]

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

--- Comment #6 from Hongtao.liu  ---
The missing point of my patch is for 512-bit vector compare, integer mask
vector compare still should be used even with target_xop, that's the root cause
of this issue.

Refer to this part.
---
-  if (GET_MODE_SIZE (cmp_ops_mode) == 64)
+  if (ix86_valid_mask_cmp_mode (cmp_ops_mode))
 {
   unsigned int nbits = GET_MODE_NUNITS (cmp_ops_mode);
-  cmp_mode = int_mode_for_size (nbits, 0).require ();
   maskcmp = true;
+  cmp_mode = nbits > 8 ? int_mode_for_size (nbits, 0).require () :
E_QImode;
 }
   else
 cmp_mode = cmp_ops_mode;
@@ -3461,37 +3484,6 @@ ix86_expand_sse_cmp (rtx dest, enum rtx_code code, rtx
cmp_op0, rtx cmp_op1,
   || (op_false && reg_overlap_mentioned_p (dest, op_false)))
 dest = gen_reg_rtx (maskcmp ? cmp_mode : mode);

-  /* Compare patterns for int modes are unspec in AVX512F only.  */
-  if (maskcmp && (code == GT || code == EQ))
-{
-  rtx (*gen)(rtx, rtx, rtx);
-
-  switch (cmp_ops_mode)
-   {
-   case E_V64QImode:
- gcc_assert (TARGET_AVX512BW);
- gen = code == GT ? gen_avx512bw_gtv64qi3 : gen_avx512bw_eqv64qi3_1;
- break;
-   case E_V32HImode:
- gcc_assert (TARGET_AVX512BW);
- gen = code == GT ? gen_avx512bw_gtv32hi3 : gen_avx512bw_eqv32hi3_1;
- break;
-   case E_V16SImode:
- gen = code == GT ? gen_avx512f_gtv16si3 : gen_avx512f_eqv16si3_1;
- break;
-   case E_V8DImode:
- gen = code == GT ? gen_avx512f_gtv8di3 : gen_avx512f_eqv8di3_1;
- break;
-   default:
- gen = NULL;
-   }
-
-  if (gen)
-   {
- emit_insn (gen (dest, cmp_op0, cmp_op1));
- return dest;
-   }
-}
   x = gen_rtx_fmt_ee (code, cmp_mode, cmp_op0, cmp_op1);

   if (cmp_mode != mode && !maskcmp)
-

[Bug tree-optimization/92879] incorrect warning of __builtin_memset offset is out of the bounds on zero-size allocation and initialization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
 Target||x86_64-linux-gnu
   ||aarch64-linux-gnu (LP64
   ||targets)
  Component|c++ |tree-optimization

--- Comment #1 from Andrew Pinski  ---
It is seeming related to ILP32 vs LP64.  That is the warning does not show up
in ILP32 ABI targets.

[Bug c++/92879] New: incorrect warning of __builtin_memset offset is out of the bounds on zero-size allocation and initialization

[cas43 at cs dot stanford.edu]

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

Bug ID: 92879
   Summary: incorrect warning of __builtin_memset offset is out of
the bounds on zero-size allocation and initialization
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cas43 at cs dot stanford.edu
  Target Milestone: ---

DIAGNOSTIC:

g++ prog.cpp -c -Wall -O3
In constructor ‘S::S(int)’,
inlined from ‘(static initializers for prog.cpp)’ at prog.cpp:16:6:
prog.cpp:13:30: warning: ‘void* __builtin_memset(void*, int, long unsigned
int)’ offset [0, 3] is out of the bounds [0, 0]
[]8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Warray-bounds-Warray-bounds]8;;]
   13 | for(int i=0;i

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  ---
(In reply to Thomas Henlich from comment #10)
--- snip ---
> 
> 13.7.2.3.3 E and D editing
> ... If e is positive the exponent part contains e digits, otherwise it
> contains the minimum number of digits required to represent the exponent
> value. ...

Yes, thanks Thomas.

I will fix this. It was very easy to do what I did with the existing code. To
get rid of the leading zero on the exponent will require me to scratch my head
a little further.

Cheers

[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872

[helijia at gcc dot gnu.org]

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

Li Jia He  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||helijia at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #12 from Li Jia He  ---
fixed on trunk together with r278918. On behave of Xiong Hu to close the issue
since his account couldn't.

[Bug tree-optimization/92116] Potential null pointer dereference in 'gomp_acc_remove_pointer'

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|msebor at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #4 from Martin Sebor  ---
(In reply to Thomas Schwinge from comment #2)

IIRC, I assumed based on the check for t != NULL in the controlling expression
that the loop could terminate with t == NULL.  The warning code predates the
patch I was testing -- it just enables it without enhancing its implementation.
 But since r279147 removes the loop I think this report can be resolved, either
as fixed or as invalid.

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre  changed:

   What|Removed |Added

 CC||vincent-gcc at vinc17 dot net

--- Comment #8 from Vincent Lefèvre  ---
(In reply to and...@wahrzeichnen.de from comment #6)
>   6.6 (5) "An expression that evaluates to a constant is required in several
> contexts. If a floating expression is evaluated in the translation
> environment, the arithmetic range and precision shall be at least as great
> as if the expression were being evaluated in the execution environment.
> --footnote: The use of evaluation formats as characterized by
> FLT_EVAL_METHOD also applies to evaluation in the translation environment."

This is about constant expressions and is not applicable to constants. See
5.2.4.2.2p9 for constants.

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

[vincent-gcc at vinc17 dot net]

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

--- Comment #7 from Vincent Lefèvre  ---
(In reply to jos...@codesourcery.com from comment #5)
> Lack of direct float and double arithmetic requires FLT_EVAL_METHOD == 2

No, FLT_EVAL_METHOD could also be negative, in which case GCC would be allowed
to evaluate floating-point constants of type float in whatever range and
precision it wishes.

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

[anders at wahrzeichnen dot de]

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

--- Comment #6 from anders at wahrzeichnen dot de  ---
(In reply to jos...@codesourcery.com from comment #3)
> This is as specified in the C standard.

I guess you are referring to the C18 section

  6.3.1.8 (2) "The values of floating operands and of the results of floating
expressions may be represented in greater range and precision than that
required by the type; the types are not changed thereby. --footnote: The cast
and assignment operators are still required to remove extra range and
precision."

in conjunction with

  6.6 (5) "An expression that evaluates to a constant is required in several
contexts. If a floating expression is evaluated in the translation environment,
the arithmetic range and precision shall be at least as great as if the
expression were being evaluated in the execution environment. --footnote: The
use of evaluation formats as characterized by FLT_EVAL_METHOD also applies to
evaluation in the translation environment."

If so, I propose to close this bug (as __FLT_EVAL_METHOD__ is indeed 2).

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
Most architectures use FLT_EVAL_METHOD == 0.  It's specific to x87 (and 
older m68k) that FLT_EVAL_METHOD == 2 because x87 doesn't support direct 
arithmetic on float or double.  Lack of direct float and double arithmetic 
requires FLT_EVAL_METHOD == 2 and FLT_EVAL_METHOD == 2 requires 
interpreting floating constants to the range and precision of long double, 
whatever their semantic type.

[Bug c++/92878] Parenthesized aggregate initialization doesn't work in a new-expression

[ville.voutilainen at gmail dot com]

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

--- Comment #1 from Ville Voutilainen  ---
Wishlist item: please add a C++2a mode libstdc++ test that verifies that
make_unique and make_shared work with aggregates. Bonus points for
std::allocator_traits>::construct.

[Bug c++/92878] Parenthesized aggregate initialization doesn't work in a new-expression

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug target/92841] Optimize -fstack-protector-strong code generation a bit

[bp at alien8 dot de]

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

--- Comment #5 from Boris  ---
Hohumm, looks good - this is the same site it generated with your patch:

# arch/x86/kernel/cpu/scattered.c:48: {
movq%gs:40, %rax# MEM[( long unsigned int
*)40B], prephitmp_18
movq%rax, 16(%rsp)  # prephitmp_18, D.21446
movl$6, %eax#, prephitmp_18
jmp .L6 #


I haven't checked any other sites whether they are still fine but I'll do that
soon.

Thx.

[Bug c++/92878] New: Parenthesized aggregate initialization doesn't work in a new-expression

[ville.voutilainen at gmail dot com]

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

Bug ID: 92878
   Summary: Parenthesized aggregate initialization doesn't work in
a new-expression
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

//#include 

struct aggressive_aggregate
{
int a;
int b;
};

int main()
{
auto x = aggressive_aggregate(1,2); // OK 
auto y = new aggressive_aggregate(1,2); // rejected, should be OK?
//auto z = std::make_unique(1,2); // rejected, should
be OK?
}

[Bug libgomp/92877] [OpenACC] Failure to resolve back via 'acc_hostptr' an 'acc_deviceptr' retrieved for a structured mapping

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Mon Dec  9 22:52:56 2019
New Revision: 279147

URL: https://gcc.gnu.org/viewcvs?rev=279147=gcc=rev
Log:
[PR92116, PR92877] [OpenACC] Replace 'openacc.data_environ' by standard libgomp
mechanics

libgomp/
PR libgomp/92116
PR libgomp/92877
* oacc-mem.c (lookup_dev): Reimplement.  Adjust all users.
* libgomp.h (struct acc_dispatch_t): Remove 'data_environ' member.
Adjust all users.
* testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-4-2.c:
Remove XFAIL.
* testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-4.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/pr92877-1.c: New file.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92877-1.c
Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/libgomp.h
trunk/libgomp/oacc-host.c
trunk/libgomp/oacc-mem.c
trunk/libgomp/target.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-4-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-4.c

[Bug tree-optimization/92116] Potential null pointer dereference in 'gomp_acc_remove_pointer'

[tschwinge at gcc dot gnu.org]

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

--- Comment #3 from Thomas Schwinge  ---
Author: tschwinge
Date: Mon Dec  9 22:52:56 2019
New Revision: 279147

URL: https://gcc.gnu.org/viewcvs?rev=279147=gcc=rev
Log:
[PR92116, PR92877] [OpenACC] Replace 'openacc.data_environ' by standard libgomp
mechanics

libgomp/
PR libgomp/92116
PR libgomp/92877
* oacc-mem.c (lookup_dev): Reimplement.  Adjust all users.
* libgomp.h (struct acc_dispatch_t): Remove 'data_environ' member.
Adjust all users.
* testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-4-2.c:
Remove XFAIL.
* testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-4.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/pr92877-1.c: New file.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92877-1.c
Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/libgomp.h
trunk/libgomp/oacc-host.c
trunk/libgomp/oacc-mem.c
trunk/libgomp/target.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-4-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-4.c

[Bug libgomp/92503] [OpenACC] Behavior of 'acc_free' if the memory space is still used in a mapping

[tschwinge at gcc dot gnu.org]

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

--- Comment #4 from Thomas Schwinge  ---
Author: tschwinge
Date: Mon Dec  9 22:52:47 2019
New Revision: 279146

URL: https://gcc.gnu.org/viewcvs?rev=279146=gcc=rev
Log:
[PR92503] [OpenACC] Don't silently 'acc_unmap_data' in 'acc_free'

libgomp/
PR libgomp/92503
* oacc-mem.c (acc_free): Error out instead of 'acc_unmap_data'.
* testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-1.c: New
file.
* testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-2.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-3-2.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-3.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-4-2.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-4.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/clauses-1.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/context-1.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/context-2.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/context-3.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/context-4.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-13.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-14.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-18.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-91.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/nested-1.c: Likewise.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-3-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-3.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-4-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-4.c
Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/oacc-mem.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/clauses-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/context-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/context-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/context-3.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/context-4.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-13.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-14.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-18.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-91.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/nested-1.c

[Bug libgomp/92840] [OpenACC] Disallow 'acc_unmap_data' for everything other than 'acc_map_data'

[tschwinge at gcc dot gnu.org]

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

--- Comment #3 from Thomas Schwinge  ---
Author: tschwinge
Date: Mon Dec  9 22:52:36 2019
New Revision: 279145

URL: https://gcc.gnu.org/viewcvs?rev=279145=gcc=rev
Log:
[PR92840] [OpenACC] Refuse 'acc_unmap_data' unless mapped by 'acc_map_data'

libgomp/
PR libgomp/92840
* oacc-mem.c (acc_map_data): Clarify reference counting behavior.
(acc_unmap_data): Add error case for 'REFCOUNT_INFINITY'.
* testsuite/libgomp.oacc-c-c++-common/acc_unmap_data-pr92840-1.c:
New file.
* testsuite/libgomp.oacc-c-c++-common/acc_unmap_data-pr92840-2.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/acc_unmap_data-pr92840-3.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/clauses-1.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/nested-1.c: Adjust.

Added:
   
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_unmap_data-pr92840-1.c
   
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_unmap_data-pr92840-2.c
   
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_unmap_data-pr92840-3.c
Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/oacc-mem.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/clauses-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/nested-1.c

[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)

[eitan at mosenkis dot net]

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

eitan at mosenkis dot net changed:

   What|Removed |Added

 CC||eitan at mosenkis dot net

--- Comment #15 from eitan at mosenkis dot net ---
(In reply to Matthijs Kooijman from comment #14)
> I actually think this is a different problem from the fixed
> https://sourceware.org/bugzilla/show_bug.cgi?id=22502. Using gcc 8.2.1 and
> binutils 2.31.51.20181213 from the STM32 Arduino core
> (https://github.com/stm32duino/Arduino_Core_STM32), I can still reproduce
> this problem using the example from comment 11 (and also in an actual
> implementation using stm32duino). I also tested the example from the linked
> bug, which *is* indeed fixed, leading me to believe this is a different
> problem (or the fix is not complete yet).
> 
> The example from this bug is a lot bigger than the one from 22502, so there
> is probably something in here that triggers this. Maybe that the weak
> implementation is defined in assembly rather than C?

I am also still able to reproduce the problem in production code
(http://github.com/solokeys/solo) using GNU ld (GNU Tools for Arm Embedded
Processors 9-2019-q4-major) 2.33.1.20191025.

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

[anders at wahrzeichnen dot de]

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

--- Comment #4 from anders at wahrzeichnen dot de  ---
I don't know about other archs, but on amd64, GCC emits comiss insns (SSE2
single-precision scalar compare) for f0, f1, and f2 and comisd insns (SSE2
double-precision scalar compare) for f3. So this is evidently not a problem on
amd64 (i.e. it does not depend on how the decimal-to-binary rounding was done
for the value 0.1). Conclusion: Ignoring the 'f' suffix seems to be specific
for 387.

[Bug target/92807] gcc generate extra move for the snippet code along with lea instruction.

[skpgkp2 at gmail dot com]

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

--- Comment #5 from Sunil Pandey  ---
Patch link: https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00450.html

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
The value of FLT_EVAL_METHOD applies to constants as well as to 
operations.  That is, when FLT_EVAL_METHOD == 2, 0.1f has the precision of 
long double but the semantic type of float, and 0.1 has the precision of 
long double but the semantic type of double.  An explicit cast to float 
removes excess precision.  This is as specified in the C standard.

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

[anders at wahrzeichnen dot de]

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

--- Comment #2 from anders at wahrzeichnen dot de  ---
No, -ffloat-store does not help. And this has little if anything to do with
323, imho.

The asm generated for f3 is instructive: There, GCC wants to load a double
constant 0x3fba into the 387 FPU, which is
0.1555... The single-precision constant t passed as argument to
f0...f3 is 0x3dcd, which is 0.1000149... So, it's no wonder that f3
returns 1; after all 0.1000149 > 0.1555.

The questions are: Why does the code generated for f2 try to load a double
constant even if it is explicitly suffixed 'f'? Why should casting to (float)
help? Why does std=c11 or c18 change the game?

[Bug rtl-optimization/92796] [10 Regression] ICE in lra_assign, at lra-assigns.c:1646 on powerpc64le-linux-gnu

[vmakarov at gcc dot gnu.org]

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

--- Comment #10 from Vladimir Makarov  ---
(In reply to Vladimir Makarov from comment #7)

>
> 
> I'm guessing this was never a problem before I added the code to not add
> conflicts for copies.  Before then, any two pseudos/registers that were live
> simultaneously were made to conflict, which would have hid this bug.

I believe this bug existed before.  For example, the initial assignment (and
some LRA transformations) does not guarantee correctness of already made
assignments.

Therefore there is flag lra_risky_transformations_p (I am going to change this
name) to deal with such situations.  Simply the current situation was not
considered before.

I have a patch and after some testing I'll commit it (probably tomorrow).

[Bug ipa/92538] Proposal for IPA init() constant propagation

[erick.oc...@theobroma-systems.com]

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

Erick Ochoa  changed:

   What|Removed |Added

  Attachment #47278|0   |1
is obsolete||
  Attachment #47355|0   |1
is obsolete||

--- Comment #5 from Erick Ochoa  ---
Created attachment 47455
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47455=edit
Patch version 3

Hello,

I am updating the patch version.
Currently, this patch can be applied against this commit on master branch.

commit 3cce71b23f6ed221b4335b600e718d79903cc83d
Date:   Wed Dec 4 20:04:10 2019 +  
   
   
   
  git-svn-id:
svn+ssh://gcc.gnu.org/svn/gcc/trunk@278975 138bc75d-0d04-0410-961f-82ee72b054a4

This patch works on the previous patch by eliminating bugs.
Currently, all SPEC CPU 2017 benchmarks can be compiled with this patch and run
successfully.
Furthermore, it detects several constants that can be propagated in 12 of the
SPEC CPU benchmarks.

[Bug fortran/92863] ICE in gfc_typename

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
This looks reasonable:

Index: misc.c
===
--- misc.c  (Revision 279064)
+++ misc.c  (Arbeitskopie)
@@ -164,9 +164,17 @@ gfc_typename (gfc_typespec *ts)
   sprintf (buffer, "UNION(%s)", ts->u.derived->name);
   break;
 case BT_DERIVED:
-  sprintf (buffer, "TYPE(%s)", ts->u.derived->name);
+  if (ts->u.derived)
+   sprintf (buffer, "TYPE(%s)", ts->u.derived->name);
+  else
+   sprintf (buffer, "invalid type");
   break;
 case BT_CLASS:
+  if (ts->u.derived == NULL)
+   {
+ sprintf (buffer, "invalid class");
+ break;
+   }
   ts1 = ts->u.derived->components ? >u.derived->components->ts : NULL;
   if (ts1 && ts1->u.derived && ts1->u.derived->attr.unlimited_polymorphic)
sprintf (buffer, "CLASS(*)");

[Bug rtl-optimization/92796] [10 Regression] ICE in lra_assign, at lra-assigns.c:1646 on powerpc64le-linux-gnu

[bergner at gcc dot gnu.org]

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

--- Comment #9 from Peter Bergner  ---
(In reply to Vladimir Makarov from comment #7)
> A very interesting case, Peter.  I reproduced the case too.  I can take it
> from here if you don't mind.  The solution I see for this problem is to
> check that if we change  operand constraint from IN to INOUT when we change
> insn alternative [code as you meantion later] then we reconsider all conflicts
> for pseudos already assigned to hard registers.

I'm more than fine if you want to handle this yourself, since you know this
code better than anyone.

I'm guessing this was never a problem before I added the code to not add
conflicts for copies.  Before then, any two pseudos/registers that were live
simultaneously were made to conflict, which would have hid this bug.

[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons

[joseph at codesourcery dot com]

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

--- Comment #13 from joseph at codesourcery dot com  ---
On Fri, 6 Dec 2019, vgupta at synopsys dot com wrote:

> However I'm curious that the test uses qNaN. What is the expected behavior for
> sNaN. If you tweak the testcase  slightly as follows:

All the comparison operations raise exceptions for sNaN.  See IEEE 754.  
"Invalid operation is the only exception that a comparison predicate can 
signal. All predicates signal the invalid operation exception on signaling 
NaN operands. The predicates named Quiet shall not signal any exception, 
unless an operand is a signaling NaN. The predicates named Signaling shall 
signal the invalid operation exception on quiet NaN operands.".

[Bug tree-optimization/92116] Potential null pointer dereference in 'gomp_acc_remove_pointer'

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords|openacc |
  Component|libgomp |tree-optimization
   Assignee|jules at gcc dot gnu.org   |msebor at gcc dot 
gnu.org

--- Comment #2 from Thomas Schwinge  ---
Martin Sebor, regarding this:

(In reply to myself from comment #0)
> As reported in
> :
> 
> | PS I tried compiling GCC with [a new] patch.  It fails in libgomp
> | with:
> | 
> |libgomp/oacc-mem.c: In function ‘gomp_acc_remove_pointer’:
> |cc1: warning: invalid use of a null pointer [-Wnonnull]
> | 
> | so clearly it's missing location information.  With
> | -Wnull-dereference enabled we get more detail:
> | 
> |libgomp/oacc-mem.c: In function ‘gomp_acc_remove_pointer’:
> |libgomp/oacc-mem.c:1013:31: warning: potential null pointer dereference 
> [-Wnull-dereference]
> | 1013 |   for (size_t i = 0; i < t->list_count; i++)
> |  |  ~^~~~
> |libgomp/oacc-mem.c:1012:19: warning: potential null pointer dereference 
> [-Wnull-dereference]
> | 1012 |   t->refcount = minrefs;
> |  |   ^
> |libgomp/oacc-mem.c:1013:31: warning: potential null pointer dereference 
> [-Wnull-dereference]
> | 1013 |   for (size_t i = 0; i < t->list_count; i++)
> |  |  ~^~~~
> |libgomp/oacc-mem.c:1012:19: warning: potential null pointer dereference 
> [-Wnull-dereference]
> | 1012 |   t->refcount = minrefs;
> |  |   ^
> |cc1: warning: invalid use of a null pointer [-Wnonnull]
> | 
> | I didn't spend too long examining the code but it seems like
> | the warnings might actually be justified.  When the first loop
> | terminates with t being null

It's actually not possible to terminate this loop with 't = NULL'.  ;-)

As I understand this, what your compiler analysis pass has difficulties to
figure out (from the code as written in 'gomp_acc_remove_pointer'?) is that
here:

> | the subsequent dereferences are
> | invalid:
> | 
> |if (t->refcount == minrefs)
> | {
> |   /* This is the last reference, so pull the descriptor off the
> |  chain. This prevents gomp_unmap_vars via gomp_unmap_tgt from
> |  freeing the device memory. */
> |   struct target_mem_desc *tp;
> |   for (tp = NULL, t = acc_dev->openacc.data_environ; t != NULL;
> |tp = t, t = t->prev)
> | {
> |   if (n->tgt == t)
> | {
> |   if (tp)
> | tp->prev = t->prev;
> |   else
> | acc_dev->openacc.data_environ = t->prev;
> |   break;
> | }
> | }
> | }

... we are always going to eventually find 'n->tgt == t': we start this loop
with 't == n->tgt' (see further above), and what this code here is doing is
just to locate 'n->tgt' in 'data_environ', which is guaranteed to contain it
(yes, there should be some 'assert' or similar for that...), and then un-link
it from 'data_environ'.  Then we 'break', and thus after the loop we again have
the original 't = n->tgt', and so here:

> |/* Set refcount to 1 to allow gomp_unmap_vars to unmap it.  */
> |n->refcount = 1;
> |t->refcount = minrefs;
> |for (size_t i = 0; i < t->list_count; i++)

..., there will never be 't == NULL'.

Certainly this code is a bit "strange" -- but maybe that's something your
analysis has to consider for "real-world code"?  I'm assigning this PR to you
in case you'd like to track this, otherwise please set RESOLVED, INVALID or
something like that.

..., and that said, we shall be removing this code from
'gomp_acc_remove_pointer' any moment now...  ;-)

[Bug rtl-optimization/92796] [10 Regression] ICE in lra_assign, at lra-assigns.c:1646 on powerpc64le-linux-gnu

[vmakarov at gcc dot gnu.org]

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

--- Comment #8 from Vladimir Makarov  ---
(In reply to Vladimir Makarov from comment #7)

> A very interesting case, Peter.  I reproduced the case too.  I can take it
> from here if you don't mind.  The solution I see for this problem is to
> check that if we change  operand constraint from IN to INOUT when we change
> insn alternative then we reconsider all conflicts for pseudos already
> assigned to hard registers.

Sorry, I meant insn code change not the insn alternative change.

[Bug rtl-optimization/92796] [10 Regression] ICE in lra_assign, at lra-assigns.c:1646 on powerpc64le-linux-gnu

[vmakarov at gcc dot gnu.org]

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

--- Comment #7 from Vladimir Makarov  ---
(In reply to Peter Bergner from comment #6)
> 
> Vlad (or Jeff), can you point me to where this is supposed to be handled?
> I don't think I see where LRA verifies the reg_renumber[regno] values are
> still
> valid with respect to the new pattern constraints for the insns that are
> modified by spilling.
> 
> lra_reg_info[133].conflict_hard_regs does contain 66, so LRA knows it
> conflicts
> with reg 66, but it never seems to use that information as a sign that pseudo
> 133 needs reassigning.

A very interesting case, Peter.  I reproduced the case too.  I can take it from
here if you don't mind.  The solution I see for this problem is to check that
if we change  operand constraint from IN to INOUT when we change insn
alternative then we reconsider all conflicts for pseudos already assigned to
hard registers.

[Bug middle-end/92761] hash_table::expand invokes assignment on invalid objects

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #12 from Martin Sebor  ---
Fixed in 279139.  (Though there are outstanding problems with non-trivial
types.)

[Bug bootstrap/92762] hash_table::empty_slow invokes assignment on invalid objects

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Mon Dec  9 20:54:11 2019
New Revision: 279139

URL: https://gcc.gnu.org/viewcvs?rev=279139=gcc=rev
Log:
PR middle-end/92761 - hash_table::expand invokes assignment on invalid objects
PR middle-end/92762 - hash_table::empty_slow invokes assignment on invalid
objects

gcc/ChangeLog:

PR middle-end/92761
PR middle-end/92762
* hash-map-tests.c (test_map_of_type_with_ctor_and_dtor): Tighten
up tests.
* hash-table.h (hash_table::expand): Use placement new to copy
construct objects in uninitialized storage.
(hash_table::empty_slow): Avoid invoking copy assignment on
uninitialized objects.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/hash-map-tests.c
trunk/gcc/hash-table.h

[Bug middle-end/92761] hash_table::expand invokes assignment on invalid objects

[msebor at gcc dot gnu.org]

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

--- Comment #11 from Martin Sebor  ---
Author: msebor
Date: Mon Dec  9 20:54:11 2019
New Revision: 279139

URL: https://gcc.gnu.org/viewcvs?rev=279139=gcc=rev
Log:
PR middle-end/92761 - hash_table::expand invokes assignment on invalid objects
PR middle-end/92762 - hash_table::empty_slow invokes assignment on invalid
objects

gcc/ChangeLog:

PR middle-end/92761
PR middle-end/92762
* hash-map-tests.c (test_map_of_type_with_ctor_and_dtor): Tighten
up tests.
* hash-table.h (hash_table::expand): Use placement new to copy
construct objects in uninitialized storage.
(hash_table::empty_slow): Avoid invoking copy assignment on
uninitialized objects.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/hash-map-tests.c
trunk/gcc/hash-table.h

[Bug libgomp/92877] [OpenACC] Failure to resolve back via 'acc_hostptr' an 'acc_deviceptr' retrieved for a structured mapping

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

[Bug libgomp/92503] [OpenACC] Behavior of 'acc_free' if the memory space is still used in a mapping

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-12-09
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Thomas Schwinge  ---
(In reply to myself from comment #2)
> There are nvptx offloading TODOs in
> 'libgomp.oacc-c-c++-common/acc_free-pr92503-4.c',
> 'libgomp.oacc-c-c++-common/acc_free-pr92503-4-2.c'.  Can you easily (please
> don't spend much time on this) what's going wrong?  Otherwise I shall commit
> that XFAILed.

This is a variant of PR92877.  ;-O

> Please also verify whether there are any changes necessary for AMD GCN
> offloading, in particular un-XFAILing the two nvptx ones, I suppose?

..., so not related to nvptx offloading.

[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns

[dmalcolm at gcc dot gnu.org]

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

--- Comment #21 from David Malcolm  ---
(In reply to David Malcolm from comment #20)
> I've committed r279137 on Lewis's behalf, which fixes the issues identified
> in patch #13.
comment #13, I meant to say

[Bug libgomp/92877] New: [OpenACC] Failure to resolve back via 'acc_hostptr' an 'acc_deviceptr' retrieved for a structured mapping

[tschwinge at gcc dot gnu.org]

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

Bug ID: 92877
   Summary: [OpenACC] Failure to resolve back via 'acc_hostptr' an
'acc_deviceptr' retrieved for a structured mapping
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc, patch
  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, jules at gcc dot gnu.org
  Target Milestone: ---

This currently fails:

int var;

#pragma acc data create (var)
{
  void *var_p_d = acc_deviceptr ();
  assert (acc_hostptr (var_p_d) == );
}

Patch exists.

[Bug other/92871] new test case g++.dg/ext/temp-extend1.C fails starting with its introduction in r279069

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-09
 CC||jason at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Oops, I see what's going on.

The ?: with omitted middle operand is transformed earlier into
cp_stabilize_reference (arg1) ? cp_stabilize_reference (arg1) : ...
where the first two arguments are the same, then the middle argument is wrapped
into ADDR_EXPR (but I'd be afraid that generally it can be much harder to
figure out what is what) and only much later extend_ref_init_temps_1, which
only modifies the second argument (and third) and puts the subinit initializers
in there.  While the tree of the TARGET_EXPR is obviously shared between the
first and second COND_EXPR arguments, as we put the initialization just into
the second, it means the VAR_DECL that replaced the TARGET_EXPR is used before
it is initialized.

Now, I'm afraid it will be nasty to fix it up.
Either we mark with some flag COND_EXPRs that had originally the middle operand
omitted, propagate it through all the COND_EXPR rationalization etc. and then
try to figure out how to get from the second operand something suitable for the
first operand if that is at all possible (e.g. in this testcase perhaps by
figuring out that originally the second argument is & of the first one and
after changing the second one, modify the first argument to be INDIRECT_REF of
the second one and thus get all the subinit initialization in there.
Or try to somehow discover if the first and second argument were originally the
same without a flag.  Or make sure we keep the middle operand NULL much longer.
 Any other ideas?

This problem isn't actually powerpc64 specific, on x86_64-linux, while we are
lucky that the test passes, valgrind shows that it uses uninitialized memory.

[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns

[dmalcolm at gcc dot gnu.org]

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

--- Comment #20 from David Malcolm  ---
I've committed r279137 on Lewis's behalf, which fixes the issues identified in
patch #13.

As noted in review of the patch, we didn't attempt to change the behavior of
diagnostic_get_location_text with this change.  Quoting myself from:
  https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02171.html

> This is the column number as reported in the diagnostic i.e the COL_NUM
> when printing e.g.
>   warning: FILENAME:LINE_NUM:COL_NUM: some message
> 
> It seems to me that PR 49973 and this patch cover two separate things:
> (a) bytes vs display columns in diagnostic-show-locus.c
> (b) the "COL_NUM" mentioned above.
> 
> I'd prefer to omit (b) from the patch, and have the focus of the patch
> be (a), to tackle (b) in a separate patch.
> 
> [There's also the meaning of column numbers in the JSON output, and in
> the output of -fdiagnostics-parseable-fixits (which is intended to mimic
> clang's output format)]
> 
> It's unclear to me what the reported COL_NUM should be.
> There are various possibilities:
> 
> Units:
>   (A) [status quo] report a count of bytes within the line
>   (B) report a count of unicode characters
>   (C) report a count of unicode graphemes
>   (D) report based on the wcwidth of the characters
>   etc
> 
> Origin/baseline:
>   (A) [status quo] use 1 for the leftmost column
>   (B) use 0 for the leftmost column
> 
> Tab-handling:
>   (A) [status quo] don't give any kind of special status to tab characters
>   (B) implement tab stops, somehow.  For example, get_visual_column in
>   c-family/c-indentation implements tab stops based on bytes.
> 
> (so at least 4*2*2 = 16 possible meanings, ugh)
> 
> See also e.g.:
>   https://github.com/oasis-tcs/sarif-spec/issues/178
> 
> The GNU Coding Standards say
> 
>Line numbers should start from 1 at the beginning of the file, and
>column numbers should start from 1 at the beginning of the line.
>(Both of these conventions are chosen for compatibility.) Calculate
>column numbers assuming that space and all ASCII printing characters
>have equal width, and assuming tab stops every 8 columns. For
>non-ASCII characters, Unicode character widths should be used when in
>a UTF-8 locale; GNU libc and GNU gnulib provide suitable wcwidth
>functions.
> (https://www.gnu.org/prep/standards/standards.html#Errors)
> 
> I think if we do change the meaning of the "COL_NUM" output, we should
> probably add an option for it, to help with the transition (so that
> people can easily revert to the old behavior).
> 
> Perhaps something like:
> 
>   -fdiagnostics-column-unit=[bytes|gnu]
> 
>  bytes: [status-quo]; 1-based count of bytes, not respecting tab stops
>  gnu: as per GNU Coding Standards above
> 
> and have gcc 10 default to "gnu" (or whatever we call it), so that
> people can override it back to "bytes".
> 
> (again, I'm thinking aloud here)
> 
> But please can you split that out as a separate patch? (it's arguably
> still in time for GCC 10, as it's from a patch was posted before the
> stage 1 deadline).

[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns

[dmalcolm at gcc dot gnu.org]

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

--- Comment #19 from David Malcolm  ---
Author: dmalcolm
Date: Mon Dec  9 20:03:47 2019
New Revision: 279137

URL: https://gcc.gnu.org/viewcvs?rev=279137=gcc=rev
Log:
Byte vs column awareness for diagnostic-show-locus.c (PR 49973)

contrib/ChangeLog

2019-12-09  Lewis Hyatt  

PR preprocessor/49973
* unicode/from_glibc/unicode_utils.py: Support script from
glibc (commit 464cd3) to extract character widths from Unicode data
files.
* unicode/from_glibc/utf8_gen.py: Likewise.
* unicode/UnicodeData.txt: Unicode v. 12.1.0 data file.
* unicode/EastAsianWidth.txt: Likewise.
* unicode/PropList.txt: Likewise.
* unicode/gen_wcwidth.py: New utility to generate
libcpp/generated_cpp_wcwidth.h with help from the glibc support
scripts and the Unicode data files.
* unicode/unicode-license.txt: Added.
* unicode/README: New explanatory file.

libcpp/ChangeLog

2019-12-09  Lewis Hyatt  

PR preprocessor/49973
* generated_cpp_wcwidth.h: New file generated by
../contrib/unicode/gen_wcwidth.py, supports new cpp_wcwidth function.
* charset.c (compute_next_display_width): New function to help
implement display columns.
(cpp_byte_column_to_display_column): Likewise.
(cpp_display_column_to_byte_column): Likewise.
(cpp_wcwidth): Likewise.
* include/cpplib.h (cpp_byte_column_to_display_column): Declare.
(cpp_display_column_to_byte_column): Declare.
(cpp_wcwidth): Declare.
(cpp_display_width): New function.

gcc/ChangeLog

2019-12-09  Lewis Hyatt  

PR preprocessor/49973
* input.c (location_compute_display_column): New function to help with
multibyte awareness in diagnostics.
(test_cpp_utf8): New self-test.
(input_c_tests): Call the new test.
* input.h (location_compute_display_column): Declare.
* diagnostic-show-locus.c: Pervasive changes to add multibyte awareness
to all classes and functions.
(enum column_unit): New enum.
(class exploc_with_display_col): New class.
(class layout_point): Convert m_column member to array m_columns[2].
(layout_range::contains_point): Add col_unit argument.
(test_layout_range_for_single_point): Pass new argument.
(test_layout_range_for_single_line): Likewise.
(test_layout_range_for_multiple_lines): Likewise.
(line_bounds::convert_to_display_cols): New function.
(layout::get_state_at_point): Add col_unit argument.
(make_range): Use empty filename rather than dummy filename.
(get_line_width_without_trailing_whitespace): Rename to...
(get_line_bytes_without_trailing_whitespace): ...this.
(test_get_line_width_without_trailing_whitespace): Rename to...
(test_get_line_bytes_without_trailing_whitespace): ...this.
(class layout): m_exploc changed to exploc_with_display_col from
plain expanded_location.
(layout::get_linenum_width): New accessor member function.
(layout::get_x_offset_display): Likewise.
(layout::calculate_linenum_width): New subroutine for the constuctor.
(layout::calculate_x_offset_display): Likewise.
(layout::layout): Use the new subroutines. Add multibyte awareness.
(layout::print_source_line): Add multibyte awareness.
(layout::print_line): Likewise.
(layout::print_annotation_line): Likewise.
(line_label::line_label): Likewise.
(layout::print_any_labels): Likewise.
(layout::annotation_line_showed_range_p): Likewise.
(get_printed_columns): Likewise.
(class line_label): Rename m_length to m_display_width.
(get_affected_columns): Rename to...
(get_affected_range): ...this; add col_unit argument and multibyte
awareness.
(class correction): Add m_affected_bytes and m_display_cols
members.  Rename m_len to m_byte_length for clarity.  Add multibyte
awareness throughout.
(correction::insertion_p): Add multibyte awareness.
(correction::compute_display_cols): New function.
(correction::ensure_terminated): Use new member name m_byte_length.
(line_corrections::add_hint): Add multibyte awareness.
(layout::print_trailing_fixits): Likewise.
(layout::get_x_bound_for_row): Likewise.
(test_one_liner_simple_caret_utf8): New self-test analogous to the one
with _utf8 suffix removed, testing multibyte awareness.
(test_one_liner_caret_and_range_utf8): Likewise.
(test_one_liner_multiple_carets_and_ranges_utf8): Likewise.
(test_one_liner_fixit_insert_before_utf8): Likewise.
(test_one_liner_fixit_insert_after_utf8): Likewise.
(test_one_liner_fixit_remove_utf8): Likewise.
(test_one_liner_fixit_replace_utf8): Likewise.
  

[Bug c/92857] -Wsign-conversion flag issues false positives for expression using typedef'ed unsigned types

[joshua.a.saxby at gmail dot com]

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

Joshua Saxby  changed:

   What|Removed |Added

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

--- Comment #5 from Joshua Saxby  ---
Ah, I have some reading to do, then. Thank you for pointing that out and
apologies for wasting your time everyone.

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||i?86-linux-gnu
 Depends on||323

--- Comment #1 from Andrew Pinski  ---
Does -ffloat-store help?
See 323 also.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug 323] optimized code gives strange floating point results

[Bug fortran/92876] New: ICE in expand_UNIQUE, at internal-fn.c:2599

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

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

Bug ID: 92876
   Summary: ICE in expand_UNIQUE, at internal-fn.c:2599
   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: ---

Affects versions down to gfortran-6 at -O1+ :
(presumably related to pr89499)


$ cat z1.f90
program p
   call s
contains
   subroutine s
  !$acc routine vector
  !$acc loop vector
  do i = 1, 8
  end do
   end
end


$ gfortran-10-20191208 -c z1.f90 -fopenacc -Og
$
$ gfortran-10-20191208 -c z1.f90 -fopenacc -O2
during RTL pass: expand
z1.f90:6:0:

6 |   !$acc loop vector
  |
internal compiler error: in expand_UNIQUE, at internal-fn.c:2599
0x97011f expand_UNIQUE
../../gcc/internal-fn.c:2599
0x79c6e7 expand_call_stmt
../../gcc/cfgexpand.c:2639
0x79c6e7 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3709
0x79c6e7 expand_gimple_stmt
../../gcc/cfgexpand.c:3874
0x7a1827 expand_gimple_basic_block
../../gcc/cfgexpand.c:5914
0x7a3e76 execute
../../gcc/cfgexpand.c:6569

[Bug c/92875] New: GCC ignores the floating-point 'f' suffix in C11 mode

[anders at wahrzeichnen dot de]

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

Bug ID: 92875
   Summary: GCC ignores the floating-point 'f' suffix in C11 mode
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders at wahrzeichnen dot de
  Target Milestone: ---

Created attachment 47454
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47454=edit
test case with return value 0 or 8 expected, returns 12

GCC treats floating-point constants suffixed with 'f' as double, when compiled
with either -std=c11 or -std=c18. The attached test case illustrates this
problem: There are four functions f0, f1, f2, and f3. The first three functions
f0, f1, and f2 should all compile to the same code, f4 is different and there
for reference.

It turns out that with -std=387 and -m32 (or with -mfpmath=387), GCC compiles
f0 and f1 to equivalent asm but not f2. Instead, it creates the same asm for f2
as for f3, involving some loading a constant into an FPU register using double
precision. Apparently, writing '0.1f' is not enough to convince GCC that the
constant is single precision.

This can be seen with the attached program:
$ gcc -O -m32 testcase.c  &&  ./a.out; echo $? 
8
$ gcc -std=c11 -O -m32 testcase.c  &&  ./a.out; echo $? 
12

The result should be either 0, 8, or 15, depending on how exactly the decimal
constant 0.1 is rounded to binary floating-point, but it should never be
anything else.

The bug seems to be independent of optimization; it happens with -O0, -O1, -O2,
-O3, -Os, and -Og. I can trace it from GCC 9.2 all the way back to 4.8.4. It
can be triggered on 387 (with -m32 or -mfpmath=387).

[Bug fortran/92874] New: ICE in gfc_dep_compare_expr, at fortran/dependency.c:36

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

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

Bug ID: 92874
   Summary: ICE in gfc_dep_compare_expr, at
fortran/dependency.c:36
   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: ---

Affects versions down to at least gfortran-4.9,
compiles and works with -fno-frontend-optimize :


$ cat z1.f90
program p
   call s('a')
   call s('abc')
end
subroutine s(x)
   character(*) :: x
   print *, (x(1:1) == x(1:))
end


$ gfortran-10-20191208 z1.f90 -O2 -fno-frontend-optimize && ./a.out
 T
 F


$ gfortran-10-20191208 -c z1.f90 -O2
f951: internal compiler error: Segmentation fault
0xb800af crash_signal
../../gcc/toplev.c:328
0x6c9b14 gfc_dep_compare_expr(gfc_expr*, gfc_expr*)
../../gcc/fortran/dependency.c:368
0x6ca0ea are_identical_variables
../../gcc/fortran/dependency.c:187
0x6ca0ea gfc_dep_compare_expr(gfc_expr*, gfc_expr*)
../../gcc/fortran/dependency.c:486
0x758249 optimize_comparison
../../gcc/fortran/frontend-passes.c:2077
0x759a2f optimize_op
../../gcc/fortran/frontend-passes.c:1914
0x759a2f optimize_expr
../../gcc/fortran/frontend-passes.c:352
0x75a205 gfc_expr_walker(gfc_expr**, int (*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:4929
0x75a3e9 gfc_expr_walker(gfc_expr**, int (*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:4936
0x75cab1 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5347
0x75cb47 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5355
0x75dd12 optimize_namespace
../../gcc/fortran/frontend-passes.c:1474
0x75e15f gfc_run_passes(gfc_namespace*)
../../gcc/fortran/frontend-passes.c:165
0x69a1c7 gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17227
0x69a591 gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:2546
0x69a591 resolve_global_procedure
../../gcc/fortran/resolve.c:2548
0x6a3378 resolve_call
../../gcc/fortran/resolve.c:3676
0x697d7d gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11878
0x69a0d7 resolve_codes
../../gcc/fortran/resolve.c:17186
0x69a19e gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17221

[Bug fortran/92873] New: ICE in unmodified_parm_or_parm_agg_item, at ipa-fnsummary.c:1166

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

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

Bug ID: 92873
   Summary: ICE in unmodified_parm_or_parm_agg_item, at
ipa-fnsummary.c:1166
   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: ---

Affects versions down to at least gcc-5 :


$ cat z1.f90
module m
contains
   elemental function f(a,b) result(c)
  character(*), intent(in) :: a, b
  character(len(a)**len(b)) :: c
  c = a // b
   end
   subroutine s
  call sub (f(['abc'], ['xyz']))
   end
end


$ gfortran-10-20191208 -c z1.f90 -O2
during IPA pass: fnsummary
z1.f90:7:0:

7 |end
  |
internal compiler error: Segmentation fault
0xb800af crash_signal
../../gcc/toplev.c:328
0x99add0 gimple_assign_single_p
../../gcc/gimple.h:2784
0x99add0 unmodified_parm_or_parm_agg_item
../../gcc/ipa-fnsummary.c:1166
0x99add0 decompose_param_expr
../../gcc/ipa-fnsummary.c:1340
0x9a0bcd set_cond_stmt_execution_predicate
../../gcc/ipa-fnsummary.c:1463
0x9a0bcd compute_bb_predicates
../../gcc/ipa-fnsummary.c:1745
0x9a0bcd analyze_function_body
../../gcc/ipa-fnsummary.c:2481
0x9a1b64 compute_fn_summary(cgraph_node*, bool)
../../gcc/ipa-fnsummary.c:2932
0x9a212b inline_analyze_function(cgraph_node*)
../../gcc/ipa-fnsummary.c:4042
0x9a22b9 ipa_fn_summary_generate
../../gcc/ipa-fnsummary.c:4085
0xabd39c execute_ipa_summary_passes(ipa_opt_pass_d*)
../../gcc/passes.c:2189
0x7d55f9 ipa_passes
../../gcc/cgraphunit.c:2631
0x7d55f9 symbol_table::compile()
../../gcc/cgraphunit.c:2741
0x7d73a6 symbol_table::compile()
../../gcc/cgraphunit.c:2991
0x7d73a6 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2988


$ gfortran-10-20191208 -c z1.f90 # with --enable-checking=yes
during GIMPLE pass: fixup_cfg
z1.f90:3:0:

3 |elemental function f(a,b) result(c)
  |
internal compiler error: Segmentation fault
0xd05dff crash_signal
../../gcc/toplev.c:328
0xf5ce22 get_use_from_ptr
../../gcc/tree-ssa-operands.h:112
0xf5ce22 verify_use
../../gcc/tree-ssa.c:926
0xf614e2 verify_ssa(bool, bool)
../../gcc/tree-ssa.c:1161
0xc1d957 execute_function_todo
../../gcc/passes.c:1990
0xc1e6c2 execute_todo
../../gcc/passes.c:2037

[Bug fortran/92872] New: [10 Regression] ICE in build_fold_indirect_ref_loc, at fold-const.c:14842

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

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

Bug ID: 92872
   Summary: [10 Regression] ICE in build_fold_indirect_ref_loc, at
fold-const.c:14842
   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: ---

Changed between 20190929 and 20191006 :
(with a legal z0 for reference)


$ cat z0.f90
subroutine s(x)
   integer, allocatable, optional :: x(:)
   x = [1, 2, 3]
end

$ gfortran-10-20191208 -c z0.f90



$ cat z1.f90
subroutine s(x) bind(c)
   integer, allocatable, optional :: x(:)
   x = [1, 2, 3]
end


$ gfortran-10-20190929 -c z1.f90
$
$ gfortran-10-20191208 -c z1.f90
z1.f90:3:0:

3 |x = [1, 2, 3]
  |
internal compiler error: Segmentation fault
0xd05dff crash_signal
../../gcc/toplev.c:328
0x9821e4 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3386
0x9821e4 build_fold_indirect_ref_loc(unsigned int, tree_node*)
../../gcc/fold-const.c:14842
0x715eef gfc_conv_scalarized_array_ref
../../gcc/fortran/trans-array.c:3511
0x716c54 gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*)
../../gcc/fortran/trans-array.c:3641
0x75679e gfc_conv_variable
../../gcc/fortran/trans-expr.c:2808
0x7514ba gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8665
0x75d677 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10884
0x709ee7 trans_code
../../gcc/fortran/trans.c:1864
0x74107d gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6801
0x6bafe6 translate_all_program_units
../../gcc/fortran/parse.c:6302
0x6bafe6 gfc_parse_file()
../../gcc/fortran/parse.c:6541
0x705fcf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/88624] [Coarray] Rejects allocatable coarray passed as a dummy argument

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

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #2 from G. Steinmetz  ---

Update :


$ cat z1.f90
subroutine g(x)
   real, allocatable :: x(:)[:]
   call h(x)
contains
   subroutine h(z)
  real :: z(:)[*]
   end
end


$ gfortran-10-20191208 -c z1.f90 -fcoarray=lib
z1.f90:3:0:

3 |call h(x)
  |
internal compiler error: in gfc_conv_procedure_call, at
fortran/trans-expr.c:6579
0x710ece gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.c:6578
0x745888 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
../../gcc/fortran/trans-stmt.c:406
0x6d6981 trans_code
../../gcc/fortran/trans.c:1932
0x6ffb24 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6801
0x688be6 translate_all_program_units
../../gcc/fortran/parse.c:6302
0x688be6 gfc_parse_file()
../../gcc/fortran/parse.c:6541
0x6d306f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug libgomp/92854] [OpenACC] Always-true conditional in 'libgomp/oacc-mem.c:acc_unmap_data'?

[jules at gcc dot gnu.org]

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

--- Comment #6 from jules at gcc dot gnu.org ---
Created attachment 47453
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47453=edit
Patch for acc_map_data-device_already-3.c problem

This patch fixes the acc_map_data-device_already-3.c problem, which I guess has
probably been broken forever. The single tgt_mem_desc used for all the function
and global variable mappings (created in gomp_load_image_to_device) does not
have its tgt_start and tgt_end fields set properly, so oacc-mem.c:lookup_dev
cannot find any global variable.

We can fix this by calculating the total address range covered by (the union
of) all offloaded functions and global variables, and set tgt_start and tgt_end
appropriately. We then go through each splay tree key's tgt_offset, and adjust
it to be an offset within that range.

I've yet to run full tests with this, but it works for the test case mentioned.

[Bug target/92841] Optimize -fstack-protector-strong code generation a bit

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 47452
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47452=edit
gcc10-pr92841.patch

Untested fix.

[Bug other/92871] New: new test case g++.dg/ext/temp-extend1.C fails starting with its introduction in r279069

[seurer at gcc dot gnu.org]

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

Bug ID: 92871
   Summary: new test case g++.dg/ext/temp-extend1.C fails starting
with its introduction in r279069
   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: ---

Executing on host: /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/ext/temp-extend1.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 
-std=gnu++14
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs

-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs

-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/.libs
-lm  -o ./temp-extend1.exe(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++/../../
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ext/temp-extend1.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
-std=gnu++14
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/.libs
-lm -o ./temp-extend1.exe
PASS: g++.dg/ext/temp-extend1.C  -std=gnu++14 (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/.libs:/home/seurer/gcc/build/gcc-test/gcc:.:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/.libs:/home/seurer/gcc/build/gcc-test/gcc:/home/seurer/gcc/build/gcc-test/./gmp/.libs:/home/seurer/gcc/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./isl/.libs:/home/seurer/gcc/build/gcc-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.4.0/lib64
Execution timeout is: 300
spawn [open ...]
FAIL: g++.dg/ext/temp-extend1.C  -std=gnu++14 execution test
Executing on host: /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/ext/temp-extend1.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 
-std=gnu++17
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs

-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs

[Bug other/92870] New: new test case gcc.dg/vect/vect-shift-5.c fails starting with its introduction in r279114

[seurer at gcc dot gnu.org]

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

Bug ID: 92870
   Summary: new test case gcc.dg/vect/vect-shift-5.c fails
starting with its introduction in r279114
   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: ---

xecuting 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/vect/vect-shift-5.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never   -maltivec -mpower8-vector
-ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model
-fno-common -O2 -fdump-tree-vect-details -S -o vect-shift-5.s(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/vect/vect-shift-5.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -maltivec -mpower8-vector
-ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model
-fno-common -O2 -fdump-tree-vect-details -S -o vect-shift-5.s
PASS: gcc.dg/vect/vect-shift-5.c (test for excess errors)
FAIL: gcc.dg/vect/vect-shift-5.c scan-tree-dump vect "vectorizable_shift
===[\\n\\r][^\\n]*prologue_cost = 0"
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/vect/vect-shift-5.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never  -flto -ffat-lto-objects
-maltivec -mpower8-vector -ftree-vectorize -fno-tree-loop-distribute-patterns
-fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -S -o
vect-shift-5.s(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/vect/vect-shift-5.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -flto -ffat-lto-objects
-maltivec -mpower8-vector -ftree-vectorize -fno-tree-loop-distribute-patterns
-fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -S -o
vect-shift-5.s
PASS: gcc.dg/vect/vect-shift-5.c -flto -ffat-lto-objects (test for excess
errors)
FAIL: gcc.dg/vect/vect-shift-5.c -flto -ffat-lto-objects  scan-tree-dump vect
"vectorizable_shift ===[\\n\\r][^\\n]*prologue_cost = 0"
testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vect/vect.exp
completed in 1 seconds

=== gcc Summary ===

# of expected passes2
# of unexpected failures2

[Bug c++/92869] g++ wrongly reports aggregate type as not-aggregate (when explicitly defaulted ctors are added)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #1 from Andrew Pinski  ---
Most likely does not implement the difference between C++11/14 and C++17 with
respect to default member initializers.

[Bug go/92861] Passes relative time to sem_timedwait on GNU/Hurd

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #7 from Ian Lance Taylor  ---
Patch committed.

[Bug c++/92869] New: g++ wrongly reports aggregate type as not-aggregate (when explicitly defaulted ctors are added)

[igor.chorazewicz at intel dot com]

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

Bug ID: 92869
   Summary: g++ wrongly reports aggregate type as not-aggregate
(when explicitly defaulted ctors are added)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: igor.chorazewicz at intel dot com
  Target Milestone: ---

The following code, when compiled with -std=c++17 results in "0" being printed.
The correct behavior is to print "1". Removing ctors fixes the issue, however,
accordingly to the standard, explicitly defaulted ctors are allowed for an
aggregate.

#include 
#include 
#include 

template 
struct A {
A() = default;
A(const A &) = default;
A(A &&) = default;

T arr[N];   
};

int main()
{
std::cout << std::is_aggregate>::value;
}

[Bug go/92861] Passes relative time to sem_timedwait on GNU/Hurd

[ian at gcc dot gnu.org]

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

--- Comment #6 from ian at gcc dot gnu.org  ---
Author: ian
Date: Mon Dec  9 18:03:53 2019
New Revision: 279136

URL: https://gcc.gnu.org/viewcvs?rev=279136=gcc=rev
Log:
PR go/92861
runtime: don't define CLOCK_REALTIME in os_hurd.go

It's already defined in sysinfo.go.

Patch by Samuel Thibault.

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/210538

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/go/runtime/os_hurd.go

[Bug go/92861] Passes relative time to sem_timedwait on GNU/Hurd

[ian at airs dot com]

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

--- Comment #5 from Ian Lance Taylor  ---
You can also just send patches to gcc-patc...@gcc.gnu.org and/or
gofrontend-...@googlegroups.com.

[Bug go/92866] [10 Regression] libgo build failure on arm-linux-gnueabihf (ICE, segfault)

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
This doesn't look like a Go problem, it looks like a backend problem.

[Bug tree-optimization/92868] [10 Regression] ICE: tree check: expected integer_cst, have ssa_name in to_wide, at tree.h:5855

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #4)
> The problem is fixed by the patch for PR 91582:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00478.html

That patch doesn't even mention the compute_objsize changes that matter most
for this in the ChangeLog entry.
The sign_mask > 0 case which is never possible is still in there etc.

[Bug tree-optimization/92868] [10 Regression] ICE: tree check: expected integer_cst, have ssa_name in to_wide, at tree.h:5855

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Martin Sebor  ---
The problem is fixed by the patch for PR 91582:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00478.html

[Bug c/92857] -Wsign-conversion flag issues false positives for expression using typedef'ed unsigned types

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Joshua Saxby from comment #2)
> (In reply to Richard Biener from comment #1)
> > I think the warning is about foo - bar being carried out in type 'int' due 
> > to
> > integer promotion and that converted to size_t which may turn the negative
> > result into a positive.
> 
> That could be the issue, although I would expect the integer promotion to
> promote to an unsigned integer type rather than a signed one. Am I mistaken
> in this assumption?

YES you are.  If a type is smaller than int and fits into int, then it is
prompoted to int (and not unsigned int).

[Bug tree-optimization/92868] [10 Regression] ICE: tree check: expected integer_cst, have ssa_name in to_wide, at tree.h:5855

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Martin, thanks for CC'ing me on bugs I cause, but please leave assigning them
to me or whoever might choose to come up with a fix before I get to it.

[Bug tree-optimization/92867] Use ERF_RETURNS_ARG in more places

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #6 from Martin Sebor  ---
The "returns-argument" attribute should also be used to help detect buffer
overflow after returning from functions declared with it (either built-ins or
user-defined):

__attribute__ ((returns_arg (1))) char* f (char*);

char a[4], b[8];

void g (void)
{
  memcpy (b, f (a), sizeof b);   // reads 8 bytes from a
}

[Bug target/92841] Optimize -fstack-protector-strong code generation a bit

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Reduced testcase that reproduces this with -O2 -fstack-protector-strong on
x86_64-linux -m64:
const struct S { int b; } c[] = {30, 12, 20, 0, 11};
void bar (int *);

void
foo (void)
{
  int e[4];
  const struct S *a;
  for (a = c; a < c + sizeof (c); a++)
if (a->b)
  bar (e);
}

[Bug c++/92852] [8/9/10 Regression] location references block not in block tree

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
Might be dup/related to bug 91165.

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[iii at linux dot ibm.com]

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

--- Comment #27 from Ilya Leoshkevich  ---
With

-DSPEC_CPU -DNDEBUG -DPERL_CORE   -O3 -save-temps=obj -fopt-info-vec-optimized 
 -DSPEC_CPU_LP64 -DSPEC_CPU_LINUX_X64 -fgnu89-inline

on gcc113 I can see 2% slowdown:

r277511 (without this fix): 880.09s
r277515 (with this fix):897.85s

The function that degraded the most is indeed S_regmatch:

$ perf diff perf-9760321.data perf-44b2b4c.data
32.24%   exe[.] S_regmatch
 8.92%   exe[.] S_find_byclass.isra.0 
 6.80%   +0.28%  libc-2.19.so   [.] 0x0007dec0
 5.20%   exe[.] S_regtry  

However, the "shape" of S_regmatch did not change, that is, when all
offsets and register numbers are replaced with "x" in the objdump
output, the old and the new versions are identical.  This hints at some
microarchitectural effect - aliasing in the branch predictor maybe?

From my perspective, this happens too often, so I use the following test
to rule this out: just add a nop at the beginning of the problematic
function. This changes all the offsets and makes aliasing situation
completely different.  And indeed, by adding a single nop to S_regmatch,
I get wildly different results (for now this is just 1 repeat, I will
run best-of-3 overnight):

r277511 (without this fix): 929.1s
r277515 (with this fix):931.48s

[Bug tree-optimization/92868] [10 Regression] ICE: tree check: expected integer_cst, have ssa_name in to_wide, at tree.h:5855

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
That code has lots of issues.  Some in patch form as I was going through them:
gimple_call_alloc_size: for the case when size is INTEGER_CST and it is the one
argument alloc_size, I don't see a reason not to return size earlier, there is
no need to wi::to_wide.  I don't see a point in computing rng1[0] and rng2[0]
when nothing really uses it (write-only element).  Some formatting and typo in
comment.

I don't understand why you are using wi::sign_mask, the normal test for
negative wide_int when it is treated as signed integer of the corresponding
precision is wi::neg_p, that is more readable and descriptive.  If something is
tested on the wide ints with extra precision and the ::from was UNSIGNED, that
is of course not possible, but sign_mask will not work in that case either. 
And if it is ::from with SIGNED, neg_p should work fine too.
There is a weird:
  wide_int declsize = wi::to_wide (size);
  if (wi::sign_mask (dstoffrng[0]) > 0)
declsize += dstoffrng[0];
that condition is never true, sign_mask will only ever return 0 or -1:
  return (HOST_WIDE_INT) (high) < 0 ? -1 : 0;
None of this fixes the ICE.  How exactly to fix that depends on whether *poff
can be something other than INTEGER_CST or not.  If it can be only INTEGER_CST,
then whatever code is setting *poff to non-INTEGER_CST should instead punt or
set to some safe value, whatever, if it can be anything, then while it is fine
to call functions like integer_zerop etc. on that, tree_int_cst_sgn requires
the argument to be INTEGER_CST only, so there needs to be TREE_CODE (*poff) ==
INTEGER_CST && tree_int_csgn (*poff) < 0 instead.  Or perhaps you want
!tree_expr_nonnegative_p (*poff) instead?

--- gcc/builtins.c.jj   2019-12-05 09:47:23.178710510 +0100
+++ gcc/builtins.c  2019-12-09 15:52:55.951404452 +0100
@@ -3746,36 +3746,33 @@ gimple_call_alloc_size (gimple *stmt)
 }

   tree size = gimple_call_arg (stmt, argidx1);
+  if (argidx2 > nargs && TREE_CODE (size) == INTEGER_CST)
+return size;

   wide_int rng1[2];
   if (TREE_CODE (size) == INTEGER_CST)
-rng1[0] = rng1[1] = wi::to_wide (size);
+rng1[1] = wi::to_wide (size);
   else if (TREE_CODE (size) != SSA_NAME
   || get_range_info (size, rng1, rng1 + 1) != VR_RANGE)
 return NULL_TREE;

-  if (argidx2 > nargs && TREE_CODE (size) == INTEGER_CST)
-return size;
-
   /* To handle ranges do the math in wide_int and return the product
  of the upper bounds as a constant.  Ignore anti-ranges.  */
-  tree n = argidx2 < nargs ? gimple_call_arg (stmt, argidx2) :
integer_one_node;
+  tree n
+= argidx2 < nargs ? gimple_call_arg (stmt, argidx2) : integer_one_node;
   wide_int rng2[2];
   if (TREE_CODE (n) == INTEGER_CST)
-rng2[0] = rng2[1] = wi::to_wide (n);
+rng2[1] = wi::to_wide (n);
   else if (TREE_CODE (n) != SSA_NAME
   || get_range_info (n, rng2, rng2 + 1) != VR_RANGE)
 return NULL_TREE;

-  /* Extend to the maximum precsion to avoid overflow.  */
+  /* Extend to the maximum precision to avoid overflow.  */
   const int prec = ADDR_MAX_PRECISION;
-  rng1[0] = wide_int::from (rng1[0], prec, UNSIGNED);
   rng1[1] = wide_int::from (rng1[1], prec, UNSIGNED);
-  rng2[0] = wide_int::from (rng2[0], prec, UNSIGNED);
   rng2[1] = wide_int::from (rng2[1], prec, UNSIGNED);

   /* Return the lesser of SIZE_MAX and the product of the upper bounds.  */
-  rng1[0] = rng1[0] * rng2[0];
   rng1[1] = rng1[1] * rng2[1];
   tree size_max = TYPE_MAX_VALUE (sizetype);
   if (wi::gtu_p (rng1[1], wi::to_wide (size_max, prec)))
@@ -3853,7 +3850,7 @@ compute_objsize (tree dest, int ostype,
  /* Ignore negative offsets for now.  For others,
 use the lower bound as the most optimistic
 estimate of the (remaining) size.  */
- if (wi::sign_mask (wioff))
+ if (wi::neg_p (wioff))
;
  else if (wi::ltu_p (wioff, wisiz))
{
@@ -3882,9 +3879,8 @@ compute_objsize (tree dest, int ostype,

  /* Ignore negative offsets for now.  For others,
 use the lower bound as the most optimistic
-estimate of the (remaining)size.  */
- if (wi::sign_mask (min)
- || wi::sign_mask (max))
+estimate of the (remaining) size.  */
+ if (wi::neg_p (min) || wi::neg_p (max))
;
  else if (wi::ltu_p (min, wisiz))
{
@@ -3912,8 +3908,7 @@ compute_objsize (tree dest, int ostype,
   if (!ostype)
 

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

[jules at gcc dot gnu.org]

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

--- Comment #2 from jules at gcc dot gnu.org ---
Again, please don't change this code under the feet of the refcount overhaul
patch! Using the (currently OpenMP-specific) GOMP_MAP_VARS_ENTER_DATA is going
to end up mighty confusing from OpenACC-specific code.

[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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #1 from Thomas Schwinge  ---
Created attachment 47451
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47451=edit
[WIP] [PR92848] [OpenACC] Use 'GOMP_MAP_VARS_ENTER_DATA' for dynamic data
lifetimes

Julian, your thoughts on the WIP patch I'm attaching, please?

As implied by
, using
'gomp_remove_var' instead of 'gomp_remove_var_async' is is not causing any
problems for nvptx offloading (strange?); does it for AMD GCN offloading?

[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #11 from Bill Schmidt  ---
Confirmed. ;-)  Is this ready to close?

[Bug libgomp/92843] [OpenACC] Disallow 'acc_delete' etc. for everything without a dynamic reference count

[jules at gcc dot gnu.org]

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

--- Comment #6 from jules at gcc dot gnu.org ---
Please don't start making changes to the reference-counting code that is being
replaced by my overhaul patch. The existing code was rewritten for a reason --
that being, I hit various problems with it (albeit long since forgotten) that
interfered with the manual deep-copy implementation. We have refcount
self-checking code for the overhauled code.

We can address corner-case bug fixes as follow-ons once the main overhaul patch
is committed.

[Bug c++/92838] ICE (internal compiler error) calling lambda object with requires clause (in in dependent_type_p)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-09
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Started with r277655, it was rejected before the revision.

[Bug tree-optimization/92868] [10 Regression] ICE: tree check: expected integer_cst, have ssa_name in to_wide, at tree.h:5855

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-12-09
 CC||marxin at gcc dot gnu.org
  Known to work||9.2.0
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||10.0

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

[Bug libgomp/92843] [OpenACC] Disallow 'acc_delete' etc. for everything without a dynamic reference count

[tschwinge at gcc dot gnu.org]

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

--- Comment #5 from Thomas Schwinge  ---
Created attachment 47450
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47450=edit
[WIP] [PR92843, or is this a separate PR?] Properly handly dynamic reference
counts for TODO'REFCOUNT_INFINITY'

Julian, please also have a look at the other WIP patch I'm attaching.  (I think
I convinced myself that this doesn't have to be a separate PR from this one.)

Your thoughts on that one?

[Bug middle-end/92825] Unnecesary stack protection in Firefox's LightPixel.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 47449
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47449=edit
gcc10-pr92825.patch

Untested fix.

[Bug libgomp/92843] [OpenACC] Disallow 'acc_delete' etc. for everything without a dynamic reference count

[tschwinge at gcc dot gnu.org]

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

--- Comment #4 from Thomas Schwinge  ---
Created attachment 47448
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47448=edit
[WIP] [PR92843] [OpenACC] Disallow 'acc_delete' etc. for TODOeverything without
a dynamic reference count

Julian, please have a look at the WIP patch I'm attaching.

Resolving the '#if 0' will of course depend on settling on a reading of the
interactions between structured and dynamic reference counting.  (Your thoughts
on that?)  Per my current understanding, we would simply drop the '#if 0'
block.

[Bug middle-end/91226] wrong propagation of non-canonical _Decimal64 and _Decimal128 constant (BID only)

[jsm28 at gcc dot gnu.org]

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

--- Comment #4 from Joseph S. Myers  ---
Fixed for GCC 10.  Leaving open for now for possible backports to GCC 9 and 8
branches as a wrong-code fix.

[Bug middle-end/91226] wrong propagation of non-canonical _Decimal64 and _Decimal128 constant (BID only)

[jsm28 at gcc dot gnu.org]

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

--- Comment #3 from Joseph S. Myers  ---
Author: jsm28
Date: Mon Dec  9 13:59:24 2019
New Revision: 279129

URL: https://gcc.gnu.org/viewcvs?rev=279129=gcc=rev
Log:
Fix libdecnumber handling of non-canonical BID significands (PR
middle-end/91226).

As reported in bug 91226, the libdecnumber code used on the host to
interpret DFP values in the BID encoding fails, for _Decimal64 and
_Decimal128, to check for the case where a significand is too large
and so specified in IEEE 754 to be a non-canonical encoding of the
zero significand.  This patch adds the required handling of that case,
together with tests both using -O2 (testing this host code) and -O0
(testing libgcc code, which already worked before the patch); the
tests also cover _Decimal32, which already had the required check.

In the _Decimal128 case, where the code previously completely ignored
the case where the first four bits of the combination field are 1100,
1101 or 1110, the logic for determining the correct quantum exponent
in that case is also newly added by this patch, so tests are added for
that as well (again, libgcc already handled it correctly when the
conversion was done at runtime rather than at compile time).

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

PR middle-end/91226
libdecnumber:
* bid/bid2dpd_dpd2bid.c (_bid_to_dpd64): Handle non-canonical
significands.
(_bid_to_dpd128): Likewise.  Check for case where combination
field starts 1100, 1101 or 1110.

gcc/testsuite:
* gcc.dg/dfp/bid-non-canonical-d128-1.c,
gcc.dg/dfp/bid-non-canonical-d128-2.c,
gcc.dg/dfp/bid-non-canonical-d128-3.c,
gcc.dg/dfp/bid-non-canonical-d128-4.c,
gcc.dg/dfp/bid-non-canonical-d32-1.c,
gcc.dg/dfp/bid-non-canonical-d32-2.c,
gcc.dg/dfp/bid-non-canonical-d64-1.c,
gcc.dg/dfp/bid-non-canonical-d64-2.c: New tests.

Added:
trunk/gcc/testsuite/gcc.dg/dfp/bid-non-canonical-d128-1.c
trunk/gcc/testsuite/gcc.dg/dfp/bid-non-canonical-d128-2.c
trunk/gcc/testsuite/gcc.dg/dfp/bid-non-canonical-d128-3.c
trunk/gcc/testsuite/gcc.dg/dfp/bid-non-canonical-d128-4.c
trunk/gcc/testsuite/gcc.dg/dfp/bid-non-canonical-d32-1.c
trunk/gcc/testsuite/gcc.dg/dfp/bid-non-canonical-d32-2.c
trunk/gcc/testsuite/gcc.dg/dfp/bid-non-canonical-d64-1.c
trunk/gcc/testsuite/gcc.dg/dfp/bid-non-canonical-d64-2.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libdecnumber/ChangeLog
trunk/libdecnumber/bid/bid2dpd_dpd2bid.c

[Bug libgomp/92854] [OpenACC] Always-true conditional in 'libgomp/oacc-mem.c:acc_unmap_data'?

[jules at gcc dot gnu.org]

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

--- Comment #5 from jules at gcc dot gnu.org ---
Huh, yes, I missed that line in the spec (about existing mappings). I'll have a
look at the test case you mentioned.

[Bug libgomp/92840] [OpenACC] Disallow 'acc_unmap_data' for everything other than 'acc_map_data'

[jules at gcc dot gnu.org]

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

--- Comment #2 from jules at gcc dot gnu.org ---
I think that looks OK, thanks.

[Bug rtl-optimization/90282] internal compiler error: qsort checking failed in snapshot-20190429

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

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

--- Comment #4 from Andreas Schwab  ---
Workaround: use release checking.

[Bug rtl-optimization/90282] internal compiler error: qsort checking failed in snapshot-20190429

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #3 from John Paul Adrian Glaubitz  ---
This problem is still present in r278870:

../../src/gcc/ubsan.c: In function 'tree_node* ubsan_type_descriptor(tree,
ubsan_print_style)':
../../src/gcc/ubsan.c:409:33: warning: unterminated quote character ''' in
format [-Wformat-diag]
  409 |   pp_printf (_name, "'%s%s%s%s%s%s%s",
  | ^
../../src/gcc/ubsan.c:428:36: warning: spurious trailing space in format
[-Wformat-diag]
  428 |   pp_printf (_name, "'%s ", tname);
  |^
../../src/gcc/ubsan.c:428:33: warning: unterminated quote character ''' in
format [-Wformat-diag]
  428 |   pp_printf (_name, "'%s ", tname);
  | ^
/<>/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/
-B/usr/lib/gcc-snapshot/ia64-linux-gnu/bin/ -nostdinc++
-B/<>/build/prev-ia64-linux-gnu/libstdc++-v3/src/.libs
-B/<>/build/prev-ia64-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/<>/build/prev-ia64-linux-gnu/libstdc++-v3/include/ia64-linux-gnu
 -I/<>/build/prev-ia64-linux-gnu/libstdc++-v3/include 
-I/<>/src/libstdc++-v3/libsupc++
-L/<>/build/prev-ia64-linux-gnu/libstdc++-v3/src/.libs
-L/<>/build/prev-ia64-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c  -DUSE_LIBUNWIND_EXCEPTIONS  -g -O2 -fno-checking -gtoggle -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../src/gcc
-I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include 
-I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../src/gcc/../libbacktrace   -o sancov.o -MT sancov.o
-MMD -MP -MF ./.deps/sancov.TPo ../../src/gcc/sancov.c
/<>/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/
-B/usr/lib/gcc-snapshot/ia64-linux-gnu/bin/ -nostdinc++
-B/<>/build/prev-ia64-linux-gnu/libstdc++-v3/src/.libs
-B/<>/build/prev-ia64-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/<>/build/prev-ia64-linux-gnu/libstdc++-v3/include/ia64-linux-gnu
 -I/<>/build/prev-ia64-linux-gnu/libstdc++-v3/include 
-I/<>/src/libstdc++-v3/libsupc++
-L/<>/build/prev-ia64-linux-gnu/libstdc++-v3/src/.libs
-L/<>/build/prev-ia64-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c  -DUSE_LIBUNWIND_EXCEPTIONS  -g -O2 -fno-checking -gtoggle -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../src/gcc
-I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include 
-I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../src/gcc/../libbacktrace   -o tree-call-cdce.o -MT
tree-call-cdce.o -MMD -MP -MF ./.deps/tree-call-cdce.TPo
../../src/gcc/tree-call-cdce.c
/<>/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/
-B/usr/lib/gcc-snapshot/ia64-linux-gnu/bin/ -nostdinc++
-B/<>/build/prev-ia64-linux-gnu/libstdc++-v3/src/.libs
-B/<>/build/prev-ia64-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/<>/build/prev-ia64-linux-gnu/libstdc++-v3/include/ia64-linux-gnu
 -I/<>/build/prev-ia64-linux-gnu/libstdc++-v3/include 
-I/<>/src/libstdc++-v3/libsupc++
-L/<>/build/prev-ia64-linux-gnu/libstdc++-v3/src/.libs
-L/<>/build/prev-ia64-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c  -DUSE_LIBUNWIND_EXCEPTIONS  -g -O2 -fno-checking -gtoggle -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../src/gcc
-I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include 
-I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../src/gcc/../libbacktrace   -o tree-cfg.o -MT
tree-cfg.o -MMD -MP -MF ./.deps/tree-cfg.TPo ../../src/gcc/tree-cfg.c
../../src/gcc/tree-call-cdce.c: In function 'void
gen_shrink_wrap_conditions(gcall*, vec, unsigned int*)':
../../src/gcc/tree-call-cdce.c:793:1: error: qsort comparator non-negative on
sorted output: 1
  793 | }
  | ^
during RTL pass: mach
../../src/gcc/tree-call-cdce.c:793:1: internal compiler error: qsort checking
failed
0x444ce41f qsort_chk_error
../../src/gcc/vec.c:214
0x444cf3bf qsort_chk(void*, unsigned long, unsigned long, int (*)(void
const*, void const*, void*), void*)
../../src/gcc/vec.c:256
0x4458daaf gcc_qsort(void*, unsigned long, unsigned long, int (*)(void
const*, void const*))
../../src/gcc/sort.cc:270
0x440b72ff ready_sort_real

[Bug libgomp/92840] [OpenACC] Disallow 'acc_unmap_data' for everything other than 'acc_map_data'

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #1 from Thomas Schwinge  ---
Created attachment 47447
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47447=edit
[PR92840] [OpenACC] Refuse 'acc_unmap_data' unless mapped by 'acc_map_data'

Julian, any comments on the attached patch?

The TODO we shall deal with later; certainly not a priority right now.

[Bug go/92861] Passes relative time to sem_timedwait on GNU/Hurd

[samuel.thiba...@ens-lyon.org]

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

Samuel Thibault  changed:

   What|Removed |Added

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

--- Comment #4 from Samuel Thibault  ---
Reopening the bug for the fix to be commited

[Bug go/92861] Passes relative time to sem_timedwait on GNU/Hurd

[samuel.thiba...@ens-lyon.org]

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

--- Comment #3 from Samuel Thibault  ---
Created attachment 47446
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47446=edit
fix duplicate definition

Ah, sorry, _CLOCK_REALTIME is actually already getting defined in the generated
libgo/runtime_sysinfo.go file, the attached patch is needed on top of what was
already committed.

[Bug tree-optimization/92867] Use ERF_RETURNS_ARG in more places

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
GCC already has various attributes that take argument positions, e.g. the
nonnull, alloc_size, format, format_arg, so we should follow what is used for
those for this argument.
E.g. for format_arg we document:
 The parameter STRING-INDEX specifies which argument is the format
 string argument (starting from one).  Since non-static C++ methods
 have an implicit 'this' argument, the arguments of such methods
 should be counted from two.
and similarly for format, for nonnull and alloc_size we don't, so it might be
worth checking what we actually do.
There is also the case of an artificial argument holding address to the return
slot, I think that is what comes up only in RTL and would hope RTL handles it
right, but it is worth checking that too.

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

[crazylht at gmail dot com]

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

--- Comment #5 from Hongtao.liu  ---
(In reply to Richard Biener from comment #4)
> (In reply to Hongtao.liu from comment #3)
> > Since TARGET_XOP only supports 128-bit vector compare,
> > ix86_valid_mask_cmp_mode should also handle 256/512-bit vector compare when
> > avx512f is avalable.
> > 
> > 
> > untested patch
> > 
> > @@ -3428,7 +3428,7 @@ static bool
> >  ix86_valid_mask_cmp_mode (machine_mode mode)
> >  {
> >/* XOP has its own vector conditional movement.  */
> > -  if (TARGET_XOP)
> > +  if (TARGET_XOP && GET_MODE_SIZE (mode) == 128)
> >  return false;
> 
> Shouldn't we do sth like TARGET_XOP && !TARGET_AVX512F instead?  That is
> maybe simply elide that check completely, not sure why it was added.
True, thanks
> 
> >/* AVX512F is needed for mask operation.  */
> > 
> > I'll add some testcase later.

[Bug libgomp/92503] [OpenACC] Behavior of 'acc_free' if the memory space is still used in a mapping

[tschwinge at gcc dot gnu.org]

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

--- Comment #2 from Thomas Schwinge  ---
Created attachment 47445
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47445=edit
[PR92503] [OpenACC] Don't silently 'acc_unmap_data' in 'acc_free'

(In reply to jules from comment #1)
> FWIW, I don't think we should do this implicit unmapping

Julian, please have a look at the patch I'm attaching.

There are nvptx offloading TODOs in
'libgomp.oacc-c-c++-common/acc_free-pr92503-4.c',
'libgomp.oacc-c-c++-common/acc_free-pr92503-4-2.c'.  Can you easily (please
don't spend much time on this) what's going wrong?  Otherwise I shall commit
that XFAILed.

Please also verify whether there are any changes necessary for AMD GCN
offloading, in particular un-XFAILing the two nvptx ones, I suppose?


> particularly since
> it implies an expensive device-to-host-address lookup.

ACK.  That's not yet done; let's first wait what OpenACC is going to require.

I had the idea that we might actually keep such additional/expensive
sanity-checking, but guard it by an environment variable.

[Bug tree-optimization/92867] Use ERF_RETURNS_ARG in more places

[drepper.fsp+rhbz at gmail dot com]

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

Ulrich Drepper  changed:

   What|Removed |Added

 CC||drepper.fsp+rhbz at gmail dot 
com

--- Comment #4 from Ulrich Drepper  ---
This BZ came out of a discussion around C++ function call chaining along the
line of:

void f1(std::string& s, int a)
{
  std::cout << "hello " << s;
  if (a != 0)
std::cout << a;
  std::cout << '\n';
}

The 'if' prevents one single series of calls through operator<< from being used
and the compiler has reload std::cout from memory every time.  There are ugly
work-arounds in the source to get the desired behaviour but this should happen
automatically.  The work-arounds are too ugly and there is lots of code out
there.

One way would be to expose a way to specify one of the arguments is returned. 
Jakub mentioned that there is already internally a way to use the "fn spec"
attribute.  How about exposing this explicitly as a function attribute?

Jakub also raised the point how this should be applied to member functions.  I
suggest that the parameter for the attribute is really a number (not parameter
name) and that argument 1 (or 0, if you want the count start at zero) refers to
'this' in case of member functions.

How about this?

[Bug libgomp/92854] [OpenACC] Always-true conditional in 'libgomp/oacc-mem.c:acc_unmap_data'?

[tschwinge at gcc dot gnu.org]

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

--- Comment #4 from Thomas Schwinge  ---
Created attachment 47444
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47444=edit
[WIP] 'libgomp.oacc-c-c++-common/acc_map_data-device_already-*.c',
'libgomp.oacc-c-c++-common/acc_map_data-host_already-*.c'

(In reply to jules from comment #2)
> For strictly-paired acc_map_data/acc_unmap_data calls that don't interfere
> with other mappings -- no, probably not. But (like I guess you noticed too)
> the existing code feels wrong (or at least ugly) nonetheless.

;-)

> It's probably possible to come up with a legal (but odd) test case

Odd is not the problem -- actual users are doing such things, too.

> in which
> the condition is false -- maybe something like this (untested!):
> 
> int arr1[100], arr2[100], arr3[100];
> 
> void foo (void)
> {
>   #pragma acc data copy(arr1) copy(arr2) copy(arr3)
>   {
> void *darr2 = acc_deviceptr (arr2);
> acc_map_data (arr2, darr2, sizeof (arr2));
> [...]
> acc_unmap_data (arr2);
>   }
> }
> 
> Now I think the acc_map_data call will reuse the tgt for the structured data
> mapping, which binds together several array copies into a single device
> block. Forcing the first key's refcount to infinity (as is done in the
> current implementation of acc_map_data) is also wrong in that case.

In these cases, 'acc_map_data' will (should) refuse because "address [...] is
already mapped", see the test cases I'm attaching.  (ACK?)


Can you easily (please don't spend much time on this) tell what's wrong with
'libgomp.oacc-c-c++-common/acc_map_data-device_already-3.c' (see TODOs
therein).  If not, then we shall file a separate PR for this OpenACC 'declare'
case -- GCC's OpenACC 'declare' implementation has many other issues, after
all.

[Bug middle-end/92410] Invalid access to df->insns[] in regstat_bb_compute_calls_crossed (caught by hwasan)

[matmal01 at gcc dot gnu.org]

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

--- Comment #8 from Matthew Malcomson  ---
Author: matmal01
Date: Mon Dec  9 12:03:53 2019
New Revision: 279124

URL: https://gcc.gnu.org/viewcvs?rev=279124=gcc=rev
Log:
[mid-end] Add notes to dataflow insn info when re-emitting (PR92410)

In scheduling passes, notes are removed with `remove_notes` before the
scheduling is done, and added back in with `reemit_notes` once the
scheduling has been decided.

This process leaves the notes in the RTL chain with different insn uid's
than were there before.  Having different UID's (larger than the
previous ones) means that DF_INSN_INFO_GET(insn) will access outside of
the allocated array.

This has been seen in the `regstat_bb_compute_calls_crossed` function.
This patch adds an assert to the `regstat_bb_compute_calls_crossed`
function so that bad accesses here are caught instead of going
unnoticed, and then avoids the problem.

We avoid the problem by ensuring that new notes added by `reemit_notes` have an
insn record given to them.  This is done by adding a call to
`df_insn_create_insn_record` on each note added in `reemit_notes`.
`df_insn_create_insn_record` leaves this new record zeroed out, which appears
to be fine for notes (e.g. `df_bb_refs_record` already does not set
anything except the luid for notes, and notes have no dataflow information to
record).

We add the testcase that Martin found here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410#c2 .
This testcase fails with the "regstat.c" change, and then succeeds with the
"haifa-sched.c" change.

There is a similar problem with labels, that the `gcc_assert` catches
when running regression tests in gcc.dg/fold-eqandshift-1.c and
gcc.c-torture/compile/pr32482.c.
This is due to the `cfg_layout_finalize` call in `bb-reorder.c` emitting
new labels, and these labels not having a dataflow df_insn_info member.

We solve this by manually calling `df_recompute_luids` on each basic
block once this pass has finished.

Testing done:
  Ran regression tests on aarch64-none-linux-gnu cross compiler.
  Bootstrapped and ran tests on aarch64-none-linux-gnu native.

gcc/ChangeLog:

2019-12-09  Matthew Malcomson  

PR middle-end/92410
* bb-reorder.c (pass_reorder_blocks::execute): Recompute
dataflow luids once basic blocks have been reordered.
* haifa-sched.c (reemit_notes): Create df insn record for each
new note.
* regstat.c (regstat_bb_compute_calls_crossed): Assert every
insn has an insn record before trying to use it.

gcc/testsuite/ChangeLog:

2019-12-09  Matthew Malcomson  

PR middle-end/92410
* gcc.dg/torture/pr92410.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr92410.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/bb-reorder.c
trunk/gcc/haifa-sched.c
trunk/gcc/regstat.c
trunk/gcc/testsuite/ChangeLog

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[marxin at gcc dot gnu.org]

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

Bug 92832 Summary: valgrind error in incorporate_penalties
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92832

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

[Bug ipa/92832] valgrind error in incorporate_penalties

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Martin Liška  ---
Yes, I can confirm that --expensive-definedness-checks=yes fixed that.

[Bug ipa/92832] valgrind error in incorporate_penalties

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
I have a reduced test-case, but thanks.

[Bug tree-optimization/92867] Use ERF_RETURNS_ARG in more places

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Sure, go ahead.

[Bug tree-optimization/92867] Use ERF_RETURNS_ARG in more places

[prathamesh3492 at gcc dot gnu.org]

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||prathamesh3492 at gcc dot 
gnu.org

--- Comment #2 from prathamesh3492 at gcc dot gnu.org ---
If it's OK, I will try to implement this.

Thanks,
Prathamesh

[Bug c/92857] -Wsign-conversion flag issues false positives for expression using typedef'ed unsigned types

[joshua.a.saxby at gmail dot com]

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

--- Comment #3 from Joshua Saxby  ---
I can confirm that if `MyUnsigned` is changed to `unsigned char`, the issue
persists, however if it is changed to `unsigned int`, the issue is not present.

[Bug libgomp/92511] [OpenACC] Support subset subarray mappings

[tschwinge at gcc dot gnu.org]

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

--- Comment #3 from Thomas Schwinge  ---
Author: tschwinge
Date: Mon Dec  9 11:40:36 2019
New Revision: 279122

URL: https://gcc.gnu.org/viewcvs?rev=279122=gcc=rev
Log:
[PR92511] More testing for OpenACC "present" subarrays

In particular, "subset subarrays".

libgomp/
PR libgomp/92511
* testsuite/libgomp.oacc-c-c++-common/copyin-devptr-1.c: Remove
this file...
* testsuite/libgomp.oacc-c-c++-common/copyin-devptr-2.c: ..., and
this file...
* testsuite/libgomp.oacc-c-c++-common/lib-22.c: ..., and this
file...
* testsuite/libgomp.oacc-c-c++-common/lib-30.c: ..., and this
file...
* testsuite/libgomp.oacc-c-c++-common/subset-subarray-mappings-1-r-p.c:
... with their content moved into, and extended in this new file.
* testsuite/libgomp.oacc-c-c++-common/subset-subarray-mappings-1-d-a.c:
New file.
* testsuite/libgomp.oacc-c-c++-common/subset-subarray-mappings-1-d-p.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/subset-subarray-mappings-1-r-a.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/subset-subarray-mappings-2.c:
Likewise.

Added:
   
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/subset-subarray-mappings-1-d-a.c
   
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/subset-subarray-mappings-1-d-p.c
   
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/subset-subarray-mappings-1-r-a.c
   
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/subset-subarray-mappings-1-r-p.c
   
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/subset-subarray-mappings-2.c
Removed:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/copyin-devptr-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/copyin-devptr-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-22.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-30.c
Modified:
trunk/libgomp/ChangeLog

[Bug libgomp/92854] [OpenACC] Always-true conditional in 'libgomp/oacc-mem.c:acc_unmap_data'?

[tschwinge at gcc dot gnu.org]

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

--- Comment #3 from Thomas Schwinge  ---
Author: tschwinge
Date: Mon Dec  9 11:40:17 2019
New Revision: 279120

URL: https://gcc.gnu.org/viewcvs?rev=279120=gcc=rev
Log:
[PR92854] Add 'libgomp.oacc-c-c++-common/pr92854-1.c'

... to document the status quo.

libgomp/
PR libgomp/92854
* testsuite/libgomp.oacc-c-c++-common/pr92854-1.c: New file.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr92854-1.c
Modified:
trunk/libgomp/ChangeLog