Gcc Alternatives

gcc reviews and mentions

• Why GCC 1.42 on the Tektronix 4404 – with a C compiler from 1979
  1 project | news.ycombinator.com | 17 Dec 2024

  > (and of course eventually dropping support for Motorola 68010 on which the Tektronix 4404 is built)

  I don't think it ever did? Looking here[1] it still seems to be supported

  [1]https://github.com/gcc-mirror/gcc/blob/master/gcc/config/m68...

• Is C maintained like other languages with public repo, releases and issues?
  1 project | news.ycombinator.com | 14 Oct 2024

  There are some open source C compilers such as the GNU C compilers (https://github.com/gcc-mirror/gcc) and Clang (https://clang.llvm.org/get_started.html).

  There are also proprietary C compilers such as the Microsoft's C compiler (https://visualstudio.microsoft.com/vs/features/cplusplus/) and the Intel C compiler (https://www.intel.com/content/www/us/en/developer/tools/onea...).

  There are many others: https://en.m.wikipedia.org/wiki/List_of_compilers#C_compiler...

  Most mature C compilers will specify what version(s) of the C standard they implement so developer users can know what features are available. Many C compilers also implement non-standard extensions to the C language and libraries to be more competitive, overcome language shortcomings, or provide for specialized needs or development targets (e.g. features for embedded targets).

• Show HN: SSO – Small String Optimization
  4 projects | news.ycombinator.com | 12 Oct 2024

  But I'm still sure that there are several UB's in my code :)

  [1] https://tunglevo.com/note/an-optimization-thats-impossible-i...

  [2] https://github.com/gcc-mirror/gcc/blob/d09131eea083e80ccad60...

  [3] https://github.com/llvm/llvm-project/blob/4468d58080d0502a05...

• Whence '\N'?
  2 projects | news.ycombinator.com | 6 Oct 2024

  I was hoping GCC would do the same, leaving the decision about the value of '\n' to GCC's compiler, but apparently it hardcodes the numeric values for escapes[1], with options for ASCII or EBCDIC systems.

  [1] https://github.com/gcc-mirror/gcc/blob/8a4a967a77cb937a2df45...

• gcc VS lambda-mountain - a user suggested alternative
  2 projects | 10 Jun 2024
• Project Stage 1: Preparation(part-2)
  1 project | dev.to | 3 Jun 2024

  GCC github-mirror GCC Documentation GCC Internals Mannual Installing GCC

• Qt and C++ Trivial Relocation (Part 1)
  3 projects | news.ycombinator.com | 7 May 2024

  As far as I know, libstdc++'s representation has two advantages:

  First, it simplifies the implementation of `s.data()`, because you hold a pointer that invariably points to the first character of the data. The pointer-less version needs to do a branch there. Compare libstdc++ [1] to libc++ [2].

  [1]: https://github.com/gcc-mirror/gcc/blob/065dddc/libstdc++-v3/...

  [2]: https://github.com/llvm/llvm-project/blob/1a96179/libcxx/inc...

  Basically libstdc++ is paying an extra 8 bytes of storage, and losing trivial relocatability, in exchange for one fewer branch every time you access the string's characters. I imagine that the performance impact of that extra branch is tiny, and massively confounded in practice by unrelated factors that are clearly on libc++'s side (e.g. libc++'s SSO buffer is 7 bytes bigger, despite libc++'s string object itself being smaller). But it's there.

  The second advantage is that libstdc++ already did it that way, and to change it would be an ABI break; so now they're stuck with it. I mean, obviously that's not an "advantage" in the intuitive sense; but it's functionally equivalent to an advantage, in that it's a very strong technical answer to the question "Why doesn't libstdc++ just switch to doing it libc++'s way?"

• GCC 14.1 Release
  2 projects | news.ycombinator.com | 7 May 2024

  Upd: searching in the github mirror by the commit hash from the issue, found that https://github.com/gcc-mirror/gcc/commit/1e3312a25a7b34d6e3f... is in fact in the 'releases/gcc-14.1.0' tag.

  Even weirder that this one got swept under the changelog rug, it's a pretty major issue.

• C++ Safety, in Context
  8 projects | news.ycombinator.com | 12 Mar 2024

  > It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all. The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed.

  Can you find a link that substantiates your claim? You're throwing out some heavy accusations here that don't seem to match reality at all.

  Case in point, this was fixed in both major C++ libraries:

  https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d...

  https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9...

  So what C++ community refused to regard this as an issue and refused to fix it? Where is your supporting evidence for your claims?

• Std: Clamp generates less efficient assembly than std:min(max,std:max(min,v))
  4 projects | news.ycombinator.com | 16 Jan 2024
• A note from our sponsor - CodeRabbit
  coderabbit.ai | 23 Apr 2025

  Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR. Learn more →