Do macro_list and fixinc.sh need to be installed?
Hi, Do the macro_list and fixinc.sh files need to be installed? Does anything outside of gcc actually use them? If macro_list is a zero length file, can it be left out of the installation (fixinc.sh seems to test for its presence before trying to use it) or given a blank line? The reason I ask is that rpmlint gives an error on empty files, and macro_list is empty at least for h8300 and sh64. David
Does sysroot-suffix.h need to be installed?
Does sysroot-suffix.h need to be installed even when it's empty? Does anything outside of gcc actually use it? Can it be left out or given a blank line? I notice that not all targets produce such a file. The reason I ask is that rpmlint gives an error on empty files, and sysroot-suffix.h is empty at least for m68k. David
A link on your site is broken
Hi, I've been compiling resources to include in our C Developer resource guide and I came across a link that isn't working on your site. It's on this page: http://gd.tuwien.ac.at/.vhost/www.gnu.org/software/gcc/readings.html I'm getting an error message when I visit this link: http://cm.bell-labs.com/cm/cs/who/dmr/chist.html If you are planning on updating this page on your site, perhaps our guide to C developer resources - http://wiht.link/c-developer would make a suitable replacement. I hope this helps! Tom
Re: A link on your site is broken
On 17 February 2016 at 12:43, Tom Wilcox wrote: > Hi, > > I've been compiling resources to include in our C Developer resource guide > and I came across a link that isn't working on your site. > > It's on this page: > http://gd.tuwien.ac.at/.vhost/www.gnu.org/software/gcc/readings.html That's not our site. The link is broken on our own copy, but the correct URL is https://www.bell-labs.com/usr/dmr/www/chist.html not your SEO attempt :-)
Re: A link on your site is broken
On 17 February 2016 at 13:28, Jonathan Wakely wrote: > On 17 February 2016 at 12:43, Tom Wilcox wrote: >> Hi, >> >> I've been compiling resources to include in our C Developer resource guide >> and I came across a link that isn't working on your site. >> >> It's on this page: >> http://gd.tuwien.ac.at/.vhost/www.gnu.org/software/gcc/readings.html It's now fixed with the patch at https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01167.html Thanks for letting us know.
Help with building MEM_REF node
Hello,
I inserted a new local var decl in gimple, a pointer which is
malloc'ed and now I am trying to read/write in that memory.
int *mumu;
mumu = malloc ( 40 * sizeof (int));
mumu[1] = 10;
The following statement: mumu[1] = 10; which should look like this
MEM[(int *)mumu_10 + 4B] = 10;
for me, looks like:
MEM[(int * *)mumu_10 + 4B] = 10;
This is the variable insertion:
tree vardecl = build_decl (DECL_SOURCE_LOCATION (current_function_decl),
VAR_DECL, get_identifier ("mumu"),
integer_ptr_type_node);
TREE_ADDRESSABLE (vardecl) = 1;
DECL_CONTEXT (vardecl) = current_function_decl;
TREE_USED (vardecl) = 1;
add_local_decl (cfun, vardecl);
Then I insert the malloc call:
tree fn_ptr = make_ssa_name (vardecl);
fn = builtin_decl_explicit (BUILT_IN_MALLOC);
size = build_int_cst (integer_type_node, 40 * sizeof(int)); // testing purpose
gimple *malloc_stmt = gimple_build_call (fn, 1, size);
gimple_call_set_lhs (malloc_stmt, fn_ptr);
gsi_insert_before (&gsi, malloc_stmt, GSI_SAME_STMT);
And then I try to build a mem_ref to the pointer ssa:
tree mem_ref = fold_build2 (MEM_REF, TREE_TYPE (fn_ptr), fn_ptr,
build_int_cst (build_pointer_type (TREE_TYPE (fn_ptr)), 4));
gimple *stmt = gimple_build_assign (mem_ref, build_int_cst
(integer_type_node,10));
gsi_insert_after (&gsi, stmt, GSI_SAME_STMT);
If i use build2() instead of fold_build2() compilation fails with
error: non-trivial conversion at assignment
void *
int
# .MEM_12 = VDEF <.MEM_2>
MEM[(int * *)mumu_10 + 4B] = 10;
I am a newbie to gcc development, any info is appreciated.
Thanks,
Cristina
Manipulating bit fields is behaving inconsistently
When I shift a bit field in an expression small bit fields behave
one way and large bit fields another. I'm using gcc 5.3.0 on Arch Linux:
$ gcc --version
gcc (GCC) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I've created the following example:
#include
struct fields {
long long unsigned f0:12;
long long unsigned f1:52;
} __attribute__((__packed__));
struct fields x = { .f0 = 0xFFF, .f1 = 0xF };
long long unsigned g0;
long long unsigned g1;
void main(void) {
g0 = x.f0 << 1;
g1 = x.f1 << 1;
printf("x.f0=0x%llx\n", x.f0);
printf(" g0=0x%llx expect 0x1ffe\n", g0);
printf("x.f1=0x%llx\n", x.f1);
printf(" g1=0x%llx expect 0x1e\n", g1);
}
The output is:
$ gcc -m64 main.c -o main ; ./main
x.f0=0xfff
g0=0x1ffe expect 0x1ffe
x.f1=0xf
g1=0xe expect 0x1e
As you can see when shifting the f0, which is 12 bits, the
most significant bit it is seen in the result. But when shifting f1,
which is 52 bits, it is lost.
Looking at the generated code the difference in output is
because in g0 = x.f0 << 1 the and operation is done before the "shift left"
using add %eax, %eax. Where as with g1 = x.f1 << 1 the and operation
is done after the "shift left" using add %rax, %rax".
00400506 :
400506: 55 push %rbp
400507: 48 89 e5 mov%rsp,%rbp
40050a: 0f b7 05 f7 04 20 00 movzwl 0x2004f7(%rip),%eax# 600a08
400511: 66 25 ff 0f and$0xfff,%ax
400515: 0f b7 c0 movzwl %ax,%eax
400518: 01 c0 add%eax,%eax
40051a: 48 98 cltq
40051c: 48 89 05 fd 04 20 00 mov%rax,0x2004fd(%rip)# 600a20
400523: 48 8b 05 de 04 20 00 mov0x2004de(%rip),%rax# 600a08
40052a: 48 c1 e8 0c shr$0xc,%rax
40052e: 48 01 c0 add%rax,%rax
400531: 48 ba ff ff ff ff ff movabs $0xf,%rdx
400538: ff 0f 00
40053b: 48 21 d0 and%rdx,%rax
40053e: 48 89 05 d3 04 20 00 mov%rax,0x2004d3(%rip)# 600a18
It feels wrong that they would behave differently, is this really
correct behavior?
-- Wink
Re: Do macro_list and fixinc.sh need to be installed?
On 02/17/2016 04:20 AM, David Howells wrote: Hi, Do the macro_list and fixinc.sh files need to be installed? Does anything outside of gcc actually use them? If macro_list is a zero length file, can it be left out of the installation (fixinc.sh seems to test for its presence before trying to use it) or given a blank line? The reason I ask is that rpmlint gives an error on empty files, and macro_list is empty at least for h8300 and sh64. fixinc.sh should depend on your deployment model. Typically fixinc.sh is run during the build process to address certain deficiencies in the system header files. THe fixed includes would be then installed into a gcc private directory. You could have a deployment model where RPMs provide the compilers, but fixinc is run during rpm installation. This would make more sense for cross compilers or when the rpms provide binaries which run on many different systems which might have slight differences in their header files. macro_list, I believe is used by the fixinc procedure. So if you have a deployment model where you're running fixincludes at rpm installation time, then you'll want to include macro_list. Frankly these rpmlint things seem like more trouble then they're worth. There's good reasons why a package might ship empty files. jeff
Re: Does sysroot-suffix.h need to be installed?
On 02/17/2016 04:23 AM, David Howells wrote: Does sysroot-suffix.h need to be installed even when it's empty? Does anything outside of gcc actually use it? Can it be left out or given a blank line? I notice that not all targets produce such a file. The reason I ask is that rpmlint gives an error on empty files, and sysroot-suffix.h is empty at least for m68k. I would think the safest thing to do would be to make it a blank line. jeff
gcc-4.9-20160217 is now available
Snapshot gcc-4.9-20160217 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160217/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 233508 You'll find: gcc-4.9-20160217.tar.bz2 Complete GCC MD5=a95912b2630a2d09f87ae38683ecea49 SHA1=71bf9b985d920f4644d5635c1a0f6a689d4c0891 Diffs from 4.9-20160210 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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.
Re: nonnull, -Wnonnull, and do/while
> On Tue, Feb 16, 2016 at 11:04:38AM +0100, Marek Polacek wrote: >> On Tue, Feb 16, 2016 at 10:43:08AM +0100, Stefan Sobernig wrote: >>> Under a recent gcc 6 [*], we run into -Wnonnull warnings using the >>> nonnull attribute: >> >> Yes, this warning has been enhanced for GCC 6. >> >>> test.c: In function 'f': >>> test.c:16:14: warning: nonnull argument 's' compared to NULL [-Wnonnull] >>>} while (s != NULL); >>> >>> Am I missing sth.? Is this a false positive? >> >> Well, it's just that "s" has the nonnull attribute so the compiler thinks it >> should never be null in which case comparing it to null should be redundant. >> Doesn't seem like a false positive to me, but maybe someone else feels >> otherwise. > > The nonnull attribute should be solely about the value that is passed to the > function, it doesn't tell anything about the value of the argument after > it is changed. So IMHO this warning change should be reverted and instead > we should warn somewhere soon after going into SSA, only when > the SSA_NAME_IS_DEFAULT_DEF of the PARM_DECL which has non-NULL attribute > is compared to NULL. Am I supposed to file this as a bug report then, for the records? Or will it be taken care of ... Thx, Stefan
Re: nonnull, -Wnonnull, and do/while
On Thu, 2016-02-18 at 00:21 +0100, Stefan Sobernig wrote: > Am I supposed to file this as a bug report then, for the records? Or > will it be taken care of ... Jakub already did all the work. Bug filed, patch written, reviewed and committed. Plus followup fixup. He is amazing: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69835 https://gcc.gnu.org/ml/gcc-patches/2016-02/threads.html#01082 https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01203.html
