Re: Automatically generated ChangeLog files - script
On May 26, 2020, Martin Liška wrote:
> On 5/26/20 12:15 PM, Pierre-Marie de Rodat wrote:
>>> * contracts.adb, einfo.adb, exp_ch9.adb, sem_ch12.adb,
> It's not supported right now and it will make the filename parsing
> much more complicated.
Another colleague recently run into a problem with either:
* $filename <$case>:
or
* $filename [$condition]:
I can't recall which one it was, but the following patch is supposed to
implement both. Alas, I couldn't figure out how to test it:
git_check_commit.py is failing with:
Traceback (most recent call last):
File "contrib/gcc-changelog/git_check_commit.py", line 38, in
not args.non_strict_mode):
File "/l/tmp/build/gcc/contrib/gcc-changelog/git_repository.py", line 57, in
parse_git_revisions
elif file.renamed_file:
AttributeError: 'Diff' object has no attribute 'renamed_file'
accept and [cond] in ChangeLog
From: Alexandre Oliva
Only '(' and ':' currently terminate file lists in ChangeLog entries
in the ChangeLog parser. This rules out such legitimate entries as:
* filename :
* filename [COND]:
This patch extends the ChangeLog parser to recognize these forms.
for contrib/ChangeLog
* gcc-changelog/git_commit.py: Support CASE and COND.
---
contrib/gcc-changelog/git_commit.py | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/contrib/gcc-changelog/git_commit.py
b/contrib/gcc-changelog/git_commit.py
index 4a78793..537c667 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -154,6 +154,7 @@ changelog_regex = re.compile(r'^(?:[fF]or
+)?([a-z0-9+-/]*)ChangeLog:?')
pr_regex = re.compile(r'\tPR (?P[a-z+-]+\/)?([0-9]+)$')
dr_regex = re.compile(r'\tDR ([0-9]+)$')
star_prefix_regex = re.compile(r'\t\*(?P\ *)(?P.*)')
+end_of_location_regex = re.compile(r'[[<(:]')
LINE_LIMIT = 100
TAB_WIDTH = 8
@@ -203,14 +204,13 @@ class ChangeLogEntry:
line = m.group('content')
if in_location:
-# Strip everything that is not a filename in "line": entities
-# "(NAME)", entry text (the colon, if present, and anything
-# that follows it).
-if '(' in line:
-line = line[:line.index('(')]
-in_location = False
-if ':' in line:
-line = line[:line.index(':')]
+# Strip everything that is not a filename in "line":
+# entities "(NAME)", cases "", conditions
+# "[COND]", entry text (the colon, if present, and
+# anything that follows it).
+m = end_of_location_regex.search(line)
+if m:
+line = line[:m.start()]
in_location = False
# At this point, all that's left is a list of filenames
--
Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/
Free Software Evangelist Stallman was right, but he's left :(
GNU Toolchain Engineer Live long and free, and prosper ethically
await your feedback
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 how LLVM implements it using macro to store the information: > https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/3b6c06e354ef1e59da22778a9033d87ed0e3b19d/libompd/src/omp-debug.h#L22-L28 > These values are then used here: > https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/3b6c06e354ef1e59da22778a9033d87ed0e3b19d/libompd/src/omp-debug.cpp#L1344-L1358 We don't support any TRs and I think we aren't going to, so just encoding there the 5.0 numbers should be good enough. 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 #define OMPD_VERSION (5 * 1 + 0 * 100 + 0) so there is some room for minor revisions below that. Jakub
Re: [OMPD] API version formatting
On Mon, Jun 22, 2020 at 1:47 PM Jakub Jelinek via Gcc wrote:
>
> 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 how LLVM implements it using macro to store the information:
> > https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/3b6c06e354ef1e59da22778a9033d87ed0e3b19d/libompd/src/omp-debug.h#L22-L28
> > These values are then used here:
> > https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/3b6c06e354ef1e59da22778a9033d87ed0e3b19d/libompd/src/omp-debug.cpp#L1344-L1358
>
> We don't support any TRs and I think we aren't going to, so just encoding
> there the 5.0 numbers should be good enough.
> 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
> #define OMPD_VERSION (5 * 1 + 0 * 100 + 0)
> so there is some room for minor revisions below that.
I may be mistaken, but I believe OpenMP version information is
provided in the OPENMP macro. It is a date,and it is used to detect
the conformance level of OpenMP.
For example, to avoid compile problems with code that can be compiled
with MSVC (Microsoft provides an ancient version of OpenMP):
inline void BlockCopy(byte* dest, byte* src, size_t len)
{
// OpenMP 4.0 released July 2013.
#if _OPENMP >= 201307
#pragma omp simd
for (size_t i = 0; i < len; ++i)
dest[i] = src[i];
#else
for (size_t i = 0; i < len; ++i)
dest[i] = src[i];
#endif
}
Jeff
Re: [OMPD] API version formatting
On Mon, Jun 22, 2020 at 1:54 PM Jeffrey Walton via Gcc
wrote:
> On Mon, Jun 22, 2020 at 1:47 PM Jakub Jelinek via Gcc
> wrote:
> >
> > 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 how LLVM implements it using macro to store the information:
> > >
> https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/3b6c06e354ef1e59da22778a9033d87ed0e3b19d/libompd/src/omp-debug.h#L22-L28
> > > These values are then used here:
> > >
> https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/3b6c06e354ef1e59da22778a9033d87ed0e3b19d/libompd/src/omp-debug.cpp#L1344-L1358
> >
> > We don't support any TRs and I think we aren't going to, so just encoding
> > there the 5.0 numbers should be good enough.
> > 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
> > #define OMPD_VERSION (5 * 1 + 0 * 100 + 0)
> > so there is some room for minor revisions below that.
>
> I may be mistaken, but I believe OpenMP version information is
> provided in the OPENMP macro. It is a date,and it is used to detect
> the conformance level of OpenMP.
>
> For example, to avoid compile problems with code that can be compiled
> with MSVC (Microsoft provides an ancient version of OpenMP):
>
> inline void BlockCopy(byte* dest, byte* src, size_t len)
> {
> // OpenMP 4.0 released July 2013.
> #if _OPENMP >= 201307
> #pragma omp simd
> for (size_t i = 0; i < len; ++i)
> dest[i] = src[i];
> #else
> for (size_t i = 0; i < len; ++i)
> dest[i] = src[i];
> #endif
> }
>
> Jeff
>
Another thing I was wondering about (thanks Jeff for reminding me): is OMPD
versioning dependent on OpenMP versioning, and how should I address that?
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 > > > #define OMPD_VERSION (5 * 1 + 0 * 100 + 0) > > > so there is some room for minor revisions below that. > > > > I may be mistaken, but I believe OpenMP version information is > > provided in the OPENMP macro. It is a date,and it is used to detect > > the conformance level of OpenMP. We do define _OPENMP macro, but right now only to the 4.5 value because OpenMP 5.0 is not fully supported yet. If LLVM ompd_get_version returns that (5 << 24) + ..., then it seems to be non-conforming, as there is: "The OMPD API version number is equal to the value of the _OPENMP macro defined in the associated OpenMP implementation, if the C preprocessor is supported." So, please just return 201811, which is the value _OPENMP will eventually be changed to. Jakub
WWDC thread: support for darwin/macOS going forward
Hi, at Apple's WWDC this year they have announced that they are doing yet another architecture transition, so I was wondering what exactly would be the best way to go about adding support for it? The first issue would be just what to call the new architecture; it seems to be ARM-based, but there might be some proprietary extensions, so arm-apple-darwin or aarch64-apple-darwin might not work? The next issue would be how exactly to go about adding support for it: Apple had arm-apple-darwin support for gcc in their version of gcc-4.2 that I don't think they ever contributed back upstream, but that was for iOS, so I doubt it could just be forward-ported, and even if it could, previous attempts to grab stuff from Apple's version of gcc-4.2 have faltered for legal reasons, so that could also be a factor here. I'm guessing it might be better instead to just start afresh from scratch? I'd offer to help with testing but I *just* got a new Intel-based Mac that I haven't even managed to set up yet, so I highly doubt I'll have any money for a new ARM-based Mac anytime soon... Anyways, I'm interested to hear what people are thinking. Thanks, Eric Gallager
Re: WWDC thread: support for darwin/macOS going forward
Homebrew has GCC 9, which offers flawless development experience, at least up to quite advanced applications. There of course could be corner cases in ABI, exceptions handling, etc., which I however never came across myself on MacOS. Thus, discussing gcc 4.2 seems to be highly nonsensical these days. Good news is as long as the whole gadget stack is going to use the same cpu family, getting a piece of broken iPhone would be enough to study the big Mac :) вт, 23 июн. 2020 г. в 00:52, Eric Gallager via Gcc : > Hi, at Apple's WWDC this year they have announced that they are doing > yet another architecture transition, so I was wondering what exactly > would be the best way to go about adding support for it? The first > issue would be just what to call the new architecture; it seems to be > ARM-based, but there might be some proprietary extensions, so > arm-apple-darwin or aarch64-apple-darwin might not work? The next > issue would be how exactly to go about adding support for it: Apple > had arm-apple-darwin support for gcc in their version of gcc-4.2 that > I don't think they ever contributed back upstream, but that was for > iOS, so I doubt it could just be forward-ported, and even if it could, > previous attempts to grab stuff from Apple's version of gcc-4.2 have > faltered for legal reasons, so that could also be a factor here. I'm > guessing it might be better instead to just start afresh from scratch? > I'd offer to help with testing but I *just* got a new Intel-based Mac > that I haven't even managed to set up yet, so I highly doubt I'll have > any money for a new ARM-based Mac anytime soon... Anyways, I'm > interested to hear what people are thinking. > > Thanks, > Eric Gallager >
Re: WWDC thread: support for darwin/macOS going forward
Hey Eric, Eric Gallager via Gcc wrote: Hi, at Apple's WWDC this year they have announced that they are doing yet another architecture transition, so I was wondering what exactly would be the best way to go about adding support for it? The first issue would be just what to call the new architecture; it seems to be ARM-based, but there might be some proprietary extensions, so arm-apple-darwin or aarch64-apple-darwin might not work? the triple name is probably the least of our worries :) The next issue would be how exactly to go about adding support for it: Apple had arm-apple-darwin support for gcc in their version of gcc-4.2 that I don't think they ever contributed back upstream, but that was for iOS, so I doubt it could just be forward-ported, and even if it could, previous attempts to grab stuff from Apple's version of gcc-4.2 have faltered for legal reasons, so that could also be a factor here. Even if it were legally permissible (IANAL, but my understanding is it’s not) it would not be viable techncially, there’s just too much difference between 4.2 and 11. I’m guessing it might be better instead to just start afresh from scratch? I’d expect that to be the only option, and that would be assuming that the new platform was Mach-O or ELF based, and that the code for the assembler / linker remains public and there’s enough information on the ISA variant in use, and, and … Anyways, I’m interested to hear what people are thinking. Assuming the things mentioned above, it’s technically feasible to make or update a port … …doing a complete port from scratch would be far more viable it if was someone’s ‘Day-job’ .. absent that, then it’s going to take a loong time, I expect. cheers Iain
