[no subject]
Jonathan Wakely wrote: >> >On Sun, 9 Feb 2025, 00:24 Frederick Virchanza Gotham wrote: >> As the GNU compiler make its way through a translation unit, more and >> more classes get declared. So for each translation unit, the compiler >> maintains a list of what types it has seen so far. >> >> Could someone please point me to where in the GNU g++ source code I >> will find this container object? What's the name of the container, and >> in what source file is it defined? >> >> I want to add 'std::vector' to the container implicitly so that we can >> write a translation unit without needing to do "#include ". My >> end game idea is to add forward declarations for all standard library >> classes. > > > Why? That seems like it will just permit invalid code. > > Why not use 'import std;' instead? This would be an alternative to modules (seeing as how modules might become deprecated in the future). The idea is that every standard library class would be implicitly forward-declared, meaning you don't have to do "#include " if you need a forward declaration for std::vector.
Re:
Am Mi., 12. Feb. 2025 um 10:52 Uhr schrieb Frederick Virchanza Gotham via Gcc : > This would be an alternative to modules (seeing as how modules might > become deprecated in the future). Huch? Where did you catch that? Did I miss something? Best Regards, Tobias
22% degradation seen in embench:matmult-int
Embench is used for benchmarking on embedded devices. This one project matmult-int has a function Multiply. It’s a matrix multiplication for 20 x 20 matrix. The device is a ATSAME70Q21B which is Cortex-M7 The compiler is arm branch based on GCC version 13 We are compiling with O3 which has loop-interchange pass on by default. When we compile with -fno-loop-interchange we get all 22% back plus 5% speed up. When we do the loop interchange on the one loop nest that get interchanged it is slightly (.7%) faster. Has anyone else seen large degradation as a result of loop interchange? Thanks
Re: 22% degradation seen in embench:matmult-int
* When we do the loop interchange on the one loop nest that get interchanged in the program source it is slightly (.7%) faster. From: Gcc on behalf of Visda.Vokhshoori--- via Gcc Date: Wednesday, February 12, 2025 at 10:38 AM To: gcc@gcc.gnu.org Subject: 22% degradation seen in embench:matmult-int EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe Embench is used for benchmarking on embedded devices. This one project matmult-int has a function Multiply. It’s a matrix multiplication for 20 x 20 matrix. The device is a ATSAME70Q21B which is Cortex-M7 The compiler is arm branch based on GCC version 13 We are compiling with O3 which has loop-interchange pass on by default. When we compile with -fno-loop-interchange we get all 22% back plus 5% speed up. When we do the loop interchange on the one loop nest that get interchanged it is slightly (.7%) faster. Has anyone else seen large degradation as a result of loop interchange? Thanks
Re: 22% degradation seen in embench:matmult-int
On Wed, Feb 12, 2025 at 4:38 PM Visda.Vokhshoori--- via Gcc wrote: > > Embench is used for benchmarking on embedded devices. > This one project matmult-int has a function Multiply. It’s a matrix > multiplication for 20 x 20 matrix. > The device is a ATSAME70Q21B which is Cortex-M7 > The compiler is arm branch based on GCC version 13 > We are compiling with O3 which has loop-interchange pass on by default. > > When we compile with -fno-loop-interchange we get all 22% back plus 5% speed > up. > > When we do the loop interchange on the one loop nest that get interchanged it > is slightly (.7%) faster. > > Has anyone else seen large degradation as a result of loop interchange? I would suggest to compare the -fopt-info diagnostic output with and without -fno-loop-interchange, the interchanged loop might for example no longer vectorize. Other than that - no, loop interchange isn't applied very often and it has a very conservative cost model. Are you able to share a testcase? Richard. > > Thanks
Classes Implicitly Declared
Tobias wrote: >>Am Mi., 12. Feb. 2025 um 10:52 Uhr schrieb Frederick Virchanza Gotham: >> This would be an alternative to modules (seeing as how modules might >> become deprecated in the future). >Huch? Where did you catch that? Did I miss something? I think it might be a possibility given how compiler vendors (and also vendors of tools like CMake) aren't really getting very far with modules. They've had a few years already.
Re: Classes Implicitly Declared
On Wed, Feb 12, 2025 at 10:46:23PM +, Frederick Virchanza Gotham via Gcc wrote: > Tobias wrote: > > >>Am Mi., 12. Feb. 2025 um 10:52 Uhr schrieb Frederick Virchanza Gotham: > >> This would be an alternative to modules (seeing as how modules might > >> become deprecated in the future). > > >Huch? Where did you catch that? Did I miss something? > > > I think it might be a possibility given how compiler vendors (and also > vendors of tools like CMake) aren't really getting very far with > modules. They've had a few years already. FWIW, I've been helping fix bugs with modules in GCC for the last year and a half or so, and I think we're getting pretty close to something stable. Many real-world examples work now work smoothly. There are of course still bugs to work on if you would like to help fix some of them, and I'm sure that as more people start using modules there'll be many more issues found! So even just attempting to use modules in your own projects with a recent build of GCC and reporting any bugs would be very helpful, if you're interested in contributing. Nathaniel
Re: Classes Implicitly Declared
On Wed, 12 Feb 2025 at 22:47, Frederick Virchanza Gotham via Gcc
wrote:
>
> Tobias wrote:
>
> >>Am Mi., 12. Feb. 2025 um 10:52 Uhr schrieb Frederick Virchanza Gotham:
> >> This would be an alternative to modules (seeing as how modules might
> >> become deprecated in the future).
>
> >Huch? Where did you catch that? Did I miss something?
>
>
> I think it might be a possibility given how compiler vendors (and also
> vendors of tools like CMake) aren't really getting very far with
> modules. They've had a few years already.
tmp$ cat > mod.cc
import std;
int main() {
std::println("OK");
}
tmp$ ~/gcc/15/bin/g++ -fmodules -std=c++23 -fsearch-include-path
bits/std.cc mod.cc
tmp$ ./a.out
OK
