alcinnz
boosted
#warning or #error would append lines to secondary outputs. I don't know if I have anything for #pragma to do.
Specific to GLSL #version checks if our parser supports the given version. Whilst #extension checks whether our parser supports a given extension possibly enabling or disabling it, or complaining about its support or lack thereof. Depending on what's requested.
Funny thing about discussing the C, GLSL, etc preprocessor on the fediverse. Directives get confused for hashtags!
4/4 Fin!
I'd track a stack of control-flow preprocessor lines tracking whether to keep or discard the lines between them, inserting #line where needed. This is how I'd handle #if, #elif, #else, #endif, #ifdef, #ifndef, #elifdef, #elifndef.
Some of these take identifiers whose presence it should check in the macros table, others would interpret infix expressions via a couple stacks & The Shunting Yard Algorithm. Or they simply end a control-flow block.
#undef removes an entry from the macros table.
3/4
#warning or #error would append lines to secondary outputs. I don't know if I have anything for #pragma to do.
Specific to GLSL #version checks if our parser supports the given version. Whilst #extension checks whether our parser supports a given extension possibly enabling or disabling it, or complaining about its support or lack thereof. Depending on what's requested.
Funny thing about discussing the C, GLSL, etc preprocessor on the fediverse. Directives get confused for hashtags!
4/4 Fin!
oh here's a blast from the past
PythonWorks will initially be available on Windows 95, 98, and NT. Versions for Solaris 2.6 and later, Digital Unix 4, and Linux will be released in early 2000. [Availability on other platforms depends on demand.]
solaris mentioned before linux and "other platforms" beyond linux are considered important enough to at least gesture towards
they're SO sassy about msvc lmao
#pragma optimize("agtw", on) /* doesn't seem to make much difference... /
#pragma warning(disable: 4710) / who cares if functions are not inlined 😉 /
/ fastest possible local call under MSVC */
#define LOCAL(type) static __inline type __fastcall
only change since the year 2000 was to avoid lumping in clang-cl with msvc earlier this year (from someone else who also contributed to the jit). didn't ms fire their whole python team recently? that's sad i forgot about that
@ayba to avoid features creep, I would say. We don't need ` #pragma once`, because ` #ifndef` already solves that problem. Keeping things simple (in the scientific sense of "composed of fewer elements") is the spirit of C. There are already many other languages that provide tons of features and many different ways to do the same thing, I'm glad C sticks to its specificity.
d@nny disc@ mc²
boosted
@hipsterelectron @dragon I tend to believe the #prgama/optimization attribute for optimizations should really only be used for debugging purposes. There are other ways to do things without them. E.g the noipa, noclone, noipa attributes (note clang only knows about the noinline one). Compiler barriers could be used too.
Or the new #pragama to mark loops to unroll or not to vectorize.
The ` #pragma openmp simd` one could used with just -fopenmp-simd and you dont need the full openmp support is another example there.
The ones for #pragma/attribute to change the target are valid uses in headers though.
Note the #pragma for optimization is supposed to change the OPTIMIZATION macro but that is broken with gcc' c++ frontend until a few weeks ago (I pushed a fix for it).
@dragon i actually think this is a terrible idea because optimization settings should be under the control of the end user not the upstream codebase. i'm not sure of a way to thread this because generally compilers don't give you the ability to select specific types of optimization passes to perform, just a generic set of all passes under the 0-3 optimization levels. having a semantic query language for optimization passes which can be matched against whatever compiler would be pretty cool tbh but as is this seems worse than useless. cc @pinskia wondering if you would agree
@hipsterelectron @dragon I tend to believe the #prgama/optimization attribute for optimizations should really only be used for debugging purposes. There are other ways to do things without them. E.g the noipa, noclone, noipa attributes (note clang only knows about the noinline one). Compiler barriers could be used too.
Or the new #pragama to mark loops to unroll or not to vectorize.
The ` #pragma openmp simd` one could used with just -fopenmp-simd and you dont need the full openmp support is another example there.
The ones for #pragma/attribute to change the target are valid uses in headers though.
Note the #pragma for optimization is supposed to change the OPTIMIZATION macro but that is broken with gcc' c++ frontend until a few weeks ago (I pushed a fix for it).