Re: Linking to windows library

在 2024-09-18 23:04, slipbits 写道: Win10 x86-64 cygwin v3.5.4 I'm using g++ to link my object modules non-windows object module and g++ includes a windows library. The library seems to need to have a winMain function, which my code does not have, and generates a linker error. I don't know why

Re: New calling convention gotham_call

在 2024-08-20 16:13, Frederick Virchanza Gotham via Gcc 写道: I want to write a new calling convention into the GNU g++ compiler, specifically for the x86_64 instruction set. The x64 calling convention is much more complex than x86. Each of the first four parameter is not only assigned an integer

Re: GCC 14.1.1 Status Report (2024-07-11)

在 2024-07-11 15:56, Jakub Jelinek via Gcc 写道: Status == The gcc-14 branch is open for regression and documentation fixes. It's time to plan for a GCC 14.2 release which should follow roughly two to three months after the .1 release. The plan is to do a release candidate for GCC 14.2 on Tue

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

在 2024-07-05 23:23, Alejandro Colomar via Gcc 写道: Hi Martin, On Fri, Jul 05, 2024 at 05:02:15PM GMT, Martin Uecker wrote: But when the thing gets non-trivial, as in strtol(3), GCC misses the -Wrestrict diagnostic, as reported in A pointer to `char` can alias any object, so in theory one could

Re: [PATCH] Fix rust on *-w64-mingw32

Attached is an alternative patch to functionalize `load_macros_array`. It allows GCC to build on x86_64-w64-mingw32. Not tested though, as I know no Rust. As before, please edit the patch at your disposal. -- Best regards, LIU Hao diff --git a/gcc/rust/checks/errors/borrowck/rust-borrow-checke

Re: [PATCH] Fix rust on *-w64-mingw32

在 2024-04-26 18:47, Arthur Cohen 写道: Hello, Thanks a lot for the patch :) I agree with Jakub that we should be using the GNU coding style in our call to std::replace - this is what we try to enforce in the rest of the Rust frontend. Please feel welcome to rewrite the patch as necessary. It w

[PATCH] Fix rust on *-w64-mingw32

Hello, Attached is a patch for fixing build issues on *-w64-mingw32. Please check and update at your leisure. 'gcc/system.h' contains a macro called `mkdir()` and there is no need to invoke `_mkdir()` within a conditional block. -- Best regards, LIU Hao diff --git a/gcc/rust/checks/errors/b

Re: Builtin for consulting value analysis (better ffs() code gen)

在 2024-03-14 23:33, Andrew Cooper via Gcc 写道: And for x86's arch_ffs(), unsigned int arch_ffs(unsigned int x) {     unsigned int res;     if ( __builtin_constant_p(x > 0) && x > 0 )     {         // Well defined when x is known non-zero         asm("bsf %1, %0" : "=r"(res) : "rm"(x)); Ev

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

在 2024-01-30 12:22, Hans-Peter Nilsson 写道: It's #APP #NO_APP, not /APP /NO_APP, for x86_64-linux, even for -masm=intel. For x86_64-w64-mingw64, GCC emits `/APP`; but Clang still emits `#APP`, as other targets. (https://gcc.godbolt.org/z/oj8vdGb78) That said, I guess you're going to modify

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

在 2024-01-23 17:03, Jan Beulich 写道: Hmm, that would suggest to me that the Dwarf code abuses the interface. A "name" certainly shouldn't be an expression. And hence the result of the example ought to be .long "LXXYY"-1# "LXXYY" minus one So I shouldn't have checked for `*` right? Th

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

在 2024-01-23 16:38, Jan Beulich 写道: Right, but this is very "draft". You can't blindly assume the gas you use actually can deal with quotation. Let's assume that for the time being, but there's something else; see below. .refptr.bx: .quad bx Sure, this one needs quoting then, t

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

在 2024-01-22 16:39, Jan Beulich 写道: Right, I did some work in that direction a while ago. But iirc there are still cases left to be addressed. Attached is a draft patch for GCC, bootstrapped on {i686,x86_64}-w64-mingw32 with GCC 13.2 and binutils 2.41.0. This addresses the issue when a bad n

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

在 2024-01-19 17:13, Jan Beulich 写道: But I see a severe issue with your aim at confining strict mode to compiler generated code only: In inline assembly (see your mentioning of APP / NO_APP above) you still potentially reference C symbols. So the ambiguities don't disappear in APP / NO_APP regions

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

在 2024-01-19 16:19, Fangrui Song 写道: It is also unfortunate that whether the displacement is an immediate or not change the behavior of brackets. mov eax, DWORD PTR 0 # mov$0x0,%eax mov eax, DWORD PTR [0]# mov0x0,%eax mov eax, DWORD PTR sym# mov0x0,%eax with

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

在 2024-01-18 17:02, Fangrui Song 写道: Thanks for the proposal. I hope that -masm=intel becomes more useful:) Do you have a list of assembly in the unambiguous cases that fail to be parsed today as a gas PR? For example, Not really. Most of these are results from high-level languages. For exampl

Re: RFC: Formalization of the Intel assembly syntax (PR53929)

在 2024-01-18 20:54, Jan Beulich 写道: I'm sorry, but most of your proposal may even be considered for being acceptable only if you would gain buy-off from the MASM guys. Anything MASM treats as valid ought to be permitted by gas as well (within the scope of certain divergence that cannot be changed

RFC: Formalization of the Intel assembly syntax (PR53929)

Hello, There hasn't been an solution to https://gcc.gnu.org/PR53929 since almost a dozen years ago, mostly due to compatibility with MASM. I was told that the ambiguity of Intel syntax should be classified as its own limitation and disrecommendation. Notwithstanding, I am proposing a permanen

Re: No subject

在 2024/1/5 21:44, Peter0x44 via Gcc 写道: Since you mentioned windows 7 specifically, some of the suggestions aren't really appropriate. I don't believe msys2 supports windows 7 anymore. Nobody mentioned Windows 7... maybe you mistook the question mark? :| MSYS2 itself no longer supports Windows

Re:

在 2024/1/5 18:34, Jonathan Wakely via Gcc 写道: There are also the https://nuwen.net/mingw.html and https://jmeubank.github.io/tdm-gcc/download/ projects, but they both use outdated versions of GCC at the moment. Wrong mailing list; but anyway, for bleeding-edge updates, with other well managed p

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

在 2023/12/8 21:59, Florian Weimer via Gcc 写道: [PATCH] libgcov: Call __builtin_fork instead of fork May I ask why it's not something like this? Even though there may be people who define `fork()` in globa

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

在 2023/12/1 17:09, Richard Biener via Gcc 写道: Hmm, so why's it then referenced and not "GCed"? The classical "solution" is to make the reference weak via sth like extern typeof(fork) fork () __attribute__((weak)); There are issues about weak symbols on mingw targets. Calls to weak functions c

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

在 2023/12/1 16:19, Eli Zaretskii via Gcc 写道: As far as I understand it, mingw doesn't have fork and doesn't declare it in , so it's not clear to me how this has ever worked. I would expect a linker failure. Maybe that doesn't happen because the object containing a reference to fork is only ever

Re: [PATCH 3/4] libbacktrace: work with aslr on windows

在 2023/11/22 03:35, Björn Schäpers 写道: I'll guess it is not needed here, but otherwise defines the macros max and min, they then conflict e.g. with C++'s std::max/std::min. So I consider it best practice to always define it, before including . The mingw-w64 header does not define them for C++

Request for update of documentation about `-mtune`

Hello, Today I have noticed that latest GCC documentation still has (https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-mtune-17) -mtune=cpu-type ... ... ‘intel’ Produce code optimized for the most current Intel processors, which are Haswell and Silvermont for this version of GCC. ...

Re: Warning specifically for a returning noreturn

在 2023/7/5 09:40, Andrew Pinski via Gcc 写道: It is wrong to use noreturn on a function other than one which has a return type of void as documented. https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-noreturn-function-attribute : ``` It does not make sense for a noreturn func

Re: Will GCC eventually support SSE2 or SSE4.1?

在 2023-05-26 23:40, Stefan Kanthak 写道: Feel free to propose this alternative here (better elsewhere, where you'll earn less laughter). But don't forget that this 23-bit mantissa will be all zeroes for quite some 64-bit (and even 32-bit) integers which are no power of 2, for example 0x803f

Re: Will GCC eventually support SSE2 or SSE4.1?

在 2023-05-26 14:46, Stefan Kanthak 写道: OOPS: why does GCC (ab)use the SSE2 alias "Willamette New Instruction Set" (... ...) OUCH: why does it FAIL to REALLY use SSE2, as shown in the comments on the right side? Please stop yelling like that. It makes you look like a naughty pupil. 14

Re: End of subscription

在 2023/5/19 20:59, Florian Weimer via Gcc 写道: * Jonathan Wakely via Gcc: Unfortunately even the Gmail web UI doesn't offer an unsubscribe option, despite knowing the mails come from a list and showing: mailing list: gcc@gcc.gnu.org Filter messages from this mailing list It does for me, under

Re: gcc-12.3 cannot build gcc-ada on Cygwin

在 2023/5/23 04:08, Achim Gratz 写道: I've backported the patch _and_ defined both WIN32_LEAN_AND_MEAN and COM_NO_WINDOWS_H (of which I find no reference anywhere in the sources, so it's probably doing something in the Windows headers?) and the build has been working through stage 3. That look lik

Re: gcc-12.3 cannot build gcc-ada on Cygwin

在 2023-05-22 00:35, Achim Gratz 写道: The error probably is in part a result of using g++ for the compilation, but other than that I don't really have an idea what goes on here or how to fix it. This looks like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300. It's because GCC defines `abort`

Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library

在 2023/5/6 18:45, Pali Rohár 写道: Hello! If I'm looking correctly, gcc 13 was already branched. So what revisiting this -mcrtdll= parameter now? Hello! I would like to remind this -mcrtdll= support for gcc. As said before, the idea sounds good. But in order for your patch to be checked in, yo

Re: a small C (naive) program faster with clang than with gcc

在 2023/4/26 00:01, Andy via Gcc 写道: I see it in godbolt GCC compiles to: movsx eax, BYTE PTR [rdi+2] cmp al, 9 ja .L42 Clang: movzx edx, byte ptr [rdi + 2] cmp edx, 9 ja .LBB0_40 GCC extend with sign, Clang with zero. cmp with 32 bit register is apparently faster than 8bit As for extension, i

Re: MIN/MAX and trapping math and NANs

在 2023/4/11 16:51, LIU Hao via Gcc 写道: My interpretation is that if one argument is a SNaN and the other is not, `fmax()` shall return the SNaN unchanged, without converting it to a QNaN. (F.10.9.2 The fmax functions, ISO/IEC 9899:2017) 'the other is not' means the other op

Re: MIN/MAX and trapping math and NANs

在 2023/4/11 16:00, Richard Biener via Gcc 写道: I think without NaNs MIN/MAX cannot raise any exceptions (I'm not even sure whether MIN/MAX involving NaN will set invalid, but most certainly with sNaN it will trap and return a quiet NaN?). The C standard doesn't document any exceptions for fmax/fmi

Re: Buildbot (Sourceware): gcc - failed configure (failure) (master)

在 2023-01-31 21:13, Thomas Schwinge 写道: Hi! On 2023-01-30T14:50:08-0800, Steve Kargl via Fortran wrote: Does the skull and crossbones convey anymore info than the rest of the subject line Buildbot (Sourceware): gcc - failed configure (failure) (master) They convey as much additional i

Re: [PATCH 3/4] libbacktrace: work with aslr on windows

在 2023-01-21 12:05, Eli Zaretskii via Gcc 写道: I'm not sure I follow the logic. A program that calls GetModuleHandleW will refuse to start on Windows that doesn't have that API. So any version before XP is automatically excluded the moment you use code which calls that API directly (i.e. not thr

Re: Widening multiplication, but no narrowing division [i386/AMD64]

在 2023/1/9 20:20, Stefan Kanthak 写道: Hi, GCC (and other C compilers too) support the widening multiplication of i386/AMD64 processors, but DON'T support their narrowing division: QWORD-DWORD division would change the behavior of your program. Given: ``` uint32_t xdiv(uint64_t x, uin

Re: B^HDEAD code generation (AMD64)

在 2023/1/9 19:48, Thomas Koenig via Gcc 写道: On 09.01.23 12:35, Stefan Kanthak wrote: 20 superfluous instructions of the total 102 instructions! The proper place for bug reports is https://gcc.gnu.org/bugzilla/ . Feel free to submit these cases there. Created https://gcc.gnu.org/bugzilla/show

Re: Why is there no libatomic default implementation using gthr.h?

在 2022/12/19 20:45, Sebastian Huber 写道: On 19/12/2022 13:41, Jonathan Wakely wrote: 3. Use gthr as the default implementation of libatomic. I have no objection to doing this, but I don't see why you need to touch libstdc++ to do it. Just make libatomic create its own copy of gthr.h (if a fallba

Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library

在 2022-12-04 20:16, Pali Rohár via Gcc 写道: Hello! I would like to ask gcc people, what do you think about such proposed -mcrtdll= parameter? There are lot of unofficial gcc patches which implement this -mcrtdll= parameter and this parameter is present in more gcc forks. So it looks like that thi

Re: GNU = Junkware

在 2022-11-26 17:20, Dave Blanchard 写道: No, I'm not trolling, just venting here for a moment. So sick of garbage ass, crusty junkware that's always a battle to the death to accomplish anything. I really understand where Liu Hao was coming from yesterday when he was in here raging against the AT

Re: Please, really, make `-masm=intel` the default for x86

在 2022/11/25 17:32, Jakub Jelinek 写道: So just use -masm=intel yourself and don't force it on others. Other people are familiar with AT&T syntax rather than Intel syntax, in fact, as history shows, Intel syntax is a second class citizen that often takes years to fix up for new instructions. The

Re: Please, really, make `-masm=intel` the default for x86

在 2022/11/25 16:50, Marc Glisse 写道: On Fri, 25 Nov 2022, LIU Hao via Gcc wrote: I am a Windows developer and I have been writing x86 and amd64 assembly for more than ten years. One annoying thing about GCC is that, for x86 if I need to write I piece of inline assembly then I have to do it

Re: Please, really, make `-masm=intel` the default for x86

在 2022/11/25 15:48, Dave Blanchard 写道: While I sympathize with the desire to get rid of crud (and I agree that AT&T syntax is crud), as stated above it wouldn't really make a practical difference. For distro maintainers it would likely break some/many older packages which assumed the old defau

Re: Please, really, make `-masm=intel` the default for x86

在 2022/11/25 15:37, Hi-Angel 写道: Why? A default is merely a default. I don't really see why changing that should help you specifically. A decision "which assembly syntax to use" is one that makes a project like ones you're contributing to, not GCC. If they decided to use AT&T syntax, they won't s

Please, really, make `-masm=intel` the default for x86

I am a Windows developer and I have been writing x86 and amd64 assembly for more than ten years. One annoying thing about GCC is that, for x86 if I need to write I piece of inline assembly then I have to do it twice: one in AT&T syntax and one in Intel syntax. The AT&T syntax is an awkward for

Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library

在 2022/11/20 23:06, Pali Rohár 写道: Thank you for explaining more details. My simple patch takes this in care and defines also __MSVCRT_VERSION__ to the correct value based on -mcrtdll parameter. Apologies for reading your message only partially. I thought your patch was the same as MSYS2's. It

Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library

在 2022-11-20 20:53, Pali Rohár 写道: Hello! I would like to propose a new parameter for gcc: -mcrtdll= to allow specifying against which Windows C Runtime library should be binary linked. On Windows there are more crt libraries and currently gcc links to libmsvcrt.a which is in most cases symlink t

GCC 13 bootstrap failure on i686-w64-mingw32

This is caused by 2efb237ffc68ec9bb17982434f5941bfa14f8b50, which has references to `strchrnul`, which does not exist on i686w-64-mingw32: ``` g++ -std=c++11 -fno-PIE -c -DIN_GCC_FRONTEND -g -D__USE_MINGW_ACCESS -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno

Re: why does gcc jit require pthread?

在 2022-11-19 19:27, Jonathan Wakely 写道: I rebased the patch and re-tested with those options, and all tests passed again: === jit Summary === # of expected passes15081 The patch is OK for trunk if you have favorable answers for the above two questions. Thanks

Re: why does gccgit require pthread?

在 2022-11-07 20:57, Jonathan Wakely 写道: It would be a lot nicer if playback::context met the C++ Lockable requirements, and playback::context::compile () could just take a scoped lock on *this: Yeah yeah that makes a lot of sense. Would you please just commit that? I don't have write access t

Re: why does gccgit require pthread?

在 2022/11/7 15:03, Andrew Pinski 写道: The win32 thread model does not have `std::mutex`; but there is no `pthread_mutex_t` either, so it does not build either way. Oh, but I would assume it will later on right? There has been effort on C++11 threading support for win32 thread model, but I ha

Re: why does gccgit require pthread?

在 2022-11-07 12:37, Andrew Pinski 写道: The original code which used pthread was added in GCC 5 way before GCC moved to being written in C++11 which was only in the last 3 years. pthread_* functions were the best choice at the time (2014) but now GCC is written in C++11, I don't see any reason not

why does gccgit require pthread?

Greetings, At the moment, there are references to pthread mutexes in 'gcc/jit/libgccjit.cc' and 'gcc/git/jit-playback.cc'. The former was introduced by 63b2923dc6f57e74d964a9cf14f4ba595ab14ed9 in 2020, while the latter was introduced by 38771e4e1fdacfbdac5a14e50fcc0538577b1bdb in 2014. Does t

Re: Issue with dllexport/dllimport inline function

在 2022/11/2 02:11, xclae...@gmail.com 写道: Oh, that seems to be working now. Still got a small issue, glib compiles with -Werror=missing- prototypes: ../foo.h:7:5: error: no previous prototype for ‘g_strcmp0’ [- Werror=missing-prototypes] I'm a bit lost with what the prototype would look like i

Re: Issue with dllexport/dllimport inline function

在 2022-11-01 23:38, xclae...@gmail.com 写道: Thanks a lot for your help. Sorry for late reply, but I gave your trick a try and it did not work: ``` /home/xclaesse/programmation/inline-example/builddir/../foo.h:7: multiple definition of `g_strcmp0'; libfoo.dll.p/foo.c.obj:/home/xclaesse/programmati

Re: GCC trunk bootstrap failure on i686-w64-mingw32

在 2022-10-29 20:15, Eric Botcazou 写道: So what could be causing it? An oversight in https://gcc.gnu.org/pipermail/gcc-cvs/2022-August/370830.html has broken --disable-sjlj-exceptions. That's now fixed. Thank you. Rebuilding now. -- Best regards, LIU Hao OpenPGP_signature Description: Op

GCC trunk bootstrap failure on i686-w64-mingw32

Greetings, Since at least a week ago, GCC trunk fails to bootstrap with a lot such errors during stage1: ``` D:\lh_mouse\GitHub\MINGW-packages\mingw-w64-gcc\src\build-MINGW32\i686-w64-mingw32\libstdc++-v3\src\c++11/../../../../../gcc/libstdc++-v3/src/c++11/functexcept.cc:74: undefined refer

Re: Issue with dllexport/dllimport inline function

在 2022/10/12 02:37, xclae...@gmail.com 写道: Build it with: meson setup builddir --cross-file cross_file_mingw64.txt ninja -C builddir/ And it fails with: That's because you compiled it as C. I used g++ to compile these, and there was no such error. For C, this inline issue is going to

Re: Issue with dllexport/dllimport inline function

在 2022-10-11 22:26, xclae...@gmail.com 写道: #ifdef GLIB_COMPILATION # define _GLIB_API _GLIB_EXPORT # define GLIB_INLINE __attribute__((__dllexport__)) __attribute__((__gnu_inline__)) extern inline This is not correct. Typically, `dllexport` indicates that 'I want an external definition' but

Re: Issue with dllexport/dllimport inline function

在 2022/10/11 21:28, LIU Hao via Gcc 写道: Did you have any declarations that had no `__gnu_inline__`? GNU inline functions are supposed to be emitted out of line, even when its address is taken. This should be 'to be never emitted out of line'. Sorry for that. -- Best regard

Re: Issue with dllexport/dllimport inline function

在 2022/10/11 21:10, xclae...@gmail.com 写道: Le mardi 11 octobre 2022 à 13:00 +0800, LIU Hao a écrit : you may try    ```    __attribute__((__gnu_inline__))    extern inline    int g_strcmp0(const char*, const char*) { ...    ``` Thanks, I gave that a try but I get many: multiple def

Re: Issue with dllexport/dllimport inline function

在 2022/10/11 00:39, Xavier Claessens via Gcc 写道: Is there a trick to get that working with GCC? Or should that issue be reported somewhere? Probably. This Microsoft `dllimport` with `inline` has the same semantics with GNU `extern inline`, so may be it's an alternative. So instead of `

Re: Using CMake for building GCC

在 2022-09-11 22:29, Junk Trash via Gcc 写道: Hi, I want to get the opinions of GCC developers regarding adding CMake as a build system for GCC. Is it something you would like, something you are neutral about, or something you are strongly against? Thanks for your valuable feedback! https://

Re: GCC 12.0.1 Status Report (2022-04-28)

在 2022-04-28 22:59, Jakub Jelinek via Gcc 写道: Status == We have reached zero P1 regressions today and releases/gcc-12 branch has been created. GCC 12.1-rc1 will be built likely tomorrow. The branch is now frozen for blocking regressions and documentation fixes only, all changes to the branc

Re: Reqister to become gcc mirror site

在 3/5/22 07:21, Gerald Pfeifer 写道: Slovakia, Bratislava: http://gcc.fyxm.net/";>gcc.fyxm.net, thanks to Jan Teluch (ad...@2600.sk) +Taiwan, Hsinchu: https://free.nchc.org.tw/gcc/";>nchc.org.tw, thanks to FSLab Team, NCHC (fs...@nchc.org.tw) Please stop naming Taiwan like that. `China, Taiwa

Re: Bootstrap failure of GCC 11.1.1 on x86_64-w64-mingw32

在 2021-07-08 17:49, Richard Biener 写道: Maybe it was the EH format changes or dwarf5 stuff backported, CCing Eric. It would be nice to see the conftest.exe to see what's wrong (if there's anything obvious). Can you open a bugreport please? If you can bisect to the offending rev. that would be

Bootstrap failure of GCC 11.1.1 on x86_64-w64-mingw32

Last known good build was on 06/21, but I now keep getting this error: /d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/gcc/libgomp/configure: line 4071: ./conftest.exe: cannot execute binary file: Exec format error I am not sure whether it is a GCC issue or a binutils one. I hav

Re: Why does printing a pointer cause it to escape?

在 6/23/21 6:32 PM, Erick Ochoa via Gcc 写道: I notice that in these special cases, the printf function is nowhere to be found, and if one prints a pointer using printf the pointer points to escaped memory. Why is this the case? I think it is due to the incapability of ruling out the possibilit

Re: GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12

在 2021-06-16 23:22, Jonathan Wakely via Gcc 写道: Is there someone who an dig into the commit below and try to find out how the author field was incorrectly set? That gets set when the local commit is done, before pushing it to the server. I don't think there's any way to find out how/why that ha

Re: [RFC] Implementing detection of saturation and rounding arithmetic

在 5/12/21 5:13 PM, Tamar Christina via Gcc 写道: int f (int a, int b) { int res; if (__builtin_add_overflow (a, b, &res)) { if (res >= 0) return INT_MAX; else return INT_MIN; } return res; } Should be recognized as satur

Re: removing toxic emailers

在 17/04/2021 16.27, Aaron Gyes 写道: As far as I understand it Chris Punches lives in North America. Only 2% of the world population lives in the US, indeed, most live in China. It’s interesting the unkind reaction Liu Hao received in this very thread when they encountered the arguments making a

Re: Copyright Assignment Form

在 2021/4/10 下午3:22, Jonathan Wakely 写道: I don't about David, but the reason I take it off-list is that there is more than one form that might be appropriate, depending on the contributor's situation. The forms are available online (e.g. in the gnulib repo) but discussing what is suitable, and

Re: GCC association with the FSF

在 2021/4/10 上午2:02, Christopher Dimech via Gcc 写道: It is an assessment of what you propose. The removal of people from all positions is a political statements. I have no problem with political discussions and certainly don't take instructions from you, to say the least! What you talk about is

Re: Copyright Assignment Form

在 2021/4/9 下午11:06, David Edelsohn via Gcc 写道: Replied privately. Excuse me, but why this has to be done privately? I generally expect there to be such a form that people may download, fill and submit without public acknowledgements. Please forgive me if I am being too curious. -- Best re

Re: gcc can't process some utf-8 characters

在 2021/1/14 上午9:47, Roy Qu via Gcc 写道: > I use "gcc -finput-charset=utf-8 -fexec-charset=gb2312" to compile utf-8 > encoding source files under windows. Most of the time it works well, but > when the source file contains some characters such as "—", gcc will fail > and the error message is: "[Err

Re: [RFC] Increase libstdc++ line length to 100(?) columns

在 2020/11/27 下午4:14, Richard Biener 写道: > > I prefer the ( on the next line. The argument list can be two spaces > indented from > the function name or "right justified" (I think the latter looks > visually better). > The right justification thing looks reasonable. For example, I think this ``

Re: [RFC] Increase libstdc++ line length to 100(?) columns

在 2020/11/27 上午7:50, Jonathan Wakely via Gcc 写道: > I've touched on the subject a few times, e.g. > https://gcc.gnu.org/pipermail/gcc/2019-December/230993.html > and https://gcc.gnu.org/pipermail/gcc/2019-December/231013.html > > Libstdc++ code is indented by 2 columns for the enclosing namespace,

Re: I absolutely despise the whole -fexec-charset and locale garbage.

在 2020/11/19 上午2:31, sotrdg sotrdg via Gcc 写道: > The locale shit is not thread safe. printf(“Hello World %d”,3) is undefined > behavior under none-UTF-8 exec-charset. WTF WTF WTF. > > This is purely garbage tbh. Just remove this toggle. I want encoding, I can > use another library. I do not need

Re: Coding style for C++ constructs going forward

在 2020/8/13 上午2:40, David Blaikie 写道: > > Then use of `auto*` would make it easier for you to spot use of plain > pointers in your projects & scrutinize them further? > My point is that `auto*` conveys no more information than `auto`. The absence of `*` does not imply the object (pointer) being

Re: Coding style for C++ constructs going forward

在 2020/8/11 下午9:55, Nathan Sidwell 写道: > > I agree, it's the way I use auto.  I particularly like the >    auto *foo = expr; > idiom, when you're getting a pointer, but the type of the pointee is clear.  > It informs how you use 'foo'. > > Personally I dislike this syntax. Pointers are objects

Re: Two new proposals to the upcoming C2X standard

在 2020/5/29 18:35, Andreas Schwab 写道: > On Mai 29 2020, David Brown wrote: > >> So my counter-proposal for you would be to recommend gcc's "typeof" as a >> new keyword (spelt "_Typeof", with "typeof" as a macro in , >> in solid C tradition). > > Or call it _Decltype/decltype, following C++. > >