[Bug libfortran/67535] write.c sanitizer detects null pointer passed to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67535
--- Comment #6 from Vittorio Zecca ---
The cost of adding "if(base_name_len)" is two x86-64 machine instructions
cmpl$0, -20(%rbp)
je .L2
Six instructions follow then
call memcpy
which is not exactly a NOP even with base_name_len==0
In my opinion two machine instructions to avoid a useless and undefined memcpy
are a bargain.
It is not undefined behaviour to pass a NULL pointer to an arbitrary function,
but it is undefined to pass it to memcpy.
And it seems to me that after
memcpy(dest,src,len)
the statement "if(src)" is always TRUE because the optimizer assumes src!=NULL
The following is from https://gcc.gnu.org/gcc-4.9/porting_to.html
Null pointer checks may be optimized away more aggressively
GCC might now optimize away the null pointer check in code like:
int copy (int* dest, int* src, size_t nbytes) {
memmove (dest, src, nbytes);
if (src != NULL)
return *src;
return 0;
}
The pointers passed to memmove (and similar functions in ) must be
non-null even when nbytes==0, so GCC can use that information to remove the
check after the memmove call. Calling copy(p, NULL, 0) can therefore deference
a null pointer and crash.
The example above needs to be fixed to avoid the invalid memmove call, for
example:
if (nbytes != 0)
memmove (dest, src, nbytes);
This optimization can also affect implicit null pointer checks such as the one
done by the C++ runtime for the delete[] operator.
[Bug bootstrap/67546] bootstrap broken on x86_64-w64-mingw32, error: '::unsetenv' has not been declared in gcc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67546 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-11 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Kai Tietz --- I added to mingw-w64's libwinpthread a work-a-round for this sloopy code in libgomp. Nevertheless issue should be fixed IMO in libgomp, too
[Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741 Manfred Schwarb changed: What|Removed |Added CC||manfred99 at gmx dot ch --- Comment #33 from Manfred Schwarb --- There is some slight improvement since 2015-09-08: before: #> a 17.848000310.2399871 #> grep "number of SCoPs" a.f90.124t.graphite number of SCoPs: 0 number of SCoPs: 2 after: #> a 15.84710.2399871 #> grep "number of SCoPs" a.f90.121t.graphite number of SCoPs: 0 number of SCoPs: 1 which also gives a testsuite warning on my box: XPASS: gfortran.dg/graphite/pr14741.f90 -O scan-tree-dump-times graphite "number of SCoPs: 1" 1
[Bug target/63304] Aarch64 pc-relative load offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304 --- Comment #24 from Ramana Radhakrishnan --- Author: ramana Date: Fri Sep 11 09:44:26 2015 New Revision: 227679 URL: https://gcc.gnu.org/viewcvs?rev=227679&root=gcc&view=rev Log: Remove separate movtf pattern - Use an iterator for all FP modes. movtf is unnecessary as a separate expander. Move this to be with the standard scalar floating point expanders. Achieved by adding a new iterator and then using the same. Tested cross aarch64-none-elf and no regressions. Rebased version from https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00767.html 2015-09-10 Ramana Radhakrishnan PR target/63304 * config/aarch64/aarch.md (mov:GPF_F16): Use GPF_TF_F16. (movtf): Delete. * config/aarch64/iterators.md (GPF_TF_F16): New. (GPF_F16): Delete. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.md trunk/gcc/config/aarch64/iterators.md
[Bug target/67506] [5/6 Regression][SH]: error: unrecognizable insn when compiling texlive-binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506 --- Comment #9 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #6) > Thanks. I will commit it and add attachment 36309 [details] as a c-torture > test. Thanks for the quick bug fix! Matthias already uploaded a new gcc-5 snapshot today which contains the fix :). Adrian
[Bug libstdc++/65092] Container adaptors missing allocator-extended constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65092 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #2 from Jonathan Wakely --- Fixed on trunk
[Bug libstdc++/65092] Container adaptors missing allocator-extended constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65092 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Fri Sep 11 09:51:29 2015 New Revision: 227680 URL: https://gcc.gnu.org/viewcvs?rev=227680&root=gcc&view=rev Log: Allocator-extended constructors for container adaptors. PR libstdc++/65092 * include/bits/stl_queue.h (queue, priority_queue): Add allocator-extended constructors. * include/bits/stl_stack.h (stack): Likewise. * testsuite/23_containers/priority_queue/requirements/ uses_allocator.cc: Test allocator-extended constructors. * testsuite/23_containers/queue/requirements/uses_allocator.cc: Likewise. * testsuite/23_containers/stack/requirements/uses_allocator.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_queue.h trunk/libstdc++-v3/include/bits/stl_stack.h trunk/libstdc++-v3/testsuite/23_containers/priority_queue/requirements/uses_allocator.cc trunk/libstdc++-v3/testsuite/23_containers/queue/requirements/uses_allocator.cc trunk/libstdc++-v3/testsuite/23_containers/stack/requirements/uses_allocator.cc
[Bug libstdc++/66902] _S_debug_messages is unneccessary public
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66902 --- Comment #5 from Vadim Zhukov --- (In reply to Jonathan Wakely from comment #4) > Author: redi > Date: Thu Sep 3 19:05:15 2015 > New Revision: 227466 > > URL: https://gcc.gnu.org/viewcvs?rev=227466&root=gcc&view=rev > Log: > PR libstdc++/66902 > * src/c++11/debug.cc (_S_debug_messages): Make array const. > > Modified: > trunk/libstdc++-v3/ChangeLog > trunk/libstdc++-v3/src/c++11/debug.cc I see that you removed "static" modifier in that commit, effectively making the array in question exported again. Was it intended?
[Bug bootstrap/67546] bootstrap broken on x86_64-w64-mingw32, error: '::unsetenv' has not been declared in gcc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67546 --- Comment #2 from Rainer Emrich --- (In reply to Kai Tietz from comment #1) > I added to mingw-w64's libwinpthread a work-a-round for this sloopy code in > libgomp. Nevertheless issue should be fixed IMO in libgomp, too Wrong PR, this belongs to PR67141.
[Bug libgomp/67141] wrong libgomp mutex initialisation order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67141 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-11 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Kai Tietz --- I added to mingw-w64's libwinpthread a work-a-round for this sloppy code. Nevertheless the issue should be fixed IMO in libgomp, too
[Bug bootstrap/67546] bootstrap broken on x86_64-w64-mingw32, error: '::unsetenv' has not been declared in gcc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67546 --- Comment #3 from Kai Tietz --- Thanks Rainer for pointing on this. Yes, comment wasn't intended for this bug. I added comment to proper pr ... This issue is related to the fact that msvcrt doesn't provide unsetenv (as it doesn't provide setenv). Instead all this functionality needs to be expressed via getenv/putenv instead.
[Bug bootstrap/67546] bootstrap broken on x86_64-w64-mingw32, error: '::unsetenv' has not been declared in gcc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67546 Kai Tietz changed: What|Removed |Added Target|x86_64-w64-mingw32 |*-*-mingw32 Priority|P3 |P1 CC||dmalcolm at gcc dot gnu.org --- Comment #4 from Kai Tietz --- Hi David, this issue was introduced by your commit done at 2015-08-25
[Bug libstdc++/66902] _S_debug_messages is unneccessary public
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66902 --- Comment #6 from Jonathan Wakely --- 3.5 [basic.link]: -3- A name having namespace scope (3.3.6) has internal linkage if it is the name of — a variable, function or function template that is explicitly declared static; or, — a variable of non-volatile const-qualified type that is neither explicitly declared extern nor previously declared to have external linkage; or — a data member of an anonymous union. The first bullet applied when it was explicitly declared static and the second bullet applies now that it is a const-qualified type at namespace scope. In both cases it has internal linkage, so you should not see a global symbol and should not get the warning.
[Bug rtl-optimization/58517] ifcvt (after combine) puts ccreg clobbering insn between ccset insn and ccreg use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517 Oleg Endo changed: What|Removed |Added CC||kyrylo.tkachov at arm dot com --- Comment #5 from Oleg Endo --- Kyrill, since you are currently working on ifcvt related things, could you maybe have a look at this issue? I haven't checked it in a while, so I don't know if it's still a problem.
[Bug tree-optimization/67476] Add --param parloops-schedule=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67476 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #4 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00782.html
[Bug target/67506] [5/6 Regression][SH]: error: unrecognizable insn when compiling texlive-binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506 --- Comment #10 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #9) > > Thanks for the quick bug fix! Matthias already uploaded a new gcc-5 snapshot > today which contains the fix :). I guess it will take a while until you've got a new GCC build. I think we can close this as fixed?
[Bug libstdc++/58265] [lwg/2063] std::string move assignment should be noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58265 --- Comment #9 from Jonathan Wakely --- Author: redi Date: Fri Sep 11 11:02:14 2015 New Revision: 227681 URL: https://gcc.gnu.org/viewcvs?rev=227681&root=gcc&view=rev Log: Implement N4258 noexcept for std::basic_string. PR libstdc++/58265 * doc/xml/manual/intro.xml: Document LWG 2063 and 2064 resolutions. * doc/html/manual/bugs.html: Regenerate. * include/bits/basic_string.h (basic_string): Implement N4258. Add correct exception-specifications and propagate allocators correctly. * include/bits/basic_string.tcc (basic_string::swap): Propagate allocators correctly. * include/debug/string (__gnu_debug::basic_string): Add correct exceptions-specifications and allcoator-extended constructors. * testsuite/21_strings/basic_string/allocator/char/copy.cc: New. * testsuite/21_strings/basic_string/allocator/char/copy_assign.cc: New. * testsuite/21_strings/basic_string/allocator/char/minimal.cc: New. * testsuite/21_strings/basic_string/allocator/char/move.cc: New. * testsuite/21_strings/basic_string/allocator/char/move_assign.cc: New. * testsuite/21_strings/basic_string/allocator/char/noexcept.cc: New. * testsuite/21_strings/basic_string/allocator/char/swap.cc: New. * testsuite/21_strings/basic_string/allocator/wchar_t/copy.cc: New. * testsuite/21_strings/basic_string/allocator/wchar_t/copy_assign.cc: New. * testsuite/21_strings/basic_string/allocator/wchar_t/minimal.cc: New. * testsuite/21_strings/basic_string/allocator/wchar_t/move.cc: New. * testsuite/21_strings/basic_string/allocator/wchar_t/move_assign.cc: New. * testsuite/21_strings/basic_string/allocator/wchar_t/noexcept.cc: New. * testsuite/21_strings/basic_string/allocator/wchar_t/swap.cc: New. * testsuite/util/testsuite_allocator.h (tracker_allocator): Define defaulted assignment operators. Added: trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/ trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/ trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/copy.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/copy_assign.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/minimal.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/move.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/move_assign.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/noexcept.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/swap.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/ trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/copy.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/copy_assign.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/minimal.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/move.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/move_assign.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/noexcept.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/swap.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/html/manual/bugs.html trunk/libstdc++-v3/doc/xml/manual/intro.xml trunk/libstdc++-v3/include/bits/basic_string.h trunk/libstdc++-v3/include/bits/basic_string.tcc trunk/libstdc++-v3/include/debug/string trunk/libstdc++-v3/testsuite/util/testsuite_allocator.h
[Bug libstdc++/58265] [lwg/2063] std::string move assignment should be noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58265 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #10 from Jonathan Wakely --- Fixed on trunk.
[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64883 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #36 from Jonathan Wakely --- I think my work here is done. Leaving open in case anyone wants to do anything further, if not please close it.
[Bug rtl-optimization/58517] ifcvt (after combine) puts ccreg clobbering insn between ccset insn and ccreg use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #6 from ktkachov at gcc dot gnu.org --- (In reply to Oleg Endo from comment #5) > Kyrill, since you are currently working on ifcvt related things, could you > maybe have a look at this issue? I haven't checked it in a while, so I > don't know if it's still a problem. Huh, I wasn't aware of this BZ. This looks eerily similar to what I think is the root cause of PR 67481, which I'm working on now. After I'm done with PR 67481 it would be interesting to have a look whether they are indeed the same issue
[Bug libstdc++/66902] _S_debug_messages is unneccessary public
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66902 --- Comment #7 from Vadim Zhukov --- (In reply to Jonathan Wakely from comment #6) > 3.5 [basic.link]: > > -3- A name having namespace scope (3.3.6) has internal linkage if it is the > name of > — a variable, function or function template that is explicitly declared > static; or, > — a variable of non-volatile const-qualified type that is neither > explicitly declared extern nor previously declared to have external > linkage; or > — a data member of an anonymous union. > > The first bullet applied when it was explicitly declared static and the > second bullet applies now that it is a const-qualified type at namespace > scope. In both cases it has internal linkage, so you should not see a global > symbol and should not get the warning. Sorry, I've missed that. Thank you for clarification.
[Bug rtl-optimization/58517] ifcvt (after combine) puts ccreg clobbering insn between ccset insn and ccreg use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517 --- Comment #7 from Oleg Endo --- (In reply to ktkachov from comment #6) > Huh, I wasn't aware of this BZ. > This looks eerily similar to what I think is the root cause of PR 67481, > which I'm working on now. > > After I'm done with PR 67481 it would be interesting to have a look whether > they are indeed the same issue OK, thanks!
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #94 from Oleg Endo --- Kaz, do you think we can enable LRA by default for GCC 6? Some early results from the AMS optimization show new R0 spill failures. For example, AMS uses @(R0,Rn) address modes more often. Although I still would like to try this R0 prealloc pass, I don't know when I will have time for that. Enabling LRA might be easier.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #95 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #94) > Kaz, do you think we can enable LRA by default for GCC 6? I think that it's OK to make LRA default on trunk, even if it's better with your R0 pre-allocating pass. The last time I tested -mlra, there are some regressions, though. I'd like to test it again. Could you see any serious problems on sh-elf with -mlra?
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #96 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #95) > > I think that it's OK to make LRA default on trunk, even if it's > better with your R0 pre-allocating pass. The R0 pre-alloc pass could be a further improvement, even with LRA. > The last time I tested -mlra, there are some regressions, though. > I'd like to test it again. Could you see any serious problems on > sh-elf with -mlra? I haven't tried yet. I will do a full toolchain rebuild and test with -mlra enabled by default.
[Bug libstdc++/67096] libstdc++ testsuite, codecvt: many UTF-8 tests illegal (testing bytes 5 and 6)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67096 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug c/67547] New: may be an error in printf(%a..) for nexttowardf(0.f,1.f)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67547
Bug ID: 67547
Summary: may be an error in printf(%a..) for
nexttowardf(0.f,1.f)
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ka_bena at yahoo dot fr
Target Milestone: ---
include
include
int main(void)
{
printf(" %E\n", nexttowardf ( 0.F , 1.F ) ) ;
printf(" %A\n", nexttowardf ( 0.F , 1.F ) ) ;
printf(" %A\n", nexttoward ( 0. , 1. ) ) ;
return 0 ;
}
/* Results
1.401298E-045
0X0P-149
0X1P-1023
Comment:: may be an error in printf("%A...) for this value ?
Microsoft Windows XP Profesional version2002 Service Pack 3.
Gcc 4.8.0 win32 mingw32
std =-C99
*/
[Bug lto/67548] New: [5/6 Regression] LTO drops weak binding with "ld -r"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548
Bug ID: 67548
Summary: [5/6 Regression] LTO drops weak binding with "ld -r"
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
[hjl@gnu-6 lto]$ cat test.c
extern int x;
void foobar (void) { x--; }
[hjl@gnu-6 lto]$ cat test-weak.c
#include
int x;
__attribute__((weak))
void foobar (void) { x++; }
int main (void)
{
foobar ();
if (x == -1)
printf ("OK\n");
return 0;
}
[hjl@gnu-6 lto]$ make
gcc -flto -O2-c -o test-weak.o test-weak.c
gcc -flto -O2 -nostdlib -r -o test-intermediate.o test-weak.o
readelf -sW test-intermediate.o | grep foobar
10: 8 FUNCGLOBAL DEFAULT1 foobar
gcc -flto -O2-c -o test.o test.c
gcc -flto -O2 test-intermediate.o test.o -o prog
test.o (symbol from plugin): In function `foobar':
(.text+0x0): multiple definition of `foobar'
test-intermediate.o:(.text+0x0): first defined here
/tmp/cciS2u59.ltrans0.ltrans.o: In function `foobar':
:(.text+0x0): multiple definition of `foobar'
test-intermediate.o:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
Makefile:11: recipe for target 'prog' failed
make: *** [prog] Error 1
[hjl@gnu-6 lto]$
[Bug c++/67549] New: internal compiler error: in fold_binary_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67549
Bug ID: 67549
Summary: internal compiler error: in fold_binary_loc
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wolfgang.roe...@gi-de.com
Target Milestone: ---
Hi,
I would like to post a bug report for the GNU C/C++ compiler 4.8.3.
We use the compiler to generate code for a PowerPC processor.
Invokation line for the GNU C++ compiler:
ccppc -c -x c++ -std=c++11 -Wall -Werror -g -mcpu=8540 -meabi
-ftls-model=local-exec -msdata=sysv -fno-common -mspe -mabi=spe
-mfloat-gprs=double -mbig -mmultiple -mno-string -misel -mstrict-align
-fverbose-asm -fno-exceptions -fno-rtti -fgcse-sm -fno-section-anchors
-ftemplate-backtrace-limit=20 -G 8 -O3
-I
-D
X.CPP -oX.O
// file test.CPP
class B
{
public:
typedef void (B::* T_PTRFUNC)(int);
virtual void elem_func (int);
static T_PTRFUNC ptr_func = &B::elem_func;
};
..compiling this file I get the following message:
test.CPP:6:37: internal compiler error: in fold_binary_loc, at
fold-const.c:9907
static T_PTRFUNC ptr_func = &B::elem_func;
^
Kind regards
W. Roehrl
[Bug c/67547] may be an error in printf(%a..) for nexttowardf(0.f,1.f)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67547
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Andrew Pinski ---
Report this to mingw since that is where printf comes from (though it might
come directly from Microsoft's libc).
Also by the way nexttowardf is C99 and not C89 so I am getting warnings with
glibc and C89:
t1.c: In function 'main':
t1.c:6:20: warning: implicit declaration of function 'nexttowardf'
[-Wimplicit-function-declaration]
printf(" %E\n", nexttowardf ( 0.F , 1.F ) ) ;
^
t1.c:6:10: warning: format '%E' expects argument of type 'double', but argument
2 has type 'int' [-Wformat=]
printf(" %E\n", nexttowardf ( 0.F , 1.F ) ) ;
^
t1.c:7:10: warning: format '%A' expects argument of type 'double', but argument
2 has type 'int' [-Wformat=]
printf(" %A\n", nexttowardf ( 0.F , 1.F ) ) ;
^
t1.c:8:20: warning: implicit declaration of function 'nexttoward'
[-Wimplicit-function-declaration]
printf(" %A\n", nexttoward ( 0. , 1. ) ) ;
^
t1.c:8:10: warning: format '%A' expects argument of type 'double', but argument
2 has type 'int' [-Wformat=]
printf(" %A\n", nexttoward ( 0. , 1. ) ) ;
[Bug c++/67549] internal compiler error: in fold_binary_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67549 --- Comment #1 from Andrew Pinski --- 4.8.x is no longer support, can you try 4.9.x and above?
[Bug libstdc++/64857] Headers missing from and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64857 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #2 from Jonathan Wakely --- Fixed on trunk.
[Bug libstdc++/64857] Headers missing from and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64857 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Fri Sep 11 12:25:43 2015 New Revision: 227684 URL: https://gcc.gnu.org/viewcvs?rev=227684&root=gcc&view=rev Log: Rationalise PCH headers and 17_intro/headers tests. PR libstdc++/64857 * doc/xml/manual/using.xml: Improve aggregate header documentation. * doc/html/manual/*: Regenerate. * include/precompiled/extc++.h: Include for C++11 and later and include more extension headers. * testsuite/17_intro/headers/c++1998/all_attributes.cc: Remove redundant header. * testsuite/17_intro/headers/c++200x/: Rename to c++2011. * testsuite/17_intro/headers/c++2014/all_attributes.cc: Remove redundant headers. * testsuite/17_intro/headers/c++2014/all_no_exceptions.cc: New. * testsuite/17_intro/headers/c++2014/all_no_rtti.cc: New. * testsuite/17_intro/headers/c++2014/all_pedantic_errors.cc: New. * testsuite/17_intro/headers/c++2014/operator_names.cc: New. * testsuite/17_intro/headers/c++2014/stdc++.cc: New. * testsuite/17_intro/headers/c++2014/stdc++_multiple_inclusion.cc: New. Added: trunk/libstdc++-v3/testsuite/17_intro/headers/c++2011/ trunk/libstdc++-v3/testsuite/17_intro/headers/c++2011/42319.cc - copied, changed from r227681, trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/42319.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++2011/67309.cc - copied, changed from r227681, trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/67309.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++2011/all_attributes.cc - copied, changed from r227681, trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_attributes.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++2011/all_no_exceptions.cc - copied, changed from r227681, trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_no_exceptions.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++2011/all_no_rtti.cc - copied, changed from r227681, trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_no_rtti.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++2011/all_pedantic_errors.cc - copied, changed from r227681, trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_pedantic_errors.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++2011/operator_names.cc - copied, changed from r227681, trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/operator_names.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++2011/stdc++.cc - copied, changed from r227681, trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/stdc++.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++2011/stdc++_multiple_inclusion.cc - copied, changed from r227681, trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/stdc++_multiple_inclusion.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_no_exceptions.cc - copied, changed from r227681, trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_no_rtti.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_no_rtti.cc - copied, changed from r227681, trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_no_rtti.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_pedantic_errors.cc - copied, changed from r227681, trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_no_rtti.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++2014/operator_names.cc - copied, changed from r227681, trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/operator_names.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++2014/stdc++.cc - copied, changed from r227681, trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/stdc++.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++2014/stdc++_multiple_inclusion.cc - copied, changed from r227681, trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/stdc++_multiple_inclusion.cc Removed: trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/42319.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/67309.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_attributes.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_no_exceptions.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_no_rtti.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_pedantic_errors.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/operator_names.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/stdc++.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/stdc++_multiple_inclusion.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/html/manual/using.html trunk/libstdc++-v3/doc/html/manual/using_headers.html trunk/libstdc++-v3/doc/xml/manual/using.xml trunk/libstdc++-v3/include/precompiled/extc++.h
[Bug lto/67548] [5/6 Regression] LTO drops weak binding with "ld -r"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-11 CC||hubicka at ucw dot cz Target Milestone|--- |5.3 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- It was caused by r210592.
[Bug c/67095] errno for logf(-1.f)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67095 --- Comment #2 from BENAÏSSA --- Thank you for your reply. A.Benaïssa. Le Dimanche 2 août 2015 13h46, pinskia at gcc dot gnu.org a écrit : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67095 Andrew Pinski changed: What |Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- Not a gcc bug as gcc does not provide logf. Please report it to mingw if you want the optional setting of errno to happen (note this is optional for both c and posix).
[Bug lto/67548] [5/6 Regression] LTO drops weak binding with "ld -r"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548 --- Comment #2 from H.J. Lu --- This may be a linker bug if it tells GCC that a weak symbol is prevailing with "ld -r".
[Bug libstdc++/67096] libstdc++ testsuite, codecvt: many UTF-8 tests illegal (testing bytes 5 and 6)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67096 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Fri Sep 11 13:06:42 2015 New Revision: 227686 URL: https://gcc.gnu.org/viewcvs?rev=227686&root=gcc&view=rev Log: Fix invalid UTF-8 in wchar_t tests. 2015-09-11 John Marino Jonathan Wakely PR libstdc++/67096 * testsuite/22_locale/codecvt/in/wchar_t/4.cc: Do not test code points above U+10. * testsuite/22_locale/codecvt/in/wchar_t/8.cc: Likewise. * testsuite/22_locale/codecvt/in/wchar_t/9.cc: Likewise. * testsuite/22_locale/codecvt/length/wchar_t/4.cc: Likewise. * testsuite/22_locale/codecvt/out/wchar_t/4.cc: Likewise. * testsuite/22_locale/codecvt/unshift/wchar_t/4.cc: Likewise. * testsuite/27_io/basic_filebuf/seekoff/wchar_t/1.cc: Likewise. * testsuite/27_io/basic_filebuf/seekpos/wchar_t/9874.cc: Likewise. * testsuite/27_io/basic_filebuf/underflow/wchar_t/1.cc: Likewise. * testsuite/27_io/basic_filebuf/underflow/wchar_t/2.cc: Likewise. * testsuite/27_io/basic_filebuf/underflow/wchar_t/3.cc: Likewise. * testsuite/27_io/objects/wchar_t/10.cc: Likewise. * testsuite/27_io/objects/wchar_t/11.cc: Likewise. * testsuite/27_io/objects/wchar_t/12.cc: Likewise. * testsuite/27_io/objects/wchar_t/13.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/22_locale/codecvt/in/wchar_t/4.cc trunk/libstdc++-v3/testsuite/22_locale/codecvt/in/wchar_t/8.cc trunk/libstdc++-v3/testsuite/22_locale/codecvt/in/wchar_t/9.cc trunk/libstdc++-v3/testsuite/22_locale/codecvt/length/wchar_t/4.cc trunk/libstdc++-v3/testsuite/22_locale/codecvt/out/wchar_t/4.cc trunk/libstdc++-v3/testsuite/22_locale/codecvt/unshift/wchar_t/4.cc trunk/libstdc++-v3/testsuite/27_io/basic_filebuf/seekoff/wchar_t/1.cc trunk/libstdc++-v3/testsuite/27_io/basic_filebuf/seekpos/wchar_t/9874.cc trunk/libstdc++-v3/testsuite/27_io/basic_filebuf/underflow/wchar_t/1.cc trunk/libstdc++-v3/testsuite/27_io/basic_filebuf/underflow/wchar_t/2.cc trunk/libstdc++-v3/testsuite/27_io/basic_filebuf/underflow/wchar_t/3.cc trunk/libstdc++-v3/testsuite/27_io/objects/wchar_t/10.cc trunk/libstdc++-v3/testsuite/27_io/objects/wchar_t/11.cc trunk/libstdc++-v3/testsuite/27_io/objects/wchar_t/12.cc trunk/libstdc++-v3/testsuite/27_io/objects/wchar_t/13.cc
[Bug bootstrap/67546] bootstrap broken on x86_64-w64-mingw32, error: '::unsetenv' has not been declared in gcc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67546 --- Comment #5 from David Malcolm --- Is this a duplicate of PR 67363?
[Bug libstdc++/67096] libstdc++ testsuite, codecvt: many UTF-8 tests illegal (testing bytes 5 and 6)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67096 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #3 from Jonathan Wakely --- Should be fixed now, let me know if there are others that need fixing.
[Bug bootstrap/67546] bootstrap broken on x86_64-w64-mingw32, error: '::unsetenv' has not been declared in gcc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67546 --- Comment #6 from Kai Tietz --- Initially in PR/67363 just the missing strndup due failed libiberty-linking was noticed. Later comments are duplicate of this. So feel free to mark one of these bugs as duplicate, if you prefer.
[Bug fortran/67509] [6 regression] FAIL: gfortran.dg/ieee/ieee_7.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67509 --- Comment #6 from Andreas Schwab --- With that patch the test passes on all opt levels.
[Bug libstdc++/65142] std::random_device Ignores Read Return Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65142 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug libstdc++/65142] std::random_device Ignores Read Return Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65142 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |5.3 --- Comment #2 from Jonathan Wakely --- Fixed on trunk so far.
[Bug libstdc++/65142] std::random_device Ignores Read Return Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65142 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Fri Sep 11 13:44:26 2015 New Revision: 227687 URL: https://gcc.gnu.org/viewcvs?rev=227687&root=gcc&view=rev Log: Check read() result in std::random_device. PR libstdc++/65142 * src/c++11/random.cc (random_device::_M_getval()): Check read result. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++11/random.cc
[Bug tree-optimization/59478] Optimize variable access via byte copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59478
--- Comment #1 from Oleg Endo ---
(In reply to Oleg Endo from comment #0)
> This happens at least on SH with trunk rev 205905 (4.9).
> I'm not sure whether these are target specific or not.
>
> Accessing float values as integers can be done in various ways. One way is
> to do a byte copy...
>
> int float_as_int (float val)
> {
> char valbytes[sizeof (float)];
> __builtin_memcpy (valbytes, &val, sizeof (float));
>
> int result;
> __builtin_memcpy (&result, valbytes, sizeof (float));
>
> return result;
> }
>
> The above compiled with -m4-single -ml -O2 results in:
>
> add #-8,r15
> fmov.s fr5,@r15
> mov.l @r15,r0
> rts
> add #8,r15
>
> which is not so bad actually, but could be done better by utilizing the fpul
> register, as it is done when using the union approach:
This case got better. It now produces the expected sequence:
fldsfr5,fpul
rts
sts fpul,r0
[Bug fortran/67531] No IEEE rounding support for powerpc long double type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67531
--- Comment #5 from Pat Haugen ---
(In reply to Francois-Xavier Coudert from comment #3)
> How about with this? I'm trying to come as close as possible to the exact
> sequence of fe.etround() calls as the Fortran front-end and runtime library
> would end up performing…
>
>
> #include
> #include
>
> int main (void)
> {
> int r;
> long double x1, x2, x;
>
> x1 = 1;
> x = 3;
> r = fegetround ();
> fesetround (FE_UPWARD);
> x1 = x1 / x;
> fesetround (r);
>
> x2 = 1;
> x = 3;
> r = fegetround ();
> fesetround (FE_DOWNWARD);
> x2 = x2 / x;
> fesetround (r);
>
> printf ("%.40Lg\n", x1);
> printf ("%.40Lg\n", x2);
> }
pthaugen@genoa:~$ ~/install/gcc/trunk/bin/gcc junk.c -lm && ./a.out
0.53876586
0.333292246828
[Bug libstdc++/67173] experimental/filesystem/operations/current_path.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67173 --- Comment #1 from Jonathan Wakely --- Solaris 10 doesn't support realpath(path, NULL) as used in filesystem::canonical() so we need to allocate a buffer for it.
[Bug libstdc++/67173] experimental/filesystem/operations/current_path.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67173 --- Comment #2 from Jonathan Wakely --- Oops, I'm leaking the memory allocated by realpath() so that needs fixing anyway.
[Bug c++/67550] New: Initialization of local struct array with elements of global array yields zeros instead of initializer values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67550
Bug ID: 67550
Summary: Initialization of local struct array with elements of
global array yields zeros instead of initializer
values
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: f.knauf at mmkf dot de
Target Milestone: ---
Initializing a function-local struct array from values in a global struct array
yields wrong values with gcc 5.2.1. The problem can be reproduced with the
following code:
#include
#include
struct S {
int x;
int y;
};
S const data[] = {
{ 1, std::numeric_limits::max() }
};
int main() {
S data2[] = {
data[0]
};
std::cout
<< data [0].x << ", " << data [0].y << "\n"
<< data2[0].x << ", " << data2[0].y << "\n"
;
}
The output is:
$ g++ -Wall -Wextra -pedantic foo.cc
$ ./a.out
1, 2147483647
1, 0
The expected output was:
1, 2147483647
1, 2147483647
I am using gcc 5.2.1 on Debian sid (Linux 4.1.3) for x86-64. The error is also
reproducible with gcc 5.2.0 on Arch Linux (also x86-64) and gcc 5.1.1 on Fedora
22 (also x86-64). It is not reproducible with gcc 4.9.3.
A workaround for the error is to remove the "const" keyword from the
declaration of "data", i.e.
S data[] = {
{ 1, std::numeric_limits::max() }
};
The error also does not appear if std::numeric_limits::max() is replaced
with a compile-time constant value (such as 42). Consequently, in C++11 mode
(where std::numeric_limits::max() is constexpr) the above code does not
reproduce the error. Instead,
int foo() { return 23; }
S const data[] = {
{ 1, foo() }
};
can be used to produce the wrong result. With
int constexpr foo() { return 23; }
the correct result is produced.
[Bug libstdc++/67173] experimental/filesystem/operations/current_path.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67173 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Fri Sep 11 14:20:32 2015 New Revision: 227689 URL: https://gcc.gnu.org/viewcvs?rev=227689&root=gcc&view=rev Log: Fix filesystem::canonical on Solaris 10. PR libstdc++/67173 * src/filesystem/ops.cc (filesystem::canonical): Allocate buffer for realpath on Solaris 10. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/filesystem/ops.cc
[Bug libstdc++/67173] experimental/filesystem/operations/current_path.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67173 Jonathan Wakely changed: What|Removed |Added Target Milestone|6.0 |5.3 --- Comment #4 from Jonathan Wakely --- Fixed on trunk so far, will fix gcc-5-branch too.
[Bug c++/67550] Initialization of local struct array with elements of global array yields zeros instead of initializer values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67550
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-09-11
CC||trippels at gcc dot gnu.org
Known to work||4.9.3
Ever confirmed|0 |1
Known to fail||5.2.1, 6.0
--- Comment #1 from Markus Trippelsdorf ---
Also happens with a local array:
struct S {
int x;
int y;
};
int foo() { return 1; }
int main() {
S const data[] = {{0, foo()}};
S data2[] = {data[0]};
if (!data2[0].y)
__builtin_abort();
}
[Bug preprocessor/67551] New: Preprocessor generates non-ISO line directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67551
Bug ID: 67551
Summary: Preprocessor generates non-ISO line directives
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: porten at kde dot org
Target Milestone: ---
The code emitted by the preprocessor does produce warnings when compiled as
C/C++ code with -pedantic:
$ echo "int main() { return 0; }" > input.c
$ cpp -o output.c input.c
$ gcc -pedantic output.c
output.c:1:3: warning: style of line directive is a GCC extension
# 1 "input.c"
^
input.c:1:3: warning: style of line directive is a GCC extension
int main() { return 0; }
^
: warning: style of line directive is a GCC extension
:1:3: warning: style of line directive is a GCC extension
:1:3: warning: style of line directive is a GCC extension
Admittedly, this is not the normal usage mode. And when using an .i suffix for
the output file (as done by -save-temps) the -pedantic check does not kick in.
[Bug preprocessor/67551] Preprocessor generates non-ISO line directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67551 --- Comment #1 from Andrew Pinski --- Or you could use -fpreprocessed as another option which is the same as doing .i.
[Bug preprocessor/67551] Preprocessor generates non-ISO line directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67551 --- Comment #2 from Andrew Pinski --- You can also use -P to get rid of the line markers from the processor output which avoids your warning.
[Bug other/67552] New: [meta] x86 interrupt attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67552 Bug ID: 67552 Summary: [meta] x86 interrupt attribute Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: julia.koval at intel dot com Target Milestone: --- This meta bug covers all interrupt attribute issues on jkoval/interrupt/master branch in GCC git repo.
[Bug preprocessor/67551] Option for the Preprocessor generates to generate #line rather than the GCC extension for line markers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67551 Andrew Pinski changed: What|Removed |Added Summary|Preprocessor generates |Option for the Preprocessor |non-ISO line directives |generates to generate #line ||rather than the GCC ||extension for line markers Severity|normal |enhancement --- Comment #3 from Andrew Pinski --- I think the request here is to have an option which outputs #line rather than "# "filename" ..."
[Bug other/67552] [meta] x86 interrupt attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67552 --- Comment #1 from H.J. Lu --- Created attachment 36324 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36324&action=edit A patch to remove railing whitespaces in interrupt-switch-abi.c
[Bug other/67552] [meta] x86 interrupt attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67552
--- Comment #2 from H.J. Lu ---
Red zone isn't supported in interrupt handler:
'interrupt'
Use this attribute to indicate that the specified void function
without arguments is an interrupt handler. The compiler generates
function entry and exit sequences suitable for use in an interrupt
handler when this attribute is present. The 'IRET' instruction,
instead of the 'RET' instruction, is used to return from interrupt
handlers. All registers, except for the EFLAGS register which is
restored by the 'IRET' instruction, are preserved by the compiler.
The red zone isn't supported in an interrupt handler; that is an
interrupt handler can't access stack beyond the current stack
pointer.
It is wrong to do
- if (crtl->args.pops_args && crtl->args.size)
+ if (ix86_is_interrupt_p ())
+{
+ if (ix86_using_red_zone ())
+ emit_insn (gen_adddi3 (
+ gen_rtx_REG (DImode, SP_REG),
+ gen_rtx_REG (DImode, SP_REG),
+ GEN_INT (128)));
GCC should assume that red zone isn't used in interrupt handler.
[Bug preprocessor/67551] Option for the Preprocessor generates to generate #line rather than the GCC extension for line markers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67551 --- Comment #4 from porten at kde dot org --- Right. Usage of #line would be nicer. But if the additional bytes just slow down things... The recommended -fpreprocessed appears to be a good workaround. Does it maybe even speed up the compilation?
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #97 from Oleg Endo --- (In reply to Oleg Endo from comment #96) > > I haven't tried yet. I will do a full toolchain rebuild and test with -mlra > enabled by default. I've compared the results of r227512 without LRA and r227682 with LRA. Below are the new failures. Running target sh-sim/-m2/-mb FAIL: gcc.c-torture/execute/20040709-2.c -Os execution test FAIL: gcc.target/sh/hiconst.c scan-assembler-times mov\t#0 2 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,r[0-9]\\) 44 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,r[0-9]\\) 44 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,r[0-9]\\) 36 Running target sh-sim/-m2/-ml FAIL: gcc.target/sh/hiconst.c scan-assembler-times mov\t#0 2 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,r[0-9]\\) 44 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,r[0-9]\\) 44 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,r[0-9]\\) 36 Running target sh-sim/-m2a/-mb FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,r[0-9]\\) 44 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,r[0-9]\\) 44 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,r[0-9]\\) 36 Running target sh-sim/-m4/-mb FAIL: gcc.target/sh/hiconst.c scan-assembler-times mov\t#0 2 AIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,r[0-9]\\) 44 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,r[0-9]\\) 44 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,r[0-9]\\) 36 Running target sh-sim/-m4/-ml FAIL: gcc.target/sh/hiconst.c scan-assembler-times mov\t#0 2 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(16,r[0-9]\\) 44 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(4,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,gbr\\) 28 FAIL: gcc.target/sh/pr64661-2.c scan-assembler-times @\\(8,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(16,r[0-9]\\) 44 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,gbr\\) 28 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(4,r[0-9]\\) 36 FAIL: gcc.target/sh/pr64661-3.c scan-assembler-times @\\(8,gbr\\) 28 FAIL: gcc.target/sh/pr64
[Bug c++/67550] [5/6 regression] Initialization of local struct array with elements of global array yields zeros instead of initializer values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67550 Markus Trippelsdorf changed: What|Removed |Added Keywords||wrong-code CC||jason at gcc dot gnu.org Summary|Initialization of local |[5/6 regression] |struct array with elements |Initialization of local |of global array yields |struct array with elements |zeros instead of|of global array yields |initializer values |zeros instead of ||initializer values --- Comment #2 from Markus Trippelsdorf --- Started with r217814.
[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 --- Comment #21 from baoshan --- (In reply to Manuel López-Ibáñez from comment #20) > (In reply to baoshan from comment #19) > > We can see the value of up_sub is represented as unsigned int value > > 4294967291 which is really weird to me, it suppose to be a int value -5 > > here. > > All counters are unsigned. You can see what code looks like to GCC at > exactly that moment by using -fdump-tree-all-all-lineno and looking for that > line in test.c.079t.vrp1. > > ;; basic block 10, loop depth 1, count 0, freq 1430, maybe hot > ;; Invalid sum of incoming frequencies 1226, should be 1430 > ;;prev block 9, next block 11, flags: (NEW, REACHABLE) > ;;pred: 9 [85.7%] (TRUE_VALUE,EXECUTABLE) > ;; starting at line 9 > [test.c:9:13] # RANGE [4294967291, 4294967295] > _51 = i_2 + 4294967290; > [test.c:9:10] # RANGE [4294967291, 4294967295] NONZERO 4294967295 > _52 = (long unsigned intD.10) _51; > [test.c:9:10] # RANGE [17179869164, 17179869180] NONZERO 17179869180 > _53 = _52 * 4; > [test.c:9:10] # PT = nonlocal > _54 = bar_12(D) + _53; > [test.c:9:23] # VUSE <.MEM_48> > _55 = [test.c:9:23] bazD.1755[_51]; > [test.c:9:18] # .MEM_56 = VDEF <.MEM_48> > [test.c:9:10] *_54 = _55; > [test.c:9:13] # RANGE [4294967290, 4294967294] > _59 = i_2 + 4294967289; > [test.c:9:10] # RANGE [4294967290, 4294967294] NONZERO 4294967295 > _60 = (long unsigned intD.10) _59; > [test.c:9:10] # RANGE [17179869160, 17179869176] NONZERO 17179869180 > _61 = _60 * 4; > [test.c:9:10] # PT = nonlocal > _62 = bar_12(D) + _61; > [test.c:9:23] # VUSE <.MEM_56> > _63 = [test.c:9:23] bazD.1755[_59]; > [test.c:9:18] # .MEM_64 = VDEF <.MEM_56> > [test.c:9:10] *_62 = _63; > ;;succ: 11 [100.0%] (FALLTHRU,EXECUTABLE) > > It seems GCC at some moment unrolls the loop and creates such block with > those ranges. Probably, the block is unreachable, but it would be better to > not create it in the first place. Finding out where and why it is created > would help to figure out a fix. Don't you think the range value is strange? how it is possible the range value is so big according the code?
[Bug lto/67548] [5/6 Regression] LTO drops weak binding with "ld -r"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548
--- Comment #3 from H.J. Lu ---
We have
enum ld_plugin_symbol_resolution
{
LDPR_UNKNOWN = 0,
/* Symbol is still undefined at this point. */
LDPR_UNDEF,
/* This is the prevailing definition of the symbol, with references from
regular object code. */
LDPR_PREVAILING_DEF,
/* This is the prevailing definition of the symbol, with no
references from regular objects. It is only referenced from IR
code. */
LDPR_PREVAILING_DEF_IRONLY,
/* This definition was pre-empted by a definition in a regular
object file. */
LDPR_PREEMPTED_REG,
/* This definition was pre-empted by a definition in another IR file. */
LDPR_PREEMPTED_IR,
/* This symbol was resolved by a definition in another IR file. */
LDPR_RESOLVED_IR,
/* This symbol was resolved by a definition in a regular object
linked into the main executable. */
LDPR_RESOLVED_EXEC,
/* This symbol was resolved by a definition in a shared object. */
LDPR_RESOLVED_DYN,
/* This is the prevailing definition of the symbol, with no
references from regular objects. It is only referenced from IR
code, but the symbol is exported and may be referenced from
a dynamic object (not seen at link time). */
LDPR_PREVAILING_DEF_IRONLY_EXP
};
None of them is applicable to a weakdef with "ld -r".
[Bug middle-end/67553] New: Saturating SSE/AVX instructions do not get optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67553 Bug ID: 67553 Summary: Saturating SSE/AVX instructions do not get optimized Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: tmb99 at gmx dot net Target Milestone: --- Compiling this code with -O3 -mavx __m128i v0 = _mm_setzero_si128(); __m128i v2 = _mm_setzero_si128(); __m128i sum = _mm_adds_epi16(v0,v2); __m128i dif = _mm_subs_epi16(v0,v2); results in the following badly optimized assembly code: vpxor %xmm0, %xmm0, %xmm0 vpsubsw %xmm0, %xmm0, %xmm1 vpaddsw %xmm0, %xmm0, %xmm0 IMHO the adds and subs instructions should be eliminated by the optimizer
[Bug lto/67548] [5/6 Regression] LTO drops weak binding with "ld -r"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67548 --- Comment #4 from H.J. Lu --- It is wrong to clear DECL_WEAK: DECL_WEAK (next->decl) = false;
[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 --- Comment #22 from Manuel López-Ibáñez --- (In reply to baoshan from comment #21) > Don't you think the range value is strange? how it is possible the range > value is so big according the code? j = i - 1 is actually j = i + 4294967295 because of unsigned. Thus the problematic ranges: [test.c:9:13] # RANGE [4294967291, 4294967295] _51 = i_2 + 4294967290; are actually: [test.c:9:13] # RANGE [-5, -1] _51 = i_2 - 6; but this code should have not been generated. Those ranges do seem suspicious. Finding out how that block ends up with those ranges would be helpful. You probably need to debug vrp or (using -fopt-info) the point where gcc gives: test.c:7:3: note: loop turned into non-loop; it never loops. test.c:7:3: note: loop with 5 iterations completely unrolled
[Bug rtl-optimization/67553] Saturating SSE/AVX instructions do not get optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67553 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-11 Component|middle-end |rtl-optimization Ever confirmed|0 |1 --- Comment #1 from Marc Glisse --- Looks like SS_PLUS and SS_MINUS are missing in the constant folding code...
[Bug libstdc++/67554] New: runtime error in valarray (NULL passed to memcpy)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67554
Bug ID: 67554
Summary: runtime error in valarray (NULL passed to memcpy)
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 36325
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36325&action=edit
Preprocessed source code
# /usr/local/products/gcc/5.2.0/bin/g++ -fsanitize=undefined -D_GLIBCXX_DEBUG
-std=gnu++11 -Wall -Wl,-rpath,/usr/local/products/gcc/5.2.0/lib64 va.C
# ./a.out
/usr/local/products/gcc/5.2.0/include/c++/5.2.0/bits/valarray_array.h:261:9:
runtime error: null pointer passed as argument 1, which is declared to never be
null
/usr/local/products/gcc/5.2.0/include/c++/5.2.0/bits/valarray_array.h:261:9:
runtime error: null pointer passed as argument 2, which is declared to never be
null
-
#include
#include
int
main ()
{
std::array,3> foo;
std::fill(foo.begin(), foo.end(), std::valarray());
return 0;
}
-
[Bug other/67552] [meta] x86 interrupt attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67552
--- Comment #3 from H.J. Lu ---
X87 instructions should be disallowed in interrupt handler:
[hjl@gnu-6 interrupt-1]$ cat f.i
extern long double y, x;
void
__attribute__((interrupt))
fn1 (void)
{
x += y;
}
[hjl@gnu-6 interrupt-1]$ make f.s
/export/build/gnu/gcc-5/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-5/build-x86_64-linux/gcc/ -O2 -S -o f.s f.i
[hjl@gnu-6 interrupt-1]$ cat f.s
.file "f.i"
.section.text.unlikely,"ax",@progbits
.LCOLDB1:
.text
.LHOTB1:
.p2align 4,,15
.globl fn1
.type fn1, @function
fn1:
.LFB0:
.cfi_startproc
fldty(%rip)
addq$-128, %rsp
fldtx(%rip)
faddp %st, %st(1)
fstpt x(%rip)
ret
.cfi_endproc
.LFE0:
.size fn1, .-fn1
.section.text.unlikely
.LCOLDE1:
.text
.LHOTE1:
.ident "GCC: (GNU) 5.2.1 20150911"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 interrupt-1]$
[Bug other/67552] [meta] x86 interrupt attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67552
--- Comment #4 from H.J. Lu ---
MMX instructions should be disallowed in interrupt handler:
[hjl@gnu-6 interrupt-1]$ cat m.i
typedef short __v4hi __attribute__ ((__vector_size__ (8)));
typedef int __m64 __attribute__ ((__vector_size__ (8), __may_alias__));
extern __m64 y, x;
void
__attribute__((interrupt))
fn1 (void)
{
x = (__m64) __builtin_ia32_packsswb ((__v4hi) x, (__v4hi) y);
}
[hjl@gnu-6 interrupt-1]$ make m.s
/export/build/gnu/gcc-5/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-5/build-x86_64-linux/gcc/ -O2 -S -o m.s m.i
[hjl@gnu-6 interrupt-1]$ cat m.s
.file "m.i"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl fn1
.type fn1, @function
fn1:
.LFB0:
.cfi_startproc
movqx(%rip), %mm0
addq$-128, %rsp
packsswby(%rip), %mm0
movq%mm0, x(%rip)
ret
.cfi_endproc
.LFE0:
.size fn1, .-fn1
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.ident "GCC: (GNU) 5.2.1 20150911"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 interrupt-1]$
[Bug debug/67192] Backward-goto in loop can get wrong line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67192 --- Comment #11 from Andreas Arnez --- Any news here? AFAIK the problem still exists.
[Bug c++/67555] New: Emplacement of random numbers in vector displaces other variables (loop counter)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67555 Bug ID: 67555 Summary: Emplacement of random numbers in vector displaces other variables (loop counter) Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: my.pvt.emailaddress at gmail dot com Target Milestone: --- A template function receives a lambda as parameter. This lambda creates random numbers and is used to emplace these random variables in a vector in a loop. The loop counter (int) changes suddenly after the second loop, not incrementing to 2 like expeced but to 282475250, returning after two iterations. The error does not appear when I emplace 0.0 (uncommented below). Minimal example as preprocessed file below. Preprocessed file in attachment Output of 'LANG="en_US.utf8" g++ --std=c++14 -Wall -Wextra -v -save-temps bug.cc': Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/5.2.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: /build/gcc/src/gcc-5.2.0/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release --with-default-libstdcxx-abi=gcc4-compatible Thread model: posix gcc version 5.2.0 (GCC) COLLECT_GCC_OPTIONS='-std=c++14' '-Wall' '-Wextra' '-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' /usr/lib/gcc/i686-pc-linux-gnu/5.2.0/cc1plus -E -quiet -v -D_GNU_SOURCE bug.cc -mtune=generic -march=pentiumpro -std=c++14 -Wall -Wextra -fpch-preprocess -o bug.ii ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/5.2.0/../../../../i686-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/i686-pc-linux-gnu/5.2.0/../../../../include/c++/5.2.0 /usr/lib/gcc/i686-pc-linux-gnu/5.2.0/../../../../include/c++/5.2.0/i686-pc-linux-gnu /usr/lib/gcc/i686-pc-linux-gnu/5.2.0/../../../../include/c++/5.2.0/backward /usr/lib/gcc/i686-pc-linux-gnu/5.2.0/include /usr/local/include /usr/lib/gcc/i686-pc-linux-gnu/5.2.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-std=c++14' '-Wall' '-Wextra' '-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' /usr/lib/gcc/i686-pc-linux-gnu/5.2.0/cc1plus -fpreprocessed bug.ii -quiet -dumpbase bug.cc -mtune=generic -march=pentiumpro -auxbase bug -Wall -Wextra -std=c++14 -version -o bug.s GNU C++14 (GCC) version 5.2.0 (i686-pc-linux-gnu) compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version 3.1.3-p4, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++14 (GCC) version 5.2.0 (i686-pc-linux-gnu) compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version 3.1.3-p4, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 96ebd866b991a3692b342321700b9e9b COLLECT_GCC_OPTIONS='-std=c++14' '-Wall' '-Wextra' '-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' as -v --32 -o bug.o bug.s GNU assembler version 2.25.1 (i686-pc-linux-gnu) using BFD version (GNU Binutils) 2.25.1 COMPILER_PATH=/usr/lib/gcc/i686-pc-linux-gnu/5.2.0/:/usr/lib/gcc/i686-pc-linux-gnu/5.2.0/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/5.2.0/:/usr/lib/gcc/i686-pc-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/i686-pc-linux-gnu/5.2.0/:/usr/lib/gcc/i686-pc-linux-gnu/5.2.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-std=c++14' '-Wall' '-Wextra' '-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' /usr/lib/gcc/i686-pc-linux-gnu/5.2.0/collect2 -plugin /usr/lib/gcc/i686-pc-linux-gnu/5.2.0/liblto_plugin.so -plugin-opt=/usr/lib/gcc/i686-pc-linux-gnu/5.2.0/lto-wrapper -plugin-opt=-fresolution=bug.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id --eh-frame-hdr --hash-style=gnu -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/gcc/i686-pc-linux-gnu/5.2.0/../../../crt1.o /usr/lib/gcc/i686-pc-linux-gnu/5.2.0/../../../crti.o /usr/lib/gcc/i686-pc-linux-gnu/5.2.0/crtbegin.o -L/usr/lib/gcc/i686-pc-linux-gnu/5.2.0 -L/usr/lib/gcc/i686-pc-linux-gnu/5.2.0/../../.. bug.o -lstdc++ -lm -lgcc_s -lgcc -lc
[Bug c++/67555] Emplacement of random numbers in vector displaces other variables (loop counter)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67555 --- Comment #1 from Claudio Ebel --- Created attachment 36326 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36326&action=edit Unprocessed source file / minimal test case (30 lines) Preprocessed sourcefile was too big for bugzilla and pastebin.
[Bug rtl-optimization/67553] Saturating SSE/AVX instructions do not get optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67553 --- Comment #2 from tmb99 at gmx dot net --- seems to be the same for most saturating instructions: __m128i v0 = _mm_setzero_si128(); __m128i v2 = _mm_setzero_si128(); __m128i sum = _mm_adds_epi16(v0,v2); __m128i dif = _mm_subs_epi8(v0,v2); __m128i hsum = _mm_hadds_epi16(v0,v2); __m128i hdif = _mm_hsubs_epi16(v0,v2); __m128i pacu = _mm_packus_epi16(v0,v2); __m128i pacs = _mm_packs_epi32(v0,v2); compiles to: vpxor %xmm0, %xmm0, %xmm0 vpxor %xmm2, %xmm2, %xmm2 vphsubsw%xmm0, %xmm0, %xmm4 vpackuswb %xmm0, %xmm0, %xmm3 vphaddsw%xmm0, %xmm0, %xmm5 vpsubsb %xmm2, %xmm2, %xmm2 vpxor %xmm1, %xmm1, %xmm1 vpaddsw %xmm0, %xmm0, %xmm0 vpackssdw %xmm1, %xmm1, %xmm1 also: 3 setzero/vpxor instructions instead of just one.
[Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #34 from Sebastian Pop ---
r227567 extends the limits of a scop, and now we can detect a scop in the
MAIN__ function corresponding to the following code:
A=0.1D0
B=0.1D0
-fdump-tree-graphite-all shows that the loops have been tiled:
tiled by 51
tiled by 51
ISL AST generated by ISL:
{
for (int c1 = 0; c1 <= 1023; c1 += 51)
for (int c2 = 0; c2 <= 1023; c2 += 51)
for (int c3 = c1; c3 <= min(1023, c1 + 50); c3 += 1)
for (int c4 = c2; c4 <= min(1023, c2 + 50); c4 += 1)
S_4(c3, c4);
for (int c1 = 0; c1 <= 1023; c1 += 51)
for (int c2 = 0; c2 <= 1023; c2 += 51)
for (int c3 = c1; c3 <= min(1023, c1 + 50); c3 += 1)
for (int c4 = c2; c4 <= min(1023, c2 + 50); c4 += 1)
S_10(c3, c4);
}
What makes me wondering is why for memset kind of loops when tiling gets us a
better performance as reported:
before:
17.8480003
after:
15.847
Btw, what architecture have you used for this experiment?
The same happens on an AArch64 machine where I was able to reproduce your
results: the loop blocked initialization of arrays is consistently faster by
about 10%.
I noted that on a recent Intel x86_64 machine the first runs show some 10%
speedup with loop blocking and then the speedup disappears in subsequent runs
(I was alternating runs with and without loop block 10 times).
[Bug fortran/66640] Symbolic (addr2line) backtrace handler sometimes does not terminate when using OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66640 --- Comment #2 from Lorenz Hüdepohl --- (In reply to Dominique d'Humieres from comment #1) > I cannot reproduce this PR on darwin (no addr2line). > > Could you check that this has not been fixed on a recent version of trunk > (6.0): post r227503? Indeed, it does seem fixed. The example always terminates now.
[Bug tree-optimization/47679] [4.9/5/6 Regression] Strange uninitialized warning after SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47679 --- Comment #22 from Jeffrey A. Law --- Author: law Date: Fri Sep 11 21:32:38 2015 New Revision: 227697 URL: https://gcc.gnu.org/viewcvs?rev=227697&root=gcc&view=rev Log: [PATCH] Another small cleanup to the const_and_copies stack 2015-09-11 Jeff Law PR tree-optimization/47679 * tree-ssa-dom.c (struct cond_equivalence): Update comment. * tree-ssa-scopedtables.h (class const_and_copies): Prefix data member with m_. Update inline member functions as necessary. Add toplevel comment. * tree-ssa-scopedtables.c: Update const_and_copies's member functions to use m_ prefix to access the stack. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-dom.c trunk/gcc/tree-ssa-scopedtables.c trunk/gcc/tree-ssa-scopedtables.h
[Bug middle-end/17308] nonnull attribute not as useful as it could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #11 from Mark Wielaard ---
(In reply to Eric Blake from comment #8)
> In other words, with a header like:
>
> void foo(void *bar) __attribute__((nonnull(1)));
>
> and a C file like:
>
> void foo(void *bar) { if (!bar) abort(); }
>
> Even if you decide that you are unable to warn about a call to foo(var)
> because the only way to analyze that var might be NULL is in the middle end
> but the warning is only emitted by the front end, AT LEAST you could have
> warned that the 'if (!bar)' conditional is assumed to be dead code based on
> the attribute placed on var.
This part has now been implemented:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00626.html
[Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741 --- Comment #35 from Dominique d'Humieres --- I get [Book15] f90/bug% /opt/gcc/gcc6p-227264p1/bin/gfortran -Ofast pr14741.f90 -floop-interchange -march=native -Wa,-q [Book15] f90/bug% time a.out 0.48728300210.2399826 0.491u 0.006s 0:00.50 98.0% 0+0k 0+0io 0pf+0w [Book15] f90/bug% /opt/gcc/gcc6p-227383p1/bin/gfortran -Ofast pr14741.f90 -floop-interchange -march=native -Wa,-q [Book15] f90/bug% time a.out 1.4271590110.2399826 1.430u 0.008s 0:01.44 99.3% 0+0k 0+0io 0pf+0w i.e., r227264 (or 4.8, 4.9, and 5.2) is ~3 time faster than r227383.
[Bug c/28901] -Wunused-variable ignores unused const initialised variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901 --- Comment #8 from Mark Wielaard --- Submitted a patch: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00847.html
[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 Rainer Emrich changed: What|Removed |Added CC||rai...@emrich-ebersheim.de --- Comment #19 from Rainer Emrich --- *** Bug 67546 has been marked as a duplicate of this bug. ***
[Bug bootstrap/67546] bootstrap broken on x86_64-w64-mingw32, error: '::unsetenv' has not been declared in gcc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67546 Rainer Emrich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Rainer Emrich --- I think it's really a duplicate of 67363. *** This bug has been marked as a duplicate of bug 67363 ***
[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 --- Comment #20 from Rainer Emrich --- (In reply to İsmail Dönmez from comment #18) > (In reply to John David Anglin from comment #17) > > Fixed on hppa*-*-hpux*. > > Also fixes mingw-w64, thank you! Confirmed, bootstraps on native x84_64-w64-mingw32 again.
[Bug c/67556] New: Regex \w doesn't support the unicode character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67556 Bug ID: 67556 Summary: Regex \w doesn't support the unicode character Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mm.masaeli at gmail dot com Target Milestone: --- The Unicode character 200C is called "nimfaseleh" in Persian language and it is important to deal with it as a regular character. The trick is, it never comes in the beginning or ending of a word. For example in a word like the following, it is crucial: میبینم
[Bug c/67556] Regex \w doesn't support the unicode character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67556 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #1 from Andrew Pinski --- The regex interface is not part of gcc unless you are talking about the one in libstdc++. Also no testcase. J
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #98 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #97)
> I've compared the results of r227512 without LRA and r227682 with LRA.
> Below are the new failures.
A typical example of pr64661-x.c regressions is:
[LRA]
test_37_1:
stc gbr,r3 ! 22store_gbr [length = 2]
mova1f,r0 ! 6 atomic_add_fetchqi_soft_tcb [length = 20]
mov #(0f-1f),r1
.align 2
mov.l r0,@(128,gbr)
0: mov.b @(4,r3),r0
...
[no-LRA]
test_37_1:
mova1f,r0 ! 6 atomic_add_fetchqi_soft_tcb [length = 20]
mov #(0f-1f),r1
.align 2
mov.l r0,@(128,gbr)
0: mov.b @(4,gbr),r0
...
where
(define_insn_and_split "atomic_fetch__soft_tcb"
[(set (match_operand:QIHISI 0 "arith_reg_dest" "=&r")
(match_operand:QIHISI 1 "atomic_mem_operand_1" "=SraSdd"))
...
(clobber (reg:SI R0_REG))
(clobber (reg:SI R1_REG))]
"TARGET_ATOMIC_SOFT_TCB"
{
return "\rmova1f,r0" "\n"
" .align 2" "\n"
" mov #(0f-1f),r1""\n"
" mov.l r0,@(%O3,gbr)" "\n"
"0:mov. %1,r0" "\n"
...
The .ira dump shows
(insn 6 5 7 2 (parallel [
(set (reg:QI 167)
(plus:QI (mem/v:QI (plus:SI (reg:SI 144 gbr)
(const_int 4 [0x4])) [-1 S1 A8])
(const_int 1 [0x1])))
(set (mem/v:QI (plus:SI (reg:SI 144 gbr)
(const_int 4 [0x4])) [-1 S1 A8])
(unspec:QI [
(plus:QI (mem/v:QI (plus:SI (reg:SI 144 gbr)
(const_int 4 [0x4])) [-1 S1 A8])
(const_int 1 [0x1]))
] UNSPEC_ATOMIC))
...
which looks the code generated with the old RA. It seems that
old RA passes gbr+4 addressing as is but LRA spills gbr with r3
according to the constraint SraSdd. Perhaps LRA is more strict
in this regard.
I guess that these pr64661-x.c regressions are not so problem, though.
I'm not sure whether hiconst.c regression is serious or not.
The serious one would be
Running target sh-sim/-m2/-mb
FAIL: gcc.c-torture/execute/20040709-2.c -Os execution test
My sh4-unknown-linux-gnu test also shows another execution
errors for libstdc++-v3.
New tests that FAIL:
22_locale/money_get/get/wchar_t/14.cc execution test
22_locale/money_get/get/wchar_t/19.cc execution test
22_locale/money_get/get/wchar_t/22131.cc execution test
22_locale/money_get/get/wchar_t/38399.cc execution test
22_locale/money_get/get/wchar_t/39168.cc execution test
22_locale/money_get/get/wchar_t/6.cc execution test
22_locale/money_get/get/wchar_t/8.cc execution test
22_locale/money_get/get/wchar_t/9.cc execution test
22_locale/money_put/put/wchar_t/39168.cc execution test
22_locale/money_put/put/wchar_t/5.cc execution test
22_locale/money_put/put/wchar_t/6.cc execution test
These tests compiled with -mlra don't fail with libstdc++-v3
library compiled with -mno-lra, i.e. libstdc++-v3 is miscompiled
with -mlra. These wrong code problems should be resolved before
witch to LRA.
[Bug c++/67555] Emplacement of random numbers in vector displaces other variables (loop counter)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67555 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely --- You return a lambda that has references to local variables. When you invoke the lambda it accesses variables that are out of scope.
[Bug libfortran/67365] Spurious address printed in backtrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67365 --- Comment #3 from Ian Lance Taylor --- The missing address is part of the signal handling code. It's the code that returns to normal execution after the signal handler completes, by calling the rt_sigreturn system call. The backtrace code routinely decrements the return address by 1, so that it can report the file/line of the function call rather than the line that follows the call. In this case, decrementing by 1 gives it an address 1 byte before _restore_rt. It can't find any file/line information for that one byte, so you get a ???. This code is very processor-specific. GCC's internal unwind library knows that we are looking at a signal handler return, but it doesn't expose the information in any way that I can see (the _Unwind_IsSignalFrame function returns true for the function in which the signal occurred, which is the frame above the frame we are talking about). I think the best fix is going to be to add a new flag to _Unwind_Context: SIGRETURN_BIT or something, to indicate that the current context is a signal handler frame. Then we can add an _Unwind_IsSigreturn function so that the unwind code can check that bit. Then libbacktrace can return something like as gdb does. (gdb currently uses processor-specific code for this.)
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #99 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #98) > I guess that these pr64661-x.c regressions are not so problem, though. I agree. > I'm not sure whether hiconst.c regression is serious or not. I think we can ignore this for now. It's about loading/sharing constants. There are more constant related inefficiencies which can be addressed later. > The serious one would be > > Running target sh-sim/-m2/-mb > FAIL: gcc.c-torture/execute/20040709-2.c -Os execution test I will have a look at it. > My sh4-unknown-linux-gnu test also shows another execution > errors for libstdc++-v3. > > New tests that FAIL: > > 22_locale/money_get/get/wchar_t/14.cc execution test > 22_locale/money_get/get/wchar_t/19.cc execution test > 22_locale/money_get/get/wchar_t/22131.cc execution test > 22_locale/money_get/get/wchar_t/38399.cc execution test > 22_locale/money_get/get/wchar_t/39168.cc execution test > 22_locale/money_get/get/wchar_t/6.cc execution test > 22_locale/money_get/get/wchar_t/8.cc execution test > 22_locale/money_get/get/wchar_t/9.cc execution test > 22_locale/money_put/put/wchar_t/39168.cc execution test > 22_locale/money_put/put/wchar_t/5.cc execution test > 22_locale/money_put/put/wchar_t/6.cc execution test > > These tests compiled with -mlra don't fail with libstdc++-v3 > library compiled with -mno-lra, i.e. libstdc++-v3 is miscompiled > with -mlra. These wrong code problems should be resolved before > witch to LRA. Hm .. those don't fail on sh-elf ... maybe something related to the atomics? Atomics are off by default for sh-elf, but on for sh-linux.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #100 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #99) > Hm .. those don't fail on sh-elf ... maybe something related to the atomics? > Atomics are off by default for sh-elf, but on for sh-linux. Maybe. It could be something atomic related. For 14.cc case, replacing locale.o and cxx11-shim_facets.o with ones from non-LRA build fixes the failure. For example, std::locale::locale(std::locale const&) is compiled very differently in LRA/non-LRA builds. Strangely, the problem can't be reproduced with recompiling these objects with -mlra in non-LRA builds. The above constructor is compiled to [LRA build] 0: c6 2f mov.l r12,@-r15 2: 0b c7 mova30 <_ZNSt6localeC1ERKS_+0x30>,r0 4: 0a dc mov.l 30 <_ZNSt6localeC1ERKS_+0x30>,r12 ! 0 <_ZNSt6localeC1ERKS_> 6: 0c 3c add r0,r12 8: 52 62 mov.l @r5,r2 a: 0a d0 mov.l 34 <_ZNSt6localeC1ERKS_+0x34>,r0! 0 <_ZNSt6localeC1ERKS_> c: ce 01 mov.l @(r0,r12),r1 e: 18 21 tst r1,r1 10: 09 8d bt.s26 <_ZNSt6localeC1ERKS_+0x26> 12: 22 24 mov.l r2,@r4 14: 02 c7 mova20 <_ZNSt6localeC1ERKS_+0x20>,r0 16: f3 61 mov r15,r1 18: fa ef mov #-6,r15 1a: 22 63 mov.l @r2,r3 1c: 01 73 add #1,r3 1e: 32 22 mov.l r3,@r2 20: 13 6f mov r1,r15 22: 0b 00 rts 24: f6 6c mov.l @r15+,r12 26: 22 61 mov.l @r2,r1 28: 01 71 add #1,r1 2a: 12 22 mov.l r1,@r2 2c: 0b 00 rts 2e: f6 6c mov.l @r15+,r12 ... 30: R_SH_GOTPC _GLOBAL_OFFSET_TABLE_ 34: R_SH_GOT32 __pthread_key_create [non-LRA build] 0: c6 2f mov.l r12,@-r15 2: 0b c7 mova30 <_ZNSt6localeC1ERKS_+0x30>,r0 4: 0a dc mov.l 30 <_ZNSt6localeC1ERKS_+0x30>,r12 ! 0 <_ZNSt6localeC1ERKS_> 6: 22 4f sts.l pr,@-r15 8: 0c 3c add r0,r12 a: 52 61 mov.l @r5,r1 c: 09 d0 mov.l 34 <_ZNSt6localeC1ERKS_+0x34>,r0! 0 <_ZNSt6localeC1ERKS_> e: ce 02 mov.l @(r0,r12),r2 10: 28 22 tst r2,r2 12: 07 8d bt.s24 <_ZNSt6localeC1ERKS_+0x24> 14: 12 24 mov.l r1,@r4 16: 13 64 mov r1,r4 18: 07 d1 mov.l 38 <_ZNSt6localeC1ERKS_+0x38>,r1! 1a 1a: 03 01 bsrfr1 1c: 01 e5 mov #1,r5 1e: 26 4f lds.l @r15+,pr 20: 0b 00 rts 22: f6 6c mov.l @r15+,r12 24: 12 62 mov.l @r1,r2 26: 01 72 add #1,r2 28: 22 21 mov.l r2,@r1 2a: 26 4f lds.l @r15+,pr 2c: 0b 00 rts 2e: f6 6c mov.l @r15+,r12 ... 30: R_SH_GOTPC _GLOBAL_OFFSET_TABLE_ 34: R_SH_GOT32 __pthread_key_create 38: 1a 00 sts macl,r0 38: R_SH_PLT32 _ZN9__gnu_cxx12__atomic_addEPVii ... Perhaps the both codes are ok, though something odd happens on atomic things anyway.
