search for: dabb5z75

...__q; double __d; }; extern const __declspec(selectany) U __PL_nan_u = { 0x7FF8000000000000UI64 }; I guess cl.exe applies the declspec to __PL_nan_u while we try to apply it to the type? (Even though it's written before "union", so according to https://msdn.microsoft.com/en-us/library/dabb5z75.aspx it should apply to the variable.) Is there a bug filed for this? > > > On Wed, Jul 15, 2015 at 1:25 AM, Hans Wennborg <hans at chromium.org> wrote: > >> Hi all, >> >> The 3.7 release branch was created from trunk at r242221 today (around >> 10:40 pm...

...rn const __declspec(selectany) U __PL_nan_u = { 0x7FF8000000000000UI64 > }; > > I guess cl.exe applies the declspec to __PL_nan_u while we try to apply it > to the type? (Even though it's written before "union", so according to > https://msdn.microsoft.com/en-us/library/dabb5z75.aspx it should apply to > the variable.) Is there a bug filed for this? > (Filed https://llvm.org/bugs/show_bug.cgi?id=24251) > > > >> >> >> On Wed, Jul 15, 2015 at 1:25 AM, Hans Wennborg <hans at chromium.org> wrote: >> >>> Hi all, >>&...

...selectany) U __PL_nan_u = { >> 0x7FF8000000000000UI64 }; >> >> I guess cl.exe applies the declspec to __PL_nan_u while we try to apply >> it to the type? (Even though it's written before "union", so according to >> https://msdn.microsoft.com/en-us/library/dabb5z75.aspx it should apply >> to the variable.) Is there a bug filed for this? >> > > (Filed https://llvm.org/bugs/show_bug.cgi?id=24251) > After some discussion on that bug, we think it'd be better if perl could change that header, given that it's pretty new code (see the b...

Hi all, The 3.7 release branch was created from trunk at r242221 today (around 10:40 pm UTC). Branch policy: - Any doc changes can go in. Updates to the release notes are highly encouraged, and should be committed directly to the branch. - All other patches should be approved by the release manager (me) and the appropriate code owner. To get a change merged, commit it to trunk, and then reply