Re: Attribute alloc__size use and clang 5.0.1 vs. gcc7 (e.g.): __builtin_object_size(p,1) and __builtin_object_size(p,3) disagreements result

On 01/21/18 12:59, Pedro Giffuni wrote: Hi; On 01/21/18 11:56, Mark Millard wrote: [May be an __alloc_size2(n,s) should be added and used?] On 2018-Jan-20, at 5:05 PM, Pedro Giffuni <p...@freebsd.org> wrote: Very interesting , thanks for running such tests ... On 01/20/18 18:59

Re: Attribute alloc__size use and clang 5.0.1 vs. gcc7 (e.g.): __builtin_object_size(p,1) and __builtin_object_size(p,3) disagreements result

Hi; On 01/21/18 11:56, Mark Millard wrote: [May be an __alloc_size2(n,s) should be added and used?] On 2018-Jan-20, at 5:05 PM, Pedro Giffuni <p...@freebsd.org> wrote: Very interesting , thanks for running such tests ... On 01/20/18 18:59, Mark Millard wrote: [Noting

Re: Attribute alloc__size use and clang 5.0.1 vs. gcc7 (e.g.): __builtin_object_size(p,1) and __builtin_object_size(p,3) disagreements result

Very interesting , thanks for running such tests ... On 01/20/18 18:59, Mark Millard wrote: [Noting a typo in the program source, and so in the output text: the 2nd occurance of: "my_calloc_alt0 should have been: "my_calloc_alt1 . Hand edited corrections below for clarity.] On 2018-Jan-20, at

ARM broken since a while

On 11/25/17 15:28, Pedro Giffuni wrote: ... I have seen problems on arm with zstd though. For the record: arm.armv6 buildworld failed, check _.arm.armv6.buildworld for details ===> lib/libzstd (all) Assertion failed: (LiveCPSR && "CPSR liveness tracking is wro

Re: head -r326193 (e.g.) buildworld broken: rejecting some . . ./usr/src/amd64.amd64/tmp/usr/include/stdio.h content

Thank you for the report ... On 11/25/17 15:15, Mark Millard wrote: [Quick top post:] Reverting to -r326192 and rebuilding avoided the issue. Prior notes: On 2017-Nov-25, at 12:02 PM, Mark Millard wrote: For example,

Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

> On Apr 13, 2017, at 20:38, Mark Millard wrote: > > [I accidentally sent the original of the "on . . . wrote" > below to the wrong toolchain list. This just corrects that.] > > [I'll also note that lang/gcc6-aux was indirectly attempted > when I tried to build

Re: Time to enable partial relro

For the record ... On 08/26/16 20:10, Pedro Giffuni wrote: On 26/08/2016 19:00, Warner Losh wrote: ... I think we should move forward, just want to make sure it doesn’t break some arch completely before moving ahead. While lld is a goal, the goal is also to have a ld.bdf installed for 12

Re: Time to enable partial relro

On 26/08/2016 19:00, Warner Losh wrote: On Aug 26, 2016, at 12:25 PM, Pedro Giffuni <p...@freebsd.org> wrote: On 26/08/2016 11:48, Warner Losh wrote: On Aug 26, 2016, at 9:14 AM, Pedro Giffuni <p...@freebsd.org> wrote: Hello; On 08/26/16 10:06, Warner Losh wrote: On Fri,

Re: Time to enable partial relro

On 26/08/2016 11:48, Warner Losh wrote: On Aug 26, 2016, at 9:14 AM, Pedro Giffuni <p...@freebsd.org> wrote: Hello; On 08/26/16 10:06, Warner Losh wrote: On Fri, Aug 26, 2016 at 9:00 AM, Pedro Giffuni <p...@freebsd.org> wrote: On 08/26/16 05:56, Konstantin Belousov wrote: On

Re: Time to enable partial relro

On 08/26/16 10:08, Warner Losh wrote: On Fri, Aug 26, 2016 at 9:06 AM, Pedro Giffuni <p...@freebsd.org> wrote: On 08/26/16 10:01, Warner Losh wrote: On Fri, Aug 26, 2016 at 8:36 AM, Ed Maste <ema...@freebsd.org> wrote: On 26 August 2016 at 10:18, Warner Losh <i...@bs

Re: Time to enable partial relro

On 08/26/16 05:56, Konstantin Belousov wrote: On Thu, Aug 25, 2016 at 05:50:31PM -0500, Pedro Giffuni wrote: Hello; GNU RELRO support was committed in r230784 (2012-01-30) but we never enabled it by default. There was some discussion about it on https://reviews.freebsd.org/D3001 By now

Time to enable partial relro

Hello; GNU RELRO support was committed in r230784 (2012-01-30) but we never enabled it by default. There was some discussion about it on https://reviews.freebsd.org/D3001 By now, all Linux distributions, NetBSD and DragonFly support it and it is the default for most systems in binutils 2.27.

Re: unable to build FreeBSD 11-CURRENT with gcc on amd64

It looks to me like -current is broken with gcc-4.2.1 ? Not sure anybody cares, but we are testing the FORTIFY_SOURCE support with gcc-4.2.1 as we plan to support all the base compilers. Pedro. On 08/13/15 11:07, Oliver Pinter wrote: Hi Pedro and current! I have the problem with the

[CFR] FORTIFY_SOURCE

Dear developers; As part of this year's Google Summer of Code [1] Oliver Pinter and I have been working on implementing the FORTIFY_SOURCE libc extension. The idea, initially implemented in GNU libc is to use the gcc's __builtin_object_size to replace many common string functions with bounds

Re: WITH_CTF vs -g

Hi Andriy; Il giorno 10/set/2014, alle ore 12:23, Andriy Gapon a...@freebsd.org ha scritto: In my opinion WITH_CTF should imply -g in CFLAGS otherwise, as far as I can see, there is nothing to generate CTF data from. Forcing an end-user to remember to additionally pass -g is not nice.

Re: Apple's GCC 42 enhancements (was Re: [CFT] Experimental gcc update).

On 02.01.2014 15:22, Pedro Giffuni wrote: Heloo and Happy New Year! On 24.11.2013 07:54, David Chisnall wrote: On 23 Nov 2013, at 22:11, Pedro Giffunip...@freebsd.org wrote: I have particular interest in -fwritable-strings and the block support, mostly with the idea of making our gcc

Re: Apple's GCC 42 enhancements (was Re: [CFT] Experimental gcc update).

On 24.11.2013 10:11, Warner Losh wrote: On Nov 24, 2013, at 5:54 AM, David Chisnall wrote: On 23 Nov 2013, at 22:11, Pedro Giffuni p...@freebsd.org wrote: I have particular interest in -fwritable-strings and the block support, mostly with the idea of making our gcc somewhat more compatible

Apple's GCC 42 enhancements (was Re: [CFT] Experimental gcc update).

Hi; I committed the patches from Google's old gcc 4.2.1. I would like to work slowly on bringing some changes from Apple's GCC now. I have particular interest in -fwritable-strings and the block support, mostly with the idea of making our gcc somewhat more compatible to clang. Maybe someone is

[CFT] Experimental gcc update

Hi; Apparently Google has an enhanced gcc distribution for Android [1] and I found a series of interesting patches there. Most of the patches are backports of patches produced by Google employees and submitted to the FSF. The license hasn't been changed from the GPLv2. While gcc doesn't

Stack tool for optimization-unstable code

Hello; I was looking at some article referred by IT world (and later Slashdot) for this tool: http://css.csail.mit.edu/stack/ It tries to find out non-obvious bugs of the type that are caused by compiler optimizations. The master version at github has a build issue for FreeBSD but the inline

[CFT] gcc: support for barcelona

Hello; Almost a year ago I tried to bring in the support for AMD's barcelona chipset into our gcc. This actually filled a lot of holes in that were left when similar intel support was brought in. Unfortunately I had to revert rapidly such support as it broke building some C++ ports even when it

Re: [CFT] gcc: support for barcelona

On 27.05.2013 14:38, Dimitry Andric wrote: On May 27, 2013, at 21:12, Rui Paulo rpa...@felyko.com wrote: On 27 May 2013, at 09:41, Pedro Giffuni p...@freebsd.org wrote: Almost a year ago I tried to bring in the support for AMD's barcelona chipset into our gcc. This actually filled a lot

Re: Miscellaneous questions

Hello; El 03/05/2013 5:30 a. m., Dimitry Andric escribió: ... 2.) Alternative linkers Is there a document available detailing the current feasible linkers and their status? e.g., is it possible to build a working system with mclinker, gold, etc., and what is the process for accomplishing

Re: base gcc and _GLIBCXX_USE_C99

Hello; On 02/03/2013 17:33, Dimitry Andric wrote: On 2013-02-01 15:46, Pedro Giffuni wrote: On 02/01/2013 08:01, Andriy Gapon wrote: on 28/01/2013 17:11 Andriy Gapon said the following: I wonder why the following is the case for the base gcc. /usr/include/c++/4.2/bits/c++config.h: /* Define

Re: base gcc and _GLIBCXX_USE_C99

Hello Dimitry; - Messaggio originale - Da: Dimitry Andric  I had a bit more in-depth look at our current libstdc++ configuration. I took the original gcc 4.2.1 release tarball, modified a few autoconf related scripts to cope with freebsd10.0 being the current version, and did a

Re: base gcc and _GLIBCXX_USE_C99

Hello; On 02/01/2013 08:01, Andriy Gapon wrote: [ping] on 28/01/2013 17:11 Andriy Gapon said the following: Guys, I wonder why the following is the case for the base gcc. /usr/include/c++/4.2/bits/c++config.h: /* Define if C99 functions or macros from wchar.h, math.h, complex.h,

Re: Removing default build of gcc

Hello; Sorry for top-posting: I am in a mobile device that doesnt know better. I am aware that openoffice is also broken due to stlport. The situation is not too different from the fortran removal: for many reasons it is convenient to use a pre-packaged compiler for many ports. Gcc 4.2.1 is

Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1

- Messaggio originale - Da: Konstantin Belousov  On Sun, Jan 20, 2013 at 04:52:00PM +, Hongli Lai wrote: Number:        175453 Category:      standards Synopsis:      Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 Confidential:  no Severity:     

Re: GCC update for testing

On 05/18/12 02:08, Gleb Kurtsou wrote: On (17/05/2012 10:44), Pedro Giffuni wrote: Hi; I took a bunch of patches that were merged into the GCC 4.1 branch (under GPLv2) and prepared a patch for merging them into our base gcc. These are supposed to be bug fixes only. You can get the patch here

Re: GCC update for testing

Hi again; On 05/17/12 11:44, Dimitry Andric wrote: On 2012-05-17 17:44, Pedro Giffuni wrote: Hi; I took a bunch of patches that were merged into the GCC 4.1 branch (under GPLv2) and prepared a patch for merging them into our base gcc. These are supposed to be bug fixes only. You can get

GCC update for testing

Hi; I took a bunch of patches that were merged into the GCC 4.1 branch (under GPLv2) and prepared a patch for merging them into our base gcc. These are supposed to be bug fixes only. You can get the patch here: http://people.freebsd.org/~pfg/patches/patch-contrib-gcc And, for those really

Re: GCC update for testing

Hi Dimitry; On 05/17/12 11:44, Dimitry Andric wrote: On 2012-05-17 17:44, Pedro Giffuni wrote: Hi; I took a bunch of patches that were merged into the GCC 4.1 branch (under GPLv2) and prepared a patch for merging them into our base gcc. These are supposed to be bug fixes only. You can get

DragonFly added support for ELF preinit, init, and fini arrays

Hello; FYI, this commit in DragonFly seems interesting: http://leaf.dragonflybsd.org/mailarchive/commits/2012-02/msg00146.html It appears like linux had them from a while and some years ago they started using them for C++ in gcc: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01872.html