[Bug c/64417] [SH] FAIL: gcc.c-torture/compile/pr28865.c -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64417 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-01-06 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #5 from Marek Polacek --- Great, thanks.
[Bug fortran/64506] New: FORMAT Parse Error with Continuation Line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64506
Bug ID: 64506
Summary: FORMAT Parse Error with Continuation Line
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: thfanning at gmail dot com
Created attachment 34385
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34385&action=edit
Sample program to illustrate parse error.
In a FORMAT statement, a character literal immediately followed by a
continuation character (&) and then a comment character (!) results in a parse
error. A simple program is attached that implements the following statements:
100 format('This format is OK.'&
)
200 format('This format fails.'&!comment
)
300 format('This format fails.'& !comment
)
400 format('This format is OK.' &!comment
)
500 format('This format is OK.' & !comment
)
Compiling this results in the following:
200 format('This format fails.'&!comment
1
Error: Unexpected element '&' in format string at (1)
gfortran_parse_error.f90:13.32:
300 format('This format fails.'& !comment
1
Error: Unexpected element '&' in format string at (1)
[Bug c++/64497] std::scalbln does not round correctly for long doubles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64497 Sergey Zubkov changed: What|Removed |Added CC||cubbi at cubbi dot org --- Comment #5 from Sergey Zubkov --- FYI, cppreference got that phrasing from POSIX's "If the correct value would cause underflow, and is representable, a range error may occur and the correct value shall be returned.", which is a part of its optional IEC 60559 Floating-Point extension to the C standard: http://pubs.opengroup.org/onlinepubs/9699919799/functions/scalbln.html
[Bug c++/31397] Useful compiler warning missing (virtual functions in derived classes used without 'virtual')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397 --- Comment #16 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Tue Jan 6 02:02:47 2015 New Revision: 219213 URL: https://gcc.gnu.org/viewcvs?rev=219213&root=gcc&view=rev Log: implement -Wsuggest-override c-family/ PR c++/31397 * c.opt (Wsuggest-override): New option. cp/ PR c++/31397 * class.c (check_for_override): Warn when a virtual function is an override not marked override. gcc/ PR c++/31397 * doc/invoke.texi: Document -Wsuggest-override. Added: trunk/gcc/testsuite/g++.dg/warn/Wsuggest-override.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/doc/invoke.texi
[Bug rtl-optimization/64287] [5 Regression] Disable -fuse-caller-save when -pg is active
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64287 --- Comment #3 from clm at gcc dot gnu.org --- Author: clm Date: Mon Jan 5 23:42:27 2015 New Revision: 219208 URL: https://gcc.gnu.org/viewcvs?rev=219208&root=gcc&view=rev Log: 2015-01-05 Radovan Obradovic PR rtl-optimization/64287 gcc/ * toplev.c (HAVE_epilogue, HAVE_prologue): Provide default. (process_options): Disable flag_ipa_ra if profiling. gcc/testsuite/ * gcc.dg/aru-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/aru-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/toplev.c
[Bug ada/64492] Disabling libada prevents building gnattools-cross
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64492 --- Comment #15 from simon at pushface dot org --- (In reply to Luke A. Guest from comment #14) > (In reply to simon from comment #13) > > map feature yet. > > The what? indepsw-gnu.adb contains the switch to tell GNU ld to create a map file; I think this supports --create-map-file which works on command line or in package Builder of a GPR.
[Bug go/61871] FAIL: regexp from libgo testsuite on non-split stack targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61871 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #7 from Uroš Bizjak --- Thanks, the testcase now passes on alphaev68 [1]. [1] https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg00400.html
[Bug sanitizer/64344] [5 Regression] [UBSAN] ICE with -fsanitize=float-cast-overflow [ICE in -fsanitize=float-cast-overflow]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64344 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64465 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC|jakub at gcc dot gnu.org | Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek --- Fixed.
[Bug sanitizer/64265] [5 Regression] r217669 broke tsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265 --- Comment #26 from Jakub Jelinek --- Author: jakub Date: Mon Jan 5 21:47:51 2015 New Revision: 219202 URL: https://gcc.gnu.org/viewcvs?rev=219202&root=gcc&view=rev Log: PR sanitizer/64265 * gimplify.c (gimplify_function_tree): Add TSAN_FUNC_EXIT internal call as cleanup of the whole body. * internal-fn.def (TSAN_FUNC_EXIT): New internal call. * tsan.c (replace_func_exit): New function. (instrument_func_exit): Moved earlier. (instrument_memory_accesses): Adjust TSAN_FUNC_EXIT internal calls. Call instrument_func_exit if no TSAN_FUNC_EXIT internal calls have been found. (tsan_pass): Don't call instrument_func_exit. * internal-fn.c (expand_TSAN_FUNC_EXIT): New function. * tree-inline.c (copy_bb): Drop TSAN_FUNC_EXIT internal calls during inlining. Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/internal-fn.c trunk/gcc/internal-fn.def trunk/gcc/tree-inline.c trunk/gcc/tsan.c
[Bug sanitizer/64344] [5 Regression] [UBSAN] ICE with -fsanitize=float-cast-overflow [ICE in -fsanitize=float-cast-overflow]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64344 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Mon Jan 5 21:46:31 2015 New Revision: 219201 URL: https://gcc.gnu.org/viewcvs?rev=219201&root=gcc&view=rev Log: PR sanitizer/64344 * ubsan.h (ubsan_instrument_float_cast): Add ARG argument. * ubsan.c (ubsan_instrument_float_cast): Add ARG argument, pass it to libubsan handler instead of EXPR. Fold comparisons earlier, if the result is integer_zerop, return NULL_TREE. * convert.c (convert_to_integer): Pass expr as ARG. c/ * c-typeck.c (convert_for_assignment, c_finish_return): For -fsanitize=float-cast-overflow casts from REAL_TYPE to integer/enum types also set in_late_binary_op around convert call. * c-convert.c (convert): For -fsanitize=float-cast-overflow REAL_TYPE to integral type casts, if not in_late_binary_op, pass c_fully_fold result on expr as last argument to ubsan_instrument_float_cast, if in_late_binary_op, don't use c_save_expr but save_expr. testsuite/ * c-c++-common/ubsan/pr64344-1.c: New test. * c-c++-common/ubsan/pr64344-2.c: New test. Added: trunk/gcc/testsuite/c-c++-common/ubsan/pr64344-1.c trunk/gcc/testsuite/c-c++-common/ubsan/pr64344-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/c/ChangeLog trunk/gcc/c/c-convert.c trunk/gcc/c/c-typeck.c trunk/gcc/convert.c trunk/gcc/testsuite/ChangeLog trunk/gcc/ubsan.c trunk/gcc/ubsan.h
[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64465 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Mon Jan 5 21:45:08 2015 New Revision: 219200 URL: https://gcc.gnu.org/viewcvs?rev=219200&root=gcc&view=rev Log: PR tree-optimization/64465 * tree-inline.c (redirect_all_calls): During inlining clean up EH stmts and EH edges if redirect_call_stmt_to_callee changed the stmt to a non-throwing call. * gcc.dg/pr64465.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr64465.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c
[Bug target/64505] Powerpc compiler generates insn not found for -m32 -mpowerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64505 Michael Meissner changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-01-05 Ever confirmed|0 |1
[Bug target/64505] New: Powerpc compiler generates insn not found for -m32 -mpowerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64505 Bug ID: 64505 Summary: Powerpc compiler generates insn not found for -m32 -mpowerpc64 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: meissner at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Host: powerpc64-unknown-linux-gnu Target: powerpc64-unknown-linux-gnu Build: powerpc64-unknown-linux-gnu Created attachment 34384 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34384&action=edit File that shows the problem Compiling the attached file will generate an insn not found error message if it is compiled with the following options: -std=c99 -fno-strict-aliasing -Wall -m32 -mpowerpc64 foo.c -S -O2. The problem is inside of rs6000_secondary_reload, there is code for 64-bit and 32-bit. The reload insn that is returned is looking for a 64-bit scratch register, but the combination of switches -m32 -mpowerpc64 it should be generating a 32-bit scratch register.
[Bug c/64417] [SH] FAIL: gcc.c-torture/compile/pr28865.c -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64417 --- Comment #4 from Andreas Schwab --- The glibc sources never contained such an array of incomplete type. The example in bug28865#c3 has nothing to do with glibc.
[Bug libstdc++/64504] New: Invalid free() with _GLIBCXX_DEBUG and -fwhole-program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64504
Bug ID: 64504
Summary: Invalid free() with _GLIBCXX_DEBUG and -fwhole-program
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: andrey.vihrov at gmail dot com
Created attachment 34383
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34383&action=edit
Preprocessed source
Compiling the following program:
#define _GLIBCXX_DEBUG
#include
#include
int main()
{
std::string s;
std::cin >> s;
}
with "g++ -fwhole-program x.cpp" gives me
*** Error in `./a.out': free(): invalid pointer: 0x006017c0 ***
=== Backtrace: =
/usr/lib/libc.so.6(+0x732ae)[0x7fb15966e2ae]
/usr/lib/libc.so.6(+0x7872e)[0x7fb15967372e]
/usr/lib/libc.so.6(+0x78eeb)[0x7fb159673eeb]
/usr/lib/libstdc++.so.6(_ZNSs7reserveEm+0xa4)[0x7fb159f7d3e4]
/usr/lib/libstdc++.so.6(_ZStrsIcSt11char_traitsIcESaIcEERSt13basic_istreamIT_T0_ES7_RSbIS4_S5_T1_E+0x214)[0x7fb159f302f4]
./a.out[0x400b40]
/usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7fb15961b040]
./a.out[0x4009a9]
This is on 64-bit Arch Linux with GCC 4.9.2. My understanding of
-fwhole-program is that it can be used with one source file that includes
standard library headers and links with the standard library. If this is wrong,
then I'm sorry for filing a bogus bug report.
I have searched for similar reports and found bug #53838. And indeed the sample
program from that bug also crashes with the same message. However, my system
has only one GCC and libstdc++, unlike in that case.
gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-4.9-20141224/configure
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-cloog-backend=isl --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu --enable-multilib
--disable-werror --enable-checking=release
Thread model: posix
gcc version 4.9.2 20141224 (prerelease) (GCC)
[Bug fortran/47674] gfortran.dg/realloc_on_assign_5.f03: Segfault at run time for deferred (allocatable) string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47674 --- Comment #11 from Thomas Koenig --- Author: tkoenig Date: Mon Jan 5 19:21:12 2015 New Revision: 219195 URL: https://gcc.gnu.org/viewcvs?rev=219195&root=gcc&view=rev Log: 2015-01-05 Thomas Koenig PR fortran/47674 * dependency.h: Actually commit changes. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.h
[Bug ipa/64503] [5 Regression] gcc.dg/ipa/iinline-4.c:210:1: internal compiler error: Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64503 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- val *= exp2 (m_exp); - eek, why not scalbln?
[Bug ipa/64503] [5 Regression] gcc.dg/ipa/iinline-4.c:210:1: internal compiler error: Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64503
--- Comment #1 from Uroš Bizjak ---
The values at sreal::to_double are highly suspicious (these values are the same
on x86_64 and alpha), following is on x86_64:
125 val *= exp2 (m_exp);
(gdb) p val
$5 = -1073741826
(gdb) p m_exp
$6 = 2097153
(gdb) p/x m_exp
$7 = 0x21
(gdb) list
120 double
121 sreal::to_double () const
122 {
123 double val = m_sig;
124 if (m_exp)
125 val *= exp2 (m_exp);
126 return val;
127 }
This can be reproduced by simply setting breakpoint on sreal::to_double, the
problem will be exposed the first time this function is called.
[Bug ipa/64503] New: [5 Regression] gcc.dg/ipa/iinline-4.c:210:1: internal compiler error: Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64503 Bug ID: 64503 Summary: [5 Regression] gcc.dg/ipa/iinline-4.c:210:1: internal compiler error: Floating point exception Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com Recently compiler starts to crash with the Floating point exception on several IPA related testcases, where -fdump-ipa-inline is used. One example is: /space/uros/gcc-build/gcc/xgcc -B/space/uros/gcc-build/gcc/ /space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/ipa/iinline-4.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -fdump-ipa-inline -fno-early-inlining -fno-ipa-icf -S -o iinline-4.s /space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/ipa/iinline-4.c:210:1: internal compiler error: Floating point exception 0x1207c7743 crash_signal ../../gcc-svn/trunk/gcc/toplev.c:359 0x1207abf0c sreal::to_double() const ../../gcc-svn/trunk/gcc/sreal.c:125 0x120c92be7 inline_small_functions ../../gcc-svn/trunk/gcc/ipa-inline.c:1723 0x120c92be7 ipa_inline ../../gcc-svn/trunk/gcc/ipa-inline.c:2185 0x120c92be7 execute ../../gcc-svn/trunk/gcc/ipa-inline.c:2558 Please submit a full bug report, ... This problem can also bw seen on x86_64-linux-gnu with the above testcase. In the iinline-4.c.055i.inline dump file, badness is estimated to -inf: ... Considering hiphip4.constprop/36 with 6 size to be inlined into test4/14 in unknown:-1 Estimated badness is -inf, frequency 1.00. Inlined into test4 which now has time 16 and size 8,net change of -8. New minimal size reached: 160 (and several other occurrences) ... Please note that x86_64 is "immune" to infinities by default, where alpha needs special FP instructions to handle overflow traps. While this can be done (build the compiler with -mieee), it looks that something went wrong with the badness estimation.
[Bug tree-optimization/64494] [5 Regression] ICE at -Os and above on x86_64-linux-gnu in duplicate_ssa_name_range_info, at tree-ssanames.c:499
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64494 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Mon Jan 5 18:53:44 2015 New Revision: 219194 URL: https://gcc.gnu.org/viewcvs?rev=219194&root=gcc&view=rev Log: PR tree-optimization/64494 * tree-ssa-loop-im.c (move_computations_dom_walker::before_dom): Also clear SSA_NAME_ANTI_RANGE_P flag. * gcc.c-torture/compile/pr64494.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr64494.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-im.c
[Bug pch/64502] Incorrect warning about empty translation units when using pre-compiled headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64502 --- Comment #2 from johnst...@inn-soft.com --- Created attachment 34382 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34382&action=edit GCC intermediate output of MyProgram.c WITHOUT GCH
[Bug pch/64502] Incorrect warning about empty translation units when using pre-compiled headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64502 --- Comment #1 from johnst...@inn-soft.com --- Created attachment 34381 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34381&action=edit GCC pre-compiled intermediate output of Hello.h
[Bug pch/64502] New: Incorrect warning about empty translation units when using pre-compiled headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64502
Bug ID: 64502
Summary: Incorrect warning about empty translation units when
using pre-compiled headers
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: pch
Assignee: unassigned at gcc dot gnu.org
Reporter: johnst...@inn-soft.com
Created attachment 34380
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34380&action=edit
GCC intermediate output of MyProgram.c with GCH
When using a pre-compiled header that contains C code, GCC will complain anyway
that the translation unit is empty - even when it is obviously not. It appears
that the warning does not consider code that is inside the translation unit.
The test case below is rather contrived to create a minimal test case.
(Obviously, we aren't putting "int main" in the pre-compiled header!) However,
in the real world, we use GCC to compile the same source code for several
different platforms. The pre-compiled header always contains code (e.g. some
typedefs used by all platforms), but the C file itself may exclude all code via
"#if PLATFORM..." if it is not applicable to the current platform.
Steps to reproduce:
1. Create the following two files - Hello.h and MyProgram.c:
// Hello.h:
// NOTE: In the real world, we wouldn't be putting "int main" in the
// header, of course. Instead, there might be some typedefs here that
// aren't used, for example.
int main(void) {
return 0;
}
//
// MyProgram.c
#include "Hello.h"
// NOTE: In the real world, we would be excluding platform-specific code
// by using "#ifdef PLATFORM" around the entire body of code in this
// C file.
2. Now, compile it:
$ gcc -pedantic Hello.h -save-temps
$ gcc -pedantic MyProgram.c -o MyProgram -save-temps
MyProgram.c:1:0: warning: ISO C forbids an empty translation unit [-Wpedantic]
#include "Hello.h"
^
3. As illustrated above, GCC is wrongly complaining that the translation unit
is empty. It is, in fact, not empty - the code is in the pre-compiled
header...
4. Removing the pre-compiled header silences the warning:
$ rm Hello.h.gch
$ gcc -pedantic MyProgram.c -o MyProgram -save-temps
The problem is reproduced on both Cygwin 32-bit GCC 4.9.2, and on avr-gcc
distributed by Atmel, version 4.7.2.
Output of gcc -v for the Cygwin version:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.9.2/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.2-1.i686/src/gcc-4.9.2/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.2-1.i686/src/gcc-4.9.2 --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-arch=i686 --with-tune=generic --disable-sjlj-exceptions
--enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm
--enable-libquadmath --enable-libquadmath-support --enable-libssp
--enable-libada --enable-libjava --enable-libgcj-sublibs --disable-java-awt
--disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld
--with-gnu-as --with-cloog-include=/usr/include/cloog-isl
--without-libiconv-prefix --without-libintl-prefix --with-system-zlib
--enable-linker-build-id
Thread model: posix
gcc version 4.9.2 (GCC)
Attached are intermediate output files saved with "-save-temps" for cases both
with and without pre-compiled headers. My conclusion is that this warning only
considers the code in "MyProgram.i" and ignores what code might be included via
the proprietary "#pragma GCC pch_preprocess "Hello.h.gch"" that is apparently
an implementation detail of pre-compiled headers. Obviously, this doesn't
really relate to C99 grammar, which doesn't even consider pre-compiled headers.
One idea for fixing the problem might be a flag saved in the GCH file
indicating whether the file contained any real code, or whether it is empty.
The warning would only be raised if the C file AND the GCH file are both empty.
[Bug ada/64492] Disabling libada prevents building gnattools-cross
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64492 --- Comment #14 from Luke A. Guest --- (In reply to simon from comment #13) > TOOLS_TARGET_PAIRS is set in both gnattools/Makefile (when it has been > configured) and gcc/ada/gcc-interface/Makefile.in. Your patch is to the > gnattools/ one, the gcc-interface one already has this pair. Yup, as with the patches that we've wrangling with for the past 15 years (yes, that long) that has been the case, although I don't know when it all got split up into libada and gnattools dirs. But, the gnattool/configure case was moved there from the gcc-interface/Makefile.in, I always thought that they just forgot to remove the one from there. > If it is the case that any arm-*-eabi target is going to be a bare runtime If any *-elf/eabi-elf/coff/whatever target is going to be bare runtime... When I first started looking into this I was interested in ARM, not so much now. But maybe in the future. > target, with --disable-libada disabling gnattools/, then Eric’s patch and > Arno’s incantation will IMO work - I just built GCC 5 arm-eabi with Eric’s > patch and the two files were successfully copied into build/gcc/ada/tools, > and arm-eabi-gnatmake is capable of building a library. Haven’t checked the Interesting. > map feature yet. The what? > Looking at the two versions of TOOLS_TARGET_PAIRS, it seems that > gcc-interface/Makefile is mainly concerned with building the RTS > (LIBGNAT_TARGET_PAIRS etc) with the TOOLS_TARGET_PAIRS being left in place, > pretty much as fossils, when building the tools was moved to > gnattools/Makefile. Would be nice if this was documented in an easy to understand way in the makefiles, as in "What it's there for and why." As I state above, I have been dabbling on and off for 14 years for this. I have posted about it in various places and only got the response of the incantation, which I told them never worked, shame it's taken this long to get this quite major issue fixed.
[Bug c/64417] [SH] FAIL: gcc.c-torture/compile/pr28865.c -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64417 --- Comment #3 from Marek Polacek --- I have a patch for rejecting such code, but the question is if it is desirable to not accept that code, since e.g. glibc used to (?) misuse this feature.
[Bug libstdc++/64467] [5 Regression] 28_regex/traits/char/isctype.cc and wchar_t/isctype.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467 --- Comment #4 from Hans-Peter Nilsson --- (In reply to Jonathan Wakely from comment #3) > Almost certainly r217066. > > Is this a newlib target? Yes. > I would expect to see the same failure for all > newlib targets, as I defined std::ctype_base::blank to be equal to > std::ctype_base::space for newlib (and any libc where I couldn't determine > the right bitmask for the [:blank:] character class) and the [:space:] class > includes newline. What I meant by "Unexpectedly, I don't see this for other non-linux and/or "newlib" targets with libstdc++ results posted to gcc-testresults@", is that I couldn't find that which you (and I) expected. Though, not many posted "newlib" targets test-results include libstdc++ results. Trying to build one myself (one where I didn't also write the port) but alas previously trusted targets such as arm-eabi and powerpc-eabisim break left and right (building or massive test failures). Bah.
[Bug fortran/47674] gfortran.dg/realloc_on_assign_5.f03: Segfault at run time for deferred (allocatable) string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47674 --- Comment #10 from Thomas Koenig --- Author: tkoenig Date: Mon Jan 5 17:15:17 2015 New Revision: 219193 URL: https://gcc.gnu.org/viewcvs?rev=219193&root=gcc&view=rev Log: 2015-01-05 Thomas Koenig PR fortran/47674 * dependency.c: Update copyright years. (gfc_discard_nops): Add prototype. * dependency.c (discard_nops): Rename to gfc_discard_nops, make non-static. (gfc_discard_nops): Use gfc_discard_nops. (gfc_dep_difference): Likewise. * frontend-passes.c Update copyright years. (realloc_strings): New function. Add prototype. (gfc_run_passes): Call realloc_strings. (realloc_string_callback): New function. (create_var): Add prototype. Handle case of a scalar character variable. (optimize_trim): Do not handle allocatable variables. 2015-01-05 Thomas Koenig PR fortran/47674 * gfortran.dg/realloc_on_assign_25.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_25.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64465 --- Comment #9 from Jakub Jelinek --- I believe with function versioning you create a new function and fixup_cfg pass is what will be run first on that, isn't that the case? In any case, there is no guarantee TODO_cleanup_cfg will be executed right after function versioning, so the changes should be postponed till it will be ensured. The inliner on the other side always uses TODO_cleanup_cfg and thus should be safe.
[Bug c/59708] clang-compatible checked arithmetic builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708 --- Comment #31 from Pat Haugen --- (In reply to Pat Haugen from comment #30) > builtin-arith-overflow-10/11 are target problem, I'm working on a fix. builtin-arith-overflow-10/11 are fixed with the patch for pr64358.
[Bug middle-end/64415] [5 Regression] ICE: verify_ssa failed / segmentation fault with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64415 H.J. Lu changed: What|Removed |Added CC||hubicka at ucw dot cz --- Comment #2 from H.J. Lu --- It was caused by r218767.
[Bug c++/64501] Unreachable catch BB for try blocks that cannot create an exception of specific type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64501 --- Comment #1 from Marc Glisse --- There are a lot of possible optimizations related to exceptions, and most compilers perform almost none :-( The compiler could notice that t is nothrow, but it doesn't. If you mark it explicitly (add throw() for instance) main will be simplified. PR 53294 would also let it simplify for different reasons.
[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64465 --- Comment #8 from Jan Hubicka --- > > execute_fixup_cfg is called from inline_transform, I wonder why it does not > > catch > > this case? Anyway updating things immediately after redirection seems like > > right > > thing to do. Any reason why this is not part of redirect_stmt_to_callee? > > Because the early inliner does not call it. Early inliner should not do any redirection however. > > And the reason why I haven't changed cgraph.c is: > /* We need to defer cleaning EH info on the new statement to > fixup-cfg. We may not have dominator information at this point > and thus would end up with unreachable blocks and have no way > to communicate that we need to run CFG cleanup then. */ > comment, I initially had there the maybe_clean_or_replace_eh_stmt > (e->call_stmt, new_stmt); but that comment made me to reconsider. Which is > why > I've limited it in the patch to the inliner (id->call_stmt test), and don't do > this when versioning functions. Hmm, OK, it seems like someone (me?) already tried this :) However I do not see why function versioning should be any safer than inliner use in this respect. Honza
[Bug libstdc++/64467] [5 Regression] 28_regex/traits/char/isctype.cc and wchar_t/isctype.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467 --- Comment #3 from Jonathan Wakely --- Almost certainly r217066. Is this a newlib target? I would expect to see the same failure for all newlib targets, as I defined std::ctype_base::blank to be equal to std::ctype_base::space for newlib (and any libc where I couldn't determine the right bitmask for the [:blank:] character class) and the [:space:] class includes newline.
[Bug libstdc++/64467] [5 Regression] 28_regex/traits/char/isctype.cc and wchar_t/isctype.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467 --- Comment #2 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #0) > I'll triage the revision range to exclude that. It's one of 217063-217066, inclusive.
[Bug c++/64501] New: Unreachable catch BB for try blocks that cannot create an exception of specific type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64501
Bug ID: 64501
Summary: Unreachable catch BB for try blocks that cannot create
an exception of specific type
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
Hello.
I've been wondering if following catch branch in main can be optimized out as
unreachable:
void linker_error (void);
void t()
{
try
{
throw (char)(1);
}
catch (char t) {}
}
int
main()
{
try
{
t();
}
catch (void *v)
{
linker_error ();
}
}
As there's no possible emission of an exception of void*, can by call of
linker_error removed?
Thanks,
Martin
[Bug c++/64266] Can GCC produce local mergeable symbols for *.__FUNCTION__ and *.__PRETTY_FUNCTION__ functions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64266 --- Comment #2 from Jason Merrill --- (In reply to Jakub Jelinek from comment #1) > C++11 says that the address of __func__ can be the same as address of other > string literals, so I think that allows putting it into mergeable section. > But what isn't clear to me is if __func__ is used in some inline function, > if the standard allows __func__ to have different addresses between > different compilation units. The Core WG seems to be moving toward dropping the requirement that string literals have the same address in different compilation units, so I think we don't need to worry about __func__ either.
[Bug go/61871] FAIL: regexp from libgo testsuite on non-split stack targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61871 --- Comment #6 from ian at gcc dot gnu.org --- Author: ian Date: Mon Jan 5 16:13:06 2015 New Revision: 219192 URL: https://gcc.gnu.org/viewcvs?rev=219192&root=gcc&view=rev Log: PR go/61871 runtime: Increase stack size on 64-bit non-split-stack systems. >From Uros Bizjak. Modified: trunk/libgo/runtime/proc.c
[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64465 --- Comment #7 from Jakub Jelinek --- (In reply to Jan Hubicka from comment #6) > > Updated patch that works on this testcase. From the cgraph.c comments, it > > looks > > like e.g. during function versioning we rely on fixup_cfg to fix it up, but > > during inlining I think we need to do it immediately. TODO_cleanup_cfg is > > on > > during inlining. > > execute_fixup_cfg is called from inline_transform, I wonder why it does not > catch > this case? Anyway updating things immediately after redirection seems like > right > thing to do. Any reason why this is not part of redirect_stmt_to_callee? Because the early inliner does not call it. And the reason why I haven't changed cgraph.c is: /* We need to defer cleaning EH info on the new statement to fixup-cfg. We may not have dominator information at this point and thus would end up with unreachable blocks and have no way to communicate that we need to run CFG cleanup then. */ comment, I initially had there the maybe_clean_or_replace_eh_stmt (e->call_stmt, new_stmt); but that comment made me to reconsider. Which is why I've limited it in the patch to the inliner (id->call_stmt test), and don't do this when versioning functions.
[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64465 --- Comment #6 from Jan Hubicka --- > Updated patch that works on this testcase. From the cgraph.c comments, it > looks > like e.g. during function versioning we rely on fixup_cfg to fix it up, but > during inlining I think we need to do it immediately. TODO_cleanup_cfg is on > during inlining. execute_fixup_cfg is called from inline_transform, I wonder why it does not catch this case? Anyway updating things immediately after redirection seems like right thing to do. Any reason why this is not part of redirect_stmt_to_callee? Thanks for looking into this (I am flying back to Calgary at Friday and should be back in regular schedule) Honza
[Bug middle-end/64028] [5 Regression] r211599 caused many vectorizer test failures with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64028
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
I believe that is correct though.
If you have -fPIC, it means the sa or sb arrays could be interposed, and they
can have a different alignment then, so you can't rely on the increased
alignment.
So, either those tests should use
/* { dg-require-effective-target nonpic } */
or could e.g. use hidden visibility, or make the arrays static.
E.g.
--- gcc.dg/vect/vect-7.c(revision 219190)
+++ gcc.dg/vect/vect-7.c(working copy)
@@ -5,8 +5,8 @@
#define N 128
-short sa[N];
-short sb[N];
+static short sa[N];
+static short sb[N];
__attribute__ ((noinline))
int main1 ()
works fine for me. What other tests behave similarly?
[Bug c/64480] List designated initializer triggers -Wmissing-field-initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64480 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Yep, I bet it's the same bug. I'm slightly nervous about backporting that fix to 4.8/4.9 branches though.
[Bug c/64480] List designated initializer triggers -Wmissing-field-initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64480 --- Comment #1 from joseph at codesourcery dot com --- I don't see this with trunk - maybe the same as bug 60784?
[Bug target/64061] [5 Regression] ICE: in gen_rtx_SUBREG, at emit-rtl.c:894 with -O2 -g -fno-dce -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64061 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Assuming fixed.
[Bug c++/64489] A simple struct wrapping a const int is not trivially copyable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64489 Ville Voutilainen changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com --- Comment #1 from Ville Voutilainen --- I'll take a look at fixing this. :)
[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64465 Jakub Jelinek changed: What|Removed |Added Attachment #34377|0 |1 is obsolete|| --- Comment #5 from Jakub Jelinek --- Created attachment 34379 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34379&action=edit gcc5-pr64465.patch Updated patch that works on this testcase. From the cgraph.c comments, it looks like e.g. during function versioning we rely on fixup_cfg to fix it up, but during inlining I think we need to do it immediately. TODO_cleanup_cfg is on during inlining.
[Bug ipa/64472] FAIL: gcc.dg/ipa/inline-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64472 --- Comment #4 from Jan Hubicka --- I think marking it inline is best fix: with static the inliner may get smart rnough to consider it used once. Honza
[Bug ada/64492] Disabling libada prevents building gnattools-cross
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64492 --- Comment #13 from simon at pushface dot org --- (In reply to Luke A. Guest from comment #2) > But, I noticed this in the gnat makefile a while back and was going to > investigate, but haven't got around to it yet: > > # *-elf, *-eabi, or *-eabispe > ifeq ($(strip $(filter-out elf eabi eabispe,$(target_os))),) > TOOLS_TARGET_PAIRS=\ > mlib-tgt-specific.adb indepsw.adb endif > > Essentially, we just need for that to include a specific system or build > with just those two files and it's sorted. TOOLS_TARGET_PAIRS is set in both gnattools/Makefile (when it has been configured) and gcc/ada/gcc-interface/Makefile.in. Your patch is to the gnattools/ one, the gcc-interface one already has this pair. If it is the case that any arm-*-eabi target is going to be a bare runtime target, with --disable-libada disabling gnattools/, then Eric’s patch and Arno’s incantation will IMO work - I just built GCC 5 arm-eabi with Eric’s patch and the two files were successfully copied into build/gcc/ada/tools, and arm-eabi-gnatmake is capable of building a library. Haven’t checked the map feature yet. Looking at the two versions of TOOLS_TARGET_PAIRS, it seems that gcc-interface/Makefile is mainly concerned with building the RTS (LIBGNAT_TARGET_PAIRS etc) with the TOOLS_TARGET_PAIRS being left in place, pretty much as fossils, when building the tools was moved to gnattools/Makefile.
[Bug c++/64497] std::scalbln does not round correctly for long doubles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64497 --- Comment #4 from Jonathan Wakely --- Looking at the C standard, it seems that the result is implementation-defined on underflow, and zero is a valid result. C++ doesn't change that.
[Bug c++/64497] std::scalbln does not round correctly for long doubles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64497 --- Comment #3 from Jonathan Wakely --- (In reply to Walter Mascarenhas from comment #2) > What if there is a difference in the expected behavior > for this function in C and C++11? There isn't any difference, so it doesn't matter. > Is it not up to g++ > for implementing what is mandated in C++11? (This > is not a rhetorical question, I really do not know the answer.) Yes. > On the other hand, > http://en.cppreference.com/w/cpp/numeric/math/scalbn states that > > "If a range error due to underflow occurs, the correct result (after > rounding) is returned." The C++ standard doesn't say that. > I looked at the standard (N3797.pdf) but did not find anything > specific about std::scalbln. It says it is the same as C, so cppreference.com is wrong.
[Bug fortran/63922] Compiler error with OpenMP, default(none) and an integer parameter array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63922 John Donners changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #2 from John Donners --- I can confirm that this is solved in 4.9.2
[Bug ada/64492] Disabling libada prevents building gnattools-cross
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64492 --- Comment #12 from simon at pushface dot org --- (In reply to Eric Botcazou from comment #10) > This should work with Arno's incantation now. Confirmed. Thanks. I have to say, though, that configuring with --disable-libada --enable-cross-gnattools means you can just “make; make install” without any need for incantations!
[Bug c/64417] [SH] FAIL: gcc.c-torture/compile/pr28865.c -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64417
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek ---
I tend to agree. In other words,
struct foo { int x; char y[]; };
struct foo a1[] = { { 1, "a" } };
struct foo a2[] = { { 1, { "a" } } };
struct foo a3[] = { 1, "a" };
struct foo b1[] = { { 1, { 'a', '\0' } } };
struct foo b2[] = { 1, { 'a', '\0' } };
We reject b1 and b2, but should also reject a[123].
[Bug c++/64500] New: push_to_top_level() shows up high during Chromium build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64500 Bug ID: 64500 Summary: push_to_top_level() shows up high during Chromium build. Product: gcc Version: 5.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, marxin at gcc dot gnu.org Created attachment 34378 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34378&action=edit unreduced testcase Running "perf top" during Chromium build shows that push_to_top_level() is in the 8-12% range. This is an older issue, because it already happens for 4.8.4. Here is an example: markus@x4 Release % perf record c++ -std=gnu++11 -O2 -c InspectorCSSAgent.ii [ perf record: Woken up 6 times to write data ] [ perf record: Captured and wrote 1.275 MB perf.data (~55717 samples) ] markus@x4 Release % perf report 8.01% cc1plus cc1plus [.] push_to_top_level 4.23% cc1plus cc1plus [.] gt_ggc_mx_lang_tree_node 2.13% cc1plus cc1plus [.] ggc_set_mark 1.98% cc1plus cc1plus [.] lookup_page_table_entry 1.75% cc1plus libc-2.19.90.so [.] _int_malloc 1.61% cc1plus cc1plus [.] ggc_internal_alloc 1.57% cc1plus cc1plus [.] lookup_field_r
[Bug other/64499] New: -gsplit-dwarf splits objcopy argument at spaces in file path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64499 Bug ID: 64499 Summary: -gsplit-dwarf splits objcopy argument at spaces in file path Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: jlegg at feralinteractive dot com If using -gsplit-dwarf and outputting an object file in a path containing spaces, objcopy is invoked to copy the debug symbols to a dwo file, however the dwo file path is split into multiple arguments at the spaces. Here is a minimal test case that compiles an empty file: $ gcc -v -gsplit-dwarf -x c -c /dev/null -o "o .o" Using built-in specs. COLLECT_GCC=gcc Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.9.2-20141101/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.9.2-20141101/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC) COLLECT_GCC_OPTIONS='-v' '-gsplit-dwarf' '-c' '-o' 'o .o' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-redhat-linux/4.9.2/cc1 -quiet -v /dev/null -quiet -dumpbase null -mtune=generic -march=x86-64 -auxbase-strip o .o -gsplit-dwarf -version -o /tmp/ccUMU7DF.s GNU C (GCC) version 4.9.2 20141101 (Red Hat 4.9.2-1) (x86_64-redhat-linux) compiled by GNU C version 4.9.2 20141101 (Red Hat 4.9.2-1), GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include-fixed" ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../x86_64-redhat-linux/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include /usr/local/include /usr/include End of search list. GNU C (GCC) version 4.9.2 20141101 (Red Hat 4.9.2-1) (x86_64-redhat-linux) compiled by GNU C version 4.9.2 20141101 (Red Hat 4.9.2-1), GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 03cfec3867418ce243292e9ba51d447c COLLECT_GCC_OPTIONS='-v' '-gsplit-dwarf' '-c' '-o' 'o .o' '-mtune=generic' '-march=x86-64' as -v --64 -o o .o /tmp/ccUMU7DF.s GNU assembler version 2.24 (x86_64-redhat-linux) using BFD version version 2.24 COLLECT_GCC_OPTIONS='-v' '-gsplit-dwarf' '-c' '-o' 'o .o' '-mtune=generic' '-march=x86-64' objcopy --extract-dwo o .o o .dwo Usage: objcopy [option(s)] in-file [out-file] Copies a binary file, possibly transforming it in the process The options are: I've cut off the rest of objcopy's usage output. The command line arguments to objcopy in this example are 0) /usr/bin/objcopy 1) --extract-dwo 2) o .o 3) o 4) .dwo Arguments 3 and 4 should be one argument, o .dwo.
[Bug c++/64497] std::scalbln does not round correctly for long doubles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64497
--- Comment #2 from Walter Mascarenhas ---
What if there is a difference in the expected behavior
for this function in C and C++11? Is it not up to g++
for implementing what is mandated in C++11? (This
is not a rhetorical question, I really do not know the answer.)
In http://man7.org/linux/man-pages/man3/scalbn.3.html it
is written that scalbln should return 0 in case of underflow:
"If the result underflows, a range error occurs, and the functions
return zero, with a sign the same as *x*."
On the other hand,
http://en.cppreference.com/w/cpp/numeric/math/scalbn states that
"If a range error due to underflow occurs, the correct result (after
rounding) is returned."
I looked at the standard (N3797.pdf) but did not find anything
specific about std::scalbln.
If there is indeed a discrepancy in the definitions of scalbln in C
and C++11 then there
may be no bug in libm, and my vendor will not change it.
I do not have a copy of the ISO 60599 standard, and I do not know whether
the content of the pages http://man7.org/linux/man-pages/man3/scalbn.3.html and
http://en.cppreference.com/w/cpp/numeric/math/scalbn are compatible with
any standards. Therefore I am in no position to argue,
but maybe you could think a bit longer about this..
On Mon, Jan 5, 2015 at 10:29 AM, redi at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64497
>
> --- Comment #1 from Jonathan Wakely ---
> GCC just calls the scalnlnl() function in libm, so it's not a GCC bug, and
> is
> not specific to C++ either. I suggest you report it to your libc vendor.
>
> Complete testcase in C:
>
> #include
> #include
> #include
>
> int main()
> {
> long double di = scalbnl(1.1L, -16446);
> assert( di != 0.0L );
> long double dl = scalblnl(1.1L, -16446L);
> assert( dl != 0.0L );
> }
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You reported the bug.
>
[Bug c++/64497] std::scalbln does not round correctly for long doubles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64497
--- Comment #1 from Jonathan Wakely ---
GCC just calls the scalnlnl() function in libm, so it's not a GCC bug, and is
not specific to C++ either. I suggest you report it to your libc vendor.
Complete testcase in C:
#include
#include
#include
int main()
{
long double di = scalbnl(1.1L, -16446);
assert( di != 0.0L );
long double dl = scalblnl(1.1L, -16446L);
assert( dl != 0.0L );
}
[Bug middle-end/64448] New middle-end pattern breaks vector BIF folding on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64448 --- Comment #1 from Marek Polacek --- Looks like something for combine?
[Bug c/64423] Incorrect column number of -Wchar-subscripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64423 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug c/64423] Incorrect column number of -Wchar-subscripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64423 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Mon Jan 5 12:03:57 2015 New Revision: 219186 URL: https://gcc.gnu.org/viewcvs?rev=219186&root=gcc&view=rev Log: PR c/64423 c-family/ * c-common.c (warn_array_subscript_with_type_char): Add location_t parameter. Use it. * c-common.h (warn_array_subscript_with_type_char): Update declaration. c/ * c-typeck.c (build_array_ref): Pass loc down to warn_array_subscript_with_type_char. cp/ * typeck.c (cp_build_array_ref): Pass loc down to warn_array_subscript_with_type_char. testsuite/ * gcc.dg/pr64423.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr64423.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-common.h trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64465 --- Comment #4 from Jakub Jelinek --- Created attachment 34377 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34377&action=edit non-working patch (at least contains reduced testcase) For some reason this doesn't work :(.
[Bug ada/64492] Disabling libada prevents building gnattools-cross
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64492 --- Comment #11 from Luke A. Guest --- (In reply to simon from comment #5) > (In reply to Luke A. Guest from comment #2) > > But, I noticed this in the gnat makefile a while back and was going to > > investigate, but haven't got around to it yet: > > > > # *-elf, *-eabi, or *-eabispe > > ifeq ($(strip $(filter-out elf eabi eabispe,$(target_os))),) > > TOOLS_TARGET_PAIRS=\ > > mlib-tgt-specific.adb > indepsw.adb > endif > > > > Essentially, we just need for that to include a specific system or build > > with just those two files and it's sorted. > > I agree that, for some reason, this tools target pair is not actioned for > target arm-eabi. Perhaps there should be another PR? > No, in my patch above, you only have part of the patch, the second part adds the necessary lines in the gnattools/configure script to enable them correctly including lib support. Without that it shouldn't even build but if it does by some miracle it will use defaults which are very basic. > The effect is that arm-eabi-gnatmake is unable to build libraries on this > platform. However, gprbuild is OK. I always use gprbuild when building > libraries because it does a much better job, and is necessary when building > Darwin dylibs. > > I understand (can’t remember where from) that AdaCore intend to remove the > ability of gnatmake to build libraries for any target in future releases. If > this is true, I think it would be regrettable, since gprbuild isn’t part of > GCC (it does have copyright assignment to FSF, though). GCC 5 is still OK. Well that's a stupid idea,
[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64465
--- Comment #3 from Jakub Jelinek ---
I get the same ICE as H.J., and the bug is that redirect_all_calls
redirects a call to __builtin_unreachable , before it was
_10 = __open_alias (__path_6(D), __oflag_3(D), __builtin_va_arg_pack ());
and afterwards
__builtin_unreachable ("/dev/null", 3);
(note, again there is the bug that the extra arguments aren't dropped).
[Bug middle-end/64498] New: [5 Regression] Cannot build Firefox with LTO: ICE in substitute_and_fold_dom_walker::before_dom_children
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64498 Bug ID: 64498 Summary: [5 Regression] Cannot build Firefox with LTO: ICE in substitute_and_fold_dom_walker::before_dom_children Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: markus at trippelsdorf dot net Hello. With gcc version 5.0.0 20150105 (experimental) (GCC) and latest master branch of Firefox, compiled with -O2 and -flto, I see following problem in a ltrans: /home/marxin/Programming/gecko-dev/js/src/builtin/Intl.cpp: In function ‘NewUDateFormat’: /home/marxin/Programming/gecko-dev/js/src/builtin/Intl.cpp:1840:0: internal compiler error: Segmentation fault NewUDateFormat(JSContext *cx, HandleObject dateTimeFormat) ^ 0x8de73f crash_signal ../../gcc/toplev.c:359 0x98feab gimple_code ../../gcc/gimple.h:1545 0x98feab gimple_nop_p ../../gcc/gimple.h:5589 0x98feab get_default_value ../../gcc/tree-ssa-ccp.c:291 0x98feab get_value ../../gcc/tree-ssa-ccp.c:365 0x98feab get_constant_value ../../gcc/tree-ssa-ccp.c:384 0xa0556d replace_uses_in ../../gcc/tree-ssa-propagate.c:948 0xa0556d substitute_and_fold_dom_walker::before_dom_children(basic_block_def*) ../../gcc/tree-ssa-propagate.c:1151 0xdf4022 dom_walker::walk(basic_block_def*) ../../gcc/domwalk.c:188 0xa05030 substitute_and_fold(tree_node* (*)(tree_node*), bool (*)(gimple_stmt_iterator*), bool) ../../gcc/tree-ssa-propagate.c:1230 0x990cb0 ccp_finalize ../../gcc/tree-ssa-ccp.c:934 0x990cb0 do_ssa_ccp ../../gcc/tree-ssa-ccp.c:2374 0x990cb0 execute ../../gcc/tree-ssa-ccp.c:2406 Where: #0 0x00bb4950 in gimple_code (g=0x0) at ../../gcc/gimple.h:1545 #1 0x00bb52cc in gimple_nop_p (g=0x0) at ../../gcc/gimple.h:5589 #2 0x00bb6350 in get_default_value (var=0x7fffe5d24870) at ../../gcc/tree-ssa-ccp.c:291 #3 0x00bb6620 in get_value (var=0x7fffe5d24870) at ../../gcc/tree-ssa-ccp.c:365 #4 0x00bb66b7 in get_constant_value (var=0x7fffe5d24870) at ../../gcc/tree-ssa-ccp.c:384 #5 0x00c48d5e in replace_uses_in (stmt=0x7fffe5d116c0, get_value=0xbb666e ) at ../../gcc/tree-ssa-propagate.c:948 #6 0x00c49484 in substitute_and_fold_dom_walker::before_dom_children (this=0x7fffd430, bb=0x7fffe5d02750) at ../../gcc/tree-ssa-propagate.c:1151 #7 0x0108d113 in dom_walker::walk (this=0x7fffd430, bb=0x7fffe5d02750) at ../../gcc/domwalk.c:188 #8 0x00c4975a in substitute_and_fold (get_value_fn=0xbb666e , fold_fn=0xbbc57c , do_dce=true) at ../../gcc/tree-ssa-propagate.c:1230 #9 0x00bb7c20 in ccp_finalize () at ../../gcc/tree-ssa-ccp.c:934 #10 0x00bbd0a2 in do_ssa_ccp () at ../../gcc/tree-ssa-ccp.c:2374 #11 0x00bbd155 in (anonymous namespace)::pass_ccp::execute (this=0x1b68c40) at ../../gcc/tree-ssa-ccp.c:2406 #12 0x00a1bbb2 in execute_one_pass (pass=0x1b68c40) at ../../gcc/passes.c:2311 #13 0x00a1bdec in execute_pass_list_1 (pass=0x1b68c40) at ../../gcc/passes.c:2363 #14 0x00a1be1d in execute_pass_list_1 (pass=0x1b67ec0) at ../../gcc/passes.c:2364 #15 0x00a1be5a in execute_pass_list (fn=0x7fffe6a37c78, pass=0x1b67e00) at ../../gcc/passes.c:2374 #16 0x00745a2c in cgraph_node::expand (this=0x76a64930) at ../../gcc/cgraphunit.c:1798 #17 0x00745ecb in expand_all_functions () at ../../gcc/cgraphunit.c:1934 #18 0x00746938 in symbol_table::compile (this=0x76c3a000) at ../../gcc/cgraphunit.c:2284 #19 0x006b154c in lto_main () at ../../gcc/lto/lto.c:3446 #20 0x00ac3b8c in compile_file () at ../../gcc/toplev.c:570 #21 0x00ac5f48 in do_compile () at ../../gcc/toplev.c:2018 #22 0x00ac6152 in toplev::main (this=0x7fffd7cf, argc=36, argv=0x7fffd8c8) at ../../gcc/toplev.c:2115 #23 0x0067afc9 in main (argc=36, argv=0x7fffd8c8) at ../../gcc/main.c:38 in #2: (gdb) call debug_tree(var) in #5: (gdb) call debug_gimple_stmt(stmt) # DEBUG code => _578 Unfortunately, problem is in a LTRANS and it's hard to reduce a testcase. Was there any recent change in CCP? If needed, I can provide dumps. Thanks, Martin
[Bug c++/64497] New: std::scalbln does not round correctly for long doubles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64497 Bug ID: 64497 Summary: std::scalbln does not round correctly for long doubles Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: walter.mascarenhas at gmail dot com The overload std::scalbln(long double, long) may not round the result correctly when the exponent is very small. For instance, with round mode = near, std::scalbln(1.1L, -16446) returns 0, whereas std::scalbn(1.1L, -16446) and std::ldexp(1.1L, -16446) return std::numeric_limits::denorm_min(), which I believe is the correct result.
[Bug target/63304] Aarch64 pc-relative load offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304 --- Comment #12 from David Abdurachmanov --- I decided to re-enable -Os for OpenLoops. Then use powerful hardware with 32-physical-cores (x86_64) and 0.5TB of RAM to see if I could get lucky. Fired up QEMU user mode with Fedora for AArch64 chroot for compiling. It did resolve some of failures, but not everything. I have seen processes going as far as 25+GB of RSS and taking hours to finish. This is the reason package is compiled with -O0.
[Bug ada/64492] Disabling libada prevents building gnattools-cross
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64492 Eric Botcazou changed: What|Removed |Added Status|REOPENED|RESOLVED Version|4.9.1 |4.9.3 Resolution|--- |FIXED --- Comment #10 from Eric Botcazou --- This should work with Arno's incantation now.
[Bug ada/64492] Disabling libada prevents building gnattools-cross
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64492 --- Comment #8 from Eric Botcazou --- Author: ebotcazou Date: Mon Jan 5 10:17:12 2015 New Revision: 219183 URL: https://gcc.gnu.org/viewcvs?rev=219183&root=gcc&view=rev Log: PR ada/64492 * gcc-interface/Makefile.in (../stamp-tools): Reinstate dropped code. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Makefile.in
[Bug ada/64492] Disabling libada prevents building gnattools-cross
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64492 --- Comment #9 from Eric Botcazou --- Author: ebotcazou Date: Mon Jan 5 10:17:28 2015 New Revision: 219184 URL: https://gcc.gnu.org/viewcvs?rev=219184&root=gcc&view=rev Log: PR ada/64492 * gcc-interface/Makefile.in (../stamp-tools): Reinstate dropped code Modified: branches/gcc-4_9-branch/gcc/ada/ChangeLog branches/gcc-4_9-branch/gcc/ada/gcc-interface/Makefile.in
[Bug middle-end/64182] wide-int rounding division is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64182 Jakub Jelinek changed: What|Removed |Added Summary|[5 Regression] wide-int |wide-int rounding division |rounding division is broken |is broken --- Comment #11 from Jakub Jelinek --- I think fixed on the trunk, but likely the double-int.c fix has not been backported to release branches.
[Bug c++/64496] [4.8/4.9/5 Regression] ICE with NSDMI and lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64496 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-05 Target Milestone|--- |4.8.5 Ever confirmed|0 |1
[Bug c++/64496] New: [4.8/4.9/5 Regression] ICE with NSDMI and lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64496
Bug ID: 64496
Summary: [4.8/4.9/5 Regression] ICE with NSDMI and lambda
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: jason at gcc dot gnu.org
template class B;
template
struct B { template B(F); };
template
template
B::B(F) {}
int
main()
{
int a;
struct A
{
B l = [=] { a; };
};
A t;
}
ICEs with -std=c++0x starting with r179155.
[Bug middle-end/64353] [5 Regression] ICE: in execute_todo, at passes.c:1986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64353 Jakub Jelinek changed: What|Removed |Added CC||ienkovich at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with r217125.
[Bug target/64411] ICE: in verify_target_availability, at sel-sched.c:1577 with -Os -mcmodel=medium -fPIC -fschedule-insns -fselective-scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64411 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-05 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.8.5 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/64487] [4.8/4.9/5 Regression] internal compiler error: in fold_offsetof_1, at c-family/c-common.c:9857
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64487 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Summary|internal compiler error: in |[4.8/4.9/5 Regression] |fold_offsetof_1, at |internal compiler error: in |c-family/c-common.c:9857|fold_offsetof_1, at ||c-family/c-common.c:9857 --- Comment #2 from Jakub Jelinek --- Started with r156865.
[Bug tree-optimization/64494] [5 Regression] ICE at -Os and above on x86_64-linux-gnu in duplicate_ssa_name_range_info, at tree-ssanames.c:499
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64494 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 34376 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34376&action=edit gcc5-pr64494.patch Untested fix.
[Bug middle-end/64415] [5 Regression] ICE: verify_ssa failed / segmentation fault with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64415 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-05 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/64487] internal compiler error: in fold_offsetof_1, at c-family/c-common.c:9857
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64487 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-05 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed. fold_offsetof_1 gets C++-specific ARROW_EXPR and is upset about that.
[Bug tree-optimization/64495] [4.8/4.9/5 Regression] ICE at -O3 for trunk and wrong code for 4.8/4.9 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64495 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- This one started with r195609.
[Bug tree-optimization/64493] [4.8/4.9/5 Regression] ICE at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64493
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-01-05
CC||jakub at gcc dot gnu.org
Target Milestone|--- |4.8.5
Summary|ICE at -O3 on |[4.8/4.9/5 Regression] ICE
|x86_64-linux-gnu|at -O3 on x86_64-linux-gnu
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
To avoid the #include, I've used
int a, b, c, d, e, f, g, h;
int
main ()
{
for (; a; a--)
for (d = 1; d <= 0; d++)
for (; d;)
if (h)
{
if (!g) __builtin_abort ();
if (!0) __builtin_abort ();
}
for (f = 4; f; f--)
{
for (b = 0; b < 2; b++)
c |= 1;
e |= c;
}
return 0;
}
and that started to ICE with r181990.
[Bug ada/64492] Disabling libada prevents building gnattools-cross
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64492 --- Comment #6 from simon at pushface dot org --- (In reply to Eric Botcazou from comment #4) > Correction: some bits were incorrectly removed from > gcc-interface/Makefile.in. Do you mean the parts where the creation and population of gcc/ada/tools has been migrated to gnattools/Makefile?
Re: [Bug ada/64492] New: Disabling libada prevents building gnattools-cross
> Unfortunately you can???t build the cross gnattools, because > --disable-libada > adds gnattools to the list of unconfigured directories, which means that > the > directory gcc/ada/tools is never created, let alone populated. > gcc/ada/gcc-interface/Makefile.in touches stamp-tools, but that???s > all. You can actually. The way to build gnattools when using --disable-libada is to do: obj $ make -C gcc cross-gnattools ada.all.cross Arno
[Bug ada/64492] Disabling libada prevents building gnattools-cross
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64492 --- Comment #7 from charlet at adacore dot com --- > Unfortunately you can???t build the cross gnattools, because > --disable-libada > adds gnattools to the list of unconfigured directories, which means that > the > directory gcc/ada/tools is never created, let alone populated. > gcc/ada/gcc-interface/Makefile.in touches stamp-tools, but that???s > all. You can actually. The way to build gnattools when using --disable-libada is to do: obj $ make -C gcc cross-gnattools ada.all.cross Arno
[Bug tree-optimization/64495] [4.8/4.9/5 Regression] ICE at -O3 for trunk and wrong code for 4.8/4.9 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64495 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-05 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.8.5 Summary|ICE at -O3 for trunk and|[4.8/4.9/5 Regression] ICE |wrong code for 4.8/4.9 on |at -O3 for trunk and wrong |x86_64-linux-gnu|code for 4.8/4.9 on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed. I get an ICE with this testcase even with 4.8/4.9 (with checking enabled).
[Bug ada/64492] Disabling libada prevents building gnattools-cross
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64492 --- Comment #5 from simon at pushface dot org --- (In reply to Luke A. Guest from comment #2) > But, I noticed this in the gnat makefile a while back and was going to > investigate, but haven't got around to it yet: > > # *-elf, *-eabi, or *-eabispe > ifeq ($(strip $(filter-out elf eabi eabispe,$(target_os))),) > TOOLS_TARGET_PAIRS=\ > mlib-tgt-specific.adb indepsw.adb endif > > Essentially, we just need for that to include a specific system or build > with just those two files and it's sorted. I agree that, for some reason, this tools target pair is not actioned for target arm-eabi. Perhaps there should be another PR? The effect is that arm-eabi-gnatmake is unable to build libraries on this platform. However, gprbuild is OK. I always use gprbuild when building libraries because it does a much better job, and is necessary when building Darwin dylibs. I understand (can’t remember where from) that AdaCore intend to remove the ability of gnatmake to build libraries for any target in future releases. If this is true, I think it would be regrettable, since gprbuild isn’t part of GCC (it does have copyright assignment to FSF, though). GCC 5 is still OK.
[Bug ada/64492] Disabling libada prevents building gnattools-cross
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64492 Eric Botcazou changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2015-01-05 Resolution|WORKSFORME |--- Ever confirmed|0 |1 --- Comment #4 from Eric Botcazou --- Correction: some bits were incorrectly removed from gcc-interface/Makefile.in.
[Bug ada/64492] Disabling libada prevents building gnattools-cross
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64492 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #3 from Eric Botcazou --- If you configure with --disable-libada, you should be able to build the tools with "make -C gcc cross-gnattools" after manually building the RTS and touching gcc/ada/stamp-gnatlib-rts.
[Bug tree-optimization/64494] [5 Regression] ICE at -Os and above on x86_64-linux-gnu in duplicate_ssa_name_range_info, at tree-ssanames.c:499
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64494 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-05 CC||jakub at gcc dot gnu.org Target Milestone|--- |5.0 Summary|ICE at -Os and above on |[5 Regression] ICE at -Os |x86_64-linux-gnu in |and above on |duplicate_ssa_name_range_in |x86_64-linux-gnu in |fo, at tree-ssanames.c:499 |duplicate_ssa_name_range_in ||fo, at tree-ssanames.c:499 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r218580.
[Bug middle-end/64457] NVCC like features CUDA/OpenCL support for GCC to use GPU's to speed up compile jobs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64457 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Only OpenACC offloading to nvptx is in latest stages before merge (hopefully it will merge into trunk in the first half of January), OpenMP offloading to nvptx will need some further work. But yeah, I think OpenMP or OpenACC is preferrable over CUDA here, which is by design specific to a single hw implementation.
