#pragma

@jannem early versions of gcc ran nethack when you wrote #pragma

which is more benign than the traditional consequence that comp.std.c warned of, saying the compiler could make demons fly out of your nose

I found #pragma clang diagnostic which allows you to save the state, restore the state and disable specific warnings for lines of code.

I'm pretty sure the answer to this is "no", but does anybody know if it's possible to use a pragma in C# to limit code to a specific minimum language version?

Something like:

`#pragma CSharp_13_Or_Greater`

#DotNet #CSharp

@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.

@pamelafox I personally prefer 100% from the get go, and explicitly add #pragma: no-cover for those hard to test scenarios, especially when the project is volunteer-run with limited maintainer bandwidth.

I think @nedbat once said something along the lines of: "when you only have x% coverage, then you don't really know what the rest of the code is doing" 🫠

@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).

The messy reality of SIMD (vector) functions
----
- 2 days ago | 5 points | 0 comments
- URL: https://johnnysswlab.com/the-messy-reality-of-simd-vector-functions/
- Discussions: https://news.ycombinator.com/item?id=44468114
- Summary: The article discusses SIMD (vector) functions, which process multiple data elements per function call to improve performance. It explains how to declare and define vector functions using compiler pragmas or attributes, such as `#pragma omp declare simd`. The article highlights the limitations of SIMD functions, including limited compiler support and inefficient compiler-generated implementations. It also provides guidance on how to provide custom vector implementations using intrinsics and how to override vector functions. The article concludes that while SIMD functions have potential, their effectiveness is hindered by various limitations and caveats.

stm32f4discovery : ELF - Build Failed (lupyuen)
NuttX Dashboard: https://nuttx-dashboard.org
Build History: https://nuttx-dashboard.org/d/fe2q876wubc3kc/nuttx-build-history?var-board=stm32f4discovery&var-config=elf

arm-none-eabi-ld: cannot find /root/nuttx/arch/arm/src/crt0.o: No such file or directory
make[4]: *** [Makefile:57: errno] Error 1
make[4]: Target 'install' not remade because of errors.
make[3]: *** [Makefile:88: errno_install] Error 2
chip/stm32_gpio.c:44:11: note: '#pragma message: C

@zeux @pervognsen fun fact: on RISC-V, the amount of intrinsics for the vector extension would be through the roof due to combinatorial explosion, but they employ

#pragma riscv intrinsic "vector"
(sans quote marks in Clang)

to have the compiler instantiate them all internally. Arm partially employs that tactic too

as a downside, one no longer can fish out intrinsics from installed headers (not to imply that someone would try that on RISC-V)

https://gcc.gnu.org/cgit/gcc/tree/gcc/config/riscv/riscv_vector.h

huh, so it was something to do with my #ifndefs. gcc really really didn't like them.

Replaced them with #pragma once and absolutely no red squiggles now.

Man, I haven't used C++ in ages.

@Ninji maybe i should start adding #pragma no_bugs to my C++ source files, if AI can do it so can gcc

*holds up a sign that says `#pragma optimize("", off)` above you*

:3

olimex-stm32-p407 : KNSH - Build Failed (nuttxpr)
NuttX Dashboard: https://nuttx-dashboard.org
Build History: https://nuttx-dashboard.org/d/fe2q876wubc3kc/nuttx-build-history?var-board=olimex-stm32-p407&var-config=knsh

chip/stm32_gpio.c:44:11: note: '#pragma message: CONFIG_STM32_USE_LEGACY_PINMAP will be deprecated migrate board.h see tools/stm32_pinmap_tool.py'
44 | # pragma message "CONFIG_STM32_USE_LEGACY_PINMAP will be deprecated migrate board.h see tools/stm32_pinmap_tool.py"
| ^~~~~~

How to politely use assert in a header (gcc/clang/msvc/what else?):

#pragma push_macro("NDEBUG")
#undef NDEBUG
#include <assert.h>
// your asserts should properly assert
#pragma pop_macro("NDEBUG")
// nobody has 2 know

Your vendor’s assert.h should be able to be included multiple times with NDEBUG defined or not.

RealProbe: An Automated and Lightweight Performance Profiler for In-FPGA Execution of High-Level Synthesis Designs

Jiho Kim, Cong Hao
https://arxiv.org/abs/2504.03879 https://arxiv.org/pdf/2504.03879 https://arxiv.org/html/2504.03879

arXiv:2504.03879v1 Announce Type: new
Abstract: High-level synthesis (HLS) accelerates FPGA design by rapidly generating diverse implementations using optimization directives. However, even with cycle-accurate C/RTL co-simulation, the reported clock cycles often differ significantly from actual FPGA performance. This discrepancy hampers accurate bottleneck identification, leading to suboptimal design choices. Existing in-FPGA profiling tools, such as the Integrated Logic Analyzer (ILA), require tedious inspection of HLS-generated RTL and manual signal monitoring, reducing productivity. To address these challenges, we introduce RealProbe, the first fully automated, lightweight in-FPGA profiling tool for HLS designs. With a single directive--#pragma HLS RealProbe--the tool automatically generates all necessary code to profile cycle counts across the full function hierarchy, including submodules and loops. RealProbe extracts, records, and visualizes cycle counts with high precision, providing actionable insights into on-board performance. RealProbe is non-intrusive, implemented as independent logic to ensure minimal impact on kernel functionality or timing. It also supports automated design space exploration (DSE), optimizing resource allocation based on FPGA constraints and module complexity. By leveraging incremental synthesis and implementation, DSE runs independently of the original HLS kernel. Evaluated across 28 diverse test cases, including a large-scale design, RealProbe achieves 100% accuracy in capturing cycle counts with minimal logic overhead-just 16.98% LUTs, 43.15% FFs, and 0% BRAM usage. The tool, with full documentation and examples, is available on GitHub.

I feel kind of stupid for never thinking of doing this before, makes finding blocks of code with #pragma mark so much easier.

nucleo-f411re : NSH - Build Failed (NuttX)
NuttX Dashboard: https://nuttx-dashboard.org
Build History: https://nuttx-dashboard.org/d/fe2q876wubc3kc/nuttx-build-history?var-board=nucleo-f411re&var-config=nsh

chip/stm32_gpio.c:44:11: note: '#pragma message: CONFIG_STM32_USE_LEGACY_PINMAP will be deprecated migrate board.h see tools/stm32_pinmap_tool.py'
44 | # pragma message "CONFIG_STM32_USE_LEGACY_PINMAP will be deprecated migrate board.h see tools/stm32_pinmap_tool.py"
| ^~~~~~~
make[1]:

nucleo-f411re : NSH - Build Failed (NuttX)
NuttX Dashboard: https://nuttx-dashboard.org
Build History: https://nuttx-dashboard.org/d/fe2q876wubc3kc/nuttx-build-history?var-board=nucleo-f411re&var-config=nsh

chip/stm32_gpio.c:44:11: note: '#pragma message: CONFIG_STM32_USE_LEGACY_PINMAP will be deprecated migrate board.h see tools/stm32_pinmap_tool.py'
44 | # pragma message "CONFIG_STM32_USE_LEGACY_PINMAP will be deprecated migrate board.h see tools/stm32_pinmap_tool.py"
| ^~~~~~~
make[1]:

@eniko does #pragma warning (disable etc) not respect the color highlighting?

@flyingsaceur

#pragma once

Excuse me?