[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #19 from fxcoudert at gmail dot com --- Hi Rainer, > Thanks a lot for the patch. I've now re-bootstrapped trunk on macOS 14 > with it applied instead of the local (incomplete) > workaround. I haven’t yet tested Xcode 13.3 myself, and have only followed the PRs from far away. Are there any issues (SDK, linker, or otherwise) that we need to report to Apple? Or that are already reported but we want taken more seriously? I can use my channel through Homebrew to get them to prioritise it to some extent. It’s probably too late for 13.3 at this point, but we should get it fixed anyway for later. FX --- Comment #20 from fxcoudert at gmail dot com --- Hi Rainer, > Thanks a lot for the patch. I've now re-bootstrapped trunk on macOS 14 > with it applied instead of the local (incomplete) > workaround. I haven’t yet tested Xcode 13.3 myself, and have only followed the PRs from far away. Are there any issues (SDK, linker, or otherwise) that we need to report to Apple? Or that are already reported but we want taken more seriously? I can use my channel through Homebrew to get them to prioritise it to some extent. It’s probably too late for 13.3 at this point, but we should get it fixed anyway for later. FX
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #19 from fxcoudert at gmail dot com --- Hi Rainer, > Thanks a lot for the patch. I've now re-bootstrapped trunk on macOS 14 > with it applied instead of the local (incomplete) > workaround. I haven’t yet tested Xcode 13.3 myself, and have only followed the PRs from far away. Are there any issues (SDK, linker, or otherwise) that we need to report to Apple? Or that are already reported but we want taken more seriously? I can use my channel through Homebrew to get them to prioritise it to some extent. It’s probably too late for 13.3 at this point, but we should get it fixed anyway for later. FX --- Comment #20 from fxcoudert at gmail dot com --- Hi Rainer, > Thanks a lot for the patch. I've now re-bootstrapped trunk on macOS 14 > with it applied instead of the local (incomplete) > workaround. I haven’t yet tested Xcode 13.3 myself, and have only followed the PRs from far away. Are there any issues (SDK, linker, or otherwise) that we need to report to Apple? Or that are already reported but we want taken more seriously? I can use my channel through Homebrew to get them to prioritise it to some extent. It’s probably too late for 13.3 at this point, but we should get it fixed anyway for later. FX
[Bug fortran/66377] [F95] Wrong-code with equivalenced array in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66377 --- Comment #5 from fxcoudert at gmail dot com fxcoudert at gmail dot com --- Is this code old, or a regression introduced by the recent module-equivalence patch (to reduce the module sizes)? Does removing the code regress module size in the case of modules with equiv used in modules used in modules etc? FX
[Bug middle-end/60102] [4.9/5 Regression] powerpc fp-bit ices at dwf_regno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102 --- Comment #22 from fxcoudert at gmail dot com fxcoudert at gmail dot com --- Sorry. The REGISTER_NAMES macro that was updated in rs6000.h file gets redefined in darwin.h file. I can provide the required patch, but I don't have a darwin machine to test the changes. If you upload a patch on the bugzilla entry, I will test it. FX
[Bug middle-end/31068] ICE at -O1 -fipa-pta
--- Comment #3 from fxcoudert at gmail dot com 2007-04-16 07:03 --- Subject: Re: ICE at -O1 -fipa-pta PS, I will fix this sometime after we have LTO. Until then, -fipa-pta is not worth it. Can it be made an undocumented option, then, for the time being? Because it's still an ICE on valid code using a documented option :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31068
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #4 from fxcoudert at gmail dot com 2007-03-07 21:09 --- Subject: Re: MINLOC should sometimes be inlined (gas_dyn is so slw) In gfc_conv_intrinsic_function, expr-rank is 0 for minval and 1 for minloc (which is bogus). It's not bogus. The MINLOC is an array of rank 1, that's correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug libfortran/24383] mingw doesn't have SSIZE_MAX
--- Comment #6 from fxcoudert at gmail dot com 2005-10-21 19:49 --- Fixed. -- fxcoudert at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24383
[Bug libfortran/20438] Reconfiguring of libgfortran fails conflicting types for int8_t
--- Comment #5 from fxcoudert at gmail dot com 2005-10-21 20:13 --- (In reply to comment #4) Is this true any more on the mainline? Yes, it is. -- fxcoudert at gmail dot com changed: What|Removed |Added CC||fxcoudert at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20438
[Bug libfortran/24383] mingw doesn't have SSIZE_MAX
--- Comment #4 from fxcoudert at gmail dot com 2005-10-20 08:53 --- This is fixed in mingw CVS. I will add the workaround with SHRT_MAX. It might not be very efficient, but at least it's garanteed to work, and I think we'd better be on the safe side. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24383
[Bug libfortran/24432] [4.1 regression] Missing symbols
--- Comment #6 from fxcoudert at gmail dot com 2005-10-19 08:27 --- Eric, I let you close this PR after you check that the regression disappeared. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24432
[Bug libfortran/24432] [4.1 regression] Missing symbols
--- Comment #9 from fxcoudert at gmail dot com 2005-10-19 09:46 --- (In reply to comment #7) Looks like you have to unify your preprocessor macro strategy in libgfortran. Oh, s***. Now, they're defined with value 1 (unless my grep failed me, I think I've done them all). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24432
[Bug libfortran/24432] [4.1 regression] Missing symbols
--- Comment #2 from fxcoudert at gmail dot com 2005-10-18 21:43 --- (In reply to comment #0) has introduced a bunch of regressions on non-C99 SPARC/Solaris platforms How come they I don't see those on my sparc-solaris2.9 builds? See http://quatramaran.ens.fr/~coudert/gfortran/test-results/test-sparc-solaris-20051012.log and older. This is particularly annoying, since sparc-solaris2.9 is one of the platforms on which I regtested this patch! Other than that, I concur in diagnosis and solution. Will implement that as soon as possible (most probably on Wednesday evening, European time). [FX, please make sure your email address as recorded in the ChangeLog file is registered with Bugzilla; same for [EMAIL PROTECTED] Thanks in advance.] Sorry, I didn't know that rule. Will use my gcc.gnu.org address in changelogs in the future. Does that need to be retroactive? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24432
[Bug middle-end/21597] [4.1 Regression] libgcc broken on targets with MKDIR_TAKES_ONE_ARG
--- Additional Comments From fxcoudert at gmail dot com 2005-05-21 10:03 --- On i386-mingw32, there is another one of those: ../../gcc/fastjar/jartool.c: In function 'extract_jar': ../../gcc/fastjar/jartool.c:1770: error: too many arguments to function 'mkdir' Looks like MKDIR_TAKES_ONE_ARG is not defined as it should be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21597
