Re: https access to git repository is not working

On Wed, Mar 11, 2020 at 08:41:11AM +0100, Uros Bizjak via Gcc wrote: > $ git clone https://gcc.gnu.org/git/gcc.git > Cloning into 'gcc'... > fatal: repository 'https://gcc.gnu.org/git/gcc.git/' not found I believe #overseers are aware of this and other still unresolved issues (email to bugzilla

GCC 9.3 Released

The GNU Compiler Collection version 9.3 has been released. GCC 9.3 is a bug-fix release from the GCC 9 branch containing important fixes for regressions and serious bugs in GCC 9.2 with more than 157 bugs fixed since the previous release. This release is available from the FTP servers listed at:

GCC 9.4 Status Report (2020-03-12)

Status == GCC 9.3 has been released and the branch is again open for regression and documentation fixes. History makes us expect a GCC 9.4 release from end of year up to almost a year from now. Quality Data Priority # Change from last report ---

Re: Request to deprecate offloading to HSAIL in GCC

On Thu, Apr 09, 2020 at 07:43:02PM +0200, Martin Jambor wrote: > Therefore it is only fair to warn the community and any possible hidden > users or would-be users that it is very likely that I will propose > removal of HSAIL offloading in the course of GCC 11 development cycle > and I would like

Re: subversion status on gcc.gnu.org

On Thu, Apr 02, 2020 at 02:19:10PM +0200, Georg-Johann Lay wrote: > Am 20.03.20 um 18:37 schrieb Frank Ch. Eigler via Gcc: > > Hi - > > > > Both svn: and ssh+svn: now work for your archeological needs. > > Further, URLs such as > > > > https://gcc.gnu.org/viewcvs?rev=279160=gcc=rev > >

Re: subversion status on gcc.gnu.org

On Mon, Apr 06, 2020 at 10:46:34AM +0200, Martin Liška wrote: > On 4/6/20 10:37 AM, Jakub Jelinek wrote: > > On Mon, Apr 06, 2020 at 10:09:24AM +0200, Martin Liška wrote: > > > On 4/6/20 1:57 AM, Frank Ch. Eigler wrote: > > > > Hi - > > > > > > > > Courtesy of a lovely httpd RewriteMap-basd hack

Re: subversion status on gcc.gnu.org

On Mon, Apr 06, 2020 at 10:09:24AM +0200, Martin Liška wrote: > On 4/6/20 1:57 AM, Frank Ch. Eigler wrote: > > Hi - > > > > Courtesy of a lovely httpd RewriteMap-basd hack courtesy of Martin, we > > have all the svn r# redirects working, and faster than before. > > Great. Thank you

Re: Can we please have the old mailing list back

On Wed, Mar 25, 2020 at 09:03:15PM +, Jonathan Wakely via Gcc wrote: > See the link at the bottom of every page in the old archive: > http://www.mhonarc.org/ > > > what is the exact problem that prevents it from being used any longer? > > It's not packaged for RHEL 8. It is in EPEL8:

Re: subversion status on gcc.gnu.org

On Fri, Apr 03, 2020 at 10:38:17AM +0200, Martin Liška wrote: > > The gcc git svn-rev alias handles that (and also handles release and other > > branches) using approx. > > git log --all --grep="From-SVN: r$rev\b" | head -n 1 | awk '{print $2}' > > where $rev is 2000 in your case. > > > >

Re: GSoC: Implementation of OMPD

Hi! I appreciate you are interested in this GSoC topic! On Tue, Mar 24, 2020 at 09:18:50PM -0400, y2s1982 . via Gcc wrote: > > The OMPD project idea might be the most ambitious from the whole lot. > > Basically, the goal is to come up with a prototype implementation of > > chapter 5 of OpenMP

aarch64 C++ ABI analysis

Hi! The same testcase as has been used for powerpc64le-linux can be used for aarch64-linux too: struct X { }; struct Y { int : 0; }; struct Z { int : 0; Y y; }; struct U : public X { X q; }; struct A { float a, b, c, d; }; struct B : public X { float a, b, c, d; }; struct C : public Y { float a,

Re: Not usable email content encoding

On Thu, Apr 23, 2020 at 09:34:20AM +0100, Jonathan Wakely via Gcc wrote: > I've been having problems with it recently, e.g. > https://gcc.gnu.org/g:e76100ced607218a3bf had to fix a changelog, > because https://gcc.gnu.org/g:d76925e46fad09fc9be67 put my changelog > entry in the wrong place in

Re: GCC optimizations with O3

On Wed, Apr 22, 2020 at 04:17:56PM +0200, Philipp Tomsich wrote: > ptomsich@android:~/riscv/gcc/gcc$ git grep OPT_LEVELS_3 > common/common-target.h: OPT_LEVELS_3_PLUS, /* -O3 and above. */ > common/common-target.h: OPT_LEVELS_3_PLUS_AND_SIZE, /* -O3 and above and > -Os. */ >

GCC 11.0.0 Status Report (2020-04-30)

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

GCC 10.0.1 Status Report (2019-04-30)

Status == We have reached zero P1 regressions today and releases/gcc-10 branch has been created; GCC 10.1-rc1 will be built and announced later tonight or tomorrow. The branch is now frozen for blocking regressions and documentation fixes only, all changes to the branch require a RM approval

GCC 10.1 Release Candidate available from gcc.gnu.org

The first release candidate for GCC 10.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/10.1.0-RC-20200430/ ftp://gcc.gnu.org/pub/gcc/snapshots/10.1.0-RC-20200430 and shortly its mirrors. It has been generated from git revision r10-8080-g591d857164c37cd0bb96da2a293148e01f280e0f. I

Re: [libgomp] Ask for help on an improvement for synchronization overhead

On Thu, Apr 30, 2020 at 05:37:26PM -0300, Adhemerval Zanella via Gcc wrote: > Hi all, I would like to check if someone could help me figure out > an issue I am chasing on a libgomp patch intended to partially > address the issue described at BZ#79784. > > I have identified that one of the

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

On Fri, May 01, 2020 at 09:23:33AM +0200, Martin Liška wrote: > On 4/30/20 11:21 PM, Jakub Jelinek via Gcc wrote: > > The first release candidate for GCC 10.1 is available from > > > > https://gcc.gnu.org/pub/gcc/snapshots/10.1.0-RC-20200430/ > > ftp://gcc.gnu.org/

Re: Automatically generated ChangeLog files - script

On Thu, Apr 30, 2020 at 03:29:10PM +0200, Martin Liška wrote: > $ ./changelog.py > patches/1957-c-generic-lambda-forwarding-function-PR94546.patch > OK > -- gcc/cp/ChangeLog -- > 2020-04-22 Jason Merrill > > PR c++/94546 > * pt.c (register_parameter_specializations): If

Re: Automatically generated ChangeLog files - script

On Thu, Apr 30, 2020 at 05:14:34PM +0200, Martin Liška wrote: > On 4/30/20 3:45 PM, Jakub Jelinek wrote: > > If this is what is really created, then for the new file, missing * space, > > gcc/testsuite/ that shouldn't be there and missing PR c++/94546 line above > > it. > > I've just fixed all

Re: Automatically generated ChangeLog files - script

On Mon, May 04, 2020 at 08:56:16PM +0200, Martin Liška wrote: > What's missing right now is how will we declare a Backport format. > Can we just use something like: 'Backport from > 6607bdd4c834f92fce924abdaea3405f62dc'? No. What we should allow is that people just git cherry-pick

Re: GCC 10.0.1 Status Report (2019-04-30)

On Mon, May 04, 2020 at 11:03:13PM +0100, Jonathan Wakely wrote: > On Thu, 30 Apr 2020 at 19:20, Jakub Jelinek via Gcc wrote: > > > > Status > > == > > > > We have reached zero P1 regressions today and releases/gcc-10 branch has > > been created; G

Re: Automatically generated ChangeLog files - PHASE 1

On Tue, May 12, 2020 at 11:05:58AM +0200, Martin Liška wrote: > Thanks to Jakub, we finally set up an experimental environment: > gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git > > The repository now contains a new pre-commit hook that validates > the git commit format ([1]) and provides a

Re: Multilibs in stage-1

On Thu, May 07, 2020 at 09:02:58AM +0200, Richard Biener wrote: > Hmm. IIRC it required special-handling in the individual libs - Jakub > may remeber (IIRC > he implemented short-cutting libsanitizer builds) Just fuzzy memories, but I think the libsanitizer case was that it the build of that is

Re: New mklog script

On Tue, May 19, 2020 at 10:11:28AM +0200, Martin Liška wrote: > > I find this format more helpful for the reasons below so unless your > > script can be tweaked to do something similar I'd like to be able to > > continue to use mine going forward with the new infrastructure. > > Let's extend the

GCC 10.1 Released

A year has lapsed away since the release of last major GCC release, more than 33 years passed since the first public GCC release and the GCC developers survived repository conversion from SVN to GIT earlier this year. Today, we are glad to announce another major GCC release, 10.1. This release

Re: Fw: GSoC topic: Implement hot cold splitting at GIMPLE IR level

On Mon, Mar 16, 2020 at 11:11:14PM +, Aditya K via Gcc wrote: > > > > 2) ipa-split is very simplistic and only splits when there is no value > >computed in header of function used in the tail. We should support > > adding extra parameters for values computed and do more general SESE >

Stability of pipermail ml archive URLs

Hi! Last week after sending status report mails to gcc mailing list, I've opened the web archive and copied the URLs of those status reports https://gcc.gnu.org/pipermail/gcc/2020-April/232267.html https://gcc.gnu.org/pipermail/gcc/2020-April/232268.html and checked them into gcc-wwwdocs git

Re: New mklog script

On Tue, May 19, 2020 at 05:21:16PM +0100, Richard Earnshaw wrote: > This is really a wart in the GNU coding style. And one reason why I > tend to indent such labels by a single space. It particularly affects > things like class definitions where public, private, etc statements > often appear in

Re: ChangeLog files - server and client scripts

On Thu, May 21, 2020 at 03:12:21PM -0700, Ian Lance Taylor via Gcc wrote: > Hi, this unfortunately breaks gccgo development. Significant parts of > the gccgo sources are simply copied from other repositories. Those > other repositories do not use ChangeLog files. The git commit hook > should

Re: ChangeLog files - server and client scripts

On Fri, May 22, 2020 at 12:04:10PM +0100, Richard Earnshaw wrote: > >> The directories in question are > >> > >> gcc/go/gofrontend > >> libgo > >> gcc/testsuite/go.test/test > > > > The script has: > > ignored_prefixes = [ > > 'gcc/d/dmd/', > > 'gcc/go/frontend/', > > The directory is

Re: ChangeLog files - server and client scripts

On Thu, May 21, 2020 at 02:52:37PM -0400, Jason Merrill wrote: > Was there a decision somewhere to require ChangeLog entries for all > testcase changes now, as the hook is enforcing? They were optional before. > > remote: *** ChangeLog format failed: > remote: ERR: changed file not mentioned in

Re: PowerPC long double Mangling

On Wed, Sep 09, 2020 at 12:32:22PM -0500, Segher Boessenkool wrote: > On Wed, Sep 09, 2020 at 07:06:41PM +0200, Thomas Koenig wrote: > > Am 09.09.20 um 17:36 schrieb Segher Boessenkool: > > >You can use both __ibm128 and __ieee128 in one program, so it isn't an > > >ABI change. Only the default

Re: Why was it important to change "FALLTHROUGH" to "fall through"?

On Tue, Sep 08, 2020 at 07:28:45AM -0700, Bruce Korb via Gcc wrote: > On Tue, Sep 8, 2020 at 2:33 AM Jonathan Wakely wrote: > > > Nope. I had /* FALLTHROUGH */ on the line before a blank line before > > > the case label. After Googling, I found an explicit reference that you > > > had to spell

Re: Function signatures in extern "C".

On Mon, Sep 07, 2020 at 10:27:13AM +0100, Jonathan Wakely via Gcc wrote: > On Mon, 7 Sep 2020 at 09:18, Iain Sandoe wrote: > > > > Perhaps the PR should be reopened with “accepts invalid”? > > My impression from the PR is that the reporter was using a different > ABI, where the name isn't

Re: PowerPC long double Mangling

On Tue, Sep 15, 2020 at 01:37:20AM -0400, Michael Meissner wrote: > > What's the benefit of having __float128 and IEEE long double be > > distinct types? That complicates things for libraries like libstdc++. > > If we want to support using "__float128" with C++ iostreams then we > > need yet

Re: Is there a way to look for a tree by its UID?

On Fri, Sep 04, 2020 at 10:12:57AM +0200, Erick Ochoa wrote: > I am thinking about representing an alias set similarly to the pt_solution. > Instead of having bits set in position of points-to variables UIDs, I was > thinking about having bits set in position of may-alias variables' UIDs. I >

Re: Is there a way to look for a tree by its UID?

On Thu, Sep 03, 2020 at 10:22:52AM +0200, Erick Ochoa wrote: > So, I am just wondering is there an interface where I could do something > like: > > ``` > // vars is the field in pt_solution of type bitmap > EXECUTE_IF_SET_IN_BITMAP (vars, 0, uid, bi) > { >// uid is set >

Loop question

Hi! Compiling the following testcase with -O2 -fopenmp: int a[1][128]; __attribute__((noipa)) void foo (void) { #pragma omp for simd schedule (simd: dynamic, 32) collapse(2) for (int i = 0; i < 1; i++) for (int j = 0; j < 128; j++) a[i][j] += 3; } int main () { for (int

Re: GCC DWARF Issue - Frame Pointer Dependency

On Tue, Oct 13, 2020 at 08:22:03AM +0200, Richard Biener via Gcc wrote: > > Another question, is there a known work around for this issue? > > In case you do not get a sufficient answer here it might be useful to > report a bug in bugzilla so it doesn't get lost. And, as written in

Re: [RFC] LTO Dead Field Elimination and LTO Field Reordering

On Thu, Aug 20, 2020 at 07:41:54PM +, Tamar Christina wrote: > While I would agree that it's fundamentally more restrictive than an > object based one I wouldn't say it's useless. At the very least it gives > us something to build on later. It is IMHO useless and has also very undesirable

Re: duplicate arm test results?

On Wed, Sep 23, 2020 at 12:37:52PM +0200, Andreas Schwab wrote: > On Sep 23 2020, Jakub Jelinek via Gcc wrote: > > > Even that 8.4.1 20200918 is redundant, r8-10517 uniquely and shortly > > identifies both the branch and commit. > > But it requires a repository to ide

Re: First set of patches to allow changing the long double default were posted:

On Mon, Sep 28, 2020 at 05:07:55PM -0400, Michael Meissner wrote: > On Mon, Sep 28, 2020 at 04:38:51PM +, Joseph Myers wrote: > > On Thu, 24 Sep 2020, Michael Meissner wrote: > > > > > As per the discussion in this thread, I did decide to keep things to two > > > types > > > within the

Re: duplicate arm test results?

On Wed, Sep 23, 2020 at 10:22:52AM +0100, Richard Sandiford wrote: > So that would give: > > Results for 8.4.1 20200918 [r8-10517] on arm-none-linux-gnueabihf > > and hopefully free up some space at the end for the kind of thing > you mention. Even that 8.4.1 20200918 is redundant, r8-10517

Re: New mklog script

On Tue, May 26, 2020 at 03:14:54PM +0200, Martin Liška wrote: > > > > gcc-ci? > > > > > > What the abbreviation stands for? > > > > > > Martin > > > > > > > > > > > R. > > > > > > > > > > > CheckIn > > > > For those who come from the SVN days where ci was the standard > > abbreviation for

[IMPORTANT] ChangeLog related changes

Hi! I've turned the strict mode of Martin Liška's hook changes, which means that from now on no commits to the trunk or release branches should be changing any ChangeLog files together with the other files, ChangeLog entry should be solely in the commit message. The DATESTAMP bumping script will

Re: [1-800-GIT-HELP] Backporting a series of commits into a combined commit?

On Sat, May 30, 2020 at 09:35:05PM +0100, Jonathan Wakely via Gcc wrote: > On Sat, 30 May 2020 at 21:09, Harald Anlauf wrote: > > > > Dear experts, > > > > let's assume I need to backport a series of commits on master to a release > > branch. > > In the release branch, this series of commits

Re: [1-800-GIT-HELP] Backporting a series of commits into a combined commit?

On Tue, Jun 02, 2020 at 10:53:57AM +0200, Richard Biener wrote: > On Mon, Jun 1, 2020 at 2:17 PM Thomas Koenig via Fortran > wrote: > > > > Hi Martin, > > > > > For now, I would recommend doing 1:1 backports. Otherwise, you'll need > > > to merge > > > all ChangeLog entries in a format the server

Re: [IMPORTANT] ChangeLog related changes

On Tue, May 26, 2020 at 12:42:41PM +0200, Thomas Koenig wrote: > Am 26.05.20 um 11:04 schrieb Thomas Koenig via Gcc: > > Am 26.05.20 um 00:48 schrieb Jakub Jelinek via Gcc: > > > > > I've turned the strict mode of Martin Liška's hook changes, > > > > This

Re: [IMPORTANT] ChangeLog related changes

On Tue, May 26, 2020 at 12:27:59PM +0100, Richard Earnshaw wrote: > I haven't investigated in detail, but could we use a merge strategy with > the cherry-pick to drop ChangeLog entries? If that works, sure. Note, when cherry-picking commits from before conversion to git or whenever people started

Re: ChangeLog files - server and client scripts

On Fri, May 22, 2020 at 12:37:29PM -0700, Ian Lance Taylor wrote: > Thanks for looking into this. > > Unfortunately, my push is still failing. I'm not sure why. > > remote: *** ChangeLog format failed: > remote: ERR: cannot find a ChangeLog location in message > remote: > remote: Please see:

Re: ChangeLog files - server and client scripts (git cherry-pick)

On Wed, May 20, 2020 at 11:19:49AM +0200, Thomas Koenig wrote: > Hm, one question: I find the r11-1234 type commit to be much more > readable, in ChangeLog files and everywhere else. > > Would it be possible to have that format instead of > "cherry picked from commit $HEX_SOUP" ? I think if you

Re: wide int knowledge/bug?

On Tue, Oct 27, 2020 at 01:18:03PM -0400, Andrew MacLeod via Gcc wrote: > I was looking at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97596 > > and the ranger is constructing some 128 bit constants and calling > wide_int_to_tree to turn them into trees. > > In particular, it starts with the

Re: Complete 'ChangeLog' files state (was: GCC 10.2 Release Candidate available from gcc.gnu.org)

On Fri, Jul 17, 2020 at 09:10:45AM +0200, Richard Biener wrote: > On Fri, 17 Jul 2020, Thomas Schwinge wrote: > > > Hi! > > > > On 2020-07-15T13:50:35+0200, Richard Biener wrote: > > > The first release candidate for GCC 10.2 is available from > > > > > >

Re: Coding style for C++ constructs going forward

On Fri, Aug 07, 2020 at 07:56:03AM -0700, Joel Brobecker wrote: > > Pedro has pointed out LLVM's coding standards for "auto", which we may or > > may not want to follow/adopt: > > https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable Also see the

Re: ** POTENTIAL FRAUD ALERT - RED HAT ** Re: Problem with 64-bit only compiler build

On Wed, Aug 12, 2020 at 09:33:05AM -0400, Paul Smith wrote: > As someone who takes a lot of advantage of the flexibility that tools > like GCC provide I'm wary of reducing that flexibility. On the other > hand I'm not sure that breaking up the internal structure of GCC's > installation via

Re: Problem with 64-bit only compiler build

On Wed, Aug 12, 2020 at 01:08:53PM +0100, Jonathan Wakely via Gcc wrote: > > Oddly, I looked through the gnulib library and didn't find any > > appropriate module for this. It seems like there should be one. > > C++17 provides std::filesystem::weakly_canonical for that. It doesn't > help GCC or

Re: Unused libgcc symbol reference

On Thu, Aug 13, 2020 at 02:33:50PM +0200, Tobias Wölfel via Gcc wrote: > I observed that in some ELF files there is code present which is not used. > It originates from integer arithmetics. > The following snipped should help to demonstrate the problem. It is there because the division in this

GCC Plugins and global_options

Hi! Any time somebody adds or removes an option in some *.opt file (which e.g. on the 10 branch after branching off 11 happened 5 times already), many offsets in global_options variable change. It is true we don't guarantee ABI stability for plugins, but we change the most often used data

Re: [OMPD] Questions on per-process functions and related data types.

On Wed, Jul 01, 2020 at 10:50:44PM -0400, y2s1982 . via Gcc wrote: > per-process functions defined in 5.5.2. > I have some questions on defining or at least using some of the data types. The standard makes those intentionally not defined, it is up to the implementation to put in there whatever is

Re: [OMPD] Questions on per-process functions and related data types.

On Thu, Jul 02, 2020 at 10:57:11AM -0400, y2s1982 . wrote: > > On Wed, Jul 01, 2020 at 10:50:44PM -0400, y2s1982 . via Gcc wrote: > > > per-process functions defined in 5.5.2. > > > I have some questions on defining or at least using some of the data > > types. > > > > The standard makes those

Re: gcc-changelog: Support git revert commit messages

On Tue, Jun 30, 2020 at 10:45:27AM +0200, Martin Liška wrote: > Hello. > > After a brief discussion with Jakub, I was convinced to support 'git revert' > where > a ChangeLog is created from the commit the was reverted. Ok. Jakub

Re: Confirm the semantic of GCC extension "Conditionals with Omitted Operands"

On Wed, Jul 01, 2020 at 11:53:05AM -0400, Nathan Sidwell wrote: > On 7/1/20 10:11 AM, Gong, Sishuai via Gcc wrote: > > Hope this mail finds you well. I am writing this to ask about one extension > > in GCC, which is “Conditionals with Omitted Operands”. > > > > From the document at

Re: DW_OP_implict_value usage and motivation

On Tue, Jul 07, 2020 at 09:26:58AM +, Tomar, Sourabh Singh wrote: > Thanks for clarifying this. I went through literature and other stuff > available, it describes operation and semantics. Unfortunately I wasn't > able to get to the actual DWARF Issue/proposal when it was proposed. > > One

Re: New x86-64 micro-architecture levels

On Mon, Jul 13, 2020 at 06:31:31AM -0700, H.J. Lu via Gcc wrote: > > > H.J. has patches for ELF program properties. I think > > > GNU_PROPERTY_X86_ISA_1_NEEDED would convey this information. This > > > proposal and the glibc patches are independent of that. > > > > From (partly just halfway)

Re: DW_OP_implict_value usage and motivation

On Sat, Jul 04, 2020 at 04:23:58PM +, Tomar, Sourabh Singh wrote: > Consider the following test case: > [..] > int main () { > __int128 newVar = 8; > newVar = ~newVar; > return 0; > } DW_OP_implicit_value as well as DW_OP_stack_value is described in DWARF4/5, just read

Re: [OMPD] Library Functions

On Tue, Jun 30, 2020 at 06:50:54PM -0400, y2s1982 . via Gcc wrote: > 2020-06-30 Tony Sim > > libgomp/ChangeLog: > > * libgompd.h : Add gompd_callbacks variable. No space before :, but generally, you should be exact on what changed. So * libgompd.h: Include omp-tools.h.

Re: RFC/RFH - proof of concept for GCC OpenMP 5.0 non-rectangular worksharing-loop implementation

On Wed, Jun 17, 2020 at 02:29:40PM +0200, Richard Biener wrote: > So this remembers me of the loop scalarization pass Sebastian once > implemented - that is, with the above constraints it looks like we > can do the actual collapsing, replacing collapsed loops with a new > one with a canonical IV

Re: [OMPD] API version formatting

On Mon, Jun 22, 2020 at 03:14:44PM -0400, y2s1982 . via Gcc wrote: > > > If the 4 separate bytes of the version isn't something written somewhere > > in > > > the standard, I'd use something along the lines of > > > #define GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__) > > > macro, so make it > >

Re: [OMPD] API version formatting

On Sat, Jun 20, 2020 at 01:26:59PM -0400, y2s1982 . via Gcc wrote: > I have a question on API version formatting. > I have been looking at the get_api_version() and get_api_version_string() > documentation: > https://www.openmp.org/spec-html/5.0/openmpsu213.html#x269-17920005.5.1.2 > I also saw

Re: RFC noipa sizeof function for record relayout at link time

On Mon, Jun 29, 2020 at 01:05:20PM +0200, Richard Biener via Gcc wrote: > > // source code > > struct astruct a; > > memset(a, 0, sizeof(a)); > > > > // parse time > > memset(a, 0, 64); Actually, I don't see the point at all, it doesn't matter if the user used sizeof(a) or 64 knowing that the

RFC/RFH - proof of concept for GCC OpenMP 5.0 non-rectangular worksharing-loop implementation

Hi! Before OpenMP 5.0, all OpenMP loop nests had to be rectangular (and OpenMP has various other restrictions that make implementation easier), so that it was very easy to compute the number of iterations of the collapsed loop by computing number of iterations of each of the loops in the loop

Re: [OMPD] regarding const char **ompd_dll_locations

On Thu, Jun 18, 2020 at 06:19:43PM -0400, y2s1982 . wrote: > Thank you for the quick response. I assume, then, there's no need for > making a function to set this global variable at this point. Should I > create a simple unit test that asserts the value to be "libgompd.so.1" for > now, or should I

Re: [OMPD] regarding const char **ompd_dll_locations

On Thu, Jun 18, 2020 at 05:24:25PM -0400, y2s1982 . wrote: > (LLVM currently simply puts { "ompd.so", NULL }, but I am assuming this was > just a placeholder.) Let's put there { "libgompd" SONAME_SUFFIX (1), NULL } for now. You'll need to change the SONAME_SUFFIX macros though - remove the ()s

Re: Stepping down as x86 vector ISA maintainer

On Wed, Jun 03, 2020 at 09:25:35AM +0200, Uros Bizjak via Gcc wrote: > I would like to inform GCC community, that I decided to step down from > maintaining x86 vector ISA part. x86 vector ISA has its own > non-responsive maintainer, but I have filled the maintainers role > nevertheless, until

Re: GSoC: OMPD conversation

On Fri, Jun 05, 2020 at 03:13:42PM -0400, y2s1982 . wrote: > > > The LLVM's repository for OMPD development is at this github repo > > > , > > > under the branch ompd-test. > > > The OMPD documentation > > >

Re: install location of math-vector-fortran.h

On Mon, Jun 08, 2020 at 12:52:36PM +0200, Matthias Klose wrote: > GCC and glibc need to agree on the install location for math-vector-fortran.h. > Currently it is installed into > > /usr/include/finclude/math-vector-fortran.h > > However the file is architecture specific, currently only having

Re: gcc math functions for OpenMP vectoization

On Fri, Jun 05, 2020 at 01:58:55PM +, Feltgen, Eric wrote: > my name is Eric, I'm a german student at RWTH Aachen University currently > researching OpenMP. > > > For my research, I'm also looking at math functions provided by compilers > like GCC. When writing vectorizable code, it is

Re: Automatic vs. manual 'ChangeLog' files updates for devel/ branches etc. (was: [PATCH] wwwdocs: Document devel/omp/gcc-10 branch)

On Wed, Jun 10, 2020 at 05:47:54PM +0200, Thomas Schwinge wrote: > The automated system runs once a day. I guess it's generally deemed > acceptable if the source code state (commits) and the 'ChangeLog' files > state is out of sync for one day. There surely must be some mechanism in > place to

Re: LTO Dead Field Elimination

On Mon, Jul 27, 2020 at 02:52:21PM +0200, Erick Ochoa wrote: > I will work on making this more readable. I understand your comments and you > are right. I am currently in the process of writing a human-readable PDF > with an overview of this. There is already a (somewhat hurried) version of > this

Re: [OMPD] Questions on per-process functions and related data types.

On Thu, Jul 02, 2020 at 06:58:49PM -0400, y2s1982 . via Gcc wrote: > This is giving me more clarity on what I have to do. At the moment, I am > storing the > information in the handle. > > I do have one problem: in 5.5.2.1 ( >

Re: [OMPD] Questions on per-process functions and related data types.

On Fri, Jul 03, 2020 at 10:26:27AM -0400, y2s1982 . wrote: > Still, following the documentation 5.5.2.1, how should I extract version > information from ompd_address_space_context_t that is owned by the > debugger instead of the OMPD to check for compatibility , especially > when it is not

Re: Accessing fields in the global_options structure from out-of-sync plugins

On Fri, Aug 14, 2020 at 04:33:42PM +0100, Nick Clifton wrote: > With the annobin plugin for gcc I have a problem accessing some of the > fields in the global_options structure. Although the plugin can use > the macros defined in options.h, this only works if the plugin is in > sync with

Re: DWARF64 gcc/clang flag discussion

On Mon, Nov 23, 2020 at 06:38:16PM -0800, David Blaikie via Gcc wrote: > > I would pick -gdwarf32/-gdwarf64 (are we sure the DWARF spec will > > never reach version 32 or 64? > > maybe -g32 / -g64 similar to -m32/-m64 are good enough?) > > Any sense of a good way to break the tie/uncertainty? >

Re: DWARF64 gcc/clang flag discussion

On Tue, Nov 24, 2020 at 12:04:45PM +0100, Mark Wielaard wrote: > Hi, > > On Tue, 2020-11-24 at 08:50 +0100, Richard Biener wrote: > > On Tue, Nov 24, 2020 at 8:45 AM Jakub Jelinek wrote: > > > I agree with Richard and I'd lean towards -gdwarf32/-gdwarf64, even > > > when DWARF 32 is released in

Re: DWARF64 gcc/clang flag discussion

On Mon, Dec 07, 2020 at 08:14:20AM +0100, Richard Biener via Gcc wrote: > > Sorry, just going around in circles a bit, I guess this may be a better > > summary: > > If I had to pick a -g flag/semantic for this, I guess I'd pick > > -gdwarf32/64 without implied -g. I'd pick that if I knew GCC

Re: No warning for module global variable which is set but never used

On Wed, Dec 09, 2020 at 10:50:22AM +0100, David Brown wrote: > I'd say that it makes sense to have such a warning as a natural > enhancement to the existing "-Wunused-but-set-variable" warning. But I That is not really possible. The -Wunused-but-set-* warning works by having two bits for the

Re: Possible leaks observed in GCC.

On Wed, Dec 09, 2020 at 12:55:40PM +, Jonathan Wakely via Gcc wrote: > > > I observed some leaks using valgrind while compiling a sample program > > > using GCC. > > > > This seems more appropriate for gcc-h...@gcc.gnu.org instead. > > > > > Could anyone aware of these details provide any

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

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

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

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: 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, Nov 09, 2020 at 08:57:48AM +0100, Martin Liška wrote: > On 11/6/20 8:59 PM, Jakub Jelinek wrote: > > I think I'll work with Martin early next week to think about further spots > > to add logging, so we narrow down where it is still called and where it > > isn't. > > Hello. > > I'm

Re: gcc/DATESTAMP not updated any longer

On Tue, Nov 10, 2020 at 09:23:09AM +0100, Martin Liška wrote: > On 11/9/20 11:09 PM, Jakub Jelinek wrote: > > So I think either new_update must be raising an exception, or returning > > None for some reason. > > Bet we want to add logging for that exception, as well as for it returning > > None

Re: Minimum CUDA version supported by GCC?

On Thu, Nov 19, 2020 at 12:03:09PM +0100, Thomas Schwinge wrote: > 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. > , >

Re: Re: typeof and operands in named address spaces

On Tue, Nov 17, 2020 at 11:13:52AM -0800, Linus Torvalds wrote: > > +#define __unqual_typeof(type) typeof( (typeof(type))type ) > that's certainly a much nicer version than the existing pre-processor > expansion from hell. It would need to be typeof( (typeof(type)) (type) ) to not be that

Re: gcc/DATESTAMP not updated any longer

On Mon, Nov 02, 2020 at 08:14:22PM +0100, Rainer Orth wrote: > I noticed that gcc/DATESTAMP isn't updated any longer after this > Friday. I doubt this is intentional... === Working on: master === branch pulled and checked out 74 revisions since last Daily bump writing to ./libstdc++-v3/ChangeLog

Re: gcc/DATESTAMP not updated any longer

On Mon, Nov 02, 2020 at 09:37:56PM +0100, Martin Liška wrote: > > writing to ./gcc/testsuite/ChangeLog > > empty group "()" found:"* tree-vect-slp.c (): Update backedges in > > single-node cycles." > > Traceback (most recent call last): > >File "../gcc-changelog/git_update_version.py",

Re: Implementing OpenMP 5.0 requires directive

On Fri, Oct 30, 2020 at 10:48:09PM +0800, Chung-Lin Tang wrote: > We've been going over how we should implement the requires directive, in a > bit more complete > sense than the current state (i.e. only atomic_default_mem_order working). > > For the three clauses where the specification requires

  1   2   3   4   5   6   7   8   9   10   >