Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
gcc vs clang: why/when do you stay/switch?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
CaptainBlood
Advocate
Advocate


Joined: 24 Jan 2010
Posts: 3954

PostPosted: Sun Dec 01, 2024 10:34 am    Post subject: gcc vs clang: why/when do you stay/switch? Reply with quote

More and more topics have clang as an origin of issue.
Likely only because more and more users are switching. no judging on clang here.

I've just noticed stage3 has a LLVM version.

LTO kernel requires clang as gcc in this respect is simply not there.

IIUC clang is expected to compile faster in many cases which would be a time-saver when testing source packages or ebuilds.

As far as performance is concerned I know there are packages which do perform much faster when build with clang.
Defining such a list isn't a easy task. :)

There can be other reasons, unlisted there. :roll:

Anyone having switched at package level or globally to share reasons of choice, whatever their stage3 was?

Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here, i.e. a countermeasure to portage implicit braces, belt & diaper paradigm
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. "


Last edited by CaptainBlood on Wed Dec 04, 2024 12:34 am; edited 5 times in total
Back to top
View user's profile Send private message
Zucca
Moderator
Moderator


Joined: 14 Jun 2007
Posts: 3761
Location: Rasi, Finland

PostPosted: Sun Dec 01, 2024 11:19 am    Post subject: Reply with quote

I've used musl+llvm toolchain on amd64. And I'm about to set up one once again. Last time I ran it, it needed some extra work with some of the packages. And I needed to mask gcc.
I do run (not updated recently) glibc+llvm on my MacBook Air M2 which is arm64 obviously. I have hopes llvm could give better optimizations on Apple ARM since Apple itself uses llvm quite a lot. There hasn't been problems, but I don't use it very much because of the lack of memory (only 8G with no possibility to upgrade).
_________________
..: Zucca :..

My gentoo installs:
init=/sbin/openrc-init
-systemd -logind -elogind seatd

Quote:
I am NaN! I am a man!
Back to top
View user's profile Send private message
Goverp
Advocate
Advocate


Joined: 07 Mar 2007
Posts: 2183

PostPosted: Sun Dec 01, 2024 12:21 pm    Post subject: Reply with quote

I switched to Clang 'cos it uses less space to compile qtwebengine, and hence can compile it faster. Having done that for qtwebengine, I thought I'd try it on more and more stuff until now it's my default*. My reason for that is Clang & LLVM are much newer than gcc, and (as Captain Blood mentioned, works better with LTO), and I assume large software suffers with age.
Also, AFAIK the only way to compile a kernel with LTO is with Clang.

* I say "default", as I have a package.env file for those where Clang breaks, but I know that the Gentoo devs also override the use of Clang for packages they know are broken, so I probably use Clang rather less often than I think!
_________________
Greybeard
Back to top
View user's profile Send private message
CaptainBlood
Advocate
Advocate


Joined: 24 Jan 2010
Posts: 3954

PostPosted: Sun Dec 01, 2024 1:13 pm    Post subject: Reply with quote

Goverp wrote:
(as Captain Blood mentioned, works better with LTO)
Didn't said that, only mentioned clang dedicated kernel LTO feature.
Not saying that ain't true, I have no experience to share...

Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here, i.e. a countermeasure to portage implicit braces, belt & diaper paradigm
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. "
Back to top
View user's profile Send private message
Spanik
Veteran
Veteran


Joined: 12 Dec 2003
Posts: 1007
Location: Belgium

PostPosted: Mon Dec 02, 2024 9:09 am    Post subject: Reply with quote

I have a couple of packages that I use clang because when compiling them with gcc I hit a hardware issue with the cpu (AMD Epyc). So more a workaround then anything else.
_________________
Expert in non-working solutions
Back to top
View user's profile Send private message
mirekm
Apprentice
Apprentice


Joined: 12 Feb 2004
Posts: 219
Location: Gliwice

PostPosted: Mon Dec 02, 2024 9:12 am    Post subject: Reply with quote

I stay on gcc. The main reason is security. For gcc there is hardened version.
The other thing is that clang allow bad quality code to work, and you will never know where is a hole allowing attack to your computer.
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22772

PostPosted: Mon Dec 02, 2024 1:31 pm    Post subject: Reply with quote

Both gcc and clang allow bad quality code to compile, as long as the code is standards-compliant. It is fairly straightforward to write a program that both compilers will accept, but that has serious security problems when exposed to untrusted input. Therefore, I think it is not fair to blame clang for allowing bad quality code to work.
Back to top
View user's profile Send private message
CaptainBlood
Advocate
Advocate


Joined: 24 Jan 2010
Posts: 3954

PostPosted: Mon Dec 02, 2024 10:32 pm    Post subject: Reply with quote

mirekm wrote:
I stay on gcc. The main reason is security. For gcc there is hardened version.

So IIUC ebuild hardened kernel is currently gcc only, right?

Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here, i.e. a countermeasure to portage implicit braces, belt & diaper paradigm
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. "
Back to top
View user's profile Send private message
mirekm
Apprentice
Apprentice


Joined: 12 Feb 2004
Posts: 219
Location: Gliwice

PostPosted: Tue Dec 03, 2024 6:25 am    Post subject: Reply with quote

Hu wrote:
Both gcc and clang allow bad quality code to compile, as long as the code is standards-compliant. It is fairly straightforward to write a program that both compilers will accept, but that has serious security problems when exposed to untrusted input. Therefore, I think it is not fair to blame clang for allowing bad quality code to work.


But what I see trying to compile chromium with gcc, there are frequently compilation errors like missing includes of header files, private parts of objects used globally, etc. All these get compiled clearly with clang, while you get errors with gcc.
What that says?
Back to top
View user's profile Send private message
mirekm
Apprentice
Apprentice


Joined: 12 Feb 2004
Posts: 219
Location: Gliwice

PostPosted: Tue Dec 03, 2024 6:30 am    Post subject: Reply with quote

[quote]So IIUC ebuild hardened kernel is currently gcc only, right?
/quote]

This I don't know. I didn't try to compile kernel with clang. As far I remember, on newest kernels there were patches to compile it with clang.
Back to top
View user's profile Send private message
bstaletic
Guru
Guru


Joined: 05 Apr 2014
Posts: 385

PostPosted: Tue Dec 03, 2024 7:18 am    Post subject: Reply with quote

mirekm wrote:
But what I see trying to compile chromium with gcc, there are frequently compilation errors like missing includes of header files, private parts of objects used globally, etc. All these get compiled clearly with clang, while you get errors with gcc.
What that says?


Taking your claims about compile time errors at face value, it only says that one specific project is only tested with clang.
Go look at magic_enum and you'll see the codebase that reaches into the implementation specific stuff of all three common C++ compilers.
Automagically printing enumerators is not possible in standard C++ and won't be until proposal P2996 gets implemented.

Even funnier is that operator| was absolutely not portable even between compiler versions, when it comes to piping user defined views. We needed P2387 to give us std::ranges::range_adaptor_closure and std::bind_back.
That did not stop some brave souls to find the implementation details for each compiler that supported C++20 at the time and do a lot of std::_Compiler_specific_things.
Back to top
View user's profile Send private message
CaptainBlood
Advocate
Advocate


Joined: 24 Jan 2010
Posts: 3954

PostPosted: Tue Dec 03, 2024 10:29 am    Post subject: Reply with quote

mirekm wrote:
CaptainBlood wrote:
So IIUC ebuild hardened kernel is currently gcc only, right?
This I don't know. I didn't try to compile kernel with clang. As far I remember, on newest kernels there were patches to compile it with clang.

My bad, :oops: You must be talking stage3 then?

Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here, i.e. a countermeasure to portage implicit braces, belt & diaper paradigm
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. "
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22772

PostPosted: Tue Dec 03, 2024 1:36 pm    Post subject: Reply with quote

To extend on bstaletic's response to mirekm's comments about Chromium, I would add that if gcc is rejecting these files, and clang is accepting them, then it seems more likely that gcc is being strict about requiring correct inputs and clang is being sloppy and allowing invalid inputs. However, mirekm's earlier post read to me more like a complaint that clang was allowing insecure code to succeed. There is an important distinction between code which is unsafe to run because it may do something bad versus code that is safe to run, but painful to read and compile. Assuming mirekm's comments about Chromium are accurate, we know only that some unspecified version is painful to compile. It might be perfectly safe and secure to run once it is compiled. Without a specific version and specific error messages, we cannot determine the true extent of the problems with Chromium.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 20501

PostPosted: Tue Dec 03, 2024 11:17 pm    Post subject: Reply with quote

I dislike having only a single option. So while I'm glad they both exist, I'd ideally only need one installed.

I use both, albeit not for anything meaningful. gcc from the command line, clang in make files. The former including a link to 'gcc' while the latter does not.
_________________
Quis separabit? Quo animo?
Back to top
View user's profile Send private message
pa4wdh
l33t
l33t


Joined: 16 Dec 2005
Posts: 892

PostPosted: Wed Dec 04, 2024 3:55 pm    Post subject: Reply with quote

I"m using gcc (unless some ebuild forces otherwise).

I know clang/llvm exists, but i don't know a single reason to use one or the other. For now i'm using gcc because it's the default.
I hope with this topic i'll learn something about both and be able to make an informed decision :).
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com
Back to top
View user's profile Send private message
flysideways
Guru
Guru


Joined: 29 Jan 2005
Posts: 497

PostPosted: Thu Dec 05, 2024 8:45 pm    Post subject: Reply with quote

I have not gone out of my way to use clang, but, after the runaway amount of memory webkit-gtk needs and the upstream recommendation to use clang, my 8G Gentoo Pi 5 has per package invocation of clang for webkit-gtk. With clang, it compiles fine with 4 threads and about the same time as earlier gcc builds when 8G would still support 4 threads.

Using gcc, I was down to 2 threads to avoid out of memory errors. Even with 2 threads, there were occasions I noticed the system memory was at 6.6G.

Time permitting, it would be interesting to do the llvm install.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum