[Bug c/27898] New: Compile failure with --combine and anonymous structures

[dwmw2 at infradead dot org]

$ cat foobar.c
union u {
struct {
int i;
};
};

extern int somefunc(union u *);
$ gcc --combine -c foobar.c foobar.c
foobar.c:8: error: conflicting types for 'somefunc'
foobar.c:8: error: previous declaration of 'somefunc' was here

gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)

Happens on both PowerPC and i386. If the internal structure is made
non-anonymous, it compiles.


-- 
   Summary: Compile failure with --combine and anonymous structures
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: dwmw2 at infradead dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27898

[Bug c/27899] New: Compile warning with --combine and global register variables.

[dwmw2 at infradead dot org]

$ echo 'register struct foo *current asm ("r2");' > foobar.c
$ gcc --combine foobar.c foobar.c -c 
foobar.c:1: warning: register used for two global register variables


Is this warning harmless? It's still going to do the right thing, yes?

Also happens on i386 (with s/r2/ebx/)
gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)


-- 
   Summary: Compile warning with --combine and global register
variables.
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: dwmw2 at infradead dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27899

[Bug c/28706] New: Compile failure with --combine and explicitly aligned structures

[dwmw2 at infradead dot org]

$ cat foo.c
struct rb_node
{
} __attribute__((aligned(sizeof(long;

extern struct rb_node *rb_prev(struct rb_node *);
extern struct rb_node *rb_prev(struct rb_node *);
 $ gcc -c --combine foo.c foo.c
foo.c:6: error: conflicting types for ‘rb_prev’
foo.c:5: error: previous declaration of ‘rb_prev’ was here

gcc version 4.1.1 20060525 (Red Hat 4.1.1-1.pr27898)

Removing the explicit alignment fixes the problem.


-- 
   Summary: Compile failure with --combine and explicitly aligned
structures
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwmw2 at infradead dot org
 GCC build triplet: powerpc-linux-gnu
  GCC host triplet: powerpc-linux-gnu
GCC target triplet: powerpc-linux-gnu, i386-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28706

[Bug c/27898] Compile failure with --combine and anonymous structures

[dwmw2 at infradead dot org]

--- Comment #3 from dwmw2 at infradead dot org  2006-08-13 10:30 ---
That simple test case seems to have been fixed with your patch -- thanks.
Next failure reported as PR28706.

Full test cases in Red Hat bug #194327 at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194327


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27898

[Bug c/28712] New: Compile failure with --combine and packed structures.

[dwmw2 at infradead dot org]

$ cat foo.i
struct tss_struct;

extern struct tss_struct *doublefault_tss;

struct tss_struct {
} __attribute__((packed));

 $ gcc -c --combine foo.i foo.i
 $ gcc -c --combine foo.i foo.i foo.i
foo.i:3: error: conflicting types for ‘doublefault_tss’
foo.i:3: error: previous declaration of ‘doublefault_tss’ was here

Removing the packed attribute, or compiling only _two_ of them together, makes
it work.

Seen with ppc->i686 GCC 4.1.0 and also
Fedora PowerPC gcc version 4.1.1 20060525 (Red Hat 4.1.1-1.pr27898)

(Both with Alex's patch for pr27898).


-- 
   Summary: Compile failure with --combine and packed structures.
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwmw2 at infradead dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28712

[Bug web/28714] New: Bugzilla mail sent from invalid address

[dwmw2 at infradead dot org]

(And bugzilla needs a 'bugzilla' product because this shouldn't really be filed
against gcc itself).

The mails sent by GCC bugzilla have a return address of
'[EMAIL PROTECTED]' but that address fails basic sender verification
because gcc.gnu.org doesn't actually accept bounces to that address:

MAIL FROM:<>
250 <>, sender OK - how exciting to get mail from you!
RCPT TO:<[EMAIL PROTECTED]>
550 Sorry, there is no mailbox for [EMAIL PROTECTED] here.  Contact
[EMAIL PROTECTED] if you think there is a problem.
quit
221 sourceware.org closing connection. Have a wonderful day.


Thus, I don't get any mail from GCC bugzilla -- it all gets rejected as spam:

2006-08-14 08:58:11 H=sourceware.org [209.132.176.174] sender verify fail for
<[EMAIL PROTECTED]>
2006-08-14 08:58:11 H=sourceware.org [209.132.176.174]
F=<[EMAIL PROTECTED]> rejected RCPT <[EMAIL PROTECTED]>: Sender
verify failed


-- 
   Summary: Bugzilla mail sent from invalid address
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
    AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwmw2 at infradead dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28714

[Bug c/28744] New: externally_visible attribute not effective with prior declaration of symbol.

[dwmw2 at infradead dot org]

$ cat foo.c
extern char *bar1 __attribute__((externally_visible));
char *bar1;

extern char *bar2 __attribute__((externally_visible));
char *bar2 __attribute__((externally_visible));

extern char *bar3;
char *bar3 __attribute__((externally_visible));

char *bar4 __attribute__((externally_visible));

char *bar5;
extern char *bar5 __attribute__((externally_visible));
 $ gcc -O -fwhole-program -c -o foo.o foo.c
foo.c:1: warning: ‘externally_visible’ attribute have effect only on public
objects
foo.c:4: warning: ‘externally_visible’ attribute have effect only on public
objects
foo.c:13: warning: ‘externally_visible’ attribute have effect only on public
objects
 $ nm -a foo.o | grep bar
0004 C bar4

All five of these variables ought to be externally visible.
Note -fwhole-program.

Seen with:
(ppc) gcc version 4.1.1 20060525 (Red Hat 4.1.1-1.pr27898)
(ppc->i686) gcc version 4.1.0


-- 
   Summary: externally_visible attribute not effective with prior
declaration of symbol.
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwmw2 at infradead dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28744

[Bug c/28755] New: duplicate members of arrays

[dwmw2 at infradead dot org]

See attached test case. Observe the number of times certain lines of the
'vesa_modes' array are emitted. This isn't particularly optimal, especially as
it happens even with -Os.

 $ make
cc -Os -c -o fbmon.o fbmon.i -save-temps
grep 39682 fbmon.s
.long   39682
.long   39682


-- 
   Summary: duplicate members of arrays
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: dwmw2 at infradead dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28755

[Bug c/28755] duplicate members of arrays

[dwmw2 at infradead dot org]

--- Comment #1 from dwmw2 at infradead dot org  2006-08-16 17:29 ---
Created an attachment (id=12084)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12084&action=view)
test case


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28755

[Bug web/28714] Bugzilla mail sent from invalid address

[dwmw2 at infradead dot org]

--- Comment #2 from dwmw2 at infradead dot org  2006-08-16 17:33 ---
Mail should be sent from a valid address, because sending from an _invalid_
address can fall foul of antispam protection, as in the example shown.

Since the apparent sender does not accept bounces, the mail is rejected.

Just accepting (and blackholing) bounces to [EMAIL PROTECTED] would
fix this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28714

[Bug c/28744] externally_visible attribute not effective with prior declaration of symbol.

[dwmw2 at infradead dot org]

--- Comment #6 from dwmw2 at infradead dot org  2006-08-16 18:11 ---
I don't think it's working right even with the new patch. I'll verify tomorrow,
and make sure I have all the correct patches included in my build. The point at
which I copied my ppc-cross-i386 'cc1' into
/usr/libexec/gcc/ppc64-redhat-linux/4.1.1/cc1 and then wondered why native GCC
wouldn't work any more was probably the point at which I should stop working on
this for today.

My hack at http://david.woodhou.se/pr27844.patch is working around the problem
for now, so I have least been able to link a kernel.

I'm building a Linux kernel with
http://david.woodhou.se/linux-combine-build.patch applied. It shouldn't matter
much, but the git tree it's applied to is
git://git.infradead.org/~jcrouse/geode.git and the config is
http://david.woodhou.se/olpc-config

The failure mode with GCC 4.1.0, the patch from
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00993.html and also the patch in
comment #5 is that some functions aren't available in the final link:

kernel/built-in.o: In function `register_irq_proc':
/pmac/git/geode/kernel/irq/proc.c:128: undefined reference to `proc_mkdir'


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28744

[Bug c/28744] externally_visible attribute not effective with prior declaration of symbol.

[dwmw2 at infradead dot org]

--- Comment #7 from dwmw2 at infradead dot org  2006-08-17 09:16 ---
The one with proc_mkdir was because the EXPORT_SYMBOL is in a different file to
the original function -- although my version was working correctly, I'm willing
to deal with that case.

The symbol 'proc_root' is also missing though. Simple test case:

 $ cat foo.c
extern int foo;

int __attribute__((externally_visible)) *bar(void)
{
return &foo;
}
pmac /home/dwmw2 $ cat bar.c

int foo __attribute__((externally_visible)) = 42;
 $ gcc -fwhole-program --combine -Os -c -ofoo.o foo.c bar.c
 $ nm -a foo.o  T bar  b .bss
 n .comment
 d .data
 d foo.1277
 a foo.c
 n .note.GNU-stack
 t .text

Note 'd foo.1277' instead of the expected 'D foo'. Giving foo.c and bar.c in
the opposite order on the command line 'fixes' this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28744

[Bug web/28714] Bugzilla mail sent from invalid address

[dwmw2 at infradead dot org]

--- Comment #5 from dwmw2 at infradead dot org  2006-08-18 08:10 ---
Yep, I got the mail. Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28714

[Bug c/28744] externally_visible attribute not effective with prior declaration of symbol.

[dwmw2 at infradead dot org]

--- Comment #10 from dwmw2 at infradead dot org  2006-08-18 11:11 ---
I've hacked around this for now by reverting the patch for PR25795 and doing
this instead:

--- gcc/c-decl.c~   2006-01-19 23:48:07.0 +
+++ gcc/c-decl.c2006-08-15 21:43:43.0 +0100
@@ -1660,6 +1660,25 @@ merge_decls (tree newdecl, tree olddecl,
   if (TREE_DEPRECATED (newdecl))
 TREE_DEPRECATED (olddecl) = 1;

+  if (TREE_CODE (newdecl) == FUNCTION_DECL)
+{
+  struct cgraph_node *n = cgraph_node (newdecl);
+  if (n->local.externally_visible)
+   {
+  struct cgraph_node *o = cgraph_node (olddecl);
+  o->local.externally_visible = true;
+   }
+}
+  else if (TREE_CODE (newdecl) == VAR_DECL)
+{
+  struct cgraph_varpool_node *n = cgraph_varpool_node (newdecl);
+  if (n->externally_visible)
+   {
+ struct cgraph_varpool_node *o = cgraph_varpool_node (olddecl);
+ o->externally_visible = true;
+   }
+}
+
   /* Keep source location of definition rather than declaration and of
  prototype rather than non-prototype unless that prototype is
  built-in.  */
--- gcc/c-common.c~ 2006-08-18 10:35:10.0 +0100
+++ gcc/c-common.c  2006-08-18 10:52:18.0 +0100
@@ -4243,7 +4243,7 @@ handle_externally_visible_attribute (tre
 {
   tree node = *pnode;

-  if ((!TREE_STATIC (node) && TREE_CODE (node) != FUNCTION_DECL)
+  if (0 && (!TREE_STATIC (node) && TREE_CODE (node) != FUNCTION_DECL)
   || !TREE_PUBLIC (node))
 {
   warning (OPT_Wattributes,


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28744

[Bug c/28779] New: internal compiler error: in cgraph_estimate_size_after_inlining, at ipa-inline.c:106

[dwmw2 at infradead dot org]

See attached test case (ignore the warning; cf. pr27899):
/opt/crosstool/gcc-4.1.0-glibc-2.3.6/i686-unknown-linux-gnu/bin/i686-unknown-linux-gnu-gcc-4.1.0
-c -o e1000.o e1000_hw.i e1000_main.i --combine -fwhole-program -Os
In file included from /pmac/git/geode/include/linux/thread_info.h:22,
 from /pmac/git/geode/include/linux/preempt.h:10,
 from /pmac/git/geode/include/linux/spinlock.h:50,
 from /pmac/git/geode/include/linux/capability.h:46,
 from /pmac/git/geode/include/linux/sched.h:45,
 from /pmac/git/geode/include/linux/module.h:10,
 from /pmac/git/geode/drivers/net/e1000/e1000.h:38,
 from /pmac/git/geode/drivers/net/e1000/e1000_main.c:31:
include2/asm/thread_info.h:88: warning: register used for two global register
variables
/pmac/git/geode/drivers/net/e1000/e1000_main.c:4860: internal compiler error:
in cgraph_estimate_size_after_inlining, at ipa-inline.c:106
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

Seen with 4.1.0 i386 (with the set of patches at
http://david.woodhou.se/combine/gcc-patches since otherwise it dies a lot
earlier) and also with Red Hat's 4.1.1 branch with same patches, for i386 and
PowerPC. The attached preprocessed source will be i386.

Sorry, I'm not sure how to cut the test case down to something smaller.


-- 
   Summary: internal compiler error: in
cgraph_estimate_size_after_inlining, at ipa-inline.c:106
   Product: gcc
   Version: 3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: dwmw2 at infradead dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779

[Bug c/28779] internal compiler error: in cgraph_estimate_size_after_inlining, at ipa-inline.c:106

[dwmw2 at infradead dot org]

--- Comment #1 from dwmw2 at infradead dot org  2006-08-19 09:26 ---
Created an attachment (id=12095)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12095&action=view)
Test case.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779

[Bug c/28779] internal compiler error: in cgraph_estimate_size_after_inlining, at ipa-inline.c:106

[dwmw2 at infradead dot org]

--- Comment #2 from dwmw2 at infradead dot org  2006-08-19 09:29 ---
Doesn't happen with '-O', or '-O2'. Only with '-Os' or '-O3'.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779

[Bug middle-end/28779] internal compiler error: in cgraph_estimate_size_after_inlining, at ipa-inline.c:106

[dwmw2 at infradead dot org]

--- Comment #4 from dwmw2 at infradead dot org  2006-08-19 15:52 ---

> /pmac/git/geode/include/linux/page-flags.h:252: error: conflicting types for
> ‘test_clear_page_dirty’

Sounds like you don't have PR27898 fixed.

With -v ...

/opt/crosstool/gcc-4.1.0-glibc-2.3.6/i686-unknown-linux-gnu/bin/i686-unknown-linux-gnu-gcc-4.1.1
-c -o e1000.o e1000_hw.i e1000_main.i --combine -fwhole-program -v -Os
Using built-in specs.
Target: i686-unknown-linux-gnu
Configured with: ../configure --target=i686-unknown-linux-gnu
--host=powerpc64-redhat-linux
--prefix=/opt/crosstool/gcc-4.1.0-glibc-2.3.6/i686-unknown-linux-gnu
--with-headers=/opt/crosstool/gcc-4.1.0-glibc-2.3.6/i686-unknown-linux-gnu/i686-unknown-linux-gnu/include
--with-local-prefix=/opt/crosstool/gcc-4.1.0-glibc-2.3.6/i686-unknown-linux-gnu/i686-unknown-linux-gnu
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit
--enable-shared --enable-c99 --enable-long-long --enable-languages=c
Thread model: posix
gcc version 4.1.1 20060817 (Red Hat 4.1.1-18)

/opt/crosstool/gcc-4.1.0-glibc-2.3.6/i686-unknown-linux-gnu/libexec/gcc/i686-unknown-linux-gnu/4.1.1/cc1
-fpreprocessed e1000_hw.i e1000_main.i -quiet -dumpbase e1000_hw.i
-mtune=generic -auxbase-strip e1000.o -Os -version -fwhole-program -o
/tmp/ccQKdpY0.s
GNU C version 4.1.1 20060817 (Red Hat 4.1.1-18) (i686-unknown-linux-gnu)
compiled by GNU C version 4.1.1 20060525 (Red Hat 4.1.1-1.pr27898).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4a2b66e229c24ed7405efc929117b7df
In file included from /pmac/git/geode/include/linux/thread_info.h:22,
 from /pmac/git/geode/include/linux/preempt.h:10,
 from /pmac/git/geode/include/linux/spinlock.h:50,
 from /pmac/git/geode/include/linux/capability.h:46,
 from /pmac/git/geode/include/linux/sched.h:45,
 from /pmac/git/geode/include/linux/module.h:10,
 from /pmac/git/geode/drivers/net/e1000/e1000.h:38,
 from /pmac/git/geode/drivers/net/e1000/e1000_main.c:31:
include2/asm/thread_info.h:88: warning: register used for two global register
variables
/pmac/git/geode/drivers/net/e1000/e1000_main.c:4860: internal compiler error:
in cgraph_estimate_size_after_inlining, at ipa-inline.c:106
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla> for instructions.
make: *** [e1000.o] Error 1


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779

[Bug middle-end/20826] [4.0/4.1/4.2 Regression] excessive compiler resource usage

[dwmw2 at infradead dot org]

--- Comment #8 from dwmw2 at infradead dot org  2006-09-21 20:38 ---
Apologies -- GCC bugzilla mail was going missing due to being sent with a bogus
sender address. Will dig out a current test case if it's still an issue.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20826

[Bug c++/20826] New: 4.0 regression: excessive compiler resource usage

[dwmw2 at infradead dot org]

Compiling the attached file with '-fno-enforce-eh-specs -O2' on a 450MHz G4 with
gcc 3.4 takes 30 seconds. Compiling it with gcc 4 on a 1.3GHz G4 takes a number
of hours before failing:
cc1plus: out of memory allocating 1643995136 bytes after a total of 94982144 
bytes

This are both 64-bit-capable toolchains, defaulting to 32-bit output. (Fedora
Core 3 and Fedora Core 4 respectively, on PPC).

-- 
   Summary: 4.0 regression: excessive compiler resource usage
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwmw2 at infradead dot org
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: ppc-redhat-linux
GCC target triplet: ppc64-redhat-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20826

[Bug c++/20826] 4.0 regression: excessive compiler resource usage

[dwmw2 at infradead dot org]

--- Additional Comments From dwmw2 at infradead dot org  2005-04-08 11:34 
---
Created an attachment (id=8564)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8564&action=view)
offending source file


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20826

[Bug target/93654] Inappropriate "-fcf-protection and -mindirect-branch=thunk are incompatible on x86_64" restriction

[dwmw2 at infradead dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654

David Woodhouse  changed:

   What|Removed |Added

 CC||dwmw2 at infradead dot org

--- Comment #1 from David Woodhouse  ---
Indeed. We even changed the ABI of the thunk to be CET-compatible and allow the
'jmp *reg' form instead of being ret-equivalent.

[Bug c/56370] New: RFE: warn on 'foo = realloc(foo, …)'

[dwmw2 at infradead dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56370

 Bug #: 56370
   Summary: RFE: warn on 'foo = realloc(foo, …)'
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dw...@infradead.org


I thought I actually knew C, but it's just been pointed out to me that I have a
habit of doing 'foo = realloc(foo, …)', which causes a memory leak in the
failure case because whatever 'foo' used to point to can never be freed.
Looking around, I see the same bug is fairly common.

It's very rarely sane to assign the return value of realloc() directly to the
same variable which was its first argument. Only when you don't *care* about a
memory leak, or where you have another copy of the pointer that used to be in
'foo' and can still free it.

It would be nice if the compiler would warn about this idiom.

[Bug rtl-optimization/55177] missed optimizations with __builtin_bswap

[dwmw2 at infradead dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177



--- Comment #9 from David Woodhouse  2013-03-08 
12:11:24 UTC ---

This is now enabled in the Linux kernel.



Core patch: http://git.kernel.org/linus/cf66bb93 (in v3.8 but does nothing

there)

x86:http://git.kernel.org/linus/83a57a4d (will be in v3.9)

PowerPC:http://git.kernel.org/linus/fe3955cb (will be in v3.9)



There's an ARM patch which looks like it missed the boat for 3.9 but should

hopefully be in v3.10: https://lkml.org/lkml/2013/2/22/475



On ARM where we have no load-and-swap or store-and-swap primitives we are

already seeing a tiny win. But fixing up more of the missing optimisations

would be good.

[Bug tree-optimization/55177] New: Missed optimisation: bswap, mask with constant, bswap back again.

[dwmw2 at infradead dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177



 Bug #: 55177

   Summary: Missed optimisation: bswap, mask with constant, bswap

back again.

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: dw...@infradead.org





extern int x;



void foo(void)

{

  int a = __builtin_bswap32(x);

  a &= 0x5a5b5c5d;

  x = __builtin_bswap32(a);

}



With GCC 4.7.2 (x86_64 Fedora) this compiles to:

foo:

.LFB0:

.cfi_startproc

movlx(%rip), %eax

bswap%eax

andl$-1515936861, %eax

bswap%eax

movl%eax, x(%rip)

ret

.cfi_endproc





Surely the actual swap should be optimised out, and the 0x5a5b5c5d constant

mask should be swapped instead so we just load, mask with 0x5d5c5b5a and store

without any runtime swapping?



(See also PR42586 which may be related)

[Bug tree-optimization/55177] Missed optimisation: bswap, mask with constant, bswap back again.

[dwmw2 at infradead dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177

--- Comment #1 from David Woodhouse  2012-11-02 
10:45:52 UTC ---
We have a similar issue with:

extern void func(void);
int baz(void)
{
if (__builtin_bswap32(x) & 0x8)
func();
}

baz:
.LFB1:
.cfi_startproc
movlx(%rip), %eax
bswap%eax
testl$524288, %eax
jne.L12
rep
ret
…

Again there's no need for a bswap followed by testing with a constant.

[Bug rtl-optimization/55177] missed optimizations with __builtin_bswap

[dwmw2 at infradead dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177



--- Comment #3 from David Woodhouse  2012-11-02 
17:05:03 UTC ---

The first example isn't *that* dumb, as a cut-down test case of real code which

may look more complex in reality.



If the real code really *is* as simple as my test case, you're right that

perhaps we *could* optimise it ourselves by eschewing the normal accessor

macros for explicit-endian values, and manually byteswapping the constant

instead.



But really, we shouldn't *have* to. The compiler can see what's happening, and

it can deal with it a whole lot better than we can, especially when it comes to

loads and stores. 



Your argument applies just as well to the second test case. I could just

byteswap the constant instead of the variable. But still I shouldn't have to.

[Bug rtl-optimization/55177] missed optimizations with __builtin_bswap

[dwmw2 at infradead dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177

--- Comment #5 from David Woodhouse  2012-11-02 
19:41:28 UTC ---
Indeed. Bear in mind that sometimes we *hide* the actual variable (by prefixing
its name or putting it in a small struct of its own), just to *force* people to
use the appropriate byte-swapping accessor functions/macros. And with good
reason, because people will often forget to handle the endianness issues
otherwise.

So what you describe as 'really dumb' is actually something that we *force*
people to do. We'd be much worse off without it.

Of course, if we could just mark the variable with __attribute__((bigendian))
then perhaps it would all JustWork™ ... but that's a separate discussion ☹

[Bug rtl-optimization/55177] missed optimizations with __builtin_bswap

[dwmw2 at infradead dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177



--- Comment #7 from David Woodhouse  2012-11-08 
14:29:37 UTC ---

Linux kernel patch to use the builtins at

http://marc.info/?l=linux-arch&m=135212414925921&w=2



I think I have the GCC version checks right there, for the availability of the

builtins? That is, __builtin_bswap32() and __builtin_bswap64() since GCC 4.4,

and __builtin_bswap16() since GCC 4.6 on PowerPC or GCC 4.9 on other platforms?

[Bug c/57587] New: RFE: 'maybenull' attribute.

[dwmw2 at infradead dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57587

Bug ID: 57587
   Summary: RFE: 'maybenull' attribute.
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dwmw2 at infradead dot org

I'd like an attribute analogous to __attribute__((nonnull)) for function
arguments, except that it should indicate that an argument is *expected* to be
NULL. Or preferably, it could be applied to a *type* or a function member...

It is common, in glib-based software, to have functions which return
success/failure and also take an *optional* 'GError **' argument which can be
populated with more detailed error information on failure. This error pointer
is usually passed through to inferior functions, and a failure of such a
function will cause the parent function to immediately return 'FALSE', with the
detailed error having already been populated.

However, the 'error' argument may often be NULL, if a failure is not going to
be reported to the user.

It is a common bug, when such a function calls another function, to use the
'error' function to detect whether an error happens — instead of checking the
return value of the function as we should. To make that slightly clearer...

This code bad:

gboolean my_foo(GError **error)
{
my_bar(error);
if (*error)
   return FALSE;

return my_baz(error);
}

This code good:

gboolean my_foo(GError **error)
{
if (!my_bar(error))
return FALSE;

return my_baz(error);
}

This bug is distressingly common. There may be other ways to catch this common
coding error, but if we could ensure that the compiler would *warn* about any
untested assumption that the pointer is non-NULL, that would be useful.

Having it done along the lines of the __attribute__((nonnull)) function
attribute may be simpler, but it would require every function declaration to
carry the attribute. And if we could rely on codemonkeys do to that, we could
probably rely on them to get it right in the first place.

So if there's a way we can mark the *GError* type with an attribute that says
"pointers to this are probably NULL", that would be useful. I'm not entirely
sure how that would work.

It might also be useful to mark struct members with the same attribute. The
definition of 'struct foo' would effectively be able to enforce the rule "Thou
shalt not assume that foo_s->bar is non-NULL. Always check before dereferencing
it".

[Bug c/86360] New: "inline" (and neither static nor extern) function not emitted.

[dwmw2 at infradead dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86360

Bug ID: 86360
   Summary: "inline" (and neither static nor extern) function not
emitted.
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dwmw2 at infradead dot org
  Target Milestone: ---

https://gcc.gnu.org/onlinedocs/gcc/Inline.html says:

> When an inline function is not static, then the compiler must assume
> that there may be calls from other source files; since a global symbol
> can be defined only once in any program, the function must not be defined
> in the other source files, so the calls therein cannot be integrated. 
> Therefore, a non-static inline function is always compiled on its own
> in the usual fashion. 

Either I misunderstand that, or it isn't true:

$ cat foo.c

inline int foo(int a)
{
return a+1;
}

int main(int a)
{
return foo(a);
}

$ gcc -O0 -o- -S foo.c
.file   "foo.c"
.text
.globl  bar
.type   bar, @function
bar:
.LFB1:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
subq$16, %rsp
movl%edi, -4(%rbp)
movl-4(%rbp), %eax
movl%eax, %edi
callfoo
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE1:
.size   bar, .-bar
.ident  "GCC: (GNU) 8.1.1 20180502 (Red Hat 8.1.1-1)"
.section.note.GNU-stack,"",@progbits


Note the 'foo' function doesn't get emitted.

cf. https://github.com/openwrt/packages/pull/6377#issuecomment-401084671
http://lists.osmocom.org/pipermail/osmocom-sdr/2018-June/001791.html

[Bug c/86360] "inline" (and neither static nor extern) function not emitted.

[dwmw2 at infradead dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86360

--- Comment #3 from David Woodhouse  ---
Thanks for the prompt response.

I'll stick with my original "compiler isn't required to emit" comment in my
referenced patch submission, which everyone had questioned...

[Bug c/86360] "inline" (and neither static nor extern) function not emitted.

[dwmw2 at infradead dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86360

--- Comment #5 from David Woodhouse  ---
Well, it's *allowed* to emit it inline. But if it doesn't then it mustn't emit
it out-of-line. At least, from your citation, it mustn't emit it out-of-line
such that it can be seen from another translation unit.

I'm not sure if it would be permitted for a compiler to emit that function as a
static (but out-of-line) function. Perhaps if there's no extern definition of
the same function, that might be a reasonable thing for a compiler to do?

But frankly I don't care much either. I already submitted a patch to make the
code that offended me use 'static inline', and although I allowed myself to be
talked into filing this PR I'm more than happy just to point at the response
and say "no, my initial analysis was correct".

Thanks again.

[Bug target/50818] va_list is filled incorrectly in functions with ms_abi attribute on amd64

[dwmw2 at infradead dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50818

--- Comment #8 from David Woodhouse  ---
(In reply to H.J. Lu from comment #7)
> As a workaround, you can try 
>   __builtin_ms_va_*
> instead of
>   __builtin_va_*

The problem is that in the UEFI build we don't *know* what ABI we'll be built
with for many functions. Some functions are explicitly marked EFIAPI, which
translates to __attribute__((ms_abi)). But any function which isn't explicitly
exported is functions are 'native'. Except where we got tired of the resulting
pain (this bug included), and added -fms-abi to the command line. Or when we're
building on a platform that *does* target Windows or Windows-like ABI natively.
Or when the wind is blowing in the other direction.

So hard-coding it doesn't work. We really need the builtins to do the right
thing for the function they're used from.

[Bug target/59672] Add -m16 support for x86

[dwmw2 at infradead dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59672

--- Comment #5 from David Woodhouse  ---
Note that LLVM/clang has a -m16 option now which does the same thing. Again,
not needing dirty hacks to ensure that asm(".code16gcc") really *is* the first
thing the assembler sees.

[Bug target/59672] Add -m16 support for x86

[dwmw2 at infradead dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59672

--- Comment #9 from David Woodhouse  ---
Thanks. This appears to work for me to build the Linux kernel's 16-bit boot
code with the patch at
http://lkml.kernel.org/r/1389180083-23249-3-git-send-email-david.woodho...@intel.com

[Bug target/67169] -fstack-check=no doesn't disable stack checking

[dwmw2 at infradead dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67169

--- Comment #4 from David Woodhouse  ---
It's required by Windows but not by UEFI, which otherwise has the same ABI. We
had previously been able to build UEFI firmware with MinGW.

[Bug tree-optimization/55177] missed optimizations with __builtin_bswap

[dwmw2 at infradead dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177

--- Comment #15 from David Woodhouse  ---
More missed optimistions (gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC))

I see it using movbe for the pointer_abuse() function, but can't see a simple
way to make it use movbe *without* killing kittens.

gcc -march=atom -O2 -x c -o - -S - -Wstrict-aliasing data[1] << 16) | (p->data[2] << 8) |
p->data[1];
}

unsigned add(struct pkt *p)
{
return (p->data[0] << 24) + (p->data[1] << 16) + (p->data[2] << 8) +
p->data[1];
}

unsigned pointer_abuse(struct pkt *p)
{
return __builtin_bswap32(*(unsigned *)p->data);
}
EOF

[Bug tree-optimization/55177] missed optimizations with __builtin_bswap

[dwmw2 at infradead dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177

--- Comment #17 from David Woodhouse  ---
Er, yes. Sorry, I originally tried it with uint16_t but it wasn't even using
movbe for the pointer_abuse() function then, so I made it 32-bit instead.
Badly. Come to think of it, the lack of movbe in the 16-bit pointer_abuse()
case is potentially another bug worth fixing.

Here's the corrected test case.

/* gcc -march=atom -O2 -c load_be.c -Wstrict-aliasing -o- -S */
struct pkt {
unsigned char data[10];
};

unsigned or(struct pkt *p)
{
return (p->data[0] << 24) | (p->data[1] << 16) | (p->data[2] << 8) |
p->data[3];
}

unsigned add(struct pkt *p)
{
return (p->data[0] << 24) + (p->data[1] << 16) + (p->data[2] << 8) +
p->data[3];
}

unsigned pointer_abuse(struct pkt *p)
{
return __builtin_bswap16(*(unsigned short *)p->data);
}

[Bug preprocessor/66871] New: .incbin in .S files does not appear in automatically generated dependencies

[dwmw2 at infradead dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66871

Bug ID: 66871
   Summary: .incbin in .S files does not appear in automatically
generated dependencies
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dwmw2 at infradead dot org
  Target Milestone: ---

$ cat foo.S
.incbin "foo.bin"
$ gcc -Wp,-MD,foo.d -o foo.o -c foo.S
$ cat foo.d
foo.o: foo.S /usr/include/stdc-predef.h
$

Why is 'foo.bin' not included in the dependencies?

[Bug preprocessor/66871] .incbin in .S files does not appear in automatically generated dependencies

[dwmw2 at infradead dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66871

--- Comment #2 from David Woodhouse  ---
It would still be extremely useful for it to emit dependencies on those files
which are actually included (after preprocessing).

Otherwise we end up screwing around with preprocessing it and then looking for
'.incbin' and generating the full set of dependencies manually. Which is
horrid.

[Bug target/50818] va_list is filled incorrectly in functions with ms_abi attribute on amd64

[dwmw2 at infradead dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50818

David Woodhouse  changed:

   What|Removed |Added

 CC||dwmw2 at infradead dot org

--- Comment #2 from David Woodhouse  ---
Still broken in 5.1.1.

Note that if you contrive to build it with -mabi=ms on the command line (by
splitting the two functions into separate files and building them separately),
it works fine.

It also works fine if you explicitly use __builtin_ms_va_{list,start,end}.

The problem seems to be that GCC is using the *global* ABI setting to decide
what to do when it sees a plain __builtin_va_list, rather the ABI for the
*current* function.

This is hurting us for UEFI builds too, where only public functions are marked
with __attribute__((ms_abi)) but we need *some* way to make va_list do the
right thing in the general case.

[Bug c/67169] New: -fstack-check=no doesn't disable stack checking

[dwmw2 at infradead dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67169

Bug ID: 67169
   Summary: -fstack-check=no doesn't disable stack checking
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dwmw2 at infradead dot org
  Target Milestone: ---

$ echo 'void foo(void) { char lots[8192]; }' | i686-w64-mingw32-gcc -S -o- -xc
- -fstack-check=no
.file   ""
.text
.globl  _foo
.def_foo;   .scl2;  .type   32; .endef
_foo:
pushl   %ebp
movl%esp, %ebp
movl$8192, %eax
call___chkstk_ms
subl%eax, %esp
nop
leave
ret
.ident  "GCC: (GNU) 5.1.0 20150422 (Fedora MinGW 5.1.0-2.fc22)"


This is causing me problems when building the EDK II UEFI implementation.
Building that with MinGW is useful because it reproduces a number of
LLP64-related issues which would otherwise require Windows to discover.

If I use '-fstack-check=specific' *that* does seem to do what I want. But I'm
not sure I should be suggesting that as an upstream fix for the MinGW build,
because it seems wrong.

[Bug target/67169] -fstack-check=no doesn't disable stack checking

[dwmw2 at infradead dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67169

--- Comment #2 from David Woodhouse  ---
(In reply to Andrew Pinski from comment #1)
> I suspect i686-w64-mingw32 can never be used for self host binaries.

It has been. EDKII has toolchain configurations for it:
http://tianocore.sourceforge.net/wiki/Unix-like_systems#Build_gcc_x64_UEFI_cross_compiler

[Bug middle-end/23299] GCSE? caused miscompilation

[dwmw2 at infradead dot org]

-- 
   What|Removed |Added

 CC||dwmw2 at infradead dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23299

[Bug rtl-optimization/21643] New: GCC fails to merge ranges in comparison.

[dwmw2 at infradead dot org]

I'd expect the result of compiling these two functions to be identical, but it
isn't:

int fish1(unsigned char c)
{
if (c =='"' || c == 0x20 || c < 0x20)
return 1;
}
int fish2(unsigned char c)
{
if (c == '"' || c <= 0x20)
return 1;
}

If I remove the 'c == '"' ||' from each, I do get the expected results.
$ gcc -O2 -S asd.c -o /dev/stdout
.file   "asd.c"
.section".text"
.align 2
.p2align 4,,15
.globl fish1
.type   fish1, @function
fish1:
mr 0,3
li 3,1
cmpwi 7,0,34
cmpwi 6,0,32
beqlr 7
cmplwi 7,0,31
beqlr 6
blelr 7
blr
.size   fish1,.-fish1
.align 2
.p2align 4,,15
.globl fish2
.type   fish2, @function
fish2:
mr 0,3
li 3,1
cmpwi 7,0,34
cmplwi 6,0,32
beqlr 7
blelr 6
blr
.size   fish2,.-fish2
.ident  "GCC: (GNU) 4.0.0 20050512 (Red Hat 4.0.0-5)"
.section.note.GNU-stack,"",@progbits

-- 
   Summary: GCC fails to merge ranges in comparison.
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
     Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwmw2 at infradead dot org
CC: gcc-bugs at gcc dot gnu dot org,jakub at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21643

[Bug rtl-optimization/21643] GCC fails to merge ranges in comparison.

[dwmw2 at infradead dot org]

--- Additional Comments From dwmw2 at infradead dot org  2005-05-18 12:33 
---
Happens with gcc 3.4 too, and also on i386.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21643

[Bug c/30171] New: non-portable va_list abuse is permitted on i386

[dwmw2 at infradead dot org]

See https://bugs.helixcommunity.org/show_bug.cgi?id=5641 -- particularly the
assignment to va_list (the references are uncommon enough that they probably
don't matter).

The world would be a better place if this kind of code would fail to build, or
at least _warn_, on i386. The ABI might not allow us to make va_list 'const'
but we could perhaps add an __attribute__((va_list)) which marks it for
'special' treatment?

This warning could perhaps be enabled by default on any platform which code is
expected to be portable (like Linux) but disabled on i386-only platforms
(win32).


-- 
   Summary: non-portable va_list abuse is permitted on i386
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: dwmw2 at infradead dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30171

[Bug c/30171] non-portable va_list abuse is permitted on i386

[dwmw2 at infradead dot org]

--- Comment #2 from dwmw2 at infradead dot org  2006-12-12 17:33 ---
Yeah, fair enough. Enable the warning by default everywhere then.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30171

[Bug middle-end/26374] Compile failure on long double

[dwmw2 at infradead dot org]

--- Comment #10 from dwmw2 at infradead dot org  2006-12-28 14:32 ---
Any progress on this?


-- 

dwmw2 at infradead dot org changed:

   What|Removed |Added

 CC||dwmw2 at infradead dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26374