[Bug libfortran/71123] Namelist read failure on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71123 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-05-17 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Marked as assigned.
[Bug fortran/70959] [6/7 Regression] Invalid type determination due to expression in a type declaration statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70959 --- Comment #6 from Dominique d'Humieres --- > 1. Maybe the placement of the warning is spurious, but is there any chance it > is actually assigning the type REAL(4) to e18? I don't think so as shown by the results 370370367037037013703703670370370137037036296732672 37037036703703704 of the following test: integer(8), parameter :: e1 = 3 * 12345678901234567_8 integer(8) :: e2, e3, e4 real(4) :: a real(8) :: b e2 = (e1) a = e1 b = e1 e3 = a e4 = b print *, e1, e2, e3, e4 end
[Bug lto/71089] [7 Regression] Failed to build 483.xalancbmk in SPEC CPU 2006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71089 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #3 from Markus Trippelsdorf --- Also happens when building Firefox with -flto: trippels@gcc2-power8 gecko-dev % cat out | grep "nternal compi" lto1: internal compiler error: in lto_output_node, at lto-cgraph.c:473 lto1: internal compiler error: Segmentation fault lto1: internal compiler error: Segmentation fault lto1: internal compiler error: in lto_output_node, at lto-cgraph.c:473 lto1: internal compiler error: Segmentation fault lto1: internal compiler error: in lto_output_node, at lto-cgraph.c:473 lto1: internal compiler error: in lto_output_node, at lto-cgraph.c:473 lto1: internal compiler error: in lto_output_node, at lto-cgraph.c:473 lto1: internal compiler error: Segmentation fault ...
[Bug c/71152] NULL is not cast to (void *) as it ought to be if compiling code with -c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71152
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
I bet you're using ccache, just uninstall it, it is broken by design unless it
starts using -fdirective-only preprocessing, more and more warnings depend on
macro contexts which are lost with separate preprocessing.
On this testcase we do warn with:
./xgcc -B ./ -isystem include/ pr71152.c
pr71152.c: In function ‘NULL_as_int’:
pr71152.c:6:10: warning: return makes integer from pointer without a cast
[-Wint-conversion]
return NULL;
^~~~
and don't with:
./xgcc -B ./ -isystem include/ pr71152.c -save-temps
because NULL macro in that case comes from system header and we get:
int
NULL_as_int ()
{
return
# 6 "pr71152.c" 3 4
((void *)0)
# 6 "pr71152.c"
;
}
in the preprocessed source.
[Bug libgcc/70720] moxie-rtems stanza does not include crti/crtn extra_parts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70720 --- Comment #5 from sh at gcc dot gnu.org --- Author: sh Date: Tue May 17 06:22:28 2016 New Revision: 236309 URL: https://gcc.gnu.org/viewcvs?rev=236309&root=gcc&view=rev Log: [RTEMS] Fix moxie libgcc support libgcc/ PR libgcc/70720 * config.host (moxie-*-rtems*): Merge this stanza with other moxie targets so the same extra_parts are built. Also have tmake_file add on to its value rather than override. Modified: branches/gcc-4_9-branch/libgcc/ChangeLog branches/gcc-4_9-branch/libgcc/config.host
[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114 --- Comment #19 from Dominique d'Humieres --- Results at https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg01774.html.
[Bug libgcc/70720] moxie-rtems stanza does not include crti/crtn extra_parts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70720 --- Comment #4 from sh at gcc dot gnu.org --- Author: sh Date: Tue May 17 06:17:53 2016 New Revision: 236308 URL: https://gcc.gnu.org/viewcvs?rev=236308&root=gcc&view=rev Log: [RTEMS] Fix moxie libgcc support libgcc/ PR libgcc/70720 * config.host (moxie-*-rtems*): Merge this stanza with other moxie targets so the same extra_parts are built. Also have tmake_file add on to its value rather than override. Modified: branches/gcc-5-branch/libgcc/ChangeLog branches/gcc-5-branch/libgcc/config.host
[Bug libgcc/70720] moxie-rtems stanza does not include crti/crtn extra_parts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70720 --- Comment #3 from sh at gcc dot gnu.org --- Author: sh Date: Tue May 17 06:15:52 2016 New Revision: 236307 URL: https://gcc.gnu.org/viewcvs?rev=236307&root=gcc&view=rev Log: [RTEMS] Fix moxie libgcc support libgcc/ PR libgcc/70720 * config.host (moxie-*-rtems*): Merge this stanza with other moxie targets so the same extra_parts are built. Also have tmake_file add on to its value rather than override. Modified: branches/gcc-6-branch/libgcc/ChangeLog branches/gcc-6-branch/libgcc/config.host
[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71135 --- Comment #5 from Yaakov Selkowitz --- Possible patch included in attachment 38505 for bug 71133.
[Bug libstdc++/71133] msp430-elf -mlarge FTBFS in libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71133 --- Comment #1 from Yaakov Selkowitz --- Created attachment 38505 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38505&action=edit Draft patch for 6.1 The results of this test are (so far) used only in the code that will later fail to compile on <32-bit-pointer targets anyway (bug 71135). There's probably a much better way of doing this, but the attached patch seems to be a workaround.
[Bug c/71157] New: -Wnull-dereference false alarm in wrong function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71157 Bug ID: 71157 Summary: -Wnull-dereference false alarm in wrong function Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: eggert at gnu dot org Target Milestone: --- Created attachment 38504 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38504&action=edit preprocessed source code for emacs/lib-src/etags.c I discovered this when compiling bleeding-edge GNU Emacs with GCC 6.1.0 on x86-64. For the attached file e.i, the shell command: gcc -O2 -S -Wnull-dereference e.i issues the diagnostics: e.i: In function 'Forth_words': e.i:9690:10: warning: potential null pointer dereference [-Wnull-dereference] while (*cp != '\0' && !c_isspace (*cp)) ^~~ e.i:9690:10: warning: potential null pointer dereference [-Wnull-dereference] e.i:9690:10: warning: potential null pointer dereference [-Wnull-dereference] I see three things wrong with these diagnostics. First, line 9690 is nowhere near the function Forth_words. Second, I see no path to line 9690 in which its pointer CP can possibly be null. Furthermore, CP is dereferenced only twice in line 9690, so why are there three warnings?
[Bug fortran/70959] [6/7 Regression] Invalid type determination due to expression in a type declaration statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70959 --- Comment #5 from William Clodius --- 1. Maybe the placement of the warning is spurious, but is there any chance it is actually assigning the type REAL(4) to e18? 2. It sounds as if the logic of arith.c is in an incorrect order. What should be done is roughly? Is this a parenthesized expression? If yes is the expression comma deliminated? If yes is it a single comma delimination? If yes is the first part REAL(4)? If yes is the second part REAL(4)? If yes then it is a COMPLEX(8) expression Else the parts are inconsistent in type and might be recognized as an extension Else if no is the first part REAL(8)? If yes then is the second part REAL(8) expression If yes then it is a COMPLEX(16) expression Else the parts are inconsistent in type and might be recognized as an extension Else is the first part another type you want to allow as an extension ... Else is it a multi comma deliminated expression? if yes then a syntax error, unrecognized expression Else it is a scalar expression of the type of the "first" expression 3. By the above if it mistakenly recognizing a complex constant I would expect it to be to a OMPLEX(16) constant. The message reads as if it might be converting the INTEGER(8) to REAL(8) then deciding that it is part of a COMPLEX(8) constant.
[Bug preprocessor/69665] Internal error on #pragma push_macro("__FILE__")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69665 Martin Sebor changed: What|Removed |Added Keywords||ice-on-invalid-code Known to fail||4.9.3, 5.3.0, 6.1.0 --- Comment #2 from Martin Sebor --- I hit Save Changes prematurely. Confirmed with all recent versions of GCC including today's top of trunk (7.0). The test case looks invalid though (programs likely shouldn't be allowed to redefine __FILE__ or other standard predefined macros).
[Bug preprocessor/69665] Internal error on #pragma push_macro("__FILE__")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69665
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-05-17
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||7.0
--- Comment #1 from Martin Sebor ---
$ cat uu.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -c
-Wall -Wextra -Wpedantic uu.c
#pragma push_macro ("__FILE__")
#define __FILE__ "foobar.c"
#pragma pop_macro ("__FILE__")
uu.c:1:33: internal compiler error: invalid hash type 1 in cpp_macro_definition
#pragma push_macro ("__FILE__")
^
0x856ad9 c_cpp_error(cpp_reader*, int, int, rich_location*, char const*,
__va_list_tag (*) [1])
/src/gcc-svn/gcc/c-family/c-common.c:10232
0x18ccc54 cpp_diagnostic
/src/gcc-svn/libcpp/errors.c:61
0x18ccd26 cpp_error(cpp_reader*, int, char const*, ...)
/src/gcc-svn/libcpp/errors.c:76
0x18e716e cpp_macro_definition(cpp_reader*, cpp_hashnode*)
/src/gcc-svn/libcpp/macro.c:3352
0x18c9b4e do_pragma_push_macro
/src/gcc-svn/libcpp/directives.c:1542
0x18c9760 do_pragma
/src/gcc-svn/libcpp/directives.c:1457
0x18c79e4 _cpp_handle_directive
/src/gcc-svn/libcpp/directives.c:510
0x18dab37 _cpp_lex_token
/src/gcc-svn/libcpp/lex.c:2214
0x18e52cf cpp_get_token_1
/src/gcc-svn/libcpp/macro.c:2458
0x18e5719 cpp_get_token_with_location(cpp_reader*, unsigned int*)
/src/gcc-svn/libcpp/macro.c:2644
0x87281a c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
/src/gcc-svn/gcc/c-family/c-lex.c:398
0x7d86ce c_lex_one_token
/src/gcc-svn/gcc/c/c-parser.c:274
0x7d8add c_parser_peek_token
/src/gcc-svn/gcc/c/c-parser.c:455
0x80c026 c_parse_file()
/src/gcc-svn/gcc/c/c-parser.c:17903
0x87e56c c_common_parse_file()
/src/gcc-svn/gcc/c-family/c-opts.c:1064
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71135 --- Comment #4 from Yaakov Selkowitz --- (In reply to Yaakov Selkowitz from comment #3) > It seems that #define _GLIBCXX_USE_WEAK_REF 1 would fix this; the question > is where exactly it should go (config/os/generic/os_defines.h ?) and under > what conditions. Sorry, that should be #define _GLIBCXX_USE_WEAK_REF 0 and (due to --with-newlib) in config/os/newlib/os_defines.h (which is already defined inside an ifdef __CYGWIN__ block).
[Bug fortran/71156] New: PURE interface/definition inconsistency: accepts invalid, rejects valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71156 Bug ID: 71156 Summary: PURE interface/definition inconsistency: accepts invalid, rejects valid Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: damian at sourceryinstitute dot org Target Milestone: --- As shown below, gfortran 6.1.0 rejects the application of the PURE attribute consistently in a procedure interface body and the corresponding procedure definition. Conversely, gfortran accepts the inconsistent approach (not shown) of using PURE in the interface body but omitting PURE from the procedure definition. By contrast, the Cray and Intel compilers behave opposite to gfortran: Intel and Cray accept the consistent syntax below and reject the inconsistent syntax in which PURE appears only in the interface body or only in the definition. If Intel and Cray are correct, then gfortran is accepting invalid code and rejecting the complementary valid code and it would be great if a fix could be applied to the 6 and 7 branches. $ cat consistency.f90 module my_interface implicit none interface pure module subroutine f end subroutine end interface end module submodule(my_interface) my_implementation implicit none contains pure module subroutine f end subroutine end submodule $ gfortran -c consistency.f90 consistency.f90:12:28: pure module subroutine f 1 Error: Duplicate PURE attribute specified at (1) $ gfortran --version GNU Fortran (MacPorts gcc6 6.1.0_0) 6.1.0
[Bug c++/70979] [C++14] g++ falsely accepts constexpr function returning a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70979
--- Comment #4 from Martin Sebor ---
Including the following test case from the duplicate bug 71116 (which is
expected to pass in C+++ 14 and prior):
$ cat uu.cpp && /home/msebor/build/gcc-fortify-source/gcc/xgcc
-B/home/msebor/build/gcc-fortify-source/gcc -S uu.cpp
void oops () {
auto fn = []{ };
static_assert (!__is_literal_type (decltype (fn)), "oops");
}
uu.cpp: In function ‘void oops()’:
uu.cpp:3:3: error: static assertion failed: oops
static_assert (!__is_literal_type (decltype (fn)), "oops");
^
[Bug libstdc++/71108] to_string is relatively slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71108 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez --- (In reply to Adrian Wielgosik from comment #0) > For example, this function is 3-7x faster than 6.1 std::to_string(unsigned > int) in a microbenchmark. https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html
[Bug c++/70979] [C++14] g++ falsely accepts constexpr function returning a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70979 Martin Sebor changed: What|Removed |Added CC||eric.niebler at gmail dot com --- Comment #3 from Martin Sebor --- *** Bug 71116 has been marked as a duplicate of this bug. ***
[Bug c++/71116] Lambdas should not be literal types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71116
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Last reconfirmed||2016-5-16
CC||msebor at gcc dot gnu.org
Resolution|--- |DUPLICATE
Known to fail||4.9.3, 5.3.0, 6.1.0, 7.0
--- Comment #1 from Martin Sebor ---
Confirmed with all supported versions of GCC as well as today's trunk of 7.0.
A slightly simplified test case independent of libstdc++:
$ cat uu.cpp && /home/msebor/build/gcc-fortify-source/gcc/xgcc
-B/home/msebor/build/gcc-fortify-source/gcc -S uu.cpp
void oops () {
auto fn = []{ };
static_assert (!__is_literal_type (decltype (fn)), "oops");
}
uu.cpp: In function ‘void oops()’:
uu.cpp:3:3: error: static assertion failed: oops
static_assert (!__is_literal_type (decltype (fn)), "oops");
^
I think this needs to be fixed in tandem with bug 70979 and so is probably
simplest to treat it as a duplicate.
*** This bug has been marked as a duplicate of bug 70979 ***
[Bug c/71152] NULL is not cast to (void *) as it ought to be if compiling code with -c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71152 --- Comment #4 from Martin Sebor --- Sorry, I didn't finish the sentence: ...please attach the complete preprocessor output on the off change that the NULL macro isn't expanded to (void*)0 for some reason.
[Bug c/71152] NULL is not cast to (void *) as it ought to be if compiling code with -c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71152 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #3 from Martin Sebor --- I'm not able to reproduce this with either 6.1 or the current trunk, or find an older revision that fails to give the warning. I would suggest opening a bug against the Fedora GCC (please att
[Bug middle-end/71155] New: symbol in wrong section .data.rel.local on mips64el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71155 Bug ID: 71155 Summary: symbol in wrong section .data.rel.local on mips64el Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: aurelien at aurel32 dot net Target Milestone: --- Host: mips64el-linux-gnuabi64 Target: mips64el-linux-gnuabi64 Build: mips64el-linux-gnuabi64 Created attachment 38503 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38503&action=edit preprocessed source file When compiling the GNU libc on mips64el-linux-gnuabi64 with GCC >= 4.9, the resulting libc causes lua 5.2 to not work correcty. It happens this is due to wrong the compilation of libio/oldstdfiles.c. When using GCC <= 4.8, the _IO_stdin_ symbol ends up in the data.rel section just like _IO_stdout_ and _IO_stderr_. When using GCC >= 4.9, the _IO_stdin_ symbol is moved to the .data.rel.local section, while the two others are unchanged. This is also reproducible with GCC 5 and GCC 6. The issue seems to have been introduced by the following patch: https://gcc.gnu.org/ml/gcc-patches/2014-01/msg01169.html I have attached the preprocessed source file, the original source file can be found there: https://sourceware.org/git/?p=glibc.git;a=blob;f=libio/oldstdfiles.c;h=609b7d9ef2d78f851a29b3d25efbb03f9c76ca91;hb=HEAD
[Bug target/71153] aarch64 LSE __atomic_fetch_and() generates inversion for constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71153 --- Comment #3 from Andrew Pinski --- The other way of fixing this is to expose the NOT in RTL before register allocator. That is harder but still doable.
[Bug target/71153] aarch64 __atomic_fetch_and() generates probably incorrect double inversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71153
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2016-05-16
CC||pinskia at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #2 from Andrew Pinski ---
LDCLRL does MEM &= ~op.
LDCLR – atomic AND NOT (bitclear) of a location with value in a register, with
original data loaded into a register.
Applies to 8, 16, 32, 64 bits. Each instruction can have one of four possible
orderings - acquire, release,
acquire&release, no order, as it performs both a load and a store.
So the code is correct just not optimal.
Something like this should get the code back to optimal:
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 236c819..ad92f6a 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -11607,6 +11607,7 @@ aarch64_gen_atomic_ldop (enum rtx_code code, rtx
out_data, rtx out_result,
aarch64_atomic_load_op_code ldop_code;
rtx src;
rtx x;
+ bool already_swapped = false;
if (out_data)
out_data = gen_lowpart (mode, out_data);
@@ -11614,6 +11615,12 @@ aarch64_gen_atomic_ldop (enum rtx_code code, rtx
out_data, rtx out_result,
if (out_result)
out_result = gen_lowpart (mode, out_result);
+ if (code == AND && CONST_INT_P (value))
+{
+ value = simplify_gen_unary (NOT, mode, value, mode);
+ already_swapped = true;
+}
+
/* Make sure the value is in a register, putting it into a destination
register if it needs to be manipulated. */
if (!register_operand (value, mode)
@@ -11670,8 +11677,11 @@ aarch64_gen_atomic_ldop (enum rtx_code code, rtx
out_data, rtx out_result,
if (short_mode)
src = gen_lowpart (wmode, src);
- not_src = gen_rtx_NOT (wmode, src);
- emit_insn (gen_rtx_SET (src, not_src));
+ if (!already_swapped)
+ {
+ not_src = gen_rtx_NOT (wmode, src);
+ emit_insn (gen_rtx_SET (src, not_src));
+ }
if (short_mode)
src = gen_lowpart (mode, src);
[Bug c++/71154] Attributes for an explicit template instantiation are ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71154 --- Comment #1 from James Abbatiello --- Created attachment 38502 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38502&action=edit Too simple patch
[Bug c++/71154] New: Attributes for an explicit template instantiation are ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71154
Bug ID: 71154
Summary: Attributes for an explicit template instantiation are
ignored
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: abbeyj+gcc at gmail dot com
Target Milestone: ---
Created attachment 38501
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38501&action=edit
Reproducer
Trying to apply attributes (like visibility("default")) to an explicit template
instantiation does not work if the type has been previously mentioned in the
translation unit.
This was previously reported as part of bug #50044. But that bug was
eventually marked as a duplicate of bug #40068 which only seems to cover the
problem with typeinfo. The part about the problem with attributes seems to
have been lost so I'm opening this bug to cover it.
STR:
==
$ cat main.cpp
template
class C
{
void foo();
};
C g_c_int;
C g_c_double;
template
void C::foo() {}
template class __attribute__((visibility("default"))) C;
template class C;
$ g++ -fvisibility=hidden -fPIC -shared main.cpp -o main.so
main.cpp:13:55: warning: type attributes ignored after type is already defined
[-Wattributes]
template class __attribute__((visibility("default"))) C;
^~
$ nm -C main.so | grep foo
061c t C::foo()
0610 t C::foo()
==
Note that C::foo() is marked as local (lowercase t) when the intent was to
make it global (uppercase). When compiled with clang++ instead there are no
warnings and nm reports:
0510 t C::foo()
0500 W C::foo()
where C::foo() is global as desired.
Similar code, with the __attribute__ replaced with __declspec(dllexport), works
as expected with MSVC 2012. That is, C::foo() is exported from the DLL
and C::foo() is not.
I have a patch for this which I will attach. It just removes the relevant
checks entirely. This seems likely to cause problems elsewhere but perhaps it
gives somebody an idea on where to start.
[Bug target/71153] aarch64 __atomic_fetch_and() generates probably incorrect double inversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71153 --- Comment #1 from dhowells at redhat dot com --- (In reply to dhowe...@redhat.com from comment #0) > ... If nothing else, the MOVN and MOV could be condensed into just a MOV. ... The MOVN and the MVN could be condensed, that is.
[Bug target/71153] New: aarch64 __atomic_fetch_and() generates probably incorrect double inversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71153
Bug ID: 71153
Summary: aarch64 __atomic_fetch_and() generates probably
incorrect double inversion
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
Compiling this code:
static __always_inline
void clear_bit_unlock(long bit, volatile unsigned long *addr)
{
unsigned long mask = 1UL << (bit & (64 - 1));
addr += bit >> 6;
__atomic_fetch_and(addr, ~mask, __ATOMIC_RELEASE);
}
void bar_clear_bit_unlock(unsigned long *p)
{
clear_bit_unlock(22, p);
}
for aarch64-linux-gnu with "-march=armv8-a+lse -Os" generates a double negation
of the mask value in the assembly:
007c :
7c: 92a00801mov x1, #0xffbf // #-4194305
80: aa2103e1mvn x1, x1
84: f8611001ldclrl x1, x1, [x0]
88: d65f03c0ret
The instruction at 7c is loading an inverted value into x1 (it's actually a
MOVN instruction according to the opcode table that I can find); the value in
x1 is then inverted *again* by the MVN instruction.
Now, I can't find a description of how the LDCLRL instruction works, so I can't
say that it doesn't invert the parameter a third time (ie. apply an A AND-NOT B
operation), but it looks suspicious. If nothing else, the MOVN and MOV could
be condensed into just a MOV.
If a parameter is used instead of a constant:
void foo_clear_bit_unlock(long bit, unsigned long *p)
{
clear_bit_unlock(bit, p);
}
then two MVN instructions are generated:
0048 :
48: 12001403and w3, w0, #0x3f
4c: 9346fc02asr x2, x0, #6
50: d2800020mov x0, #0x1// #1
54: 8b020c21add x1, x1, x2, lsl #3
58: 9ac32000lsl x0, x0, x3
5c: aa2003e0mvn x0, x0
60: aa2003e2mvn x2, x0
64: f8621022ldclrl x2, x2, [x1]
68: d65f03c0ret
The C code appears to be correct, because on x86_64 it generates:
004c :
4c: f0 48 81 27 ff ff bflock andq $0xffbf,(%rdi)
53: ff
54: c3 retq
[Bug libstdc++/11196] _GNU_SOURCE vs. M_PI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11196 Jan van Dijk changed: What|Removed |Added CC||j.v.dijk at tue dot nl --- Comment #10 from Jan van Dijk --- Has this been (partly) fixed in the meantime? The OP's test program compiles just fine with: g++ (SUSE Linux) 4.8.3 20140627 [gcc-4_8-branch revision 212064] g++ (SUSE Linux) 5.3.1 20160412 [gcc-5-branch revision 234894] g++ (GCC) 7.0.0 20160516 (experimental) x86_64-w64-mingw32.shared-g++ (GCC) 4.9.3 I also see that GNU_SOURCE is no longer implicitly defined. At least, I do not see that in the output of "g++ -dM -E - < /dev/null" anymore. Are there any remaining issues, or should this report be closed?
[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114 --- Comment #18 from Dominique d'Humieres --- > smoke test passes, I'll leave it to Dominique's full-run to confirm. With the patch in comment 15 applied on top of revision r236286 the reported failures are gone. From the fix, would it be possible to derive a test failing on linux? Also the test gcc.target/i386/pr70799-1.c fails FAIL: gcc.target/i386/pr70799-1.c scan-assembler movdqa[ t]+.LC0 In the assembly I see movdqa LC0-L3$pb(%eax), %xmm0 with nothing between \t and L.
[Bug rtl-optimization/71150] [7 Regression] ICE on valid code at -O1 and above in 64-bit mode on x86_64-linux-gnu in lra_eliminate_reg_if_possible, at lra-eliminations.c:1402
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71150 Jiong Wang changed: What|Removed |Added Target||i386* Status|NEW |ASSIGNED --- Comment #2 from Jiong Wang --- r236181 was assuming SUBREG_REG (x) is a REG, but actually it might be not, at least for i386. A simple new guard of REG_P check can fix this regression. Will explore more to see what's the best fix and propose a patch shortly.
[Bug c/71152] NULL is not cast to (void *) as it ought to be if compiling code with -c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71152 --- Comment #2 from Ray Strode --- this test case works as expected with gcc-5.3.1-6.fc23.x86_64
[Bug c++/71145] Alpha: Error: No lda !gpdisp!278 was found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71145 --- Comment #3 from Michael Cree --- Created attachment 38500 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38500&action=edit compressed preprocessed source Failing preprocessed source compressed with gzip; hopefully this goes through okay.
[Bug c/71152] NULL is not cast to (void *) as it ought to be if compiling code with -c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71152 --- Comment #1 from Ray Strode --- $ rpm -q gcc gcc-6.0.0-0.20.fc25.x86_64
[Bug c/71152] New: NULL is not cast to (void *) as it ought to be if compiling code with -c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71152 Bug ID: 71152 Summary: NULL is not cast to (void *) as it ought to be if compiling code with -c Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rstrode at redhat dot com Target Milestone: --- Created attachment 38499 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38499&action=edit small test case try compiling with -c and without I was refactoring code in a project and moved some code off to a helper function. The helper function returns an integer error code and the main function returns a pointer. When I moved the error handling code over from the main function to the helper function, I neglected to change the return code from NULL to -1. gcc didn't warn about this. So I wrote a quick test case (attached) and discovered something very strange. gcc does warn if you compile and link the code in one step, i.e.: $ gcc nulltest.c nulltest.c: In function ‘NULL_as_int’: nulltest.c:6:12: warning: return makes integer from pointer without a cast [-Wint-conversion] return NULL; ^~~~ $ But if you pass -c to defer linking, the bug manifests: $ gcc nulltest.c -c $
[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71135 --- Comment #3 from Yaakov Selkowitz --- It seems that #define _GLIBCXX_USE_WEAK_REF 1 would fix this; the question is where exactly it should go (config/os/generic/os_defines.h ?) and under what conditions.
[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71135 --- Comment #2 from Yaakov Selkowitz --- (In reply to Jonathan Wakely from comment #1) > I think we just want to disable TM library support for such targets. Okay, h8300-elf and xstormy16-elf are both similarly affected. msp430-elf probably will be as well once configure works again (bug 71133).
[Bug bootstrap/70835] New: internal compiler error on libiberty/floatformat.c when bootstrapping 5.3.0 with 5.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70835
Bug ID: 70835
Summary: internal compiler error on libiberty/floatformat.c
when bootstrapping 5.3.0 with 5.3.0
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: nunya223bidness at streetwisemail dot com
Target Milestone: ---
../gcc-5.3.0/configure --prefix=/usr/local
--with-native-system-header-files=/opt/include:/volume1/mmt/x-tools/x86_64-unknown-linux-gnu/include
--enable-bootstrap --enable-lto --with-{gmp,mpc,mpfr,isl}=/usr/local
--with-gnu-ld --enable-twoprocess --enable-gather-detailed-mem-stats
--enable-multilib --enable-multiarch --enable-decimal-float=yes
--enable-fixed-point --enable-plugin --disable-dependency-tracking
--disable-nls --disable-canonical-system-headers --with-glibc-version=2.20
--without-cuda-driver --enable-languages=c,c++
--with-build-time-tools=/usr/local --with-build-libsubdir=lib CFLAGS="-v
-save-temps" ; make
[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
make[2]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
make[3]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
rm -f stage_current
make[3]: Leaving directory '/volume1/local/src/gcc-5.3.0-build'
make[2]: Leaving directory '/volume1/local/src/gcc-5.3.0-build'
make[2]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
make[3]: Entering directory '/volume1/local/src/gcc-5.3.0-build/libiberty'
if [ x"-fpic" != x ]; then \
gcc -c -DHAVE_CONFIG_H -g -I. -I../../gcc-5.3.0/libiberty/../include -W
-Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -fpic
../../gcc-5.3.0/libiberty/floatformat.c -o pic/floatformat.o; \
else true; fi
GNU MP: Cannot allocate memory (size=4611686018427387859)
../../gcc-5.3.0/libiberty/floatformat.c: In function 'floatformat_to_double':
../../gcc-5.3.0/libiberty/floatformat.c:529:2: internal compiler error: Aborted
dto = ldexp (1.0, exponent);
^
0x9bed4f crash_signal
../../gcc-5.3.0/gcc/toplev.c:383
0x93c390 real_from_mpfr(real_value*, __mpfr_struct const*, tree_node*,
mpfr_rnd_t)
../../gcc-5.3.0/gcc/realmpfr.c:92
0x939b49 real_from_string(real_value*, char const*)
../../gcc-5.3.0/gcc/real.c:2073
0x93a3bc real_from_string3(real_value*, char const*, machine_mode)
../../gcc-5.3.0/gcc/real.c:2123
0x6576a3 interpret_float
../../gcc-5.3.0/gcc/c-family/c-lex.c:897
0x65834c c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
../../gcc-5.3.0/gcc/c-family/c-lex.c:442
0x602fef c_lex_one_token
../../gcc-5.3.0/gcc/c/c-parser.c:258
0x613d1a c_parser_peek_token
../../gcc-5.3.0/gcc/c/c-parser.c:440
0x613d1a c_parser_next_token_is
../../gcc-5.3.0/gcc/c/c-parser.c:452
0x613d1a c_parser_postfix_expression_after_primary
../../gcc-5.3.0/gcc/c/c-parser.c:7865
0x60e067 c_parser_postfix_expression
../../gcc-5.3.0/gcc/c/c-parser.c:7715
0x61031a c_parser_unary_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6602
0x610e8f c_parser_cast_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6440
0x611072 c_parser_binary_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6255
0x611ba5 c_parser_conditional_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6031
0x611ff0 c_parser_expr_no_commas
../../gcc-5.3.0/gcc/c/c-parser.c:5949
0x61206a c_parser_expr_no_commas
../../gcc-5.3.0/gcc/c/c-parser.c:5991
0x6124e2 c_parser_expression
../../gcc-5.3.0/gcc/c/c-parser.c:8022
0x612c99 c_parser_expression_conv
../../gcc-5.3.0/gcc/c/c-parser.c:8055
0x60c096 c_parser_statement_after_labels
../../gcc-5.3.0/gcc/c/c-parser.c:5115
sh-4.3# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/volume1/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.3.0/configure
--with-buildtime-tools=/volume1/mmt/x-tools/x86_64-unknown-linux-gnu/bin
--with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local
--with-isl=/usr/local --disable-multilib
--with-sysroot=/volume1/mmt/x-tools/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/sysroot
--enable-bootstrap --disable-lto
Thread model: posix
gcc version 5.3.0 (GCC)
sh-4.3# uname -s -r -v -m -p -i -o
Linux 3.10.77 #7321 SMP Thu Apr 21 14:35:22 CST 2016 x86_64 unknown unknown
GNU/Linux
[Bug ipa/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71146 --- Comment #6 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71146 > > --- Comment #5 from Marek Polacek --- > And of course I found it (I think) just after posting the previous commit: Ah, thanks. It looks OK to me. I was wondering if it is cleaner to split the BB just to make the outer loop continue where it started or do something smarter. I wonder how we managed to redirect call within thunk to unreachable? Honza
[Bug ipa/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71146 --- Comment #5 from Marek Polacek --- And of course I found it (I think) just after posting the previous commit: --- a/gcc/tree-inline.c +++ b/gcc/tree-inline.c @@ -4486,6 +4486,7 @@ expand_call_inline (basic_block bb, gimple *stmt, copy_body_data *id) update_stmt (stmt); id->src_node->remove (); expand_call_inline (bb, stmt, id); + maybe_remove_unused_call_args (cfun, stmt); return true; } fn = cg_edge->callee->decl;
[Bug target/71151] New: -fmerge-constants and -fdata-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151
Bug ID: 71151
Summary: -fmerge-constants and -fdata-sections results in
string constants in .progmem.gcc_sw section
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: senthil.thecoder at gmail dot com
Target Milestone: ---
Using -fdata-sections causes string literals in functions to go into
.progmem.sw_gcc, instead of .rodata.str. This is incorrect, since code using
them expects data memory addresses, not flash.
$ cat printf.c
extern void bar(const char*);
void foo(void)
{
bar("BB");
}
$ avr-gcc -mmcu=atmega32u2 printf.c -S -Os -fdata-sections -ffunction-sections
$ cat printf.s
jaguar:~/scratch$ cat printf.s
.file "printf.c"
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__SREG__ = 0x3f
__tmp_reg__ = 0
__zero_reg__ = 1
.section.progmem.gcc_sw_table.foo.str1.1,"aMS",@progbits,1
.LC0:
.string "BB"
.section.text.foo,"ax",@progbits
.global foo
.type foo, @function
foo:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
ldi r24,lo8(.LC0)
ldi r25,hi8(.LC0)
jmp bar
.size foo, .-foo
.ident "GCC: (GNU) 6.1.0"
As the testcase shows, the string goes into progmem.gcc_sw_table..*,
and this gets placed in flash by the linker script. Reading from the address in
r25:24 will obviously not give the correct results - it will read from whatever
happens to be mapped at the same address in the data address space.
[Bug ipa/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71146 --- Comment #4 from Marek Polacek --- It would appear that we need to call maybe_remove_unused_call_args somewhere, but so far haven't found the right spot...
[Bug tree-optimization/71149] missing modulo 2 optimization converting result to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71149
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-05-16
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> Most likely the opt needs to be moved from fold-const to match.pd . Should
> be a simple patch.
Yes:
/* If this is an NE or EQ comparison of zero against the result of a
signed MOD operation whose second operand is a power of 2, make
the MOD operation unsigned since it is simpler and equivalent. */
if (integer_zerop (arg1)
&& !TYPE_UNSIGNED (TREE_TYPE (arg0))
&& (TREE_CODE (arg0) == TRUNC_MOD_EXPR
|| TREE_CODE (arg0) == CEIL_MOD_EXPR
|| TREE_CODE (arg0) == FLOOR_MOD_EXPR
|| TREE_CODE (arg0) == ROUND_MOD_EXPR)
&& integer_pow2p (TREE_OPERAND (arg0, 1)))
{
tree newtype = unsigned_type_for (TREE_TYPE (arg0));
tree newmod = fold_build2_loc (loc, TREE_CODE (arg0), newtype,
fold_convert_loc (loc, newtype,
TREE_OPERAND (arg0, 0)),
fold_convert_loc (loc, newtype,
TREE_OPERAND (arg0,
1)));
return fold_build2_loc (loc, code, type, newmod,
fold_convert_loc (loc, newtype, arg1));
}
Something like:
(for mod (ceil_mod floor_mod round_mod trunc_mod)
(for eqne (ne eq)
(simplify (eqne (mod @1 integer_pow2p@2) integer_zerop)
(if (!TYPE_UNSIGNED (TREE_TYPE (@1)))
(
I am lazy to fill in the ... part right now but you get the idea.
[Bug rtl-optimization/71150] [7 Regression] ICE on valid code at -O1 and above in 64-bit mode on x86_64-linux-gnu in lra_eliminate_reg_if_possible, at lra-eliminations.c:1402
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71150 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-16 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |7.0 Summary|ICE on valid code at -O1|[7 Regression] ICE on valid |and above in 64-bit mode on |code at -O1 and above in |x86_64-linux-gnu in |64-bit mode on |lra_eliminate_reg_if_possib |x86_64-linux-gnu in |le, at |lra_eliminate_reg_if_possib |lra-eliminations.c:1402 |le, at ||lra-eliminations.c:1402 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with: commit 4fe01ba94e99e792ebe9da2ccb3b071aa1bac388 Author: jiwang Date: Thu May 12 17:00:52 2016 + [LRA] PR70904, relax the restriction on subreg reload for wide mode 2016-05-12 Jiong Wang gcc/ PR rtl-optimization/70904 * lra-constraint.c (process_addr_reg): Relax the restriction on subreg reload for wide mode. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@236181 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug rtl-optimization/71150] New: ICE on valid code at -O1 and above in 64-bit mode on x86_64-linux-gnu in lra_eliminate_reg_if_possible, at lra-eliminations.c:1402
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71150
Bug ID: 71150
Summary: ICE on valid code at -O1 and above in 64-bit mode on
x86_64-linux-gnu in lra_eliminate_reg_if_possible, at
lra-eliminations.c:1402
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The following code causes an ICE when compiled with the current gcc trunk at
-O1 and above on x86_64-linux-gnu in the 64-bit mode.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160516 (experimental) [trunk revision 236272] (GCC)
$
$ gcc-trunk -O0 -c small.c
$
$ gcc-trunk -O1 -c small.c
small.c: In function ‘fn2’:
small.c:11:1: internal compiler error: in lra_eliminate_reg_if_possible, at
lra-eliminations.c:1402
}
^
0xa5d0fe lra_eliminate_reg_if_possible(rtx_def**)
../../gcc-source-trunk/gcc/lra-eliminations.c:1402
0xa4d9ee in_class_p
../../gcc-source-trunk/gcc/lra-constraints.c:266
0xa51031 process_addr_reg
../../gcc-source-trunk/gcc/lra-constraints.c:1320
0xa54b11 process_address_1
../../gcc-source-trunk/gcc/lra-constraints.c:2983
0xa55ce9 process_address
../../gcc-source-trunk/gcc/lra-constraints.c:3233
0xa55ce9 curr_insn_transform
../../gcc-source-trunk/gcc/lra-constraints.c:3534
0xa5a736 lra_constraints(bool)
../../gcc-source-trunk/gcc/lra-constraints.c:4530
0xa46484 lra(_IO_FILE*)
../../gcc-source-trunk/gcc/lra.c:2290
0x9fd839 do_reload
../../gcc-source-trunk/gcc/ira.c:5381
0x9fd839 execute
../../gcc-source-trunk/gcc/ira.c:5565
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
--
long a;
void fn1 () {}
void
fn2 ()
{
unsigned b = (unsigned long) fn1;
if (a ^ b)
a--;
}
[Bug tree-optimization/71149] missing modulo 2 optimization converting result to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71149 --- Comment #1 from Andrew Pinski --- Most likely the opt needs to be moved from fold-const to match.pd . Should be a simple patch.
[Bug tree-optimization/71149] New: missing modulo 2 optimization converting result to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71149
Bug ID: 71149
Summary: missing modulo 2 optimization converting result to
bool
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
One would expect GCC to emit comparably efficient code for all three functions
below, but it only does so for odd_mod and odd_and but not for the equivalent
odd_mod_cvt function. Clang emits the same optimal code for all three
functions.
$ cat xxx.cpp && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc
-Dbool=_Bool -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout -o/dev/null
-xc xxx.cpp
int odd_mod (int a) {
return (a % 2) != 0;
}
_Bool odd_mod_cvt (int a) {
return a % 2;
}
int odd_and (int a) {
return (a & 1) != 0;
}
;; Function odd_mod (odd_mod, funcdef_no=0, decl_uid=1745, cgraph_uid=0,
symbol_order=0)
odd_mod (int a)
{
int _1;
:
_1 = a_4(D) & 1;
return _1;
}
;; Function odd_mod_cvt (odd_mod_cvt, funcdef_no=1, decl_uid=1748,
cgraph_uid=1, symbol_order=1)
odd_mod_cvt (int a)
{
int _1;
_Bool _3;
:
_1 = a_2(D) % 2;
_3 = _1 != 0;
return _3;
}
;; Function odd_and (odd_and, funcdef_no=2, decl_uid=1751, cgraph_uid=2,
symbol_order=2)
odd_and (int a)
{
int _1;
:
_1 = a_3(D) & 1;
return _1;
}
[Bug hsa/70857] [6/7 Regression] ICE with -fopenmp -fopenacc in insert_vi_for_tree, at tree-ssa-structalias.c:2813
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70857 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Jambor --- Fixed.
[Bug hsa/70857] [6/7 Regression] ICE with -fopenmp -fopenacc in insert_vi_for_tree, at tree-ssa-structalias.c:2813
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70857 --- Comment #6 from Martin Jambor --- Author: jamborm Date: Mon May 16 15:57:06 2016 New Revision: 236292 URL: https://gcc.gnu.org/viewcvs?rev=236292&root=gcc&view=rev Log: [PR 70857] Copy RESULT_DECL of HSA outlined kernel function 2016-05-16 Martin Jambor PR hsa/70857 * omp-low.c (grid_expand_target_grid_body): Copy RESULT_DECL of the outlined kernel function. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/omp-low.c
[Bug c++/71121] Spurious warning: "the address of [...] will never be NULL [-Waddress]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71121 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-16 CC||jason at gcc dot gnu.org, ||msebor at gcc dot gnu.org Known to work||5.3.0 Blocks||55004 Ever confirmed|0 |1 Known to fail||6.1.0 --- Comment #1 from Martin Sebor --- Confirmed with 6.1.0 and today's top of trunk (7.0). Both the auto and the constexpr appear to be necessary to trigger the warning. The regression appears to have been introduced in r234940. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 [Bug 55004] [meta-bug] constexpr issues
[Bug hsa/70857] [6/7 Regression] ICE with -fopenmp -fopenacc in insert_vi_for_tree, at tree-ssa-structalias.c:2813
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70857 --- Comment #5 from Martin Jambor --- Author: jamborm Date: Mon May 16 15:40:30 2016 New Revision: 236291 URL: https://gcc.gnu.org/viewcvs?rev=236291&root=gcc&view=rev Log: [PR 70857] Copy RESULT_DECL of HSA outlined kernel function 2016-05-16 Martin Jambor PR hsa/70857 * omp-low.c (grid_expand_target_grid_body): Copy RESULT_DECL of the outlined kernel function. Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c
[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71135 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-16 Ever confirmed|0 |1
[Bug libstdc++/71133] msp430-elf -mlarge FTBFS in libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71133 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-16 CC||torvald at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71135 Jonathan Wakely changed: What|Removed |Added CC||torvald at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- I think we just want to disable TM library support for such targets.
[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114 --- Comment #17 from Iain Sandoe --- smoke test passes, I'll leave it to Dominique's full-run to confirm.
[Bug driver/68463] Offloading fails when some objects are compiled with LTO and some without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68463 --- Comment #7 from jnorris at gcc dot gnu.org --- Author: jnorris Date: Mon May 16 13:47:47 2016 New Revision: 236287 URL: https://gcc.gnu.org/viewcvs?rev=236287&root=gcc&view=rev Log: Backport from mainline r236098. 2016-05-10 James Norris PR driver/68463 * config/rs6000/sysv4.h (CRTOFFLOADBEGIN): Define. Add crtoffloadbegin.o if offloading is enabled and -fopenacc or -fopenmp is specified. (CRTOFFLOADEND): Likewise. (STARTFILE_LINUX_SPEC): Add CRTOFFLOADBEGIN. (ENDFILE_LINUX_SPEC): Add CRTOFFLOADEND. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/rs6000/sysv4.h
[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114 --- Comment #16 from Ilya Enkovich --- (In reply to Iain Sandoe from comment #15) > that code won't build - did you mean : > Sure. Thanks for noticing!
[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #15 from Iain Sandoe ---
(In reply to Dominique d'Humieres from comment #14)
> > Looks I found the problem. validize_mem generates new instructions which
> > are placed wrongly. This patch should help. Unfortunately I can't test
> > it properly on Darwin.
>
> Thanks for the feedback. I just started a clean regstrap, allow for ~6h+.
that code won't build - did you mean :
if (!standard_sse_constant_p (vec_cst, V2DImode))
- vec_cst = validize_mem (force_const_mem (V2DImode, vec_cst));
+ {
+ start_sequence ();
+ vec_cst = validize_mem (force_const_mem (V2DImode, vec_cst));
+ rtx_insn *seq = get_insns ();
+ end_sequence ();
+ emit_insn_before (seq, insn);
+ }
?
[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114 --- Comment #14 from Dominique d'Humieres --- > Looks I found the problem. validize_mem generates new instructions which > are placed wrongly. This patch should help. Unfortunately I can't test > it properly on Darwin. Thanks for the feedback. I just started a clean regstrap, allow for ~6h+.
[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #13 from Ilya Enkovich ---
Looks I found the problem. validize_mem generates new instructions which are
placed wrongly. This patch should help. Unfortunately I can't test it
properly on Darwin.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 046717b..5fdd12b 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3688,7 +3688,13 @@ dimode_scalar_chain::convert_op (rtx *op, rtx_insn
*insn)
gen_rtvec (2, *op, const0_rtx));
if (!standard_sse_constant_p (vec_cst, V2DImode))
- vec_cst = validize_mem (force_const_mem (V2DImode, vec_cst));
+ {
+ start_sequence ();
+ vec_cst = validize_mem (force_const_mem (V2DImode, vec_cst));
+ rtx_insn *seq = get_insns ();
+ end_sequence ();
+ emit_insn_before (insns, insn)
+ }
emit_insn_before (gen_move_insn (tmp, vec_cst), insn);
*op = tmp;
[Bug ipa/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71146 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-16 CC||mpolacek at gcc dot gnu.org Component|middle-end |ipa Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #3 from Marek Polacek --- Started with: commit 76e435b59827b24023218ca99d634ed81cd28e7d Author: hubicka Date: Sun May 8 18:44:02 2016 + * cgraph.c (thunk_adjust): Export. * cgraphclones.c (cgraph_node::create_clone): Clone thunk info. * cgraphunit.c (thunk_adjust): Export. (cgraph_node::assemble_thunks_and_aliases): Do not assemble inlined thunks. * ipa-inline-analyssi.c (compute_inline_parameters): Thunks are inlinable. * tree-inline.c (expand_call_inline): Expand thunks inline. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@236012 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug tree-optimization/71132] [7 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu with “seg fault”
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71132 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-16 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |7.0 Summary|gcc ICE at -O3 on valid |[7 Regression] gcc ICE at |code on x86_64-linux-gnu|-O3 on valid code on |with “seg fault”|x86_64-linux-gnu with “seg ||fault” Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with: commit f52a3ef65a923faa1c22a8c04cda64ed8f0b2234 Author: rguenth Date: Thu May 12 07:18:58 2016 + 2016-05-12 Richard Biener PR tree-optimization/70986 * cfganal.c: Include cfgloop.h. (dfs_find_deadend): Prefer to take edges exiting loops. * gcc.dg/torture/pr70986-1.c: New testcase. * gcc.dg/torture/pr70986-2.c: Likewise. * gcc.dg/torture/pr70986-3.c: Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@236158 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114 --- Comment #12 from Iain Sandoe --- (In reply to Iain Sandoe from comment #11) > I wonder if it's a stack/data alignment problem maybe not; comparing 6.1 and trunk with the function annotated to __attribute__((noinline)) it seems that the problem is introduced before the inlining; and it looks, as you say, to be related to the load of the constant value equivalent to data[0]. For 6.1 since the function is static the constant load is moved into variable_shift() and the value of i is passed in eax. This all shows up in a Linux X x86_64-apple-darwin10 configured like: ../gcc-mainline/configure --prefix=/somewhere --target=x86_64-apple-darwin10 --host=x86_64-linux-gnu --build=x86_64-linux-gnu --enable-languages=c --enable-targets=all
[Bug middle-end/39275] -funroll-loop fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39275 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #5 from Arseny Solokha --- I cannot reproduce it w/ any supported (as of today) version of gcc, as well as w/ trunk. Seems to be fixed long ago.
[Bug tree-optimization/71109] gcc ICE at -O3 on valid code on x86_64-linux-gnu in "maybe_record_trace_start"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71109 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-16 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with: commit 5c2b6d9bed3b944469ab387325476d1188000f46 Author: segher Date: Tue Sep 15 00:38:21 2015 + shrink-wrap: Rewrite This patch rewrites the shrink-wrapping algorithm, allowing non-linear pieces of CFG to be duplicated for use without prologue instead of just linear pieces. * shrink-wrap.c (requires_stack_frame_p): Fix formatting. (dup_block_and_redirect): Delete function. (can_dup_for_shrink_wrapping): New function. (fix_fake_fallthrough_edge): New function. (try_shrink_wrapping): Rewrite function. (convert_to_simple_return): Call fix_fake_fallthrough_edge. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@227775 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug tree-optimization/71148] New: [7 Regression] Compile time hog w/ -O3 -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71148
Bug ID: 71148
Summary: [7 Regression] Compile time hog w/ -O3 -funroll-loops
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
It take indefinite (or very long?) time for gcc-7.0.0-alpha20160515 to compile
the following snippet w/ -O3 -funroll-loops:
int rh, ok, kq, fu;
void
js (int cs)
{
rh = fu;
if (fu != 0)
{
cs /= 3;
if (cs <= 0)
{
int z9;
for (z9 = 0; z9 < 2; ++z9)
{
z9 += cs;
ok += z9;
fu += ok;
}
}
}
}
void
vy (int s3)
{
int yo, g2 = 0;
sd:
js (g2);
for (yo = 0; yo < 2; ++yo)
{
if (fu != 0)
goto sd;
kq += (s3 != (g2 ? s3 : 0));
for (s3 = 0; s3 < 72; ++s3)
g2 *= (~0 - 1);
g2 -= yo;
}
for (fu = 0; fu < 18; ++fu)
for (yo = 0; yo < 17; ++yo)
if (g2 < 0)
goto sd;
}
et_splay(et_occ *) is the absolute leader in perf top w/ 32%, almost like in
PR51005.
[Bug fortran/70959] [6/7 Regression] Invalid type determination due to expression in a type declaration statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70959 --- Comment #4 from Dominique d'Humieres --- As shown by the following reduced test integer(8), parameter :: e18 = 1000_8 integer(8) :: e19 e19= (e18) print *, e18, e19 end there are two issues: (1) a bogus warning, (2) more annoying, the warning is misplaced, hence misleading. IMO if one tries to fix this PR the priority should be the second issue.
[Bug middle-end/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71146 Markus Trippelsdorf changed: What|Removed |Added CC||hubicka at ucw dot cz --- Comment #2 from Markus Trippelsdorf --- -fno-devirtualize-speculatively "fixes" the issue.
[Bug middle-end/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71146
--- Comment #1 from Markus Trippelsdorf ---
trippels@gcc2-power8 http % cat Http2Session.ii
typedef enum {} nsresult;
struct A {
virtual void SetConnection();
};
struct B {
virtual nsresult OnReadSegment(const char *, int, int *) = 0;
};
struct C : A, B {
nsresult OnReadSegment(const char *, int, int *);
void FlushOutputQueue();
B *mSegmentReader;
};
void C::FlushOutputQueue() {
if (!mSegmentReader)
return;
mSegmentReader->OnReadSegment(0, 0, 0);
}
nsresult C::OnReadSegment(const char *, int, int *) {
FlushOutputQueue();
mSegmentReader = 0;
OnReadSegment(0, 0, 0);
}
trippels@gcc2-power8 http % g++ -O3 -c Http2Session.ii
Http2Session.ii: In member function ‘virtual nsresult C::OnReadSegment(const
char*, int, int*)’:
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
mSegmentReader->OnReadSegment(0, 0, 0);
^
__builtin_unreachable (adjusted_this.9_275, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.10_280, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.11_290, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.12_295, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.13_300, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.14_305, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.15_317, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.16_322, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.17_327, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.18_332, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.19_337, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.20_342, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.21_356, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.22_361, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.23_366, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.24_371, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.25_376, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.26_381, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.27_386, 0B, 0, 0B);
Http2Session.ii:16:41: error: __builtin_unreachable or __builtin_trap call with
arguments
__builtin_unreachable (adjusted_this.28_391, 0B, 0, 0B);
Http2Session.ii:16:41: internal compiler error: verify_gimple failed
0x10b1c447 verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:5166
0x109be22f execute_function_todo
../../gcc/gcc/passes.c:1964
0x109bf083 do_per_function
../../gcc/gcc/passes.c:1648
0x109bf39f execute_todo
../../gcc/gcc/passes.c:2016
[Bug rtl-optimization/70978] [5 Regression] internal compiler error: in assign_by_spills, at lra-assigns.c:1428 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70978 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-16 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Ramana Radhakrishnan --- Confirmed.
[Bug c++/71147] [6 REGRESSION] Flexible array member wrongly rejected in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71147 Avi Kivity changed: What|Removed |Added Attachment #38497|0 |1 is obsolete|| --- Comment #1 from Avi Kivity --- Created attachment 38498 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38498&action=edit Slightly simpler reproducer (no std::atomic)
[Bug c++/71147] New: [6 REGRESSION] Flexible array member wrongly rejected in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71147 Bug ID: 71147 Summary: [6 REGRESSION] Flexible array member wrongly rejected in template Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: a...@cloudius-systems.com Target Milestone: --- Created attachment 38497 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38497&action=edit Reproducer gcc (GCC) 6.1.1 20160510 (Red Hat 6.1.1-2) The attached code does not compile under g++ 6. It works fine under 5.3 (with -std=gnu++14). Removing "template , or converting the array to be an array of unsigned (instead of array of struct) hides the problem.
[Bug c++/71145] Alpha: Error: No lda !gpdisp!278 was found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71145 --- Comment #2 from Uroš Bizjak --- Similar to PR 64113. Maybe we need to move the mentioned peephole2s to post-epilogue_completed splitter.
[Bug c++/71145] Alpha: Error: No lda !gpdisp!278 was found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71145 --- Comment #1 from Uroš Bizjak --- (In reply to Michael Cree from comment #0) > I will attempt to attach preprocessed source of SubscriberInfo.cpp from > libavg. Um, no I can't; it's too large for the 1000kB limit. How can I > provide the file? Even when you compress it?
[Bug middle-end/71146] New: [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71146 Bug ID: 71146 Summary: [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Target Milestone: --- Created attachment 38496 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38496&action=edit unreduced testcase trippels@gcc2-power8 ~ % ~/gcc_test/usr/local/bin/g++ -w -O3 -c Http2Session.ii /home/trippels/gecko-dev/netwerk/protocol/http/Http2Session.cpp: In member function ‘nsresult mozilla::net::Http2Session::BufferOutput(const char*, uint32_t, uint32_t*)’: /home/trippels/gecko-dev/netwerk/protocol/http/Http2Session.cpp:2898:62: error: __builtin_unreachable or __builtin_trap call with arguments rv = mSegmentReader->OnReadSegment(buf, count, countRead); ^ __builtin_unreachable (adjusted_this.1907_86, _52, avail_47, &countRead); /home/trippels/gecko-dev/netwerk/protocol/http/Http2Session.cpp:2898:62: internal compiler error: verify_gimple failed 0x10b1c447 verify_gimple_in_cfg(function*, bool) ../../gcc/gcc/tree-cfg.c:5166 0x109be22f execute_function_todo ../../gcc/gcc/passes.c:1964 0x109bf083 do_per_function ../../gcc/gcc/passes.c:1648 0x109bf39f execute_todo ../../gcc/gcc/passes.c:2016 Reducing...
[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114 --- Comment #11 from Iain Sandoe --- I wonder if it's a stack/data alignment problem
[Bug c++/71145] New: Alpha: Error: No lda !gpdisp!278 was found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71145
Bug ID: 71145
Summary: Alpha: Error: No lda !gpdisp!278 was found
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mcree at orcon dot net.nz
Target Milestone: ---
Target: alpha
In certain packages on debian-ports build logs for the Alpha architecture I am
seeing compile failures of the nature:
{standard input}: Assembler messages:
{standard input}:7233: Error: No lda !gpdisp!278 was found
One such example is src/player/SubscriberInfo.o of the source package libavg
(build log is at
https://buildd.debian.org/status/fetch.php?pkg=libavg&arch=alpha&ver=1.8.1-2.1&stamp=1461798687).
Compile failure happens with gcc-5 (Debian version 5.3.1-19) and also with
gcc/g++ (7.0.0) built from the trunk about a week ago (though the line number
of the failure changes).
I will attempt to attach preprocessed source of SubscriberInfo.cpp from libavg.
Um, no I can't; it's too large for the 1000kB limit. How can I provide the
file?
Compiling with:
g++ -pthread -ffast-math -pipe -g -O2 -c SubscriberInfo-preprocessed.cpp -fPIC
-o .libs/SubscriberInfo.o
results in the No lda gpdisp error.
It successfully compiles if the -O2 is changed to -O0 or -O1.
[Bug c++/71143] [7 Regression] bogus error: ‘A’ is not a base of ‘B< >’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71143 --- Comment #1 from Markus Trippelsdorf --- Started with r236221.
[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114 --- Comment #10 from Iain Sandoe --- (In reply to Ilya Enkovich from comment #9) > (In reply to Iain Sandoe from comment #8) > > Created attachment 38495 [details] > > assembly for linux case > > > > Here's the asm for the case from my build, although I don't expect it'll > > help much if you can't reproduce it. > > But I can build and run this asm with no problem. What's wrong with it then? not sure, I'll see if I can analyse more.
[Bug c++/70466] ICE on invalid code on x86_64-linux-gnu in tree check: expected constructor, have parm_decl in convert_like_real, at cp/call.c:6371 with -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70466 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #2 from Paolo Carlini --- Mine.
[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104
--- Comment #3 from nsz at gcc dot gnu.org ---
simplified a bit further:
void foo(void);
int vfork(void);
int *p;
void bar(void)
{
foo();
*p = vfork();
}
[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114 --- Comment #9 from Ilya Enkovich --- (In reply to Iain Sandoe from comment #8) > Created attachment 38495 [details] > assembly for linux case > > Here's the asm for the case from my build, although I don't expect it'll > help much if you can't reproduce it. But I can build and run this asm with no problem. What's wrong with it then?
[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114 --- Comment #8 from Iain Sandoe --- Created attachment 38495 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38495&action=edit assembly for linux case Here's the asm for the case from my build, although I don't expect it'll help much if you can't reproduce it.
[Bug tree-optimization/71144] New: [6/7 Regression] isl_aff.c:1001: position out of bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71144
Bug ID: 71144
Summary: [6/7 Regression] isl_aff.c:1001: position out of
bounds
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
The testcase:
int a, c, d, e, f;
int b[1];
short g;
void
fn1 ()
{
for (; a; a++)
if (f)
for (; e; e--)
{
d = 0;
for (; d <= 0; d++)
if (c)
break;
(g = a) || (b[a] = 0);
}
}
ICEs with -Ofast -floop-interchange:
../../gcc/isl/isl_aff.c:1001: position out of bounds
mycrash.c: In function ‘fn1’:
mycrash.c:6:1: internal compiler error: Aborted
fn1 ()
^~~
0xbab71f crash_signal
../../gcc/gcc/toplev.c:333
0x13a4fe2 isl_handle_error
../../gcc/isl/isl_ctx.c:96
0x1365fa1 isl_aff_set_coefficient_si
../../gcc/isl/isl_aff.c:1000
0x12342da extract_affine_chrec
../../gcc/gcc/graphite-sese-to-poly.c:239
0x12342da extract_affine
../../gcc/gcc/graphite-sese-to-poly.c:381
0x123418e extract_affine
../../gcc/gcc/graphite-sese-to-poly.c:421
0x123523d add_condition_to_pbb
../../gcc/gcc/graphite-sese-to-poly.c:458
0x123523d add_conditions_to_domain
../../gcc/gcc/graphite-sese-to-poly.c:525
0x123523d build_iteration_domains
../../gcc/gcc/graphite-sese-to-poly.c:1017
0x1234fe5 build_iteration_domains
../../gcc/gcc/graphite-sese-to-poly.c:1040
0x123579f build_poly_scop(scop*)
../../gcc/gcc/graphite-sese-to-poly.c:1364
0x121fb9a graphite_transform_loops()
../../gcc/gcc/graphite.c:319
0x12201a0 graphite_transforms
../../gcc/gcc/graphite.c:356
0x12201a0 execute
../../gcc/gcc/graphite.c:433
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
This is using ISL 0.15 as downloaded from contrib/download_prerequisites.
Don't know if this is an ISL bug or a bug in the way GCC communicates with it.
[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114 --- Comment #7 from Ilya Enkovich --- (In reply to Dominique d'Humieres from comment #2) > Created attachment 38486 [details] > Assembly for gcc.c-torture/execute/ashldi-1.c compiled with r236090 > > Assembly for gcc.c-torture/execute/ashldi-1.c compiled with r236090 and -Os > -m32. This part looks wrong: movd%xmm1, %edi movaps (%edi), %xmm0 Most probably it is an attempt to load a constant. Unfortunately I still don't have a way to reproduce it. Will try more.
[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #6 from Ilya Enkovich ---
(In reply to Iain Sandoe from comment #5)
> Also fails on Linux for the m32 multilib with -msse2avx :
> make -k check-gcc-c
> RUNTESTFLAGS="--target_board=unix/-msse/-msse2avx\{-m32,-m64\}
> execute.exp=ashldi-1.c"
Can't reproduce the problem on Linux (using r236170)
=== gcc Summary for unix/-msse/-msse2avx/-m32 ===
# of expected passes16
Running target unix/-msse/-msse2avx/-m64
=== gcc Summary for unix/-msse/-msse2avx/-m64 ===
# of expected passes16
[Bug c++/71143] New: [7 Regression] bogus error: ‘A’ is not a base of ‘B< >’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71143
Bug ID: 71143
Summary: [7 Regression] bogus error: ‘A’ is not a base of
‘B< >’
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
trippels@gcc2-power8 llvm_build % cat LockFileManager.ii
struct A;
template struct B {
void m_fn1() { this->A::assign; }
};
trippels@gcc2-power8 llvm_build % clang++ -std=c++14 -c LockFileManager.ii
trippels@gcc2-power8 llvm_build % /home/trippels/gcc_5/usr/local/bin/g++
-std=c++14 -c LockFileManager.ii
trippels@gcc2-power8 llvm_build % /home/trippels/gcc_6/usr/local/bin/g++ -c
LockFileManager.ii
trippels@gcc2-power8 llvm_build % /home/trippels/gcc_test/usr/local/bin/g++ -c
LockFileManager.ii
LockFileManager.ii: In member function ‘void B< >::m_fn1()’:
LockFileManager.ii:3:27: error: ‘A’ is not a base of ‘B< >’
void m_fn1() { this->A::assign; }
^~
[Bug rtl-optimization/70978] [5 Regression] internal compiler error: in assign_by_spills, at lra-assigns.c:1428 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70978 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #1 from ktkachov at gcc dot gnu.org --- CC'ing Vlad on LRA opinion
[Bug tree-optimization/71142] New: [6/7 Regression] ICE: Segmentation fault in ssa_default_def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71142
Bug ID: 71142
Summary: [6/7 Regression] ICE: Segmentation fault in
ssa_default_def
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
The testcase:
int a, b, d, e;
int c[10];
short f;
unsigned g;
void
fn1 ()
{
int *h = &d;
for (; f; f--)
{
a = 0;
for (; a <= 1; a++)
{
d = 1;
for (; d >= 0; d--)
{
b = 0;
for (; b < 7; b++)
c[b] = b;
}
*h ^= g;
}
}
*h = *h & e;
}
ICEs on aarch64-none-linux-gnu with -Ofast -floop-interchange:
mycrash.c: In function 'fn1':
mycrash.c:7:1: internal compiler error: Segmentation fault
fn1 ()
^~~
0xb02b4f crash_signal
$SRC/gcc/toplev.c:335
0xb58db5 ssa_default_def(function*, tree_node*)
$SRC/gcc/tree-dfa.c:305
0xb5b9c4 get_or_create_ssa_default_def(function*, tree_node*)
$SRC/gcc/tree-dfa.c:357
0xb9665f get_reaching_def
$SRC/gcc/tree-into-ssa.c:1168
0xb9b6b4 rewrite_update_phi_arguments
$SRC/gcc/tree-into-ssa.c:2017
0xb9b6b4 rewrite_update_dom_walker::before_dom_children(basic_block_def*)
$SRC/gcc/tree-into-ssa.c:2137
0x1063b49 dom_walker::walk(basic_block_def*)
$SRC/gcc/domwalk.c:265
0xb9427c rewrite_blocks
$SRC/gcc/tree-into-ssa.c:2194
0xb9cccf update_ssa(unsigned int)
$SRC/gcc/tree-into-ssa.c:3356
0x1091de5 graphite_regenerate_ast_isl(scop*)
$SRC/gcc/graphite-isl-ast-to-gimple.c:3204
0x1088995 graphite_transform_loops()
$SRC/gcc/graphite.c:329
0x1088b34 graphite_transforms
$SRC/gcc/graphite.c:356
0x1088b34 execute
$SRC/gcc/graphite.c:433
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug testsuite/70227] pr69589 does not check for -rdynamic availability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70227 Jiong Wang changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jiong Wang --- Fixed r236265.
[Bug testsuite/70227] pr69589 does not check for -rdynamic availability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70227 --- Comment #3 from Jiong Wang --- Author: jiwang Date: Mon May 16 08:11:42 2016 New Revision: 236265 URL: https://gcc.gnu.org/viewcvs?rev=236265&root=gcc&view=rev Log: [testsuite] PR70227, skip g++.dg/lto/pr69589_0.C on targets without -rdynamic support PR testsuite/70227 * g++.dg/lto/pr69589_0.C: Skip arm and aarch64 bare-metal targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/lto/pr69589_0.C
[Bug c++/71092] [6/7 Regression] ICE: in cxx_eval_call_expression, at cp/constexpr.c:1449; only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71092 Markus Trippelsdorf changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #6 from Markus Trippelsdorf --- Both issues started with r232848.
[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
Iain Sandoe changed:
What|Removed |Added
Target|x86_64-apple-darwin*|x86_64-apple-darwin*,x86_64
||-pc-linux-gnu
Host|x86_64-apple-darwin*|x86_64-apple-darwin*,x86_64
||-pc-linux-gnu
Build|x86_64-apple-darwin*|x86_64-apple-darwin*,x86_64
||-pc-linux-gnu
--- Comment #5 from Iain Sandoe ---
Also fails on Linux for the m32 multilib with -msse2avx :
make -k check-gcc-c
RUNTESTFLAGS="--target_board=unix/-msse/-msse2avx\{-m32,-m64\}
execute.exp=ashldi-1.c"
