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

[thenlich+gccbug at gmail dot com]

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

--- Comment #10 from Thomas Henlich  ---
(In reply to Jerry DeLisle from comment #5)
> Author: jvdelisle
> Date: Thu Nov 28 18:33:20 2019
> New Revision: 278817
> 
> URL: https://gcc.gnu.org/viewcvs?rev=278817&root=gcc&view=rev
> Log:
>   PR fortran/90374
>   * io.c (check_format): Allow zero width expoenent with e0.
> 
>   * io/format.c (parse_format_list): Relax format checking to allow
>   e0 exponent specifier.
> 
>   * gfortran.dg/fmt_zero_width.f90: Update test.
> 
> Modified:
> trunk/gcc/fortran/ChangeLog
> trunk/gcc/fortran/io.c
> trunk/gcc/testsuite/ChangeLog
> trunk/gcc/testsuite/gfortran.dg/fmt_zero_width.f90
> trunk/libgfortran/ChangeLog
> trunk/libgfortran/io/format.c
> trunk/libgfortran/io/write_float.def

fmt_zero_width.f90:
  ..
  write (aresult,fmt="(E0.10e0)") rn
  if (aresult /= "0.313928E-02") stop 39

Shouldn't that be (according to Fortran 2018):
  if (aresult /= "0.313928E-2") stop 39

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.
...

[Bug fortran/92863] New: ICE in gfc_typename

[asolokha at gmx dot com]

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

Bug ID: 92863
   Summary: ICE in gfc_typename
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gfortran-10.0.0-alpha20191208 snapshot (r279100) ICEs when compiling the
following testcase:

type(l1) function mp()
  call sub(mp)
end function mp

function bi(ry)
  call sub(ry)
end function bi

% powerpc-e300c3-linux-gnu-gfortran-10.0.0-alpha20191208 -c pws8056f.f90
pws8056f.f90:1:0:

1 | type(l1) function mp()
  | 
Error: The type for function 'mp' at (1) is not accessible
f951: internal compiler error: Segmentation fault
0xe74916 crash_signal
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191208/work/gcc-10-20191208/gcc/toplev.c:328
0x860c1b sprintf
/usr/include/bits/stdio2.h:36
0x860c1b gfc_typename(gfc_typespec*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191208/work/gcc-10-20191208/gcc/fortran/misc.c:167
0x834466 compare_parameter
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191208/work/gcc-10-20191208/gcc/fortran/interface.c:2399
0x834466 gfc_compare_actual_formal(gfc_actual_arglist**, gfc_formal_arglist*,
int, int, bool, locus*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191208/work/gcc-10-20191208/gcc/fortran/interface.c:3149
0x9749ef check_externals_procedure
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191208/work/gcc-10-20191208/gcc/fortran/frontend-passes.c:5410
0x97a9a3 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191208/work/gcc-10-20191208/gcc/fortran/frontend-passes.c:5039
0x97c24f gfc_check_externals(gfc_namespace*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191208/work/gcc-10-20191208/gcc/fortran/frontend-passes.c:5496
0x885704 gfc_parse_file()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191208/work/gcc-10-20191208/gcc/fortran/parse.c:6494
0x8d3fbe gfc_be_parse_file
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.0_alpha20191208/work/gcc-10-20191208/gcc/fortran/f95-lang.c:210

[Bug tree-optimization/92862] New: Suspicious codes in tree-ssa-loop-niter.c and predict.c

[fxue at os dot amperecomputing.com]

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

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

Function loop_only_exit_p() in tree-ssa-loop-niter.c:

  for (i = 0; i < loop->num_nodes; i++)
{
  for (bsi = gsi_start_bb (body[i]); !gsi_end_p (bsi); gsi_next (&bsi))
if (stmt_can_terminate_bb_p (gsi_stmt (bsi)))
  {
return true;
  }
}

we should return false, not true?


Function predict_paths_leading_to_edge() in predict.c:

 FOR_EACH_EDGE (e2, ei, bb->succs)
if (e2->dest != e->src && e2->dest != e->dest
&& !unlikely_executed_edge_p (e)
&& !dominated_by_p (CDI_POST_DOMINATORS, e->src, e2->dest))
  {
has_nonloop_edge = true;
break;
  }

"e" is loop invariant, I guess that unlikely_executed_edge_p (e) might be
unlikely_executed_edge_p (e2), which is more reasonable. And we can find
similar code in predict_paths_for_bb () that uses the latter.

[Bug target/29997] [meta-bug] various targets: GCC fails to encode epilogues in unwind-info

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #8 from Eric Gallager  ---
(In reply to Ian Lance Taylor from comment #6)
> All the insns in sh_expand_epilogue need to be examined to see if they need
> REG_CFA notes.  Some of them already have them.  I don't know what more are
> needed.
> 
> For example, look at the changes made to the i386 backend when rth added the
> general support for unwinding through epilogues:
> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00277.html

cc-ing rth then, if his changes are relevant here...

[Bug other/12955] Incorrect rounding of soft float denorm mul/div

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||geoffk at gcc dot gnu.org

--- Comment #14 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #8)
> I could not find any more mention of this after
> ,
> was there another patch.

cc-ing Geoffrey Keating from that thread

[Bug target/92686] Inefficient mask operation for 128/256-bit vector VCOND_EXPR under avx512f

[crazylht at gmail dot com]

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

Hongtao.liu  changed:

   What|Removed |Added

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

--- Comment #6 from Hongtao.liu  ---
Fixed in GCC10.

[Bug target/80969] [8 Regression] ICE in ix86_expand_prologue, at config/i386/i386.c:14606

[crazylht at gmail dot com]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #8 from Hongtao.liu  ---
ICE in r279107, I think my patch trigger some potential bug.

/export/users/liuhongt/gcc/gnu-toolchain/gcc/gcc/testsuite/gcc.target/i386/pr80969-1.c:
In function ‘main’:
/export/users/liuhongt/gcc/gnu-toolchain/gcc/gcc/testsuite/gcc.target/i386/pr80969-1.c:16:1:
internal compiler error: in sp_valid_at, at config/i386/i386.c:6160
0x747bd7 sp_valid_at
../../../gcc/gnu-toolchain/gcc/gcc/config/i386/i386.c:6160
0x10ded88 choose_basereg
../../../gcc/gnu-toolchain/gcc/gcc/config/i386/i386.c:6196
0x10df115 choose_baseaddr
../../../gcc/gnu-toolchain/gcc/gcc/config/i386/i386.c:6309
0x10df1b6 ix86_emit_save_reg_using_mov
../../../gcc/gnu-toolchain/gcc/gcc/config/i386/i386.c:6358
0x10f450e ix86_emit_save_sse_regs_using_mov
../../../gcc/gnu-toolchain/gcc/gcc/config/i386/i386.c:6447
0x10f55b0 ix86_expand_prologue()
../../../gcc/gnu-toolchain/gcc/gcc/config/i386/i386.c:8248
0x14368ba gen_prologue()
../../../gcc/gnu-toolchain/gcc/gcc/config/i386/i386.md:13130
0x10e5988 target_gen_prologue
../../../gcc/gnu-toolchain/gcc/gcc/config/i386/i386.md:19667
0xabcdb7 make_prologue_seq
../../../gcc/gnu-toolchain/gcc/gcc/function.c:5779
0xabcf82 thread_prologue_and_epilogue_insns()
../../../gcc/gnu-toolchain/gcc/gcc/function.c:5896
0xabd672 rest_of_handle_thread_prologue_and_epilogue
../../../gcc/gnu-toolchain/gcc/gcc/function.c:6387
0xabd672 execute
../../../gcc/gnu-toolchain/gcc/gcc/function.c:6463
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Same error for pr80969-4.c.

[Bug target/92686] Inefficient mask operation for 128/256-bit vector VCOND_EXPR under avx512f

[liuhongt at gcc dot gnu.org]

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

--- Comment #5 from liuhongt at gcc dot gnu.org ---
Author: liuhongt
Date: Mon Dec  9 04:16:24 2019
New Revision: 279107

URL: https://gcc.gnu.org/viewcvs?rev=279107&root=gcc&view=rev
Log:
Enable mask movement for VCOND_EXPR under avx512f for
128/256-bit vector when integer mask is available.

Changelog
gcc/
PR target/92686
* config/i386/sse.md
(*_cmp3,
*_cmp3,
*_ucmp3,
*_ucmp3): New.
* config/i386/i386.c (ix86_print_operand): New operand substitution.
* config/i386/i386-expand.c (ix86_valid_mask_cmp_mode):
New function.
(ix86_expand_sse_cmp): Relax condition for integer mask from
512-bit vector to all 128/256/512-bit vector. Delete code gen
for avx512f compare patterns since we have generic pattern now.
(ix86_expand_sse_movcc): Adjust condition and codegen for
maskcmp.
(ix86_expand_int_sse_cmp): Don't canonicalize the comparison
when corresponding vector compare is available.

gcc/testsuite/
* gcc.target/i386/pr92686.inc: New file.
* gcc.target/i386/avx512bw-pr92686-vpcmp-1.c: New test.
* gcc.target/i386/avx512bw-pr92686-vpcmp-intelasm-1.c: Ditto.
* gcc.target/i386/avx512bw-pr92686-vpcmp-2.c: Ditto.
* gcc.target/i386/avx512vl-pr92686-vpcmp-1.c: Ditto.
* gcc.target/i386/avx512vl-pr92686-vpcmp-intelasm-1.c: Ditto.
* gcc.target/i386/avx512vl-pr92686-vpcmp-2.c: Ditto.
* gcc.target/i386/avx512bw-pr92686-movcc-1.c: Ditto.
* gcc.target/i386/avx512bw-pr92686-movcc-2.c: Ditto.
* gcc.target/i386/avx512vl-pr92686-movcc-1.c: Ditto.
* gcc.target/i386/avx512vl-pr92686-movcc-2.c: Ditto.
* gcc.target/i386/avx512vl-pr88547-1.c: Adjust testcase.
* gcc.target/i386/pr88547-1.c: Ditto.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr92686-movcc-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr92686-movcc-2.c
trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr92686-vpcmp-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr92686-vpcmp-2.c
trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr92686-vpcmp-intelasm-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr92686-movcc-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr92686-movcc-2.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr92686-vpcmp-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr92686-vpcmp-2.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr92686-vpcmp-intelasm-1.c
trunk/gcc/testsuite/gcc.target/i386/pr92686.inc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-expand.c
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr88547-1.c
trunk/gcc/testsuite/gcc.target/i386/pr88547-1.c

[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 #2 from Ian Lance Taylor  ---
Thanks, committed.

[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 #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Mon Dec  9 03:43:33 2019
New Revision: 279106

URL: https://gcc.gnu.org/viewcvs?rev=279106&root=gcc&view=rev
Log:
PR go/92861
runtime: use absolute time for sem_timedwait

Patch by Samuel Thibault.

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

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

[Bug target/92822] [10 Regression] testsuite failures on aarch64 after r278938

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-09
 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |10.0
Summary|regressions on aarch64  |[10 Regression] testsuite
   |after r278938   |failures on aarch64 after
   ||r278938
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

>FAIL: gcc.target/aarch64/singleton_intrinsics_1.c scan-assembler-times 
>aarch64_get_lanev2di 2
Works now.

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

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

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

Bug ID: 92861
   Summary: Passes relative time to sem_timedwait on GNU/Hurd
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: samuel.thiba...@ens-lyon.org
CC: cmang at google dot com
  Target Milestone: ---

Created attachment 47442
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47442&action=edit
proposed fix

In src/libgo/go/runtime/os_hurd.go, a relative time is set in var ts, and &ts
is passed to sem_timedwait. But sem_timedwait expects an absolute time, not a
relative time. The attached patch fixes this by using the time from
clock_gettime(CLOCK_REALTIME), like is done in os_aix.go.

[Bug c++/92851] Lambda capture of *this with mutable is not mutable

[flast at flast dot jp]

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

--- Comment #2 from Kohei Takahashi  ---
(In reply to Jonathan Wakely from comment #1)
> Please provide a complete testcase not a URL, as required by
> https://gcc.gnu.org/bugs/

Sorry, here is reproducible complete code.


struct S
{
int a;

void foo() const
{
[*this]() mutable
{
a = 0;
}();
}
};


GCC rejects with following message, but clang not.


prog.cc: In lambda function:
prog.cc:9:15: error: assignment of member 'S::a' in read-only object
9 | a = 0;
  | ~~^~~

[Bug c++/92851] Lambda capture of *this with mutable is not mutable

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-12-08
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Please provide a complete testcase not a URL, as required by
https://gcc.gnu.org/bugs/

[Bug c++/92859] compiler treats enum type as an integer during overload resolution when a bit-field of this enum is considered

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-08
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
N.B. GCC 7 is no longer supported by the GCC project.

Confirmed as a bug in supported releases though (and svn trunk).

[Bug c++/92856] incorrectly accepts invalid C++11 braced initialisation of double from long double

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> The behaviour is by design

And documented, see
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-Wnarrowing

"For C++11 and later standards, narrowing conversions are diagnosed by default,
as required by the standard. A narrowing conversion from a constant produces an
error, and a narrowing conversion from a non-constant produces a warning, but
-Wno-narrowing suppresses the diagnostic. Note that this does not affect the
meaning of well-formed code; narrowing conversions are still considered
ill-formed in SFINAE contexts."

[Bug libstdc++/92853] std::filesystem::path::operator+=(std::filesystem::path const&) corrupts the heap

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
The problem is that the trailing slash in the right operand gets processed
twice:

977 if (it != last && it->_M_type() == _Type::_Root_dir)
978   {
979 ++it;
980 if (it == last)
981   {
982 // This root-dir becomes a trailing slash
983 auto pos = _M_pathname.length() + p._M_pathname.length();
984 ::new(output++) _Cmpt({}, _Type::_Filename, pos);
985 ++_M_cmpts._M_impl->_M_size;
986   }
987   }
...
999 if (is_dir_sep(_M_pathname.back()))
1000  {
1001::new(output++) _Cmpt({}, _Type::_Filename, _M_pathname.length());
1002++_M_cmpts._M_impl->_M_size;│
1003  }

Which is easily fixed:

--- a/libstdc++-v3/src/c++17/fs_path.cc
+++ b/libstdc++-v3/src/c++17/fs_path.cc
@@ -975,16 +975,7 @@ path::operator+=(const path& p)
}

   if (it != last && it->_M_type() == _Type::_Root_dir)
-   {
- ++it;
- if (it == last)
-   {
- // This root-dir becomes a trailing slash
- auto pos = _M_pathname.length() + p._M_pathname.length();
- ::new(output++) _Cmpt({}, _Type::_Filename, pos);
- ++_M_cmpts._M_impl->_M_size;
-   }
-   }
+   ++it;

   while (it != last)
{

[Bug c++/92855] -fvisibility-inlines-hidden failing to hide out-of-line copies of certain inline member functions

[thiago at kde dot org]

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

--- Comment #5 from Thiago Macieira  ---
(In reply to Alexander Monakov from comment #4)
> (FWIW, making 'f' a template in your example makes it non-hidden)
> 
> Can you explain why you expect the command-line option to override the
> attribute on the namespace? GCC usually implements the opposite, i.e.
> attributes prevail over the defaults specified on the command line.
> 
> In your sample on Godbolt, Clang also appears to honour the attribute rather
> than the option.

And ICC does the opposite and hides everything. Either way, GCC's behaviour of
applying this to templates (which is bug 47877, so you may close as duplicate)
is unexpected and seems inconsistent.

I expect the emitted function to be hidden because it's inline and because of
-fvisibility-inlines-hidden. From the TexInfo manual:

 The effect of this is that GCC may, effectively, mark inline
 methods with '__attribute__ ((visibility ("hidden")))' so that they
 do not appear in the export table of a DSO and do not require a PLT
 indirection when used within the DSO.  Enabling this option can
 have a dramatic effect on load and link times of a DSO as it
 massively reduces the size of the dynamic export table when the
 library makes heavy use of templates.

Since the out-of-line copies of the inline functions will be emitted in every
TU that failed to inline them, and thus remain in every DSO, there's no need to
export them. Each DSO can call its own, local copy through PC-relative calls
and jumps.

For the particular problem at hand, which we're still debugging, see
https://bugreports.qt.io/browse/QTBUG-80535. The issue there is that certain
non-Qt symbols were exported by the DSO and thus got tagged with the ELF
version "Qt_5". That by itself is not a problem, but we've found that some
applications began referencing those symbols with that ELF version and we don't
understand why. The result is that the internal details of how something was
implemented became part of our ABI.

[Bug c/87488] hyperlink filenames in diagnostics

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #21 from Eric Botcazou  ---
*** Bug 92858 has been marked as a duplicate of this bug. ***

[Bug other/92858] [10 regression] spurious backslashes around switch string in warning messages

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Eric Botcazou  ---
Yes, thanks, I missed it.

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

[Bug libstdc++/92853] std::filesystem::path::operator+=(std::filesystem::path const&) corrupts the heap

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-12-08
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |9.3
 Ever confirmed|0   |1

[Bug libstdc++/92850] clang has already supported concepts in latest trunk. However it does not define __cpp_concepts macro. I defined it but crashes clang compiler

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to fdlbxtqi from comment #2)
> "Are you sure concepts are fully implemented in clang?"
> 
> Yes, but feature testing macro is missing.

No, it very obviously doesn't support concepts:

https://godbolt.org/z/n4AkpC

So that will be why it doesn't define the macro.

[Bug libstdc++/92850] clang has already supported concepts in latest trunk. However it does not define __cpp_concepts macro. I defined it but crashes clang compiler

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
If the macro is not defined it's either a clang bug, or is intentional because
the implementation is not finished.

It is undefined for you to define any __cpp* macro yourself.

[Bug c++/92856] incorrectly accepts invalid C++11 braced initialisation of double from long double

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
The standard requires a diagnostic for this, and GCC issues a diagnostic. The
behaviour is by design and not a bug.

Use -Werror=narrowing if you want an error.

[Bug other/92858] [10 regression] spurious backslashes around switch string in warning messages

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
In konsole?  See PR87488.

[Bug tree-optimization/65424] gcc does not recognize byte swaps implemented as loop.

[pavel.kryukov at phystech dot edu]

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

Pavel I. Kryukov  changed:

   What|Removed |Added

 CC||pavel.kryukov at phystech dot 
edu

--- Comment #5 from Pavel I. Kryukov  ---
Could you please tell if there is any progress?
I use C++ templates to do low-level byte operations for BE CPU simulator hosted
on LE machine. The example is here: https://godbolt.org/z/ff-NAF (I replaced
template type with a define, but it does not change output a lot).

[Bug c++/92855] -fvisibility-inlines-hidden failing to hide out-of-line copies of certain inline member functions

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #4 from Alexander Monakov  ---
(FWIW, making 'f' a template in your example makes it non-hidden)

Can you explain why you expect the command-line option to override the
attribute on the namespace? GCC usually implements the opposite, i.e.
attributes prevail over the defaults specified on the command line.

In your sample on Godbolt, Clang also appears to honour the attribute rather
than the option.

[Bug c++/92855] -fvisibility-inlines-hidden failing to hide out-of-line copies of certain inline member functions

[thiago at kde dot org]

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

--- Comment #3 from Thiago Macieira  ---
The symbol in question is inline, therefore -fvisibility-inlines-hidden should
trigger and cause it to become hidden too.

Testcase showing that GCC will apply that:

#define VISIBILITY(x) __attribute__((visibility(#x)))

namespace N VISIBILITY(default) {
void other();

inline void f()
{
other();
}

void g() { f(); }
}

If you compile this with -fno-inline to cause f() to be emitted, you'll see:

.section.text.N::f(),"axG",@progbits,N::f(),comdat
.p2align 4
.weak   N::f()
.hidden N::f()
.type   N::f(), @function
N::f():
jmp N::other()
.size   N::f(), .-N::f()

See: https://gcc.godbolt.org/z/nW3RbX

So I contend that the symbol should have been hidden and wasn't because of a
bug. Please reconsider.

[Bug libfortran/92836] segfault with inquire()

[tkoenig at gcc dot gnu.org]

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

--- Comment #14 from Thomas Koenig  ---
Created attachment 47441
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47441&action=edit
Output of valgrind --tool=helgrind

The code from https://gcc.gnu.org/ml/fortran/2019-12/msg00020.html :


program inq
  use OMP_Lib
  implicit none
  logical :: s
  character(len=27) :: c
  integer :: i, j

  i=64
  !$omp parallel private(c,j,s)
  do while (.true.)
 if (OMP_Get_Thread_Num() < omp_get_num_threads()/2) then
open(newUnit=j,file='test.txt',form='formatted',status='unknown')
write (c,'(e17.10)') 1.23456d0
write (j,*) trim(c)
close(j)
 else
inquire(file='test.txt',exist=s)
 end if
  end do
  !$omp end parallel
end program

certainly raises a few flags using valgrind --tool=helgrind (see attachment);
apart from the things that happen in libgomp (see PR40362), there are also
fishy things going on in libgfortran:

==4669== Possible data race during write of size 8 at 0x645E9E8 by thread #5
==4669== Locks held: 1, at address 0x645EAC0
==4669==at 0x5099EA0: _gfortrani_new_unit (open.c:566)
==4669==by 0x509A7FC: already_open (open.c:720)
==4669==by 0x509A7FC: _gfortran_st_open (open.c:897)
==4669==by 0x400BED: MAIN__._omp_fn.0 (in /tmp/a.out)
==4669==by 0x5611065: gomp_thread_start (team.c:123)
==4669==by 0x4C315BD: mythread_wrapper (hg_intercepts.c:389)
==4669==by 0x5C9A723: start_thread (in /lib64/libpthread-2.22.so)
==4669==by 0x5F9BE8C: clone (in /lib64/libc-2.22.so)
==4669== 
==4669== This conflicts with a previous read of size 8 by thread #16
==4669== Locks held: 1, at address 0x52F94C0
==4669==at 0x50A39D1: find_file0 (unix.c:1722)
==4669==by 0x50A39EE: find_file0 (unix.c:1741)
==4669==by 0x50A514A: _gfortrani_find_file (unix.c:1779)
==4669==by 0x509258C: _gfortran_st_inquire (inquire.c:803)
==4669==by 0x400B5C: MAIN__._omp_fn.0 (in /tmp/a.out)
==4669==by 0x5611065: gomp_thread_start (team.c:123)
==4669==by 0x4C315BD: mythread_wrapper (hg_intercepts.c:389)
==4669==by 0x5C9A723: start_thread (in /lib64/libpthread-2.22.so)
==4669==  Address 0x645e9e8 is 8 bytes inside a block of size 752 alloc'd
==4669==at 0x4C2DA51: calloc (vg_replace_malloc.c:762)
==4669==by 0x4E5D612: _gfortrani_xcalloc (memory.c:78)
==4669==by 0x50A2B17: insert_unit (unit.c:233)
==4669==by 0x50A2D77: get_gfc_unit (unit.c:356)
==4669==by 0x509A788: _gfortran_st_open (open.c:889)
==4669==by 0x400BED: MAIN__._omp_fn.0 (in /tmp/a.out)
==4669==by 0x5611065: gomp_thread_start (team.c:123)
==4669==by 0x4C315BD: mythread_wrapper (hg_intercepts.c:389)
==4669==by 0x5C9A723: start_thread (in /lib64/libpthread-2.22.so)
==4669==by 0x5F9BE8C: clone (in /lib64/libc-2.22.so)
==4669==  Block was alloc'd by thread #5

...

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

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #10 from Thomas Koenig  ---
I cannot reproduce the error any more with cygwin's current 8.3.0
(testing), so it seems to be fixed in the meantime.

Could you confirm that?  If so, we could mark this as FIXED.

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

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||tkoenig at gcc dot gnu.org

--- Comment #9 from Thomas Koenig  ---
Here's where it segfaults with 7.4.0:

(gdb) r
Starting program: /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/f951.exe tst.f
-ffixed-form -quiet -dumpbase tst.f -mtune=generic -march=x86-64 -auxbase tst
-g -ffpe-trap=zero,overflow,underflow -fdollar-ok -fintrinsic-modules-path
/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/finclude -o /tmp/ccuPm0Se.s
[New Thread 12104.0x2468]
[New Thread 12104.0x2650]
[New Thread 12104.0x2e74]
[New Thread 12104.0x2600]
[New Thread 12104.0x2368]

Thread 1 received signal SIGSEGV, Segmentation fault.
0x0001004fcf20 in build_common_decl (is_init=false, union_type=, com=0x6001e8870) at
/usr/src/debug/gcc-7.4.0-1/gcc/fortran/trans-common.c:463
463   attributes = gfc_add_attributes_to_decl (com->head->attr,
NULL_TREE);
(gdb) p com
$1 = (gfc_common_head *) 0x6001e8870
(gdb) p com->head
$2 = (gfc_symbol *) 0x0

$4 = {where = {nextc = 0x6000d6a60, lb = 0x6000d6a10}, use_assoc = 0 '\000',
saved = 0 '\000', threadprivate = 0 '\000', omp_declare_target = 0 '\000',
omp_declare_target_link = 0 '\000', name = "__BLNK__", '\000' , head = 0x0, binding_label = 0x0,
  is_bind_c = 0, refs = 0}

Backtrace:

#0  0x0001004fcf20 in build_common_decl (is_init=false,
union_type=, com=0x6001e8870) at
/usr/src/debug/gcc-7.4.0-1/gcc/fortran/trans-common.c:463
#1  create_common (com=com@entry=0x6001e8870, head=head@entry=0x60020bff0,
saw_equiv=) at
/usr/src/debug/gcc-7.4.0-1/gcc/fortran/trans-common.c:672
#2  0x0001004fd4c9 in translate_common (common=0x6001e8870,
var_list=) at
/usr/src/debug/gcc-7.4.0-1/gcc/fortran/trans-common.c:1213
#3  0x0001004fd6d0 in gfc_trans_common (ns=ns@entry=0x60017dc10) at
/usr/src/debug/gcc-7.4.0-1/gcc/fortran/trans-common.c:1300
#4  0x00010050aac4 in gfc_generate_function_code (ns=0x60017dc10) at
/usr/src/debug/gcc-7.4.0-1/gcc/fortran/trans-decl.c:6235
#5  0x0001004983af in translate_all_program_units
(gfc_global_ns_list=) at
/usr/src/debug/gcc-7.4.0-1/gcc/fortran/parse.c:6075
#6  gfc_parse_file () at /usr/src/debug/gcc-7.4.0-1/gcc/fortran/parse.c:6275
#7  0x0001004df32b in gfc_be_parse_file () at
/usr/src/debug/gcc-7.4.0-1/gcc/fortran/f95-lang.c:204
#8  0x0001008fd8ac in compile_file () at
/usr/src/debug/gcc-7.4.0-1/gcc/toplev.c:467
#9  0x0001010e7b8d in do_compile () at
/usr/src/debug/gcc-7.4.0-1/gcc/toplev.c:2003
#10 toplev::main (this=this@entry=0xca46, argc=,
argc@entry=17, argv=, argv@entry=0xcac0) at
/usr/src/debug/gcc-7.4.0-1/gcc/toplev.c:2138
#11 0x000101107545 in main (argc=17, argv=0xcac0) at
/usr/src/debug/gcc-7.4.0-1/gcc/main.c:39

[Bug tree-optimization/92860] [8/9/10 regression] Global flags affected by -O settings are clobbered by optimize attribute

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-08
Summary|[8,9,10 regression] Global  |[8/9/10 regression] Global
   |flags affected by -O|flags affected by -O
   |settings are clobbered by   |settings are clobbered by
   |optimize attribute  |optimize attribute
 Ever confirmed|0   |1

--- Comment #2 from Jan Hubicka  ---
Partly fixed on trunk - I think we have other flags/params missing Optimization
attribute that behaves same way.

[Bug tree-optimization/92860] [8,9,10 regression] Global flags affected by -O settings are clobbered by optimize attribute

[hubicka at gcc dot gnu.org]

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

--- Comment #1 from Jan Hubicka  ---
Author: hubicka
Date: Sun Dec  8 13:50:32 2019
New Revision: 279089

URL: https://gcc.gnu.org/viewcvs?rev=279089&root=gcc&view=rev
Log:
PR tree-optimization/92860
* common.opt (fprofile-reorder-functions, ftoplevel-reorder): Add
Optimization flag.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/common.opt

[Bug tree-optimization/92860] New: [8,9,10 regression] Global flags affected by -O settings are clobbered by optimize attribute

[hubicka at gcc dot gnu.org]

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

Bug ID: 92860
   Summary: [8,9,10 regression] Global flags affected by -O
settings are clobbered by optimize attribute
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

Hi,
the following testcase:
void linker_error();
__attribute__ ((optimize("-O0")))
int a ()
{
}
static int remove_me ()
{
  linker_error ();
}
void
main()
{
}

builds with GCC6 but not with GCC8, GCC9 and GCC10:
hubicka@lomikamen-jh:/aux/hubicka/trunk4/gcc$ gcc -O2 t.c
hubicka@lomikamen-jh:/aux/hubicka/trunk4/gcc$
/aux/hubicka/trunk-install/bin/gcc -O2 t.c
/usr/local/bin/ld: /tmp/cckSFE5R.o: in function `remove_me':
t.c:(.text+0x17): undefined reference to `linker_error'
collect2: error: ld returned 1 exit status

The problem is that while processing the optimize attribute for a we overwritte
flag_toplevel_reorder that is affected by optimization flag but not marked as
Optimization.  I suppose there are other cases like this.

[Bug c++/92859] New: compiler treats enum type as an integer during overload resolution when a bit-field of this enum is considered

[armagvvg at gmail dot com]

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

Bug ID: 92859
   Summary: compiler treats enum type as an integer during
overload resolution when a bit-field of this enum is
considered
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: armagvvg at gmail dot com
  Target Milestone: ---

Created attachment 47440
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47440&action=edit
gzipped preprocessed file

Enumeration types are different from their underlying types when participating
in function overload resolution. But the compiler doesn't differentiate them
when a bit-field member is defined from the enumeration type. And an overloaded
stream operator is defined inside a class where that enum exists. The sample:


#include 

struct ES { 
enum E { v }; 

// 1
friend std::ostream& operator<<(std::ostream& os, E) { return os << "E"; }
};

// 2 - should be the same but...
// std::ostream& operator<<(std::ostream& os, ES::E) { return os << "E"; }

struct S {
ES::E e : 1; 
};

int main() {
S s{}; 
std::cout << s.e << std::endl;
return 0;
}


It's expected that an output should be 'E' thus calling the operator<<(..., E)
defined here. But 's.e' field is considered integer and '0' is printed.

What's more interesting, if the operator will be defined as marked by '2', all
it works as expected.

Compiled with: g++ -Wall -Wextra -std=c++11 --save-temps -o tst.gcc tst.cpp
No output during compilation.

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

> uname -r
5.0.0-32-generic

I've repeated this bug also on my work with gcc 9.1.0. The same behaviour using
-std=c++14 and -std=c++17.

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

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #3 from Thomas Koenig  ---
Fixed. Thanks for the bug report!

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

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Dec  8 13:42:42 2019
New Revision: 279088

URL: https://gcc.gnu.org/viewcvs?rev=279088&root=gcc&view=rev
Log:
Error on Associate with a program.

2018-12-08  Thomas Koenig  

PR fortran/92780
* resolve.c (resolve_assoc_var): Issue error if the associating
entity is a program.

2018-12-08  Thomas Koenig  

PR fortran/92780
* gfortran.dg/associate_50.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/associate_50.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/92764] ICE in gfc_procedure_use

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Koenig  ---
Fixed on trunk.

Thanks for the bug report!

[Bug fortran/92764] ICE in gfc_procedure_use

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Dec  8 13:02:54 2019
New Revision: 279087

URL: https://gcc.gnu.org/viewcvs?rev=279087&root=gcc&view=rev
Log:
2018-12-08  Thomas Koenig  

PR fortran/92764
* interface.c (gfc_procedure_use): Check for existence of derived
component before using (twice).

2018-12-08  Thomas Koenig  

PR fortran/92764
* gfortran.dg/interface_44.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/interface_44.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/92755] [10 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2123

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #3 from Thomas Koenig  ---
Fixed.

Thanks a lot for the bug report!

[Bug fortran/92755] [10 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2123

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Dec  8 12:25:15 2019
New Revision: 279086

URL: https://gcc.gnu.org/viewcvs?rev=279086&root=gcc&view=rev
Log:
2019-12-08  Thomas Koenig  

PR fortran/92755
* dependency.c (gfc_dep_resolver):  Move skipping of _data ref
into the loop.

2019-12-08  Thomas Koenig  

PR fortran/92755
* gfortran.dg/dependency_57.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/dependency_57.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dependency.c
trunk/gcc/testsuite/ChangeLog

[Bug libgomp/40362] openmp: some libgomp functions trigger data races

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #16 from Thomas Koenig  ---
Looking at a simple OMP program, I now get conflicts reported by
valgrind which I do not see here:

program main
  implicit none
  integer, parameter :: n = 100
  real, dimension(n) :: a
  real, dimension(n,n) :: b
  integer :: i, j, n1, n2
  call random_number (a)
!$omp parallel private(i,j)
!$omp do
  do j=1,n
 do i=1,n
b(i,j) = a(i) * a(j)
 end do
  end do
!$omp end parallel
  read (*,*) n1, n2
  print *,b(n1, n2)
end program main
$ gfortran -g -fopenmp -fcheck=all do.f90
$ echo 10 10 | valgrind --tool=helgrind ./a.out  2>&1 | head -60
==4359== Helgrind, a thread error detector
==4359== Copyright (C) 2007-2017, and GNU GPL'd, by OpenWorks LLP et al.
==4359== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==4359== Command: ./a.out
==4359== 
==4359== ---Thread-Announcement--
==4359== 
==4359== Thread #1 is the program's root thread
==4359== 
==4359== ---Thread-Announcement--
==4359== 
==4359== Thread #16 was created
==4359==at 0x5F9BE4E: clone (in /lib64/libc-2.22.so)
==4359==by 0x5C993AF: create_thread (in /lib64/libpthread-2.22.so)
==4359==by 0x5C9AECA: pthread_create@@GLIBC_2.2.5 (in
/lib64/libpthread-2.22.so)
==4359==by 0x4C313C9: pthread_create_WRK (hg_intercepts.c:427)
==4359==by 0x4C324BF: pthread_create@* (hg_intercepts.c:460)
==4359==by 0x561167A: gomp_team_start (team.c:836)
==4359==by 0x5609CFC: GOMP_parallel (parallel.c:169)
==4359==by 0x400B45: MAIN__ (do.f90:8)
==4359==by 0x400D1E: main (do.f90:18)
==4359== 
==4359== 
==4359== 
==4359== Possible data race during write of size 4 at 0x645BC00 by thread #1
==4359== Locks held: none
==4359==at 0x56138DB: gomp_barrier_wait_end (bar.c:40)
==4359==by 0x56138DB: gomp_barrier_wait_end (bar.c:35)
==4359==by 0x5611AA0: gomp_simple_barrier_wait (simple-bar.h:60)
==4359==by 0x5611AA0: gomp_team_start (team.c:850)
==4359==by 0x5609CFC: GOMP_parallel (parallel.c:169)
==4359==by 0x400B45: MAIN__ (do.f90:8)
==4359==by 0x400D1E: main (do.f90:18)
==4359== 
==4359== This conflicts with a previous read of size 4 by thread #16
==4359== Locks held: none
==4359==at 0x561392B: gomp_barrier_wait_start (bar.h:98)
==4359==by 0x561392B: gomp_barrier_wait (bar.c:56)
==4359==by 0x5611032: gomp_simple_barrier_wait (simple-bar.h:60)
==4359==by 0x5611032: gomp_thread_start (team.c:117)
==4359==by 0x4C315BD: mythread_wrapper (hg_intercepts.c:389)
==4359==by 0x5C9A723: start_thread (in /lib64/libpthread-2.22.so)
==4359==by 0x5F9BE8C: clone (in /lib64/libc-2.22.so)
==4359==  Address 0x645bc00 is 128 bytes inside a block of size 192 alloc'd
==4359==at 0x4C2B831: malloc (vg_replace_malloc.c:309)
==4359==by 0x56040E8: gomp_malloc (alloc.c:38)
==4359==by 0x5611278: gomp_get_thread_pool (pool.h:42)
==4359==by 0x5611278: get_last_team (team.c:150)
==4359==by 0x5611278: gomp_new_team (team.c:169)
==4359==by 0x5609CE5: GOMP_parallel (parallel.c:169)
==4359==by 0x400B45: MAIN__ (do.f90:8)
==4359==by 0x400D1E: main (do.f90:18)
==4359==  Block was alloc'd by thread #1
==4359== 
==4359== 
==4359== 
==4359== Possible data race during write of size 4 at 0x645BBC4 by thread #1
==4359== Locks held: none
==4359==at 0x56138E1: gomp_barrier_wait_end (bar.c:41)
==4359==by 0x56138E1: gomp_barrier_wait_end (bar.c:35)

... and so on.

I would have to dig a bit deeper into this to see if this is valid.

This is with current trunk and valgrind 3.15.0 on x86_64-pc-linux-gnu.

[Bug other/92858] New: [10 regression] spurious backslashes around switch string in warning messages

[ebotcazou at gcc dot gnu.org]

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

Bug ID: 92858
   Summary: [10 regression] spurious backslashes around switch
string in warning messages
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: minor
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ebotcazou at gcc dot gnu.org
  Target Milestone: ---

The switch string is printed between a pair of backslashes in warning messages,
which doesn't seem to be a progress.  Consider the following C file:

int A[128];

inline void
fill (int *a, int n)
{
  for (int i = 0; i < n; i++)
a[i] = i * 2 - n;
}

int get (int i)
{
  fill (A, 128);
  return A[i];
}

compiled at -O -fno-early-inlining --param max-inline-insns-single=0 -Winline:

t.c: In function 'get':
t.c:4:1: warning: inlining failed in call to 'fill': --param
max-inline-insns-single limit reached [\-Winline\]
4 | fill (int *a, int n)
  | ^~~~
t.c:12:3: note: called from here
   12 |   fill (A, 128);
  |   ^

With the GCC 9 compiler, the message is:

t.c: In function 'get':
t.c:4:1: warning: inlining failed in call to 'fill': --param
max-inline-insns-single limit reached [-Winline]
4 | fill (int *a, int n)
  | ^~~~
t.c:12:3: note: called from here
   12 |   fill (A, 128);
  |   ^

which looks fine.

[Bug c/92857] New: -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

Bug ID: 92857
   Summary: -Wsign-conversion flag issues false positives for
expression using typedef'ed unsigned types
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joshua.a.saxby at gmail dot com
  Target Milestone: ---

Created attachment 47439
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47439&action=edit
Full pre-processed source of the minimal code sample required to produce the
erroneous behaviour

When using typedef'ed unsigned types in an arithmetic expression and compiling
with GCC's -Wsign-conversion flag, GCC produces a false positive warning about
sign conversion as a result of the expression.

Here is a minimal code sample (gcc_sign_conversion_warning_bug.c):

#include 
#include 

typedef uint8_t MyUnsigned;

int main(void) {
MyUnsigned foo = 3U;
MyUnsigned bar = 2U;
// conversion to ‘unsigned int’ from ‘int’ may change the sign of the
result
size_t baz = foo - bar + 1U;
// ^
return (int)baz;
}

(the full preprocessed source is also attached as a file to this bug report)

Essential information:

- GCC version 5.4.0 20160609

- Running on Ubuntu 16.04

- GCC build-time options: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.12' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu

- Command line that triggers the bug: gcc -v -save-temps -std=gnu99
-Wsign-conversion gcc_sign_conversion_warning_bug.c

- The erroneous warning message produced is: 
gcc_sign_conversion_warning_bug.c:16:28: warning: conversion to ‘unsigned int’
from ‘int’ may change the sign of the result [-Wsign-conversion]
 size_t baz = foo - bar + 1U;
^
Additional information:

I have used the online Compiler Explorer at godbolt.org to verify that this
issue is also present on all GCC versions from 5.4 through 9.2 inclusive. If it
is useful to anyone, there is a link to this online sample here:
https://godbolt.org/z/-2jSYx

I have also tested this on the Clang compiler on the same system used to verify
the GCC sample and Clang does not issue a warning (same warning flag was used).

[Bug c++/92856] New: incorrectly accepts invalid C++11 braced initialisation of double from long double

[marc at kdab dot com]

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

Bug ID: 92856
   Summary: incorrectly accepts invalid C++11 braced
initialisation of double from long double
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc at kdab dot com
  Target Milestone: ---

The following code:

   // https://godbolt.org/z/tWa2dr
   int main() {
   extern long double ld;
   double d{ld};
   }

is invalid according to [dcl.list.init]3.9
(http://eel.is/c++draft/dcl.init.list#3.9): regardless of a target's actual
size for these types, long double -> double is considered a narrowing
conversion [dcl.list.init]/7 (http://eel.is/c++draft/dcl.init.list#7.2), and
the compiler cannot use the constant expression loophole here.

Clang and MSVC correctly error on this.

Actual behaviour: GCC only warns (-Wnarrowing), even with -pedantic.

Expected behaviour: GCC does not accept this code.

This bug exists in all compiler versions, afaict (4.7.4, 4.8.3, 9.1, trunk).