Re: [PATCH v17 2/2] c: Add __countof__ operator

On Fri, 8 Nov 2024, Alejandro Colomar wrote: >I've just checked that JeanHeyd opened a survey about the name. >It's here: . Yes, I saw it on Fedi, where it was announced big, and filled it in. Thanks, //mirabilos -- 11:56⎜«liwakura:#!/bin/mksh

Re: [PATCH v17 2/2] c: Add __countof__ operator

Alejandro Colomar dixit: >Yes; there are four n papers. See below, plus the history of why >four papers. Thanks, will look at them but probably on Tuesday. >> >- _Nelementsof >> >- _Nelemsof >> >> If you want to shorten elements, elts is probably seen more >> often than elems, at least in

Re: [PATCH v17 2/2] c: Add __countof__ operator

Hi Alejandro, >On Sun, Oct 27, 2024 at 01:40:23AM GMT, mirabilos wrote: >> Not too sure what the root context of this thread is, but in BSD land > >The root context is that > >- _Lengthof was added to C2y in the Minnesota meeting. It was proposed where/how would this be used for? Also, do you h

Re: [RFD] Extremely large alignment of read-only strings

Hans-Peter Nilsson dixit: >> ? except -malign-data=abi is, apparently, cris-only. >ITYM "i386-only". I see "malign-data=" in >gcc/config/i386/i386.opt. No (actually tested on amd64, which didn’t support it). >(Not sure why the CRIS port was mentioned at all. The GCC 6 texinfo documentation *o

Re: [RFD] Extremely large alignment of read-only strings

Dixi quod… >Alexander Monakov dixit: > >>First of all, I think option -malign-data=abi (new in GCC 5) addresses your >>need: it can be used to reduce the default (excessive) alignment to just the >>psABI-dictated value (you can play with this at https://gcc.godbolt.org even >>if > >Ah, nice! … e

Re: [RFD] Extremely large alignment of read-only strings

Alexander Monakov dixit: >First of all, I think option -malign-data=abi (new in GCC 5) addresses your >need: it can be used to reduce the default (excessive) alignment to just the >psABI-dictated value (you can play with this at https://gcc.godbolt.org even if Ah, nice! >Note that like with othe

Re: [RFD] Extremely large alignment of read-only strings

(apologies for the double post, GMane had a hiccup. The latter, which this is a reply to, has one discussion item more, so please ignore the other)

[RFD] Extremely large alignment of read-only strings

Hi, (tl;dr: skip to “questions from me to the GCC developers”) I’ve recently spotted the following in some code I inherited: struct foo { char name[4]; uint8_t len; uint8_t type; }; static const struct foo fooinfo[] = { /* list of 43 members */ }; I’ve seen the

[RFD] Insane alignment of read-only arrays

Hi, (tl;dr: skip to “questions from me to the GCC developers”) I’ve recently spotted the following in some code I inherited: struct foo { char name[4]; uint8_t len; uint8_t type; }; static const struct foo fooinfo[] = { /* list of 43 members */ }; I’ve seen the

Re: "stable" version bootstrapping

Richard Biener dixit: >in the install instructions (gcc/doc/install.texi) in the >pre-requesites section. Ah yes, I saw that, but… >Currently it reads: ⓐ that’s “curently”, plus it doesn’t specificially say that 3.4 is the “stable” version currently picked, which is one of the reasons I tho

Re: "stable" version bootstrapping

Tobias Burnus net-b.de> writes: > GCC since 4.8 requires a C++98 compiler, i.e. GCC since 3.4 should be > fine. However, who knows when some C++11 features will start to get Hrm, indeed. > used. Thus, why not using the latest compiler which still builds with C, > i.e. GCC 4.6 or GCC 4.7. (Th

Re: Intentional or accidental backward-incompatibility w.r.t. process attributes?

NightStrike gmail.com> writes: > > ... used to work, with the attribute from the declaration being applied also > > to the definition. I stumbled upon this as well recently. > Someone else just asked not too long ago: > > http://gcc.gnu.org/ml/gcc-help/2013-03/msg00012.html Yes, but there’s n

"stable" version bootstrapping

Hi, the GCC wiki says: “We will periodically pick a stable version of GCC, and require that that version of GCC be able to build all versions of GCC up to and including the next stable version. E.g., we may decide that all newer versions of GCC should be buildable with GCC 4.3.5.” Which version

ICE: in bitmap_set_replace_value

ab.c:1842:1: internal compiler error: in bitmap_set_replace_value, at tree-ssa-pre.c:867 yyparse (void) ^ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. Executing the same command with -O1 instead of -O2 compiles just fine. Also using the gcc-4.8-20121230 snapshot compiles just fine. Is this a regression? Thanks, thorsten

Re: Question about memory allocation in ifcvt.c

the fix to 4.5 thorsten

Question about memory allocation in ifcvt.c

ifcvt.c? I have seen, that also gcc-4.7.2 still uses alloca. Thanks! Thorsten

Re: build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR

Joseph S. Myers dixit: >It's desirable to be able to configure GCC correctly in the presence of >installed headers and only a dummy libc.so, so as to get a GCC that can be >used to build the full glibc. Ah, right, the GNU case. Sorry, I totally did not have that one in mind, even though I know

Re: build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR

Thomas Schwinge dixit: >Ideally, IMO, this test (for stack-smashing-protection support in glibc) >should not be done by grepping through SYSROOT's features.h, but instead >by using the CPP for doing that. Why not just autoconf? Check for the presence of __stack_smash_handler() in libc… or am I m

Re: build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR

Thomas Schwinge dixit: >First, the check for gcc_cv_libc_provides_ssp is not complete, as has >already pointed out (with patches!) before, but is still not fixed on >trunk. Let me revisit that: in configure.ac it is being checked for >``case "$target" in *-*-linux*)'' which should rather match ``

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Paul Eggert dixit: > […] gcc -O2 makes no promises without > -fwrapv. gcc -O1 -fwrapv even doesn't work correctly for gcc3, and gcc2 and gcc <3.3(?) don't even have -fwrapv: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477 bye, //mirabile -- "Using Lynx is like wearing a really good pair o

Re: Reconsidering gcjx

Andrew Haley dixit: > > Thorsten> Why not keep enough support in jc1 to bootstrap ecj? > > > > We don't know how much of the language that would be. > >And we can't tell _a priori_. As I understand it, the intention is to >use upstream sources, and they w

Re: Reconsidering gcjx

Tom Tromey dixit: >In my preferred approach we would simply delete a portion of the >existing gcj and turn jc1 into a purely bytecode-based compiler. >ecj is written in java. This will complicate the bootstrap process. Why not keep enough support in jc1 to bootstrap ecj? Maybe split out so that

Re: Big Classpath Merge warning

Tom Tromey dixit: >I'm finally ready to check in the big classpath merge, and I wanted to >post a short warning before I went ahead with it. Is it possible to use a current libgcj or classpath with gcc 3.4? Thanks, //mirabile -- I believe no one can invent an algorithm. One just happens to hit

Re: updating libtool, etc.

Daniel Jacobowitz dixit: >> >Geoff> Does anyone mind if I update libtool to the latest released >> >version, >> >Geoff> 1.5.18, and regenerate everything with automake 1.9.5? >> > >> >If everyone agrees to go forward with this >> >> Oh, I should have said: "and if you don't mind, how do yo

should libgcc depend on libc?

objdump -p says: Dynamic Section: NEEDED libc.so.37.0 SONAME libgcc_s.so.1.1 [...] nm | sort says: U _exit U abort U dl_iterate_phdr U free U malloc U memcpy U memset U mprotect U perror U sys

Re: gij problem (3.4.4)

Andrew Haley dixit: >Do you have any reason to suspect this might be MirOS specific? We have to patch a lot. Some of it is OpenBSD legacy, some from NetBSD, some from newer GNU tools, some patches are build system specific. And since it happened on execution of a class with only one page source c

Re: gij problem (3.4.4)

Andrew Haley dixit: >In which case it would be best to post a bug report at >gcc.gnu.org/bugzilla and attach both source and class files. What for? I'm 99% sure nobody else has got the bug, since most probably haven't even heard of the MirOS operating system. And it's only in the latest snapshot.

Re: gij problem (3.4.4)

Andrew Haley dixit: >No, but I do know that I would not even attempt to start looking at >this with no debugging info in libgcj. libgcj builds by default with >full debugging info, so something (someone) must have removed it. Yes, our libraries are stripped by default. I can build one with full

gij problem (3.4.4)

Hello, I've got Java classes from source ("99 bottles of beer") compiled to bytecode and from source or bytecode to a dynamically linked executable working just fine, also Sun's JDK works on the generated bytecode - however, gij does not, even without boehm-gc (which prevented it from working befo

Re: volatile semantics

Mike Stump dixit: > int avail; > int main() { > while (*(volatile int *)&avail == 0) >continue; > return 0; > } 3.4.4 fetches too. I get: .L2: mov %eax, DWORD PTR avail test%eax, %eax je .L2 This is at -O99, other levels produce similar results. //mir

Re: libjava build times

Andrew Haley dixit: >Richard Henderson writes: > > > > Now, unless I've done something drastically wrong, it appears as if we > > are spending 2/3 of our time in the libtool script. > >Yes, that's right. That's similar to what my oprofile experiments suggest. Could you please go to http://wiki.

Re: libjava/3.4.4 problem (SOLVED)

Dixi: >Mark Mitchell dixit: > >>In general, GCC 3.4.3 is working for people > >I've been playing around a lot with the various 3.4.4 snapshots >lately, and got everything to work, except for libjava: With the change in the configuration file, it works now. However, I'm curious about why FreeBSD d

Re: libjava/3.4.4 problem

Andrew Pinski dixit: >> Does anyone have an idea where to look? > > This is a bug in your config, you forgot to define NO_IMPLICIT_EXTERN_C. Thanks a lot, I will try that after I updated to 20050429. bye, //mirabile

libjava/3.4.4 problem (was Re: GCC 3.4.4 Status (2005-04-29))

Mark Mitchell dixit: >In general, GCC 3.4.3 is working for people I've been playing around a lot with the various 3.4.4 snapshots lately, and got everything to work, except for libjava: gmake[1]: Entering directory `/usr/obj/gcc/libjava' /bin/ksh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CON

Re: GCC 4.1: Buildable on GHz machines only?

Zack Weinberg dixit: >This could be made substantially easier if libgcc moved to the top >level. You wanna help out with that? What about crtstuff? //mirabile

sjlj exceptions?

Hi, when porting gcc (still 3.4.4), how do I exactly know whether I need to pass --enable-sjlj-exceptions to configure? Is there a test case which fails if I need it and have it not enabled, and passes otherwise (disabled and not needed, or enabled)? TIA, //mirabile -- > Hi, does anyone sell op

Re: Getting rid of -fno-unit-at-a-time

Daniel Jacobowitz dixit: >On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote: >> BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1 >> or so... I still lean on that crutch. > >A user! Can you explain why? If you're "just" looking for users: I need -fno-unit-at-a-

Re: Question about "#pragma pack(n)" and "-fpack-struct"

James E Wilson dixit: >Currently, -fpack-struct is defined >to have the same effect as attribute ((packed)) for all structures, >which in turn is equivalent to #pragma pack(1) for all structures. Let me please add a feature request here. gcc warns if it cannot pack structs since they're already

Re: GCC Status Report (2005-03-09)

Mark Mitchell dixit: >4.1 Status >== > >The 4.1 projects Wiki page shows that four projects have been checked >in: Hello etoh-san, do you have a statement about ProPolice for gcc 4? Are you working on it, or even bringing it into mainline (maybe even disabled by default, doesn't matter as

Re: matching constraints in asm operands question

Andrew Pinski dixit: >> which seems to work, but I'm really concerned about the manuals >> warning of the input and output operads being in seperate places. > static __inline__ void atomic_inc(atomic_t *v) > { > __asm__ __volatile__("addql #1,%0" : "+m" (*v)); > } Hi, I have got the same p

Re: Moving to an alternate VCS

Joe Buck dixit: >On Fri, Feb 11, 2005 at 01:49:34PM +0000, Thorsten Glaser wrote: >> I've always found the FSF's ChangeLog policy a bit weird >> (for CVS projects - for RCS projects it's understandable). > >The ChangeLog fulfills a sometimes-ignored lega

Re: Moving to an alternate VCS

Chris Jefferson dixit: > As someone who just started submitting code, I'd say for a beginner the most > important features of the version control system are (in particular relating > to > CVS) 4) [svn] Get rid of the forced "ChangeLog" entry - writing (it's already the changeset's commit mess