[Bug libfortran/61049] [4.9/4.10 Regression] NIST test FM906 fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61049 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #4 from Jerry DeLisle --- Assigning to myself. Will ad Dominiques reduced test case to the testsuite.
[Bug libfortran/61049] [4.9/4.10 Regression] NIST test FM906 fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61049 --- Comment #3 from Jerry DeLisle --- Created attachment 32734 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32734&action=edit Patch pending This patch places eat_separator back in but leaves the portion below which was added to finish_separator. i am still testing but it fixes this regression and the fix to PR46800 is retained.
[Bug tree-optimization/42145] Incorrect "may be used uninitialized warning" for a very specific test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42145
--- Comment #11 from Marcel Telka ---
It is reproducible even with -O1:
int f(void);
int
main(void)
{
int a, b;
a = f();
if (a)
b = f();
if (a && b)
return 1;
return 0;
}
$ gcc -O1 -Wuninitialized -c a.c
a.c: In function 'main':
a.c:12:15: warning: 'b' may be used uninitialized in this function
[-Wmaybe-uninitialized]
if (a && b)
^
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/gcc/4.8/lib/gcc/sparc-sun-solaris2.11/4.8.2/lto-wrapper
Target: sparc-sun-solaris2.11
Configured with:
/ws/builds2/jenkins/src/du/dilos-userland-review/components/gcc48/gcc-4.8.2/configure
--prefix=/usr/gcc/4.8 --mandir=/usr/gcc/4.8/share/man --bindir=/usr/gcc/4.8/bin
--libdir=/usr/gcc/4.8/lib --sbindir=/usr/gcc/4.8/sbin --infodir=/usr/share/info
--without-gnu-as --with-as=/usr/bin/as --build=sparc-sun-solaris2.11
--infodir=/usr/gcc/4.8/share/info --libexecdir=/usr/gcc/4.8/lib
--enable-languages=c,c++,fortran,objc --enable-shared
--enable-targets=sparcv9-sun-solaris2.11 --without-gnu-ld --with-ld=/usr/bin/ld
Thread model: posix
gcc version 4.8.2 (GCC)
$
[Bug c/61050] OpenMP: wrong behavior of 'omp for' on corner cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61050 --- Comment #2 from Guido Martínez --- (In reply to Jakub Jelinek from comment #1) > This is undefined behavior. > See OpenMP 4.0, 2.6, lines 18-26 on page 52: > > "The following restrictions also apply: > > - If test-expr is of the form var relational-op b and relational-op is < or > <= then incr-expr must cause var to increase on each iteration of the loop. > If test-expr is of the form var relational-op b and relational-op is > or >= > then incr-expr must cause var to decrease on each iteration of the loop. > > - If test-expr is of the form b relational-op var and relational-op is < or > <= then incr-expr must cause var to decrease on each iteration of the loop. > If test-expr is of the form b relational-op var and relational-op is > or >= > then incr-expr must cause var to increase on each iteration of the loop." I see. I apologize for reporting this, then.
[Bug libstdc++/61059] regex throws regex_error for valid extended regular expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61059 Jonathan Wakely changed: What|Removed |Added Known to work|4.10.0 | Target Milestone|4.9.1 |--- --- Comment #2 from Jonathan Wakely --- (Unsetting fields I accidentally filled in on the wrong browser tab)
[Bug libstdc++/61059] regex throws regex_error for valid extended regular expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61059
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work||4.10.0
Resolution|--- |INVALID
Target Milestone|--- |4.9.1
--- Comment #1 from Jonathan Wakely ---
Reduced:
#include
int main()
{
std::regex description_keys("\\]", std::regex::extended);
}
POSIX says this is undefined:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04_02
The closing brace is not a POSIX ERE special character so should not be
escaped.
As a GNU extension we accept it with -std=gnu++11
[Bug libstdc++/60940] general operations on atomic types do not work with atomic integral typedefs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60940 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-04 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/61057] [C++11] operator . considered part of User Defined Literal invocation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61057
Jonathan Wakely changed:
What|Removed |Added
CC||emsr at gcc dot gnu.org
--- Comment #1 from Jonathan Wakely ---
Reduced:
class Int {
public:
constexpr Int(long long unsigned value)
: m_value(value)
{}
const long long unsigned m_value;
};
constexpr Int operator "" _i(long long unsigned i) {
return Int(i);
}
auto x = 1_i.m_value;
I think G++ is correct, the grammar in the standard defines 1_i.m_value as a
pp-number, i.e. a single preprocessing token, which is treated as a literal, so
_i.m_value is looked up as the suffix.
Clang gives the same error.
[Bug bootstrap/60984] [4.9 Regression] AIX: gcc-4.9.0 bootstrap fails in stage-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984 --- Comment #12 from David Edelsohn --- Are you using GNU Bash as your SHELL (recommended in the target-specific installation instructions). It should not take that long to bootstrap GCC on a recent system. AIX /bin/sh runs configure very slowly.
[Bug rtl-optimization/61060] New: [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -free-ter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61060 Bug ID: 61060 Summary: [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -free-ter Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 32733 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32733&action=edit reduced testcase Compiler output: $ gcc -ftree-ter testcase.c testcase.c: In function 'foo': testcase.c:6:3: internal compiler error: in int_mode_for_mode, at stor-layout.c:400 return __builtin_memset (dest, ch, len); ^ 0xb2e513 int_mode_for_mode(machine_mode) /mnt/svn/gcc-trunk/gcc/stor-layout.c:400 0x84759e emit_move_via_integer /mnt/svn/gcc-trunk/gcc/expr.c:3198 0x85579c emit_move_insn_1(rtx_def*, rtx_def*) /mnt/svn/gcc-trunk/gcc/expr.c:3578 0x855b68 emit_move_insn(rtx_def*, rtx_def*) /mnt/svn/gcc-trunk/gcc/expr.c:3645 0x836ebc copy_to_mode_reg(machine_mode, rtx_def*) /mnt/svn/gcc-trunk/gcc/explow.c:656 0xe10960 ix86_expand_set_or_movmem(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, bool) /mnt/svn/gcc-trunk/gcc/config/i386/i386.c:24182 0xedd82e gen_setmemsi(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*) /mnt/svn/gcc-trunk/gcc/config/i386/i386.md:15539 0xa35452 insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*) const /mnt/svn/gcc-trunk/gcc/recog.h:291 0xa35452 maybe_gen_insn(insn_code, unsigned int, expand_operand*) /mnt/svn/gcc-trunk/gcc/optabs.c:8322 0xa35a88 maybe_expand_insn(insn_code, unsigned int, expand_operand*) /mnt/svn/gcc-trunk/gcc/optabs.c:8334 0x849eee set_storage_via_setmem(rtx_def*, rtx_def*, rtx_def*, unsigned int, unsigned int, long, unsigned long, unsigned long, unsigned long) /mnt/svn/gcc-trunk/gcc/expr.c:3007 0x717197 expand_builtin_memset_args /mnt/svn/gcc-trunk/gcc/builtins.c:3731 0x7306c0 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) /mnt/svn/gcc-trunk/gcc/builtins.c:6173 0x84f64d expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /mnt/svn/gcc-trunk/gcc/expr.c:10340 0x85eb17 store_expr(tree_node*, rtx_def*, int, bool) /mnt/svn/gcc-trunk/gcc/expr.c:5328 0x865f5e expand_assignment(tree_node*, tree_node*, bool) /mnt/svn/gcc-trunk/gcc/expr.c:5114 0x7573f6 expand_call_stmt /mnt/svn/gcc-trunk/gcc/cfgexpand.c:2273 0x7573f6 expand_gimple_stmt_1 /mnt/svn/gcc-trunk/gcc/cfgexpand.c:3170 0x7573f6 expand_gimple_stmt /mnt/svn/gcc-trunk/gcc/cfgexpand.c:3322 0x758a37 expand_gimple_basic_block /mnt/svn/gcc-trunk/gcc/cfgexpand.c:5162 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. $ gcc -v Using built-in specs. COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-210047-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df --enable-languages=c,c++,lto,fortran --prefix=/mnt/svn/gcc-trunk/binary-210047-lto-fortran-checking-yes-rtl-df/ --without-cloog --without-ppl Thread model: posix gcc version 4.10.0 20140504 (experimental) (GCC) Tested revisions: Tested revisions: r210047 - ICE 4.9 r209651 - ICE 4.8 r209342 - OK 4.7 r209345 - OK 4.6 r197894 - OK
[Bug target/61058] New: [4.7/4.8/4.9/4.10 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61058 Bug ID: 61058 Summary: [4.7/4.8/4.9/4.10 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable() Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 32731 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32731&action=edit reduced testcase Compiler output: $ gcc -fno-asynchronous-unwind-tables -mtune=atom testcase.c testcase.c: In function 'f': testcase.c:4:1: internal compiler error: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:17922 } ^ 0xac42d4 rtl_check_failed_type1(rtx_def const*, int, int, char const*, int, char const*) /mnt/svn/gcc-trunk/gcc/rtl.c:754 0xdcc92a distance_agu_use_in_bb /mnt/svn/gcc-trunk/gcc/config/i386/i386.c:17922 0xdd02e9 distance_agu_use /mnt/svn/gcc-trunk/gcc/config/i386/i386.c:17979 0xdd02e9 ix86_lea_outperforms /mnt/svn/gcc-trunk/gcc/config/i386/i386.c:18063 0xffa274 output_89 /mnt/svn/gcc-trunk/gcc/config/i386/i386.md:2081 0x872491 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*) /mnt/svn/gcc-trunk/gcc/final.c:2919 0x873e3d final(rtx_def*, _IO_FILE*, int) /mnt/svn/gcc-trunk/gcc/final.c:2024 0x87434e rest_of_handle_final /mnt/svn/gcc-trunk/gcc/final.c:4428 0x87434e execute /mnt/svn/gcc-trunk/gcc/final.c:4502 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. $ gcc -v Using built-in specs. COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-210047-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df --enable-languages=c,c++,lto,fortran --prefix=/mnt/svn/gcc-trunk/binary-210047-lto-fortran-checking-yes-rtl-df/ --without-cloog --without-ppl Thread model: posix gcc version 4.10.0 20140504 (experimental) (GCC) Built with RTL checking enabled. Tested revisions: r210047 - ICE 4.9 r209651 - ICE 4.8 r209342 - ICE 4.7 r209345 - ICE 4.6 r197894 - OK
[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014 --- Comment #1 from Fredrik Hallenberg --- Same results with gcc 4.9.0
[Bug c++/61057] New: [C++11] operator . considered part of User Defined Literal invocation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61057 Bug ID: 61057 Summary: [C++11] operator . considered part of User Defined Literal invocation. Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: isupeene at ualberta dot ca Created attachment 32730 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32730&action=edit Contains udl_bug.cpp and udl_bug_workaround.cpp When compiling with 'g++ -std=c++11 ': The attached file udl_bug.cpp reproduces the bug, producing the error: "error: unable to find numeric literal operator ‘operator"" _i.m_value’". The attached file udl_bug_workaround.cpp compiles successfully and produces the expected output.
[Bug lto/61043] LTO accumulates CPU requirements from all input objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61043 --- Comment #3 from Andi Kleen --- >Unfortunately, gcc does not allow using SIMD intrinsics if not enabled by >>compiler switches, so leaving the compiler options for a generic target CPU >>wouldn't work. At least that is the case with gcc 4.8. This has been fixed in 4.9
[Bug tree-optimization/61056] strchr (x, 0) is not converted to strlen (x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61056 --- Comment #2 from Oleg Endo --- (In reply to Jakub Jelinek from comment #1) > 1) your testcase uses strrchr rather than strchr Sorry, typo/pasto. It was meant to be "strchr". > 2) why do you think it is desirable to convert strchr (x, 0) to x + strlen > (x)? On SH we have a builtin strlen implementation. I was just expecting strchr (x, 0) to utilize it, that's all. > Unless you have good library implementation for the latter and bad for the > former, strchr (x, 0) should be a win. > What the strlen pass does is that if you e.g. use strchr (x, 0) or strlen > (x) several times when the lengths of the strings actually can't change in > between, it can avoid the second and following call. And, it is able to > deal even with strlen (x) used in one place and strchr (x, 0) in another or > vice versa etc. (plus various other optimizations). Ah, thanks for the explanation. BTW, are there any plans to add true builtin strchr support so that it can be expanded by the target code in the same way as strlen?
[Bug tree-optimization/61056] strchr (x, 0) is not converted to strlen (x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61056 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- 1) your testcase uses strrchr rather than strchr 2) why do you think it is desirable to convert strchr (x, 0) to x + strlen (x)? Unless you have good library implementation for the latter and bad for the former, strchr (x, 0) should be a win. What the strlen pass does is that if you e.g. use strchr (x, 0) or strlen (x) several times when the lengths of the strings actually can't change in between, it can avoid the second and following call. And, it is able to deal even with strlen (x) used in one place and strchr (x, 0) in another or vice versa etc. (plus various other optimizations).
[Bug target/60884] [SH] improve inlined strlen-like builtin functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60884 --- Comment #2 from Oleg Endo --- I was trying to see how to implement the strchr builtin function which could also utilize the cmp/str insn. However, it seems that the necessary builtin expansion code for strchr is not there (yet).
[Bug tree-optimization/61056] New: strchr (x, 0) is not converted to strlen (x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61056
Bug ID: 61056
Summary: strchr (x, 0) is not converted to strlen (x)
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
At least on SH and r210026 the following:
extern "C" const char* strchr (const char*,int);
const char* test (const char* x)
{
return strrchr (x, 0);
}
does not get converted to a strlen (x). It seems that tree-ssa-strlen is
trying to do something but always fails.
[Bug libstdc++/61023] set/map move assignment doesn't move (or copy) the comparator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61023 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-04 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Jonathan Wakely --- Agreed, and I think there's an obvious approach to solve it, so we don't need to wait for a DR.
[Bug web/61054] Clearly note effect of memcpy optimization improvements in 4.9 changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61054 --- Comment #3 from Jonathan Wakely --- N.B. as well as custom allocators it affects the built-in delete[], which performs an implicit null check that can be optimized away in buggy code. We documented it on that page because of case where that happened.
[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832 --- Comment #3 from Paul Pluzhnikov --- Still reproduces on current trunk at r210049
[Bug fortran/45179] Support UTF-8 (and other encodings) in the source file (.f90) for CHARACTER(kind=4)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45179 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-04 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Still present at r210049.
[Bug web/61054] Clearly note effect of memcpy optimization improvements in 4.9 changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61054 Harald van Dijk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Harald van Dijk --- You're right, thanks for the pointer, somehow I missed that page.
[Bug fortran/51945] Diagnose wrong default initialization of DTs in a DT declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51945 --- Comment #8 from Dominique d'Humieres --- I have the patches in comments 4 and 7 for several months. They fix the issues without regression. Would it helps if I do the packaging?
[Bug web/61054] Clearly note effect of memcpy optimization improvements in 4.9 changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61054 --- Comment #1 from Jonathan Wakely --- We already documented it, see "null pointer checks optimized away more aggressively" at http://gcc.gnu.org/gcc-4.9/porting_to.html
[Bug target/61055] New: [avr] wrong test instruction after increment with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61055
Bug ID: 61055
Summary: [avr] wrong test instruction after increment with -O1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: konfera at efton dot sk
Target: avr
#include
extern int16_t foo(int16_t, int16_t);
int main(void) {
int16_t x = 0;
int16_t y = 0;
uint8_t c = 0x20;
do {
x = foo(x, y);
y = foo(y, c);
c++;
if (c >= 0x80) c = 0x20;
} while (y > 0);
while(1);
}
c:\tmp>avr-gcc -mmcu=avr2 -O1 -S ca.c -o ca.s
c:\tmp>avr-gcc --version
avr-gcc (AVR_8_bit_GNU_Toolchain_3.4.3_1072) 4.8.1
The sequence
c++;
if (c >= 0x80) c = 0x20;
compiles into
inc r15
brge .L2
set
clr r15
bld r15,5
.L2:
which fails when c == 0x7f, as brge does jump after the increment.
Jan Waclawek
[Bug web/61054] New: Clearly note effect of memcpy optimization improvements in 4.9 changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61054
Bug ID: 61054
Summary: Clearly note effect of memcpy optimization
improvements in 4.9 changes
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: web
Assignee: unassigned at gcc dot gnu.org
Reporter: harald at gigawatt dot nl
Consider this reduced program:
void *volatile null;
volatile long zerolen;
int main() {
void *dst = null, *src = null;
__builtin_memcpy (dst, src, zerolen);
if (dst) __builtin_abort ();
}
This program is invalid, but until 4.8 it would compile and run without an
issue. As of 4.9, it aborts.
I'm not asking for GCC to change (the programs should be fixed instead), but it
is not clear from the GCC 4.9 Changes page that such code no longer works. This
affects real code using custom allocators and realloc-like functions, where
some of those realloc-like functions don't bother to check for null pointers
and assume zero-length memcpy is a no-op. When the old memory is then freed,
and their free-like function performs a null pointer check, that check is
optimised away if the function gets inlined.
Could the GCC 4.9 Changes page get a mention of this?
I do see "Better inlining of memcpy and memset that is aware of value ranges
and produces shorter alignment prologues." in the IA-32/x86-64 section, but I
cannot tell if it is related to that, or if it is actually arch-independent.
[Bug ipa/60965] [4.10 Regression] IPA: Devirtualization versus placement new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965 --- Comment #13 from Jan Hubicka --- > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965 > > --- Comment #11 from Andrew Haley --- > (In reply to Jason Merrill from comment #9) > > (In reply to Andrew Haley from comment #8) > > > While it's true that we can play hardball on this one by insisting that > > > only > > > char arrays should be used with placement new, it wouldn't really do any > > > good. I don't think it would make any real-world code more efficient. > > > > On the contrary, this bug is an example of making real code more efficient, > > just inappropriately because of the special status of char arrays. We > > really don't want to have to assume that any random object can invisibly > > change type, as that would make type-based optimizations pretty useless. > > In this case? Really? What real well-defined code would be pessimized by > disabling this transformation in the case of POD types? Note that I do intend to disable it for all POD types for now (both at 4.9 and 4.10, at the proposed patch does). We may revisit it for 4.10 later, but I do not expect this is giong to cost too much of optimization; basically it will only lose in paths where there is call of virtual pointer of one derived type but we know that the instance is of incompatible derived type. These cases are harmful, since inliner & IPA code will agressively inline and optimize along those provably impossible paths, but it is not _that_ serious. What matters currently is that types with vtbl pointer are not changing randomly. Note that there is -fno-devirtualize as workaround in 4.9 Thank you! Honza
[Bug ipa/60965] [4.10 Regression] IPA: Devirtualization versus placement new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965 --- Comment #12 from Jan Hubicka --- > (In reply to Jan Hubicka from comment #4) > > Mine, probably 4.9 regression, too. > > It is, and Jonathan Wakely's earlier reduction exposes it on 4.9 too. > > (In reply to Jan Hubicka from comment #6) > > Can you, please, double check that it fixes the Java issues? > > With 4.9.0, for me, IcedTea reliably hangs during the build process. I hadn't > investigated the problem at all, but with 4.9.0 plus your patch, it builds > successfully. > > What I had looked into was a segmentation fault in Qt > (https://bugreports.qt-project.org/browse/QTBUG-38733) and Chromium, both > using > WebKit, also because of this. Chromium is still building, but for Qt, I can > confirm it is also fixed by your patch. Thank you, I think the patch (as it is, modulo the reversed comment) is safe - per Jason's comments we may make it stronger, but it won't win much: we are only interested in tracking types with vtable pointer, nothing else at the moment. Assuming that any type can change at any time would really disable pretty much all of the type based devirtualization - not just the case we are seeing, as the compiler would have to prove that there is no vtable store in between definition and apperance of the polymorphic call. We have logic for that, but it is not particularly strong: alias analysis will always say yes on any external function call, for instance. We make pretty strong assumptions here for years, so I hope there will be no additional surprises. I am still travelling, but will go ahead with it on monday if there are no other problems found. Honza
[Bug c/61053] [4.9/4.10 Regression] _Alignas(long long) reduces alignment of long long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61053 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-04 Known to work||4.8.2 Summary|_Alignas(long long) reduces |[4.9/4.10 Regression] |alignment of long long |_Alignas(long long) reduces ||alignment of long long Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- FWIW, it also compiles OK as C++11 with s/_Alignas/alignas/
[Bug c/61053] New: _Alignas(long long) reduces alignment of long long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61053 Bug ID: 61053 Summary: _Alignas(long long) reduces alignment of long long Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pdziepak at quarnos dot org On 32 bit x86 definition like the following one: _Alignas(long long) long long ll; causes GCC 4.9 to produce error: ‘_Alignas’ specifiers cannot reduce alignment of ‘ll’ Only types long long and double seem to be affected. The problem is not present on GCC 4.8.2.
[Bug c++/59498] [4.9/4.10 Regression] Pack expansion error in template alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59498 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-04 Known to work||4.8.2 Summary|Pack expansion error in |[4.9/4.10 Regression] Pack |template alias |expansion error in template ||alias Ever confirmed|0 |1 Known to fail||4.10.0, 4.9.0 --- Comment #2 from Jonathan Wakely --- This is a regression since 4.8 (4.7 gave a "sorry")
[Bug libfortran/61049] [4.9/4.10 Regression] NIST test FM906 fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61049 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-04 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > Also confirmed it is r208629. Simple fix is to revert that patch and reopen > the original bug which is related to CTRL-D on stdin, PR46800 I don't think there is any need to rush to revert.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #34 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #33 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #32 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #31 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #30 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #29 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug fortran/41936] Memory leakage with allocatables and user-defined operators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41936
--- Comment #6 from Dominique d'Humieres ---
Is the following patch OK?
--- ../_clean/gcc/fortran/trans-expr.c2014-04-30 21:41:33.0 +0200
+++ gcc/fortran/trans-expr.c2014-05-04 00:42:50.0 +0200
@@ -6504,6 +6504,20 @@ gfc_conv_expr_reference (gfc_se * se, gf
/* Take the address of that value. */
se->expr = gfc_build_addr_expr (NULL_TREE, var);
+ if (expr->ts.type == BT_DERIVED && expr->rank
+ && !gfc_is_finalizable (expr->ts.u.derived, NULL)
+ && expr->ts.u.derived->attr.alloc_comp
+ && expr->expr_type != EXPR_VARIABLE)
+{
+ tree tmp;
+
+ tmp = build_fold_indirect_ref_loc (input_location, se->expr);
+ tmp = gfc_deallocate_alloc_comp (expr->ts.u.derived, tmp, expr->rank);
+
+ /* The components shall be deallocated before
+ their containing entity. */
+ gfc_prepend_expr_to_block (&se->post, tmp);
+}
}
It fixes the memory leaks for the test in comment 0 and for
gfortran.dg/class_array_15.f03, but not pr55603 nor pr60913.
Is the following change for gfortran.dg/class_array_15.f03
--- ../_clean/gcc/testsuite/gfortran.dg/class_array_15.f032013-01-06
22:34:50.0 +0100
+++ gcc/testsuite/gfortran.dg/class_array_15.f032014-05-04
10:24:06.0 +0200
@@ -1,4 +1,5 @@
! { dg-do run }
+! { dg-options "-fdump-tree-original" }
!
! Tests the fixes for three bugs with the same underlying cause. All are
regressions
! that come about because class array elements end up with a different tree
type
@@ -114,3 +115,5 @@ subroutine pr54992 ! This test remains
bh => bhGet(b,instance=2)
if (loc (b) .ne. loc(bh%hostNode)) call abort
end
+! { dg-final { scan-tree-dump-times "builtin_free" 12 "original" } }
+! { dg-final { cleanup-tree-dump "original" } }
enough (there are only 11 builtin_free without the patch)? or should I add the
test in comment 0 (15 builtin_free with the patch, 12 without)?
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #28 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #27 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #26 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #25 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #24 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #23 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug ipa/60965] [4.10 Regression] IPA: Devirtualization versus placement new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965 --- Comment #11 from Andrew Haley --- (In reply to Jason Merrill from comment #9) > (In reply to Andrew Haley from comment #8) > > While it's true that we can play hardball on this one by insisting that only > > char arrays should be used with placement new, it wouldn't really do any > > good. I don't think it would make any real-world code more efficient. > > On the contrary, this bug is an example of making real code more efficient, > just inappropriately because of the special status of char arrays. We > really don't want to have to assume that any random object can invisibly > change type, as that would make type-based optimizations pretty useless. In this case? Really? What real well-defined code would be pessimized by disabling this transformation in the case of POD types? > As far as I know people always use char arrays for placement new anyway; at > least all the examples I've ever seen do. I'm not really sure how, given that objects must be aligned. We don't really know how much code this transformation breaks, but I do know that it breaks in ways that are hard to diagnose: in the Java example a function silently falls through to whatever happens to follow it. How about a compromise? Make this optimization respect -fno-strict-aliasing. People already expect that option to disable type-based optimizations.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #22 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #21 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #20 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #19 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #18 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #17 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #16 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #15 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #14 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #13 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 Thomas Preud'homme changed: What|Removed |Added CC||thomas.preudhomme at arm dot com --- Comment #12 from Thomas Preud'homme --- A patch to fix this is currently under discussion on gcc-patches at: http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00164.html
[Bug lto/61043] LTO accumulates CPU requirements from all input objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61043
--- Comment #2 from andysem at mail dot ru ---
(In reply to Andi Kleen from comment #1)
> Yes LTO doesn't support different options for different files, and combines
> some of them (which happens in your case) and ignores some others.
>
> You could use tag the functions in the different file with
>
> __attribute__(target("..."))
>
> This will also allow automatic switching.
>
> Arguably gcc should do this automatically for LTO, but unfortunately it
> doesn't
Unfortunately, gcc does not allow using SIMD intrinsics if not enabled by
compiler switches, so leaving the compiler options for a generic target CPU
wouldn't work. At least that is the case with gcc 4.8.
> Or alternatively don't compile the file that needs the changed options with
> LTO
Yes, I'm currently not using LTO in my real world project that exhibits this
problem. But users of my project would like to enable LTO, and currently this
silently produces incorrect binaries. The purpose of this ticket is to indicate
the problem and suggest a possible solution (automatically marking each
function in every translation unit with the target options).
