On 07.12.22 20:09, Julian Brown wrote:
On Wed, 26 Oct 2022 12:39:39 +0200
Tobias Burnus wrote:
The ICE seems to be because gcc/fortran/trans-openmp.cc's
gfc_split_omp_clauses mishandles this as the dump shows the following:
#pragma omp target firstprivate(a) map(tofrom:a)
#pragma
For the testcase in this PR what fold-const.cc optimize_bit_field_compare
does to bitfield against constant compares is confusing the uninit
predicate analysis and it also makes SRA obfuscate instead of optimize
the code. We've long had the opinion that those optimizations are
premature but we do
Hi Julian:
On 07.12.22 20:13, Julian Brown wrote:
I know that this was the case before, but can you move the mark:1 etc.
after 'tlink'? In that case all bitfields are grouped together.
Thanks for doing so.
I wonder whether that also rejects the following – which seems to be
valid. The 'map' go
On Wed, Dec 07, 2022 at 05:54:40PM -0800, Jerry D via Fortran wrote:
> Other than Benson, I have received no sign of any interest from gfortran
> developers to adopt a teaming/collaboration platform. I am a bit
> disappointed. Maybe my intent was misunderstood. I am not suggesting
> replacing the
Hi,
On 08.12.22 17:27, Steve Kargl via Fortran wrote:
On Wed, Dec 07, 2022 at 05:54:40PM -0800, Jerry D via Fortran wrote:
Other than Benson, I have received no sign of any interest from gfortran
developers to adopt a teaming/collaboration platform. I am a bit
disappointed. Maybe my intent was
I was thinking I might try to contribute when I retire, though that may be in a
year or two. But it's been a very long time since I dove into a large software
project and it's intimidating. I do know C (really C++, I haven't used plain C
for a long time). I am one of those "aging" types but
Hi Jerry, all,
as already said, the basic issue appears to be the low number
of contributors, most (all?) of which are working on gfortran
in their spare time (like me). I think it is not likely that
they will commit to being available regularly.
I have used IRC once for a discussion that was r
Dear all,
a fairly obvious, or rather trivial fix that appeared while
analyzing another pr and that can be treated independently:
reject duplicate CONTIGUOUS attributes.
(Intel and NAG reject this, Cray warns that this is non-standard.)
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks
On Thu, Dec 08, 2022 at 10:59:42PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> a fairly obvious, or rather trivial fix that appeared while
> analyzing another pr and that can be treated independently:
> reject duplicate CONTIGUOUS attributes.
>
> (Intel and NAG reject this, Cray warns
