Re: a feature to the wishlist
On 14/09/2021 20:48, Rafał Pietrak wrote:
W dniu 13.09.2021 o 13:41, David Brown pisze:
On 13/09/2021 11:51, Rafał Pietrak via Gcc wrote:
Hi,
Thenk you for very prompt reply.
(I'm not sure how much this is a "gcc development list" matter, rather
than perhaps a "gcc help list" or perhaps comp.arch.embedded Usenet
group discussion, but I'll continue here until Jonathan or other gcc
developers say stop.)
Thank you. I appreciate it.
And yet, I do think, that it's about the "core" gcc - it's about a
programmer is able to "talk to gcc" without much "missunderstanding".
But I'm not going to push it much more. I accept, that "talking to gcc"
with d->cr1 &= ~ { ... } syntax is not what majority of programmers
would like to be able to do.
The gcc developers are always interested in new ideas. But they are not
keen on new syntaxes or extensions - there has to be a /very/ good
reason for them. The days of gcc being a maverick that makes up its own
improved C are long, long gone - they'd much rather work with the C and
C++ committees towards improving the languages in general, instead of
having more of their own non-standard additions. So an extension like
this should ideally be a proposal for adding to C23, though gcc could
always implement it earlier. And while I appreciate what you are trying
to do here, it is simply not general enough or important enough to
justify such changes. To get a new feature implemented, it has to do
something you could not do before, or do it /far/ more simply, clearly,
safely or efficiently.
W dniu 13.09.2021 o 10:44, Jonathan Wakely pisze:
On Mon, 13 Sept 2021 at 07:55, Rafał Pietrak via Gcc wrote:
[-]
#elif VARIANT_WORKING
struct cr_s a = (struct cr_s) {
.re = 1,
.te = 1,
.rxneie = 1,
.txeie = 1,
.ue = 1 };
int *b = (int *) &a;
d->cr1 &= ~(*b);
This is a strict aliasing violation. You should either use a union or
memcpy to get the value as an int.
Yes, I know. I know, this is a "trick" I use (I had to use to missleed
gcc).
Don't think of it as a "trick" - think of it as a mistake. A completely
unnecessary mistake, that will likely give you unexpected results at times :
union {
struct cr_s s;
uint32_t raw;
} a = {(struct cr_s) {
.re = 1,
.te = 1,
.rxneie = 1,
.txeie = 1,
.ue = 1 }
};
d->cr1 &= ~(a.raw);
Ha! This is very nice.
But pls note, that if contrary to my VARIANT_WORKING this actually is
kosher (and not an error, like you've said about the my "WORKING"), and
it actually looks very similar to the VARIANT_THE_BEST ... may be there
is a way to implement VARIANT_THE_BEST as "syntactic trick" leading
compiler into this semantics you've outlined above?
The issue I noticed with your "WORKING" is the bit order - that is
orthogonal to the code structure, and easy to fix by re-arranging the
fields in the initial bit-field. It is independent from the structure
of the code.
I'm raising this questions, since CR1 as int (or better as uint32_t) is
already declared in my code. Compiler shouldn't have too hard time
weeding out struct cr_s from union embedding it.
The code to convert between a bit-field of size 32-bit and a uint32_t is
nothing at all, and the compiler can handle that fine :-) But you have
to write the source code in a way that the conversion is well defined
behaviour. When you write something that is not defined behaviour, the
compiler can generate code in ways you don't expect because technically
you haven't told it what you actually want.
I hope you also realise that the "VARIANT_TRADITIONAL" and
"VARIANT_WORKING" versions of your code do different things. The ARM
Cortex-M devices (like the STM-32) are little-endian, and the bitfields
are ordered from the LSB. So either your list of #define's is wrong, or
your struct cr_s bitfiled is wrong. (I haven't used that particular
device myself, so I don't know which is wrong.)
I'm sory. this is my mistake. I've taken a shortcut and quickly written
an at hoc '#defines' for the email. In my code I have:
enum usart_cr1_e {
USART_SBK, USART_RWU, USART_RE, USART_TE, USART_IDLEIE,
USART_RXNEIE, USART_TCIE, USART_TXEIE, USART_PEIE, USART_PS,
USART_PCE, USART_WAKE, USART_M, USART_UE,
};
And gcc produces exactly the same code in both variants:
8000c56: 68d3ldr r3, [r2, #12]
8000c58: f423 5302 bic.w r3, r3, #8320 ; 0x2080
8000c5c: f023 032c bic.w r3, r3, #44 ; 0x2c
8000c60: 60d3str r3, [r2, #12]
Great.
Also - perhaps beside the point, but good advice anyway - for this kind
of work you should always use the fixed-size types such as
"uint32_t", not home-made types like "uint". And you always want
unsigned typ
Question about missing array bounds check
I have a question about array index bounds check that I do not fully understand.
Compiling the code below, I get warnings for out-of-bounds in one case, but not
the other,
also printf output gets different, but should be same?
Maybe someone can explain what is going on, and if observed behavior is as
expected.
BR Fredrik
SOURCE CODE
#include
static const char *item[] = {
"0"
};
const char * __attribute__ ((noinline)) get_item_at(int idx) {
return item[idx];
}
int main(void) {
printf("Testing string array auto-contcat\n");
// this gives warning
printf("item_at_0 = %s\n", item[0]);
printf("item_at_1 = %s\n", item[1]);
// this gives no warning, and other output <<< ???
printf("item_at_0 = %s\n", get_item_at(0));
printf("item_at_1 = %s\n", get_item_at(1));
return 0;
}
COMPILATION (gets warnings)
gcc -o test string_array_concat.c -W -Wall -Wextra -Os
In file included from /usr/include/stdio.h:867,
from string_array_concat.c:1:
In function ‘printf’,
inlined from ‘main’ at string_array_concat.c:19:3:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:107:10: warning: ‘%s’ directive
argument is null [-Wformat-overflow=]
107 | return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack
());
| ^~~
EXECUTION (prints different results)
Testing string array auto-contcat
item_at_0 = 0
item_at_1 = (null)
item_at_0 = 0
item_at_1 = 0
Re: GCC/OpenMP offloading for Intel GPUs?
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 wikipedia is right and it is close to GLSL then it likely has not the ability to perform calls? You'd need sth like HSAIL then. > 2. offload bundler to create FAT object > -- > > If the answer is yes for both, they can hook it up with libomptarget library > and our IGC back-end. > > >-Original Message- > >From: Thomas Schwinge > >Sent: Wednesday, September 15, 2021 12:57 AM > >To: gcc@gcc.gnu.org > >Cc: Jakub Jelinek ; Tobias Burnus > >; Kirill Yukhin ; Liu, > >Hongtao > >Subject: GCC/OpenMP offloading for Intel GPUs? > > > >Hi! > > > >I've had a person ask about GCC/OpenMP offloading for Intel GPUs (the new > >ones, not MIC, obviously), to complement the existing support for Nvidia and > >AMD GPUs. Is there any statement other than "ought to be doable; someone > >needs to contribute the work"? > > > > > >Grüße > > Thomas > >- > >Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, > >80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: > >Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; > >Registergericht München, HRB 106955
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 wikipedia is right and it is > close to GLSL > then it likely has not the ability to perform calls? You'd need sth > like HSAIL then. I believe SPIR-V is essentially LLVM IR, except with some restrictions and perhaps small additions. > > 2. offload bundler to create FAT object We already produce FAT objects our way. > > -- > > > > If the answer is yes for both, they can hook it up with libomptarget > > library and our IGC back-end. We really can't use libomptarget, it clashes with what libgomp provides which is handling both the host OpenMP threads and OpenMP/OpenACC offloading. Is the IGC back-end open source? Does it use LLVM to compile SPIR-V into whatever ISA the Intel GPGPUs have? Jakub
Re: Question about missing array bounds check
On Wed, 15 Sept 2021 at 10:02, Fredrik Hederstierna wrote: > > I have a question about array index bounds check that I do not fully > understand. This question belongs on the gcc-help mailing list instead. > Compiling the code below, I get warnings for out-of-bounds in one case, but > not the other, That's not what the warning says. It is warning you that the argument is null, not that item[1] is out of bounds (although it *is* out of bounds). > also printf output gets different, but should be same? Your code has undefined behaviour. There is nothing at item[1] so accessing it is undefined, and anything can happen.
RE: GCC/OpenMP offloading for Intel GPUs?
Hi! On 2021-09-15T02:00:33+, "Liu, Hongtao via Gcc" wrote: > I got some feedback from my colleague Thanks for reaching out to them. > - > What we need from GCC > > 1. generate SPIR-V > 2. offload bundler to create FAT object > -- > > If the answer is yes for both, they can hook it up with libomptarget library > and our IGC back-end. OK, I didn't remember Intel's use of SPIR-V as intermediate representation (but that's certainly good!), and leaving aside the technical/implementation issues (regarding libomptarget etc. use, as brought up by Jakub), the question then is: are Intel planning to do that work (themselves, like for Intel MIC offloading back then), or interested in hiring someone to do it, or not? Grüße Thomas >>-Original Message- >>From: Thomas Schwinge >>Sent: Wednesday, September 15, 2021 12:57 AM >>To: gcc@gcc.gnu.org >>Cc: Jakub Jelinek ; Tobias Burnus >>; Kirill Yukhin ; Liu, >>Hongtao >>Subject: GCC/OpenMP offloading for Intel GPUs? >> >>Hi! >> >>I've had a person ask about GCC/OpenMP offloading for Intel GPUs (the new >>ones, not MIC, obviously), to complement the existing support for Nvidia and >>AMD GPUs. Is there any statement other than "ought to be doable; someone >>needs to contribute the work"? >> >> >>Grüße >> Thomas >>- >>Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, >>80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: >>Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; >>Registergericht München, HRB 106955 - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Re: Error when accessing git read-only archive
On Mon, 13 Sept 2021 at 14:03, Jonathan Wakely wrote: > > On Mon, 13 Sept 2021 at 14:01, Jonathan Wakely wrote: > > > > On Mon, 13 Sept 2021 at 13:53, Thomas Koenig via Gcc > > wrote: > > > > > > Hi, > > > > > > I just got an error when accessing the gcc git pages at > > > https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git , it is: > > > > > > This page contains the following errors: > > > error on line 91 at column 6: XML declaration allowed only at the start > > > of the document > > > Below is a rendering of the page up to the first error. > > > > The web server seems to restart the page in the middle of the HTML, > > the content contains: > > > > > > > > Content-type: text/html > > > > > > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> > > http://www.w3.org/1999/xhtml"; xml:lang="en-US" lang="en-US"> > > Ah, the "second" page it's trying to display (in the middle of the > first) is an error: > > > > 500 - Internal Server Error > > > Wide character in subroutine entry at /var/www/git/gitweb.cgi line 2208. > > Jan-Benedict managed to push a commit with a non-ASCII author email, which gitweb can't handle. f42e95a830ab48e59389065ce79a013a519646f1 says "@ług-owl.de"
Re: Error when accessing git read-only archive
On Mon, 2021-09-13 at 14:03 +0100, Jonathan Wakely via Gcc wrote: > On Mon, 13 Sept 2021 at 14:01, Jonathan Wakely > wrote: > > > > On Mon, 13 Sept 2021 at 13:53, Thomas Koenig via Gcc < > > gcc@gcc.gnu.org> wrote: > > > > > > Hi, > > > > > > I just got an error when accessing the gcc git pages at > > > https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git , it is: > > > > > > This page contains the following errors: > > > error on line 91 at column 6: XML declaration allowed only at the > > > start > > > of the document > > > Below is a rendering of the page up to the first error. > > > > The web server seems to restart the page in the middle of the HTML, > > the content contains: > > > > > > > > Content-type: text/html > > > > > > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> > > http://www.w3.org/1999/xhtml"; xml:lang="en-US" lang="en- > > US"> > > Ah, the "second" page it's trying to display (in the middle of the > first) is an error: > > > > 500 - Internal Server Error > > > Wide character in subroutine entry at /var/www/git/gitweb.cgi line > 2208. > > Summarizing some notes from IRC: The last commit it manages to print successfully in that log seems to be: c012297c9d5dfb177adf1423bdd05e5f4b87e5ec so it appears that: 42e95a830ab48e59389065ce79a013a519646f1 is triggering the issue, and indeed https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f42e95a830ab48e59389065ce79a013a519646f1 fails in a similar way, whereas other commits work. It appears to be due to the "ł" character in the email address of the Author, in that: commit c012297c9d5dfb177adf1423bdd05e5f4b87e5ec Author: Jan-Benedict Glaw works, whereas: commit f42e95a830ab48e59389065ce79a013a519646f1 Author: Jan-Benedict Glaw doesn't. git show f42e95a830ab48e59389065ce79a013a519646f1 | hexdump -C shows: 0030 41 75 74 68 6f 72 3a 20 4a 61 6e 2d 42 65 6e 65 |Author: Jan-Bene| 0040 64 69 63 74 20 47 6c 61 77 20 3c 6a 62 67 6c 61 |dict Glaw .D| 0060 61 74 65 3a 20 20 20 4d 6f 6e 20 53 65 70 20 31 |ate: Mon Sep 1| i.e. we have the two bytes 0xc5 0x82, which is the UTF-8 encoding of "ł". $ git format-patch c012297c9d5dfb177adf1423bdd05e5f4b87e5ec^^..c012297c9d5dfb177adf1423bdd05e5f4b87e5ec 0001-Fix-multi-statment-macro.patch 0002-cr16-elf-is-now-obsoleted.patch $ file *.patch 0001-Fix-multi-statment-macro.patch: unified diff output, UTF-8 Unicode text 0002-cr16-elf-is-now-obsoleted.patch: unified diff output, ASCII text Hope this is helpful Dave
Re: Error when accessing git read-only archive
Hi David, Jonathan and all others, On Wed, 2021-09-15 09:21:04 -0400, David Malcolm via Gcc wrote: > On Mon, 2021-09-13 at 14:03 +0100, Jonathan Wakely via Gcc wrote: > > On Mon, 13 Sept 2021 at 14:01, Jonathan Wakely > > wrote: > > > On Mon, 13 Sept 2021 at 13:53, Thomas Koenig via Gcc > > > wrote: > > Summarizing some notes from IRC: > > The last commit it manages to print successfully in that log seems to > be: > c012297c9d5dfb177adf1423bdd05e5f4b87e5ec > so it appears that: > 42e95a830ab48e59389065ce79a013a519646f1 > is triggering the issue, and indeed > > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f42e95a830ab48e59389065ce79a013a519646f1 > fails in a similar way, whereas other commits work. > > It appears to be due to the "ł" character in the email address of the > Author, in that: > > commit c012297c9d5dfb177adf1423bdd05e5f4b87e5ec > Author: Jan-Benedict Glaw > > works, whereas: > > commit f42e95a830ab48e59389065ce79a013a519646f1 > Author: Jan-Benedict Glaw That was indeed me, after moving my GCC repo to a different machine and adding an explicit user.email (as this wasn't automatically picking up a proper domain.) The "ł" was a typo (AltGr key still pressed while typing the "l" after having entered the "@" which requires it on a German keyboard layout.) So I broke it. Any way to make sure something like this doesn't occur again? Sorry for inconvenience! Jan-Benedict -- signature.asc Description: PGP signature
Re: Error when accessing git read-only archive
On Wed, 15 Sept 2021 at 14:37, Jan-Benedict Glaw wrote: > > Hi David, Jonathan and all others, > > On Wed, 2021-09-15 09:21:04 -0400, David Malcolm via Gcc > wrote: > > On Mon, 2021-09-13 at 14:03 +0100, Jonathan Wakely via Gcc wrote: > > > On Mon, 13 Sept 2021 at 14:01, Jonathan Wakely > > > wrote: > > > > On Mon, 13 Sept 2021 at 13:53, Thomas Koenig via Gcc > > > > wrote: > > > > Summarizing some notes from IRC: > > > > The last commit it manages to print successfully in that log seems to > > be: > > c012297c9d5dfb177adf1423bdd05e5f4b87e5ec > > so it appears that: > > 42e95a830ab48e59389065ce79a013a519646f1 > > is triggering the issue, and indeed > > > > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f42e95a830ab48e59389065ce79a013a519646f1 > > fails in a similar way, whereas other commits work. > > > > It appears to be due to the "ł" character in the email address of the > > Author, in that: > > > > commit c012297c9d5dfb177adf1423bdd05e5f4b87e5ec > > Author: Jan-Benedict Glaw > > > > works, whereas: > > > > commit f42e95a830ab48e59389065ce79a013a519646f1 > > Author: Jan-Benedict Glaw > > That was indeed me, after moving my GCC repo to a different machine > and adding an explicit user.email (as this wasn't automatically > picking up a proper domain.) The "ł" was a typo (AltGr key still > pressed while typing the "l" after having entered the "@" which > requires it on a German keyboard layout.) > > So I broke it. Any way to make sure something like this doesn't > occur again? We could add a check to the git hooks (and gcc-verify alias) to reject non-ASCII email addresses, since they're probably mistakes. And we should report it to Gitweb (if it isn't already fixed upstream) and get a fix into the version used on gcc.gnu.org.
Re: PING^2: [RFC] Whole Program Devirtualization
Hi Feng, On Tue, Sep 14 2021, Feng Xue OS via Gcc wrote: > Ping again. > I have read your email but do not have much to comment. I think that you have identified all the potential issues yourself. IIUC, I am afraid that they will mean that at least the "Typeinfo symbol resolution by linker-plugin" and "Virtual constant replacement" (but I suspect also other things you propose) will not be safe to perform by default at any optimization level save -Ofast. The cost-benefit evaluation of having it in the compiler will be difficult, but if you believe there will be users (and we will be able to document the semantics of the new options well) and the code is not very difficult to maintain, then presumably there will be no hard objections, I think. Thanks for looking into such techniques and discussing them here, Martin
Re: Error when accessing git read-only archive
Hi, On Wed, 2021-09-15 at 14:43 +0100, Jonathan Wakely via Gcc wrote: > On Wed, 15 Sept 2021 at 14:37, Jan-Benedict Glaw > wrote: > > On Wed, 2021-09-15 09:21:04 -0400, David Malcolm via Gcc < > > gcc@gcc.gnu.org> wrote: > > > It appears to be due to the "ł" character in the email address of > > > the > > > Author, in that: > > > > > > commit c012297c9d5dfb177adf1423bdd05e5f4b87e5ec > > > Author: Jan-Benedict Glaw > > > > > > works, whereas: > > > > > > commit f42e95a830ab48e59389065ce79a013a519646f1 > > > Author: Jan-Benedict Glaw > > > > That was indeed me, after moving my GCC repo to a different machine > > and adding an explicit user.email (as this wasn't automatically > > picking up a proper domain.) The "ł" was a typo (AltGr key still > > pressed while typing the "l" after having entered the "@" which > > requires it on a German keyboard layout.) > > > > So I broke it. Any way to make sure something like this doesn't > > occur again? > > We could add a check to the git hooks (and gcc-verify alias) to > reject > non-ASCII email addresses, since they're probably mistakes. > > And we should report it to Gitweb (if it isn't already fixed > upstream) > and get a fix into the version used on gcc.gnu.org. The issue is the gravatar support, which calls md5_hex($email). For now I disabled gravatar support on sourceware.org/gcc.gnu.org in /etc/gitweb.conf Cheers, Mark
Re: Error when accessing git read-only archive
Hi Jonathan! On Wed, 2021-09-15 14:43:45 +0100, Jonathan Wakely wrote: > On Wed, 15 Sept 2021 at 14:37, Jan-Benedict Glaw wrote: [UTF-8 in committer's email addresses] > > So I broke it. Any way to make sure something like this doesn't > > occur again? > > We could add a check to the git hooks (and gcc-verify alias) to reject > non-ASCII email addresses, since they're probably mistakes. It was indeed a typo for me, but others might, in the long run, actually use IDNs. Should they prepare their commits using Punycode? > And we should report it to Gitweb (if it isn't already fixed upstream) > and get a fix into the version used on gcc.gnu.org. I hope the local fix is already forwarded. That was quite a Brown Paperbag typo. :( Sorry, Jan-Benedict -- signature.asc Description: PGP signature
Re: Exact inform format escape sequence (GCC 10 or GCC 11)
On 9/14/21 3:43 AM, Basile Starynkevitch wrote:
On 9/14/21 11:32 AM, Martin Liška wrote:
On 9/10/21 15:05, Basile Starynkevitch wrote:
Hello all,
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+ GCC plugin code under directory gccplugins/
I am getting when compiling it
gcc10_metaplugin_BMGCC.cc: In function ‘int
plugin_init(plugin_name_args*, plugin_gcc_version*)’:
gcc10_metaplugin_BMGCC.cc:165:85: warning: unquoted whitespace
character ‘\x0a’ in format [-Wformat-diag]
165 | warning(UNKNOWN_LOCATION, "BISMON GCC10 METAPLUGIN:
datestamp difference for %s:\n"
| ^~~
166 | " plugin has %s, GCC had %s; this is risky.",
| ~~
gcc10_metaplugin_BMGCC.cc:169:84: warning: unquoted whitespace
character ‘\x0a’ in format [-Wformat-diag]
169 | warning(UNKNOWN_LOCATION, "BISMON GCC10 METAPLUGIN:
devphase difference for %s:\n"
| ^~~
170 | " plugin has %s, GCC had %s; this is risky.",
| ~~
gcc10_metaplugin_BMGCC.cc:174:89: warning: unquoted whitespace
character ‘\x0a’ in format [-Wformat-diag]
174 | warning(UNKNOWN_LOCATION, "BISMON GCC10 METAPLUGIN:
configuration difference for %s:\n"
| ^~~
175 | " plugin has %s, GCC had %s; this is risky.",
| ~~
gcc10_metaplugin_BMGCC.cc: In function ‘void
parse_plugin_arguments(const char*, plugin_name_args*)’:
gcc10_metaplugin_BMGCC.cc:405:53: warning: unquoted sequence of 2
consecutive space characters in format [-Wformat-diag]
405 | inform (UNKNOWN_LOCATION, "Bismon plugin %qs (%s:%d)
will handle GCC include-file events with prefix %qs",
| ^~
Hello.
The warning -Wformat-diag is internal GCC warning that hasn't been
documented. I'm CC'ing the warning author.
Where can I read the complete specification of % escape sequences for
inform?
You can read it just in source code if I'm correct, that's the only
option you have:
gcc/c-family/c-format.c:3031.
Sorry, even after looking inside it (function check_tokens presumably),
I don't understand them.
Could anyone on the list give a better explanation, or at least a dozen
of examples covering most of the cases!
-Wformat-diag detects common spelling mistakes in GCC diagnostic
messages and deviations from an internal GCC style conventions for
them. The instances above point out uses of the line-feed character
('\x0a') in the warning text that should either be quoted or avoided.
The last instance notes the use of two consecutive spaces where just
one should be used.
The conventions are documented here:
https://gcc.gnu.org/codingconventions.html
-Wformat-diag is normally only issued when compiling GCC itself.
As an GCC-internal option useful only to GCC developers it's not
mentioned in the user manual. It might make sense to document
it either in the Developer Options section or in the Internals
manual. Probably the best place to look to understand them is
the testsuite:
gcc/testsuite/gcc.dg/format/gcc_diag-11.c
Similarly, the GCC-internal format directives like %qs are only
described in GCC sources. They vary somewhat from one part of GCC
to another and the documentation is scattered throughout. The base
subset is discussed here:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/pretty-print.c;h=ade1933f86a0e5c4ab75e58e0bc6b269ccb4cfe2;hb=7ca388565af176bd4efd4f8db1e5e9e11e98ef45#l1025
Martin
Re: Error when accessing git read-only archive
Hi,
On Wed, 2021-09-15 16:10:50 +0200, Mark Wielaard wrote:
[UTF-8 email address containing a 'ł']
> The issue is the gravatar support, which calls md5_hex($email).
> For now I disabled gravatar support on sourceware.org/gcc.gnu.org in
> /etc/gitweb.conf
I am not a Perl guy, but it seems this works (tested locally):
--- a/gitweb/gitweb.perl2021-09-15 20:23:13.788195846 +0200
+++ b/gitweb/gitweb.perl2021-09-15 20:24:19.911806868 +0200
@@ -2193,7 +2193,7 @@
my $size = shift;
$avatar_cache{$email} ||=
"//www.gravatar.com/avatar/" .
- md5_hex($email) . "?s=";
+ md5_hex(utf8::is_utf8($email)?
Encode::encode_utf8($email): $email) . "?s=";
return $avatar_cache{$email} . $size;
}
I'll send that to the GIT mailing list and ask for verification.
Thanks,
Jan-Benedict
--
signature.asc
Description: PGP signature
Developer branches
Some questions about developer branches: 1. Who may create one? Who may write to them? 2. Are they required to be listed in https://gcc.gnu.org/git.html ? I notice it mentioned a whole pile of them, most of which don't seem to exist. It's a bit confusing since this seems to be a concept that is used, but not clearly documented on the web pages. paul
Re: Developer branches
On Wed, 15 Sept 2021 at 21:12, Paul Koning via Gcc wrote: > > Some questions about developer branches: > > 1. Who may create one? Who may write to them? > 2. Are they required to be listed in https://gcc.gnu.org/git.html ? I notice > it mentioned a whole pile of them, most of which don't seem to exist. Which ones? All the one I looked for exist. Some of them (like gcc-4_4-plugins and pph) should really be moved to refs/dead/heads
Re: Developer branches
On Wed, 15 Sep 2021, Paul Koning via Gcc wrote: > Some questions about developer branches: > > 1. Who may create one? Who may write to them? > 2. Are they required to be listed in https://gcc.gnu.org/git.html ? I > notice it mentioned a whole pile of them, most of which don't seem to > exist. A devel/ branch (one in refs/heads/devel/) is a shared development branch, which may be created by anyone with write access (who can decide how it will work in terms of patch approvals etc.), should be documented in git.html, and will not accept non-fast-forward pushes or branch deletion. A user branch (in refs/users//heads/) is a personal development branch, which may be created by that user (sourceware username), may not necessarily be documented in git.html, and can have non-fast-forward pushes or branch deletion (it's up to that user to decide the rules for that branch, including for non-fast-forward pushes). Likewise a vendor branch (in refs/vendors//heads/). All branches are subject to the same legal requirements (copyright assignment or DCO for code committed there). Some basic commit message checks apply to all commits on all branches, but not the ones on ChangeLog entries (it's up to you if you want to have ChangeLog entries in commit messages on a development branch). Many of the branches listed in git.html are old ones that were put in refs/dead/heads/ on conversion from SVN to git because they had not been active recently at that time. Such branches ought to be moved to the Inactive section if not already there. We don't have a documented process for moving a refs/heads/devel/ branch to refs/dead/heads/ after it's dead - that's something that can only be done with direct repository manipulation (git update-ref) on the server, it's not allowed as a push by the hooks, and should preferably be followed by git repack --window=1250 --depth=250 -b -AdFfi (on the server, takes a long time and over 100 GB of memory) because of how the delta islands configuration separates out the data for refs/dead/. -- Joseph S. Myers jos...@codesourcery.com
Re: Developer branches
> On Sep 15, 2021, at 4:34 PM, Jonathan Wakely wrote: > > On Wed, 15 Sept 2021 at 21:12, Paul Koning via Gcc wrote: >> >> Some questions about developer branches: >> >> 1. Who may create one? Who may write to them? >> 2. Are they required to be listed in https://gcc.gnu.org/git.html ? I >> notice it mentioned a whole pile of them, most of which don't seem to exist. > > Which ones? All the one I looked for exist. Perhaps I did the procedures wrong. I did a git pull, then git branch -a |fgrep devel. I see 24 entries. Looking at the git.html page, that mentions a lot more. Some examples that do exist: modula-2, ira-select. Some that don't: the ave* branches, x86, var-template. paul
Re: Developer branches
> On Sep 15, 2021, at 5:21 PM, Joseph Myers wrote: > > On Wed, 15 Sep 2021, Paul Koning via Gcc wrote: > >> Some questions about developer branches: >> >> 1. Who may create one? Who may write to them? >> 2. Are they required to be listed in https://gcc.gnu.org/git.html ? I >> notice it mentioned a whole pile of them, most of which don't seem to >> exist. > > A devel/ branch (one in refs/heads/devel/) is a shared development branch, > which may be created by anyone with write access (who can decide how it > will work in terms of patch approvals etc.), should be documented in > git.html, and will not accept non-fast-forward pushes or branch deletion. > > A user branch (in refs/users//heads/) is a personal development > branch, which may be created by that user (sourceware username), may not > necessarily be documented in git.html, and can have non-fast-forward > pushes or branch deletion (it's up to that user to decide the rules for > that branch, including for non-fast-forward pushes). Likewise a vendor > branch (in refs/vendors//heads/). > > All branches are subject to the same legal requirements (copyright > assignment or DCO for code committed there). > ... Thanks, that's useful. Suppose I want to collaborate with one other person (for now) on pdp11 target work, does it make sense to keep that in a user branch since the community is so small and isolated? I assume the other person would need (as a minimum) write-after-approval privs. paul
RE: GCC/OpenMP offloading for Intel GPUs?
Rely from Xinmin and adding him to this thead. IGC is open sourced. It takes SPIR-V IR and LLVM IR. We need "GCC IR to SPIR-V translator" similar to "LLVM-IR to SPIR-V translator" we have for LLVM-IR. How does GCC support device library? >-Original Message- >From: Thomas Schwinge >Sent: Wednesday, September 15, 2021 7:20 PM >To: Liu, Hongtao >Cc: gcc@gcc.gnu.org; Jakub Jelinek ; Tobias Burnus >; Kirill Yukhin ; Richard >Biener >Subject: RE: GCC/OpenMP offloading for Intel GPUs? > >Hi! > >On 2021-09-15T02:00:33+, "Liu, Hongtao via Gcc" >wrote: >> I got some feedback from my colleague > >Thanks for reaching out to them. > >> - >> What we need from GCC >> >> 1. generate SPIR-V >> 2. offload bundler to create FAT object >> -- >> >> If the answer is yes for both, they can hook it up with libomptarget library >and our IGC back-end. > >OK, I didn't remember Intel's use of SPIR-V as intermediate representation >(but that's certainly good!), and leaving aside the technical/implementation >issues (regarding libomptarget etc. use, as brought up by Jakub), the question >then is: are Intel planning to do that work (themselves, like for Intel MIC >offloading back then), or interested in hiring someone to do it, or not? > > >Grüße > Thomas > > >>>-Original Message- >>>From: Thomas Schwinge >>>Sent: Wednesday, September 15, 2021 12:57 AM >>>To: gcc@gcc.gnu.org >>>Cc: Jakub Jelinek ; Tobias Burnus >>>; Kirill Yukhin ; >>>Liu, Hongtao >>>Subject: GCC/OpenMP offloading for Intel GPUs? >>> >>>Hi! >>> >>>I've had a person ask about GCC/OpenMP offloading for Intel GPUs (the >>>new ones, not MIC, obviously), to complement the existing support for >>>Nvidia and AMD GPUs. Is there any statement other than "ought to be >>>doable; someone needs to contribute the work"? >>> >>> >>>Grüße >>> Thomas >>>- >>>Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße >>>201, >>>80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: >>>Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; >>>Registergericht München, HRB 106955 >- >Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, >80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: >Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; >Registergericht München, HRB 106955
