Re: [RFC] Adding Python as a possible language and it's usage
On Fri, Jul 27, 2018 at 3:38 PM, Joseph Myers wrote: > On Fri, 27 Jul 2018, Michael Matz wrote: > >> Using any python scripts as part of generally building GCC (i.e. where the >> generated files aren't prepackaged) will introduce a python dependency for >> distro packages. And for those distros that bootstrap a core cycle of >> packages (e.g. *SUSE) this will include python (and all its dependencies) >> into that bootstrap cycle. > > I would have expected most concerns to be about builds on non-GNU hosts - > not about builds on GNU/Linux where Python is generally already available > (and differences in Python versions should definitely *not* affect the > generated output, so there should be no increases in the number of > iterations required for any bootstrap cycle to converge). > > We've been having a similar discussion for glibc, both about replacing > uses of perl (optional, but required to build the manual and to run > various tests - python is also already required to run various tests) with > python and about replacing uses of awk (required) with python as well, in > the interests of easier maintainability - and I didn't see any concerns > raised about such a change at all. Of course in the glibc case pretty > much all building is done on GNU hosts (although theoretically you can > cross-compile from non-GNU systems, in practice that's liable to be broken > with e.g. cross-rpcgen not building with random systems' headers, and > probable dependencies on GNU versions of various host tools). I can certainly remember quite a number of painful issues getting shaken out by python during the AArch64 bootstrap much before we published the port upstream that not much other testing was able to find. It was a good test of the toolchain but if it is required that you need to have working python on the target *before* you get a bootstrapped GCC on the system, I'm not sure how helpful / frustrating that is really to folks trying to bring up a GNU / Linux system natively. I am concerned that we are increasing the barrier on entry for such developers. It is not the majority of developers (but put another way) we do need to answer the question whether the dependency on python makes it harder for folks to bring up a new GNU/Linux system on a new architecture even though it may make life easier in other areas for working on the compiler. What are the other areas where we envisage using python in the longer term for GCC ? option processing is one area, where else ? > Obviously if you're bootstrapping core packages and their build > dependencies, use in glibc is more or less equivalent to use in GCC. (But > if build dependencies include those involved in testing, you already have > python as one for glibc, and Tcl for GCC, for example.) This implies that the decision for glibc has been made. while you imply above that the discussion is still on going ? regards Ramana > > > Joseph S. Myers > jos...@codesourcery.com
Re: Dynamically allocated array of function pointers
Please don't cross-post to this list and to gcc-help, this question is
off-topic here
On Sat, 28 Jul 2018 at 04:01, Vladimir Reshetnikov
wrote:
>
> I'm trying to understand why gcc rejects the dynamic array allocation in
> the initializer of e (introducing an alias or additional parenthesization
> suppress the error). Clang and MSVC happily compile this code. Does gcc
> correctly reject this code?
>
> template
> void f() {
> typedef void(*arr[T::value])(); // OK
> arr a = { }; // OK
> void(*b[T::value])() = { }; // OK
> void(**c)() = new arr { }; // OK
> void(**d)() = new (void(*[(T::value)])()) { }; // OK
> void(**e)() = new (void(*[T::value])()) { }; // error: capture of
> non-variable 'T'
> }
>
> struct S {
> static constexpr int value = 5;
> };
>
> int main() {
> f();
> }
>
> Tested against build 9.0.0 20180726 (experimental).
>
> --
> Thanks
> Vladimir
Re: [RFC] Adding Python as a possible language and it's usage
On Sat, 2018-07-28 at 10:55 +0100, Ramana Radhakrishnan wrote: > On Fri, Jul 27, 2018 at 3:38 PM, Joseph Myers m> wrote: > > On Fri, 27 Jul 2018, Michael Matz wrote: > > > > > Using any python scripts as part of generally building GCC (i.e. > > > where the > > > generated files aren't prepackaged) will introduce a python > > > dependency for > > > distro packages. And for those distros that bootstrap a core > > > cycle of > > > packages (e.g. *SUSE) this will include python (and all its > > > dependencies) > > > into that bootstrap cycle. > > > > I would have expected most concerns to be about builds on non-GNU > > hosts - > > not about builds on GNU/Linux where Python is generally already > > available > > (and differences in Python versions should definitely *not* affect > > the > > generated output, so there should be no increases in the number of > > iterations required for any bootstrap cycle to converge). > > > > We've been having a similar discussion for glibc, both about > > replacing > > uses of perl (optional, but required to build the manual and to run > > various tests - python is also already required to run various > > tests) with > > python and about replacing uses of awk (required) with python as > > well, in > > the interests of easier maintainability - and I didn't see any > > concerns > > raised about such a change at all. Of course in the glibc case > > pretty > > much all building is done on GNU hosts (although theoretically you > > can > > cross-compile from non-GNU systems, in practice that's liable to be > > broken > > with e.g. cross-rpcgen not building with random systems' headers, > > and > > probable dependencies on GNU versions of various host tools). > > I can certainly remember quite a number of painful issues getting > shaken out by python during the AArch64 bootstrap much before we > published the port upstream that not much other testing was able to > find. It was a good test of the toolchain but if it is required that > you need to have working python on the target *before* you get a > bootstrapped GCC on the system, I'm not sure how helpful / > frustrating > that is really to folks trying to bring up a GNU / Linux system > natively. I am concerned that we are increasing the barrier on entry > for such developers. > > It is not the majority of developers (but put another way) we do need > to answer the question whether the dependency on python makes it > harder for folks to bring up a new GNU/Linux system on a new > architecture even though it may make life easier in other areas for > working on the compiler. > > What are the other areas where we envisage using python in the longer > term for GCC ? option processing is one area, where else ? FWIW I have a Python module for working with the output of -fsave- optimization-record (a JSON-based format). It's not clear to me if that should live in the gcc source tree (and thus tarball) or as a part of a 3rd-party repository. Related to that, I'd like to use Python in the testsuite, for verifying the output of -fsave-optimization-record. See https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01546.html for more info on both of these. Dave > > Obviously if you're bootstrapping core packages and their build > > dependencies, use in glibc is more or less equivalent to use in > > GCC. (But > > if build dependencies include those involved in testing, you > > already have > > python as one for glibc, and Tcl for GCC, for example.) > > This implies that the decision for glibc has been made. while you > imply above that the discussion is still on going ? > > regards > Ramana > > > > > > > Joseph S. Myers > > jos...@codesourcery.com
"fall-through" errors
../../autoopts/makeshell.c: In function ‘text_to_var’:
../../autoopts/makeshell.c:324:14: error: this statement may fall
through [-Werror=implicit-fallthrough=]
(*(opts->pUsageProc))(opts, EXIT_SUCCESS);
~^~~~
This warning goes away if the comment "/* FALLTHROUGH */ is present.
You are missing a condition:
switch (which) {
case TT_LONGUSAGE:
(*(opts->pUsageProc))(opts, EXIT_SUCCESS);
/* NOTREACHED */
Please add the exception for a "/* NOTREACHED */" comment. Thank you.
Re: "fall-through" errors
On Sat, Jul 28, 2018 at 10:22:35AM -0700, Bruce Korb wrote:
> ../../autoopts/makeshell.c: In function ‘text_to_var’:
> ../../autoopts/makeshell.c:324:14: error: this statement may fall
> through [-Werror=implicit-fallthrough=]
> (*(opts->pUsageProc))(opts, EXIT_SUCCESS);
> ~^~~~
>
> This warning goes away if the comment "/* FALLTHROUGH */ is present.
> You are missing a condition:
>
> switch (which) {
> case TT_LONGUSAGE:
> (*(opts->pUsageProc))(opts, EXIT_SUCCESS);
> /* NOTREACHED */
>
> Please add the exception for a "/* NOTREACHED */" comment. Thank you.
NOTREACHED means something different, and I don't think we want to add
support for this when we already support a way (including a standard way) to
mark function pointers noreturn (noreturn attribute, _Noreturn in C).
Or you can use -Wimplicit-fallthrough=1 where any kind of comment no matter
what you say there will disable the implicit fallthrough warning.
Jakub
Re: "fall-through" errors
On Sat, Jul 28, 2018 at 10:44 AM Jakub Jelinek wrote:
>
> On Sat, Jul 28, 2018 at 10:22:35AM -0700, Bruce Korb wrote:
> > ../../autoopts/makeshell.c: In function ‘text_to_var’:
> > ../../autoopts/makeshell.c:324:14: error: this statement may fall
> > through [-Werror=implicit-fallthrough=]
> > (*(opts->pUsageProc))(opts, EXIT_SUCCESS);
> > ~^~~~
> >
> > This warning goes away if the comment "/* FALLTHROUGH */ is present.
> > You are missing a condition:
> >
> > switch (which) {
> > case TT_LONGUSAGE:
> > (*(opts->pUsageProc))(opts, EXIT_SUCCESS);
> > /* NOTREACHED */
> >
> > Please add the exception for a "/* NOTREACHED */" comment. Thank you.
>
> NOTREACHED means something different, and I don't think we want to add
> support for this when we already support a way (including a standard way) to
> mark function pointers noreturn (noreturn attribute, _Noreturn in C).
> Or you can use -Wimplicit-fallthrough=1 where any kind of comment no matter
> what you say there will disable the implicit fallthrough warning.
Messing with "noreturn" means messing with autoconf configury and you have no
idea how much I have always hated that horrific environment. Using the
"implicit-fallthrough=1" thingy means the same thing, but making sure it is GCC
and not Clang. That is why using the "obvious" implication that if a function
does not return, then you won't "accidentally" fall through either. Rather than
mess with all that, do both: /* FALLTHROUGH */ /* NOTREACHED */
I think it would be good to reconsider NOTREACHED. Once upon a time,
I segregated out -Wformat-contains-nul. I could offer again, but it
would be a long
time for the round tuit and it would be hard for me.
Re: "fall-through" errors
On Sat, Jul 28, 2018 at 10:56:24AM -0700, Bruce Korb wrote: > > NOTREACHED means something different, and I don't think we want to add > > support for this when we already support a way (including a standard way) to > > mark function pointers noreturn (noreturn attribute, _Noreturn in C). > > Or you can use -Wimplicit-fallthrough=1 where any kind of comment no matter > > what you say there will disable the implicit fallthrough warning. > > Messing with "noreturn" means messing with autoconf configury and you have no > idea how much I have always hated that horrific environment. Using the > "implicit-fallthrough=1" thingy means the same thing, but making sure it is > GCC > and not Clang. That is why using the "obvious" implication that if a function > does not return, then you won't "accidentally" fall through either. Rather > than > mess with all that, do both: /* FALLTHROUGH */ /* NOTREACHED */ > I think it would be good to reconsider NOTREACHED. Once upon a time, > I segregated out -Wformat-contains-nul. I could offer again, but it > would be a long > time for the round tuit and it would be hard for me. You don't need to use configure for this, something like: #ifdef __has_attribute #if __has_attribute(__noreturn__) #define NORETURN __attribute__((__noreturn__)) #endif #endif #ifndef NORETURN #define NORETURN #endif will do. Or glibc headers have: #if defined __GNUC__ && defined __GNUC_MINOR__ # define __GNUC_PREREQ(maj, min) \ ((__GNUC__ << 16) + __GNUC_MINOR__ >= ((maj) << 16) + (min)) #else # define __GNUC_PREREQ(maj, min) 0 #endif #if (!defined _Noreturn \ && (defined __STDC_VERSION__ ? __STDC_VERSION__ : 0) < 201112 \ && !__GNUC_PREREQ (4,7)) # if __GNUC_PREREQ (2,8) # define _Noreturn __attribute__ ((__noreturn__)) # else # define _Noreturn # endif #endif with Jakub
Re: "fall-through" errors
On Sat, Jul 28, 2018 at 11:48 AM Jakub Jelinek wrote: > You don't need to use configure for this, something like: > #ifdef __has_attribute > #if __has_attribute(__noreturn__) > #define NORETURN __attribute__((__noreturn__)) > #endif OK. Thanks. It _will_ be a bit more complicated because my toy emits headers for others to compile. SO, more like: #ifdef NORETURN # define _AO_NoReturn NORETURN #else <> #endif and then emit headers with the _AO_NoReturn marker. namespaces can be a nuisance.
Re: "fall-through" errors
On 7/28/18, Bruce Korb wrote:
> ../../autoopts/makeshell.c: In function ‘text_to_var’:
> ../../autoopts/makeshell.c:324:14: error: this statement may fall
> through [-Werror=implicit-fallthrough=]
> (*(opts->pUsageProc))(opts, EXIT_SUCCESS);
> ~^~~~
>
> This warning goes away if the comment "/* FALLTHROUGH */ is present.
> You are missing a condition:
>
> switch (which) {
> case TT_LONGUSAGE:
> (*(opts->pUsageProc))(opts, EXIT_SUCCESS);
> /* NOTREACHED */
>
> Please add the exception for a "/* NOTREACHED */" comment. Thank you.
>
I suggested gcc start recognizing "/*NOTREACHED*/" in bug 53479
comment 14 but got shot down there, too:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479#c14
Hvala vam što ste nas kontaktirali.
Primili smo vašu poruku i odgovorićemo što pre. Prijatan dan Puno poljubaca, Adminka http://upoznavanje.net";>Upoznavanje.net -- Our mailing address is: upoznavanje.net Durmitorska 15. Sremska mitrovica 22000 Serbia This email is sent exclusively to members of Upoznavanje.net. To unsubscribe please login to your account and select menu: Account -> Privacy Settings, then click on Notifications and uncheck. Ovu poruku ste primili jer ste član sajta Upoznavanje.net Da se odjavite ulogujte se na vaš nalog i iz menija izaberite: Nalog -> Podešavanja privatnosti, zatim idite na Obaveštenja i isključite ih. --
