[Bug tree-optimization/79997] simple-ssa-sprintf i18n: wrong plural form in maybe_warn
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
[Bug tree-optimization/79998] New: typo in diagnostic "specified bound %wu"
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 translation/79999] New: possible typo in gimplify.c: depend(sink:)
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 ipa/80000] New: diagnostics: trailing spaces in "one definition rule "
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 other/80001] New: diagnostics: untranslateable %s placeholders in omp-offload.c
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 translation/80001] diagnostics: untranslateable %s placeholders in omp-offload.c
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 libstdc++/67214] undefined behaviour in std::num_get::_M_extract_int()
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 demangler/80002] New: quadratic behavior in demangler
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 translation/80003] New: i386.c: %s placeholder is no semantic grammar unit
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 libstdc++/67214] undefined behaviour in std::num_get::_M_extract_int()
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&action=edit patch for this PR Since GCC 7 is in stage 4, this patch will be committed in GCC 8 stage 1.
[Bug fortran/79853] diagnostics: double space in "Assumed or deferred"
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 fortran/79859] diagnostics: argument quoted twice in "No initializer for allocatable compoonent"
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/79844] diagnostics: extra space at end of line
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 libstdc++/71107] wstring_convert::from_bytes produces wide chars with the wrong byte order
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 libstdc++/79511] Convertation issues in std::codecvt_utf8_utf16
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
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 rtl-optimization/80004] New: non-atomic load moved to before atomic load with std::memory_order_acquire
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++/67214] undefined behaviour in std::num_get::_M_extract_int()
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 preprocessor/80005] New: cpp expands __has_include() filename parts
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 fortran/78854] [F03] DTIO namelist output not working on internal unit
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&root=gcc&view=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 fortran/78881] [F03] reading from string with DTIO procedure does not work properly
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 libstdc++/71107] wstring_convert::from_bytes produces wide chars with the wrong byte order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71107 --- Comment #12 from Bitterblue --- Wonderful news!
[Bug tree-optimization/80006] New: loss of range information after widening conversion
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 char) x_5(D) + 3
Adding assert for x_5
[Bug ada/80007] New: --disable-bootstrap with gnat-5 leads to failed gnat-7 build on aarch64
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 ada/80007] --disable-bootstrap with gnat-5 leads to failed gnat-7 build on aarch64
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] --disable-bootstrap with gnat-5 leads to failed gnat-7 build on aarch64
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
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
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 c++/80008] New: internal compiler error: in cp_parser_direct_declarator, at cp/parser.c:20031 [C++17]
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&action=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 fortran/80009] New: Printing/writing a structure with a real edit descriptor.
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&action=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 fortran/80009] Printing/writing a structure with a real edit descriptor.
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 c++/80008] internal compiler error: in cp_parser_direct_declarator, at cp/parser.c:20031 [C++17]
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 c++/80008] internal compiler error: in cp_parser_direct_declarator, at cp/parser.c:20031 [C++17]
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]
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 fortran/80009] Printing/writing a structure with a real edit descriptor.
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++/78999] problem with gcc on cygwin??? cygwin 2.6.1 with gcc 5.4.0
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 c++/78999] problem with gcc on cygwin??? cygwin 2.6.1 with gcc 5.4.0
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 libstdc++/79833] std::put_time has the wrong values for 2 digit years
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&action=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.
