Re: gcc/DATESTAMP not updated any longer

On Fri, Dec 11, 2020 at 07:04:28PM +0100, Martin Liška wrote: > On 12/11/20 2:17 PM, Rainer Orth wrote: > > Rainer Orth writes: > > > > > I noticed that gcc/DATESTAMP isn't updated any longer after this > > > Friday. I doubt this is intentional... > > > > This has happened again tonight... > >

Re: gcc/DATESTAMP not updated any longer

On Mon, Dec 14, 2020 at 09:59:22AM +0100, Martin Liška wrote: > On 12/11/20 7:26 PM, Jakub Jelinek wrote: > > When running it manually it just completed without problems. > > So, no idea what happened. > > Morning. > > Unfortunately, today we have similar problem. Master was bumped, but > not any

Re: gcc/DATESTAMP not updated any longer

On Mon, Dec 14, 2020 at 10:21:15AM +0100, Martin Liška wrote: > On 12/14/20 10:05 AM, Jakub Jelinek wrote: > > Note, last night r11 DATESTAMP bump actually succeeded, it was the other > > branches that failed. > > I know. > > So please try to output the script output to a log. So that we can anal

Re: gcc/DATESTAMP not updated any longer

On Mon, Dec 14, 2020 at 11:02:44AM +0100, Andreas Schwab wrote: > On Dez 14 2020, Martin Liška wrote: > > > On 12/11/20 7:26 PM, Jakub Jelinek wrote: > >> When running it manually it just completed without problems. > >> So, no idea what happened. > > > > Morning. > > > > Unfortunately, today we h

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

On Tue, Dec 15, 2020 at 05:02:24PM +0100, Thomas Schwinge wrote: > Per the 'fold_convert_loc' code (cited below), we see that for 'type' of > 'case INTEGER_TYPE' etc. -- which 'type' of 'case REFERENCE_TYPE' does > "fall through" into -- we do not handle 'arg' of 'REAL_CST' like we do > for 'type'

Re: More consistency for Git log messages?

On Tue, Dec 29, 2020 at 12:54:53AM +0100, Gerald Pfeifer wrote: > Having spent a bit more time with GCC sources (as opposed to wwwdocs) > recently and looking for prior art to guide me, I noticed there's a > lot of options to specific the ChangeLog file(s) to use. > > And correspondingly a lot o

Re: Calls to auto-vectorized AVX512 functions

On Mon, Feb 08, 2021 at 11:42:13AM +0100, Richard Biener via Gcc wrote: > > I have a question as to the auto-vectorizer in GCC. > > > > When AVX512 instruction is available, the auto-vectorizer in gcc > > sometimes generates calls to AVX2 functions instead of AVX512 functions. > > > > > > $ cat vab

Re: DWZ 0.14 released

On Tue, Mar 09, 2021 at 11:38:07AM +, Hannes Domani via Dwz wrote: > Am Dienstag, 9. März 2021, 10:10:47 MEZ hat Mark Wielaard > Folgendes geschrieben: > > > Hi Allan, > > > > On Tue, Mar 09, 2021 at 09:06:54AM +0100, Allan Sandfeld Jensen wrote: > > > Btw, question for gcc/binutils > > > >

Re: printf: Ambiguous warning

On Tue, Mar 16, 2021 at 11:20:05AM +0100, Rene Kita wrote: > (Please keep me CC'd, I'm not subscribe to the list) > > Here is a minimal example: > #include > > int > main() > { > unsigned short n; > unsigned short *p; > p = &n; > > printf("p: %hn\n", p); > } > > > % gcc -Wall -Wpedant

Re: [RFC] avoid type conversion through versioning loop

On Mon, Mar 22, 2021 at 09:22:26AM +0100, Richard Biener via Gcc wrote: > Better than doing loop versioning is to enhance SCEV (and thus also > dependence analysis) to track extra conditions they need to handle > cases similar as to how niter analysis computes it's 'assumptions' > condition. That

Re: Can help with task of language frontend cleanup

On Thu, Mar 25, 2021 at 12:06:08PM +, Jonathan Wakely via Gcc wrote: > What would be the benefit? > > I can understand the advantage of a single binary that is a > cross-compiler for different targets (but it would be a huge task to > get GCC there). You wouldn't need multiple complete copies

Re: GCC 10.3 Release Candidate available from gcc.gnu.org

On Thu, Apr 01, 2021 at 08:49:19PM +0100, Jonathan Wakely via Gcc wrote: > On Thu, 1 Apr 2021 at 20:23, Iain Sandoe wrote: > > > > Richard Biener wrote: > > > > > On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou > > > wrote: > > >>> I have so far bootstrapped and tested the release candidate

Re: GCC 10.3 Release Candidate available from gcc.gnu.org

On Fri, Apr 02, 2021 at 09:37:26AM +0200, Matthias Klose wrote: > On 4/1/21 2:35 PM, Richard Biener wrote: > > > > The first release candidate for GCC 10.3 is available from > > > > https://gcc.gnu.org/pub/gcc/snapshots/10.3.0-RC-20210401/ > > ftp://gcc.gnu.org/pub/gcc/snapshots/10.3.0-RC-20210

GCC 11.1 Release Candidate available from gcc.gnu.org

The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I ha

GCC 11.0.1 Status Report (2021-04-20)

Status == We have reached zero P1 regressions today and releases/gcc-11 branch has been created; GCC 11.1-rc1 has been built and announced a few moments ago. The branch is now frozen for blocking regressions and documentation fixes only, all changes to the branch require a RM approval now. I

GCC 12.0.0 Status Report (2021-04-20)

Status == The trunk has branched for the GCC 11 release and is now open again for general development, stage 1. Please consider not disrupting it too much during the RC phase of GCC 11 so it is possible to test important fixes for 11.1 on it. Quality Data Priority #

D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)

On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote: > > On 4/20/21 10:24 AM, Jakub Jelinek via Gcc wrote: > > The first release candidate for GCC 11.1 is available from > > > > https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ > &g

GCC 8.5 Status Report (2021-04-23)

Status == GCC 8.5 release and closing of the 8 branch is several months overdue, we don't have enough time to maintain trunk and 4 supported release branches. Therefore, I'd like to do 8.5-rc1 on 7th of May and release 8.5 and close the branch a week after that. We have one P1 bug though - P98

Second GCC 11.1 Release Candidate available from gcc.gnu.org

Some blocker bugs were reported against the first release candidate of GCC 11.1, so there is a second release candidate for GCC 11.1 available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210423/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210423 and shortly its mirrors. It has b

Re: Second GCC 11.1 Release Candidate available from gcc.gnu.org

On Sun, Apr 25, 2021 at 08:21:12PM +0100, Iain Sandoe via Gcc wrote: > William Seurer via Gcc wrote: > > > On 4/23/21 8:31 AM, Jakub Jelinek via Gcc wrote: > > > Some blocker bugs were reported against the first release candidate > > > of GCC 11.1, so there is a se

GCC 11.1 Released

The GCC developers are proud to announce another major GCC release, 11.1. This release switches the default debugging format to DWARF 5 [1] on most targets and switches the default C++ language version to -std=gnu++17. It makes great progress in the C++20 language support, both on the compiler and

GCC 11.1.1 Status Report (2021-04-27)

Status == GCC 11.1 has been released, the releases/gcc-11 branch is open again for regression and documentation bugfixing. GCC 11.2 can be expected in 2-3 months from now unless something serious changes the plans. Quality Data Priority # Change from last report ---

Re: TREE_NO_WARNING and internal variables

On Thu, Apr 29, 2021 at 11:22:15AM -0600, Martin Sebor via Gcc wrote: > The C front end (and perhaps others as well) creates internal > variables in a few places, such as in convert_lvalue_to_rvalue > like so: > > /* Remove the qualifiers for the rest of the expressions and >create t

Re: TREE_NO_WARNING and internal variables

On Thu, Apr 29, 2021 at 11:54:27AM -0600, Martin Sebor via Gcc wrote: > On 4/29/21 11:32 AM, Jakub Jelinek wrote: > > On Thu, Apr 29, 2021 at 11:22:15AM -0600, Martin Sebor via Gcc wrote: > > > The C front end (and perhaps others as well) creates internal > > > variables in a few places, such as in

GCC 8.5 Release Candidate available from gcc.gnu.org

The first release candidate for GCC 8.5 is available from https://gcc.gnu.org/pub/gcc/snapshots/8.5.0-RC-20210507/ ftp://gcc.gnu.org/pub/gcc/snapshots/8.5.0-RC-20210507 and shortly its mirrors. It has been generated from git revision r8-10959-g3488242b9a949ebc55b4a857380f94506f90ff76. I have

GCC 8.5 Status Report (2021-05-07)

Status == The 8.5 branch is now frozen for the final GCC 8.5 release, the release candidate has been announced. All changes to the branch require RM approval. Quality Data Priority # Change from last report --- --- P1

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

On Fri, May 07, 2021 at 10:20:11PM +0200, Thomas Schwinge wrote: > 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)

Re: gettext, _, N_, and G_

On Thu, May 13, 2021 at 06:01:39PM -0400, Jason Merrill via Gcc wrote: > I understand that the difference between the _ macro and the N_ macro is > that the former is used to force a gettext call on the argument and the > latter is used for strings for which gettext will be called later. But I > d

Re: gettext, _, N_, and G_

On Thu, May 13, 2021 at 08:56:39PM -0400, Jason Merrill wrote: > >From 8718fbbf83978bd8ec4bf0a0e4164459158df182 Mon Sep 17 00:00:00 2001 > From: Jason Merrill > Date: Thu, 13 May 2021 20:53:50 -0400 > Subject: [PATCH] intl: add comments to _, N_, and G_ > To: gcc-patc...@gcc.gnu.org > > gcc/Chang

Re: gettext, _, N_, and G_

On Fri, May 14, 2021 at 09:41:57AM +0200, Jakub Jelinek via Gcc wrote: > I'd just write > /* Like N_, but for GCC diagnostic format strings. See ABOUT-GCC-NLS for >details. */ > for this and if something is unclear, clarify there. See https://gcc.gnu.org/legacy-ml/gc

GCC 8.5 Releasedd

GCC version 8.5 has been released. GCC 8.5 is a bug-fix release from the GCC 8 branch containing important fixes for regressions and serious bugs in GCC 8.4 with more than 199 bugs fixed since the previous release. This is also the last release from the GCC 8 branch, GCC continues to be maintaine

Re: Update to GCC copyright assignment policy

On Tue, Jun 01, 2021 at 10:00:06AM -0400, David Edelsohn via Gcc wrote: > GCC was created as part of the GNU Project but has grown to operate as > an autonomous project. > > The GCC Steering Committee has decided to relax the requirement to > assign copyright for all changes to the Free Software F

Re: Update to GCC copyright assignment policy

On Tue, Jun 01, 2021 at 11:25:16AM -0400, Paul Koning via Gcc wrote: > GCC is free software; you can redistribute it and/or modify > it under the terms of the GNU General Public License as published by > the Free Software Foundation; either version 3, or (at your option) > any later version. > > T

Re: Update to GCC copyright assignment policy

On Thu, Jun 03, 2021 at 02:35:51PM +0200, Giacomo Tesio wrote: > > The GCC Steering Committee has decided to relax the requirement to > > assign copyright for all changes to the Free Software Foundation. GCC > > will continue to be developed, distributed, and licensed under the GNU > > General Pub

Re: Update to GCC copyright assignment policy

On Thu, Jun 03, 2021 at 04:07:07PM +0200, Giacomo Tesio wrote: > On Thu, 3 Jun 2021 15:02:16 +0200 Jakub Jelinek wrote: > > > On Thu, Jun 03, 2021 at 02:35:51PM +0200, Giacomo Tesio wrote: > > > Is it possible to release a new version for the last commit that > > > only includes changes under FSF

Re: Update to GCC copyright assignment policy

On Mon, Jun 07, 2021 at 02:17:55PM +, Giacomo Tesio wrote: > Anyway, to most people it's just a matter of risk assesment. > > GCC will now come with a new legal risk that was absemt before, thus > it should be handled properly, with a proper notice and incapaulated > in a new major version.

Re: Update to GCC copyright assignment policy

On Mon, Jun 07, 2021 at 11:45:49AM -0400, Jason Merrill wrote: > The copyright troll risk is much, much lower for GCC than for Linux. > First, because GPL3 specifically addresses the over-strict automatic > termination rules in GPL2 that copyright trolls leverage. And also because > there are many

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Thu, Jun 10, 2021 at 11:01:49AM +0100, Jonathan Wakely via Gcc wrote: > On 10/06/21 10:44 +0100, Jonathan Wakely wrote: > > > Quite interesting idea! Are you willing to prepare a patch for it? > > > > This works. > > And this works better, because it checks the PR in the title matches > one in

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Thu, Jun 10, 2021 at 11:20:26AM -0600, Martin Sebor wrote: > One other note: you mention policy above, which suggests a requirement. > My understanding is that the format of a commit message is a convention > put in place to take some of the tedium out of creating ChangeLog > entries. If that's

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Thu, Jun 10, 2021 at 12:55:43PM -0600, Martin Sebor wrote: > Instead of rejecting commits that don't mention all the same PRs on > the first line of the commit as in the ChangeLog entries it seems > that the Git commit script could extract the PR references from > just the ChangeLong entries

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Thu, Jun 10, 2021 at 03:16:43PM -0600, Martin Sebor wrote: > > Just look at the start of this thread. Some people put > > the [PRn] only in the first line of the commit. And that is > > what these changes want to diagnose, that is an error and results > > in bugzilla not being updated. >

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Fri, Jun 11, 2021 at 11:02:52AM -0600, Martin Sebor wrote: > My objection is to making our policies and tools more restrictive > than they need to be. We shouldn't expect everyone to study whole > manuals just to figure out how to successfully commit a change (or > learn how to format it just t

Re: GCC/clang warning incompatibility with unused private member variables

On Fri, Jun 11, 2021 at 04:03:34PM -0400, Jason Merrill via Gcc wrote: > You can use #pragma to disable a warning for a particular section of code: > > #pragma GCC diagnostic push > #pragma GCC diagnostic ignored "-Wattributes" > class Test { > [[maybe_unused]] int a_; > void b() {}; > }

Re: Difficulties in merging patterns

On Thu, Jun 17, 2021 at 03:21:05PM +0200, Richard Biener wrote: > but the difficulty is in the (const_int ..) operand to (vec_merge ..). > I've tried sth like > > (define_mode_attr addsub_cst [(V4DF "(const_int 5)") (V2DF "(const_int > 1)") > (V4SF "(const_int 5)") (

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Thu, Jun 17, 2021 at 09:33:06AM -0600, Martin Sebor wrote: > On 6/17/21 9:11 AM, Michael Matz wrote: > > Hello, > > > > On Thu, 17 Jun 2021, Martin Sebor via Gcc wrote: > > > > > > The original problem is that the PR wasn't _in the body_ of the commit > > > > > > But I see [PR100085] right th

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Thu, Jun 17, 2021 at 05:12:52PM +, Joseph Myers wrote: > On Thu, 17 Jun 2021, Richard Earnshaw via Gcc wrote: > > > It seems a bit dangerous to me to rely on just extracting PR numbers from > > tests. What if the patch is just adjusting a test to make it compatible > > with > > the remain

Re: [Patch] contrib/mklog.py: Improve PR handling (was: git gcc-commit-mklog doesn't extract PR number to ChangeLog)

On Fri, Jun 18, 2021 at 12:10:33PM +0100, Jonathan Wakely wrote: > On Fri, 18 Jun 2021 at 12:05, Tobias Burnus wrote: > > But with -p added, it becomes rather nice. For instance: > > > >git diff |./contrib/mklog.py -b foo/12394 -b 100123 -p > > > > nows prints: > > > > PR c++/12394 - internal c

Re: Hongtao Liu as x86 vectorization maintainer

On Mon, Jun 21, 2021 at 02:49:56AM +, Liu, Hongtao via Gcc wrote: > >-Original Message- > >From: Jason Merrill > >Sent: Monday, June 21, 2021 10:07 AM > >To: Liu, Hongtao > >Cc: gcc Mailing List ; Marek Polacek > >Subject: Hongtao Liu as x86 vectorization maintainer > > > >I am pleas

Re: where is PRnnnn required again?

On Tue, Jul 06, 2021 at 03:20:26PM -0600, Martin Sebor via Gcc wrote: > I came away from the recent discussion of ChangeLogs requirements > with the impression that the PR bit should be in the subject > (first) line and also above the ChangeLog part but doesn't need > to be repeated again in th

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

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 > constitute a warp, which means "execution state per thread, including a > program counter",

Re: Failures building glibc with mainline GCC

On Fri, Jul 30, 2021 at 04:38:58PM +, Joseph Myers wrote: > In addition to failures building glibc, for those configurations for which > glibc builds there's a failure building the testsuite: > > tst-thread_local1.cc:177:5: error: variable 'std::array char*, std::function >, 2> do_thread_X' h

Re: Failures building glibc with mainline GCC

On Fri, Jul 30, 2021 at 10:53:28AM -0600, Martin Sebor via Gcc wrote: > On 7/30/21 9:30 AM, Joseph Myers wrote: > > There are a lot of failures building glibc with mainline GCC right now > > > > (previously, there were ICEs buil

Re: gcc_assert() and inhibit_libc

On Mon, Aug 16, 2021 at 12:50:49PM -0400, Jason Merrill via Gcc wrote: > > The trap builtin is target-specific. Making this system-specific (in > > this case RTEMS) could be an issue. > > Is that necessary? Are there interesting targets that don't have a trap insn? Depends on the definition of i

Re: On(c)e more: optimizer failure

On Sat, Aug 21, 2021 at 09:40:16PM +0200, Stefan Kanthak wrote: > > I believe your example doesn't take into account that the values can be NaN > > which compares false in all situations. > > That's a misbelief! > Please notice the first if-clause, which rules out NaNs for both arguments. > Also n

Re: s390 port

On Fri, Sep 03, 2021 at 10:38:36PM +1000, Paul Edwards via Gcc wrote: > > This is not in one single place, but spread throughout the > > compiler, both common code and back-end. I do not think it will > > be possible to get the compiler to generate correct code if > > you do not specify the addres

Re: Exact inform format escape sequence (GCC 10 or GCC 11)

On Tue, Sep 14, 2021 at 11:32:13AM +0200, Martin Liška wrote: > On 9/10/21 15:05, Basile Starynkevitch wrote: > > In the Bismon static source code analyzer on > > https://github.com/bstarynk/bismon/ commit ad8b6270691e > > > > (funded by http://decoder-project.eu/ ) which contains some GPLv3+

Re: GCC/OpenMP offloading for Intel GPUs?

On Wed, Sep 15, 2021 at 11:19:29AM +0200, Richard Biener wrote: > On Wed, Sep 15, 2021 at 4:02 AM Liu, Hongtao via Gcc wrote: > > > > I got some feedback from my colleague > > > > - > > What we need from GCC > > > > 1. generate SPIR-V > > But is SPIR-V powerful enough here, if wik

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

On Fri, Sep 17, 2021 at 10:08:34AM +0200, Florian Weimer via Gcc wrote: > > So the compiler would emit a call to __memcmpeq and at the same time > > emit a weak alias of __memcmpeq to memcmp so the program links > > when the libc version targeted does not provide __memcmpeq? Or would > > glibc thr

libgfortran.so SONAME and powerpc64le-linux ABI changes

Hi! On powerpc64le-linux target, one can select between two incompatible long double formats (both of them are 16-byte), __ibm128 which is a sum of two doubles, and __float128 (note, not implemented through libquadmath), which is IEEE754 quad format. The default for long double can be selected wi

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Mon, Oct 04, 2021 at 01:24:05PM +0200, Richard Biener wrote: > > Your thoughts on this? > > How does glibc deal with this? There's a load of long double ABI in there. I don't know, CCing Florian; all I can see is that starting with glibc 2.26 in addition to sin{f,,l} there is also sinf128, bu

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Mon, Oct 04, 2021 at 01:36:56PM +0200, Jakub Jelinek via Gcc wrote: > On Mon, Oct 04, 2021 at 01:24:05PM +0200, Richard Biener wrote: > > > Your thoughts on this? > > > > How does glibc deal with this? There's a load of long double ABI in there. > > I don&#

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Mon, Oct 04, 2021 at 12:07:54PM +0200, Jakub Jelinek via Gcc wrote: > Or the last option would be to try to make libgfortran.so.5 ABI compatible > with both choices on powerpc64le-linux. From quick skimming of libgfortran, > we have lots of generated functions, which use HAVE_GFC_RE

Re: Including documentation files with gcc releases

On Wed, Oct 06, 2021 at 01:19:28PM +, dimechc via Gcc wrote: > I got the GCC 11.2 download, but cannot locate the doc directory used to > produce the > gcc documentation manuals. gcc/doc/, gcc/*/*.texi, libstdc++-v3/doc/, lib*/*.texi, ... Jakub

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, Oct 06, 2021 at 10:17:44AM -0500, Segher Boessenkool wrote: > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote: > > On 05.10.21 23:54, Segher Boessenkool wrote: > > >>There is also the issue of binary data. If some user has written > > >>out data in double double and wants to

Re: Including documentation files with gcc releases

On Wed, Oct 06, 2021 at 03:57:35PM +, dimechc via Gcc wrote: > ‐‐‐ Original Message ‐‐‐ > On Wednesday, October 6th, 2021 at 2:50 PM, Jonathan Wakely > wrote: > > > On Wed, 6 Oct 2021, 14:19 dimechc, wrote: > > > >> I got the GCC 11.2 download, but cannot locate the doc directory us

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote: > We can emulate it everywhere (using libquadmath for example). This can > magically make -msoft-float work as well everywhere, btw. Emulation is one thing, but another one is where are those __float128 or quad long double argume

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Wed, Oct 06, 2021 at 11:59:37AM -0500, Segher Boessenkool wrote: > On Wed, Oct 06, 2021 at 06:34:33PM +0200, Jakub Jelinek wrote: > > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote: > > > We can emulate it everywhere (using libquadmath for example). This can > > > magically

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote: > On 07.10.21 05:35, Michael Meissner via Fortran wrote: > > I tried this at one point. There are a lot of hidden assumptions that the > > kind > > number is the number of bytes. I'm sure it can be tracked down, but the > > problem i

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Thu, Oct 07, 2021 at 11:56:45AM +0200, Andreas Schwab wrote: > On Okt 07 2021, Alastair McKinstry wrote: > > > I strongly advise against this -- identical SONAMEs for the libraries on > > all architectures is a key assumption on all Debian-based distributions > > and designs > > Even glibc ha

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Thu, Oct 07, 2021 at 11:24:35AM -0400, Michael Meissner wrote: > On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote: > > On 07.10.21 05:35, Michael Meissner via Fortran wrote: > > > I tried this at one point. There are a lot of hidden assumptions that > > > the kind > > > number is

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Sat, Oct 09, 2021 at 11:11:51AM +0200, Thomas Koenig wrote: > The question is still if we can avoid a new SONAME for >99% of our users > for no gain at all for them. Is there a possibility of aliasing the > SONAME somehow (grasping at straws here)? I'd hope Debian can just ln -sf libgfortran.s

Re: Development request

On Tue, Oct 12, 2021 at 01:09:10PM +0200, Martin Jambor wrote: > The preferred way of communication is email posted to the mailing list > (sometimes CCing the people you think are most likely to reply) and I am > quite confident that people will read it and reply to reasonable > questions and revie

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Fri, Oct 15, 2021 at 08:50:08AM -0500, Bill Schmidt wrote: > Thanks, Jakub, for starting this discussion, and to everyone who weighed in. > The conversation > went in a number of different directions, so I'd like to summarize my > understanding of points > where I think there was agreement.

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

On Fri, Oct 15, 2021 at 08:05:38PM +0200, Thomas Koenig wrote: > > with -mabi=ibmlongdouble, I see 31 and 291, while with -mabi=ieeelongdouble > > 33 and 4931. The 0.0_8 precision/range values are 15 and 307, so neither > > precision of C long double if it is double-double nor range matches > > a

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (2nd patch)

On Sat, Oct 30, 2021 at 11:30:29AM +0200, Thomas Koenig wrote: > - Have a compiler switch which selects between IEEE_QP and IBM_QP. > This was a suggestion by Steve Lionel formerly of DEC and Intel, > and they did that when they had a few floating point formats on > the Alpha to choose from.

Re: New ThreadSanitizer runtime (v3)

On Mon, Nov 22, 2021 at 08:00:38PM +0100, Dmitry Vyukov wrote: > Not sure about gcc, but in clang the old no_sanitize_thread attribute > disabled only part of instrumentation (only memory accesses, but not > atomics and function entry/exit). The new attribute disables all > instrumentation. In gcc

Re: distinguishing gcc compilation valgrind false positives

On Wed, Nov 24, 2021 at 12:31:53PM -0700, Jeff Law via Gcc wrote: > Agreed.  Work from the assumption it's a real GCC issue until proven > otherwise. > > I believe GCC has annotations to help valgrind that are turned on by a magic > configuration option as well. True, but Zdenek has them turned o

Re: [power-ieee128] What should the math functions be annotated with?

On Wed, Dec 01, 2021 at 09:34:47PM +0100, Thomas Koenig via Gcc wrote: > I am currently working on implementing the IEEE 128-bit floating > on POWER. One of the things to decide is what to call the > math functions for the library calls. > > Example: libgfortran/generated/bessel_r16.c currently h

Re: [power-ieee128] What should the math functions be annotated with?

On Wed, Dec 01, 2021 at 09:54:50PM +0100, Jakub Jelinek wrote: > sinl in C when compiled with -mabi=ieeelongdouble), but I'm not sure > if those need to be declared by libgfortran or math.h declares them). To answer this myself, just tried on Fedora 34 and we'd need to declare those ourselves. Bec

Re: [power-ieee128] What should the math functions be annotated with?

On Fri, Dec 03, 2021 at 08:29:53AM +0100, Thomas Koenig wrote: > > On 01.12.21 21:54, Jakub Jelinek via Fortran wrote: > > > Inside of libgfortran, I think it should depend on some macro defined > > in libgfortran.h. > > #if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \ >

Re: [power-ieee128] What should the math functions be annotated with?

On Fri, Dec 03, 2021 at 12:16:56PM +0100, Thomas Koenig wrote: > > It is part of upstream glibc 2.32 (released Aug 2020) and later, see > > https://sourceware.org/git/?p=glibc.git;a=commit;h=051be01f6b41a1466b07ae4bd7f5894a8ec5fe67 > > distrowatch says that glibc 2.32 and later is in Ubuntu 21.04 a

Re: [power-ieee128] What should the math functions be annotated with?

On Sat, Dec 04, 2021 at 11:16:28AM +0100, Thomas Koenig wrote: > > On 04.12.21 07:39, Michael Meissner via Fortran wrote: > > I have loaded Advance Toolchain 15.0 on the system. It is located in > > /opt/at15.0. AT 15 provides a GCC 11.2 compiler and GLIBC 2.34. > > I tried bootstrapping (from

Re: [power-ieee128] What should the math functions be annotated with?

On Sat, Dec 04, 2021 at 10:12:37AM -0600, Peter Bergner via Gcc wrote: > On 12/4/21 9:37 AM, Peter Bergner wrote: > > On 12/4/21 9:25 AM, Michael Meissner wrote: > > ubuntu@gcc-fortran:/home/tkoenig/Tst$ ldd ./a.out > > ./a.out: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not > > f

Re: [power-iee128] How to specify linker flags

On Mon, Jan 03, 2022 at 11:19:21AM +0100, Thomas Koenig wrote: > > > If you are building libraries that contain modules with multiple > > > long double > > > types, you must use the '-mno-gnu-attribute'.  We also use the > > > '-Wno-psabi' > > > option, which silences the warning that you are switc

Re: Mass rename of C++ .c files to .cc suffix?

On Fri, Jan 07, 2022 at 11:25:50AM +0100, Martin Jambor wrote: > Would anyone be terribly against mass renaming all *.c files (that are > actually C++ files) within the gcc subdirectory to ones with .cc suffix? > > We already have 47 files with suffix .cc directly in the gcc > subdirectory and 160

Re: Mass rename of C++ .c files to .cc suffix?

On Fri, Jan 07, 2022 at 03:33:54PM -0300, Alexandre Oliva via Gcc wrote: > On Jan 7, 2022, Martin Jambor wrote: > > > Would anyone be terribly against mass renaming all *.c files (that are > > actually C++ files) within the gcc subdirectory to ones with .cc suffix? > > I wouldn't mind that. >

Re: [PATCH] Mass rename of C++ .c files to .cc suffix

On Tue, Jan 11, 2022 at 04:50:02PM +0100, Martin Liška wrote: > On 1/11/22 16:48, Toon Moene wrote: > > On 1/11/22 13:56, Martin Liška wrote: > > > > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > > Plus it survives build of all FEs (--enable-languages=all) on > > >

Re: [PATCH] Mass rename of C++ .c files to .cc suffix

On Tue, Jan 11, 2022 at 05:03:34PM +0100, Martin Liška wrote: > On 1/11/22 16:56, Jakub Jelinek wrote: > > While e.g. libcpp or gcc are in C++. > > Which means I should rename .c files under libcpp, right? > Is there any other folder from gcc/ and libcpp/ that would need that as well? >From the d

Re: [PATCH] Mass rename of C++ .c files to .cc suffix

On Tue, Jan 11, 2022 at 06:23:51PM +, Jonathan Wakely via Gcc-patches wrote: > > Regarding fortran: can we have a vote on this one? > > > > Some developers (including myself) are not really familiar with C++, > > and in the past preference has been expressed on the fortran ML in > > favor of no

Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ

On Tue, Jan 18, 2022 at 10:08:20AM +0100, Martin Liška wrote: > On 1/18/22 09:53, Richard Biener wrote: > > Technically all release managers are also global reviewers, but I > > agree the speciality > > of the Ada setup (esp. the runtime being in gcc/) could have been > > anticipated. > > Yeah, I

Re: Enquiry

On Sun, Jan 30, 2022 at 10:47:41AM +0100, Theodore Papadopoulo wrote: > Before creating a bug report, I want to check with the GCC community (all > the more that checking that the problem has not yet been reported is > complicated at leat for me). > > The following (admitedly buggy) program genera

Re: Enquiry

On Sun, Jan 30, 2022 at 10:50:56AM +, Jonathan Wakely wrote: > We could put a trap instruction at the end of the function though, which > would make the result a bit less arbitrary. > > I've come around to thinking that's preferable for cases like this. Depends on which exact cases. Because f

Re: Enquiry

On Sun, Jan 30, 2022 at 11:11:15AM +, Jonathan Wakely wrote: > On Sun, 30 Jan 2022, 10:58 Jakub Jelinek, wrote: > > > On Sun, Jan 30, 2022 at 10:50:56AM +, Jonathan Wakely wrote: > > > We could put a trap instruction at the end of the function though, which > > > would make the result a b

Re: adding OMPD support

On Fri, Feb 11, 2022 at 12:46:32AM +0200, Mohamed Atef wrote: >i want to make the variable ompd_dll_locations global to openMP > runtime according to my understanding i should add it to OMP_5.1 {} in Given that it is not going to make GCC 12 which introduced the OMP_5.1 symbol version, our

Re: OpenMP auto-simd

On Wed, Mar 02, 2022 at 03:12:30PM +, Stubbs, Andrew wrote: > Has anyone ever considered having GCC add the "simd" clause to offload (or > regular) loop nests automatically? > > For example, something like "-fomp-auto-simd" would transform "distribute > parallel" to "distribute parallel simd

Re: possible bug in gcc compiler

Note, this mailing list is for development of gcc, gcc-help would be more appropriate. On Fri, Mar 11, 2022 at 07:53:32PM +, Larry Jackson via Gcc wrote: > I goofed and failed to put a space after the "case" word: > > switch(nu){ > case1: v1 =val;break; > case2: v2 =val;break; > case3: v3 =va

Urgent GCC ABI backend maintainer ping re zero width bitfield passing (PR102024)

Hi! I'd like to ping port maintainers about https://gcc.gnu.org/PR102024 As I wrote, the int : 0 bitfields are present early in the TYPE_FIELDS during structure layout and intentionally affect the layout. We had some code to remove those from TYPE_FIELDS chains in the C and C++ FEs, but for C tha

Re: Urgent GCC ABI backend maintainer ping re zero width bitfield passing (PR102024)

On Tue, Mar 22, 2022 at 04:28:08PM +, Richard Earnshaw wrote: > Unless I've missed something subtle here, the layout of > > struct S { float a; int : 0; float b;}; > > is going to identical to > > struct T { float a; float b;}; > > on pretty much every architecture I can think of, so th

Re: Urgent GCC ABI backend maintainer ping re zero width bitfield passing (PR102024)

On Fri, Mar 25, 2022 at 02:26:56PM +, Richard Earnshaw wrote: > Just to confirm that this is our final position. The 'int:0 field should be > ignored for the purposes of determining the parameter passing as it has no > effect on the layout of the type. > > We do not feel that an update to the

GCC 12.0.1 Status Report (2022-04-28)

Status == We have reached zero P1 regressions today and releases/gcc-12 branch has been created. GCC 12.1-rc1 will be built likely tomorrow. The branch is now frozen for blocking regressions and documentation fixes only, all changes to the branch require a RM approval now. If no show stopper

<    1   2   3   4   >