ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
--
──
Dr. Matthia
ssible to add this
> in the future? This could massively simplify writing and maintaining
> multi-platform SIMD code.
>
> Thanks,
> Martin
//
--
──
Dr. Matthias Kretzhttps://kretzfamily.de
GSI Helmholtzzentrum für Schwerionenforschung https://gsi.de
SIMD easy and portable https://github.com/VcDevel/Vc
──
element type. So I agree, `vector_size(auto)` seems
like a possible solution. One could then take the sizeof if the number is
important to know.
--
──
Dr. Matthias Kretzhttps://kretzfamily.de
GSI Helmholtzzentrum für Schwerionenforschung https://gsi.de
SIMD easy and portable https://github.com/VcDevel/Vc
──
s to a substitution failure (SFINAE).
--
──
Dr. Matthias Kretzhttps://kretzfamily.de
GSI Helmholtzzentrum für Schwerionenforschung https://gsi.de
SIMD easy and portable
attribute const,
or for how GCC implements it? :-)
Cheers,
Matthias
--
Dipl.-Phys. Matthias Kretz
http://compeng.uni-frankfurt.de/index.php?id=mkretz
Hi,
On Friday 25 February 2011 16:26:24 Richard Guenther wrote:
> On Fri, Feb 25, 2011 at 4:19 PM, Matthias Kretz wrote:
> > My expectation was, that, since the ctor has a constructed object as
> > return value, the compiler is free, instead of calling a ctor twice for
>
e data
pointed to must not be declared const. This includes all C++ member functions,
including constructors, which have an implicit this-pointer argument.
On Friday 25 February 2011 17:42:40 Dave Korn wrote:
> On 25/02/2011 15:43, Matthias Kretz wrote:
> > I fully understand why it happene
Hi,
On Friday 25 February 2011 19:37:27 Jonathan Wakely wrote:
> On 25 February 2011 17:05, Matthias Kretz wrote:
> > I'm saying that the way I thought about const + ctor seems logical (if
> > you are not a compiler developer at least :-) ). Regardless of how well
> > de
rd
=
I'd look into implementing this for GCC 4.7, if you like the idea. Unless, of
course, somebody else prefers to do it instead. :-)
[1] https://bugs.launchpad.net/bugs/780551
Cheers,
Matthias
--
Dipl.-Phys. Matthias Kretz
http://compeng.uni-frankfurt.de/?mkretz
SIMD easy and portable: http://compeng.uni-frankfurt.de/?vc
On Thursday 26 May 2011 12:18:19 Richard Guenther wrote:
> On Thu, May 26, 2011 at 12:06 PM, Matthias Kretz wrote:
> > __GNUC_DISTRIBUTOR___
> > This macro is defined in releases of GCC that are prepared by entities
> > other than the FSF. The actual name of the macro depends
g, possibly provide a patch, and hope for
better days.
> you still need to rely on configure checks to see what
> actually works with a given compiler.
I agree. This will not be the silver bullet. But I believe it would still
improve things.
Regards,
Matthias
--
Dipl.-Phys. Matthias
ny further support than that RedHat already had the need
for this macro themselves --- I guess I should end this thread here. Don't
want to waste our time any further...
Cheers,
Matthias
--
Dipl.-Phys. Matthias Kretz
http://compeng.uni-frankfurt.de/?mkretz
SIMD easy and portable: http://compeng.uni-frankfurt.de/?vc
Hi,
On Thursday 26 May 2011 12:06:18 Matthias Kretz wrote:
> if you like the idea
Richard and Jonathan don't like it - or doubt its effectiveness.
Ian supports the idea. Jakub and Nathan mentioned that they already do
something like it, so can I count that as "like"? :)
Shou
rd to write. Markup
languages have gotten better and I really hope we can move on!
> >>> 5) Lack of macros.
> >>>
> >>> AFAIK, only simple textual substitution is available, no macros
> >>> with arguments.
I don't recall for su
question:
https://godbolt.org/z/3cKq5hT1o
--
──────
Dr. Matthias Kretz https://mattkretz.github.io
GSI Helmholtz Centre for Heavy Ion Research https://gsi.de
std::experimental::simd https://github.com/VcDevel/std-simd
──
ve
a similar effect. But the inline asm hammer is really too big for the problem.
--
──────
Dr. Matthias Kretz https://mattkretz.github.io
GSI Helmholtz Centre for Heavy Ion Research https://gsi.de
std::experimental::simd https://github.com/VcDevel/std-simd
──
g to look into a patch to libstdc++, building
upon the above sketch as a starting point. Ultimately, if this becomes a
viable build mode, I'd like to have a replacement for the [[gnu::error("")]]
hack with a dedicated builtin.
- Matthias
--
On Saturday, 29 June 2024 16:20:55 GMT+2 Martin Uecker wrote:
> Am Samstag, dem 29.06.2024 um 08:50 -0500 schrieb Matthias Kretz via Gcc:
> > I.e. once UB becomes IFNDR, the dreaded time-travel optimizations can't
> > happen anymore. Instead precondition checks bubble up becau
On Sunday, 30 June 2024 08:33:35 GMT+2 Martin Uecker wrote:
> Am Sonntag, dem 30.06.2024 um 05:03 +0200 schrieb Matthias Kretz:
> > On Saturday, 29 June 2024 16:20:55 GMT+2 Martin Uecker wrote:
> > > Am Samstag, dem 29.06.2024 um 08:50 -0500 schrieb Matthias Kretz via
Gcc:
&g
0M. The latter variant needs 24x longer to compile.
Are long flat template argument/parameter lists a special problem? Why does it
make overload resolution *so much more* expensive?
Beyond that torture test (should I turn it into a PR?), what can I do to help?
Thanks,
Matthias
--
─
20 matches
Mail list logo
