Hi,
I tried to merge trunk to into the coarray_native branch in preparation
of some further work. After some problems, it seems that the commit
worked. However, pushing it resulted in an error message, and it seems
there was no e-mail to the gcc-cvs mailing list.
The commit is
commit b18a97e5
Am 06.12.20 um 18:37 schrieb dhumieres.domini...@free.fr:
Hi Thomas,
I'm currently trying to put together a testsuite for the shared coarray
branch. What I have so far is a directory
gcc/testsuite/gfortran.dg/caf-shared
which contains the attached dejagnu file plus the test cases
I don't see
have received a copy of the GNU General Public License
# along with GCC; see the file COPYING3. If not see
# <http://www.gnu.org/licenses/>.
#
# Contributed by Thomas König
# Test shared coarray support.
load_lib gfortran-dg.exp
set blddir [lookfor_file [get_multilibs] libcaf_shared]
Am 10.08.20 um 18:53 schrieb Michael Meissner:
IMHO, changing the default is only appropriate for times like a distribution
major number changes, where backwards and forwards compatibility is carefully
controlled. But before we can contemplate doing this, we need the ability to
change the defaul
Just another thought.
In Fortran, we have the possibility to define KIND numbers for
numeric types however we want.
So, it would be no problem to have two long double types
with distinct kind numbers, let's say KIND=16 for
one type and KIND=17 for the other. We can then let
selected_real_kind re
Hi Michael,
I have shortened the distribution list somewhat for the Fortran-relevant
parts.
I want to discuss changes that I think we need to make across the open source
toochain to allow us to change the long double type on PowerPC hardware from
using the IBM extended double (i.e. a pair of do
> Am 04.07.2020 um 19:11 schrieb Richard Biener :
>
> On July 4, 2020 11:30:05 AM GMT+02:00, "Thomas König"
> wrote:
>>
>> What could be a preferred way to achieve that? Could optimization
>> options like -ffast-math be applied to blocks instead of
Hi,
in Fortran, it would sometimes be useful to have a different optimization
depending on whether we generate inlined code for intrinsics (where we
know when it is OK to „go wild“) or user code, where we need to
adhere (for example) to IEEE semantics unless otherwise instructed
by the user.
Wh
Hi,
Some comments.
Generally, I found the old format to be very good for navigating, and I
would like to have the new one match the old one as closely as possible.
1) the by date monthly list of mails used to be ordered newest to oldest
mails first, now it is oldest to newest, so when dealing
Hi,
one more point: The gcc mailing list including this discussion is currently not
being archived, the last message is from 2020-03-06.
Hi,
I concur with what Jakub wrote. The new web interface is much less useful than
the old one; a severe regression for developers, so to speak.
I also seem to have missed all discussion on this change (if there was
anything). I do not understand why such a huge change was implemented that way,
> CC overseers.
>
> they are not stripped – I do see them both in my inbox and at
> https://gcc.gnu.org/pipermail/fortran/2020-March/054050.html
They were stripped for me :-( I even mailed Paul about the (for me) missing
attachment.
Not sure what is going on there, but whatever change was made
Hi,
looks like the new mailing list setup is stripping off patches. Example:
https://gcc.gnu.org/pipermail/fortran/2020-
March/054050.html
The attachments are also not distributed via mail.
This breaks the gfortran review process. Could somebody please fix this?
Regards
Hi Eric,
> There is an entire machinery in the middle-end and the back-ends to support
> this (look for trampolines/descriptors in the manual and the source code).
> This should essentially work out of the box for any language front-end.
Thanks for the pointer. The documentation I have seen seems
Am 27.01.19 um 21:52 schrieb Steve Kargl:
In fact, I would be in favor of removing -Wall, as it is misnamed,
in favor of -Wlevel=0,1,2,3... -Wlevel=0 default warnings.
-Wlevel=1 is equivalent to -Wall. -Wlevel=2 is -Wall -Wextra
(and maybe -Wsurprising).
... and -Wlevel=3 could then be -Wkit
> Am 23.01.2019 um 12:36 schrieb Jonathan Wakely :
>
> When there are new warnings that aren't enabled by -Wall -Wextra,
> there's probably a reason they aren't enabled by default.
-Wconversion-extra is an example of such a warning.
It catches a very common error people make in Fortran, see
> Am 23.01.2019 um 01:53 schrieb Martin Sebor :
> I often wish GCC supported it -- not in the hopes of finding every
> conceivable bug or transgression against known coding styles but
> as a tool to discover warnings that have to be explicitly enabled
> either by using their own options or by s
Hello world,
with Fortran 2018, recursive is becoming the default. This will likely
have a serious impact on many user codes, which often declare large
arrays which could then overflow stacks, leading to segfaults without
further explanation.
What could we do? A few options, not all mutally excl
Hi,
it seems that gcc bugzilla is currently down, error message is:
Software error:
Can't connect to the database.
Error: Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2)
Is your database installed and up and running?
Do you have the correct username and
19 matches
Mail list logo
