[Bug target/71009] g++: ICE on modified gdb/valarith.c with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71009 --- Comment #12 from Ryan Schmidt --- How would I do that?
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 Ryan Schmidt changed: What|Removed |Added CC||gcc at ryandesign dot com --- Comment #6 from Ryan Schmidt --- I can confirm the "DEF_INTERNAL_FLT_FN (...) has no associated built-in functions" errors when building gcc 8.2.0 with Apple gcc 4.2.1 from Xcode 3.1.4 on PowerPC Mac OS X 10.5.8.
[Bug target/82092] [8/9 regression] gcc fails to link genmodes on darwin (cfiStartsArray[i] != cfiStartsArray[i-1])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82092 --- Comment #15 from Ryan Schmidt --- Yes, I noticed Homebrew had the update, and I didn't understand why it worked there. But now I do. Some more information has turned up in a new MacPorts ticket: https://trac.macports.org/ticket/56521 In MacPorts gcc ports, we use --with-as=/opt/local/bin/as (this assembler is provided by our cctools port). This change was made in MacPorts 6 years ago by Jeremy who reported this bug, though I'm not entirely sure why. I suspect the problem is that our cctools port is currently at version 895, which corresponds to what's in Xcode 8.1, and that's apparently too old to work properly in this case. I am able to get a more recent snapshot to build if I instead use --with-as=/usr/bin/as, so perhaps we either need to do that in MacPorts or we need to update our cctools port to a more recent version.
[Bug target/82092] gcc fails to link genmodes on darwin (cfiStartsArray[i] != cfiStartsArray[i-1])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82092 --- Comment #10 from Ryan Schmidt --- Is gcc8 ever going to be buildable on macOS again? It's been unbuildable for 11 months now.
[Bug target/82092] gcc fails to link genmodes on darwin (cfiStartsArray[i] != cfiStartsArray[i-1])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82092 --- Comment #9 from Ryan Schmidt --- Is it safe to use the patch? Will a gcc built with the patch produce correct code? If so, I would like to include it in MacPorts so that I can update our gcc8 port to a newer version. Because of this problem, we have not been able to do so since June 2017.
[Bug target/71009] g++: ICE on modified gdb/valarith.c with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71009 Ryan Schmidt changed: What|Removed |Added CC||gcc at ryandesign dot com --- Comment #9 from Ryan Schmidt --- I am also encountering this problem on i386-apple-darwin9.8.0 when compiling texlive-bin 20170604 with gcc 6.4.0, though in my case it's -Os not -Ofast: libtool: compile: /opt/local/bin/gcc-mp-6 -DHAVE_CONFIG_H -I. -I./LuaJIT-src/src -DLUAJIT_ENABLE_LUA52COMPAT -DLUAI_HASHLIMIT=6 -U_FORTIFY_SOURCE -isystem/opt/local/include -fomit-frame-pointer -march=i686 -msse -msse2 -mfpmath=sse -fno-stack-protector -Wall -pipe -Os -m32 -MT LuaJIT-src/src/lj_cconv.lo -MD -MP -MF LuaJIT-src/src/.deps/lj_cconv.Tpo -c LuaJIT-src/src/lj_cconv.c -fno-common -DPIC -o LuaJIT-src/src/.libs/lj_cconv.o LuaJIT-src/src/lj_cconv.c: In function 'lj_cconv_ct_ct': LuaJIT-src/src/lj_cconv.c:368:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1025 } ^ libbacktrace could not find executable to open
[Bug target/82092] gcc fails to link genmodes on darwin (cfiStartsArray[i] != cfiStartsArray[i-1])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82092 Ryan Schmidt changed: What|Removed |Added CC||gcc at ryandesign dot com --- Comment #6 from Ryan Schmidt --- (In reply to Dominique d'Humieres from comment #3) > --- ../_clean/gcc/config/darwin.c 2017-09-18 15:49:48.0 +0200 > +++ gcc/config/darwin.c 2017-09-23 21:00:41.0 +0200 > @@ -3201,6 +3201,10 @@ darwin_override_options (void) >flag_reorder_blocks = 1; > } > > +// FIXME ; Jam this off until we figure out what codegen issues are > caused > +flag_reorder_blocks_and_partition = 0; > +flag_reorder_blocks = 1; > + > /* FIXME: flag_objc_sjlj_exceptions is no longer needed since there is > only > one valid choice of exception scheme for each runtime. */ > if (!global_options_set.x_flag_objc_sjlj_exceptions) > > Could you please test this patch? Yes, this patch does allow gcc 8-20171217 to build for me on macOS Sierra with Xcode 9.2. Is this patch safe for us to commit to MacPorts to be able to update our gcc8 port?
[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 Ryan Schmidt changed: What|Removed |Added CC||gcc at ryandesign dot com --- Comment #47 from Ryan Schmidt --- Misty De Meo, I see you filed a RADAR where Apple said it wasn't their problem, and then they suggested you follow up with Apple DTS. Did you do that, and if so did you discover anything new?
[Bug libgcj/64219] New: Rename libgcj-5.0.pc to libgcj-5.pc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64219 Bug ID: 64219 Summary: Rename libgcj-5.0.pc to libgcj-5.pc Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj Assignee: unassigned at gcc dot gnu.org Reporter: gcc at ryandesign dot com gcc 4.9.2 installs the file libgcj-4.9.pc. gcc 5-20141130 installs the file libgcj-5.0.pc. Given the change to the gcc version numbering scheme starting with version 5, shouldn't the file be called libgcj-5.pc?
[Bug middle-end/63801] error: templates must have C++ linkage when building with isl and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63801 Ryan Schmidt gcc at ryandesign dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Ryan Schmidt gcc at ryandesign dot com --- I see that with version 5-20141207 this patch is no longer needed, so I guess the problem is fixed.
[Bug other/64184] New: error: '_SC_NPROCESSORS_ONLN' undeclared (first use in this function)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64184 Bug ID: 64184 Summary: error: '_SC_NPROCESSORS_ONLN' undeclared (first use in this function) Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: gcc at ryandesign dot com Created attachment 34190 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34190action=edit log Building gcc 4.9.2 fails on Mac OS X 10.4.11, with the following message: /Volumes/Data/macports/tiger/var/macports/build/_Volumes_Data_macports_dports_lang_gcc49/libgcc/work/gcc-4.9.2/libcilkrts/runtime/sysdep-unix.c: In function 'write_version_file': /Volumes/Data/macports/tiger/var/macports/build/_Volumes_Data_macports_dports_lang_gcc49/libgcc/work/gcc-4.9.2/libcilkrts/runtime/sysdep-unix.c:736:52: error: '_SC_NPROCESSORS_ONLN' undeclared (first use in this function) fprintf(fp, System cores: %d\n, (int)sysconf(_SC_NPROCESSORS_ONLN)); ^ /Volumes/Data/macports/tiger/var/macports/build/_Volumes_Data_macports_dports_lang_gcc49/libgcc/work/gcc-4.9.2/libcilkrts/runtime/sysdep-unix.c:736:52: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [sysdep-unix.lo] Error 1 make[2]: Leaving directory `/Volumes/Data/macports/tiger/var/macports/build/_Volumes_Data_macports_dports_lang_gcc49/libgcc/work/build/i386-apple-darwin8/libcilkrts' make[1]: *** [all-target-libcilkrts] Error 2 make[1]: Leaving directory `/Volumes/Data/macports/tiger/var/macports/build/_Volumes_Data_macports_dports_lang_gcc49/libgcc/work/build' make: *** [bootstrap] Error 2
[Bug middle-end/63801] error: templates must have C++ linkage when building with isl and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63801 --- Comment #5 from Ryan Schmidt gcc at ryandesign dot com --- I see a patch for this has been provided on the mailing list: https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg95468.html It is a long thread and I haven't read all of it.
[Bug libgcc/63801] New: error: templates must have C++ linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63801
Bug ID: 63801
Summary: error: templates must have C++ linkage
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at ryandesign dot com
Hello, I'm a developer with the MacPorts project. I'm not the maintainer of our
gcc ports, but I am the one who created our gcc5 port and kept it updated until
version 5-20140824. No later snapshot of gcc5 has successfully built for me on
OS X, failing instead with the following message:
ccache /usr/bin/clang++ -arch x86_64 -c -g -DIN_GCC-fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common -DHAVE_CONFIG_H -I. -I.
-I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc
-I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc/.
-I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc/../include
-I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc/../libcpp/include
-I/opt/local/include -I/opt/local/include -I/opt/local/include
-I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc/../libdecnumber
-I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc/../libdecnumber/dpd
-I../libdecnumber
-I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc/../libbacktrace
-DCLOOG_INT_GMP -I/opt/local/include -DCLOOG_INT_GMP -I/opt/local/include -o
graphite-clast-to-gimple.o -MT graphite-clast-to-gimple.o -MMD -MP -MF
./.deps/graphite-clast-to-gimple.TPo
/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc/graphite-clast-to-gimple.c
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated
clang: warning: treating 'cpp-output' input as 'c++-cpp-output' when in C++
mode, this behavior is deprecated
In file included from
/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc/graphite-clast-to-gimple.c:36:
In file included from /opt/local/include/isl/val_gmp.h:4:
In file included from /opt/local/include/gmp.h:34:
In file included from
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iosfwd:89:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__config:494:1:
error: templates must have C++ linkage
template bool struct __static_assert_test;
^~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__config:495:20:
error: explicit specialization of non-template struct '__static_assert_test'
template struct __static_assert_testtrue {};
^ ~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__config:496:1:
error: templates must have C++ linkage
template unsigned struct __static_assert_check {};
^~~
We are using gmp version 6.0.0 and isl version 0.14.
This was with the following OS X, Xcode and clang versions, but similar failure
occurs on earlier versions:
$ sw_vers
ProductName:Mac OS X
ProductVersion:10.10.1
BuildVersion:14B17
$ xcodebuild -version
Xcode 6.1
Build version 6A1052d
$ clang -v
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
$
[Bug middle-end/63801] error: templates must have C++ linkage when building with isl and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63801
--- Comment #2 from Ryan Schmidt gcc at ryandesign dot com ---
Isn't the extern C coming from lines 32-38 of gcc/graphite-clast-to-gimple.c
which in version 5-20141109 say:
#if defined(__cplusplus)
extern C {
#endif
#include isl/val_gmp.h
#if defined(__cplusplus)
}
#endif
The first 4 lines of /opt/local/include/isl/val_gmp.h are simply:
#ifndef ISL_VAL_GMP_H
#define ISL_VAL_GMP_H
#include gmp.h
Lines 31-36 of /opt/local/include/gmp.h (the first non-comment lines) are:
#ifndef __GMP_H__
#if defined (__cplusplus)
#include iosfwd /* for std::istream, std::ostream, std::string */
#include cstdio
#endif
[Bug middle-end/63801] error: templates must have C++ linkage when building with isl and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63801 --- Comment #4 from Ryan Schmidt gcc at ryandesign dot com --- Thanks. If I remove the extern C then it fails with: /opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc/graphite-optimize-isl.c:357:12: error: use of undeclared identifier 'isl_band_member_is_zero_distance' if (isl_band_member_is_zero_distance (Band, i)) ^ The isl changelog, under the heading Changes since isl-0.12, says The function isl_band_member_is_zero_distance has been removed. Essentially the same functionality is available through isl_band_member_is_coincident, except that is requires setting up coincidence constraints. The option schedule_outer_zero_distance has accordingly been replaced by the option schedule_outer_coincidence.
[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9
--- Comment #43 from gcc at ryandesign dot com 2010-06-20 06:57 --- Is there a reason the 3 fixes Andreas committed in February were not backported to the 4.4 branch? I just ran into Internal error: Abort trap (program ecj1) with 4.4.4 on Snow Leopard 10.6.4 and applying those patches fixed it. -- gcc at ryandesign dot com changed: What|Removed |Added CC||gcc at ryandesign dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
