Re: [PATCH 00/15] Fix data races with sub-longword accesses on Alpha

a lot of stuff. I knew you'd be working on the VAX backend as well ;-). Thanks so much for taking care of both. The community can't appreciate such work enough! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

สินเชื่อsme

ขออนุญาตผู้ดูเเลเเละเจ้าของกิจการด้วยครับ ของผมจะเป็นการเสนอเงินทุนเพื่อเจ้าของธุรกิจ ที่มีการจดทะเบียนในรูปแบบบริษัท หจก โรงงานอุตสาหกรรม ทั่วประเทศ ดอกเบี้ยต่ำ เริ่มต้นที่ 1-1.5% สอบถามฟรีพนักงานสุภาพ 0626697879 (ผู้จัดการฝ่ายการเงิน)

Re: [PATCH 00/15] Fix data races with sub-longword accesses on Alpha

Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. Do you have any plans for handling unaligned accesses for LRA as well? Thanks, adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist

Re: [PATCH v2] alpha: Add -mlra option

s > wasting cycles to look > at anything beyond C/C++ until those work with a mostly clean testsuite). So far I have found two issues: One is the LRA build failing on non-BWX targets and the other is the M2 failure. I'll open bug reports for these. In any case, I'm glad that Alpha b

Re: [PATCH v2] alpha: Add -mlra option

On Tue, 2024-10-15 at 16:18 +0200, John Paul Adrian Glaubitz wrote: > On Tue, 2024-10-15 at 07:56 -0600, Jeff Law wrote: > > Also note if we think it's basically working I can flip my tester to > > default to LRA. It bootstraps and regtests alpha once a week via qemu. &

Re: [PATCH v2] alpha: Add -mlra option

e[3]: *** Deleting file 'm2/gm2-compiler-boot/PHBuild.mod' terminate called after throwing an instance of 'unsigned int' make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/PCBuild.mod] Aborted make[3]: *** Deleting file 'm2/gm2-compiler-boot/PCBuild.mod'

Re: [PATCH v2] alpha: Add -mlra option

I still see it mentioned in config.gcc OpenVMS on Alpha seems to be still supported by HP [1]. Whether they're using the latest version of GCC, is a different question through. Adrian > [1] https://h41379.www4.hpe.com/openvms/openvms_supportchart.html -- .''`. John Paul

Re: [PATCH v2] alpha: Add -mlra option

gt; NB I spoke to Richard about it while at LPC 2024 recently. OK, good. FWIW, it *seems* that LRA seems to just work with EV56 as the baseline and the following replacements in the code: s/reload_in_progress/reload_in_progress || lra_in_progress/g Adrian -- .''`. John Paul A

Re: [PATCH v2] alpha: Add -mlra option

CC'ing Maciej who has also worked on Alpha Hi Uros, On Tue, 2024-10-15 at 12:29 +0200, Uros Bizjak wrote: > On Tue, Oct 15, 2024 at 11:09 AM John Paul Adrian Glaubitz > wrote: > > > > PR target/66207 > > * config/alpha/alpha.opt (mlra): New target option

[PATCH v2] alpha: Add -mlra option

PR target/66207 * config/alpha/alpha.opt (mlra): New target option. * config/alpha/alpha.cc (alpha_use_lra_p): New function. (TARGET_LRA_P): Use it. * config/alpha/alpha.opt.urls: Regenerate. Signed-off-by: John Paul Adrian Glaubitz --- gcc/config/alpha/alpha.cc | 10 +- gcc

[PATCH] alpha: Add -mlra

PR target/66207 * config/alpha/alpha.opt (mlra): New target option. * config/alpha/alpha.cc (alpha_use_lra_p): New function. (TARGET_LRA_P): Use it. * config/alpha/alpha.opt.urls: Regenerate. Signed-off-by: John Paul Adrian Glaubitz --- gcc/config/alpha/alpha.cc | 10 +- gcc

Re: RFH: Debugging GCC segfault with LRA-enabled SH backend

e; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. (unstable-sh4-sbuild)glaubitz@acrux:/srv/glaubitz/gcc/build$ Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist

Re: RFH: Debugging GCC segfault with LRA-enabled SH backend

eed to bisect which stage2/3 object was miscompiled and > then investigate the nature > of the miscompilation. A much more tedious process than addressing > remaining testsuite execution > FAILs. I'm not sure that bisecting works here as I suspect the issue is a result of t

RFH: Debugging GCC segfault with LRA-enabled SH backend

7;m not really a compiler expert). Does anyone else have any other suggestions? Thanks, Adrian PS: Would be great if we could upstream Linux SH native GDB support from [2] as well, in case any binutils-gdb maintainer is reading here. > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=552

Looking for someone to do paid work on SH backend

LRA as one of the most common failures that we're seeing downstream in distributions are register allocation failures such as the one reported in PR81426 [6]. Would there be anyone willing to work on switching the SH backend to LRA while being paid for it? And what would be their payment platfo

Re: [COMMITTED] Remove obsolete Solaris 11.3 support

y > similar. > > (And illumos on SPARC uses gcc4 to build the kernel [!], although > applications on Tribblix use gcc7. > Given the target market, having the latest and greatest toolchains isn't the > highest priority.) Well, at some point you will run into code t

Re: [COMMITTED] Remove obsolete Solaris 11.3 support

aris 11.3 would be considered obsolete. If it had been for Solaris 7, 8 or 9, I would totally understand. But even Solaris 10 is something that Oracle still supports [1]. Adrian > [1] > https://blogs.oracle.com/support/post/extended-support-for-oracle-solaris-10-operating-system -- .'

Re: [COMMITTED] Remove obsolete Solaris 11.3 support

u will get a satisfactory answer to that question. > > Removing Solaris 11.3 support might make sense in the future when SPARC > > support in Illumos has matured enough that people can switch over their > > machines. > > As has been noted, SPARC is on its way out for Illumos. Which makes my point to keep Solaris 11.3 support even more valid. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

Re: [COMMITTED] Remove obsolete Solaris 11.3 support

over their machines. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

Re: [PATCH] build: Check for cargo when building rust language

On Tue, 2024-04-09 at 10:00 +0200, Jakub Jelinek wrote: > On Tue, Apr 09, 2024 at 09:47:18AM +0200, John Paul Adrian Glaubitz wrote: > > Hello, > > > > On Mon, 2024-04-08 at 18:33 +0200, pierre-emmanuel.pa...@embecosm.com wrote: > > > The rust frontend requir

Re: [PATCH] build: Check for cargo when building rust language

d a Rust compiler for a target which is not supported by rustc (yet) when gccrs is supposed to build-depend on cargo which requires rustc? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

Re: Rust front-end patches v4

27;m looking forward to that. Again, thanks everyone for this fantastic effort! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

Re: Rust front-end patches v4

ffort and thanks a lot for this huge step forward for the Rust community. Can't wait to see this becoming available in the distributions :D. I will make sure we get the frontend enabled in Debian as soon as possible. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian De

[PATCH] coroutines: Fix promotion of class members in co_await statements [PR99576]

Hi, please have a look at the patch below for a potential fix that addresses the incorrect 'promotion' of members found in temporaries within co_await statements. To summarize my post in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576#c5, the recursive promotion of temporaries is too eager a

Re: Difference between 32-bit SPARCv9 and SPARCv8+?

on. Asking on top of that: Is it possible to configure gcc on sparc* with -mv8plus enabled by default? There seems to be only an option for setting the default value for -mcpu=, but -mv8plus doesn't seem to be supported as a default baseline in configure. Adrian -- .''`. John

Re: Difference between 32-bit SPARCv9 and SPARCv8+?

Hi! On 1/21/22 15:00, John Paul Adrian Glaubitz wrote: > While playing around with the compiler options trying to find a solution, I > made an interesting > discovery which is that GCC support 64-bit compare and swap on SPARCv8plus > but not on 32-bit > SPARCv9: > > gl

Difference between 32-bit SPARCv9 and SPARCv8+?

VE_SYNC_COMPARE_AND_SWAP_2 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1 glaubitz@gcc202:~$ Is this intentional? If yes, what is the exact difference between V8+ and 32-bit V9? Thanks, Adrian > [1] https://github.com/llvm/llvm-project/issues/53337 -- .''`. John Paul Adrian Gl

arm_arch8_5 and arm_arch8_6 target baselines in arm.c

re 8.2. */ int arm_fp16_inst = 0; Does anyone know whether the ARM backend is supposed to support the ARMv8.5 and ARMv8.6 baselines or are these only present in the Aarch64 backend? If the latter applies, I can just delete the two if statements in arm-rust.c. Thanks, Adrian > [1] https://gi

Re: [Ping] AVR CC0 conversion

en suggest to get the second patch committed as well, then close the bug report and claim your bounty. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

Re: [Ping] AVR CC0 conversion

ow - > https://gcc.gnu.org/git?p=gcc.git;a=commit;h=3ba781d3b5c8efadb60866c9743b657e8f0eb222 Awesome \o/. Should we wait for the second patch [1] to be merged as well before closing the PR? [2] Adrian > [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568659.html > [2] https://

Re: [Ping] AVR CC0 conversion

patches/2021-January/563779.html >> also) and verified that the results matched the original patchset. > > OK for trunk. Anything else that keeps us from merging the changes? Would be great to have the last backend besides CR-16 finally converted to MODE_CC on trunk. Adrian --

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

a bounty regularly checking Bountysource.com (Disclaimer: I'm not affiliated with them, I just chose them because the seem to be the most popular site) or similar campaign sites for such offers. Thanks, Adrian > [1] https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561489.html -- .

Re: Updating the backend status for h8300 on the wiki

On 12/7/20 9:06 AM, Eric Botcazou wrote: >> Now there are only AVR and CR16 that need to be converted. Great progress! > > Indeed, but why does CR16 not have the 'c' letter then? I noticed that as well. Adrian -- .''`. John Paul Adrian Glaubitz : :' : D

Re: Updating the backend status for h8300 on the wiki

to be converted. Great progress! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

Updating the backend status for h8300 on the wiki

Hi! Now that h8300 has been converted to use MODE_CC, it might be a good idea to update the documentation on the wiki [1] which still lists h8300 as being cc0. Adrian > [1] https://gcc.gnu.org/backends.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - g

Re: [PATCH] m68k: tag floating-point ABI used

ing binutils patch. > > If approved, I'll need a maintainer to commit on my behalf. This seems like a useful enhancement to the m68k backend. Any chance it can be picked up? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `

Re: [PATCH] m68k: tag floating-point ABI used

ing binutils patch. > > If approved, I'll need a maintainer to commit on my behalf. This seems like a useful enhancement to the m68k backend. Any chance it can be picked up? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `

Bountysource campaign for AVR backend now at $7,150

Hello! I just got a notification that the Bountysource campaign I created to modernize the AVR backend - primarily converting it to MODE_CC - has been bumped to $7,150 by Microchip [1]. I hope this will finally convince someone to complete the task :-). Adrian > [1] >

Bountysource campaign for converting the VAX backend

Hi! The NetBSD VAX porters have shown interest in a Bountysource campaign for their GCC backend [1], so I created one [2]. The backend can be tested with the help of the SimH emulator, see [3, 4]. Adrian > [1] http://mail-index.netbsd.org/port-vax/2020/04/16/msg003460.html > [2] &

Bountysource campaign for converting AVR to MODE_CC

get some more donations if we spread the word. But maybe someone is interested nonetheless to work on the AVR backend as a little sideline. Thanks, Adrian > [1] > https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases > [2]

Re: Regression on 32-bit powerpc?

On 3/5/20 9:11 AM, Jakub Jelinek wrote: > On Thu, Mar 05, 2020 at 08:56:37AM +0100, John Paul Adrian Glaubitz wrote: >> The latest gcc-10 snapshot in Debian fails to build in Debian with: > > What is the problem? > All that is present in what you posted are warnings. Okay, I w

Regression on 32-bit powerpc?

Wformat-diag] 2179 | pp_printf (pp, "\33]8;;%s\33\\", url); | ^~~ ../../src/gcc/pretty-print.c:2179:33: warning: spurious trailing punctuation sequence '\' in format [-Wformat-diag] 2179 | pp_printf (pp, "\33]8;;%s\33\\&q

Re: Bountysource campaign for gcc-rust?

Hi! On 12/27/19 12:26 AM, John Paul Adrian Glaubitz wrote: > For this reason, people have been asking for a Rust frontend for GCC similar > to > the one for Go. Now, there are actually two independent implementation of a > Rust > frontend for GCC [1, 2] being developed and

Bountysource campaign for gcc-rust?

and the desire of the community for an independent implementation, I expect the Bountysource campaign to be rather successful. Thanks, Adrian > [1] https://github.com/redbrain/gccrs > [2] https://github.com/sapir/gcc-rust/tree/rust -- .''`. John Paul Adrian Glaubitz :

Re: AW: [PATCH] m68k architecture: support ccmode + lra

ed the issues mentioned above. I would prefer getting all bugs in GCC reported to the GCC Bugzilla so that they can be resolved in GCC itself. We don't gain anything if important bug fixes are found in forks only. Adrian -- .''`. John Paul Adrian Glaubitz : :' : De

Re: AW: [PATCH] m68k architecture: support ccmode + lra

ble. We would have to enable -mlra in gcc by default and then trigger a rebuild for 10.000 source packages. But that would take a while to finish. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub

Re: AW: [PATCH] m68k architecture: support ccmode + lra

an internal compiler error which I reported to the GCC bugzilla. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

BountySource campaign for the cc0 transition of the AVR backend

goes :). Adrian > [1] > https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases > [2] > https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases > [3]

Re: [PATCH 2/4] The main m68k cc0 conversion

boards myself, but they are currently not set up and it would take me some time to get them running as I have never used them before. Adrian > [1] http://sysam.it/cff_amcore.html > [2] http://sysam.it/cff_stmark2.html -- .''`. John Paul Adrian Glaubitz : :' : Debian D

Re: [PATCH 2/4] The main m68k cc0 conversion

n mark in the "S" column should be removed. Same applies to i386, s390 and tilegx. These are all supported by qemu. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

Re: [PATCH 2/4] The main m68k cc0 conversion

On 11/25/19 1:38 PM, Bernd Schmidt wrote: > On 11/25/19 1:34 PM, John Paul Adrian Glaubitz wrote: >> Are all 4 + 2 patches in now? Thus, can we close the bug? > > We're missing one piece for better autoinc generation, but that's a > small optimization issue. The cc0 co

Re: [PATCH 2/4] The main m68k cc0 conversion

d some more testing and since I feel confident > that it really is in good shape now, I committed it. Thanks! Are all 4 + 2 patches in now? Thus, can we close the bug? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Frei

Re: [PATCH 2/4] The main m68k cc0 conversion

duction of > CC_STATUS_INIT in output_{and,ior,xor}si. You might want to check that. > > So unless there's objections over the next say 48-72 hrs, let's get the > kit in and we can iterate if there's further issues that need resolving. Any news on this? I would be in fa

Re: [PATCH 0/4] Eliminate cc0 from m68k

http://incoming.debian.org/debian-buildd/ buildd-unstable main The two lines starting with incoming are optional. They will just help getting newly built packages faster. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie

Re: [PATCH 0/4] Eliminate cc0 from m68k

ith a patched gcc-9 which may help finding more regressions. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

Re: [PATCH 0/4] Eliminate cc0 from m68k

Hi! On 11/15/19 2:45 PM, John Paul Adrian Glaubitz wrote: >> It works on the kernel build, at least. No idea if this *runs*, I just >> built it ;-) > > I just did that and kernel 5.3.9 built with gcc trunk with Bernd's patches > boots fine on qemu-m68k-system. I will

Re: [PATCH 0/4] Eliminate cc0 from m68k

rk there as well. Thanks to everyone, especially Bernd for helping to make the cc0 transition for m68k happen! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-

Re: Deprecating cc0 (and consequently cc0 targets)

;)]) > > Since "reload_completed" is referenced, this is only about the CC0 > conversion, right? Switching to LRA is not required for this step. I think it would be nice though that anyone who does the cc0 transition would also switch over to LRA unless that would be t

Re: Deprecating cc0 (and consequently cc0 targets)

ree, especially developer time. It's very valuable to everyone in the various m68k communities to have an up-to-date version of GCC available which is why so many people have donated for the cause. Thanks a lot for your time and input! Adrian -- .''`. John Paul Adrian Glaubitz :

Re: Deprecating cc0 (and consequently cc0 targets)

850 backend [3] but so far I don't understand enough of the register representation stuff to be able to know where to start. I'm seeing that all the "cc" attributes are being removed but not replaced? Adrian > [1] > https://www.bountysource.com/issues/80706251-m68k-c

Re: [PATCH] Skip check for dlopen() when compiling libstdcxx with avrlibc

On Sun, Sep 2, 2018 at 11:00 PM Jonathan Wakely wrote: > > On 02/09/18 22:18 +0300, Adrian Stratulat wrote: > >Hello, > > > >II tried compiling avr-gcc (AVR 8-bit target) with libstdcxx support, > >and even if I set the configure parameters to be "disable-

[PATCH] Skip check for dlopen() when compiling libstdcxx with avrlibc

st). I see that in the newlib case, the failing step is skipped, so I've just added branch to the condition, to skip the same check for avrlibc. Please double-check this patch, as it's my first commit to the GCC project, and I had to manually adjust a couple of things for the regeneration s

Re: [PATCH v2] libgo: Add support for sh

Thanks! Done: https://go-review.googlesource.com/c/gofrontend/+/84555 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

Re: [PATCH v2] libgo: Add support for sh

y are selected using environment variables (GO386, GOARM, etc.). Ok, so basically we should end up having only two GOARCHes for SH, being "sh" and "shbe", correct? If, yes, I can rebase my patch, make the requested changes and resubmit it to Gerrit. Adrian -- .'

Re: [PATCH v2] libgo: Add support for sh

necessary to distinguish SH3 and SH4 when choosing which files to build. What about Oleg's comment on the issue? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de

Re: [PATCH v2] libgo: Add support for sh

cacheline sizes, for example: https://go-review.googlesource.com/c/gofrontend/+/84555/1/libgo/configure.ac In total, we have four different SH targets. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Be

[PATCH v2] libgo: Add support for sh

distributions with SH support usually target sh3 and sh4 only. I have already signed the Google CLA in the past when I contributed a small patch to Kubernetes. Thanks, Adrian > [1] https://gcc.gnu.org/ml/gcc-patches/2017-12/msg0.html -- .''`. John Paul Adrian Glaubitz :

Re: [PATCH] libgo: Add support for sh

On 12/16/2017 10:24 AM, John Paul Adrian Glaubitz wrote: > I'm not sure whether all the definitions in libgo/configure.ac are > correct for SuperH. I made the assumptions that the values are similar > for ARM 32-bit and SuperH as these architectures are comparable, except > that

Re: [PATCH] libgo: Add support for sh

On 12/16/2017 10:24 AM, John Paul Adrian Glaubitz wrote: > The attached patch adds the necessary definitions to enable libgo > to build on sh (Hitachi SuperH). Forgot to mention: I can compile Go programs for SH with the patched gcc-7 which work fine on my Renesas SH7785LCR evaluation

[PATCH] libgo: Add support for sh

overflow if ioctl(fd, syscall.TIOCGWINSZ, unsafe.Pointer(&dimensions)) < 0 { ^ Makefile:3342: recipe for target 'exp/terminal.lo' failed Thanks, Adrian > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308#c10 > [2] http://man7.o

Re: [PATCH] Add header implementation of std::to_string for integers (PR libstdc++/71108)

> Assuming that the locale issue isn't a problem, can that be reused? The to_chars patch uses C++14 features, while to_string is C++11. If that was solved, it probably could be used. However, as far as I know, simply using to_chars in to_string would technically be suboptimal, because it needs thr

Re: [PATCH] Add header implementation of std::to_string for integers (PR libstdc++/71108)

> so a conforming program could notice the difference by either calling > std::setlocale. Unless I missed or misunderstood something about locale (please let me know if I did), I don't know of any way for locale to affect %d and its integer friends.

[PATCH] Add header implementation of std::to_string for integers (PR libstdc++/71108)

separately, or is mentioning it here enough? 2017-05-27 Adrian Wielgosik PR libstdc++/71108 * libstdc++-v3/include/ext/string_conversions.h: (__int_to_string, __format_uint): New. * libstdc++-v3/include/bits/basic_string.h: Use the new function. libstdc++-v3/include/bits

Re: [rfc] gcc trunk - libgomp thread affinity for freebsd

On 7 May 2015 at 00:57, Jakub Jelinek wrote: > On Wed, May 06, 2015 at 04:29:02PM -0700, Adrian Chadd wrote: >> This patch implements basic top level thread affinity support for >> freebsd. It doesn't yet implement thread affinity support for >> core/socket grouping yet

[rfc] gcc trunk - libgomp thread affinity for freebsd

ge. https://people.freebsd.org/~adrian/gcc/20150506-gcc-trunk-libgomp-1.diff I'd appreciate feedback/review. Thanks! -adrian