On Mon, Jan 21, 2019 at 08:47:42AM +0100, Martin Liška wrote:
> diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
> index 3314e176881..5c7c062574b 100644
> --- a/gcc/fortran/decl.c
> +++ b/gcc/fortran/decl.c
> @@ -11351,6 +11351,7 @@ match
> gfc_match_gcc_builtin (void)
> {
>char builtin[G
On 1/18/19 9:39 AM, Jakub Jelinek wrote:
> On Fri, Jan 18, 2019 at 09:18:33AM +0100, Martin Liška wrote:
>> What about something as simple as this:
>>
>> diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
>> index 3314e176881..2f2b965f97d 100644
>> --- a/gcc/fortran/decl.c
>> +++ b/gcc/fortran/de
On Sun, Jan 20, 2019 at 05:04:24PM -0800, Steve Kargl wrote:
> On Tue, Jan 08, 2019 at 10:27:25PM +0100, Thomas Koenig wrote:
> > Hi Steve,
> >
> > > Well, that was quick. Moving code around is problematic.
> >
> > Thanks for checking. The patch is OK for trunk.
> >
>
> Thanks. I decided to s
Il giorno mar 15 gen 2019 alle ore 03:38 Jonathan Wakely
ha scritto:
> On 12/12/18 22:31 +0100, Giovanni Bajo wrote:
> >Hello,
> >
> >we hit a bug today while cross-compiling a C++ program with mingw32:
> >if random_shuffle or random_sample_n are called with a sequence of
> >elements whose length
On Tue, Jan 08, 2019 at 10:27:25PM +0100, Thomas Koenig wrote:
> Hi Steve,
>
> > Well, that was quick. Moving code around is problematic.
>
> Thanks for checking. The patch is OK for trunk.
>
Thanks. I decided to see if long term approach would work.
It almost does. The attached patch put ie
I was too anxious pressing the send button so that I forgot to mention:
Regtested with no new regressions on x86_64-pc-linux-gnu.
Sorry for that.
Harald
On 01/20/19 23:18, Harald Anlauf wrote:
> Dear all,
>
> here's my revised patch for the treatment of (2**e) ** n and (- 2**e) **
> n, trying
Dear all,
here's my revised patch for the treatment of (2**e) ** n and (- 2**e) **
n, trying to take into account the bitwidth of the result.
I've also extended the testcase to sample different integer kinds.
ChangeLogs see below.
Note: I don't have commit rights, so please somebody else take c
On Thu, Dec 20 2018, Jan Hubicka wrote:
> Dne 2018-12-20 15:36, Martin Jambor napsal:
>> Hi,
>>
>> Ping:
>>
>> On Fri, Dec 07 2018, Martin Jambor wrote:
>> Hi,
>>
>> the patch below adds alias analysis (AA) walk limiting to all
>> walk_alias_vdefs calls invoked as IPA-CP and ipa-fnsummary summar
Hi,
As a prerequisite for enabling subdir-objects to libphobos configure
scripts, the build should be linking to a zlib convenience library,
rather than building the zlib sources directly from libphobos.
Looking at the existing configure scripts, there's already a
libzgcj_convenience.a, it is not
Hi,
This patch fixes a small logic bug, where GNU_StackGrowsDown was
always predefined in the D language environment. Instead, don't
define it where STACK_GROWS_DOWNWARD is defined as zero. With this,
the correct libphobos code paths will now be compiled on hppa-*
targets.
Bootstrapped and regr
On Sun, Jan 20, 2019 at 9:10 AM Bernd Edlinger
wrote:
>
> On 1/20/19 4:40 PM, H.J. Lu wrote:
> > On Sun, Jan 20, 2019 at 5:29 AM Bernd Edlinger
> > wrote:
> >>
> >> Hi,
> >>
> >>
> >> I tried to build linux yesterday, and became aware that there are a few
> >> false-positive warnings with -Waddre
On Sun, Jan 20, 2019 at 10:12 AM Uros Bizjak wrote:
>
> On Sun, Jan 20, 2019 at 7:09 PM Uros Bizjak wrote:
> >
> > On Sun, Jan 20, 2019 at 4:11 PM H.J. Lu wrote:
> > >
> > > On Sun, Jan 20, 2019 at 4:03 AM Uros Bizjak wrote:
> > > >
> > > > On 1/19/19, H.J. Lu wrote:
> > > > > According to Int
On Sun, Jan 20, 2019 at 7:09 PM Uros Bizjak wrote:
>
> On Sun, Jan 20, 2019 at 4:11 PM H.J. Lu wrote:
> >
> > On Sun, Jan 20, 2019 at 4:03 AM Uros Bizjak wrote:
> > >
> > > On 1/19/19, H.J. Lu wrote:
> > > > According to Intel Intrinsics Guide:
> > > >
> > > > https://software.intel.com/sites/l
On Sun, Jan 20, 2019 at 4:11 PM H.J. Lu wrote:
>
> On Sun, Jan 20, 2019 at 4:03 AM Uros Bizjak wrote:
> >
> > On 1/19/19, H.J. Lu wrote:
> > > According to Intel Intrinsics Guide:
> > >
> > > https://software.intel.com/sites/landingpage/IntrinsicsGuide/
> > >
> > > Intel intrinsics should be ava
On 1/20/19 4:40 PM, H.J. Lu wrote:
> On Sun, Jan 20, 2019 at 5:29 AM Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>>
>> I tried to build linux yesterday, and became aware that there are a few
>> false-positive warnings with -Waddress-of-packed-member:
>>
>> struct t {
>> char a;
>> int b;
>> int *c;
Hi,
>
> 2019-01-18 Vineet Gupta
>
>* config/arc/atomic.md: Add operand to DMB instruction
>
This is ok. I'll push it asap,
Claudiu
Since a previous patch introduced the _GLIBCXX_NODISCARD macro it is now
simple to implement the rest of P0600. The parts specific to C++20 were
already added, this patch adds the attribute to the other functions.
Even though the feature specifies the nodiscard attribute only for C++20
it makes n
Hi Segher,
Yes, that's why the PR is still open 😊
The ICE can be reproduced with a much simpler testcase which is the one we use
for repro in the PR, which is now a P1.
The reason for changing this testcase was that it was invalid code.
Regards,
Tamar
-Original Message-
From: Segher Bo
Hi!
On Thu, Jan 17, 2019 at 03:02:00PM +, Tamar Christina wrote:
> This test was added back when builtins were being used instead of ACLE
> intrinsics. The test as far as I can tell is really testing vcombine,
> however some of these builtins no longer exist and causes an ICE.
>
> This fixes
On Sun, Jan 20, 2019 at 5:29 AM Bernd Edlinger
wrote:
>
> Hi,
>
>
> I tried to build linux yesterday, and became aware that there are a few
> false-positive warnings with -Waddress-of-packed-member:
>
> struct t {
> char a;
> int b;
> int *c;
> int d[10];
> } __attribute__((packed));
>
> s
On Sun, Jan 20, 2019 at 4:03 AM Uros Bizjak wrote:
>
> On 1/19/19, H.J. Lu wrote:
> > According to Intel Intrinsics Guide:
> >
> > https://software.intel.com/sites/landingpage/IntrinsicsGuide/
> >
> > Intel intrinsics should be available by including . This
> > patch moves remaining Intel intrin
Gerald Pfeifer writes:
> 2019-01-20 Gerald Pfeifer
>
> * allocfail.c (main): Increase portability of printf statement.
This is OK.
Thanks.
Ian
On Fri, Jan 18, 2019 at 04:02:14PM -0600, Segher Boessenkool wrote:
> Hi Alan,
>
> On Mon, Jan 07, 2019 at 09:29:18AM +1030, Alan Modra wrote:
> > The direct cause of this PR is the fact that tls_gdld_nomark didn't
> > handle indirect calls. Adding the missing support revealed that most
> > indir
Hi,
I tried to build linux yesterday, and became aware that there are a few
false-positive warnings with -Waddress-of-packed-member:
struct t {
char a;
int b;
int *c;
int d[10];
} __attribute__((packed));
struct t t0;
struct t *t1;
struct t **t2;
t2 = &t1;
i1 = t0.c;
I fixed them quic
On Mon, 17 Dec 2018 at 23:05, Iain Buclaw wrote:
>
> On Wed, 28 Nov 2018 at 23:46, Iain Buclaw wrote:
> >
> > On Wed, 28 Nov 2018 at 22:32, Johannes Pfau wrote:
> > >
> > > Next version, addresses the review comments.
> > >
> > > Tested at https://github.com/D-Programming-GDC/GDC/pull/768
> > >
On 1/19/19, H.J. Lu wrote:
> According to Intel Intrinsics Guide:
>
> https://software.intel.com/sites/landingpage/IntrinsicsGuide/
>
> Intel intrinsics should be available by including . This
> patch moves remaining Intel intrinsics head files from to
> .
I can't find the quoted requirement in
This addresses another fallout from the libbacktrace changes applied
in November.
libbacktrace/allocfail.c has the following declaration:
extern uint64_t get_nr_allocs (void);
And in line 133 then the following:
fprintf (stderr, "%lu\n", get_nr_allocs ());
On a 32-bit system such as x86 t
Hi,
PR 88698 ("Relax generic vector conversions") is asking to be more permissive
about type compatibility for generic vector types. While I don't think that's
a good idea per se, from a "compiler user" point of view I also see how writing
code for SSE/AVX using both generic vectors and x86 intri
28 matches
Mail list logo
