'TREE_READONLY' for 'const' array in C vs. C++

Hi! In Nvidia PTX, "A state space is a storage area with particular characteristics. All variables reside in some state space. [...]". These include: .const Shared, read-only memory. .global Global memory, shared by all threads. Implemented via 'TARGET_ENCODE_SECTION_INFO', GCC/nvptx

Re: GSoC Interest in enhancing OpenACC support

Hi Pau! On 2025-03-19T21:53:22-0400, Pau Sum via Gcc wrote: > Hey GCC Community, Welcome to GCC! > I am interested in contributing to the "Enhance OpenACC Support" project for > Google Summer of Code 2025. Thanks for your interest! I saw you also briefly discussed on GCC IRC. I'm logged in,

Re: GSoC 2025: In-Memory Filesystem for GPU Offloading Tests

Hi Arijit, Andrew! Arijit, welcome to GCC! On 2025-03-11T03:26:44+0530, Arijit Kumar Das via Gcc wrote: > Thank you for the detailed response! This gives me a much clearer picture > of how things work. > > Regarding the two possible approaches: > >- I personally find *Option A (self-containe

nvptx: Don't use PTX '.const', constant state space [PR119573] (was: 'TREE_READONLY' for 'const' array in C vs. C++)

Hi! I have, by the way, filed <https://gcc.gnu.org/PR119573> "nvptx: PTX '.const', constant state space" for this topic. On 2025-04-01T09:32:46+0200, Jakub Jelinek wrote: > On Tue, Apr 01, 2025 at 09:19:08AM +0200, Richard Biener via Gcc wrote: >> On Tue, Apr

Re: GSoC OpenACC

Hi Carter! On 2025-03-30T22:00:41+, Carter Weidman via Gcc wrote: > My name is Carter. I’m looking to become active in the GCC community. Welcome to GCC! > I would of course love to be funded through GSoC (and will most definitely be > submitting a formal proposal) but will contribute reg

Re: GSoC: Application Proposal for Simple File System for Nvidia and AMD GPU Code Testing

Hi Ambika! Welcome to GCC! On 2025-03-29T15:26:18-0500, Ambika Sharan via Gcc wrote: > Simple File System for Nvidia and AMD GPU Code Generation Testing Thanks for your interest, and initial work on this project idea. Please add more detail: ideas how you think you'd implement the respective

Re: [GSoC][Enhance OpenACC support] Uncertain about Cache directive functionality and device_type clause goal

Hi Chenlu! On 2025-03-27T22:05:02+1100, Zhang lv via Gcc wrote: > Hi here, Welcome to GCC! > I found digging into OpenACC meaningful. It's a late start for a GSoC > proposal ..., but not yet too late! :-) > and any suggestions from the community are appreciated! Feel free > to comment on an

Re: GSOC interest in Extend the static analysis pass, [OpenACC]

Hi Kaaden! On 2025-03-10T22:20:21+, Kaaden Ruman via Gcc wrote: > Hello, my name is Kaaden and I am a student at the University of Alberta in > Canada. Welcome to GCC! > I am interested in pursuing the "Extend the static analysis pass" idea as a > medium size project. I'm sorry that I d

Re: GSoC mandatory step error

Hi Leul! On 2025-03-31T18:33:51-0400, Leul Abiy via Gcc wrote: > I just wanted to ask about the build of gcc. I know it is a required step > before applying to GCC for the GSoC 2025. However, I get an error. Welcome to GCC, and good luck for GSoC 2025! In addition to what Martin already wrote:

Re: GSoC 2025 – Excited About GCC Go Escape Analysis & Seeking Guidance

Hi Astha, Ian! On 2025-03-31T19:48:16+0530, Astha Pipania via Gcc wrote: > I hope you're doing well! Astha, welcome to GCC! > I'm incredibly excited about the "GCC Go Escape > Analysis" project for GSoC 2025. ... which is listed on

Re: Rust: error[E0554]: `#![feature]` may not be used on the stable release channel

Hi! On 2025-03-17T20:03:48+, Iain Sandoe via Gcc wrote: >> On 17 Mar 2025, at 19:43, Toon Moene wrote: >> >> I was eager to try the new rust updates ... >> >> But I got this: >> >> error[E0554]: `#![feature]` may not be used on the stable release channel >> --> src/lib.rs:19:1 >> | >>

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

Hi! On 2025-02-10T20:59:43+0100, Thomas Koenig wrote: > Am 10.02.25 um 08:43 schrieb Richard Biener: >> We have need-bisection and other need-, so iff then maybe a need-stdchk for >> cases compliance is unclear? > > That sounds very good to me; if there are no objections, I will create > this in

GCC Steering Committee attention, Re: [WIP 0/8] Algol 68 GCC Front-End

Hi GCC Steering Committee! Please consider accepting into GCC this new -- old? ;-) -- Algol 68 front end (awaiting conclusion of the ongoing technical review), and appointing José as its maintainer. (At FOSDEM last weekend, we were briefly discussing this contribution, and I offered to raise and

FOSDEM 2025 GCC (GNU Toolchain) devroom (was: GCC (GNU Toolchain) dev room - CFP)

ot;. > The third page will include fields for: > > - Profile picture, name > - Biography (optional) > - Availability > > Once you've completed the required sections, submit and we'll get back > to you soon! > > You may adjust the details after submittin

nvptx: PTX 'alloca' for '-mptx=7.3'+, '-march=sm_52'+ [PR65181] (was: Raise nvptx code generation to default PTX ISA 7.3, sm_52, therefore CUDA 11.3 (released 2021-04))

2'+ [PR65181]", see attached. Grüße Thomas >From 3861d362ec7e3c50742fc43833fe9d8674f4070e Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 7 Dec 2024 00:17:49 +0100 Subject: [PATCH] nvptx: PTX 'alloca' for '-mptx=7.3'+, '-march=sm_52'+ [PR6518

nvptx: For '-march=sm_52' and higher, default at least to '-mptx=7.3' (was: Raise nvptx code generation to default PTX ISA 7.3, sm_52, therefore CUDA 11.3 (released 2021-04))

ble" ("bookworm", 2023-06) has 11.8.89~11.8.0-5~deb12u1 > packaged Pushed to trunk branch commit b7f168644966d451fbe46ee9d06c9763a539c41b "nvptx: For '-march=sm_52' and higher, default at least to '-mptx=7.3'", see attached, so that we'll be able to use PTX '

nvptx: Switch default from '-march=sm_30' to '-march=sm_52' (was: Raise nvptx code generation to default PTX ISA 7.3, sm_52, therefore CUDA 11.3 (released 2021-04))

Hi! On 2024-09-20T18:49:46+0200, Thomas Schwinge wrote: > We'd like to raise nvptx code generation from PTX ISA 6.0, sm_30 "Kepler" > to default PTX ISA 7.3, sm_52 "Maxwell", therefore CUDA 11.3 (2021-04). > This is, primarily, so that we're able to use &#

nvptx: Support '--with-multilib-list' (was: Raise nvptx code generation to default PTX ISA 7.3, sm_52, therefore CUDA 11.3 (released 2021-04))

branch commit 86b3a7532d56f74fcd1c362f2da7f95e8cc4e4a6 "nvptx: Support '--with-multilib-list'", see attached. Grüße Thomas >From 86b3a7532d56f74fcd1c362f2da7f95e8cc4e4a6 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 27 Sep 2024 17:44:16 +0200 Subject: [PATCH] nvptx: Support '--wit

Re: GCC devroom at FOSDEM 2025?

Hi James! On 2024-12-01T17:34:13-0500, "James K. Lowden" wrote: > On Tue, 01 Oct 2024 11:48:34 +0200 > Thomas Schwinge wrote: > >> I need two, three people as co-organizers: >> for evaluating submissions (before 2024-12-15), > > I went to https://pretalx.

GCC (GNU Toolchain) devroom at FOSDEM 2025! (was: GCC devroom at FOSDEM 2025?)

Hi! The good news first: a GCC (GNU Toolchain) devroom has been accepted fos FOSDEM 2025! :-) Details and Call for Participation to be shared soon. On 2024-10-10T15:03:26-0400, "James K. Lowden" wrote: > On Tue, 01 Oct 2024 11:48:34 +0200 > Thomas Schwinge wrote: > &

GCC devroom at FOSDEM 2025?

Hi! FOSDEM have recently posted the "FOSDEM 2025 call for devrooms", . Given the great success of last year's GCC devroom: , I'd like to apply again, for a GCC devroom (and related toolchain parts)

Re: Raise nvptx code generation to default PTX ISA 7.3, sm_52, therefore CUDA 11.3 (released 2021-04)

Hi! On 2024-09-23T09:22:55+0200, Richard Biener wrote: > On Fri, Sep 20, 2024 at 6:50 PM Thomas Schwinge > wrote: >> (This is orthogonal to yesterday's >> "GCC 15: nvptx '-mptx=3.1' multilib variants are deprecated".) >> >> We'd

GCC nvptx-none Target Testing (was: New page "nvptx" in the GCC wiki to document --target=nvptx-none configurations)

Hi! On 2017-02-16T21:10:20+0100, I wrote: > I created a new page "nvptx" in the GCC wiki to document > --target=nvptx-none configurations: . (I've revised that one -- it's been a few years... -- and in particular then) I've added more details re "GCC nvptx-none Tar

Raise nvptx code generation to default PTX ISA 7.3, sm_52, therefore CUDA 11.3 (released 2021-04)

Hi! (This is orthogonal to yesterday's "GCC 15: nvptx '-mptx=3.1' multilib variants are deprecated".) We'd like to raise nvptx code generation from PTX ISA 6.0, sm_30 "Kepler" to default PTX ISA 7.3, sm_52 "Maxwell", therefore CUDA 11.3 (2021-04). This is, primarily, so that we're able to use 'al

GCC 15: nvptx '-mptx=3.1' multilib variants are deprecated

e users for another 1.5 years.) These '-mptx=3.1' multilib variants are only useful for users of ancient CUDA/Nvidia Driver, which doesn't support GCC's default PTX ISA 6.0 multilib variants; PTX ISA 6.0 is supported as of CUDA 9, 2017-09. Grüße Thomas >From 8c099b2c4f

Re: git help: fortran_unsigned branch

Hi! I'm not sure I understand what actually the issue is, but: On 2024-08-09T20:00:42+0200, Thomas Koenig wrote: > I have managed to bring the fortran-unsigned branch into a state where First, I see that the upstream devel/fortran_unsigned branch does contain (a) your development work, and (b)

Re: How to add an additional option to dg-compile and dg-run

Hi Thomas! On 2024-07-29T10:18:49+0200, Thomas Koenig via Gcc wrote: > for the fortran-unsigned branch By the way: I did see your recent announcement; wow -- Fortran finally getting an UNSIGNED type! :-) > I would like to be able to run all > existing Fortran tests also with -funsigned, to mak

Re: GSoC

Hi Abhinav! Thanks for your interest in contributing to GCC, and thanks to Martin for all the information you already provided. Just a bit more, to get you started on developing a proper project proposal: On 2024-03-13T14:54:52+0100, Martin Jambor wrote: > On Tue, Mar 12 2024, Abhinav Gupta wro

Re: Help needed with maintainer-mode

Hi! On 2024-03-04T00:30:05+, Sam James wrote: > Mark Wielaard writes: >> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote: >>> [...], I read >>> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration >>> which basically says "run autoreconf in every dir where there is a >>> c

Re: GSoC: Application for Rust Front-End Project at GCC

Hi Arpit! First, welcome to GCC, and I appreciate your enthousiasm! On 2023-12-30T22:30:37+0530, CS21B062 ARPIT GUPTA wrote: > Dear GCC Community, > > I hope this email finds you well. My name is Arpit and I am writing to > express my interest in participating in GSoC, specifically for the > Rus

Re: Question about creating global varaiable during IPA PASS.

Hi Hanke! On 2023-12-13T17:04:57+0800, Hanke Zhang via Gcc wrote: > Hi, I'm trying to create a global variable in my own PASS which > located at the LATE_IPA_PASSES. (I'm using GCC 10.3.0.) I can't comment on IPA aspects, or whether something was different on oldish GCC 10 (why using that one, b

Re: Build breakage

Hi! On 2023-12-13T20:27:44+, Jonathan Wakely wrote: > On Wed, 13 Dec 2023, 19:37 Thomas Schwinge, wrote: >> On 2023-12-13T11:15:54-0800, Jerry D via Gcc wrote: >> > I am getting this failure to build from clean trunk. >> >>

Fix 'libgomp/config/linux/allocator.c' 'size_t' vs. '%ld' format string mismatch (was: Build breakage)

GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From 5445ff4a51fcee4d281f79b5f54b349290d0327d Mon Sep 17 00:00:00 20

Re: Build breakage

Hi! On 2023-12-13T11:15:54-0800, Jerry D via Gcc wrote: > I am getting this failure to build from clean trunk. This is due to commit r14-6499-g348874f0baac0f22c98ab11abbfa65fd172f6bdd "libgomp: basic pinned memory on Linux", which supposedly was only tested with '--disable-multilib' or so. As A

GCC developer room at FOSDEM 2024: Call for Participation open

orldclock/belgium/brussels> > * If you're not able to attend the talk in-person, live stream links >will be available on the FOSDEM schedule page: > <https://fosdem.org/2024/schedule/>. > * FOSDEM Matrix channels are specific to each devroom, >the general link i

Re: Enable top-level recursive 'autoreconf'

Hi! On 2023-10-19T11:57:33+0200, Andreas Schwab wrote: > On Okt 19 2023, Thomas Schwinge wrote: >> On 2023-10-18T15:42:18+0100, R jd <3246251196r...@gmail.com> wrote: >>> I guess I can ask, why there is not a recursive approach for configuring >>> GCC.

Enable top-level recursive 'autoreconf' (was: Hints on reconfiguring GCC)

chränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From 43127e5643337ca407071ad93bccbc716024352e Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 19 Oct 2023 10:28:30 +0200 Subject: [PATCH] Enable top-

Re: Hints on reconfiguring GCC

Hi Ryan! In addition to what Iain said: On 2023-10-15T14:00:47+0100, Iain Sandoe wrote: >> On 15 Oct 2023, at 13:40, R jd <3246251196r...@gmail.com> wrote: >> I am part of a team that ensures that GCC is ported for AmigaOS4 and the >> next generation hardware. > > :-) :-) >> My question is in

Re: Anyone interesting to submit a GCC devroom request proposal at FOSDEM? (was Re: After Cauldron - online mini BoFs and Fosdem)

Hi! Sorry for the late reply; I'm still working through email accumulated during (mostly offline) vacations after the GNU Tools Cauldron... ;-) On 2023-10-16T14:31:53-0400, David Malcolm wrote: > On Tue, 2023-10-03 at 14:37 +0200, Dodji Seketeli wrote: >> Mark Wielaard a écrit: >> > Also Dodji

Re: Incremental LTO Project

Hi! Four things: On 2023-09-10T23:25:06+0200, Jan Hubicka via Gcc wrote: >> On 2023-09-07T19:00:49-0400, James Hu via Gcc wrote: >> > I noticed that adding incremental LTO was a GSoC project that was not >> > claimed this cycle ( >> > https://summerofcode.withgoogle.com/programs/2023/organizati

Re: Attempt to fix g++.dg tests failures in gnu-versioned-namespace mode

Hi! On 2023-09-20T07:08:25+0200, François Dumont via Gcc wrote: > I've configured libstdc++ with --enable-symvers=gnu-versioned-namespace I can't comment on that option... > and run make check-c++. > > A number of failures are like this one: > > /home/fdumont/dev/gcc/git/gcc/testsuite/g++.dg/co

Re: Incremental LTO Project

Hi! On 2023-09-07T19:00:49-0400, James Hu via Gcc wrote: > I noticed that adding incremental LTO was a GSoC project that was not > claimed this cycle ( > https://summerofcode.withgoogle.com/programs/2023/organizations/gnu-compiler-collection-gcc). > I was curious about working on this project, bu

GNU Tools Cauldron 2023

1, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From 24127b05c065c0fd24c996f5b27829bfa37de485 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 5 Sep 2023 1

Support in the GCC(/C++) test suites for '-fno-exceptions'

Hi! This issue comes up in context of me working on C++ support for GCN and nvptx target. Those targets shall default to '-fno-exceptions' -- or, "in other words", '-fexceptions' is not supported. (Details omitted here.) It did seem clear to me that with such a configuration it'll be hard to ge

Re: For GCC, newlib combined tree, newlib build-tree testing, use standard search paths

Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From e56b38625929c3cf62c71d3fbd

Re: For GCC, newlib combined tree, newlib build-tree testing, use standard search paths

. > > > Grüße > Thomas - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From e56

For GCC, newlib combined tree, newlib build-tree testing, use standard search paths

Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From e56b38625929c3cf62c71d3fbd9264aaeef39d0c Mon

RE: GSoC Separate Host Process Offloading

Hi Adi! I've not been able yet to review your items in detail, but it's very good that you're discussing your ideas! At least a few comments: On 2023-04-01T03:16:28+, "Prasad, Adi via Gcc" wrote: > Tobias wrote: >> [...] permit something like -foffload=host instead of having to >> specify -

Re: GSoC Separate Host Process Offloading

Hi Adi! On 2023-03-28T20:39:04+, "Prasad, Adi via Gcc" wrote: > I’m Adi Prasad, a 2nd year Computing student at Imperial College London, > interested in doing the Separate Host Process Offloading GSoC project this > summer. Greak, and welcome to GCC! :-) > First off, I’m aware I’m gettin

Re: [GSoC] gccrs Unicode support

Hi! (By the way, this GSoC project is being discussed in GCC/Rust Zulip: .) I'm now also putting Mark Wielaard in CC; he once also started discussing this topic, "thinking of importing a couple of gnulib modules to

Re: GSoC'2023: Separate Host Process Offloading: GCC

Hi! Sorry, let me try again -- our IT department likes to garble emails in order to attach a "disclaimer"... On 2023-03-13T21:37:24+0100, I wrote: > Hi Madhu! > > (As you've sent your equally worded > "GSoC'2023: Bypass assembler when generating LTO object files: GCC" email > to , let me also Cc

Re: GSoC'2023: Separate Host Process Offloading: GCC

- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 --- Begin Message --- Hi Madhu! (As

Git 'hooks/post_receive.py': UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 2766: invalid start byte

Hi! The following is not an actual problem for me or GCC/Rust; just for your information: I've just pushed to GCC devel/rust/master branch Git commits cc23831ec66..74913f718b0, which 'hooks/post_receive.py' threw up upon: $ git push upstream github/Rust-GCC/gccrs/master:devel/rust/master

Re: Buildbot (Sourceware): gcc - failed configure (failure) (master)

Hi! On 2023-01-30T14:50:08-0800, Steve Kargl via Fortran wrote: > Does the skull and crossbones convey anymore info than the rest of > the subject line > > Buildbot (Sourceware): gcc - failed configure (failure) (master) They convey as much additional information as does (automated) colorfu

Re: GDC environment variable

Hi! On 2022-12-07T12:05:18+0530, Ankur Saini via Gcc wrote: >> On 07-Dec-2022, at 11:42 AM, Dave Blanchard wrote: >> >> Is there an environment variable like 'CC' or 'CXX', which specifies the >> name of the D compiler to use, which I might need to set when bootstrapping >> GCC? Thanks. > > I

Handling of large stack objects in GPU code generation -- maybe transform into heap allocation?

Hi! For example, for Fortran code like: write (*,*) "Hello world" ..., 'gfortran' creates: struct __st_parameter_dt dt_parm.0; try { dt_parm.0.common.filename = &"source-gcc/libgomp/testsuite/libgomp.oacc-fortran/print-1_.f90"[1]{lb: 1 sz: 1}; dt_parm.0.comm

GCC 13: OpenMP offloading to Intel MIC has been removed (was: Remove support for Intel MIC offloading)

Grüße Thomas - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From c59054dae1319cd2

Re: DejaGnu: flags via 'RUNTESTFLAGS' overriding those specified in test cases

: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From 3ce58c891359cd439518786448fd21a94c5a70a4 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date

DejaGnu: flags via 'RUNTESTFLAGS' overriding those specified in test cases

Hi! On 2022-02-04T13:09:29+0100, Tom de Vries via Gcc wrote: > On 2/4/22 08:21, Thomas Schwinge wrote: >> On 2022-02-03T13:35:55+, "vries at gcc dot gnu.org via Gcc-bugs" >> wrote: >>> while iterating over dimensions { -mptx=3.1 , -mptx=6.3 } x { >&g

Forward GCC '-v' command-line option to binutils assembler, linker (was: [PING] nvptx: forward '-v' command-line option to assembler, linker)

CC "nvptx: forward '-v' command-line option to assembler, linker" (see snippets quoted below), and during review we found: On 2022-09-05T17:02:26+0200, Tom de Vries via Gcc-patches wrote: > On 6/7/22 17:41, Thomas Schwinge wrote: >> --- a/gcc/config/nvptx/nvptx.h >&

Re: GNU Tools Cauldron 2022

dron 2022", see attached. See you in less than two weeks! Grüße Thomas >From b465e8f1f72a0718aebcf483a78b68c3e68ead72 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 2 Sep 2022 21:39:18 +0200 Subject: [PATCH] GNU Tools Cauldron 2022 --- htdocs/index.html | 4 1 file

Re: Setting up editors for the GNU/GCC coding style?

Hi! On 2022-07-29T09:36:41+0200, Marc Poulhies via Gcc wrote: > Iannetta Paul writes: >> About configuring recent editors to follow the GNU coding style, I don't >> really >> know but it should always be possible to register a hook that will run >> `indent` >> when the file is saved. > > There

Re: GCC Rust git branch

;. Grüße Thomas - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From 15e0

Document mailing list (was: GCC Rust git branch)

- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 >From 1c89cdccbebda5d4c2eeeb627b1461b8

Re: nvptx multilib setup

Hi Tom! On 2022-02-04T13:09:29+0100, Tom de Vries via Gcc wrote: > On 2/4/22 08:21, Thomas Schwinge wrote: >> On 2022-02-03T13:35:55+, "vries at gcc dot gnu.org via Gcc-bugs" >> wrote: >>> I've tested this using (recommended) driver 470.94 on board

Re: GSoC Fortran - Do Concurrent

Hi Bryan! Thanks for reaching out, and welcome to GCC! On 2022-05-03T13:34:13-0500, Bryan Carroll via Gcc wrote: > I know I'm too late for GSoC, but if Tobias Burnus or someone wants to > mentor me, I'm willing to work on the Fortran - Do Concurrent project, as a > volunteer, if it's not already

Re: OpenMP auto-simd

Hi! ... with the usual caveat that I know much more about OpenACC than OpenMP, and I know (at least a bit) more about nvptx than GCN... ;-) On 2022-03-02T15:12:30+, "Stubbs, Andrew" wrote: > Has anyone ever considered having GCC add the "simd" clause to offload (or > regular) loop nests au

Re: GCC GSoC 2022: Call for project ideas and mentors

Hi David! On 2022-01-07T12:41:17-0500, David Malcolm via Fortran wrote: > I'd like to (again) mentor a project relating to the GCC static > analyzer: > https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer > > I've updated the analyzer task ideas on: > https://gcc.gnu.org/wiki/SummerOfCode >

nvptx multilib setup (was: [Bug target/104364] [12 Regression] OpenMP/nvptx regressions after "[nvptx] Add some support for .local atomics")

Hi Tom! Taking this one to the mailing list; not directly related to PR104364: On 2022-02-03T13:35:55+, "vries at gcc dot gnu.org via Gcc-bugs" wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104364 > I've tested this using (recommended) driver 470.94 on boards: (As not every user w

Re: distinguishing gcc compilation valgrind false positives

Hi! On 2021-11-24T20:05:56+0100, Zdenek Sojka via Gcc wrote: > from time to time, I come upon a testcase that failed during the automated > runs, but passes during reduction; there are valgrind warnings present, > however. Thanks for looking into this. Please collect any Valgrind notes at

https://patchwork.sourceware.org/project/gcc/

Hi! As I learned from Twitter the other day, , we now have patchwork set up on sourceware, tracking : . As I'm generally supportive of such "automatism" (if feasible), I wonder: are we going to

RE: GCC/OpenMP offloading for Intel GPUs?

ike for Intel MIC offloading back then), or interested in hiring someone to do it, or not (actively) interested in helping GCC support Intel GPUs? Grüße Thomas >>-Original Message- >>From: Thomas Schwinge >>Sent: Wednesday, September 15, 2021 7:20 PM >>To: Liu, Hongtao >&

Re: [PING^2] Re: Fix 'hash_table::expand' to destruct stale Value objects

Hi! On 2021-09-17T15:03:18+0200, Richard Biener wrote: > On Fri, Sep 17, 2021 at 2:39 PM Jonathan Wakely wrote: >> On Fri, 17 Sept 2021 at 13:08, Richard Biener >> wrote: >> > On Fri, Sep 17, 2021 at 1:17 PM Thomas Schwinge >> > wrote: >> > > On 2

[PING^2] Re: Fix 'hash_table::expand' to destruct stale Value objects

Hi! On 2021-09-10T10:00:25+0200, I wrote: > On 2021-09-01T19:31:19-0600, Martin Sebor via Gcc-patches > wrote: >> On 8/30/21 4:46 AM, Thomas Schwinge wrote: >>> Ping -- we still need to plug the memory leak; see patch attached, and/or >>> long discussion here:

RE: GCC/OpenMP offloading for Intel GPUs?

ing libomptarget etc. use, as brought up by Jakub), the question then is: are Intel planning to do that work (themselves, like for Intel MIC offloading back then), or interested in hiring someone to do it, or not? Grüße Thomas >>-Original Message- >>From: Thomas Schwinge >&g

GCC/OpenMP offloading for Intel GPUs?

Hi! I've had a person ask about GCC/OpenMP offloading for Intel GPUs (the new ones, not MIC, obviously), to complement the existing support for Nvidia and AMD GPUs. Is there any statement other than "ought to be doable; someone needs to contribute the work"? Grüße Thomas - Siem

[PING] Re: Fix 'hash_table::expand' to destruct stale Value objects

Hi! On 2021-09-01T19:31:19-0600, Martin Sebor via Gcc-patches wrote: > On 8/30/21 4:46 AM, Thomas Schwinge wrote: >> Ping -- we still need to plug the memory leak; see patch attached, and/or >> long discussion here: > > Thanks for answering my questions. I have no concerns

Fix 'hash_table::expand' to destruct stale Value objects (was: 'hash_map>')

Hi! Ping -- we still need to plug the memory leak; see patch attached, and/or long discussion here: On 2021-08-16T14:10:00-0600, Martin Sebor wrote: > On 8/16/21 6:44 AM, Thomas Schwinge wrote: >> On 2021-08-12T17:15:44-0600, Martin Sebor via Gcc wrote: >>> On 8/6/21 10:57 A

Make 'gcc/hash-map-tests.c:test_map_of_type_with_ctor_and_dtor_expand' work on 32-bit architectures [PR101959]

hitectures [PR101959]", which does resolve the issue for a '-m32' i686-pc-linux-gnu build? Grüße Thomas > On Tue, Aug 17, 2021 at 5:00 AM Richard Biener via Gcc > wrote: >> >> On Tue, Aug 17, 2021 at 8:40 AM Thomas Schwinge >> wrote: >> > >&g

Add more self-tests for 'hash_map' with Value type with non-trivial constructor/destructor (was: Expensive selftests)

Hi! On 2021-08-17T10:57:36+0200, Richard Biener wrote: > On Tue, Aug 17, 2021 at 8:40 AM Thomas Schwinge > wrote: >> On 2021-08-16T14:10:00-0600, Martin Sebor wrote: >> > On 8/16/21 6:44 AM, Thomas Schwinge wrote: >> >> [...], to document the current behav

Expensive selftests (was: 'hash_map>')

Hi! On 2021-08-16T14:10:00-0600, Martin Sebor wrote: > On 8/16/21 6:44 AM, Thomas Schwinge wrote: >> [...], to document the current behavior, I propose to >> "Add more self-tests for 'hash_map' with Value type with non-trivial >> constructor/destructor&q

Re: 'hash_map>'

Hi! On 2021-08-12T17:15:44-0600, Martin Sebor via Gcc wrote: > On 8/6/21 10:57 AM, Thomas Schwinge wrote: >> So I'm trying to do some C++... ;-) >> >> Given: >> >> /* A map from SSA names or var decls to record fields. */ >> typedef

Re: 'hash_map>'

Hi! On 2021-08-09T12:02:02+0200, Richard Biener via Gcc wrote: > On Fri, Aug 6, 2021 at 6:58 PM Thomas Schwinge > wrote: >> So I'm trying to do some C++... ;-) >> >> Given: >> >> /* A map from SSA names or var decls to record fields

Re: 'hash_map>'

Hi! On 2021-08-07T09:54:53+0100, Jonathan Wakely via Gcc wrote: > On Sat, 7 Aug 2021, 09:08 Thomas Schwinge, wrote: >> On 2021-08-06T19:37:58+0100, Jonathan Wakely wrote: >> > On Fri, 6 Aug 2021, 17:58 Thomas Schwinge, wrote: >> >> So I'm trying to do

Re: 'hash_map>'

Hi! On 2021-08-06T19:37:58+0100, Jonathan Wakely wrote: > On Fri, 6 Aug 2021, 17:58 Thomas Schwinge, wrote: >> So I'm trying to do some C++... ;-) >> >> Given: >> >> /* A map from SSA names or var decls to record fields. */ >> typedef

'hash_map>'

Hi! So I'm trying to do some C++... ;-) Given: /* A map from SSA names or var decls to record fields. */ typedef hash_map field_map_t; /* For each propagation record type, this is a map from SSA names or var decls to propagate, to the field in the record type that should b

Pushing XFAILed test cases (was: [PATCH, Fortran] Bind(c): CFI_signed_char is not a Fortran character type)

[Also including for guidance.] Hi! (I'm not involved in or familiar with Sandra's Fortran TS29113 work, just commenting generally here.) On 2021-07-16T09:52:28+0200, Thomas Koenig via Gcc-patches wrote: > It is my understanding that it is not gcc policy to add xfailed test > cases for thing

Re: Nvidia GPU Volta+ (sm_70+) Independent Thread Scheduling

Hi! On 2021-07-13T17:59:43+0200, Jakub Jelinek wrote: > On Tue, Jul 13, 2021 at 05:48:51PM +0200, Thomas Schwinge wrote: >> Starting with the Volta family (sm_70+), Nvidia GPUs introduced >> Independent Thread Scheduling for the 32 threads ("32 SIMD lanes") that >>

Nvidia GPU Volta+ (sm_70+) Independent Thread Scheduling

Hi! Starting with the Volta family (sm_70+), Nvidia GPUs introduced Independent Thread Scheduling for the 32 threads ("32 SIMD lanes") that constitute a warp, which means "execution state per thread, including a program counter", succeeding the previous "warp-synchronous" abstraction where "warps

Atomic operations on floating-point data types

Hi! Per we've found that GCC's nvptx back end doesn't make use of the PTX 32-bit floating-point add instruction, , as declared in 'gcc/config/nvptx/nv

Webinar "A Compiler's View of the OpenMP API" (Johannes Doerfert)

Hi! A webinar has been announced: "A Compiler's View of the OpenMP API" (Johannes Doerfert), ,

OpenMP 'simd', unexpected nesting of variable declaration in bind vs. 'private' clause

Hi! I'm currently working on an OpenACC thing, which in 'omp-low' separately for each OpenACC 'loop' construct, collects variable declarations referenced in 'private' clauses as well as those from inner binds (simplified). Accidently that was also enabled for OpenMP, and for a few testcases of Op

Re: Speed of compiling gimple-match.c

Hi! On 2021-05-03T13:18:35-0700, Andrew Pinski via Gcc wrote: > I noticed my (highly, -j24) parallel build of GCC is serialized on > compiling gimple-match.c. Has anyone looked into splitting this > generated file into multiple files? There is "[meta] GCC build s

Re: 'walk_stmt_load_store_addr_ops' for non-'gimple_assign_single_p (stmt)'

Hi! On 2021-03-17T08:46:16+0100, Richard Biener wrote: > On Wed, Mar 17, 2021 at 12:25 AM Thomas Schwinge > wrote: >> This is a prototype/"initial hack" for a very simple implementation of >> <https://gcc.gnu.org/PR90591> "Avoid unnecessary data transfe

Re: 'walk_stmt_load_store_addr_ops' for non-'gimple_assign_single_p (stmt)'

Hi! Thanks, Michael, and again Richard for your quick responses. On 2021-03-16T15:25:10+, Michael Matz wrote: > On Tue, 16 Mar 2021, Thomas Schwinge wrote: > >> >>Indeed, given (Fortran) 'zzz = 1', we produce GIMPLE: >> >> >> &g

Re: 'walk_stmt_load_store_addr_ops' for non-'gimple_assign_single_p (stmt)'

Hi! Richard, thanks for your answer. I'll need to look into this more; two questions already: On 2021-03-15T20:17:17+0100, Richard Biener via Gcc wrote: > On March 15, 2021 7:31:46 PM GMT+01:00, Thomas Schwinge > wrote: >>First time I'm using this API -- so the error

'walk_stmt_load_store_addr_ops' for non-'gimple_assign_single_p (stmt)'

Hi! First time I'm using this API -- so the error certainly may be on my side. ;-) What I'm doing, is a 'walk_gimple_seq', and in that one's 'callback_stmt', call 'walk_stmt_load_store_addr_ops', to collect variable load/store/address-taken instances. This did seem quite straight-forward, given

Question about 'gcc/fold-const.c:fold_convert_loc' for 'real_cst' -> 'reference_type' of 'real_type'

Hi! In a development branch based on devel/omp/gcc-10 branch (og10), which is based on releases/gcc-10 branch, I'm running into the following issue. But: the master branch code seems to look the same. Given a specific scenario, we run into an ICE: during GIMPLE pass: oaccdevlow dump file

Re: DejaGnu diagnostics checking confused, possibly related to 'dg-line'?

Hi! Ping. Anybody got an opinion on the approach we should take? Grüße Thomas On 2020-11-03T15:21:40+0100, I wrote: > Hi! > > I've investigated some more. > > On 2020-11-03T13:31:53+0100, I wrote: >> Help. Save the attached file as 'gcc/testsuite/c-c++-common/goacc/l_.c', >> and then run: >

Minimum CUDA version supported by GCC?

Hi! As far as I can tell, we (GCC) don't currently state the minimum CUDA version supported: for nvptx target, and especially then for OpenACC/OpenMP nvptx offloading. , ,

  1   2   3   >