Re: [patch, fortran] PR 56867

> OK for trunk? What about the other open branches? OK for trunk. After it’s been in for a bit of time, probably OK for all active branches, unless someone (or you) think it’s unwise. FX

Re: [Fortran, Patch] Cosmetics

> 2014-12-28 Andre Vehreschild > >* trans-decl.c (gfc_finish_var_decl): Fixed displaced comment. >* trans-stmt.c (gfc_trans_allocate): Fixed indentation. OK to commit. Thanks! FX

Re: [Patch, Fortran + Testsuite] Fix coarray handling in modules

dg-compile-aux-modules support to caf.dg > (currently unused). OK. It’s probably best to commit the two parts as separate commits, though. FX

Re: [PATCH, fortran] Add gfc_define_builtin_with_spec

If unused on trunk, why would we commit it there? When your branch is merged, you'll merge it along. Otherwise that defeats the purpose of working on a branch, unless I misunderstand something... FX > Le 9 janv. 2015 à 16:37, Tom de Vries a écrit : > > Jakub, > > For th

Re: [PATCH, fortran] Add gfc_define_builtin_with_spec

, we don’t add unused code to the codebase. A quick grep through the current front-end and middle-end confirms that. Because it’s not used and not tested, it could bitrot and adds to the maintainance cost. FX

Re: Fix some more decl types in the Fortran frontend

vered right now, otherwise you would have seen regressions). Cheers, FX

Re: Fix some more decl types in the Fortran frontend

> So it looks like the following patch would be the right thing? I would think so. FX

Re: Fix some more decl types in the Fortran frontend

> And thanks for the review, FX. Do you want to undo your Fortran-maintainer → > mere-contributor status, given that you are now again a bit more involved in > the GCC development? Yeah, why not. I promise I'll be careful and only review things in my comfort zone (which isn'

Re: [PATCH v4 1/2] Fix __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__

* If the command-line is empty, just return. */ >if (argc <= 1) I don’t know why the exact size of new_flag should be sizeof(…)+6, but it makes sense to widen it with the new version. Given the above, could a darwin maintainer please approve this patch (either with or without my addi

Re: [PATCH v4 1/2] Fix __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__

> That should be allocated in darwin_find_version_from_kernel, using > asprintf, and static doesn't make sense either. Does this look sane? (I don’t often use asprintf, so I might have done something stupid) FX darwin.diff Description: Binary data

Re: Lots of C++ failures

In fact, after looking at the latest gcc-patches messages, I think it may be due to this commit: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01107.html (based purely on the fact that the unrecognized insn is a call, and the patch deals with CALL_EXPR). FX > I am testing trunk on darwi

Re: Lots of C++ failures

, cause it’s apparently not committed yet (at least, not in rev. 215234 which is the one failing for me). But now, I’ve found it is PR 61387 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61387), already known. FX

Re: [PATCH v4 1/2] Fix __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__

> I don't think you need strdup here. Updated version, bootstraps and regtests. OK to commit? gcc/ChangeLog: * config/darwin-c.c (version_as_macro): Added extra 0 for OS X 10.10 and above * config/darwin-driver.c (darwin_find_version_from_kernel): Removed kernel version check to

Re: Fix some more decl types in the Fortran frontend

So, after a six-year break (was it so long?), I’m back among the maintainers. Committed as rev. 215237 FX 2014-09-13 Francois-Xavier Coudert * MAINTAINERS: Move myself to reviewers (Fortran). Index: MAINTAINERS

Re: [PATCH v4 1/2] Fix __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__

Committed as rev. 215251 Thanks for the review. FX

Re: [patch i386]: Sibcall tail-call improvement and partial fix PR/60104

> Perhaps it would be safer simply to revert that hunk of the original patch > unless/until (1) and (2) above are addressed? Given that the original patch addresses “only” a missed-optimization (and causes ice-on-valid), it makes sense to me. FX

Re: [PR libfortran/62768] Handle filenames with embedded nulls

): Likewise. >>(delete_file): Likewise. OK, if you add a runtime testcase. I tried to think of other characters we might want to sanitize/special case, but at least on Unix/POSIX only NUL and / are fundamentally different. It might make sense to think about it for Windows targets. FX

Re: [patch i386]: Sibcall tail-call improvement and partial fix PR/60104

i has not clarified it following Iain’s request, 3. darwin maintainers have no idea how to hunt that bug, because of #1 & 2. Given that it breaks severely a secondary platform, can we please revert it, while Iain and Kai (and others) can work on getting it better, on list or in bugzilla?

Re: [PATCH] Fix PR63152

allocatable || sym_has_alloc_comp || has_finalizer); So do we want to test (sym->attr.allocatable), or (!sym->attr.pointer)? Or, asked another way: should we NULLIFY in the case of sym_has_alloc_comp || has_finalizer? FX

Re: [patch i386]: Sibcall tail-call improvement and partial fix PR/60104

ee to revert that patch. Please provide a testcase, why my > suggested fix isn't suitable. If there is a patch submitted that fixes the issue, of course reversion is bad. I was unaware of that. FX

Re: [patch i386]: Sibcall tail-call improvement and partial fix PR/60104

> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61387 comment #9. It > doesn't apply anymore due current version of predicate was altered. > Nevertheless I could easily update patch for current trunk version. Sure, please send that and I’ll test it on darwin. Thanks, FX

Re: [patch i386]: Sibcall tail-call improvement and partial fix PR/60104

ct, yes. Something in Darwin’s handling of visibility triggers it. One more point, unanswered in what I’ve seen, is this from Iain: > b) I'd like a clear explanation of what it's supposed to do so that we can > examine why it doesn't do that.. > c) ..and, until we fix it it, it should be disabled or left out. FX

Re: [PATCH] Fix PR63152

en for a number of additional > testcases involving alloc_comp and finalizers looked good as well. So, I > think the original patch is still fine. OK to commit, then. Thanks for the thorough answer to my question. FX

Re: [patch i386]: Sibcall tail-call improvement and partial fix PR/60104

Hi Kai, The patch you sent (copied below) does not fix the darwin regression. It still fails with the same ICE on attached valid code (in 64-bit mode; it compiles with -m32). FX a.C Description: Binary data > Index: config/i386/predicates

Re: [patch i386]: Sibcall tail-call improvement and partial fix PR/60104

ich Mike seconds, fixes the issue. See the testresults I posted here: https://gcc.gnu.org/ml/gcc-testresults/2014-09/msg01449.html (without the patch, there are 900+ testsuite failures) Could one of the maintainers (i386 or global) review it, please? FX Index: gcc/config/i3

Re: [PATCH] remove duplicated lines in gcc/fortran/resolve.c

uplicated > lines. OK for the trunk? You didn’t say if it was regtested. OK if it was (one can never be too sure!) Thanks, FX

[fortran,patch] Emit code for some IEEE functions in the front-end

regresses ieee_2.f90, at -m32 -fno-float-store only, where we seem to trigger a missimplification of __builtin_rint(). I’ll send, just after this one, a mail to gcc to get some help on that, and track the issue separately. OK to commit? FX ieee.ChangeLog Description: Binary data ieee.diff

[fortran,patch] Forbid assignment of different character kinds

it or tested it) to do so. Bootstrapped and regtested on x86_64-apple-darwin14. OK to commit? FX PS: given the little feedback we get on that feature, I suppose nobody actually uses nondefault character kinds. Just like it seems nobody uses the IEEE modules (no feedback received, at all

Re: [fortran,patch] Forbid assignment of different character kinds

gfc_current_form != FORM_FIXED, as diagnostics should be emitted based on language/pedantic options, not source form. Regtested on x86_64-apple-darwin14, comes with a testcase. OK to commit? FX pr36534.ChangeLog Description: Binary data pr36534.diff Description: Binary data

Re: [PATCH v4 1/2] Fix __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__

otstraps and regtests fine on x86_64-apple-darwin14 (I’ve got unrelated objc/obj-c++ failures, see PS). I suggest we backport it to 4.9, so that when 4.9.2 is released it builds fine on Yosemite. OK? FX PS: I’ve got quite a few objc/obj-c++ failures on x86_64-apple-darwin14, but I assume it’s

Re: [PATCH, i386]: Enable reminder{sd,df,xf} and fmod{sf,df,xf} only for flag_finite_math_only.

> The patch will be committed to mainline and other release branches. Thanks! FX

Re: [Fortran, Patch] Implement IMPLICIT NONE

>> Build and regtested on x86-64-gnu-linux. >> OK for the trunk? Looks mostly OK, but I have one question: I don’t understand what the wording "Type IMPLICIT NONE statement” is supposed to mean. Why “type”? FX

Re: [Fortran, Patch] Implement IMPLICIT NONE

> If you have a better suggestion for the wording … I’d suggest “IMPLICIT NONE (TYPE) statement at %C following an IMPLICIT statement” (and the other way around). OK, with or without the wording change, I let you decide

Re: [fortran,patch] Emit code for some IEEE functions in the front-end

to get some > help on that, and track the issue separately. > > OK to commit? > FX ieee.ChangeLog Description: Binary data ieee.diff Description: Binary data

Re: [fortran,patch] Forbid assignment of different character kinds

ed. In the interest of minimal modification of this code, I have committed the original approach as rev. 215887. Thanks for the review. FX

[patch] Add -static-libquadmath option

regtested on x86_64 linux. OK to commit? FX static_quadmath.ChangeLog Description: Binary data static_quadmath.diff Description: Binary data

Re: fatal error: gnu/stubs-32.h: No such file

I received no feedback, I'd like to submit this doc patch formally. Tested by doing "make info html pdf". OK to commit to trunk? What about other active release branches? FX Index: install.texi === --- install.texi

[RFC, patch] Detect lack of 32-bit devel environment on x86_64-linux targets

ile being invisible to a large majority of the power users. So, what do you think? FX Index: configure.ac === --- configure.ac(revision 201292) +++ configure.ac(working copy) @@ -2861,6 +2861,26 @@ case &qu

Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)

s was done in GMP. This code should be cleaned up, and it will fix bootstrap on clang-based target coincidentally, without adding another kludge. FX

Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)

cgi?id=61315). Since my PR has been closed twice by Andrew Pinski (“it’s clang’s fault, bouh ouh”), I’d ask the maintainers to step in. Can we please provide a GCC that works for the default darwin setup? Or at least drop darwin as secondary target and document the failure? FX

Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)

> Please post a patch. How about that? I’m not doing a full clean-up of the longlong.h code outside the area affected. This restores bootstrap on darwin, confirming that both the system compiler and later-stage-gcc accepts it. FX longlong.diff Description: Binary data longlong.Change

Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)

o do the tedious work of proposing a full patch, but I won’t be able to test it (and I didn’t want to do it if it had no chance of being accepted). Thanks, FX longlong.ChangeLog Description: Binary data longlong.ChangeLog Description: Binary data

Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)

o these other archs is suitable, I’m willing to do the tedious work of proposing a full patch, but I won’t be able to test it (and I didn’t want to do it if it had no chance of being accepted). Thanks, FX longlong.diff Description: Binary data longlong.ChangeLog Description: Binary data

Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)

ef/gnu/coreutils/src/longlong.h). FX

Re: Darwin bootstrap failure following wide int merge

d on x86_64-apple-darwin due to error below. Richard, could this be due to your revision 211013? FX ../../trunk/gcc/rtl.c: In function ‘void cwi_output_hex(FILE*, const_rtx)’: ../../trunk/gcc/rtl.c:239:62: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 h

Re: Darwin bootstrap failure following wide int merge

> I suppose casting the result of CWI_ELT () to uint64_t fixes this. Do > similar errors happen elsewhere? I don’t think you can cast to uint64_t, as host wide int might be some other type, no? There are others: ../../trunk/gcc/print-rtl.c: In function ‘void print_rtx(const_rtx)’: ../../trunk/

Re: Darwin bootstrap failure following wide int merge

bootstrap on x86_64-apple-darwin13. Thanks! FX patch Description: application/applefile CL Description: Binary data

Re: [RFC, patch] Detect lack of 32-bit devel environment on x86_64-linux targets

y enough and a serialization point, no? There you can do the > check even for when cross-compiling. Well, you’ve already built a whole stage, so it’s not so early, is it? FX

Re: [RFC, patch] Detect lack of 32-bit devel environment on x86_64-linux targets

icular special case, and a later check. I argued for an earlier check, because it was a particular annoying and particularly un-user-friendly error, and wrote the check in a way to minimize the number of false negatives. But, as you say, it is not possible to write a perfect check at that early point. FX

Re: [fortran,patch] Support for IEEE underflow control on x86/x86_64

of view, I’ve committed the patch as revision 212407. FX underflow.diff Description: Binary data underflow.ChangeLog Description: Binary data

Re: [fortran, patch] IEEE intrinsic modules (ping)

t will return 0, i.e. a nonexisting rounding mode flag, which is more appropriate (though it should never happen in practice). Committed as rev. 212423 after testing on x86_64-apple-darwin13. Thanks, FX z Description: Binary data

Re: [PATCH, fortran testsuite]: A couple of fixes in gfortran.dg/ieee directory

> And yes, I learned in a hard way that there is a difference between > f90 and F90 file extension. Yup, pre-processing. Sorry I wasn’t fast enough to reply to your earlier email, and thanks for doing this. FX

Re: PR 60414: Patch proposal

testcase doesn’t crash the compiler any more, but to confirm that it now generates the correct code (i.e. that we don’t turn an ice-on-valid bug into a wrong-code bug!). Cheers, FX

[patch, fortran] ATAN2 and -fsign-zero doc fixes

with "make man info html pdf", OK to commit to trunk? Cheers, FX doc.diff Description: Binary data doc.ChangeLog Description: Binary data

[fortran, patch] Document the interaction of -finit-{real,integer,…} and -Wuninitialized

ot;make info man html pdf". OK to commit to trunk? FX doc_finit_warnings.diff Description: Binary data doc_finit_warnings.ChangeLog Description: Binary data

[libgfortran, patch] Silence a warning in fallback round() implementation

ng my config.h on x86_64-linux to simulate the conditions. OK to commit to trunk? FX round.diff Description: Binary data round.ChangeLog Description: Binary data

[fortran, patch] PR 21881, issue a fatal error instead of an ICE

, but that's not for now AFAIU). So, the attached patch simply turns the ICE into a fatal error. The error being fatal, it doesn't trigger double errors as far as I could check. I'm not adding a testcase, though I could if you think that's necessary. Regtested on x86_64-

[libgfortran, patch] Silence a warning in libgfortran's runtime/error.c

This patch for PR 47972 uses __builtin_choose_expr instead of the current if-else, avoiding the type warning for the branch not taken. This was suggested by Jakub in the PR itself. Bootstrapped and regtested on x86_64-linux, OK to commit to trunk? FX typewarning.ChangeLog Description: Binary

[fortran, patch] Add DREAL simplification (last remaining elemental required for initialization expressions)

its last update). Regtested on x86_64-linux, comes with a testcase. OK to commit to trunk? FX dreal.ChangeLog Description: Binary data dreal.diff Description: Binary data

[fortran, patch] Substring simplification fix

oint of the substring is never less than zero. But, the actual condition should be: never less than the starting point. So, the attached patch corrects the fix for PR 48876 and fixes PR 50409. It expands the original testcase to include the code triggering the new PR. Regtested on x86_64-apple-

[fortran, patches] Two short patches to review

runk? I'll then add the testcase from the PR and commit. Cheers, FX

Re: [fortran, patches] Two short patches to review

review. I certainly > have no problems with committing the patch. Well, given the amount of compliment, I'm sure to screw up and then hide :) I'll get to it tomorrow morning, after some sleep. Thanks, FX

Re: [fortran, patch] Add DREAL simplification (last remaining elemental required for initialization expressions)

> PS: Any chance of wrapping the long line to less than 80 characters? Committed as rev. 181198, with the long line in intrinsic.c wrapped. Thanks for reviewing, FX

Re: [fortran, patches] Two short patches to review

> Although I suspect you've been lurking in the background, > welcome back to the land of gfortran hacking. Your first > screw up is free, additional screw ups require you to > fix your screw up and fix an additional bug as your reward. Attached patch committed as re

Re: [Patch, libfortran] Reduce default precision for list-directed and G0 real output

;t be neglected. At least, I'd suggest surveying how other compilers handle the issue (Sun, which I have at hand, does precise round-trip). FX

[fortran, patch] Follow-up "widechar error" patch

error is printed. I didn't handle it consistently, which should now be fixed. Bootstrapped and regtested on x86_64-apple-darwin11. OK to commit? FX errorfix.ChangeLog Description: Binary data errorfix.diff Description: Binary data

[fortran, patch] Fix handling of backtrace options in the library

as bootstrapped and regtested on x86_64-apple-darwin11, but is an area not covered by the testsuite. I have manually checked that running various types of abort, both in a pure Fortran code and a mixed C/Fortran (with C main), with all combinations -fno-backtrace/GFORTRAN_ERROR_BACKTRACE, beh

[fortran, patch] Allow displaying backtraces from user code

using BIND(C) Patch was bootstrapped and regtested on x86_64-apple-darwin11, also tested with "make info html pdf". OK for trunk? FX traceback2.ChangeLog Description: Binary data traceback2.diff Description: Binary data

[fortran, patch] Improve module version error messages

(which are currently numbers) to the user, and it also seems better to me: those are for internal use anyway, and not documented. They're useful only to us, and they're written in the module file anyway. So, bootstrapped and regtested on x86_64-apple-darwin11, OK for trunk? FX module.ChangeLog Description: Binary data module.diff Description: Binary data

[fortran, patch] Fix display of locus when source contains wide characters

t.f90. Bootstrapped and regtested on x86_64-apple-darwin11, OK for trunk? FX widechar_locus.ChangeLog Description: Binary data widechar_locus.diff Description: Binary data test.f90 Description: Binary data

Re: [Patch, Fortran] Add -Wc-binding-type warning

ortable and could be wrong, but probably is OK in most cases. It can have value, but not as a default warning I think. I don't think I can approve patches given that I'm not following gfortran development very closely, but if I could I would approve it, it seems OK :) FX

Re: [fortran, patch] Improve module version error messages

le I committed the patch based on Steve approval. Thanks for the review! FX

Re: [fortran, patch] Allow displaying backtraces from user code

inions on this issue, but I'll implement the new intrinsic if that's the consensus. Thanks, FX

Re: [fortran, patch] Fix display of locus when source contains wide characters

> Looks OK to me except for: > >> - for (; i > 0; i--) >> + for (; i > 0;) > > Might as well just make that a while loop. Indeed! Committed with a while loop, thanks for the review! FX

Re: [Patch, libfortran] PR 48931 Async-signal-safety of backtrace signal handler

ot safe to use here; only execle() and execve() are. Cheers! FX

Re: [Patch, libfortran] PR 48931 Async-signal-safety of backtrace signal handler

y of the PATH during initialization, and only search addr2line when really needed (which can be done with a static buffer and a series of call to execve(), can't it?) FX

Re: PATCH: Remove README.QMTEST

; at which that was written. Given that nobody is actively working on > making this work, it's best just to remove the file. There are also qmtest targets in gcc/Makefile.in. Shouldn't these be removed too? FX

[fortran, doc] Fix doc for LOG intrinsic

The attached patch clarifies the documentation of the LOG intrinsic by stating explicitly that it's the natural log function. Tested with "make info html pdf", OK to commit to trunk? FX log_doc.ChangeLog Description: Binary data log_doc.diff Description: Binary data

[fortran, committed] Fix CTIME code generation

The patch below fixes PR 47552, where we generate a variable of wrong type for the string length argument passed to CTIME. Patch was approved in the PR, was regtested on x86_64-linux. Committed as revision 170898. 2011-03-12 Francois-Xavier Coudert PR fortran/47552 * trans-

Re: [fortran, doc] Fix doc for LOG intrinsic

e". How about > "logarithm function with base 10"? If you want, you could could also add, > e.g., common/decadic logarithm to the index. OK, I kept both "logarithm with base 10" and "base 10 logarithm". Committed the attached patch as rev. 170899. FX log.diff Description: Binary data

[fortran, patch] Fix memory leak in arith_power()

lve.c:3977) ==26601==by 0x50BA26: resolve_code (resolve.c:8997) ==26601==by 0x50CFDB: gfc_resolve_blocks (resolve.c:8725) With the patch, the leak disappears. It was regtested on x86_64-linux. OK to commit to trunk? FX

[libgfortran, patch] More than 26 temporary files with weak mktemp()

The attached patch fixes half of PR 47439. On platform with weak or historical implementations of mktemp(), this function cannot generate more than 26 unique filenames for a given base. This happens in particular on Windows, and limits us to 26 scratch files open simultaneously. The patch works

[libgfortran, build] Remove AC_TRY_* macros from libgfortran configury

Dear Fortran maintainers, dear autoconf gurus, The attached patch replaces the deprecated AC_TRY_{COMPILE,LINK,RUN} macros in libgfortran configury with their AC_*_IFELSE equivalents. Now (4.7 just branched) seems a good time, and I think I didn't screw it too much because the regenerated confi

Re: [libgfortran, build] Remove AC_TRY_* macros from libgfortran configury

> Out of curiosity, did you update these manually, or did you run > autoupdate on the files? Thanks for the review. I updated manually, didn't know there was such a thing as autoupdate! FX

Re: [libgfortran, patch] More than 26 temporary files with weak mktemp()

bsence of mkstemp(). OK for trunk? FX mktemp_2.ChangeLog Description: Binary data mktemp_2.diff Description: Binary data scratch_1.f90 Description: Binary data

Re: [libgfortran, patch] More than 26 temporary files with weak mktemp()

Both OK. > - Don't set errno as we anyway loop until we successfully open a file > with O_CREAT|O_EXCL. No, if I don't set errno, the continue statement will not iteration the loop, as the condition (fd == -1 && errno == EEXIST) is false. Unless I don't understand what you mean. FX

Re: [libgfortran, patch] More than 26 temporary files with weak mktemp()

> The new test failed on Linux/x86. Yes, it might if you have a low limit on the number of concurrently open files. I've lowered the number to 30 (revision 171180). FX

Re: [PATCH] Testsuite, DWARF2: adjust regexp to match darwin output

Thanks Jeff, pushed as 94e68ce96c285e479736851f1ad8cc87c8c3ff0c FX

Re: Darwin: Replace environment runpath with embedded [PR88590]

Thanks a lot Alexandre for the review! FX

[PATCH] Testsuite, Darwin: skip PIE test

Hi, The recent commit of https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634347.html has made this test invalid. We now don’t emit __PIE__, and the test should be skipped on darwin. Fixes the new failure on x86_64-apple-darwin21. OK to push? FX 0001-Testsuite-Darwin-skip-PIE

[PATCH] Testsuite, i386: Fix test by passing -march

-darwin21. OK to push? FX 0001-Testsuite-i386-Fix-test-by-passing-march.patch Description: Binary data

[PATCH] Testsuite, Darwin: Fix trampoline warning

Heap-based trampolines are enabled on darwin20 and later, meaning that no warning is emitted. Fixes the test failure on x86_64-apple-darwin21 OK to push? FX 0001-Testsuite-Darwin-Fix-trampoline-warning.patch Description: Binary data

[PATCH] Testsuite, i386: Mark test as requiring dfp

Hi, The test is currently failing on x86_64-apple-darwin with "decimal floating-point not supported for this target”. Marking the test as requiring dfp fixes the issue. OK to push? FX 0001-Testsuite-i386-Mark-test-as-requiring-dfp.patch Description: Binary data

[PATCH] Testsuite, i386: Mark test as requiring ifunc

Hi, The test is currently failing on x86_64-apple-darwin. Marking the test as requiring ifunc fixes the issue. OK to push? FX 0001-Testsuite-i386-Mark-test-as-requiring-ifunc.patch Description: Binary data

Re: Darwin: Replace environment runpath with embedded [PR88590]

Hi, > +enable_darwin_at_rpath_$1=no I actually don’t understand why this one would have $1 in the name, unlike all other regenerated configure files. What value do we expect for $1 at this point in the file? That’s just plain weird. FX

Re: [PATCH] Testsuite, i386: Fix test by passing -march

> Well It can fail on x86_64-linux-gnu too if GCC was configured with > --with-arch=core2 for an example. > So having it, in this case, not being darwin specific would be > beneficial for all x86_64/i?86 targets. I pushed it as-is, meaning it will indeed apply to all x86_64/i?86 targets. FX

Re: [PATCH] Testsuite, i386: Mark test as requiring dfp

kind ping for this easy patch > Le 30 oct. 2023 à 15:19, FX Coudert a écrit : > > Hi, > > The test is currently failing on x86_64-apple-darwin with "decimal > floating-point not supported for this target”. > Marking the test as requiring dfp fixes the issue

Re: [PATCH] Include safe-ctype.h after C++ standard headers, to avoid over-poisoning

OK to push? FX > Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 > > When building gcc's C++ sources against recent libc++, the poisoning of > the ctype macros due to including safe-ctype.h before including C++ > standard headers such as , , etc, causes many

Re: [PATCH] Include safe-ctype.h after C++ standard headers, to avoid over-poisoning

> Hmm I recall trying it and finding a problem - was there some different fix > applied > in the end? The bug is still open, I don’t think a patch was applied, and I don’t find any email to the list stating what the problem could be. FX

Re: [PATCH] Include safe-ctype.h after C++ standard headers, to avoid over-poisoning

> I think it's an obvious change ... Thanks, pushed. Dimitry, I suggest you post the second patch for review. FX

<    1   2   3   4   5   6   7   >