Let's just commit the #undef so that seawasp is green and back to
being ready to tell us if something else breaks.
+1. I was afraid that working around this would be impossibly
painful ... but if it just takes one judiciously placed #undef,
let's do that and not argue about it.
Done.
Hi,
On 2019-07-29 10:27:54 +1200, Thomas Munro wrote:
> On Mon, Jul 29, 2019 at 9:55 AM Tom Lane wrote:
> > Thomas Munro writes:
> > > Let's just commit the #undef so that seawasp is green and back to
> > > being ready to tell us if something else breaks.
> >
> > +1. I was afraid that working
On Mon, Jul 29, 2019 at 9:55 AM Tom Lane wrote:
> Thomas Munro writes:
> > Let's just commit the #undef so that seawasp is green and back to
> > being ready to tell us if something else breaks.
>
> +1. I was afraid that working around this would be impossibly
> painful ... but if it just takes
Thomas Munro writes:
> Let's just commit the #undef so that seawasp is green and back to
> being ready to tell us if something else breaks.
+1. I was afraid that working around this would be impossibly
painful ... but if it just takes one judiciously placed #undef,
let's do that and not argue
On Mon, Jul 29, 2019 at 8:03 AM Fabien COELHO wrote:
> If reordering includes is not an option, too bad. Then "#undef Min" which
> I find disputable, allthough I've done much worse... it might or might not
> work depending on what is done afterwards. Or rename the macro, as I
> suggested first,
Hello Tom,
They should be fully independent anyway, so the order should
not matter?
On what grounds do you claim that's true anywhere, let alone
everywhere?
I mean that the intersection of Postgres realm, a database written in C,
and LLVM realm, a compiler written in C++, should not
Fabien COELHO writes:
> Otherwise, why not simply move llvm C++ includes *before* postgres
> includes?
We've been burnt in the past by putting other headers before postgres.h.
(A typical issue is that the interpretation of varies depending
on _LARGE_FILES or a similar macro, so you get
Hello Thomas,
I would just #undef Min for our small number of .cpp files that
include LLVM headers. It's not as though you need it in C++, which
has std::min() from .
Like so. Fixes the problem for me (llvm-devel-9.0.d20190712).
Hmmm. Not so nice, but if it works, why not, at least the
On Sat, Jul 27, 2019 at 7:12 PM Thomas Munro wrote:
> On Sat, Jul 27, 2019 at 7:06 PM Fabien COELHO wrote:
> > Maybe we should consider doing an explicit bug report, but I would not bet
> > that they are going to fold… or fixing the issue pg side, eg "pg_Min",
> > less than 400 hundred
On Sat, Jul 27, 2019 at 7:06 PM Fabien COELHO wrote:
> >>> c.h defines a C Min macro conflicting with llvm new class
> >>> llvm:ElementCount Min member
> >>
> >> Really? Well, we will hardly be the only code they broke with that.
> >> I think we can just wait for them to reconsider.
> >
> > FYI
c.h defines a C Min macro conflicting with llvm new class
llvm:ElementCount Min member
Really? Well, we will hardly be the only code they broke with that.
I think we can just wait for them to reconsider.
FYI This is now on LLVM's release_90 branch, due out on August 28.
Maybe we should
On Fri, Jun 7, 2019 at 12:13 PM Tom Lane wrote:
> didier writes:
> > c.h defines a C Min macro conflicting with llvm new class
> > llvm:ElementCount Min member
>
> Really? Well, we will hardly be the only code they broke with that.
> I think we can just wait for them to reconsider.
FYI This is
didier writes:
> c.h defines a C Min macro conflicting with llvm new class
> llvm:ElementCount Min member
Really? Well, we will hardly be the only code they broke with that.
I think we can just wait for them to reconsider.
regards, tom lane
failure). Apparently clang got upgraded from "trunk 361691" to "trunk
362290" ... is the new clang broken?
I think that machine might also update llvm to a trunk checkout. Is that
right Fabien?
Yes, the version is recompiled from sources on every Saturday.
--
Fabien.
c.h defines a C Min macro conflicting with llvm new class
llvm:ElementCount Min member
On Thu, Jun 6, 2019 at 7:32 PM Alvaro Herrera wrote:
>
> Seawasp (using experimental clang 9.0) has been complaining of late:
>
> /home/fabien/clgtk/bin/clang -Wno-ignored-attributes -fno-strict-aliasing
>
Hi,
On 2019-06-06 13:32:16 -0400, Alvaro Herrera wrote:
> Seawasp (using experimental clang 9.0) has been complaining of late:
>
> /home/fabien/clgtk/bin/clang -Wno-ignored-attributes -fno-strict-aliasing
> -fwrapv -O2 -D__STDC_LIMIT_MACROS -D__STDC_FORMAT_MACROS
> -D__STDC_CONSTANT_MACROS
Seawasp (using experimental clang 9.0) has been complaining of late:
/home/fabien/clgtk/bin/clang -Wno-ignored-attributes -fno-strict-aliasing
-fwrapv -O2 -D__STDC_LIMIT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_CONSTANT_MACROS -D_DEBUG -D_GNU_SOURCE -I/home/fabien/clgtk/include
17 matches
Mail list logo
