[Bug libstdc++/79833] std::put_time has the wrong values for 2 digit years

[ryxi at stu dot xidian.edu.cn]

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||ryxi at stu dot xidian.edu.cn

--- Comment #1 from Xi Ruoyao  ---
Created attachment 40949
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40949=edit
patch of this issue

My patch to make "%y" (including "%D"), "%Y", and "%C" conforming
to POSIX.

If this is OK I'll send it in GCC 8 stage 1.

BTW there are several other issues about non-conforming time_get.
For example PR 71557, PR 71637 and PR 45896.

[Bug c++/78999] problem with gcc on cygwin??? cygwin 2.6.1 with gcc 5.4.0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Andrew Pinski  ---
.

[Bug c++/78999] problem with gcc on cygwin??? cygwin 2.6.1 with gcc 5.4.0

[bplummer at hotmail dot com]

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

--- Comment #2 from Brian Plummer  ---
You can close this bug.  

I uninstalled/reinstalled Cygwin a number of times from different mirror sites
and finally got a good install.  Here are my thoughts:

1.  I disabled my AntiVirus software (AVG Free).
2.  I tried a number of mirror-sites.  This one worked for me:
mirrors.xmission.com(http)
3.  But, on all of the mirror sites I tried, the install process would
periodically hang requiring me the stop and restart the process.
4.  I don't think the hanging caused any problems...because when it finally
finished the Hash check on all the packages passed.

So, what really happened here?  I just can't say.  Could be that the
distributions at some of the mirrors are corrupt or incomplete.  Could be that
my AntiVirus software was causing some kind of problem although it never
complained.  I only know that I got a clean install with my AntiVirus disabled.
 I turned it back on when the install completed and everything appeared to work
as I would expect.  It could be that the hangs that I described were causing
some kind of problem, but I cannot say what it might be especially when the
Hash check passed.  That's all I've got.

So, again please close this case.

Thanks!!

[Bug fortran/80009] Printing/writing a structure with a real edit descriptor.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-12
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Works for me (outputs 5.5 at run time) on x86_64-apple-darwin from 4.3.1 up to
trunk (7.0 r246000).

[Bug c++/80008] internal compiler error: in cp_parser_direct_declarator, at cp/parser.c:20031 [C++17]

[julien at lecomte dot at]

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

Julien  changed:

   What|Removed |Added

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

--- Comment #3 from Julien  ---
fixed in 7.0.1 20170312

[Bug c++/80008] internal compiler error: in cp_parser_direct_declarator, at cp/parser.c:20031 [C++17]

[julien at lecomte dot at]

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

--- Comment #2 from Julien  ---
fixed in 7.0.1 20170312

[Bug c++/80008] internal compiler error: in cp_parser_direct_declarator, at cp/parser.c:20031 [C++17]

[julien at lecomte dot at]

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

--- Comment #1 from Julien  ---
Forgot to add this:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/usr/local --enable-languages=c,c++
--disable-multilib --disable-bootstrap --with-system-zlib --disable-nls
--libexecdir=/usr/local/lib
Thread model: posix
gcc version 7.0.1 20170305 (experimental) (GCC)

And lastly:
gmp-6.1.2
mpc-1.0.3
mpfr-3.1.5

[Bug fortran/80009] Printing/writing a structure with a real edit descriptor.

[walt.brainerd at gmail dot com]

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

--- Comment #1 from Walt Brainerd  ---
Forgot to add:

Pls see F08 std 9.6.3(7) 2nd bullet

[Bug fortran/80009] New: Printing/writing a structure with a real edit descriptor.

[walt.brainerd at gmail dot com]

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

Bug ID: 80009
   Summary: Printing/writing a structure with a real edit
descriptor.
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: walt.brainerd at gmail dot com
  Target Milestone: ---

Created attachment 40948
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40948=edit
bug.f90, the file compiled as shown in Description/Comment

$ gfortran --version bug.f90
GNU Fortran (GCC) 7.0.1 20170122 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Walt@HP_Envy /cygdrive/c/walt/ZHI/FC/FC_Code
$ ./a
At line 48 of file bug.f90 (unit = 6, file = 'stdout')
Fortran runtime error: Expected REAL for item 1 in formatted transfer, got
CLASS or DERIVED
(f4.1)
 ^

Error termination. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open
#0  0x
#1  0x
#2  0x
#3  0x
#4  0x
#5  0x
#6  0x
#7  0x
#8  0x
#9  0x
#10  0x
#11  0x
#12  0x
#13  0x

[Bug c++/80008] New: internal compiler error: in cp_parser_direct_declarator, at cp/parser.c:20031 [C++17]

[julien at lecomte dot at]

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

Bug ID: 80008
   Summary: internal compiler error: in
cp_parser_direct_declarator, at cp/parser.c:20031
[C++17]
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: julien at lecomte dot at
  Target Milestone: ---

Created attachment 40947
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40947=edit
json_scanner.ii

gcc (GCC) 7.0.1 20170305 (experimental)
libtoolize (GNU libtool) 2.4.2

$ cat /etc/debian_version
8.7

# command:
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -Iinclude -std=c++17 -Wfatal-errors
-MT src/json_scanner.lo -MD -MP -MF src/.deps/json_scanner.Tpo -c
src/json_scanner.cxx  -fPIC -DPIC -o src/.libs/json_scanner.o

# notable env:
CXXFLAGS=-std=c++17 -Wfatal-errors
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games



src/json_scanner.cxx:6:1: internal compiler error: in
cp_parser_direct_declarator, at cp/parser.c:20031
 json_scanner(std::istream& is)
 ^~~~
0x77e21f cp_parser_direct_declarator
../../gcc/cp/parser.c:20031
0x77e21f cp_parser_declarator
../../gcc/cp/parser.c:19502
0x792c7d cp_parser_init_declarator
../../gcc/cp/parser.c:19047
0x793bd8 cp_parser_simple_declaration
../../gcc/cp/parser.c:12781
0x7948b1 cp_parser_block_declaration
../../gcc/cp/parser.c:12599
0x79b6a0 cp_parser_declaration
../../gcc/cp/parser.c:12496
0x79baa4 cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:12372
0x79c17c cp_parser_namespace_body
../../gcc/cp/parser.c:18274
0x79c17c cp_parser_namespace_definition
../../gcc/cp/parser.c:18250
0x79b7cb cp_parser_declaration
../../gcc/cp/parser.c:12480
0x79baa4 cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:12372
0x79bde8 cp_parser_translation_unit
../../gcc/cp/parser.c:4366
0x79bde8 c_parse_file()
../../gcc/cp/parser.c:38427
0x901eb2 c_common_parse_file()
../../gcc/c-family/c-opts.c:1107

[Bug ada/80007] --disable-bootstrap with gnat-5 leads to failed gnat-7 build on aarch64

[tulipawn at gmail dot com]

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

--- Comment #4 from PeteVine  ---
> Can you try again without --disable-bootstrap ?

It's GNAT 5.4.0. OK, I'll try again.

[Bug ada/80007] --disable-bootstrap with gnat-5 leads to failed gnat-7 build on aarch64

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to PeteVine from comment #2)
> Right, I definitely used the same setup a few days ago minus
> --disable-bootstrap.

Can you try again without --disable-bootstrap ?  

What GCC exact version are you starting with?

[Bug ada/80007] --disable-bootstrap with gnat-5 leads to failed gnat-7 build on aarch64

[tulipawn at gmail dot com]

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

--- Comment #2 from PeteVine  ---
Right, I definitely used the same setup a few days ago minus
--disable-bootstrap.

[Bug ada/80007] --disable-bootstrap with gnat-5 leads to failed gnat-7 build on aarch64

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
So without --disable-bootstrap, the build is successive?

If so then the bug is in GCC 5 rather than GCC 7.

[Bug ada/80007] New: --disable-bootstrap with gnat-5 leads to failed gnat-7 build on aarch64

[tulipawn at gmail dot com]

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

Bug ID: 80007
   Summary: --disable-bootstrap with gnat-5 leads to failed gnat-7
build on aarch64
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tulipawn at gmail dot com
  Target Milestone: ---

Never tried bootstrapping ada this way before (a full bootstrap succeeded a few
days ago), so I'm not entirely sure if that's allowed/advisable but I got the
following failure:

/mnt/odroid/gcc-master/build/./gcc/xgcc -B/mnt/odroid/gcc-master/build/./gcc/
-B/usr/gcc7/aarch64-linux-gnu/bin/ -B/usr/gcc7/aarch64-linux-gnu/lib/ -isystem
/usr/gcc7/aarch64-linux-gnu/include -isystem
/usr/gcc7/aarch64-linux-gnu/sys-include-c -g -O2  -fPIC  -W -Wall -gnatpg
-nostdinc   g-exptty.adb -o g-exptty.o
+===GNAT BUG DETECTED==+
| 7.0.1 20170311 (experimental) (aarch64-linux-gnu) Program_Error unhandled
signal|
| Error detected at s-stoele.adb:36:20 |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

system.ads
g-exptty.adb
g-exptty.ads
g-expect.ads
gnat.ads
g-os_lib.ads
s-os_lib.ads
s-string.ads
ada.ads
a-uncdea.ads
g-regpat.ads
s-regpat.ads
g-tty.ads
s-oscons.ads
interfac.ads
i-c.ads
s-parame.ads
s-exctab.ads
s-stalib.ads
a-unccon.ads
a-tags.ads
s-stoele.ads
a-stream.ads
s-soflin.ads
a-except.ads
s-traent.ads
s-stache.ads
s-stratt.ads
s-unstyp.ads
s-secsta.ads
s-finmas.ads
a-finali.ads
s-finroo.ads
s-stopoo.ads
s-pooglo.ads
a-caldel.ads
a-calend.ads
s-stoele.adb

compilation abandoned
../gcc-interface/Makefile:296: recipe for target 'g-exptty.o' failed

[Bug tree-optimization/80006] New: loss of range information after widening conversion

[msebor at gcc dot gnu.org]

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

Bug ID: 80006
   Summary: loss of range information after widening conversion
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This bug is the cause of bug 79356 (discussed here:
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00684.html).

When the following test case is compiled for some targets (such as powerpc64)
it emits a diagnostic for the call to ff in f as expected.  This is thanks the
range of the x variable is correctly represented as the anti-range ~[-3, 7],
which means that valid (i.e., non-negative) argument to the allocation function
is greater greater than 7 (negative argument are considered invalid).

However, the same warning is not issued for the call to gg, or even for ff on
on other targets (such as x86_64).  The reason is that VRP appears to "lose"
the range of the signed char variable x when it's converted to int.  On x86_64,
this conversion from signed char to int is for some reason performed even in
function f, so the test program triggers no warnings.  On powerpc64, the
conversion is not done in f but it is done in g where it is explicit.

In summary, it seems as though there are two problems:
1) the spurious signed char to int conversion on x86_64 inserted (very early on
-- as can be seen in the tree-original dump)
2) the loss of range info when converting a signed char variable to signed int.

$ cat t.c && /build/powerpc64le-linux-gnu/gcc-trunk/gcc/xgcc -B
/build/powerpc64le-linux-gnu/gcc-trunk/gcc -O2 -S -Wall -Wextra -Wpedantic
-Walloc-size-larger-than=7 -fdump-tree-vrp=/dev/stdout t.c
void* f (signed char x)
{
  extern void* ff (signed char) __attribute__ ((alloc_size (1)));

  if (-3 <= x && x <= 7)
x = -4;

  return ff (x);
}

void* g (signed char x)
{
  extern void* gg (int) __attribute__ ((alloc_size (1)));

  if (-3 <= x && x <= 7)
x = -4;

  return gg (x);
}



;; Function f (f, funcdef_no=0, decl_uid=2492, cgraph_uid=0, symbol_order=0)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4
;; 2 succs { 3 4 }
;; 3 succs { 4 }
;; 4 succs { 1 }
Adding assert for x_4(D) from (unsigned char) x_4(D) + 3
Adding assert for x_4(D) from (unsigned char) x_4(D) + 3

SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j

x_8 -> { x_4(D) }
x_9 -> { x_4(D) }
Incremental SSA update started at block: 2
Number of blocks in CFG: 6
Number of blocks to update: 4 ( 67%)



Value ranges after VRP:

x.0_1: [0, +INF]
_2: [0, +INF]
x_3: ~[-3, 7]  EQUIVALENCES: { } (0 elements)
x_4(D): VARYING
_7: VARYING
x_8: [-3, 7]  EQUIVALENCES: { x_4(D) } (1 elements)
x_9: ~[-3, 7]  EQUIVALENCES: { x_4(D) } (1 elements)


Removing basic block 3
f (signed char x)
{
  unsigned char x.0_1;
  unsigned char _2;
  void * _7;

   [100.00%]:
  x.0_1 = (unsigned char) x_4(D);
  _2 = x.0_1 + 3;
  if (_2 <= 10)
goto ; [54.00%]
  else
goto ; [46.00%]

   [46.00%]:

   [100.00%]:
  # x_3 = PHI 
  _7 = ff (x_3);
  return _7;

}



;; Function f (f, funcdef_no=0, decl_uid=2492, cgraph_uid=0, symbol_order=0)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4
;; 2 succs { 3 4 }
;; 3 succs { 4 }
;; 4 succs { 1 }
Adding assert for x_4(D) from (unsigned char) x_4(D) + 3
Adding assert for x_4(D) from (unsigned char) x_4(D) + 3

SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j

x_8 -> { x_4(D) }
x_9 -> { x_4(D) }
Incremental SSA update started at block: 2
Number of blocks in CFG: 6
Number of blocks to update: 4 ( 67%)



Value ranges after VRP:

x.0_1: [0, +INF]
_2: [0, +INF]
x_3: ~[-3, 7]  EQUIVALENCES: { } (0 elements)
x_4(D): VARYING
_7: VARYING
x_8: [-3, 7]  EQUIVALENCES: { x_4(D) } (1 elements)
x_9: ~[-3, 7]  EQUIVALENCES: { x_4(D) } (1 elements)


Removing basic block 3
f (signed char x)
{
  unsigned char x.0_1;
  unsigned char _2;
  void * _7;

   [100.00%]:
  x.0_1 = (unsigned char) x_4(D);
  _2 = x.0_1 + 3;
  if (_2 <= 10)
goto ; [54.00%]
  else
goto ; [46.00%]

   [46.00%]:

   [100.00%]:
  # x_3 = PHI 
  _7 = ff (x_3);
  return _7;

}


t.c: In function ‘f’:
t.c:8:10: warning: argument 1 range [8, 127] exceeds maximum object size 7
[-Walloc-size-larger-than=]
   return ff (x);
  ^~
t.c:3:16: note: in a call to allocation function ‘ff’ declared here
   extern void* ff (signed char) __attribute__ ((alloc_size (1)));
^~

;; Function g (g, funcdef_no=1, decl_uid=2498, cgraph_uid=1, symbol_order=1)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4
;; 2 succs { 3 4 }
;; 3 succs { 4 }
;; 4 succs { 1 }
Adding assert for x_5(D) from (unsigned 

[Bug libstdc++/71107] wstring_convert::from_bytes produces wide chars with the wrong byte order

[cantabile.desu at gmail dot com]

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

--- Comment #12 from Bitterblue  ---
Wonderful news!

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
This is interesting.

If I use:

read( unit=s, fmt='(DT)', iostat=istat, iomsg=imsg ) foo

then we do not lose the first character. However, the loop in the dtio
procedure does not exit.

So I inserted in the loop: if (i.gt.10) exit loop_read

resulting in:

$ ./a.out 
loop i:  1
i = 1, c = H
loop i:  2
i = 2, c = e
loop i:  3
i = 3, c = l
loop i:  4
i = 4, c = l
loop i:  5
i = 5, c = o
loop i:  6
i = 6, c =  
loop i:  7
i = 7, c =  
loop i:  8
i = 8, c =  
loop i:  9
i = 9, c =  
loop i: 10
i = 10, c =  
loop i: 11
i = 11, c =  

(I am printing the loop variable before the read)

Regardless in this case we are not losing the first character. I am speculating
that the parent procedure is starting the read based on the format specifier
and eating the first character.  As I said, this is interesting.

[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit

[jvdelisle at gcc dot gnu.org]

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

--- Comment #13 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sat Mar 11 14:49:57 2017
New Revision: 246070

URL: https://gcc.gnu.org/viewcvs?rev=246070=gcc=rev
Log:
2017-03-11  Jerry DeLisle  

PR libgfortran/78854
* io/list_read.c (nml_get_obj_data): Stash internal unit for
later use by child procedures.
* io/write.c (nml_write_obj): Likewise.
* io/tranfer.c (data_transfer_init): Minor whitespace.
* io/unit.c (set_internal_uit): Look for the stashed internal
unit and use it if found.

* gfortran.dg/dtio_25.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/dtio_25.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c
trunk/libgfortran/io/transfer.c
trunk/libgfortran/io/unit.c
trunk/libgfortran/io/write.c

[Bug preprocessor/80005] New: cpp expands __has_include() filename parts

[tim+gcc-bugzilla at centricular dot com]

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

Bug ID: 80005
   Summary: cpp expands __has_include() filename parts
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tim+gcc-bugzilla at centricular dot com
  Target Milestone: ---

gcc (Debian 6.3.0-4) 6.3.0 20170121
cpp (Debian 6.3.0-4) 6.3.0 20170121
Also happens with latest gcc7 snapshot on https://gcc.godbolt.org/

Linux 4.9.0-1-amd64 #1 SMP Debian 4.9.2-2 (2017-01-12) x86_64 GNU/Linux

I believe this is a gcc preprocessor bug. It works fine with clang fwiw.


1) Precondition:

/usr/include/linux/memfd.h exists (it does).


2) Source code to reproduce:


#ifdef __has_include
 #if !__has_include()
  #error "Header 'linux/memfd.h' could not be found"
 #endif
#endif



3) Steps to reproduce:

$ cpp inctest.c out
inctest.c:3:12: error: #error "Header 'linux/memfd.h' could not be found"

$ strace -f cpp inctest.c out 2>&1 | grep memfd.h | grep /usr/include
[pid  8935] open("/usr/include/1/memfd.h", O_RDONLY|O_NOCTTY) = -1 ENOENT

Note that linux/memfd.h was expanded to 1/memfd.h here.

Presumably #define linux 1 is one of the compiler/preprocessor predefines?

I believe it should not expand filenames (clang doesn't, fwiw).

Adding a #undef linux "fixes" the issue.

[Bug libstdc++/67214] undefined behaviour in std::num_get::_M_extract_int()

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Jonathan Wakely  ---
Thanks, please post the patch to the mailing lists during Stage 1.

[Bug rtl-optimization/80004] New: non-atomic load moved to before atomic load with std::memory_order_acquire

[fboranek at atlas dot cz]

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

Bug ID: 80004
   Summary: non-atomic load moved to before atomic load with
std::memory_order_acquire
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fboranek at atlas dot cz
  Target Milestone: ---

Folowing code
(https://gist.github.com/fboranek/5c99f96a99f902f5cf9dc5d597ff8fe3) for 4
thread doesn't compute the correct result if it is compiled by gcc (Debian
6.3.0-6) 6.3.0 20170205. The code is corect compiled by gcc 4.9.2 and 5.4.1. It
is also correct compiled if the variable counter is not static bat global.

This issue can be related to bug 78778, but bug 78778 is appear in 5.1.0 while
this issue is since version 6.


static int counter {0};
static std::atomic flag {false};

void increment1(int cycles)
{
for (int i=0; i < cycles; ++i)
{
while (flag.exchange(true, std::memory_order_acquire));

++counter;

flag.store(false, std::memory_order_release);
}
}

// asm for gcc 5.4.1
004010f0 <_Z10increment1i>:
  4010f0:   31 c9   xor%ecx,%ecx
  4010f2:   85 ff   test   %edi,%edi
  4010f4:   ba 01 00 00 00  mov$0x1,%edx
  4010f9:   7e 26   jle401121 <_Z10increment1i+0x31>
  4010fb:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)
  401100:   89 d0   mov%edx,%eax
  401102:   86 05 ec 20 20 00   xchg   %al,0x2020ec(%rip)#
6031f4 <_ZL4flag>
  401108:   84 c0   test   %al,%al
  40110a:   75 f4   jne401100 <_Z10increment1i+0x10>
  40110c:   83 c1 01add$0x1,%ecx
  40110f:   83 05 e2 20 20 00 01addl   $0x1,0x2020e2(%rip)#
6031f8 <_ZL7counter>
  401116:   39 cf   cmp%ecx,%edi
  401118:   c6 05 d5 20 20 00 00movb   $0x0,0x2020d5(%rip)#
6031f4 <_ZL4flag>
  40111f:   75 df   jne401100 <_Z10increment1i+0x10>
  401121:   f3 c3   repz retq 
  401123:   0f 1f 00nopl   (%rax)
  401126:   66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
  40112d:   00 00 00

// asm for gcc 6.3.0
1420 <_Z10increment1i>:
1420:   8b 0d d2 1d 20 00   mov0x201dd2(%rip),%ecx#
2031f8 <_ZL7counter>
1426:   85 ff   test   %edi,%edi
1428:   ba 01 00 00 00  mov$0x1,%edx
142d:   8d 34 0flea(%rdi,%rcx,1),%esi
1430:   7e 26   jle1458 <_Z10increment1i+0x38>
1432:   66 0f 1f 44 00 00   nopw   0x0(%rax,%rax,1)
1438:   89 d0   mov%edx,%eax
143a:   86 05 b4 1d 20 00   xchg   %al,0x201db4(%rip)#
2031f4 <_ZL4flag>
1440:   84 c0   test   %al,%al
1442:   75 f4   jne1438 <_Z10increment1i+0x18>
1444:   83 c1 01add$0x1,%ecx
1447:   39 ce   cmp%ecx,%esi
1449:   89 0d a9 1d 20 00   mov%ecx,0x201da9(%rip)#
2031f8 <_ZL7counter>
144f:   c6 05 9e 1d 20 00 00movb   $0x0,0x201d9e(%rip)#
2031f4 <_ZL4flag>
1456:   75 e0   jne1438 <_Z10increment1i+0x18>
1458:   f3 c3   repz retq 
145a:   66 0f 1f 44 00 00   nopw   0x0(%rax,%rax,1)

[Bug libstdc++/71107] wstring_convert::from_bytes produces wide chars with the wrong byte order

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #11 from Jonathan Wakely  ---
This is the same problem as PR 79511

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

[Bug libstdc++/79511] Convertation issues in std::codecvt_utf8_utf16

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||cantabile.desu at gmail dot com

--- Comment #13 from Jonathan Wakely  ---
*** Bug 71107 has been marked as a duplicate of this bug. ***

[Bug libstdc++/71107] wstring_convert::from_bytes produces wide chars with the wrong byte order

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #10 from Jonathan Wakely  ---
I have a fix for this now.

[Bug fortran/79844] diagnostics: extra space at end of line

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-11
   Assignee|unassigned at gcc dot gnu.org  |dominiq at lps dot 
ens.fr
 Ever confirmed|0   |1

[Bug fortran/79859] diagnostics: argument quoted twice in "No initializer for allocatable compoonent"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-11
   Assignee|unassigned at gcc dot gnu.org  |dominiq at lps dot 
ens.fr
 Ever confirmed|0   |1

[Bug fortran/79853] diagnostics: double space in "Assumed or deferred"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-11
   Assignee|unassigned at gcc dot gnu.org  |dominiq at lps dot 
ens.fr
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
This is gcc/fortran/expr.c.

[Bug libstdc++/67214] undefined behaviour in std::num_get::_M_extract_int()

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #2 from Xi Ruoyao  ---
Created attachment 40946
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40946=edit
patch for this PR

Since GCC 7 is in stage 4, this patch will be committed in GCC 8 stage 1.

[Bug translation/80003] New: i386.c: %s placeholder is no semantic grammar unit

[roland.illig at gmx dot de]

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

Bug ID: 80003
   Summary: i386.c: %s placeholder is no semantic grammar unit
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from config/i386/386.c:

error ("interrupt service routine should have unsigned %s"
   "int as the second argument",
   TARGET_64BIT
   ? (TARGET_X32 ? "long long " : "long ")
   : "");

The placeholder %s is attached to the "int" following it without a space. This
looks suspicious, and indeed the sentence is hard to understand for
translators. It should rather look like this:

error ("interrupt service routine should have %qs "
   "as the second argument",
   TARGET_64BIT && TARGET_X32 ? "unsigned long long int"
   : TARGET_64_BIT ? "unsigned long int"
   : "unsigned int");

In this form the translator doesn't have to care about the contents of the %qs
placeholder, since it won't affect the enclosing sentence. Also, the code now
clearly and unambiguously names the exact types (as a semantic unit) instead of
a list of type keywords.

[Bug demangler/80002] New: quadratic behavior in demangler

[trippels at gcc dot gnu.org]

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

Bug ID: 80002
   Summary: quadratic behavior in demangler
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

Playing with LibFuzzer turned up the following testcase:

c++filt
_ZcvT_IrcvT_IreloaT_IrcvT_IreloaT_IreloaT_IrcvT_IrleoaT_IrcvT_IreloaT_IreloaT_IrcvT_IrelcvT_IreloaT_ZcvT_IrcvT_IreloaT_IrcvT_IreloaT_IreloaT_IrcvT_IrleoaT_IrcvT_IreloaT_IreloaT_IrcvT_IrelcvT_IreloaT_ZcvT_IrcvT_IreloaT
takes 36 seconds


_ZcvT_IrcvT_IreloaT_IrcvT_IreloaT_IreloaT_IrcvT_IrleoaT_IrcvT_IreloaT_IreloaT_IrcvT_IrelcvT_IreloaT_ZcvT_IrcvT_IreloaT_IrcvT_IreloaT_IreloaT_IrcvT_IrleoaT_IrcvT_IreloaT_IreloaT_IrcvT_IrelcvT_IreloaT_ZcvT_IrcvT_IreloaT_IrcvT_IreloaT_
takes 2:30 minutes

_ZcvT_IrcvT_IreloaT_IrcvT_IreloaT_IreloaT_IrcvT_IrleoaT_IrcvT_IreloaT_IreloaT_IrcvT_IrelcvT_IreloaT_ZcvT_IrcvT_IreloaT_IrcvT_IreloaT_IreloaT_IrcvT_IrleoaT_IrcvT_IreloaT_IreloaT_IrcvT_IrelcvT_IreloaT_ZcvT_IrcvT_IreloaT_IrcvT_IreloaT_IreloaT_IrcvT_
takes 9 minutes 

etc...

If we want to add the demangler to https://github.com/google/oss-fuzz this
issue should be solved.

[Bug libstdc++/67214] undefined behaviour in std::num_get::_M_extract_int()

[ryxi at stu dot xidian.edu.cn]

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||ryxi at stu dot xidian.edu.cn

--- Comment #1 from Xi Ruoyao  ---
For GCC 5/6/7 I can't reproduce this since the target code is in libstdc++.so
and there the ubsan can't sanitize them.  But it seems a real undefined
behaviour.

BTW, -Woverflow doesn't warn for this in the building of libstdc++ (or this
bug should have been detected and fixed). I think there are still improvements
of -Woverflow to do.

[Bug translation/80001] diagnostics: untranslateable %s placeholders in omp-offload.c

[roland.illig at gmx dot de]

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

--- Comment #1 from Roland Illig  ---
Note that the above is not the only instance. Please check each %s format
specifier in this file for this pattern.

loop->routine ? "routine call" : "loop" (twice)
tiling ? " tile" : ""

While here, please also update the '%s' around line 600 to be %qs.

[Bug other/80001] New: diagnostics: untranslateable %s placeholders in omp-offload.c

[roland.illig at gmx dot de]

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

Bug ID: 80001
   Summary: diagnostics: untranslateable %s placeholders in
omp-offload.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from omp-offload.c:

error_at (loop->loc,
  "%s uses same OpenACC parallelism as containing loop",
  loop->routine ? "routine call" : "inner loop");

The %s placeholder cannot be translated into other languages, but should be.
Therefore the ?: should be replaced with a ?: for the whole sentence.


error_at (loop->loc, loop->routine
  ? "routine call uses same OpenACC parallelism as containing loop"
  : "inner loop uses same OpenACC parallelism as containing loop");

[Bug ipa/80000] New: diagnostics: trailing spaces in "one definition rule "

[roland.illig at gmx dot de]

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

Bug ID: 8
   Summary: diagnostics: trailing spaces in "one definition rule
"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from ipa-devirt.c:

if (warning_at (
  DECL_SOURCE_LOCATION(TYPE_NAME (DECL_CONTEXT (vtable->decl))),
  OPT_Wodr,
  "virtual table of type %qD violates "
  "one definition rule  ",
  DECL_CONTEXT (vtable->decl)))

There are two spaces after "one definition rule" that should not be there.

[Bug translation/79999] New: possible typo in gimplify.c: depend(sink:)

[roland.illig at gmx dot de]

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

Bug ID: 7
   Summary: possible typo in gimplify.c: depend(sink:)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from gimple.c:

error_at (OMP_CLAUSE_LOCATION (source_c),
  "% clause specified together with "
  "% clauses on the same construct");

There is a colon after "sink". In a diagnostic some lines above, there is no
colon.

error_at (OMP_CLAUSE_LOCATION (c),
  "number of variables in % "
  "clause does not match number of "
  "iteration variables");

As the German translator, I stumbled upon this, and I think one of them has a
typo.

[Bug tree-optimization/79998] New: typo in diagnostic "specified bound %wu"

[roland.illig at gmx dot de]

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

Bug ID: 79998
   Summary: typo in diagnostic "specified bound %wu"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from gimple-ssa-sprintf.c:

warning_at (gimple_location (info.callstmt), info.warnopt (),
"specified bound %wu exceeds %",
dstsize);

There is an extra space after INT_MAX.

[Bug tree-optimization/79997] simple-ssa-sprintf i18n: wrong plural form in maybe_warn

[roland.illig at gmx dot de]

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

--- Comment #1 from Roland Illig  ---
Another instance in the same file, function format_directive:

1 == fmtres.range.likely

And another, in the same function:

min == 1