Hi Richard,
>> Now that mpc 1.1.0 was released we could update the versions if we get
>> sufficient
>> "positives" from people testing with newer releases.
>
> I've given it a try with that combo on sparc-sun-solaris2.10 (a primary
> target) and i386-pc-solaris2.10 (32 and 64-bit each), with mixed
On 17.01.2018 09:19, Richard Biener wrote:
> On Tue, Jan 16, 2018 at 8:20 PM, Andrew Roberts
> wrote:
>> Boot strap on Darwin x86_64 with llvm now seems broken as of last 8.0.0
>> snapshot, it still is working fine with 7.2.0.
>> I've added bug: 83903
>>
>> x86_64, armv6, armv7, aarch64 all seem
Hi experts,
I am writing a gcc plugin for parsing the structure fields. But I have the
problem how to get the offset of each field in the struct? Just like the
offsetof macro in gcc.
I see DECL_FIELD_OFFSET in tree.h, but the result seems not right.
My test program could be found in stack ov
On 2018-02-06 10:49:48 +0100, Matthias Klose wrote:
> I have seen some issues with mpfr 4.0.0 on 32bit platforms, however
> not in GCC itself yet. These are all fixed in 4.0.1 rc2, so maybe
> document 4.0.1 instead of 4.0.0 once it is released.
The issues were also present on 64-bit platforms and
On 2018-02-06 17:14:38 +0100, Vincent Lefevre wrote:
> Now, I've just found a "regression" when comparing Sipe results with
> MPFR results, but it is the Sipe result with SIPE_FLOAT equal to 1
> (float) or 2 (double) that is incorrect, 3 (long double) being OK.
> Bug triggered with -O2 -march=nativ
> I am writing a gcc plugin for parsing the structure fields. But I have the
> problem how to get the offset of each field in the struct? Just like the
> offsetof macro in gcc.
>
> I see DECL_FIELD_OFFSET in tree.h, but the result seems not right.
The offset in bits/bytes is given by tree.c:bit_p
On Tue, 6 Feb 2018, Vincent Lefevre wrote:
> The issues were also present on 64-bit platforms and were due to
> a bug in mpfr_div_ui, which has always been present, since 1999.
> With MPFR 4.0.0, they are also visible with mpfr_div just because
> mpfr_div now uses mpfr_div_ui in some simple cases.
On Tue, 6 Feb 2018, Vincent Lefevre wrote:
> Well, if I add -std=c99 or -std=c11, the failure disappears. The
> reason is that GCC generates a FMA (indeed, this new machine has
> a FMA), but this occurs across different C statements. So, maybe
> not a bug, but a bad feature, IMHO.
Use -ffp-contra
Here's a short status report for trunk on x86_64-w64-mingw32 host.
I know this is only a secondary platform, but there are some serius issues.
Especially the ada part is in a bad shape compared to 7.3.0, see
https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg00439.html
and
https://gcc.gnu.org/ml/g
On 6 February 2018 at 18:03, Rainer Emrich wrote:
> At least 20 of the acats tests catch all memory until the host memory is
> exhausted.
> Same holds for the two libstdc++ tests
> 23_containers/unordered_set/requirements/exception/basic.cc
> and
> 23_containers/unordered_set/requirements/excepti
On 2018-02-06 17:32:30 +, Joseph Myers wrote:
> GCC doesn't use mpfr_div at all; it uses MPFR to fold calls to a range of
> libm functions with constant arguments (input and output precisions should
> always be the same, since GCC doesn't yet support built-in functions for
> the TS 18661-1 n
> Here's a short status report for trunk on x86_64-w64-mingw32 host.
>
> I know this is only a secondary platform, but there are some serius issues.
>
> Especially the ada part is in a bad shape compared to 7.3.0, see
> https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg00439.html
> and
> https://
On 2018-02-06 17:34:23 +, Joseph Myers wrote:
> Use -ffp-contract=off to disable all contraction, or -ffp-contract=on to
> disable it between statements (which currently actually disables all
> contraction, as the FMA generation doesn't know what was originally a
> single source expression).
Hi all.
Hopefully this isn't too annoying a question :).
My environment has been using GCC 6.2 (locally compiled) on GNU/Linux
systems. We use a separate heap management library (jemalloc) rather
than the libc allocator. The way we did this in the past was to
declare operator new/delete (all fo
Am 06.02.2018 um 22:50 schrieb Eric Botcazou:
>> Here's a short status report for trunk on x86_64-w64-mingw32 host.
>>
>> I know this is only a secondary platform, but there are some serius issues.
>>
>> Especially the ada part is in a bad shape compared to 7.3.0, see
>> https://gcc.gnu.org/ml/gcc-
Hi,
In this round of GCC stabilization, I've noticed a larger than usual
number of bugs that carried over from earlier cycles, with notes
indicating it was too late to fix them during stabilization.
I wish we had some means to mark such bugs clearly, so that they could
be found easily earlier in
As the person who, eons ago, wrote a bunch of the the GDB code for this C++
ABI support, and as someone who helped with DWARF support in both GDB and
GCC, let me try to propose a useful path forward (in the hopes that someone
will say "that's horrible, do it this instead")
Here are the constraint
> Sorry for the stupid question. How do I pass this to the testsuite?
For ACATS it's a little awkward: you manually need to add it to the gccflags
variable in gcc/testsuite/ada/acats/run_all.sh
--
Eric Botcazou
18 matches
Mail list logo
