[Bug fortran/37131] inline matmul for small matrix sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #26 from Andreas Schwab sch...@linux-m68k.org --- *** Bug 65981 has been marked as a duplicate of this bug. ***
[Bug libstdc++/65861] libstdc++ is silently generating wrong code when its std::search is given an input iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65861 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org --- There are actually good reasons *not* to reject input iterators at compile-time. You could have an iterator which meets most, but not all, the forward iterator requirements, and so must have input_iterator_tag as its category. Such as iterator could work fine with std::search, if we don't reject it via a static assertion. (istreambuf_iterator is not such an iterator, as it's genuinely a single-pass iterator, and so can't be used ... but we can't reliably detect that as the only property we can test is the iterator_category tag).
[Bug fortran/65975] !$ is not recognized as a comment when -fopenmp flag is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65975 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- GCC is correct. See e.g. OpenMP 4.0, section 2.2 Conditional Compilation chapter (or similar chapter in older OpenMP versions). !$ in free form and !$ *$ c* in fixed form are replaced by two spaces if the various conditions mentioned in Conditional Compilation chapter are met and OpenMP support is enabled.
[Bug fortran/65981] FAIL: gfortran.dg/bound_9.f90 -O execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65981 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- Probably invalid Fortran. *** This bug has been marked as a duplicate of bug 37131 ***
[Bug c++/65977] New: Constexpr should be allowed in declaration of friend template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65977
Bug ID: 65977
Summary: Constexpr should be allowed in declaration of friend
template specialization
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rhalbersma at gmail dot com
Target Milestone: ---
The following code comes from this StackOverflow QA (note this is not related
to std::bitset, it's just a homegrown class to experiment with constexpr):
http://stackoverflow.com/q/29871138/819272
#include cstddef
templatestd::size_t
class bitset;
templatestd::size_t N
constexpr bool operator==(const bitsetN, const bitsetN) noexcept;
templatestd::size_t N
class bitset
{
friend constexpr bool operator== (const bitsetN, const bitsetN)
noexcept;
//^ -- error from this piece
};
templatestd::size_t N
constexpr bool operator==(const bitsetN, const bitsetN) noexcept
{
return true;
}
int main() {}
The error I get with -std=c++11 on gcc 4.9.1 through gcc HEAD 6.0.0 20150501 is
'constexpr' is not allowed in declaration of friend template specialization
The same code on older gcc version (4.6 through 4.8) gives a slightly different
error
'inline' is not allowed in declaration of friend template specialization
which seems to have been introduced in 2013
https://gcc.gnu.org/ml/gcc-patches/2013-03/msg01028.html
Richard Smith's accepted answer on StackOverflow (
http://stackoverflow.com/a/29957648/819272 ) states that although constexpr
functions are implicitly inline, an inline function does not imply the inline
specifier. Therefore the above code should be valid.
[Bug libstdc++/65978] New: missing constexpr on std::forward_as_tuple and std::tie (LWG issues 2275 and 2301)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65978 Bug ID: 65978 Summary: missing constexpr on std::forward_as_tuple and std::tie (LWG issues 2275 and 2301) Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rhalbersma at gmail dot com Target Milestone: --- Neither libstdc++ 5.1.0 nor the trunk version implement LWG defect reports 2275 and 2301 that make std::tuple utilities std::forward_as_tuple and std::tie constexpr http://wg21.cmeerw.net/lwg/issue2275 http://wg21.cmeerw.net/lwg/issue2301 Both of these have been implemented in libc++ for a while now: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131007/090369.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140224/099936.html Since both resolutions only require C++11 style constexpr support, they could also be backported to earlier versions in -std=c++1y mode.
[Bug c++/65973] segmentation fault when compiling C++14 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65973
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-05-02
CC||trippels at gcc dot gnu.org
Summary|Current gcc 6 snapshot |segmentation fault when
|fails with segmentation |compiling C++14 code
|fault when compiling C++14 |
|code|
Ever confirmed|0 |1
Known to fail||5.1.0, 6.0
Severity|blocker |normal
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 tmp % cat test.ii
class foo {
constexpr foo() noexcept { __PRETTY_FUNCTION__; };
};
markus@x4 tmp % g++ -c -std=c++14 test.ii
test.ii: In constructor ‘constexpr foo::foo()’:
test.ii:2:51: internal compiler error: Segmentation fault
constexpr foo() noexcept { __PRETTY_FUNCTION__; };
^
0xc834af crash_signal
../../gcc/gcc/toplev.c:380
0x7c6cf4 tsi_stmt
../../gcc/gcc/tree-iterator.h:92
0x7c6cf4 build_constexpr_constructor_member_initializers
../../gcc/gcc/cp/constexpr.c:550
0x7c6cf4 massage_constexpr_body
../../gcc/gcc/cp/constexpr.c:680
0x7d0a7b register_constexpr_fundef(tree_node*, tree_node*)
../../gcc/gcc/cp/constexpr.c:783
0x5fa005 maybe_save_function_definition
../../gcc/gcc/cp/decl.c:14110
0x5fa005 finish_function(int)
../../gcc/gcc/cp/decl.c:14234
0x6e91b9 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:23473
0x6ec82c cp_parser_late_parsing_for_member
../../gcc/gcc/cp/parser.c:24150
0x6c7901 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:20041
0x6c7901 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:20067
0x6c7901 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14707
0x6dac5f cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11938
0x6ebf71 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11515
0x6e5b73 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11462
0x6efac9 cp_parser_declaration
../../gcc/gcc/cp/parser.c:11359
0x6ee15a cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:11245
0x6ee46f cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4107
0x6ee46f c_parse_file()
../../gcc/gcc/cp/parser.c:33173
0x826152 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1057
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.
[Bug c/65958] -fstack-check breaks alloca on architectures using generic stack checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65958 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Two things to do here: 1) switch ARM to modern stack-checking and 2) fix the underlying issue with alloca and VLAs.
[Bug target/65979] New: internal compiler error: in make_edges, at tree-cfg.c:923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 Bug ID: 65979 Summary: internal compiler error: in make_edges, at tree-cfg.c:923 Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de Target Milestone: --- Host: sh4-linux-gnu Target: sh*-*-* Created attachment 35440 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35440action=edit Full build log for gcc-5 on sh4-linux-gnu (gzip-compressed) Hello! gcc-5 has hit Debian now and I had my first go at attempting to build it on sh4. Unfortunately, the build fails at some point with the following error: configure:3467: $? = 1 configure:3655: checking for suffix of object files configure:3677: /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/lib/ -isystem /usr/sh4-linux -gnu/include -isystem /usr/sh4-linux-gnu/sys-include -isystem /«PKGBUILDDIR»/build/sys-include-c -g -O2 conftest.c 5 conftest.c: In function 'main': conftest.c:11:1: internal compiler error: in make_edges, at tree-cfg.c:923 main () ^ Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-5/README.Bugs for instructions. Preprocessed source stored into /tmp/ccrZ8ce7.out file, please attach this to your bugreport. Attaching the build log as well as the preprocessed source. As always, please ping me if you need more input. Cheers, Adrian
[Bug debug/65980] New: [6 Regression] -fcompare-debug building Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65980
Bug ID: 65980
Summary: [6 Regression] -fcompare-debug building Linux kernel
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
markus@x4 /tmp % cat qib_sdma.i
enum qib_sdma_events { qib_sdma_event_e40_sw_cleaned } fn3();
enum qib_sdma_events a;
int b;
int fn1() {
asm goto(.pushsection .smp_locks\a\\n.balign 4\n.long
.\n.popsection\n671:\n\tlock subl %1,0; je %l[cc_label]
:
: (0)
:
: cc_label);
return 0;
cc_label:
return 1;
}
static inline int fn2(void p1()) {
if (fn1()) {
p1(0);
return 1;
}
return 0;
}
void fn4(enum qib_sdma_events p1) {
switch (b) {
case 0:
switch (p1)
case 1: {
void *c = fn3;
fn2(c);
}
switch (p1)
case 0: {
void *d = fn3;
fn2(d);
} break;
case 1: {
void *e = fn3;
fn2(e);
}
}
a = 0;
}
markus@x4 /tmp % gcc --save-temps -O2 -c -fcompare-debug qib_sdma.i
gcc: error: qib_sdma.i: -fcompare-debug failure (length)
markus@x4 /tmp % diff -u qib_sdma.gkd qib_sdma.gk.gkd
--- qib_sdma.gkd2015-05-02 11:16:58.224148129 +0200
+++ qib_sdma.gk.gkd 2015-05-02 11:16:58.257480705 +0200
@@ -122,7 +122,7 @@
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 5000 (nil)))
- 7)
-(code_label # 0 0 4 20 [2 uses])
+(code_label # 0 0 4 9 [2 uses])
(note # 0 0 [bb 4] NOTE_INSN_BASIC_BLOCK)
(jump_insn:TI # 0 0 4 (parallel [
(asm_operands/v (.pushsection .smp_locksa
@@ -228,7 +228,7 @@
(pc))) qib_sdma.i:25# {*jcc_1}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 2900 (nil)))
- - 20)
+ - 9)
(note # 0 0 [bb 8] NOTE_INSN_BASIC_BLOCK)
(insn:TI # 0 0 8 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:SI 5 di [orig:88 p1 ] [88])
@@ -242,7 +242,7 @@
(pc))) qib_sdma.i:30# {*jcc_1}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 4085 (nil)))
- - 20)
+ - 9)
(note # 0 0 [bb 9] NOTE_INSN_BASIC_BLOCK)
(insn:TI # 0 0 9 (set (mem/c:SI (symbol_ref:DI (a) [flags 0x2] var_decl #
a) [ a+0 S4 A32])
(const_int 0 [0])) qib_sdma.i:40# {*movsi_internal}
[Bug c/65958] -fstack-check breaks alloca on architectures using generic stack checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65958
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Target|arm |
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-05-02
CC||ebotcazou at gcc dot gnu.org
Target Milestone|--- |6.0
Summary|[arm] -fstack-check breaks |-fstack-check breaks alloca
|__builtin(alloca) |on architectures using
||generic stack checking
Ever confirmed|0 |1
--- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
Known issue with architectures doing stack-checking the old way like ARM, but
the underlying issue is more general and related to VLAs:
extern void abort (void);
int foo (int n)
{
char *p, *q;
if (1)
{
char i[n];
p = __builtin_alloca (8);
p[0] = 1;
}
q = __builtin_alloca (64);
__builtin_memset (q, 0, 64);
return !p[0];
}
int main (void)
{
if (foo (48) != 0)
abort ();
return 0;
}
fails on x86-64 because of it (with or without -fstack-check).
[Bug libstdc++/65978] missing constexpr on std::forward_as_tuple and std::tie (LWG issues 2275 and 2301)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65978 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Sat May 2 11:20:03 2015 New Revision: 222719 URL: https://gcc.gnu.org/viewcvs?rev=222719root=gccview=rev Log: PR libstdc++/65978 * include/std/tuple (forward_as_tuple, tie): Add constexpr. * testsuite/20_util/tuple/creation_functions/constexpr.cc: Uncomment and fix tests for forward_as_tuple and tie. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/tuple trunk/libstdc++-v3/testsuite/20_util/tuple/creation_functions/constexpr.cc
[Bug libstdc++/65978] missing constexpr on std::forward_as_tuple and std::tie (LWG issues 2275 and 2301)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65978 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-02 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed on trunk so far.
[Bug target/65979] internal compiler error: in make_edges, at tree-cfg.c:923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #1 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Created attachment 35441 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35441action=edit Preprocessed source files for gcc-5
[Bug fortran/65981] New: FAIL: gfortran.dg/bound_9.f90 -O execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65981 Bug ID: 65981 Summary: FAIL: gfortran.dg/bound_9.f90 -O execution test Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: tkoenig at gcc dot gnu.org Target Milestone: --- On Linux/x86, r222661 caused: FAIL: gfortran.dg/bound_9.f90 -O execution test
[Bug fortran/65975] !$ is not recognized as a comment when -fopenmp flag is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65975 --- Comment #3 from Carl Ponder CPonder at nVidia dot Com --- So the compiler is really complaining about the external qualifier here !$ external, logical:: omp_in_parallel right? Is this something not supported in gfortran?
[Bug target/65951] [AArch64] Will not vectorize 64bit integer multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65951 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Blocks||53947 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- ISTR there was some pattern support for division by constant so maybe you can add some for multiplication as well. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 Kazumoto Kojima kkojima at gcc dot gnu.org changed: What|Removed |Added CC||kkojima at gcc dot gnu.org --- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to John Paul Adrian Glaubitz from comment #1) Created attachment 35441 [details] Preprocessed source files for gcc-5 ccLfmF03.out ccrZ8ce7.out internal compiler error: in make_edges, at tree-cfg.c:923 Looks your build compiler has some wrong code problem. Perhaps reducing optimization level for the build compiler or changing the build compiler may help. cc13zIkw.out ccY9XfBa.out ccQG4ZY9.out ccln30GZ.out error: unable to find a register to spill in class 'R0_REGS' against some atomic constructs. Looks a known issue which unfortunately we have no solution with the current register allocator. You can try new register allocator with new -mlra option. AFAIK, new register allocator (LRA) doesn't cause this error. I can't see these failures on my cross builds of gcc-5, though. It could be a problem of the build compiler too.
[Bug ipa/65972] ICE after applying a patch to enable verify_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65972 --- Comment #1 from AK hiraditya at msn dot com --- PS: The bootstrap fails after applying this patch and emits the error reported above.
[Bug lto/65950] Loop is not vectorized with lto.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65950 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Do we eventually think the loop is cold?
[Bug libstdc++/17995] gcc-3.4.2/libstdc++-v3/libsupc++/eh_alloc.cc:34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17995 Cary Lewis cary.lewis at gmail dot com changed: What|Removed |Added CC||cary.lewis at gmail dot com --- Comment #12 from Cary Lewis cary.lewis at gmail dot com --- I know this is a very old bug, but I was wondering if anyone ever solved this issue? gcc-core builds fine on sco 5.0.7, but the I would like to be able to build a more modern version of the c++ compiler. The reality is that there are still a lot of SCO unix machines out there, and it should be possible to build g++ on them.
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
--- Comment #34 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Rainer Emrich from comment #30)
I'm testing the following instead:
Index: gcc/lto-wrapper.c
===
--- gcc/lto-wrapper.c (Revision 222611)
+++ gcc/lto-wrapper.c (Arbeitskopie)
@@ -934,12 +934,9 @@ run_gcc (unsigned argc, char *argv[])
filename[p - argv[i]] = '\0';
file_offset = (off_t) loffset;
}
- fd = open (argv[i], O_RDONLY);
+ fd = open (argv[i], O_RDONLY|O_BINARY);
if (fd == -1)
- {
- lto_argv[lto_argc++] = argv[i];
- continue;
- }
+ continue;
Note that passing filename instead of argv[i] is most certainly also good
(though I was trying to figure out if that's a separate issue or not).
if (find_and_merge_options (fd, file_offset, LTO_SECTION_NAME_PREFIX,
fdecoded_options, fdecoded_options_count,
[Bug lto/65982] New: [5/6 Regression] ICE: in lto_output_varpool_node, at lto-cgraph.c:623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65982
Bug ID: 65982
Summary: [5/6 Regression] ICE: in lto_output_varpool_node, at
lto-cgraph.c:623
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
Target Milestone: ---
markus@x4 tmp % cat proplist-util.i
static int a __attribute__ ((weakref (b)));
int c;
void
foo (void)
{
if (a)
c = 0;
}
markus@x4 tmp % gcc -shared -fPIC -flto -O2 proplist-util.i
lto1: internal compiler error: in lto_output_varpool_node, at lto-cgraph.c:623
0x8cc55e lto_output_varpool_node
../../gcc/gcc/lto-cgraph.c:623
0x8cc55e output_symtab()
../../gcc/gcc/lto-cgraph.c:1040
0x8d7f03 lto_output()
../../gcc/gcc/lto-streamer-out.c:2368
0x931c41 write_lto
../../gcc/gcc/passes.c:2395
0x9353d2 ipa_write_optimization_summaries(lto_symtab_encoder_d*)
../../gcc/gcc/passes.c:2599
0x5a94ba do_stream_out
../../gcc/gcc/lto/lto.c:2500
0x5aa2c2 stream_out
../../gcc/gcc/lto/lto.c:2544
0x5aa2c2 lto_wpa_write_files
../../gcc/gcc/lto/lto.c:2681
0x5b3dab do_whole_program_analysis
../../gcc/gcc/lto/lto.c:3362
0x5b3dab lto_main()
../../gcc/gcc/lto/lto.c:3489
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.
lto-wrapper: fatal error: /var/tmp/gcc_test/usr/local/bin/gcc returned 1 exit
status
compilation terminated.
/usr/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
[Bug fortran/65975] !$ is not recognized as a comment when -fopenmp flag is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65975 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- It is rejected the same way if you just type external, logical:: foobar end If you write instead external foobar logical:: foobar end it is accepted. I think Fortran95 would use INTERFACE instead (or MODULE), dunno where the external, type:: form would come from. CCing Tobias. !$ external omp_in_parallel !$ logical:: omp_in_parallel !$ external omp_get_thread_num !$ integer:: omp_get_thread_num or !$ include 'omp_lib.h' will work.
[Bug debug/65980] [6 Regression] -fcompare-debug failure building Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65980 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-02 CC||jakub at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r222360.
[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #4 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #3) I can't see these failures on my cross builds of gcc-5, though. It could be a problem of the build compiler too. Although I can't see them in my cross builds, I've confirmed that the given testcase fails with cross gcc-5 compilers and it doesn't fail with -mlra.
[Bug libstdc++/17995] gcc-3.4.2/libstdc++-v3/libsupc++/eh_alloc.cc:34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17995 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Cary Lewis from comment #12) gcc-core builds fine on sco 5.0.7, but the I would like to be able to build a more modern version of the c++ compiler. Try it, if it still fails then re-open this bug and provide the errors, I'll tak a look at it.
[Bug fortran/65976] gfortran man-page lists the -fno-fixed-form flag but does not define it, and it doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65976 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from kargl at gcc dot gnu.org --- Thanks for the bug report. Many of the -f* options have a negative form -fno-*. -ffixed-form happens to be one of the options that rejects the negative form.
[Bug fortran/65976] gfortran man-page lists the -fno-fixed-form flag but does not define it, and it doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65976 kargl at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.2
[Bug libstdc++/65641] unordered_map - __detail::_Mod_range_hashing is slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65641 --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org --- Currently, the only implemented policy uses primes from a hard-coded list for the number of buckets. This makes it easy to precompute (and hard-code in the library) anything that may be helpful to speed-up modulo computation. With a number of buckets that is a power of 2, modulo computation becomes trivial (masking). However, the simplistic specialization of std::hash for pointers in libstdc++ means that all double* hash to a multiple of 8. So we would need to add some scrambling somewhere to avoid leaving most buckets empty in unordered_setdouble*.
[Bug libstdc++/17995] gcc-3.4.2/libstdc++-v3/libsupc++/eh_alloc.cc:34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17995 --- Comment #16 from Cary Lewis cary.lewis at gmail dot com --- Sorry, here is the output of the command that generates the error during make bootstrap. I appreciate the help very much. Here is the configure command: ../gcc-3.4.3/configure --prefix=/usr/local/gcc-3.4.3x --enable-languages=c,c++ --with-gnu-as + cd /tmp/gcc-build/i686-pc-sco3.2v5.0.7/pic/libstdc++-v3/libsupc++ + /tmp/gcc-build/gcc/xgcc -save-temps -shared-libgcc -B/tmp/gcc-build/gcc/ -nostdinc++ -L/tmp/gcc-build/i686-pc-sco3.2v5.0.7/pic/libstdc++-v3/src -L/tmp/gcc-build/i686-pc-sco3.2v5.0.7/pic/libstdc++-v3/src/.libs -B/usr/local/gcc-3.4.3x/i686-pc-sco3.2v5.0.7/bin/ -B/usr/local/gcc-3.4.3x/i686-pc-sco3.2v5.0.7/lib/ -isystem /usr/local/gcc-3.4.3x/i686-pc-sco3.2v5.0.7/include -isystem /usr/local/gcc-3.4.3x/i686-pc-sco3.2v5.0.7/sys-include -fPIC -I/tmp/gcc-3.4.3/libstdc++-v3/../gcc -I/tmp/gcc-build/i686-pc-sco3.2v5.0.7/pic/libstdc++-v3/include/i686-pc-sco3.2v5.0.7 -I/tmp/gcc-build/i686-pc-sco3.2v5.0.7/pic/libstdc++-v3/include -I/tmp/gcc-3.4.3/libstdc++-v3/libsupc++ -O2 -g -O2 -g -O2 -fPIC -fno-implicit-templates -Wall -W -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -c ../../../../../gcc-3.4.3/libstdc++-v3/libsupc++/eh_alloc.cc -o eh_alloc.o In file included from ../../../../../gcc-3.4.3/libstdc++-v3/libsupc++/eh_alloc.cc:34: /tmp/gcc-build/i686-pc-sco3.2v5.0.7/pic/libstdc++-v3/include/cstring: In function `void* std::memchr(void*, int, size_t)': /tmp/gcc-build/i686-pc-sco3.2v5.0.7/pic/libstdc++-v3/include/cstring:101: error: `void* std::memchr(void*, int, size_t)' conflicts with previous using declaration `void* memchr(void*, int, size_t)' /tmp/gcc-build/i686-pc-sco3.2v5.0.7/pic/libstdc++-v3/include/cstring: In function `char* std::strchr(char*, int)': /tmp/gcc-build/i686-pc-sco3.2v5.0.7/pic/libstdc++-v3/include/cstring:107: error: `char* std::strchr(char*, int)' conflicts with previous using declaration `char* strchr(char*, int)' /tmp/gcc-build/i686-pc-sco3.2v5.0.7/pic/libstdc++-v3/include/cstring: In function `char* std::strpbrk(char*, const char*)': /tmp/gcc-build/i686-pc-sco3.2v5.0.7/pic/libstdc++-v3/include/cstring:113: error: `char* std::strpbrk(char*, const char*)' conflicts with previous using declaration `char* strpbrk(char*, const char*)' /tmp/gcc-build/i686-pc-sco3.2v5.0.7/pic/libstdc++-v3/include/cstring: In function `char* std::strrchr(char*, int)': /tmp/gcc-build/i686-pc-sco3.2v5.0.7/pic/libstdc++-v3/include/cstring:119: error: `char* std::strrchr(char*, int)' conflicts with previous using declaration `char* strrchr(char*, int)' /tmp/gcc-build/i686-pc-sco3.2v5.0.7/pic/libstdc++-v3/include/cstring: In function `char* std::strstr(char*, const char*)': /tmp/gcc-build/i686-pc-sco3.2v5.0.7/pic/libstdc++-v3/include/cstring:125: error: `char* std::strstr(char*, const char*)' conflicts with previous using declaration `char* strstr(char*, const char*)' There are commands in the include files that attempt to undef the various c defines, but undef won't undo a function prototype. Let me know if there any any tests you want me to perform.
[Bug fortran/65976] gfortran man-page lists the -fno-fixed-form flag but does not define it, and it doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65976 --- Comment #1 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat May 2 16:37:35 2015 New Revision: 222725 URL: https://gcc.gnu.org/viewcvs?rev=222725root=gccview=rev Log: 2015-05-02 Steven G. Kargl ka...@gcc.gnu.org PR fortran/65976 * invoke.texi: Remove 'no-' in '-fno-fixed-form' Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi
[Bug fortran/65976] gfortran man-page lists the -fno-fixed-form flag but does not define it, and it doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65976 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat May 2 16:40:18 2015 New Revision: 222726 URL: https://gcc.gnu.org/viewcvs?rev=222726root=gccview=rev Log: 2015-05-02 Steven G. Kargl ka...@gcc.gnu.org PR fortran/65976 * invoke.texi: Remove 'no-' in '-fno-fixed-form' Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/invoke.texi
[Bug libstdc++/17995] gcc-3.4.2/libstdc++-v3/libsupc++/eh_alloc.cc:34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17995 --- Comment #14 from Cary Lewis cary.lewis at gmail dot com --- It's this exact error. The 3rd stage fails. With the conflict about ::strstr and std::strstr
[Bug libstdc++/17995] gcc-3.4.2/libstdc++-v3/libsupc++/eh_alloc.cc:34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17995 --- Comment #15 from Jonathan Wakely redi at gcc dot gnu.org --- It can't be this exact error, because the line number will have changed, and it would be useful to know the exact line numbers where the errors happen with the current sources (we have three different versions of cstring and without checking some config files I wouldn't know which is being used on SCO ... maybe using a different one would solve the problem). Please either provide the error here or email it to me separately so I can see the *exact* error, not a similar one from GCC 3.4.2 a decade ago. I'll take a look, but since I don't have a SCO machine I need more info from you.
[Bug target/65983] New: [6 Regression] ICE: SIGSEGV in mark_label_nuses (emit-rtl.c:3618) with -fsanitize=thread -mavx512ifma -march=barcelona
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65983 Bug ID: 65983 Summary: [6 Regression] ICE: SIGSEGV in mark_label_nuses (emit-rtl.c:3618) with -fsanitize=thread -mavx512ifma -march=barcelona Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Created attachment 35442 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35442action=edit reduced testcase Compiler output: $ gcc -fsanitize=thread -mavx512ifma -march=barcelona testcase.c testcase.c: In function 'foo': testcase.c:10:1: internal compiler error: Segmentation fault } ^ 0xb635ff crash_signal /mnt/svn/gcc-trunk/gcc/toplev.c:380 0x7c664e mark_label_nuses /mnt/svn/gcc-trunk/gcc/emit-rtl.c:3618 0x7c66d8 mark_label_nuses /mnt/svn/gcc-trunk/gcc/emit-rtl.c:3625 0x7c66d8 mark_label_nuses /mnt/svn/gcc-trunk/gcc/emit-rtl.c:3625 0x7d49f9 try_split(rtx_def*, rtx_def*, int) /mnt/svn/gcc-trunk/gcc/emit-rtl.c:3814 0xa95738 split_insn /mnt/svn/gcc-trunk/gcc/recog.c:2919 0xa9dd0d split_all_insns() /mnt/svn/gcc-trunk/gcc/recog.c:3009 0xa9de38 rest_of_handle_split_before_sched2 /mnt/svn/gcc-trunk/gcc/recog.c:4060 0xa9de38 execute /mnt/svn/gcc-trunk/gcc/recog.c:4099 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. Tested revisions: r222716 - ICE 5 r222437 - OK
[Bug c/59098] Unwarranted warning: promoted ~unsigned is always non-zero [-Wsign-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59098 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to fenugrec from comment #3) Probable duplicate of Bug 38341 I don't think so. The problem here is not only whether the warning is correct or not. A major issue is that the original code does not contain ~unsigned, but GCC transforms (folds) the code too early. It is also unclear whether the code paths that lead to this are the same. Two things may cause exactly the same wrong warning but may be unrelated, or cause two different warnings, but have the same root cause. Hard to say without running GCC under the debugger and analyzing the execution (https://gcc.gnu.org/wiki/DebuggingGCC)
[Bug target/65979] internal compiler error: in make_edges, at tree-cfg.c:923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #2 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Additional comment: There seem to be multiple (unrelated?) errors which prevent the built but all of them, including the one I reported seem to relate to conftest.c. So I'll rename the bug title accordingly. Adrian
[Bug target/65986] New: [6 Regression] ICE: in extract_constrain_insn, at recog.c:2244 (insn does not satisfy its constraints) with -mavx512ifma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65986
Bug ID: 65986
Summary: [6 Regression] ICE: in extract_constrain_insn, at
recog.c:2244 (insn does not satisfy its constraints)
with -mavx512ifma
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Created attachment 35444
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35444action=edit
reduced testcase
Compiler output:
$ gcc -O -mavx512ifma testcase.c
testcase.c: In function 'ufraw_test':
testcase.c:25:1: error: insn does not satisfy its constraints:
}
^
(insn 110 109 104 7 (set (reg:V2DF 53 xmm16 [ D.2731 ])
(vec_merge:V2DF (vec_duplicate:V2DF (float:DF (reg/v:SI 4 si [orig:100
iWidth ] [100])))
(reg:V2DF 53 xmm16 [ D.2731 ])
(const_int 1 [0x1]))) testcase.c:22 2195 {sse2_cvtsi2sd}
(expr_list:REG_DEAD (reg/v:SI 4 si [orig:100 iWidth ] [100])
(nil)))
testcase.c:25:1: internal compiler error: in extract_constrain_insn, at
recog.c:2244
0xae3e58 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/mnt/svn/gcc-trunk/gcc/rtl-error.c:110
0xae3ec4 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/mnt/svn/gcc-trunk/gcc/rtl-error.c:121
0xa9b23c extract_constrain_insn(rtx_insn*)
/mnt/svn/gcc-trunk/gcc/recog.c:2244
0xaa97be copyprop_hardreg_forward_1
/mnt/svn/gcc-trunk/gcc/regcprop.c:793
0xaaab2a execute
/mnt/svn/gcc-trunk/gcc/regcprop.c:1289
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.
Tested revisions:
r222716 - ICE
5 r222437 - OK
[Bug middle-end/65984] New: ICE: definition in block 4 does not dominate use in block 2 with -fnon-call-exceptions -fsanitize=enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65984 Bug ID: 65984 Summary: ICE: definition in block 4 does not dominate use in block 2 with -fnon-call-exceptions -fsanitize=enum Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Created attachment 35443 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35443action=edit reduced testcase Compiler output: $ gcc -fnon-call-exceptions -fsanitize=enum testcase.C testcase.C: In function 'int foo(int)': testcase.C:12:1: error: definition in block 4 does not dominate use in block 2 } ^ for SSA_NAME: _3 in statement: _4 = _3; testcase.C:12:1: internal compiler error: verify_ssa failed 0xf08601 verify_ssa(bool, bool) /mnt/svn/gcc-trunk/gcc/tree-ssa.c:1068 0xc21ed5 execute_function_todo /mnt/svn/gcc-trunk/gcc/passes.c:1953 0xc2268b execute_todo /mnt/svn/gcc-trunk/gcc/passes.c:2003 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. Tested revisions: r222716 - ICE 5 r222437 - ICE 4_9 r222436 - ICE
[Bug c++/65985] compiler segfault with assert() in constexpr constructor body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65985 --- Comment #1 from rhalbersma rhalbersma at gmail dot com --- See also LWG active issue 2234 http://cplusplus.github.io/LWG/lwg-active.html#2234
[Bug target/65987] New: [6 Regression] [SH] Wrong jump generated for gcc.dg/tree-prof/va-arg-pack-1.c with -fprofile-use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65987 Bug ID: 65987 Summary: [6 Regression] [SH] Wrong jump generated for gcc.dg/tree-prof/va-arg-pack-1.c with -fprofile-use Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kkojima at gcc dot gnu.org Target Milestone: --- Target: sh*-*-* I've got FAIL: gcc.dg/tree-prof/va-arg-pack-1.c compilation, -fprofile-use -D_PROFILE_USE with /tmp/ccn6JsFz.s: Assembler messages: /tmp/ccn6JsFz.s:524: Error: displacement to defined symbol .L85 overflows 12-bit field ... which means that wrong branch instructions generated.
[Bug libstdc++/17995] gcc-3.4.2/libstdc++-v3/libsupc++/eh_alloc.cc:34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17995 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #17 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Cary Lewis from comment #16) ../gcc-3.4.3/configure --prefix=/usr/local/gcc-3.4.3x Oh ... you really are build gcc 3.4, when you said more modern version of the compiler I thought you meant something recent. Have you tried a newer GCC? SCO support was removed in GCC 4.3, but 4.2.4 should work, and this problem might already be fixed in that release.
[Bug target/65987] [6 Regression] [SH] Wrong jump generated for gcc.dg/tree-prof/va-arg-pack-1.c with -fprofile-use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65987 --- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Created attachment 35445 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35445action=edit patch for section crossing jumps It turns out that some SH specific jump optimizations don't take into account section crossing jumps. I'm testing the attached patch.
[Bug c++/65985] New: compiler segfault with assert() in constexpr constructor body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65985
Bug ID: 65985
Summary: compiler segfault with assert() in constexpr
constructor body
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rhalbersma at gmail dot com
Target Milestone: ---
The following code segfaults with -std=c++1y for g++ 5.1.0 and trunk 20150502
on the combination of constexpr and assert() in the constructor body (removing
either the constexpr keyword everywhere or the assert() will compile cleanly).
#include cassert
class Angle
{
int degrees = 0;
constexpr auto invariant() const noexcept
{
return 0 = degrees degrees 360;
}
public:
explicit constexpr Angle(int n) noexcept
:
degrees{n % 360}
{
assert(invariant());
}
/* implicit */ constexpr operator auto() const noexcept
{
return degrees;
}
};
int main()
{
static_assert(Angle{360} == 0, );
}
This code correctly compiles with -std=c++14 from Clang 3.3 and higher.
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #32 from Frédéric Buclin LpSolit at netscape dot net --- For some reason, DateTime::TimeZone-new(name = 'local') sometimes returns Asia/Kolkata, which explains the -05:30 offset observed in the famous 2% of bugmails with an incorrect timestamp. I added extra debug code to track which TZ method is the culprit.
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #33 from Frédéric Buclin LpSolit at netscape dot net --- I found only one user account which uses the Asia/Kolkata timezone. But no reason why this would interact with the local timezone.
[Bug other/63509] Misleading error message when building gcc without C++ compiler installed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63509 Chenry chenrylee at qq dot com changed: What|Removed |Added CC||chenrylee at qq dot com --- Comment #4 from Chenry chenrylee at qq dot com --- Also occurred on CentOS 7, solved by installing gcc-c++.
[Bug bootstrap/65988] New: Trying to compile GCC 5.1 in my (customized) Solaris 10/x86-64 fails with GMP errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65988 Bug ID: 65988 Summary: Trying to compile GCC 5.1 in my (customized) Solaris 10/x86-64 fails with GMP errors Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: jcea at jcea dot es Target Milestone: --- Currently running GCC 4.9.2. Compiled cleanly. When trying to compile GCC 5.1 I get these errors: (partial/incomplete) [...] /tmp/z/obj/prev-i386-pc-solaris2.10/libstdc++-v3/include/bits/stringfwd.h:69:3: error: template with C linkage templatetypename _CharT, typename _Traits = char_traits_CharT, ^ In file included from /tmp/z/obj/prev-i386-pc-solaris2.10/libstdc++-v3/include/iosfwd:40:0, from /usr/local/include/gmp.h:34, from /usr/local/include/isl/val_gmp.h:4, from ../../gcc-5.1.0/gcc/graphite-isl-ast-to-gimple.c:33: /tmp/z/obj/prev-i386-pc-solaris2.10/libstdc++-v3/include/bits/postypes.h:111:3: error: template with C linkage templatetypename _StateT ^ /tmp/z/obj/prev-i386-pc-solaris2.10/libstdc++-v3/include/bits/postypes.h:214:3: error: template with C linkage templatetypename _StateT ^ /tmp/z/obj/prev-i386-pc-solaris2.10/libstdc++-v3/include/bits/postypes.h:219:3: error: template with C linkage templatetypename _StateT ^ In file included from /usr/local/include/gmp.h:34:0, from /usr/local/include/isl/val_gmp.h:4, from ../../gcc-5.1.0/gcc/graphite-isl-ast-to-gimple.c:33: /tmp/z/obj/prev-i386-pc-solaris2.10/libstdc++-v3/include/iosfwd:76:3: error: template with C linkage templatetypename _CharT, typename _Traits = char_traits_CharT ^ /tmp/z/obj/prev-i386-pc-solaris2.10/libstdc++-v3/include/iosfwd:79:3: error: template with C linkage [...] In file included from /usr/local/include/isl/val_gmp.h:4:0, from ../../gcc-5.1.0/gcc/graphite-isl-ast-to-gimple.c:33: /usr/local/include/gmp.h:2255:71: error: conflicting declaration of C function ‘std::ostream operator(std::ostream, mpq_srcptr)’ __GMP_DECLSPEC_XX std::ostream operator (std::ostream , mpq_srcptr); ^ /usr/local/include/gmp.h:2254:33: note: previous declaration ‘std::ostream operator(std::ostream, mpz_srcptr)’ __GMP_DECLSPEC_XX std::ostream operator (std::ostream , mpz_srcptr); ^ /usr/local/include/gmp.h:2256:71: error: conflicting declaration of C function ‘std::ostream operator(std::ostream, mpf_srcptr)’ __GMP_DECLSPEC_XX std::ostream operator (std::ostream , mpf_srcptr); ^ /usr/local/include/gmp.h:2255:33: note: previous declaration ‘std::ostream operator(std::ostream, mpq_srcptr)’ __GMP_DECLSPEC_XX std::ostream operator (std::ostream , mpq_srcptr); [...] /usr/local/include/gmp.h:2255:33: note: previous declaration ‘std::ostream operator(std::ostream, mpq_srcptr)’ __GMP_DECLSPEC_XX std::ostream operator (std::ostream , mpq_srcptr); ^ /usr/local/include/gmp.h:2256:71: error: conflicting declaration of C function ‘std::ostream operator(std::ostream, mpf_srcptr)’ __GMP_DECLSPEC_XX std::ostream operator (std::ostream , mpf_srcptr); ^ /usr/local/include/gmp.h:2254:33: note: previous declaration ‘std::ostream operator(std::ostream, mpz_srcptr)’ __GMP_DECLSPEC_XX std::ostream operator (std::ostream , mpz_srcptr); ^ /usr/local/include/gmp.h:2258:68: error: conflicting declaration of C function ‘std::istream operator(std::istream, mpq_ptr)’ __GMP_DECLSPEC_XX std::istream operator (std::istream , mpq_ptr); ^ /usr/local/include/gmp.h:2257:33: note: previous declaration ‘std::istream operator(std::istream, mpz_ptr)’ __GMP_DECLSPEC_XX std::istream operator (std::istream , mpz_ptr); ^ /usr/local/include/gmp.h:2259:68: error: conflicting declaration of C function ‘std::istream operator(std::istream, mpf_ptr)’ __GMP_DECLSPEC_XX std::istream operator (std::istream , mpf_ptr); ^ /usr/local/include/gmp.h:2258:33: note: previous declaration ‘std::istream operator(std::istream, mpq_ptr)’ __GMP_DECLSPEC_XX std::istream operator (std::istream , mpq_ptr); ^ /usr/local/include/gmp.h:2259:68: error: conflicting declaration of C function ‘std::istream operator(std::istream, mpf_ptr)’ __GMP_DECLSPEC_XX std::istream operator (std::istream , mpf_ptr); ^ /usr/local/include/gmp.h:2257:33: note:
