Re: Bug in closed-source, proprietary software that I do not have access to

2019-05-25 Thread gilles
Thomas, Several SPEC benchmarks are available at no cost for non commercial usage. See https://www.spec.org/order.html, you may qualify Cheers, Gilles - Original Message - > Hi, > > consider this: There is a bug, confirmed by several people. This occurs > in c

Re: AW: AW: [Patch, fortran] PRs 89843 and 90022 - C Fortran Interop fixes.

2019-04-12 Thread Gilles Gouaillardet
dropped (unless mandatory). Cheers, Gilles On 4/12/2019 4:53 PM, Bader, Reinhold wrote: Dear Gilles, -Ursprüngliche Nachricht- Von: Gilles Gouaillardet Gesendet: Freitag, 12. April 2019 02:25 An: Bader, Reinhold ; Paul Richard Thomas ; fort...@gcc.gnu.org; gcc-patches Betreff: Re: AW

Re: AW: [Patch, fortran] PRs 89843 and 90022 - C Fortran Interop fixes.

2019-04-11 Thread Gilles Gouaillardet
interface subroutine bar_f08(buf) BIND(C, name="bar_c") implicit none !GCC$ ATTRIBUTES NO_COPY_IN :: buf TYPE(*), DIMENSION(..), INTENT(IN) :: buf end subroutine end interface end module Does this make sense ? Gilles On 4/10/2019 4:22 PM, Bader, Reinhold wrote: Hi Gilles, I

Re: [Patch, fortran] PRs 89843 and 90022 - C Fortran Interop fixes.

2019-04-10 Thread Gilles Gouaillardet
how this will break a lot of existing apps (once again, those apps might be incorrect in the first place, but most of us got used to them working). To me, this is a second reason why copy-in is not desirable (at least as a default option). Cheers, Gilles On 4/9/2019 7:18 PM, Paul

Re: gcc 4.9.2 and above are not aware of malloc (and friends) hooks

2015-06-15 Thread Gilles Gouaillardet
. (gcc deliberately makes such aggressive optimizations that are known to be illegal in very rare cases, so marking the variable as volatile is not a workaround but a requirement) thanks in advance for the clarification Gilles On Wed, Jun 10, 2015 at 10:33 AM, Gilles Gouaillardet gilles.gouaillar

gcc 4.9.2 and above are not aware of malloc (and friends) hooks

2015-06-08 Thread Gilles Gouaillardet
please comment on this issue ? - is this a bug ? - is this a feature ? (e.g. a known to be aggressive optimization that explicitly requires the global variable is declared as volatile) Thanks and regards, Gilles #include stdlib.h #include malloc.h int global; void *hook (size_t alignment, size_t

Re: [PATCH] Fix logic for detection of zero initializer (PR c/53119)

2014-06-04 Thread S. Gilles
On Wed, Jun 04, 2014 at 03:15:02PM +0200, Marek Polacek wrote: On Mon, Jun 02, 2014 at 12:58:53AM -0400, S. Gilles wrote: Thanks for tackling this. @@ -6858,6 +6858,9 @@ /* 1 if this constructor is erroneous so far. */ static int constructor_erroneous; +/* 1

[PATCH] Fix logic for detection of zero initializer (PR c/53119)

2014-06-01 Thread S. Gilles
test case. If this is approved, could someone commit it for me, as I do not have access? S. Gilles 2014-06-01 S. Gilles sgil...@umd.edu gcc/ChangeLog: PR c/53119 c/ * c-typeck.c (push_init_level, process_init_element, pop_init_level): Correct check for zero initialization

Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)

2009-02-06 Thread Gilles J. Seguin
On Fri, 2009-02-06 at 12:32 +, Joseph S. Myers wrote: On Fri, 6 Feb 2009, Sean Callanan wrote: - Modify the GCC link process to use libltdl and libtool -export-dynamic Although this may make theoretical sense in terms of the work for a cross-platform implementation already being

[Bug inline-asm/38815] New: Taking the address of a __thread variable prevents the r0 register from being loaded

2009-01-12 Thread gilles dot chanteperdrix at xenomai dot org
AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gilles dot chanteperdrix at xenomai dot org GCC target triplet: armeb-unknown-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38815

[Bug inline-asm/38815] Taking the address of a __thread variable prevents the r0 register from being loaded

2009-01-12 Thread gilles dot chanteperdrix at xenomai dot org
--- Comment #1 from gilles dot chanteperdrix at xenomai dot org 2009-01-12 18:03 --- The following code: __thread long tl = 42; long f(void) { long *l = tl; register long r0 __asm__ (r0); register long *r1 __asm__ (r1); r0 = 23; r1 = l

[Bug middle-end/38674] When storing in a register the address of a value contained in the same register, gcc 4.3.2 on ARM clobbers the register before saving its content on the stack.

2009-01-05 Thread gilles dot chanteperdrix at xenomai dot org
--- Comment #1 from gilles dot chanteperdrix at xenomai dot org 2009-01-05 15:21 --- The following, even simpler test case: unsigned long long f(unsigned long long ull) { register unsigned long long *__r0 __asm__ (r0) = ull; __asm__ __volatile__ ( : +r (__r0

[Bug regression/38674] New: optimization bug.

2008-12-30 Thread gilles dot chanteperdrix at xenomai dot org
: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gilles dot chanteperdrix at xenomai dot org GCC target triplet: armeb-unknown-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id