RFC: Make builtin types only valid for some target features
Hi, I'm working to find one solution for PR106736, which requires us to make some built-in types only valid for some target features, and emit error messages for the types when the condition isn't satisfied. A straightforward idea is to guard the registry of built-in type under the corresponding target feature. But as Peter pointed out in the PR, it doesn't work, as these built-in types are used by some built-in functions which are required to be initialized always regardless of target features, in order to support target pragma/attribute. For the validity checking on the built-in functions, it happens during expanding the built-in functions calls, since till then we already know the exact information on specific target feature. One idea is to support built-in type checking in a similar way, to check if all used type_decl (built-in type) are valid or not somewhere. I hacked to simply check currently expanding gimple stmt is gassign and further check the types of its operands, it did work but checking gassign isn't enough. Maybe I missed something, there seems not an efficient way for a full check IMHO. So I tried another direction, which was inspired by the existing attribute altivec, to introduce an artificial type attribute and the corresponding macro definition, during attribute handling it can check target option node about target feature for validity. The advantage is that the checking happens in FE, so it reports error early, and it doesn't need a later full checking on types. But with some prototyping work, I found one issue that it doesn't support param decl well, since the handling on attributes of function decl happens after that on attributes of param decl, so we aren't able to get exact target feature information when handling the attributes on param decl. It requires front-end needs to change the parsing order, I guess it's not acceptable? So I planed to give up and return to the previous direction. Does the former idea sound good? Any comments/suggestions, and other ideas? Thanks a lot in advance! BR, Kewen
Feature request: Warning when .c file gets #include'd
Hi, I've met a guy that is learning C and got stuck when the linker produced a screenful of messages about that he did something define multiple times. The cause of the problem was trivial: He did ``#include "something.c"'' in his code. In the past, I also did this thing multiple times and I would appreciate a warning produced by the gcc when compiling C/C++ file that includes a file ending in .c, .cx, .cpp or .cxx. What do you think about that? I would prefer to make this enabled when -Wextra is used. Based on my past experience with using .c files in the include directive, I can think of these problems. - Sometimes, I want to include a file that is definitely not a header, but also it is not a stand-alone source file. I personally prefer using .inc suffix, but some people possibly terminate the file names with .c suffix like a source file. Example: list of enum fields included from a separate file that was generated by a script - In some projects, someone can deliberately want to include another source file. For example, this can happen when doing unit tests and you do not want to specify the source file name on the command line. If you accept that, I can try to implement that. (That would be my first contribution to this project and I do not know gcc codebase, but it looks like a relatively simple change.) Do you think that it would need a copyright assignment? Thanks, Jiří
Re: Feature request: Warning when .c file gets #include'd
On Fri, Dec 02, 2022 at 03:57:44PM +0100, Jiří Wolker via Gcc wrote: > > Hi, > > I've met a guy that is learning C and got stuck when the linker produced > a screenful of messages about that he did something define multiple > times. The cause of the problem was trivial: > > He did ``#include "something.c"'' in his code. > > In the past, I also did this thing multiple times and I would appreciate > a warning produced by the gcc when compiling C/C++ file that includes a > file ending in .c, .cx, .cpp or .cxx. > > What do you think about that? > > I would prefer to make this enabled when -Wextra is used. The problem is that a lot of beginners don't use -Wextra, so the warning wouldn't be displayed anyway. > Based on my past experience with using .c files in the include > directive, I can think of these problems. > > - Sometimes, I want to include a file that is definitely not a header, > but also it is not a stand-alone source file. I personally prefer > using .inc suffix, but some people possibly terminate the file names > with .c suffix like a source file. > > Example: list of enum fields included from a separate file that was > generated by a script > > - In some projects, someone can deliberately want to include another > source file. For example, this can happen when doing unit tests and > you do not want to specify the source file name on the command line. Indeed, e.g. elfutils uses this a lot: #define LIBELFBITS 64 #include "elf32_xlatetom.c" We use including .c in our testsuite a lot as well. So I'm afraid this would get -1 from me personally, sorry. > If you accept that, I can try to implement that. (That would be my first > contribution to this project and I do not know gcc codebase, but it > looks like a relatively simple change.) Do you think that it would need > a copyright assignment? I think it would. Thanks, Marek
Re: Feature request: Warning when .c file gets #include'd
On Fri, 2 Dec 2022 at 15:47, Marek Polacek wrote: > > On Fri, Dec 02, 2022 at 03:57:44PM +0100, Jiří Wolker via Gcc wrote: > > > > Hi, > > > > I've met a guy that is learning C and got stuck when the linker produced > > a screenful of messages about that he did something define multiple > > times. The cause of the problem was trivial: > > > > He did ``#include "something.c"'' in his code. > > > > In the past, I also did this thing multiple times and I would appreciate > > a warning produced by the gcc when compiling C/C++ file that includes a > > file ending in .c, .cx, .cpp or .cxx. > > > > What do you think about that? > > > > I would prefer to make this enabled when -Wextra is used. > > The problem is that a lot of beginners don't use -Wextra, so the > warning wouldn't be displayed anyway. Right. If the fact you're including a non-header file (which is **never** done by any tutorials or example code **anywhere**) isn't enough of a discouragement, a warning that nobody ever sees isn't going to help. And there are lots of ways to get the same linker errors. Defining functions in a header file and not making them 'inline' (or 'static inline' or whatever C99 says is the right way to do that) will produce the same results, but your warning wouldn't help. > > Based on my past experience with using .c files in the include > > directive, I can think of these problems. > > > > - Sometimes, I want to include a file that is definitely not a header, > > but also it is not a stand-alone source file. I personally prefer > > using .inc suffix, but some people possibly terminate the file names > > with .c suffix like a source file. > > > > Example: list of enum fields included from a separate file that was > > generated by a script > > > > - In some projects, someone can deliberately want to include another > > source file. For example, this can happen when doing unit tests and > > you do not want to specify the source file name on the command line. > > Indeed, e.g. elfutils uses this a lot: > #define LIBELFBITS 64 > #include "elf32_xlatetom.c" > > We use including .c in our testsuite a lot as well. Libstdc++ does it in several places: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/src/c%2B%2B11/cow-sstream-inst.cc;h=8839f4a6f75d608ec911fb99098f5e15ab71f162;hb=HEAD#l29
RE: Gcc - Animation Software
Hi Gcc, Can you please drop me a note if you caught the email below ? Shall i get back with more info on this ? Awaiting your response, Emma From: Kathy Wood Sent: Thursday, November 17, 2022 6:33 PM To: 'Gcc' Subject: Gcc - Animation Software Importance: High Hi Gcc , Im emailing you to see if you would be interested in the data list of Animation Software Users, Clients and Customers at discounted price? Henceforth, we maintain a valid and updated data list of the following technology users: * Adobe After Effects * Renderforest * Animaker * Unity * 3ds Max Design * Blender * Powtoon * KeyShot * Moho Pro * CelAction2D * Autodesk Maya * Cartoon Animator 4 Ø Clip Studio Paint, many more. Kindly let me know if youd like to see the more info on this ? -- Thanks & Awaiting youre response, Kathy Wood | Demand Generation Expert Please reply with an "skip" if you are not interested
Re: access to include path in front end
On Thu, 1 Dec 2022 17:14:31 + (UTC)
Michael Matz wrote:
> > 3. Correct the entries in the default_compilers array. Currently I
> > have in cobol/lang-specs.h:
> >
> > {".cob", "@cobol", 0, 0, 0},
> > {".COB", "@cobol", 0, 0, 0},
> > {".cbl", "@cobol", 0, 0, 0},
> > {".CBL", "@cobol", 0, 0, 0},
> > {"@cobol",
> > "cobol1 %i %(cc1_options) %{!fsyntax-only:%(invoke_as)}",
> > 0, 0, 0},
>
> It misses %(cpp_unique_options) which was the reason why your -I
> arguments weren't passed to cobol1.
If I understood you correctly, I don't need to modify gcc.cc. I only
need to modify cobol/lang-specs.h, which I've done. But that's
evidently not all I need to do, because it doesn't seem to work.
The last element in the fragment in cobol/lang-specs.h is now:
{"@cobol",
"cobol1 %i %(cc1_options) %{!fsyntax-only:%(invoke_as)} "
"%(cpp_unique_options) ",
0, 0, 0},
(using string constant concatenation). That's the only change I made,
so far, because everything we said (AIUI) boiled down to, "just add
cpp_unique_options to your spec string".
> You would just your new %(cobol_options), or simply '%{v} %{I*}'
> directly in addition to cc1_options.
I didn't do that. IIUC, the 2nd element in the struct can be a string
constant or the address of a char* variable. So, I chose a string
constant.
Getting wiser with age, I used -### to dump the cobol1 command
line. It appears to be consistent with observed behavior: when I run
under gdb and stop at the cobol1::main function, argc is 14, and argv
does not include the -I option.
The -### output reports the cobol1 command line (as 14 strings,
exactly) on line 10. In additon to what was supplied (by me, invoking
gcobol), it shows:
-quiet
-dumpdir o- -dumpbase csytst10.cbl
-dumpbase-ext .cbl
"-main=gcc/cobol/prim/samples/CUBES/cobol/csytst10.cbl"
"-mtune=generic"
"-march=x86-64"
-o /tmp/ccLYrc6D.s
The -main I can explain later if it matters. The others are magic I
don't understand and don't think matter, but I show them so you know.
Note that I'm invoking gcobol from the build tree, using -B (among
others) to make it DTRT.
I see the -B and -I options, and others, with their arguments, contained
in COLLECT_GCC_OPTIONS on lines 9 and 11. I guess that represents an
environment string? Or, anyway, a string that holds the options that
will be passed to collect2?
The contents of COLLECT_GCC_OPTIONS appear to be a superset of the
options supplied on the cobol1 command line.
It would seem the single change I made is less than the minimum
required, but I confess I've lost track of why anything more is
needed.
--jkl
gcc-11-20221202 is now available
Snapshot gcc-11-20221202 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20221202/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision 0ccdba3e5e7451b07d9858a8650478c5fb94aad1 You'll find: gcc-11-20221202.tar.xz Complete GCC SHA256=8c09fdbb280cf95c4dabd15cf9e26648d74053a0bc65f2e8179d5e746d21da06 SHA1=d5f396c0d23c7410f98a6cf29f359c301f8e329a Diffs from 11-20221125 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
