Re: libatomic IFUNC question (arm & libat_have_strexbhd)

* Richard Henderson: > On 06/05/2017 10:50 PM, Florian Weimer wrote: >> * Steve Ellcey: >> >>> I have a question about the use of IFUNCs in libatomic. I was looking at >>> the >>> arm implementation and in gcc/libatomic/config/linux/arm/host-co

Re: GC/GTY and Coverity "resource leaks" (was Re: Daily Coverity analysis on gcc)

* David Malcolm: > The most recent one, and thus the first one I looked at (CID=1412982) > was a supposed "Resource Leak" in the get_cast_suggestion function I > introduced in r249461, where the local variable "trial" is supposedly > leaked (leading to 3 issues within Coverity overall, if I'm read

Re: RFC: Add ___tls_get_addr

On 07/05/2017 05:38 PM, H.J. Lu wrote: > We are considering to add an alternative interface, ___tls_get_addr, to > glibc, which doesn't realign stack. Compilers, which properly align stack > for TLS, call generate call to ___tls_get_addr, instead of __tls_get_addr, > if ___tls_get_addr is availabl

Re: gcc behavior on memory exhaustion

* Andrew Haley: > On 09/08/17 14:05, Andrew Roberts wrote: >> 2) It would be nice to see some sort of out of memory error, rather than >> just an ICE. > > There's nothing we can do: the kernel killed us. We can't emit any > message before we die. (killed) tells you that we were killed, but > we

Re: gcc behavior on memory exhaustion

* Pedro Alves: >> The siginfo_t information should indicate that the signal originated >> from the kernel. > > OOC, where? While a parent process can use "waitid" to get > a siginfo_t with information about the child exit, that siginfo_t > is not the same siginfo_t a signal handler would get as

Re: assuming signed overflow does not occur

* Bruce Korb: > I know about all these theoretical possibilities of numbers behaving > in strange ways when arithmetic optimizations assume that signed > overflow won't occur when they actually might. Yep, it creates subtle > bugs. The warning is worthwhile. Still and all: > > 485 tvdi

Re: Byte swapping support

* Eric Botcazou: >> To support applications that assume big-endian memory layout on little- >> endian systems, I'm considering adding support for reversing the >> storage order to GCC. > > That was also the goal of the scalar_storage_order attribute. By the way, what happened to the C++ bits? I

Re: Byte swapping support

* Eric Botcazou: >> By the way, what happened to the C++ bits? I think the c-family patch >> which went in assumes that the C++ bits are there as well. > > I don't really understand what you mean by "assume" here, handle_pragma_scalar_storage_order does not check c_dialect_cxx, so it will not is

GCC aliasing extension for C

I know that GCC implements a C extension (which is more or less required by POSIX) which allows you to define a buffer char buf[1024]; and then allocate objects from that (assuming that the buffer is sufficiently large and the pointers to subobjects are suitably aligned). In short, it is p

GCC extension for atomic access to members

I would like to see the GCC project to document that if the address of a member is taken, this does not constitute an access to the object as a whole. That is, in the following code: #include struct S { _Atomic int a; int b; }; int load_a (struct S *p) { return atomic_load_explicit (&

Re: GCC extension for atomic access to members

On 09/18/2017 10:07 PM, Torvald Riegel wrote: On Mon, 2017-09-18 at 14:19 +0200, Florian Weimer wrote: I would like to see the GCC project to document that if the address of a member is taken, this does not constitute an access to the object as a whole. That is, in the following code

Re: GCC extension for atomic access to members

On 09/19/2017 03:32 PM, Torvald Riegel wrote: On Tue, 2017-09-19 at 07:19 +0200, Florian Weimer wrote: On 09/18/2017 10:07 PM, Torvald Riegel wrote: On Mon, 2017-09-18 at 14:19 +0200, Florian Weimer wrote: I would like to see the GCC project to document that if the address of a member is

Re: "GOT" under aarch64

* jacob navia: > 1) How can I know what I should generate? Should I figure out the gcc > version installed? > > 2) Is there any documentation for this change somewhere? What does it mean? It's probably due to a downstream packaging change to enable position-independent executables (PIE) by defau

Re: Where should I report security related issues?

* Charo: > Is there any private list or something like that to report it > or should I use the GCC bug tracker? You could pick one of the distributions and let them handle this: * Debian * Red Hat * SUSE Just contacting one distribution is sufficient.

Re: Where should I report security related issues?

* Jeff Law: > On 11/01/2017 03:22 AM, Florian Weimer wrote: >> * Charo: >> >>> Is there any private list or something like that to report it >>> or should I use the GCC bug tracker? >> >> You could pick one of the distributions and let them handle t

Re: Caching globals in registers

* jacob navia: > > One of the reasons (besides the nullity of my code generator of course) > was that gcc cached the values of the global "table" in registers, > reading it just once. Since there are many accesses in the most busy > function in the program, gcc speeds up considerably. > > Cleve

Re: prerequisites for installing

* Joakim Rosqvist: > Humbly requesting that on the page > https://gcc.gnu.org/install/prerequisites.html you add something to inform > the reader that the "download_prerequisites" mentioned there is a script in > the contrib directory of the source code tree for gcc. It's already mentioned here:

Re: Dropping ChangeLogs

On 12/22/2017 12:42 PM, Eric Botcazou wrote: ChangeLogs are a relic from the days before version-control systems with real changesets. When you have real changesets, all ChangeLogs do is add unnecessary process friction. ChangeLogs make it possible to quickly pinpoint unintentional changes goin

Re: Dropping ChangeLogs

On 12/22/2017 01:20 PM, Siddhesh Poyarekar wrote: On Friday 22 December 2017 05:41 PM, Florian Weimer wrote: *However*, my main problem with getting rid of ChangeLogs is that without a pull-request-based contribution procedure or some tool support like Gerrit, it's impossible to tell

Re: Dropping ChangeLogs

On 12/22/2017 01:34 PM, Siddhesh Poyarekar wrote: On Friday 22 December 2017 05:57 PM, Florian Weimer wrote: The Linux community does not have a tool-based solution for that.  I think it mainly relies on lack of commit access for contributors. Sure, but that's a minor detail to implement

Re: GCC and Meltdown and Spectre vulnerabilities

* timofonic timofonic: > Paranoid jails/sandboxes inside a virtual machine may mitigate a lot > the risk for those untrusted binaries, right? Someone needs to impelement those sandboxes and virtual machines, and GCC changes may help with writing them in such a way that they are less exposed to th

Retpolines and CFI

I tried this: struct C { virtual ~C(); virtual void f(); }; void f (C *p) { p->f(); p->f(); } with r256939 and -mindirect-branch=thunk -O2 on x86-64 GNU/Linux, and got this: _Z1fP1C: .LFB0: .cfi_startproc pushq %rbx .cfi_def_cfa_offset 16 .cfi_offset

Re: Unused GCC builtins

* Manuel Rigger: > Details: We downloaded all C projects from GitHub that had more than 80 > GitHub stars, which yielded almost 5,000 projects with a total of more > than one billion lines of C code. We filtered GCC, forks of GCC, and > other compilers as we did not want to incorporate internal us

Re: Unused GCC builtins

* Jakub Jelinek: > On Wed, Jan 24, 2018 at 03:04:55PM +0100, Manuel Rigger wrote: >> In a second step, we also considered internal builtins and found that the >> vararg handling builtins (__builtin_va_start, __builtin_va_end, >> __builtin_va_arg, and __builtin_va_copy) are relied upon by many proj

Re: Retpolines and CFI

On 01/22/2018 01:21 PM, Florian Weimer wrote: There is a different issue with the think itself. __x86_indirect_thunk_rax: .LFB2:     .cfi_startproc     call    .LIND5 .LIND4:     pause     lfence     jmp .LIND4 .LIND5:     mov %rax, (%rsp)     ret

Re: Retpolines and CFI

On 01/25/2018 02:38 PM, H.J. Lu wrote: On Thu, Jan 25, 2018 at 12:32 AM, Florian Weimer wrote: On 01/22/2018 01:21 PM, Florian Weimer wrote: There is a different issue with the think itself. __x86_indirect_thunk_rax: .LFB2: .cfi_startproc call.LIND5 .LIND4

Re: Debugging optimizer problems

* jacob navia: > I have in my small C compiler introduced the following construct: > > #pragma optimize(on/off,push/pop) Not sure what you are after. GCC has something quite similar:

Re: GCC interpretation of C11 atomics (DR 459)

On 02/26/2018 05:00 AM, Ruslan Nikolaev via gcc wrote: If I understand correctly, the redirection to libatomic was made for 2 reasons: 1. cmpxchg16b is not available on early amd64 processors. (However, mcx16 flag already specifies that you use CPUs that have this instruction, so it should not

Run (some?) ELF constructors after applying RELRO protection

I think it would be a nice addition to the toolchain if it were possible to programatically initialize data in the RELRO section. We do this in glibc, but I don't think this is currently supported for general use. One important application is to allocate a memory region with mmap, on which pr

Re: GCC interpretation of C11 atomics (DR 459)

On 02/26/2018 07:36 PM, Janne Blomqvist wrote: There is no such architectural guarantee. At least on some micro-architecture (AMD Opteron "Istanbul") it's possible to construct a test which fails, proving that at least on that micro-arch SSE2 load/store isn't guaranteed to be atomic. Looks like

Re: GCC interpretation of C11 atomics (DR 459)

On 02/27/2018 05:40 PM, Simon Wright wrote: Sorry to butt in, but - if it's ROM why would you need atomic load anyway? (of course, if it's just a constant view of the object, reason is obvious) On many systems, the read-only nature of a memory region is a thread-local or process-local attribu

Re: RFA: Need to extend x86 psABI to support thread cancellation and alternate signal stack

On 03/27/2018 12:43 AM, H.J. Lu wrote: On Linux, when alternate signal stack is used with thread cancellation, _Unwind_Resume fails when it tries to unwind shadow stack from signal handler on alternate signal stack. The issue is that signal handler on alternate signal stack uses a separate shado

Re: RFA: Need to extend x86 psABI to support thread cancellation and alternate signal stack

On 03/27/2018 01:26 PM, H.J. Lu wrote: 2. Since shadow stack is never saved and restored by compiler, unwinder in libgcc counts how many stack frame it has to unwind and uses INCSSP to pop shadow stack. This can't unwind the original shadow stack when the alternate shadow stack is used. _URC_N

Re: Stack protector: leak of guard's address on stack

* Thomas Preudhomme: > Yes absolutely, CSE needs to be avoided. I made memory access volatile > because the change was easier to do. Also on Arm Thumb-1 computing the > guard's address itself takes several loads so had to modify some more > patterns. Anyway, regardless of the proper fix, do you ha

Re: Stack protector: leak of guard's address on stack

* Maxim Kuvyrkov: >> On Apr 28, 2018, at 9:22 PM, Florian Weimer wrote: >> >> * Thomas Preudhomme: >> >>> Yes absolutely, CSE needs to be avoided. I made memory access volatile >>> because the change was easier to do. Also on Arm Thumb-1 computing th

Re: Stack protector: leak of guard's address on stack

* Maxim Kuvyrkov: > The problem is fairly target-dependent, so architecture maintainers > need to look at how stack-guard canaries and their addresses are > handled and whether they can be spilled onto stack. > > It appears we need to poll architecture maintainers before filing the CVE. One CVE I

Re: [RFC] Deprecate "implicit int" for main() in C++

On 04/25/2018 04:40 PM, Jonathan Wakely wrote: More concretely, deprecating it for a few releases would allow us to apply the attached patch at some point in the future, so that instead of: rt.c:1:6: warning: ISO C++ forbids declaration of ‘main’ with no type [-Wreturn-type] main() { return 0;

Re: Auto-generated .rodata contents and __attribute__((section))

On 05/23/2018 02:55 PM, Michael Matz wrote: On Fri, 18 May 2018, Richard Biener wrote: Interesting. Do they allow merging across such sections? Consider a 8 byte entity 0x12345678 and 4 byte entities 0x1234 0x5678, will the 4 byte entities share the rodata with the 8 byte one? There's no l

Re: Enabling -ftree-slp-vectorize on -O2/Os

* Allan Sandfeld Jensen: > Anythhing else I should test or report? Interaction with -mstackrealign on i386, where it is required for system libraries to support applications which use the legacy ABI without stack alignment if you compile with -msse2 or -march=x86-64 -mtune=generic (and -mfpmath=s

Re: For which gcc release is going to be foreseen the support for the Coroutines TS extension?

On 06/04/2018 07:36 PM, Jonathan Wakely wrote: On 4 June 2018 at 18:32, Marco Ippolito wrote: Hi all, clang and VS2017 already support the Coroutines TS extensions. For which gcc release is going to be foreseen the support for the Coroutines TS extension? This has been discussed recently, sea

Re: Run (some?) ELF constructors after applying RELRO protection

On 06/11/2018 04:50 PM, Rich Felker wrote: On Tue, Feb 27, 2018 at 11:01:23AM +0100, Florian Weimer wrote: I think it would be a nice addition to the toolchain if it were possible to programatically initialize data in the RELRO section. We do this in glibc, but I don't think this is curr

Re: libmvec in gcc to have vector math in fortran

* Richard Biener: > 'pure' makes it pure but there doesn't seem to be a way to make it const? Does Fortran support setting the rounding mode? In C, sin is not const because it depends on the current rounding mode.

Re: libmvec in gcc to have vector math in fortran

* Richard Biener: > That said, good to see some glibc folks jump in on this thread. > I'd like to see glibc provide a fortran intrinsic header advertising > the libmvec routines it has. We probably do need some gfortran > adjustments here but I think that glibc advertising is better than > hard-c

Invalid program counters and unwinding

I'm looking at ways to speed up _Unwind_Find_FDE when libgcc is running on top of glibc. I have something (at the design level, with some of the code written) which allows me to get a pointer to the PT_GNU_EH_FRAME segment in memory in a lock-free fashion (so it would also be async-signal safe

Re: Invalid program counters and unwinding

On 06/26/2018 12:56 PM, Nathan Sidwell wrote: On 06/26/2018 05:26 AM, Florian Weimer wrote: So it looks to me that the caller of _Unwind_Find_FDE needs to ensure that the PC is a valid element of the call stack.  Is this a correct assumption? I thought this was an (implicit?) requirement

Re: Invalid program counters and unwinding

On 06/26/2018 01:15 PM, Nathan Sidwell wrote: On 06/26/2018 07:01 AM, Florian Weimer wrote: On 06/26/2018 12:56 PM, Nathan Sidwell wrote: On 06/26/2018 05:26 AM, Florian Weimer wrote: So it looks to me that the caller of _Unwind_Find_FDE needs to ensure that the PC is a valid element of the

Re: Invalid program counters and unwinding

On 06/26/2018 01:25 PM, Jakub Jelinek wrote: On Tue, Jun 26, 2018 at 01:01:06PM +0200, Florian Weimer wrote: On 06/26/2018 12:56 PM, Nathan Sidwell wrote: On 06/26/2018 05:26 AM, Florian Weimer wrote: So it looks to me that the caller of _Unwind_Find_FDE needs to ensure that the PC is a

Re: Invalid program counters and unwinding

On 06/26/2018 01:35 PM, Nathan Sidwell wrote: On 06/26/2018 07:21 AM, Florian Weimer wrote: GCC doesn't do this AFAIK, but it's theoretically possible not to preserve the return address for a noreturn function.  But that would be very bad for exception handling, so let's hope

Re: Invalid program counters and unwinding

On 06/28/2018 04:16 AM, Jeff Law wrote: Previous discussions: https://gcc.gnu.org/ml/gcc/2013-05/msg00253.html https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744 https://sourceware.org/ml/libc-alpha/2016-07/msg00613.html   (patch with a spread lock, still not async-signal-safe) You might als

Re: Invalid program counters and unwinding

On 06/28/2018 04:18 PM, Jeff Law wrote: On 06/28/2018 06:30 AM, Florian Weimer wrote: On 06/28/2018 04:16 AM, Jeff Law wrote: Previous discussions: https://gcc.gnu.org/ml/gcc/2013-05/msg00253.html https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744 https://sourceware.org/ml/libc-alpha/2016-07

Re: ChangeLog's: do we have to?

* Aldy Hernandez: > Can someone refresh my memory here, what are the remaining arguments for > requiring ChangeLog entries? ChangeLog entries are part of the review, commit messages are not, so you end up with surprises there. At least that's what happens in glibc.

Re: ChangeLog's: do we have to?

* Richard Kenner: >> GCC ChangeLogs don't record the purpose of the change. They say what changed, >> but not why. > > That depends on how you define "purpose". Let's take a random entry, > from a 1999 change of mine: > > * expr.c (expand_expr): If ignoring reference operations, >

Re: ChangeLog's: do we have to?

* Paul Koning: >> On Jul 5, 2018, at 10:43 AM, Florian Weimer wrote: >> >> * Aldy Hernandez: >> >>> Can someone refresh my memory here, what are the remaining arguments for >>> requiring ChangeLog entries? >> >> ChangeLog entries are part

Re: Invalid program counters and unwinding

On 07/02/2018 06:14 PM, Michael Matz wrote: There is no such language in the psABI, no (at least I haven't found anything; you had me worried for a moment :) ). But there's stronger one: all functions through which unwinding is expected must provide CFI. So, yes, such code isn't strictly confor

Re: Run (some?) ELF constructors after applying RELRO protection

On 06/11/2018 08:59 PM, Rich Felker wrote: If the application already has to annotate that the data is going to be read-only after ctors, it can just page-align/page-pad the data itself and call mprotect with minimal additional effort, and no complex interaction between application code and relro

Re: Good news, bad news on the repository conversion

* Eric S. Raymond: > The bad news is that my last test run overran the memnory capacity of > the 64GB Great Beast. I shall have to find some way of reducing the > working set, as 128GB DD4 memory is hideously expensive. Do you need interactive access to the machine, or can we run the job for you

Re: [RFC] Adding Python as a possible language and it's usage

* Segher Boessenkool: > What would the advantage of using Python be? I haven't heard any yet. > Awk may be a bit clunky but at least it is easily readable for anyone. I'm not an experienced awk programmer, but I don't think plain awk supports arrays of arrays, so there's really no good way to em

Re: gcc-gnat for Linux/MIPS-32bit-be, and HPPA2

* Jeff Law: > On 07/19/2018 02:19 PM, Carlo Pisani wrote: >> hi >> is there any chance someone has a working gcc-ada compiler? for >> - Linux/MIPS (big endian, MIPS3, MIPS4 or MIPS32) >> - Linux/HPPA2 >> >> I have successfully compiled gcc-ada for SGI_IRIX (MIPS4/BE) >> but ... every attempt to c

Re: Building libssp on a system without gets()

* Gerald Pfeifer: > some folks in FreeBSD-land have worked to remove all uses of gets() > and in fact the gets() function itself. > > Generally GCC builds just fine in such an environment, except for > libssp where libssp/gets-chk.c has the following: > >char * >__gets_chk (char *s, size_

Re: Why did Intel change his static branch prediction mechanism over these years?

On 08/14/2018 03:36 PM, 2016 quekong wrote: And Intel seems don't want to talk about it any more, because the latest material I found within Intel Document was written about ten years ago. Since branch prediction is nowadays a security feature, I doubt you will see detailed public documentati

Re: Why did Intel change his static branch prediction mechanism over these years?

On 08/15/2018 01:16 PM, 2016 quekong wrote: Hi, Florian. There is a movement to replace table-driven stack unwinding with a conditional branch after most function calls... I am sorry I don't understand its meaning, forgive my poor knowledge of dynamic prediction, I am reading relative mater

Re: Making gcc -no-canonical-prefixes the default?

* Ian Lance Taylor: > So it seems like people want it both ways. Some people want to invoke a > symlink which points to the real gcc, which requires canonicalization. > Some people want the real gcc to be a symlink which points elsewhere, > which requires non-canonicalization. I don't know what

Re: X32 psABI status

* H. J. Lu: > We made lots of progresses on x32 pABI: > > https://sites.google.com/site/x32abi/ > > 1. Kernel interface with syscall is close to be finalized. > 2. GCC x32 branch is stabilizing. > 3. The Bionic C library works with the syscall kernel interface. > > The next major milestone will be

Re: X32 psABI status

* H. Peter Anvin: > On 02/12/2011 01:10 PM, Florian Weimer wrote: >> Why is the ia32 compatiblity kernel interface used? > > Because there is no way in hell we're designing in a second > compatibility ABI in the kernel (and it has to be a compatibility ABI, > b

Re: X32 psABI status

* H. J. Lu: >> Actually, I'm wondering if you can do the translation in user space. >> There already are 32-on-64 implementations in existence, without >> kernel changes (recent Hotspot, LuaJIT, and probably some more). > > Please check out the x32 kernel source and provide feedback. I still don'

Re: X32 psABI status

* H. J. Lu: > On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer wrote: >> * H. J. Lu: >> >>>> Actually, I'm wondering if you can do the translation in user space. >>>> There already are 32-on-64 implementations in existence, without >>>> k

Re: fsf paperwork?

* Jack Howarth: >Is anyone else having problems getting the FSF copyright > clerk to complete the FSF paperwork? Yes, it is not just you. I recently experienced something similar with another GNU project, under similar circumstances.

Re: Our Publication Proposal: Your dissertation in book form

* Sarah Lynch: > LAP LAMBERT Academic Publishing GmbH& Co. KG > > Dudweiler Landstraße 99, > 66123 Saarbrücken, Germany This company appears to be affiliated with "VDM Publishing", a company which became notorious as a republisher of Wikipedia articles.

Re: Option to make unsigned->signed conversion always well-defined?

* Ulf Magnusson: > I've been experimenting with different methods for emulating the > signed overflow of an 8-bit CPU. The method I've found that seems to > generate the most efficient code on both ARM and x86 is > > bool overflow(unsigned int a, unsigned int b) { > const unsigned int sum = (i

Re: Option to make unsigned->signed conversion always well-defined?

* Ulf Magnusson: > Are you thinking of something like this? > > bool overflow_bit2(unsigned int a, unsigned int b) { > const unsigned int ashift = a << 24; > const unsigned int bshift = b << 24; > const unsigned int sum = a + b; > return (int)(~(a ^ b) & (a ^ sum)) < 0; > } Yes, b

Re: Option to make unsigned->signed conversion always well-defined?

* Ulf Magnusson: > Good machine code would be fun to see, though I might need to brush up > on my ARM. It turns out that ARM doesn't seem to have 8-bit overflow detection, so something like this has to be used (with the arguments in R1 and R2, result in the lower bit of R3): MOVR3, R1, LS

Compiling programs licensed under the GPL version 2 with GCC 4.4

Kalle Olavi Niemitalo discovered that as an operating system vendor, you are not allowed to distribute GPL version 2 programs if they are compiled with GCC 4.4. The run-time library is GPL version 3 or later, which is incompatible with GPL version 2, so it is not permitted to link this with the GP

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

* Joe Buck: > On Sat, Jul 25, 2009 at 01:53:40PM -0700, Florian Weimer wrote: >> Kalle Olavi Niemitalo discovered that as an operating system vendor, >> you are not allowed to distribute GPL version 2 programs if they are >> compiled with GCC 4.4. The run-time librar

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

* Arnaud Charlet: >> Eh, this exception doesn't change that the GPLv2 program perceives the >> GPLv3 as incompatible. Why would it? > > Is it GPLv2 or GPLv2+? GPLv2 (I tried to stress by writing "GPLv2-only"). > If the latter (the license includes something like "either version 2 > of the Licen

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

* Arnaud Charlet: >> > If the latter (the license includes something like "either version 2 >> > of the License, or (at your option) any later version"), then >> > nothing prevents you from distributing the program under GPLv3+ >> > instead of GPLv2+. >> >> Right, but we've got some stuff which i

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

* Joe Buck: > Doesn't matter, because the runtime library is not under GPLv3. It's > under GPLv3 plus the runtime restriction. That combination is more > permissive than GPLv2 (because of the exceptions it makes). Therefore, > as far as I can tell, there is no conflict; the combined program has

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

* Paolo Bonzini: >> But if I change the run-time library, I still have to license those >> changes under the GPLv3 if I want to distribute them, right? > > Yes. But if you change the runtime library and link something else > with the modified runtime library, the "something else" does not fall >

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

* Robert Dewar: > b) you should ignore all such discussions, since they invariablly >include lots of legal-sounding opinions from people who are not >lawyers and don't know, and often have significant misconceptions. This is not about legal issues. It's about FSF policy. If I wanted leg

C++: variable length arrays and operator new[]

G++ currently accepts the following code: char * alloc(unsigned a, unsigned b) { typedef char array[a]; return &**(new array[b]); } Is this intentional? The equivalent "new char[a][b]" is rejected (as required by the C++ standard).

Re: C++: variable length arrays and operator new[]

* Gabriel Dos Reis: >>> Is this intentional?  The equivalent "new char[a][b]" is rejected (as >>> required by the C++ standard). >> >> Is there any reason that g++ should reject your sample program? > > Yes: there is no obvious reason for gratuitous incompatibility in > semantics. That, and it re

Re: Ada type in binding for C99 bool

* Joel Sherrill: > What is the proper type to use in an Ada binding > for a C method that returns a C99 bool? Whatever the answer is, it should be used to define Interfaces.C.Bool. (I don't know what GCC's options for representing _Bool are, sorry.)

Re: Ada type in binding for C99 bool

* Joel Sherrill: >> Whatever the answer is, it should be used to define Interfaces.C.Bool. >> (I don't know what GCC's options for representing _Bool are, sorry.) > It appears to be unsigned char or at least sizeof(bool)=1 > on the architectures I tried this test program on. That's only half of

Re: GCC aliasing rules: more aggressive than C99?

* Joshua Haberman: > To me this allows the following: > > int i; > union u { int x; } *pu = (union u*)&i; > printf("%d\n", pu->x); I think the cast on the secodn line is undefined, not the access on the third.

Git mirror needs a run of "git gc"

Right now, each fresh clone needs to create a compressed pack, which takes quite a while. (I think, there might be something else wrong with the repository.)

Re: Change x86 default arch for 4.5?

* Tim Prince: > All CPUs still in production are at least SSE3 capable, unless someone > can come up with one of which I'm not aware. What about some of the AMD Geode processors?

Re: Defining a libgnat.so, libgnarl.so ABI

* Rainer Orth: > Since I barely know any Ada, or Ada mangling, Ada subprogram name mangling depends on the order of declarations in the source file. This order is also somewhat constrained by language rules. I think this means that defining a stable ABI is rather difficult.

Re: Why not contribute? (to GCC)

* Manuel López-Ibáñez: > What reasons keep you from contributing to GCC? My most recent case: I could not make my needs meet with those of fringe/embedded architectures, so my little work on a patch led to nowhere (as of now).

Re: Why not contribute? (to GCC)

* Richard Kenner: > Now let's suppose some company claims my patches violate their copyright. > What happens? In the GCC case, they can't come to me since I no longer own > that code. They sue the FSF, who defends the case. If they lose (because > I DID, in fact, violate somebody's copyright),

Re: Echte Lokaliserung der Programmbausprache/ Real Localisation of Programming Language

* Dave Korn: > You're not the first person to come up with this idea, and you probably > won't be the last, but it's a misbegotten idea, and there's a very good reason > why it hasn't been done before, and that's not just "because nobody's thought > of it before you", but because it would basica

Re: |new []| better not overflow and crash with g++

* Georgi Guninski: > once upon a time |calloc(BIG,BIG)| silently overflowed, now it is fixed. > > nowadays |new int[bignumber]| overflows as in: This is PR19351, first reported in 2002 (along with the calloc issue).

Re: Serious code generation/optimisation bug (I think)

* Laurent GUERBY: > Just curious: is there a "portable" way to read from memory > address zero in C code? "portable" here means likely to work > on most compilers without exotic compile flags in 2009. No, C hasn't got a notion of addresses. The situation is likely to get even more extreme, not l

Re: New GCC Runtime Library Exception

* David Edelsohn: > We have also published a rationale document and FAQ to help users > understand the exception better. It is avaliable at: > > http://www.gnu.org/licenses/gcc-exception-faq.html Is it deliberate that the exception does not extend to programs compiled with GCJ?

Re: New GCC Runtime Library Exception

* Joe Buck: > On Tue, Jan 27, 2009 at 12:51:22PM -0800, Florian Weimer wrote: >> * David Edelsohn: >> >> > We have also published a rationale document and FAQ to help users >> > understand the exception better. It is avaliable at: >> > >> >

Re: New GCC Runtime Library Exception

* Ian Lance Taylor: > Florian Weimer writes: > >> The difference is that the front end does not work on source code, but >> Java bytecode, which seems closer to intermediate representation than >> to a "high-level, non-intermediate language". > > I think i

Re: New GCC Runtime Library Exception

* Ian Lance Taylor: >>> Your argument here seems to be that linking against libgcc makes a >>> program be covered by the definition of "GCC" in the runtime library >>> license. >> >> Right. Why do you think this would not be the case? libgcc is part >> of GCC, so a program linking to libgcc is a

Re: GCC Runtime Library Exception

* Ian Lance Taylor: > After the e-mail flurry, here is my personal summary of the issues > regarding the GCC Runtime Library Exception > (http://www.gnu.org/licenses/gcc-exception.html). Thanks! > One way to resolve this might be to say that a compilation process > is Eligible so long as the

C++ ABI change for std::bad_array_new_length

This C++0X feature seems to need a change in the cross-vendor C++ ABI. Have the details already been spelled out? There is some interaction with the VLA C++ extension. We should probably prohibit allocation of objects of a VLA-based type with operator new and operator new[].

Re: some integer undefined behaviors in gcc

* John Regehr: > I ran gcc 162830 on x86 under a tool that checks for integer undefined > behaviors. The attached error messages show up when running "make > check" and when recompiling gcc. > > Each line in the attachment is an error message giving the problematic > operator, its srcloc, the typ

Re: some integer undefined behaviors in gcc

* Vincent Lefevre: > On 2010-08-07 13:38:05 +0200, Florian Weimer wrote: >> * John Regehr: > [...] >> > Let me know if more detail is needed or if it would be better for me to >> > file all 71 bug reports. >> >> I wonder if we should give up and make -

Re: some integer undefined behaviors in gcc

* Paolo Bonzini: >> There quite a few instances of the x & -x pattern, which would be fine >> with -fwrapv. > > It's always valid if you know that x is not INT_MIN, which you do in > many cases (for example if x is an offset). The reported cases cover the INT_MIN case (these are execution logs, n

<    1   2   3   4   5   6   7   8   >