[Bug middle-end/77766] [7 Regression] wrong code at -O2 and -O3 in 64-bit mode on x86_64-linux-gnu (executable hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77766 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||tbsaunde at gcc dot gnu.org --- Comment #3 from tbsaunde at gcc dot gnu.org --- appears to be fixed or latent as of r244205
[Bug c++/78948] [C++17] constexpr if instantiating too eagerly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78948 --- Comment #5 from Jason Merrill --- Author: jason Date: Sun Jan 8 06:36:10 2017 New Revision: 244206 URL: https://gcc.gnu.org/viewcvs?rev=244206&root=gcc&view=rev Log: PR c++/78948 - instantiation from discarded statement * parser.h (struct cp_parser): Remove in_discarded_stmt field. * cp-tree.h (in_discarded_stmt): Declare it. (struct saved_scope): Add discarded_stmt bitfield. (in_discarded_stmt): New macro. * decl2.c (mark_used): Check it. * parser.c (cp_parser_selection_statement): Adjust. (cp_parser_jump_statement): Adjust. Added: trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if10.C trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl2.c trunk/gcc/cp/parser.c trunk/gcc/cp/parser.h
[Bug c/79025] Incorrect loop optimization for -Os and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79025 --- Comment #2 from Andrew Pinski --- Signed interger overflow is undefined behavior.
[Bug c++/63217] template conversion operator returning const reference not used for conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63217 --- Comment #2 from Edward --- I can confirm the bug in version 6.3.0 freshly built: (found this bug researching for a similar bug I am reporting) Using built-in specs. COLLECT_GCC=/home/h/packages/gcc-6.3.0/bin/g++ COLLECT_LTO_WRAPPER=/home/h/packages/gcc-6.3.0/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-6.3.0/configure --prefix=/home/h/packages/gcc-6.3.0 --enable-languages=c++ Thread model: posix gcc version 6.3.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-std=c++1z' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /home/h/packages/gcc-6.3.0/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/cc1plus -quiet -v -D_GNU_SOURCE src/f5.cpp -quiet -dumpbase f5.cpp -mtune=generic -march=x86-64 -auxbase f5 -std=c++1z -version -o /tmp/ccSkJoqY.s GNU C++14 (GCC) version 6.3.0 (x86_64-pc-linux-gnu) compiled by GNU C version 6.3.0, GMP version 5.1.1, MPFR version 3.1.1, MPC version 1.0.1, isl version none GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/home/h/packages/gcc-6.3.0/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /home/h/packages/gcc-6.3.0/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../include/c++/6.3.0 /home/h/packages/gcc-6.3.0/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../include/c++/6.3.0/x86_64-pc-linux-gnu /home/h/packages/gcc-6.3.0/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../include/c++/6.3.0/backward /home/h/packages/gcc-6.3.0/lib/gcc/x86_64-pc-linux-gnu/6.3.0/include /usr/local/include /home/h/packages/gcc-6.3.0/include /home/h/packages/gcc-6.3.0/lib/gcc/x86_64-pc-linux-gnu/6.3.0/include-fixed /usr/include End of search list. GNU C++14 (GCC) version 6.3.0 (x86_64-pc-linux-gnu) compiled by GNU C version 6.3.0, GMP version 5.1.1, MPFR version 3.1.1, MPC version 1.0.1, isl version none GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 80f12065068033b5f76b36dba8781986 src/f5.cpp: In function ‘int main()’: src/f5.cpp:8:18: error: cannot convert ‘foo’ to ‘int’ in initialization int t((foo()));
[Bug preprocessor/29999] preprocessor documentation is missing from gcc.info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- Since the preprocessor itself is integrated with compilation nowadays, I also proposed merging more parts of the CPP manual into the GCC manual: https://gcc.gnu.org/ml/gcc/2016-12/msg00073.html But the consensus still seemed to be that people want a separate CPP manual.
[Bug c/79025] Incorrect loop optimization for -Os and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79025
--- Comment #1 from Peter Selinger ---
I would like to add that while the gcc option "-fdisable-tree-vrp1" appears to
fix the first problem, it does not solve the "secondary bug":
extern int printf (const char *__restrict __format, ...);
int main() {
int x;
for (x = 0; x >= 0 && x < 0x; x += 0x4000) {
printf("x=%d\n", x);
}
return 0;
}
$ gcc -O2 test.c -o test -fdisable-tree-vrp1
cc1: note: disable pass tree-vrp1 for functions in the range of [0, 4294967295]
$ ./test
x=0
x=1073741824
x=0
x=1073741824
x=0
[...]
[Bug preprocessor/54124] GCC 4.7.1 manual: -dM and similar options hard to find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54124 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from sandra at gcc dot gnu.org --- Fixed for GCC 7.
[Bug c/79025] New: Incorrect loop optimization for -Os and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79025
Bug ID: 79025
Summary: Incorrect loop optimization for -Os and above
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: selinger at mathstat dot dal.ca
Target Milestone: ---
Created attachment 40476
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40476&action=edit
Test case
To reproduce:
=
Consider this minimal example (no includes):
extern int printf (const char *__restrict __format, ...);
int main() {
int x;
for (x = 0; x >= 0 && x < 0x; x += 0x2000) {
printf("x=%d\n", x);
}
return 0;
}
When compiled with -O0 or -O1, this correctly terminates. When compiled with
-Os or -O2, the check for x >= 0 is ignored and the loop runs forever.
Results:
$ gcc -O0 test.c -o test
$ ./test
x=0
x=536870912
x=1073741824
x=1610612736
$ gcc -O2 test.c -o test
$ ./test
x=0
x=536870912
x=1073741824
x=1610612736
x=-2147483648
x=-1610612736
x=-1073741824
x=-536870912
x=0
x=536870912
x=1073741824
x=1610612736
x=-2147483648
x=-1610612736
x=-1073741824
x=-536870912
[...]
Compiler and system version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 6.2.0-5ubuntu12'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --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 --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-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
Thread model: posix
gcc version 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12)
Additional information:
===
The gcc option -fno-aggressive-loop-optimizations does not fix this bug.
The gcc option -fdisable-tree-vrp1 appears to fix it.
Secondary bug:
==
If I replace 0x2000 by 0x4000 in the example program, the behavior is
even more bizarre:
extern int printf (const char *__restrict __format, ...);
int main() {
int x;
for (x = 0; x >= 0 && x < 0x; x += 0x4000) {
printf("x=%d\n", x);
}
return 0;
}
$ gcc -O0 test.c -o test
$ ./test
x=0
x=1073741824
$ gcc -O2 test.c -o test
$ ./test
x=0
x=1073741824
x=0
x=1073741824
x=0
[...]
Note that in this case, not only the test for x >= 0 is ignored, but also the
addition is not performed correctly.
[Bug preprocessor/13498] CPP include search path documentation is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13498 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from sandra at gcc dot gnu.org --- Fixed for GCC 7.
[Bug preprocessor/54124] GCC 4.7.1 manual: -dM and similar options hard to find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54124 --- Comment #7 from sandra at gcc dot gnu.org --- Author: sandra Date: Sun Jan 8 01:42:26 2017 New Revision: 244205 URL: https://gcc.gnu.org/viewcvs?rev=244205&root=gcc&view=rev Log: 2017-01-07 Sandra Loosemore PR preprocessor/54124 gcc/ * doc/cppopts.texi: Reformat -d subtable to list the full name of the options. Add cross-reference to the docs for the general compiler -d options. * doc/invoke.texi (Developer Options): Add cross-reference to the preprocessor-specific -d option documentation. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/cppopts.texi trunk/gcc/doc/invoke.texi
[Bug c++/79024] alignas / alignof report wrong alignment for 64bit integer types for 32bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79024 --- Comment #2 from Xidorn Quan --- ABI requires a different alignment than in struct? That's interesting. But I think developers (I mean, users of compilers) are generally more interested on alignment requirement in struct rather than that for ABI, and most description of the concept "alignment" refers to that in struct, so it is probably better make alignof / alignas report that value.
[Bug c++/79024] alignas / alignof report wrong alignment for 64bit integer types for 32bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79024 --- Comment #1 from Andrew Pinski --- There is definitely a dup of this bug somewhere. This is a target issue. IIRC the ia32 32bit elf ABI uint64_t is 64bit aligned except inside structs where it is 32bit aligned.
[Bug c++/79024] New: alignas / alignof report wrong alignment for 64bit integer types for 32bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79024
Bug ID: 79024
Summary: alignas / alignof report wrong alignment for 64bit
integer types for 32bit target
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gnu-9fbaow at upsuper dot org
Target Milestone: ---
See the following code:
#include
#include
struct Test1 { char c; uint64_t u; };
struct Test2 { char c; alignas(uint64_t) uint64_t u; };
static_assert(sizeof(Test1) == sizeof(Test2), "Size should be same, no?");
static_assert(offsetof(Test1, u) == offsetof(Test2, u),
"Offset should be same, no?");
Compiling this code with "g++ -m32", both static assertions are broken, which
indicates that uint64_t in Test1 is not aligned as what alignas reports.
FWIW, MSVC doesn't have this issue but clang has exactly the same issue.
[Bug middle-end/78973] [7.0 regression] warning: ‘memcpy’: specified size between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78973 Martin Sebor changed: What|Removed |Added Keywords|patch | --- Comment #7 from Martin Sebor --- I should add that changing irdebi to take count as an unsigned suppresses the warning. That is also the recommended way to declare variables that store sizes or counts that cannot meaningfully be negative.
[Bug middle-end/78973] [7.0 regression] warning: ‘memcpy’: specified size between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78973
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |INVALID
--- Comment #6 from Martin Sebor ---
I take back what I said in comnment #4. I had misread the range information
reported in the VRP dump and also debugged the wrong function (before it was
inlined into the caller). I have a patch that improves the algorithm used by
the warning and adds inlining context to make debugging easier. With it GCC
prints the following:
In file included from drivers/media/pci/ttpci/av7110.c:63:0:
In function ‘irdebi’,
inlined from ‘start_debi_dma’ at drivers/media/pci/ttpci/av7110.c:376:3,
inlined from ‘gpioirq’ at drivers/media/pci/ttpci/av7110.c:659:3:
drivers/media/pci/ttpci/av7110_hw.h:406:3: warning: ‘memcpy’: specified size
between 18446744071562067968 and 18446744073709551615 exceeds maximum object
size 9223372036854775807 [-Wstringop-overflow=]
In function ‘irdebi’,
inlined from ‘start_debi_dma’ at drivers/media/pci/ttpci/av7110.c:376:3,
inlined from ‘gpioirq’ at drivers/media/pci/ttpci/av7110.c:668:3:
drivers/media/pci/ttpci/av7110_hw.h:406:3: warning: ‘memcpy’: specified size
between 18446744071562067968 and 18446744073709551615 exceeds maximum object
size 9223372036854775807 [-Wstringop-overflow=]
There are three calls to memcpy in gpioirq. The two that cause the warnings
are these:
[7.74%]:
_306 = (long unsigned int) len_138;
_307 = av7110_131->debi_virt;
memcpy (_307, &res, _306);
and
[2.75%]:
_333 = (long unsigned int) len_138;
_334 = av7110_131->debi_virt;
memcpy (_334, &res, _333);
The range information for both of the variables is:
_306: [18446744071562067968, +INF]
_333: [18446744071562067968, +INF]
which corresponds the warning messages.
The irdebi function inlined into gpioirq looks like this:
irdebi(struct av7110 *av7110, u32 config, int addr, u32 val, int count)
{
u32 res;
res=av7110_debiread(av7110, config, addr, count);
if (count<=4)
memcpy(av7110->debi_virt, (char *) &res, count);
return res;
}
It calls memcpy with an int argument that's less than or equal to 4 (and
possibly negative).
The irdebi call is inlined into start_debi_dma:
void start_debi_dma(struct av7110 *av7110, int dir,
unsigned long addr, unsigned int len)
{
...
if (len < 5)
len = 5;
if (dir == 1)
iwdebi(av7110, 0x001e, addr, 0, (len + 3) & ~3);
else
irdebi(av7110, 0x001e, addr, 0, len);
}
I.e., with an unsigned len greater than or equal to 5 (and possibly in excess
of INT_MAX).
start_debi_dma is called from gpioirq like so:
int len;
...
av7110->debilen = irdebi(av7110, 0x000e, (0x4000 + 0x0F6), 0, 2);
...
len = (av7110->debilen + 3) & ~3;
...
case 0x04:
if (!len || len > 0xff) {
iwdebi(av7110, 0x000e, (0x4000 + 0x1FF4), 0, 2);
break;
}
start_debi_dma(av7110, 0, (0x4000 + 0x1E00), len);
len here is bounded by [INT_MIN, 0xfc], i.e., it can be negative.
In summary, I think the warning is justified and the result of the signed to
unsigned to signed conversions and insufficient checks for out of bounds values
that don't take into consideration that the signed values can be negative.
[Bug libstdc++/71809] compile llvm3.8.0 failed by the libstdc++ of gcc6.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71809 --- Comment #6 from Jeffrey Walton --- (In reply to Jeffrey Walton from comment #5) > (In reply to sulit from comment #4) > > ok > > Sulit, I'm seeing the issue under Clang 3.5 on Ubuntu 16. Do you have a LLVM > bug report for this issue? Here's a Ubuntu bug report for the issue: https://bugs.launchpad.net/ubuntu/+bug/1654795.
[Bug c/79023] ARM: Compiler optimizations cause branch instruction within while loop to call itself infinitely.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79023 --- Comment #2 from George Morgan --- Ah, I see. Yes, that resolves the problem. My apologies for the inconvenience - George
[Bug c/79023] ARM: Compiler optimizations cause branch instruction within while loop to call itself infinitely.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79023 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- volatile void *ptr; is a pointer to a violatile void type. You want: void *volatile ptr;
[Bug c/79023] New: ARM: Compiler optimizations cause branch instruction within while loop to call itself infinitely.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79023
Bug ID: 79023
Summary: ARM: Compiler optimizations cause branch instruction
within while loop to call itself infinitely.
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: geo...@george-morgan.com
Target Milestone: ---
The code compiled with "arm-none-eabi-gcc -nostartfiles -ffreestanding -Os
bug.c -o bug.o"
-
volatile void *ptr;
void func(void) {
while (!ptr);
}
-
Produces the following assembly output:
---
bug.o: file format elf32-littlearm
Disassembly of section .text:
8000 :
8000: 4b02ldr r3, [pc, #8]; (800c )
8002: 681bldr r3, [r3, #0]
8004: b903cbnzr3, 8008
8006: e7feb.n 8006
8008: 4770bx lr
800a: bf00nop
800c: 00018010andeq r8, r1, r0, lsl r0
Disassembly of section .bss:
00018010 :
18010: andeq r0, r0, r0
Disassembly of section .comment:
<.comment>:
0: 3a434347bcc 10d0d24 <_stack+0x1050d24>
4: 4e472820cdpmi 8, 4, cr2, cr7, cr0, {1}
8: 36202955; instruction: 0x36202955
c: 302e332eeorcc r3, lr, lr, lsr #6
...
Disassembly of section .ARM.attributes:
<_stack-0x8>:
0: 3241andeq r3, r0, r1, asr #4
4: 61656100cmnvs r5, r0, lsl #2
8: 01006962tsteq r0, r2, ror #18
c: 0028andeq r0, r0, r8, lsr #32
10: 726f4305rsbvc r4, pc, #335544320 ; 0x1400
14: 2d786574cfldr64cs mvdx6, [r8, #-464]! ; 0xfe30
18: 0600344dstreq r3, [r0], -sp, asr #8
1c: 094d070dstmdbeq sp, {r0, r2, r3, r8, r9, sl}^
20: 14041202strne r1, [r4], #-514 ; 0xfdfe
24: 17011501strne r1, [r1, -r1, lsl #10]
28: 19011803stmdbne r1, {r0, r1, fp, ip}
2c: 1e011a01vmlane.f32 s2, s2, s2
30: Address 0x0030 is out of bounds.
--
As you can see, the instruction at 8006 calls itself infinitely.
[Bug preprocessor/13498] CPP include search path documentation is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13498 --- Comment #4 from sandra at gcc dot gnu.org --- Author: sandra Date: Sat Jan 7 22:46:13 2017 New Revision: 244201 URL: https://gcc.gnu.org/viewcvs?rev=244201&root=gcc&view=rev Log: 2017-01-07 Sandra Loosemore PR preprocessor/13498 gcc/ * doc/cpp.texi (Search Path): Rewrite to remove obsolete and redudant material, and reflect new command-line options. (System Headers): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/cpp.texi
[Bug c++/72803] [7 Regression] ICE on invalid code in linemap_position_for_loc_and_offset, at libcpp/line-map.c:891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72803 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from David Malcolm --- Should be fixed on trunk; marking as resolved.
[Bug c++/72803] [7 Regression] ICE on invalid code in linemap_position_for_loc_and_offset, at libcpp/line-map.c:891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72803 --- Comment #8 from David Malcolm --- Author: dmalcolm Date: Sat Jan 7 21:33:59 2017 New Revision: 244199 URL: https://gcc.gnu.org/viewcvs?rev=244199&root=gcc&view=rev Log: Fix linemap corruption after very wide source lines (PR c++/72803) PR c++/72803 describes an issue where a fix-it hint is to be emitted at column 512 of a 511-column source line, leading to an ICE. The root cause is a bug in linemap_line_start, when transitioning from lines >= 512 in width to narrow lines. The wide line in the reproducer has a line map with: m_column_and_range_bits = 15, m_range_bits = 5 giving 10 effective bits for representing columns, so that columns <= 1023 can be represented. When parsing the following line, linemap_line_start (..., ..., max_column_hint=0); is called. This leads to the "add_map" logic, due to this condition: || (max_column_hint <= 80 && effective_column_bits >= 10) i.e. the new line is sufficiently narrower than the old one to potentially use a new linemap (so as to conserve values within the location_t space). It then attempts to avoid allocating a new line map. Part of the logic to determine if we really need a new line map is this condition: SOURCE_COLUMN (map, highest) >= (1U << column_bits) The above condition is incorrect: we need to determine if the highest column we've handed out will fit within the proposed *effective* column bits, but "column_bits" here is the column plus the range bits, rather than just the column bits. Hence in this case linemap_line_start erroneously decides that we don't need a new line map, and updates the column bits within the existing line map, so any location_t values we've already handed out within it that are offset from the start by >= (1<= 1<<10 to narrower lines works correctly. gcc/testsuite/ChangeLog: PR c++/72803 * g++.dg/diagnostic/pr72803.C: New test case. libcpp/ChangeLog: PR c++/72803 * line-map.c (linemap_line_start): When determining if the highest column given out so far will fit into a proposed change to the current map, use the effective number of column bits, rather than the total number of column + range bits. Added: trunk/gcc/testsuite/g++.dg/diagnostic/pr72803.C Modified: trunk/gcc/ChangeLog trunk/gcc/input.c trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/line-map.c
[Bug libstdc++/71809] compile llvm3.8.0 failed by the libstdc++ of gcc6.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71809 Jeffrey Walton changed: What|Removed |Added CC||noloader at gmail dot com --- Comment #5 from Jeffrey Walton --- (In reply to sulit from comment #4) > ok Sulit, I'm seeing the issue under Clang 3.5 on Ubuntu 16. Do you have a LLVM bug report for this issue?
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 --- Comment #15 from Jeffrey Walton --- (In reply to Jonathan Wakely from comment #14) > OK, thanks. I'm not going to try to add declarations like the libc++ patch > does, as it looks like that would only be correct for Snow Leopard and not > earlier. > > I'll just add more fine-grained configure checks and if they're not declared > in then they won't be available, period. There's only so much we > can do to work around buggy C libraries on the target. Ack, thanks. The MacPorts, Brew, Fink (etc) folks thank you.
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 --- Comment #14 from Jonathan Wakely --- OK, thanks. I'm not going to try to add declarations like the libc++ patch does, as it looks like that would only be correct for Snow Leopard and not earlier. I'll just add more fine-grained configure checks and if they're not declared in then they won't be available, period. There's only so much we can do to work around buggy C libraries on the target.
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017
--- Comment #13 from Jeffrey Walton ---
(In reply to Jonathan Wakely from comment #12)
> What's the error?
My bad...
$ cat test.cxx
// #include
long long llrint(double x);
long long llrintf(float x);
long long llrintl(long double x);
long long llround(double x);
long long llroundf(float x);
long long llroundl(long double x);
int main()
{
llrint(0.0);
llrintf(0.0f);
llrintl(0.0l);
llround(0.0);
llroundf(0.0f);
llroundl(0.0l);
return 0;
}
$ /opt/local/bin/g++-mp-5 -std=c++11 test.cxx -o test.exe
Undefined symbols for architecture ppc:
"llrint(double)", referenced from:
_main in ccK6psnG.o
"llrintf(float)", referenced from:
_main in ccK6psnG.o
"llrintl(long double)", referenced from:
_main in ccK6psnG.o
"llround(double)", referenced from:
_main in ccK6psnG.o
"llroundf(float)", referenced from:
_main in ccK6psnG.o
"llroundl(long double)", referenced from:
_main in ccK6psnG.o
ld: symbol(s) not found for architecture ppc
collect2: error: ld returned 1 exit status
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 --- Comment #12 from Jonathan Wakely --- What's the error?
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 --- Comment #52 from Martin Sebor --- -Wnull-dereference is a language-independent option (it works for C, C++, and should work for all other languages). But this bug isn't the right forum to discuss general GCC usage questions (such as why -Q --help=warnings,C doesn't print some C language options). Please either raise those on the gcc-help list or open new bugs for suspected problems.
[Bug fortran/78935] [7 Regression] ICE on allocating derived type coarray with allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78935 --- Comment #10 from vehre at gcc dot gnu.org --- Waiting one week for regression reports before closing.
[Bug fortran/78781] [7 Regression] [Coarray] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1588
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78781 --- Comment #5 from vehre at gcc dot gnu.org --- Waiting one week for regression reports before closing.
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017
--- Comment #11 from Jeffrey Walton ---
> Does this C program compile and link on 10.4 and 10.5?
>
> long long llrint(double x);
> long long llrintf(float x);
> long long llrintl(long double x);
> long long llround(double x);
> long long llroundf(float x);
> long long llroundl(long double x);
>
> int main()
> {
> llrint(0.0);
> llrintf(0.0f);
> llrintl(0.0l);
> llround(0.0);
> llroundf(0.0f);
> llroundl(0.0l);
> return 0;
> }
Confirmed it _did not_ compile on OS X 10.5.8. I tried with/without 'extern',
and with/without '-lm'.
Sorry about the false alarm.
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017
--- Comment #10 from Jonathan Wakely ---
(In reply to Jeffrey Walton from comment #9)
> This patch for libc++ may be useful to you for OS X 10.6 and below (thanks
> to KC):
> https://github.com/jeremyhu/libcxx/commit/
> 720feba4874d4ca3131753dc31af127e3c509c36
Hmm, that doesn't match your results above that say the missing functions for
10.5 (Leopard) are the llrint and llround ones.
It would be strange if they added llround to Snow Leopard but removed lrint.
Does this C program compile and link on 10.4 and 10.5?
long long llrint(double x);
long long llrintf(float x);
long long llrintl(long double x);
long long llround(double x);
long long llroundf(float x);
long long llroundl(long double x);
int main()
{
llrint(0.0);
llrintf(0.0f);
llrintl(0.0l);
llround(0.0);
llroundf(0.0f);
llroundl(0.0l);
return 0;
}
[Bug fortran/78781] [7 Regression] [Coarray] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1588
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78781 --- Comment #4 from vehre at gcc dot gnu.org --- Author: vehre Date: Sat Jan 7 17:26:58 2017 New Revision: 244196 URL: https://gcc.gnu.org/viewcvs?rev=244196&root=gcc&view=rev Log: gcc/fortran/ChangeLog: 2017-01-07 Andre Vehreschild PR fortran/78781 PR fortran/78935 * expr.c (gfc_check_pointer_assign): Return the same error message for rewritten coarray pointer assignments like for plain ones. * gfortran.h: Change prototype. * primary.c (caf_variable_attr): Set attributes used ones only only ones. Add setting of pointer_comp attribute. (gfc_caf_attr): Add setting of pointer_comp attribute. * trans-array.c (gfc_array_allocate): Add flag that the component to allocate is not an ultimate coarray component. Add allocation of pointer arrays. (structure_alloc_comps): Extend nullify to treat pointer components in coarrays correctly. Restructure nullify to remove redundant code. (gfc_nullify_alloc_comp): Allow setting caf_mode flags. * trans-array.h: Change prototype of gfc_nullify_alloc_comp (). * trans-decl.c (generate_coarray_sym_init): Call nullify_alloc_comp for derived type coarrays with pointer components. * trans-expr.c (gfc_trans_structure_assign): Also treat pointer components. (trans_caf_token_assign): Handle assignment of token of scalar pointer components. (gfc_trans_pointer_assignment): Call above routine. * trans-intrinsic.c (conv_expr_ref_to_caf_ref): Add treating pointer components. (gfc_conv_intrinsic_caf_get): Likewise. (conv_caf_send): Likewise. * trans-stmt.c (gfc_trans_allocate): After allocating a derived type in a coarray pre-register the tokens. (gfc_trans_deallocate): Simply determining the coarray type (scalar or array) and deregistering it correctly. * trans-types.c (gfc_typenode_for_spec): Replace in_coarray flag by the actual codim to allow lookup of array types in the cache. (gfc_build_array_type): Likewise. (gfc_get_array_descriptor_base): Likewise. (gfc_get_array_type_bounds): Likewise. (gfc_get_derived_type): Likewise. * trans-types.h: Likewise. * trans.c (gfc_deallocate_with_status): Enable deregistering of all kind of coarray components. (gfc_deallocate_scalar_with_status): Use free() in fcoarray_single mode instead of caf_deregister. libgfortran/ChangeLog: 2017-01-07 Andre Vehreschild PR fortran/78781 PR fortran/78935 * caf/single.c (send_by_ref): Fix addressing of non-allocatable scalar destination components. gcc/testsuite/ChangeLog: 2017-01-07 Andre Vehreschild * gfortran.dg/coarray/ptr_comp_1.f08: New test. * gfortran.dg/coarray/ptr_comp_2.f08: New test. * gfortran.dg/coarray/ptr_comp_3.f08: New test. * gfortran.dg/coarray/ptr_comp_4.f08: New test. * gfortran.dg/coarray_ptr_comp_1.f08: New test. * gfortran.dg/coarray_ptr_comp_2.f08: New test. * gfortran.dg/coarray_ptr_comp_3.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/coarray/ptr_comp_1.f08 trunk/gcc/testsuite/gfortran.dg/coarray/ptr_comp_2.f08 trunk/gcc/testsuite/gfortran.dg/coarray/ptr_comp_3.f08 trunk/gcc/testsuite/gfortran.dg/coarray/ptr_comp_4.f08 trunk/gcc/testsuite/gfortran.dg/coarray_ptr_comp_1.f08 trunk/gcc/testsuite/gfortran.dg/coarray_ptr_comp_2.f08 trunk/gcc/testsuite/gfortran.dg/coarray_ptr_comp_3.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/primary.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-types.c trunk/gcc/fortran/trans-types.h trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/caf/single.c
[Bug fortran/78935] [7 Regression] ICE on allocating derived type coarray with allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78935 --- Comment #9 from vehre at gcc dot gnu.org --- Author: vehre Date: Sat Jan 7 17:26:58 2017 New Revision: 244196 URL: https://gcc.gnu.org/viewcvs?rev=244196&root=gcc&view=rev Log: gcc/fortran/ChangeLog: 2017-01-07 Andre Vehreschild PR fortran/78781 PR fortran/78935 * expr.c (gfc_check_pointer_assign): Return the same error message for rewritten coarray pointer assignments like for plain ones. * gfortran.h: Change prototype. * primary.c (caf_variable_attr): Set attributes used ones only only ones. Add setting of pointer_comp attribute. (gfc_caf_attr): Add setting of pointer_comp attribute. * trans-array.c (gfc_array_allocate): Add flag that the component to allocate is not an ultimate coarray component. Add allocation of pointer arrays. (structure_alloc_comps): Extend nullify to treat pointer components in coarrays correctly. Restructure nullify to remove redundant code. (gfc_nullify_alloc_comp): Allow setting caf_mode flags. * trans-array.h: Change prototype of gfc_nullify_alloc_comp (). * trans-decl.c (generate_coarray_sym_init): Call nullify_alloc_comp for derived type coarrays with pointer components. * trans-expr.c (gfc_trans_structure_assign): Also treat pointer components. (trans_caf_token_assign): Handle assignment of token of scalar pointer components. (gfc_trans_pointer_assignment): Call above routine. * trans-intrinsic.c (conv_expr_ref_to_caf_ref): Add treating pointer components. (gfc_conv_intrinsic_caf_get): Likewise. (conv_caf_send): Likewise. * trans-stmt.c (gfc_trans_allocate): After allocating a derived type in a coarray pre-register the tokens. (gfc_trans_deallocate): Simply determining the coarray type (scalar or array) and deregistering it correctly. * trans-types.c (gfc_typenode_for_spec): Replace in_coarray flag by the actual codim to allow lookup of array types in the cache. (gfc_build_array_type): Likewise. (gfc_get_array_descriptor_base): Likewise. (gfc_get_array_type_bounds): Likewise. (gfc_get_derived_type): Likewise. * trans-types.h: Likewise. * trans.c (gfc_deallocate_with_status): Enable deregistering of all kind of coarray components. (gfc_deallocate_scalar_with_status): Use free() in fcoarray_single mode instead of caf_deregister. libgfortran/ChangeLog: 2017-01-07 Andre Vehreschild PR fortran/78781 PR fortran/78935 * caf/single.c (send_by_ref): Fix addressing of non-allocatable scalar destination components. gcc/testsuite/ChangeLog: 2017-01-07 Andre Vehreschild * gfortran.dg/coarray/ptr_comp_1.f08: New test. * gfortran.dg/coarray/ptr_comp_2.f08: New test. * gfortran.dg/coarray/ptr_comp_3.f08: New test. * gfortran.dg/coarray/ptr_comp_4.f08: New test. * gfortran.dg/coarray_ptr_comp_1.f08: New test. * gfortran.dg/coarray_ptr_comp_2.f08: New test. * gfortran.dg/coarray_ptr_comp_3.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/coarray/ptr_comp_1.f08 trunk/gcc/testsuite/gfortran.dg/coarray/ptr_comp_2.f08 trunk/gcc/testsuite/gfortran.dg/coarray/ptr_comp_3.f08 trunk/gcc/testsuite/gfortran.dg/coarray/ptr_comp_4.f08 trunk/gcc/testsuite/gfortran.dg/coarray_ptr_comp_1.f08 trunk/gcc/testsuite/gfortran.dg/coarray_ptr_comp_2.f08 trunk/gcc/testsuite/gfortran.dg/coarray_ptr_comp_3.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/primary.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-types.c trunk/gcc/fortran/trans-types.h trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/caf/single.c
[Bug fortran/78935] [7 Regression] ICE on allocating derived type coarray with allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78935 --- Comment #8 from vehre at gcc dot gnu.org --- Fixing 78781 seems to need the same code path like this pr. But the causes of the issues are not related.
[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 --- Comment #18 from Konstantin Belousov --- (In reply to Jonathan Wakely from comment #16) > Trunk no longer defines __cxa_thread_atexit if it's found in libc. We might > want to backport this to the gcc-5-branch and gcc-6-branch. > > I will try to test this in a FreeBSD 11 VM some time soon. I just built trunk gcc on FreeBSD HEAD. Indeed, the newest gcc does not export __cxa_thread_atexit from libstdc++.so.6 when configured on a FreeBSD system which provides the symbol from libc. I also added __cxa_thread_atexit_impl, which does help with older gcc versions. I verified that libstdc++.so.6 provides __cxa_thread_atexit and expectedly forwards the calls to libc:__cxa_thread_atexit_impl. https://svnweb.freebsd.org/changeset/base/311651
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 --- Comment #51 from Tim Ruehsen --- (In reply to Martin Sebor from comment #50) > Yes, -Wnull-dereference is only in GCC 6 and later. -Wnonnull is in 5 and > prior but it does only a superficial job of checking (it only detects null > pointer constants). in GCC 7, -Wnonnull does a better job (but it's still > far from perfect). This option is not for C ? gcc 6.3.0 with options '-Q --help=warnings,C' doesn't print it out. But '-Q --help=warnings' does. Correct or missing (and if missing what else is missing with C !?).
[Bug bootstrap/78880] [7 Regression] Revision 243196 breaks bootstrap on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78880 --- Comment #3 from Rainer Emrich --- (In reply to Jeffrey A. Law from comment #2) > When using a sysroot STARTFILE_PREFIX is supposed to be relative to the > sysroot variable -- meaning the mingw port is no longer going to be looking > in /mingw/lib by default. Instead it should be looking in > $sysroot/mingw/lib. I don't see why this request is invalid. I have the libraries and start files at /x86_64-w64-trunk/mingw/lib and configured gcc including "--with-sysroot=/x86_64-w64-trunk". That's exactly what you describe. This already worked for years until your change and it's broken now! Cheers Rainer
[Bug fortran/78935] [7 Regression] ICE on allocating derived type coarray with allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78935 --- Comment #7 from Dominique d'Humieres --- Related to/duplicate of pr78781?
[Bug c/79022] New: trunk/gcc/gengtype.h: create_nested_ptr_option: decl & defn don't match ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79022 Bug ID: 79022 Summary: trunk/gcc/gengtype.h: create_nested_ptr_option: decl & defn don't match ? Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- [trunk/gcc/gengtype.h:206] -> [trunk/gcc/gengtype.c:937]: (warning) Function 'create_nested_ptr_option' argument order different: declaration ', t, from, to' definition 'next, t, to, from' Line 206 is options_p create_nested_ptr_option (options_p, type_p t, const char *from, const char *to); Line 937 is options_p create_nested_ptr_option (options_p next, type_p t, const char *to, const char *from) Suggest the declaration should match the definition.
[Bug fortran/78942] Incorrect error message for preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78942 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-07 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- The behavior changed between revisions r218570 (2014-12-10, error for 'program F,AIL') and r218658 (2014-12-12, error for '# 1 "pr78942.F90"'), may be r218627 if the change comes from gfortran.
[Bug c++/79021] New: attribute noreturn on function template ignored in generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79021
Bug ID: 79021
Summary: attribute noreturn on function template ignored in
generic lambda
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Target Milestone: ---
When a generic lambda calls a function templates declared noreturn, we still
get warnings about missing return values.
$ cat foo.cc
template
[[noreturn]]
int f(T)
{
throw "error";
}
int g()
{
f(12);
}
template
int h(T)
{
f(12);
}
int main()
{
auto g = [](auto a) -> int { f(a); };
}
$ g++-mp-6 --version
g++-mp-6 (MacPorts gcc6 6.2.0_2) 6.2.0
Copyright (C) 2016 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.
$ g++-mp-6 -std=c++14 foo.cc -Wreturn-type
foo.cc: In lambda function:
foo.cc:21:38: warning: no return statement in function returning non-void
[-Wreturn-type]
auto g = [](auto a) -> int { f(a); };
^
$ clang++-mp-3.9 -std=c++14 foo.cc -Wreturn-type
$
Please note that:
- if f is not templated, there is no warning
- if the lambda is not generic, there is no warning
- if calling from a function template rather than from a generic template
(i.e., the function h), it does not trigger any warning (even if I do use h).
[Bug target/71017] libgcc/config/i386/cpuinfo.c:346:17: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71017 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-07 CC||kyukhin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Patch submitted at https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00470.html.
[Bug rtl-optimization/65827] LRA use smaller reg class than original reg for reload and it spill fail if reg class no hard reg available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65827 Chung-Ju Wu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jasonwucj at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Chung-Ju Wu --- (In reply to Andrew Pinski from comment #1) > This might have been fixed already. Thanks to reminder. :) Yes, after I try this PR on trunk, the problem no longer exist. Target: nds32le-elf Configure option: -target=nds32le-elf --enable-languages=c --enable-checking=yes --disable-multilib Testcase: gcc.c-torture/execute/pr65427.c GCC version: gcc version 7.0.0 20170101 (experimental) (GCC) So I think the status can be set as RESOLVED-FIXED.
[Bug target/44501] Wrong register stored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44501 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Resolution|--- |INVALID --- Comment #6 from Georg-Johann Lay --- Closed as invalig because AVR32 is not a supported target.
[Bug target/70677] Suboptimal cond on AVR: unneeded stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70677 --- Comment #10 from Georg-Johann Lay --- *** Bug 52025 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/52025] caller-saves triggers a frame without need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52025 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Georg-Johann Lay --- Not actually fixed, but since v6.2+ -fno-caller-saves is the default, cf. r239080. *** This bug has been marked as a duplicate of bug 70677 ***
[Bug translation/79020] New: translatable string typo in params.def:1173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79020 Bug ID: 79020 Summary: translatable string typo in params.def:1173 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: fmarchal at perso dot be Target Milestone: --- "Use direct poisoning/unpoisoning intructions for variables smaller or equal to this number." There is a missing letter in "instructions". Message found in ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170101/gcc-7-20170101.tar.bz2 proposed to translators.
[Bug translation/79019] New: translatable string typo in cif-code.def:141
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79019 Bug ID: 79019 Summary: translatable string typo in cif-code.def:141 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: fmarchal at perso dot be Target Milestone: --- The message "caller is instrumetnation thunk" contains an error in "instrumentation". Message found in ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170101/gcc-7-20170101.tar.bz2 proposed to translators.
[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484 --- Comment #23 from Markus Trippelsdorf --- Unfortunately vmakarov SPEC tester is currently stalled for most archs. However it still works for POWER7 and here r244167 shows no effect. https://vmakarov.fedorapeople.org/spec/spec2000.ibm-p730-05-lp5/gcc/home.html
[Bug fortran/78672] Gfortran test suite failures with a sanitized compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78672 Dominique d'Humieres changed: What|Removed |Added Attachment #40273|0 |1 is obsolete|| Attachment #40304|0 |1 is obsolete|| --- Comment #7 from Dominique d'Humieres --- Created attachment 40475 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40475&action=edit Results with revision r244110
[Bug target/71676] [avr] casesi won't handle switch values larger than 16 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71676 Georg-Johann Lay changed: What|Removed |Added Target Milestone|--- |7.0
[Bug target/71678] [avr] ICE from switch / case on long long (casesi + DImode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71678 Georg-Johann Lay changed: What|Removed |Added Target Milestone|--- |7.0
[Bug target/78946] optimization throws internal compiler error for uint64_t on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78946 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Georg-Johann Lay --- switch / case won't work with 64-bit values; it's beed fixed for v7. As the changes are intrusive, there are no plans to back-port them, and hence you'll have to resort to <= 32 bits in switch / case if you use v6 or older. *** This bug has been marked as a duplicate of bug 71678 ***
[Bug target/71678] [avr] ICE from switch / case on long long (casesi + DImode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71678 Georg-Johann Lay changed: What|Removed |Added CC||tho...@maier-komor.de --- Comment #5 from Georg-Johann Lay --- *** Bug 78946 has been marked as a duplicate of this bug. ***
[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484 --- Comment #22 from Dominik Vogt --- > Is changing one a day enough for periodic testers to catch up? I'll try to keep up with testing. > New Revision: 244167 Which numbers do you need r244167 vs. r244166 or vs. 243994 or both? (If I'm supposed to run the statistics script I'd need a pointer where to find and how to run it.)
[Bug rtl-optimization/78911] [5/6/7 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911 --- Comment #10 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #9) > At least for me it hangs already in that r216281: I don't have PR at hand, but pLease note that there were some problems with this pattern in the past, fixed in the RA in the meantime. With pseudo-PIC, there is enough registers available for RA, even with allocated frame-pointer.
[Bug translation/79018] translatable string typo in params.def:1105
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79018 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jsm28 at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek --- Fixed on the trunk, when gcc.pot is regenerated and resubmitted to the translation project, it should be fully resolved.
[Bug translation/79018] translatable string typo in params.def:1105
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79018 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Sat Jan 7 08:37:06 2017 New Revision: 244195 URL: https://gcc.gnu.org/viewcvs?rev=244195&root=gcc&view=rev Log: PR translation/79018 * params.def (PARAM_MAX_STORES_TO_MERGE): Add missing space between the and store. Modified: trunk/gcc/ChangeLog trunk/gcc/params.def
[Bug translation/79018] translatable string typo in params.def:1105
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79018 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-07 CC||jakub at gcc dot gnu.org Component|other |translation Ever confirmed|0 |1
