[Bug c/77888] New: Missing -Wparentheses diagnostic

2016-10-06 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77888

Bug ID: 77888
   Summary: Missing -Wparentheses diagnostic
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
  Target Milestone: ---

int main(void)
{
int zone = 5;
int MinChassisFanZoneNum = 4;
int MaxChassisFanZoneNum = 10;

# if 0
for (int i = (zone?zone:MinChassisFanZoneNum); i <=
(zone?zone:MaxChassisFanZoneNum); i++)
 return i;
#else
for (int i = zone?zone:MinChassisFanZoneNum; i <=
zone?zone:MaxChassisFanZoneNum; i++)
 return i;

#endif

}

The missing parentheses result in an infinite loop when compiled at O2.

[Bug sanitizer/71498] New: ubsan bounds checking influenced by surrounding code

2016-06-10 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71498

Bug ID: 71498
   Summary: ubsan bounds checking influenced by surrounding code
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

$ gcc -c /tmp/test.c -o - -S -fsanitize=bounds |grep ubsan_handle
call__ubsan_handle_out_of_bounds
$ gcc -c /tmp/test.c -o - -S -fsanitize=bounds |grep ubsan_handle
$

int a[100];
extern void call(const char * fn);
int testje (int core)
{
#if 1
// OK
call("har har");
#else
// NOK
call(__FUNCTION__);
#endif

   return a[core];

}

[Bug middle-end/70871] questionable optimisation in fold-const.c

2016-05-25 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70871

--- Comment #4 from Jan Smets <jan.sm...@alcatel-lucent.com> ---
Ping

[Bug middle-end/70871] questionable optimisation in fold-const.c

2016-04-29 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70871

Jan Smets <jan.sm...@alcatel-lucent.com> changed:

   What|Removed |Added

  Attachment #38376|0   |1
is obsolete||

--- Comment #3 from Jan Smets <jan.sm...@alcatel-lucent.com> ---
Created attachment 38377
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38377=edit
possible solution

[Bug middle-end/70871] questionable optimisation in fold-const.c

2016-04-29 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70871

--- Comment #2 from Jan Smets <jan.sm...@alcatel-lucent.com> ---
Created attachment 38376
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38376=edit
possible solution

I have not extensively tested this, but it seems to work for my testcase.

[Bug middle-end/70871] New: questionable optimisation in fold-const.c

2016-04-29 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70871

Bug ID: 70871
   Summary: questionable optimisation in fold-const.c
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
  Target Milestone: ---

typedef struct X
{   
void *a; 
long int b;
int c;
int d;   
unsigned int e[3];
unsigned short f;
unsigned char g;
unsigned char h;
unsigned char i;
unsigned char j;
unsigned char k;
unsigned char l;
unsigned char m;
unsigned char n;
};



int somefunc(void)
{
struct X *pX = (0L);

extern void call(void*);
call();

if(!pX->n  && !pX->l)
return 0;

return 1;
}

for -O1 and higher

 if(!pX->n  && !pX->l)

results in (tree-original)

 if ((BIT_FIELD_REF <*pX, 64, 320> & 280379743272960) == 0)


which eventually results in 
 ASAN_CHECK (6, _1, 8, 8) 
when using -fsantize=address

Wheras ASAN really should be reporting a 2x 1 byte load and not 1x 8.

Thanks

[Bug c++/70714] New: ICE: Segmentation fault

2016-04-18 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70714

Bug ID: 70714
   Summary: ICE: Segmentation fault
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
  Target Milestone: ---

struct UINT;
typedef struct { UINT TYPES } eType;
fn1(eType) {

gcc version 5.3.1 20160411 (GCC) 
 = gcc-5-branch @ 0efe1cc72d37ff1173b52cf6bc3f17bd0ccb59f3
target = x86_64-unknown-linux-gnu

compile with : -xc++ -c testcase.best  -o /dev/null  -m32 -w

[Bug c++/70617] internal compiler error: Segmentation fault

2016-04-15 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70617

--- Comment #7 from Jan Smets <jan.sm...@alcatel-lucent.com> ---
Should I open a different issue for that?

[Bug c++/70336] [5 regression] Incorrect Wconversion warning

2016-04-14 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70336

Jan Smets <jan.sm...@alcatel-lucent.com> changed:

   What|Removed |Added

   Severity|normal  |minor

[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)

2016-04-14 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56805

Jan Smets <jan.sm...@alcatel-lucent.com> changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #8 from Jan Smets <jan.sm...@alcatel-lucent.com> ---
Hopeless

[Bug target/66920] ICE in expand_debug_locations, at cfgexpand.c:3826

2016-04-14 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66920

--- Comment #4 from Jan Smets <jan.sm...@alcatel-lucent.com> ---
Seems fixed.

[Bug target/66931] ICE in convert_move, at expr.c:316

2016-04-14 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66931

Jan Smets <jan.sm...@alcatel-lucent.com> changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jan Smets <jan.sm...@alcatel-lucent.com> ---
Seems fixed

[Bug rtl-optimization/63629] ICE in fix_loop_structure, at loop-init.c:251

2016-04-14 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63629

Jan Smets <jan.sm...@alcatel-lucent.com> changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Jan Smets <jan.sm...@alcatel-lucent.com> ---
Seems fixed.

[Bug c++/70617] internal compiler error: Segmentation fault

2016-04-11 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70617

--- Comment #5 from Jan Smets <jan.sm...@alcatel-lucent.com> ---
Reduced test case by creduce

struct UINT;
typedef struct { UINT TYPES } eType;
fn1(eType) {


gcc version 5.3.1 20160411 (GCC) 
 = gcc-5-branch @ 0efe1cc72d37ff1173b52cf6bc3f17bd0ccb59f3
target = x86_64-unknown-linux-gnu

compile with : -xc++ -c testcase.best  -o /dev/null  -m32 -w

[Bug c++/70617] internal compiler error: Segmentation fault

2016-04-10 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70617

--- Comment #3 from Jan Smets <jan.sm...@alcatel-lucent.com> ---
output is the same

[Bug c++/70617] internal compiler error: Segmentation fault

2016-04-10 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70617

--- Comment #1 from Jan Smets <jan.sm...@alcatel-lucent.com> ---
with checking=all

../pchip_code/vfp_combined_c.cpp:85:1: internal compiler error: Segmentation
fault
0xd42735 crash_signal
.././gcc-5.3.1/gcc/toplev.c:383
0x732f37 c_tree_chain_next
.././gcc-5.3.1/gcc/c-family/c-common.h:1269
0x732f37 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:237
0x734651 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:567
0x734598 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:543
0x734619 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:563
0x7345de gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:548
0x733aa8 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:382
0x734673 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:569
0x734619 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:563
0x734192 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:437
0x75ede5 gt_ggc_mx_cp_binding_level(void*)
./gt-cp-name-lookup.h:64
0x733395 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:758
0x7341ae gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:439
0x734651 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:567
0x733aa8 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:382
0x734673 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:569
0xa34e55 ggc_mark_root_tab
.././gcc-5.3.1/gcc/ggc-common.c:81
0xa34e55 ggc_mark_roots()
.././gcc-5.3.1/gcc/ggc-common.c:98
0x8269ff ggc_collect()
.././gcc-5.3.1/gcc/ggc-page.c:2199
Please submit a full bug report,

[Bug c++/70617] New: internal compiler error: Segmentation fault

2016-04-10 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70617

Bug ID: 70617
   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
  Target Milestone: ---

gcc (GCC) 5.3.1 20160404 

Unfortunately I have been unable to get a reduced testcase to upload. 
Creduce keeps running in loops and minor modifications to the source make it go
away.
The code is proprietary and therefor I can not share it.

C++ , -O0


file.cpp:1335:1: internal compiler error: Segmentation fault
0xa3dd85 crash_signal
.././gcc-5.3.1/gcc/toplev.c:383
0x6cd7e3 lookup_page_table_entry
.././gcc-5.3.1/gcc/ggc-page.c:659
0x6cd7e3 ggc_set_mark(void const*)
.././gcc-5.3.1/gcc/ggc-page.c:1540
0x638e97 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:236
0x63a33c gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:594
0x63a246 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:567
0x63a18d gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:543
0x63a20e gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:563
0x63a1d3 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:548
0x63a33c gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:594
0x63a373 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:602
0x63a373 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:602
0x63a373 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:602
0x89db2e gt_ggc_mx_gimple_statement_base(void*)
/toolchains/gcc53/gcc-builddir/gcc/gtype-desc.c:2397
0x89b90d gt_ggc_mx_basic_block_def(void*)
/toolchains/gcc53/gcc-builddir/gcc/gtype-desc.c:2055
0x89d7fd gt_ggc_mx_gimple_statement_base(void*)
/toolchains/gcc53/gcc-builddir/gcc/gtype-desc.c:2428
0x89f2c1 gt_ggc_mx_cgraph_edge(void*)
/toolchains/gcc53/gcc-builddir/gcc/gtype-desc.c:907
0x89f2b3 gt_ggc_mx_cgraph_edge(void*)
/toolchains/gcc53/gcc-builddir/gcc/gtype-desc.c:906
0x89f2b3 gt_ggc_mx_cgraph_edge(void*)
/toolchains/gcc53/gcc-builddir/gcc/gtype-desc.c:906
0x89eded gt_ggc_mx_symtab_node(void*)
/toolchains/gcc53/gcc-builddir/gcc/gtype-desc.c:1712
Please submit a full bug report,

[Bug c++/70336] New: Incorrect Wconversion warning

2016-03-21 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70336

Bug ID: 70336
   Summary: Incorrect Wconversion warning
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
  Target Milestone: ---

void bla(unsigned char * buffer, int offset, int position)
{
buffer[position/8] |= (unsigned char)(0x80 >> offset);
}

/tmp/test.c: In function 'bla':
/tmp/test.c:3:27: warning: conversion to 'unsigned char' from 'int' may alter
its value [-Wconversion]
 buffer[position/8] |= (unsigned char)(0x80 >> offset);


Does not give a warning with GCC 4.8, but does with 5.3.1

[Bug middle-end/69975] New: Missing uninitilized warning / optimized to use wrong value

2016-02-25 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69975

Bug ID: 69975
   Summary: Missing uninitilized warning / optimized to use wrong
value
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
  Target Milestone: ---

#include 

int X;

int foo(int yyy, int zzz)
{
int xxx;

if (yyy)
{
printf("in y\n");
xxx = 5;
}

if (zzz)
{
printf("in x\n");
X = xxx;
}

return X;
}

int main(void)
{
printf("got %d\n", foo(0,1));
return 0;
}


$ gcc test-uninit.c -o /tmp/bla -O1  -Wall -Wuninitialized  && /tmp/bla
in x
got 5

$ gcc test-uninit.c -o /tmp/bla -O0  -Wall -Wuninitialized  && /tmp/bla
in x
got 0


I would have expected random garbage from the stack, but never ever '5'. 
(which makes it seem as if the (yyy) condition was true.)

And this should really give a compile time warning.

If this is considered undefined behaviour, then it is not cought by
-fsanitize=undefined in GCC 5.3

[Bug bootstrap/69352] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

2016-01-19 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69352

--- Comment #4 from Jan Smets <jan.sm...@alcatel-lucent.com> ---
compile with :  -xc -c pr69352.best  -w -o /dev/null -O1

$ cat pr69352.best 
typedef enum {
  REG_HSTRH,
  REG_HSTRL,
  REG_HFAERH,
  REG_HFAERL,
  REG_HIMRH,
  REG_HIMRL,
  REG_HCMRH,
  REG_HCMRL,
  REG_HADDRH,
  REG_HADDRL,
  REG_HGPRH,
  REG_HGPRL,
  REG_HWRBFSRH,
  REG_HRBCF,
  REG_MAX
} DLLA;
a[][REG_MAX];
b, c, d, e, f, g, h, i;
fn1(p1) {
  unsigned j;
  int k = 0, l;
  DLLA m;
  if (h)
m = REG_HWRBFSRH;
  else
m = REG_HRBCF;
  if (a[p1][m])
l = fn1;
  a[p1][i] = l;
  while (c) {
if (b) {
  if (f)
k = 1;
  fn2();
}
for (; d;)
  j++;
  }
  while (c) {
if (a[p1][REG_HWRBFSRH]) {
  if (g)
k = 1;
  j++;
}
c = e;
  }
  return k;
}

[Bug c/68513] [5/6 Regression] ICE in gimplify_expr, at gimplify.c:8832, c_maybe_const_expr in IL

2016-01-19 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68513

--- Comment #13 from Jan Smets <jan.sm...@alcatel-lucent.com> ---
I don't think is fixed in 5.x-branch

[Bug bootstrap/69352] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

2016-01-18 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69352

Jan Smets <jan.sm...@alcatel-lucent.com> changed:

   What|Removed |Added

 CC||jan.sm...@alcatel-lucent.co
   ||m

--- Comment #1 from Jan Smets <jan.sm...@alcatel-lucent.com> ---
Same for mips compiling source files. If you need a testcase please let me
know.

[Bug target/63679] [5/6 Regression][AArch64] Failure to constant fold.

2016-01-18 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679

Jan Smets <jan.sm...@alcatel-lucent.com> changed:

   What|Removed |Added

 CC||jan.sm...@alcatel-lucent.co
   ||m

--- Comment #41 from Jan Smets <jan.sm...@alcatel-lucent.com> ---
Breaks a bunch of other things. See PR 69352

[Bug c++/69277] New: ICE (Segmentation fault) used but never defined

2016-01-14 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69277

Bug ID: 69277
   Summary: ICE (Segmentation fault) used but never defined
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
  Target Milestone: ---

$GCC -fpreprocessed -S -xc++ -c testcase.best  -o /dev/null -mabi=64 (mips64
cross compiler was used) 

testcase.best:14:52: warning: '{anonymous}::unique_ptr
{anonymous}::make_unique(Args&&) [with T = {anonymous}::DataContainerBinary;
Args = char (&)[]]' used but never defined
 template  unique_ptr make_unique(Args &&);
^~~

testcase.best: In instantiation of '{anonymous}::unique_ptr
{anonymous}::make_unique(Args&&) [with T = {anonymous}::DataContainerBinary;
Args = char (&)[]]':

testcase.best:14:52: internal compiler error: Segmentation fault



testcase.best :


namespace {
template  class unique_ptr {};
class DataContainerBinary;
namespace {
struct BinaryValue;
union FieldValue {
  BinaryValue *binary;
};
struct BinaryValue {
  int length;
  char data[];
};
}
template  unique_ptr make_unique(Args &&);
namespace {
unique_ptr to_binary(FieldValue field) {
  make_unique(field.binary->data);
}
}
}

And if you change do this it warning output changes slightly (probably same
issue)

16c14
< template  unique_ptr make_unique(Args &&) {}
---
> template  unique_ptr make_unique(Args &&);

[Bug c/68513] [5/6 Regression] ICE in gimplify_expr, at gimplify.c:8832, c_maybe_const_expr in IL

2015-12-03 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68513

--- Comment #11 from Jan Smets <jan.sm...@alcatel-lucent.com> ---
Thanks. Can this also be backported to 5.x? Thanks

[Bug rtl-optimization/68636] unnecessary unaligned load on mips o32

2015-12-02 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68636

--- Comment #2 from Jan Smets <jan.sm...@alcatel-lucent.com> ---
The vreg pass is different

OLD

ode_label 16 9 17 6 2 "" [1 uses])
(note 17 16 18 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(insn 18 17 0 6 (set (mem/v:SI (reg/f:SI 194 [ iftmp$0 ]) [2 *iftmp$0_1+0 S4
A32])
(const_int 0 [0])) test.c:5 281 {*movsi_internal}
 (nil))


NEW

(note 17 16 18 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(insn 18 17 19 6 (set (mem/v:BLK (reg/f:SI 194 [ D.1495 ]) [1 *_1+0 S4 A8])
(unspec:BLK [
(const_int 0 [0])
(mem/v:QI (reg/f:SI 194 [ D.1495 ]) [1 *_1+0 S1 A8])
] UNSPEC_STORE_LEFT)) test2.c:5 276 {mov_swl}
 (nil))
(insn 19 18 0 6 (set (mem/v:BLK (reg/f:SI 194 [ D.1495 ]) [1 *_1+0 S4 A8])
(unspec:BLK [
(const_int 0 [0])
(mem/v:QI (plus:SI (reg/f:SI 194 [ D.1495 ])
(const_int 3 [0x3])) [1 *_1+3 S1 A8])
(mem/v:BLK (reg/f:SI 194 [ D.1495 ]) [1 *_1+0 S4 A8])
] UNSPEC_STORE_RIGHT)) test2.c:5 278 {mov_swr}
 (nil))


I'm not sure how to proceed from here.

Thanks

[Bug c/68513] [5/6 Regression] ICE in gimplify_expr, at gimplify.c:8832, c_maybe_const_expr in IL

2015-12-02 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68513

--- Comment #9 from Jan Smets <jan.sm...@alcatel-lucent.com> ---
Could you please tell me in which commit the issue was fixed. Thanks.

[Bug rtl-optimization/68636] New: unnecessary unaligned load on mips o32

2015-12-01 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68636

Bug ID: 68636
   Summary: unnecessary unaligned load on mips o32
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
  Target Milestone: ---

typedef unsigned long uintptr_t;;

volatile unsigned int x;
void testTestTest(void)
{
x = *((volatile unsigned int *) (((volatile void
*)((uintptr_t)(0x00800070) | ((0xA000) + (uintptr_t)(0x00800070)) >=
0x0080) && ( { register int zeroIsCavium; asm volatile ( "   .setpush  
 \n" "   .setnoreorder   \n" "   mfc0%0,$15  \n" " 
 srl %0,%0,16\n" "   andi%0,%0,0xff  \n" "   xori   
%0,%0,0x0d  \n" "   .setpop \n" : "=r" (zeroIsCavium));
(zeroIsCavium == 0); } )) ? 0x2000 : 0));
}


GCC 4.8 (-march=mips2 -O2 (mabi=o32)) generates

 :
   0:   40027800mfc0v0,$15
   4:   00021402srl v0,v0,0x10
   8:   304200ffandiv0,v0,0xff
   c:   3842000dxoriv0,v0,0xd
  10:   1046beqzv0,2c <testTestTest+0x2c>
  14:   3c02a080lui v0,0xa080
  18:   24420070addiu   v0,v0,112
  1c:   8c43lw  v1,0(v0)
  20:   3c02lui v0,0x0
  24:   03e8jr  ra
  28:   ac43sw  v1,0(v0)
  2c:   3c02c080lui v0,0xc080
  30:   24420070addiu   v0,v0,112
  34:   8c43lw  v1,0(v0)
  38:   3c02lui v0,0x0
  3c:   03e8jr  ra
  40:   ac43sw  v1,0(v0)

GCC 5.2.1  more or less replaces the LW with LWL+LWR

 :
   0:   40027800mfc0v0,$15
   4:   00021402srl v0,v0,0x10
   8:   304200ffandiv0,v0,0xff
   c:   3842000dxoriv0,v0,0xd
  10:   1048beqzv0,34 <testTestTest+0x34>
  14:   3c02a080lui v0,0xa080
  18:   24420070addiu   v0,v0,112
  1c:   8843lwl v1,0(v0)
  20:   98430003lwr v1,3(v0)
  24:   00601021movev0,v1
  28:   3c03lui v1,0x0
  2c:   03e8jr  ra
  30:   ac62sw  v0,0(v1)
  34:   3c02c080lui v0,0xc080
  38:   24420070addiu   v0,v0,112
  3c:   8843lwl v1,0(v0)
  40:   98430003lwr v1,3(v0)
  44:   00601021movev0,v1
  48:   3c03lui v1,0x0
  4c:   03e8jr  ra
  50:   ac62sw  v0,0(v1)

When taking just the true branch of the inline assembly, thus further reducing
to something like

x = *((volatile unsigned int *) (((volatile void *)((uintptr_t)(0x00800070) |
((0xA000) + 0x2000) ;

then results in exactly the same code in both 4.8 and 5.2.1

 :
   0:   3c02c080lui v0,0xc080
   4:   8c430070lw  v1,112(v0)
   8:   3c02lui v0,0x0
   c:   ac43sw  v1,0(v0)
  10:   03e8jr  ra
  14:   nop


Is there a specific reason it starts using unaligned accesses when the inline
assembly is included? The variable factor is either 0x2000 or 0x0, which
both result in aligned addresses.

Thanks

[Bug rtl-optimization/68547] New: incorrect optimization

2015-11-25 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68547

Bug ID: 68547
   Summary: incorrect optimization
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
  Target Milestone: ---

Created attachment 36841
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36841=edit
test case

$ g++ test.cc -o test -O2 -Wall && ./test
DEL element[1]=200 volatile
DEL element[1]=200 last_element_index=2 (should be 2) volatile
DEL element[1]=200
DEL element[1]=200 last_element_index=1 (should be 2)
$ g++ test.cc -o test -O0 -Wall && ./test
DEL element[1]=200 volatile
DEL element[1]=200 last_element_index=2 (should be 2) volatile
DEL element[1]=200
DEL element[1]=200 last_element_index=2 (should be 2)

[Bug c/68513] New: ICE in gimplify_expr, at gimplify.c:8832

2015-11-24 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68513

Bug ID: 68513
   Summary: ICE in gimplify_expr, at gimplify.c:8832
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
  Target Milestone: ---

Created attachment 36819
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36819=edit
testcase

Test case attached. Simply compile without any optimizations.

[Bug middle-end/66920] ICE in expand_debug_locations, at cfgexpand.c:3826

2015-07-18 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66920

--- Comment #1 from Jan Smets jan.sm...@alcatel-lucent.com ---
Likely related/identical to 66931


[Bug middle-end/66931] New: ICE in convert_move, at expr.c:316

2015-07-18 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66931

Bug ID: 66931
   Summary: ICE in convert_move, at expr.c:316
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
  Target Milestone: ---

Compile with -xc++ -w   -m32 -gdwarf-4 -mno-sse test.cpp
Likely related/identical to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66920


typedef long v2di __attribute__((vector_size(16)));
struct tcounter;
int table;
void __attribute__((__always_inline__))
counter(tcounter *self, long, long) {
  *(v2di *)self + v2di{};
}

typedef struct { short total_len; } t_ing;
bool __attribute__((target(sse4.2))) test_sp() {
  t_ing var;
  counter((tcounter *)table, 1,
  var.total_len);
}


[Bug middle-end/66920] New: ICE in expand_debug_locations, at cfgexpand.c:3826

2015-07-17 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66920

Bug ID: 66920
   Summary: ICE in expand_debug_locations, at cfgexpand.c:3826
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
  Target Milestone: ---

Compile with  -xc++ -w   -m32 -gdwarf-4  -mno-sse -O1  test.cpp



test.cpp: In function 'bool test_sp(Desc*, data*)':
test.cpp:29:1: internal compiler error: in expand_debug_locations, at
cfgexpand.c:3826
 test_sp(Desc *pDesc, data *info) {


typedef long int64_t;
typedef int UINT32;
typedef short len;
struct header;
typedef UINT32 number;
struct Desc {
  short length;
};
typedef int64_t v2di __attribute__((vector_size(16)));
int table;
struct data;


void __attribute__((__always_inline__))
counter_inc(struct counter *, long, long) {
  v2di v2di{};
}

bool ing_build_qhdr_and_output(Desc *pDesc,
   data *, header *,
   number, number, bool,
   len, len,
   len) {
  counter_inc((counter *)table, 1,
  pDesc-length);
}

bool __attribute__((target(sse4.2)))
test_sp(Desc *pDesc, data *info) {
  number dest, queue_stat_addr, plen_length;
  UINT32 offset;
  UINT32 extra_header_size;
  header *sw_hdr;
  return ing_build_qhdr_and_output(pDesc, info, sw_hdr, dest,
   queue_stat_addr, 2, offset,
   extra_header_size, plen_length);
}


[Bug c++/63629] New: ICE in fix_loop_structure, at loop-init.c:251

2014-10-23 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63629

Bug ID: 63629
   Summary: ICE in fix_loop_structure, at loop-init.c:251
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com

Created attachment 33795
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33795action=edit
ice in fix_loop_structure, at loop-init.c:251

/tmp/gcc50-new/x86_64-wrs-vxworks/x86_64-unknown-linux-gnu/bin/gcc
-B/tmp/gcc50-new/x86_64-wrs-vxworks/x86_64-unknown-linux-gnu/bin -xc++ -c bug.i
 -o /dev/null -m32 -w 
bug.i: In member function 'virtual void
UnitTest::TestfltrLogTest_fltrLogIndicateTruncatedData_Normal::RunImpl()
const':
bug.i:231:4: internal compiler error: in fix_loop_structure, at loop-init.c:251
}

reduced testcase generated by delta is attached.


[Bug middle-end/63221] New: symbol with section attribute ends up in common

2014-09-10 Thread jan.sm...@alcatel-lucent.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63221

Bug ID: 63221
   Summary: symbol with section attribute ends up in common
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com

extern int sharedTop;
int sharedTop __attribute__ ((section (.cvmx_shared))); 

sharedTop ends up in COM with trunk, GCC 4.8 puts it in .cvmx_shared as one
would expect.


[Bug tree-optimization/59132] Missing aggressive array based optimisation warning

2014-04-23 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59132

--- Comment #1 from Jan Smets jan.sm...@alcatel-lucent.com ---
Ping


[Bug middle-end/58970] [4.7 Regression] internal compiler error: in get_bit_range, at expr.c:4562

2014-04-23 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

Jan Smets jan.sm...@alcatel-lucent.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #31 from Jan Smets jan.sm...@alcatel-lucent.com ---
Fixed in 4.8 and newer.


[Bug sanitizer/60861] New: out of bounds access of global var in .rodata/.bss not detected

2014-04-16 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60861

Bug ID: 60861
   Summary: out of bounds access of  global var in .rodata/.bss
not detected
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

gcc version 4.8.2 (Debian 4.8.2-16) 
gcc test.c -O2 -fsanitize=address -o test 

int depth = 3;

//int testGlobalOutOfBoundsRODATAVar[2] = {1}; /* data: works
(asan_report_load4 present) */
const int testGlobalOutOfBoundsRODATAVar[1] = {1}; /* rodata: doesn't work (no
asan_report_load4 present) */
//int testGlobalOutOfBoundsRODATAVar[1] = {0}; /* bss : works
(asan_report_load4 present) */
//int testGlobalOutOfBoundsRODATAVar[1];  /* bss : doesn't work !???
(asan_report_load4 present!)  */


int test(void)
{
return testGlobalOutOfBoundsRODATAVar[depth]; // boom
}

int main(void)
{
return test();
}


[Bug sanitizer/60861] out of bounds access of global var in .rodata/.bss not detected

2014-04-16 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60861

--- Comment #2 from Jan Smets jan.sm...@alcatel-lucent.com ---
Using -fno-common (while compiling as C), or compiling as C++ works for the
unitialized bss example: 

int testGlobalOutOfBoundsRODATAVar[5];  /* bss : works with -fno-common
(compiled as C) or when compiled as C++ */

but not for the .rodata example.


[Bug rtl-optimization/60260] New: MIPS sign extension issue

2014-02-18 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60260

Bug ID: 60260
   Summary: MIPS sign extension issue
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com

GCC 4.8.2 

mips-wrs-vxworks
 -c test.c -o test -Wall -O2 -mabi=32


int main()
{   
volatile unsigned int * ptr;
unsigned int end = 0x7fbfff80U;
unsigned int * eptr = (unsigned int*)0x8000U;

#define CACHE_LINE_SIZE 32
for (ptr = (volatile unsigned int *) end; ptr  eptr; ptr +=
CACHE_LINE_SIZE / sizeof(*ptr))
{   
//printf(ptr=%p\n, ptr);
*ptr = *ptr;
}
return 0;
}




 main:
   0:   3c027fbflui v0,0x7fbf
   4:   3442ff80ori v0,v0,0xff80
   8:   3c048000lui a0,0x8000
   c:   8c43lw  v1,0(v0)   .. then when v0 reaches
7FE0 ... 
  10:   24420020addiu   v0,v0,32   result is 8000. and
signed extended ?
  14:   ac43ffe0sw  v1,-32(v0) === crash here on addr
0x.7FE0
  18:   1444fffcbne v0,a0,c main+0xc
  1c:   nop
  20:   03e8jr  ra
  24:   1021movev0,zero

When -fno-schedule-insns -fno-schedule-insns2 is used then the add is done
after the load/stores. (Which is what GCC 4.6 does)
(Or daddiu may solve this too I think)


[Bug rtl-optimization/60260] MIPS sign extension issue

2014-02-18 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60260

Jan Smets jan.sm...@alcatel-lucent.com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Jan Smets jan.sm...@alcatel-lucent.com ---
According to C99 6.5.6 this behavior is correct. Closing.


[Bug middle-end/59338] New: error: position plus size exceeds size of referenced object in BIT_FIELD_REF

2013-11-29 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59338

Bug ID: 59338
   Summary: error: position plus size exceeds size of referenced
object in BIT_FIELD_REF
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com

minimal.i: In function 'test':
minimal.i:20:6: error: position plus size exceeds size of referenced object in
BIT_FIELD_REF
 void test(void)
  ^
BIT_FIELD_REF *qResp, 8, 32
minimal.i:23:28: note: in statement
 if (qResp-u.l[0].More == 0)
^
D.1802 = BIT_FIELD_REF *qResp, 8, 32;
minimal.i:20:6: internal compiler error: verify_gimple failed
 void test(void)
  ^


typedef enum
{
XYZZY,
} enumType;

typedef struct
{
unsigned char More : 1;
} tResp;

typedef struct
{
enumType QueryType;
union
{
tResp l[0];
} u;
} tQResp;

void test(void)
{
tQResp *qResp = (0);
if (qResp-u.l[0].More == 0)
return;
}


[Bug other/59132] New: Missing aggressive-loop-optimisation warning

2013-11-14 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59132

Bug ID: 59132
   Summary: Missing aggressive-loop-optimisation warning
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com

#include stdio.h

char info = 0;
typedef enum { A = 0 } eA; 
typedef enum { B = 0 } eB; 
typedef enum { C = 0 } eC; 

int main (void)
{

eA a = 0;  
eB b;
eC c[2];

for (a = 1; a = 2; a++)
{   
switch (info)
{   
case 1 : 
c[a] = 3;  
break;
default:
c[a] = 4;  
break;
}   

for (b = 0; b  1; b++)
{   
printf(b=%d a=%d c[a] = %d\n, b, a, c[a]);
}   
}   

return 0;
}


[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

2013-11-11 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #30 from Jan Smets jan.sm...@alcatel-lucent.com ---
Thanks!


[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

2013-11-06 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #28 from Jan Smets jan.sm...@alcatel-lucent.com ---
Can this be backported to 4.8 please.
Thanks


[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562

2013-11-03 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #5 from Jan Smets jan.sm...@alcatel-lucent.com ---
Seems to work. Thanks!


[Bug middle-end/58970] New: internal compiler error: in get_bit_range, at expr.c:4562

2013-11-02 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

Bug ID: 58970
   Summary: internal compiler error: in get_bit_range, at
expr.c:4562
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com

/tmp/minimal9.i: In function 'function':
/tmp/minimal9.i:15:28: internal compiler error: in get_bit_range, at
expr.c:4562
 pInfo-mode[x].member1 = 0;
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.



struct info
{
struct {
unsigned char member1 : 1;
unsigned char member2;
} mode[1];
};

extern void call(void);

void function(int x, struct info *pInfo)
{
if (x != -1)
call();
pInfo-mode[x].member1 = 0;
if (pInfo-mode[x].member2 == (((x) == 1) ? 2 : 1))
{
call();
}
}


[Bug middle-end/58970] internal compiler error: in get_bit_range, at expr.c:4562

2013-11-02 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970

--- Comment #1 from Jan Smets jan.sm...@alcatel-lucent.com ---
And compile with -O1 or -O2. Reproducible on x86 and mips.


[Bug ipa/58332] [4.9 Regression] error: inlined_to pointer is set but no predecessors found

2013-09-17 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58332

--- Comment #4 from Jan Smets jan.sm...@alcatel-lucent.com ---
Verified


[Bug other/58439] New: ICE verify_cgraph_node failed

2013-09-16 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58439

Bug ID: 58439
   Summary: ICE verify_cgraph_node failed
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com

Created attachment 30827
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30827action=edit
verify_cgraph_node failed

file.c:3290:1: error: inlined_to pointer is set but no predecessors found
 }
 ^
GetCoreNum/204 (GetCoreNum) @0x7f61060995f0
  Type: function definition analyzed
  Visibility: artificial
  next sharing asm name: 202
  References:
  Referring:
  Function GetCoreNum/204 is inline copy in taskLock/60
  Availability: local
  Function flags: body local
  Called by:
  Calls:
file.c:3290:1: internal compiler error: verify_cgraph_node failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.


gcc version 4.9.0 20130908 (experimental) 
mips-wrs-vxworks

testcase attached


[Bug other/58439] ICE verify_cgraph_node failed

2013-09-16 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58439

--- Comment #1 from Jan Smets jan.sm...@alcatel-lucent.com ---
Oh, and compile with -O2


[Bug sanitizer/58411] no_sanitize_undefined function attribute

2013-09-15 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58411

--- Comment #3 from Jan Smets jan.sm...@alcatel-lucent.com ---
Eg, these attributes are useful too I think:

no_sanitize = disable ALL sanitize checks
sanitize - enable ALL sanitize checks

no_sanitize_{address,undefined,vla...} = disable the specific check
sanitize_{address,undefined,vla...} = enable the specific check

Perhaps the enablers will not be used as much, but it might be useful for
people who want to instrument just one specific function.

The no_sanitize attribute could be used for sensitive code, eg, task scheduler
code, interrupt handlers where someone might choose to never instrument.

Thanks
- Jan


[Bug sanitizer/58411] New: no_sanitize_undefined function attribute

2013-09-13 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58411

Bug ID: 58411
   Summary: no_sanitize_undefined function attribute
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

Request for a no_sanitize_undefined attribute


[Bug sanitizer/58413] New: ubsan constant folding

2013-09-13 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58413

Bug ID: 58413
   Summary: ubsan constant folding
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

variable-sized object may not be initialized
  unsigned short x[128  5] = {};

initializer element is not constant
  static int x = ((int)( 0x | ((31  ((1  (4)) - 1))  (((15) + 6) +
4)) | ((0)  ((15) + 6)) | ((0)  (15)) ) );
(yes, auch)

unexpected size of type 'long long unsigned int:40'
  uint64_t start_of_buffer = ((res.ptr.s.addr  7) - res.ptr.s.back)  7; 
   .addr and .back are bitfield members of struct s. ptr is a pointer to an
union.


case label does not reduce to an integer constant

switch(int)
...
   case (11):
..


They all seem related.

Thanks!


[Bug sanitizer/58420] New: internal compiler error: in ubsan_type_descriptor, at ubsan.c:280

2013-09-13 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58420

Bug ID: 58420
   Summary: internal compiler error: in ubsan_type_descriptor, at
ubsan.c:280
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

stl.46/bits/locale_facets.h:1585:46: internal compiler error: in
ubsan_type_descriptor, at ubsan.c:280

Line 1585 is '_CharT  _M_atoms_out[__num_base::_S_oend];'


  templatetypename _CharT
struct __numpunct_cache : public locale::facet
{
  const char*   _M_grouping;
  size_t_M_grouping_size;
  bool  _M_use_grouping;
  const _CharT* _M_truename;
  size_t_M_truename_size;
  const _CharT* _M_falsename;
  size_t_M_falsename_size;
  _CharT_M_decimal_point;
  _CharT_M_thousands_sep;

  // A list of valid numeric literals for output: in the standard
  // C locale, this is -+xX0123456789abcdef0123456789ABCDEF.
  // This array contains the chars after having been passed
  // through the current locale's ctype_CharT.widen().
  _CharT_M_atoms_out[__num_base::_S_oend];

  // A list of valid numeric literals for input: in the standard
  // C locale, this is -+xX0123456789abcdefABCDEF
  // This array contains the chars after having been passed
  // through the current locale's ctype_CharT.widen().
  _CharT_M_atoms_in[__num_base::_S_iend];

  bool  _M_allocated;

  __numpunct_cache(size_t __refs = 0)
  : facet(__refs), _M_grouping(0), _M_grouping_size(0),
_M_use_grouping(false),
_M_truename(0), _M_truename_size(0), _M_falsename(0),
_M_falsename_size(0), _M_decimal_point(_CharT()),
_M_thousands_sep(_CharT()), _M_allocated(false)
{ }

  ~__numpunct_cache();

  void
  _M_cache(const locale __loc);

private:
  __numpunct_cache
  operator=(const __numpunct_cache);

  explicit
  __numpunct_cache(const __numpunct_cache);
};


[Bug sanitizer/58420] internal compiler error: in ubsan_type_descriptor, at ubsan.c:280

2013-09-13 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58420

--- Comment #1 from Jan Smets jan.sm...@alcatel-lucent.com ---
This may be because of the (not yet committed) patch for ubsan vla bounds
checking.  

http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg61427.html

Probably another one for Marek Polacek.
- Jan


[Bug sanitizer/58411] no_sanitize_undefined function attribute

2013-09-13 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58411

--- Comment #2 from Jan Smets jan.sm...@alcatel-lucent.com ---
Please also think of the other -fsanitize= options.


[Bug lto/58285] ICE in lto_output_tree, at lto-streamer-out.c:1318

2013-09-03 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58285

--- Comment #3 from Jan Smets jan.sm...@alcatel-lucent.com ---
vxworks target : . vs $ in asm names.


[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)

2013-09-03 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56805

--- Comment #7 from Jan Smets jan.sm...@alcatel-lucent.com ---
Ping


[Bug lto/58285] New: ICE in lto_output_tree, at lto-streamer-out.c:1318

2013-08-30 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58285

Bug ID: 58285
   Summary: ICE in lto_output_tree, at lto-streamer-out.c:1318
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.sm...@alcatel-lucent.com

Compile with -flto , must use mips triplet.

extern C {
extern C {
typedef int BOOL;
typedef int STATUS;
typedef struct slnode
{
} SL_LIST;
extern C {
typedef struct
{
} MEM_HANDLE;
}
}
typedef struct hashtbl
{
} H_NODE_INT;
typedef struct
{
} MODULE;
typedef MODULE *MODULE_ID;
extern C {
}
typedef struct symtab
{
} SYMTAB;
typedef SYMTAB *SYMTAB_ID;
extern C {
extern C {
extern C {
extern C {
typedef struct BOOT_PARAMS
{
int (*ioctl)
   (
   );
};
}
}
}
}
typedef struct wdb_info
{
} SPL;
}
 BOOL findXtors
(
)
{
}
extern C STATUS cplusLoadFixup
(
MODULE_ID module,
SYMTAB_ID symTab
)
{
{
}
}


[Bug preprocessor/38990] preprocessing different in g++ -E and regular compiling.

2013-06-07 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38990

Jan Smets jan.sm...@alcatel-lucent.com changed:

   What|Removed |Added

 CC||jan.sm...@alcatel-lucent.co
   ||m

--- Comment #3 from Jan Smets jan.sm...@alcatel-lucent.com ---
Confirmed. This issue is easily hit when using distcc.


[Bug preprocessor/38990] preprocessing different in g++ -E and regular compiling.

2013-06-07 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38990

--- Comment #4 from Jan Smets jan.sm...@alcatel-lucent.com ---
Known to work: GCC 4.6


[Bug other/55793] Compile hog with -gdwarf-4 and -O2 (-fvar-tracking issue)

2013-04-19 Thread jan.sm...@alcatel-lucent.com


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



--- Comment #3 from Jan Smets jan.sm...@alcatel-lucent.com 2013-04-19 
11:57:36 UTC ---

Can't confirm since the patch can not be applied to 4.6.

(Even though the branch is dead already..)


[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)

2013-04-12 Thread jan.sm...@alcatel-lucent.com


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



--- Comment #6 from Jan Smets jan.sm...@alcatel-lucent.com 2013-04-12 
09:38:52 UTC ---

What if we created a new .debug_types section for the typedef if:

 1)  -fno-eliminate-unused-debug-types is used

 2)  a typedef is unused and otherwise eliminated.



By doing this we won't create excessive information for people who are using

debug-types-sections and who want a compact set of debugging info. Would that

be possible?



Thanks


[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)

2013-04-02 Thread jan.sm...@alcatel-lucent.com


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



--- Comment #3 from Jan Smets jan.sm...@alcatel-lucent.com 2013-04-02 
18:11:41 UTC ---

For me it's very important.  To briefly describe what we do: we have structures

that are sent to different platforms with configuration information for fail

over/redundancy/etc. First we use ccparse to parse our code and find all the

relevant types/structures/etc. We end up in the file where the type is defined,

not necessarily where it's used. Then we compile our entire project and parse

the objdump STABS output of these structures/files we found with ccparse. Then

that information is used to build a bunch of static asserts based on that

information. (eg, size of members, offsets, etc). This tool helps our software

designers.



I've just written a few thousand lines of perl code to parse DWARF output and

to  regenerate the compile time checks. GCC 4.6 seems to only support

type-sections anyway. Upgrading to 4.7 or 4.8 is not an option due to strict

release planning and limited test resources.



Anything you can do to make this work is appreciated. Thank you.


[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)

2013-04-02 Thread jan.sm...@alcatel-lucent.com


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



--- Comment #5 from Jan Smets jan.sm...@alcatel-lucent.com 2013-04-02 
21:28:37 UTC ---

-gstrict-dwarf does not disable type sections in GCC 4.6, the result is

unchanged. With 4.8 the behaviour is what you described. 



Is it really that much trouble to add a DW_TAG_typedef to the .debug_type

entry, regardless of -fno-eliminate-unused-types ?  Without it the debug entry

is incomplete, imho. I would really appreciate it. Thanks.


[Bug debug/56805] New: DW_AT_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)

2013-04-01 Thread jan.sm...@alcatel-lucent.com


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



 Bug #: 56805

   Summary: DW_AT_typedef missing when -fdebug-types-section is

used (and -fno-eliminate-unused-debug-types)

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: debug

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

ReportedBy: jan.sm...@alcatel-lucent.com





typedef struct

{

char  b[4];

} some_typedef_name;



typedef some_typedef_name joske;



int main()

{

return 0;

}



Compiled with :

-gdwarf-4 -fno-var-tracking-assignments -fno-eliminate-unused-debug-types

-fdebug-types-section





Contents of the .debug_types section:



  Compilation Unit @ offset 0x0:

   Length:0x4f (32-bit)

   Version:   4

   Abbrev Offset: 0

   Pointer Size:  4

   Signature: 86cb53f6d82bc2c9

   Type Offset:   0x1d

 017: Abbrev Number: 1 (DW_TAG_type_unit)

18   DW_AT_language: 4(C++)

19   DW_AT_stmt_list   : 0x0

 11d: Abbrev Number: 2 (DW_TAG_structure_type)

1e   DW_AT_byte_size   : 4

1f   DW_AT_decl_file   : 1

20   DW_AT_decl_line   : 2

21   DW_AT_linkage_name: (indirect string, offset: 0x0):

17some_typedef_name

25   DW_AT_sibling : 0x34

 229: Abbrev Number: 3 (DW_TAG_member)

2a   DW_AT_name: b

2c   DW_AT_decl_file   : 1

2d   DW_AT_decl_line   : 3

2e   DW_AT_type: 0x34

32   DW_AT_data_member_location: 0

 134: Abbrev Number: 4 (DW_TAG_array_type)

35   DW_AT_type: 0x44

39   DW_AT_sibling : 0x44

 23d: Abbrev Number: 5 (DW_TAG_subrange_type)

3e   DW_AT_type: 0x4b

42   DW_AT_upper_bound : 3

 144: Abbrev Number: 6 (DW_TAG_base_type)

45   DW_AT_byte_size   : 1

46   DW_AT_encoding: 6(signed char)

47   DW_AT_name: (indirect string, offset: 0x14): char

 14b: Abbrev Number: 6 (DW_TAG_base_type)

4c   DW_AT_byte_size   : 4

4d   DW_AT_encoding: 7(unsigned)

4e   DW_AT_name: (indirect string, offset: 0x19): sizetype



Contents of the .debug_info section:



  Compilation Unit @ offset 0x0:

   Length:0x48 (32-bit)

   Version:   4

   Abbrev Offset: 0

   Pointer Size:  4

 0b: Abbrev Number: 7 (DW_TAG_compile_unit)

c   DW_AT_producer: (indirect string, offset: 0x27): GNU C++ 4.8.0

10   DW_AT_language: 4(C++)

11   DW_AT_name: (indirect string, offset: 0x103): /tmp/dwarf.c

15   DW_AT_low_pc  : 0x0

19   DW_AT_high_pc : 0x24

1d   DW_AT_stmt_list   : 0x0

 121: Abbrev Number: 6 (DW_TAG_base_type)

22   DW_AT_byte_size   : 4

23   DW_AT_encoding: 7(unsigned)

24   DW_AT_name: (indirect string, offset: 0x19): sizetype

 128: Abbrev Number: 6 (DW_TAG_base_type)

29   DW_AT_byte_size   : 1

2a   DW_AT_encoding: 6(signed char)

2b   DW_AT_name: (indirect string, offset: 0x14): char

 12f: Abbrev Number: 8 (DW_TAG_subprogram)

30   DW_AT_external: 1

30   DW_AT_name: (indirect string, offset: 0x22): main

34   DW_AT_decl_file   : 1

35   DW_AT_decl_line   : 7

36   DW_AT_type: 0x44

3a   DW_AT_low_pc  : 0x0

3e   DW_AT_high_pc : 0x24

42   DW_AT_frame_base  : 1 byte block: 9c (DW_OP_call_frame_cfa)

44   DW_AT_GNU_all_call_sites: 1

 144: Abbrev Number: 9 (DW_TAG_base_type)

45   DW_AT_byte_size   : 4

46   DW_AT_encoding: 5(signed)

47   DW_AT_name: int





without  -fdebug-types-section (note the DW_AT_typedef for 'some_typedef_name'

and 'joske')



Contents of the .debug_info section:



  Compilation Unit @ offset 0x0:

   Length:0x85 (32-bit)

   Version:   4

   Abbrev Offset: 0

   Pointer Size:  4

 0b: Abbrev Number: 1 (DW_TAG_compile_unit)

c   DW_AT_producer: (indirect string, offset: 0x2c): GNU C++ 4.8.0

   10   DW_AT_language: 4(C++)

11   DW_AT_name: (indirect string, offset: 0x105): /tmp/dwarf.c

15   DW_AT_low_pc  : 0x0

19   DW_AT_high_pc : 0x24

1d   DW_AT_stmt_list   : 0x0

 121: Abbrev Number: 2 (DW_TAG_structure_type)

22   DW_AT_byte_size   : 4

23   DW_AT_decl_file   : 1

24   DW_AT_decl_line   : 2

25   DW_AT_linkage_name: (indirect string, offset: 0x18):

17some_typedef_name

29   DW_AT_sibling : 0x38

 22d: Abbrev Number: 3 (DW_TAG_member)

2e   DW_AT_name: b

30   DW_AT_decl_file   : 1

31   DW_AT_decl_line   : 3

32   DW_AT_type: 0x38

36   DW_AT_data_member_location: 0

 138: Abbrev Number: 4 (DW_TAG_array_type)

39   DW_AT_type: 0x4f

3d   DW_AT_sibling : 0x48

 241: Abbrev Number: 5 (DW_TAG_subrange_type)

42   DW_AT_type: 0x48

46   DW_AT_upper_bound : 3

 148

[Bug debug/56805] DW_AT_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)

2013-04-01 Thread jan.sm...@alcatel-lucent.com


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



--- Comment #1 from Jan Smets jan.sm...@alcatel-lucent.com 2013-04-01 
23:33:18 UTC ---

And the typedef names should have an entry , regardless of

-fdebug-types-section because -fno-eliminate-unused-debug-types is used.


[Bug other/56664] New: internal compiler error: in estimate_function_body_sizes, at ipa-inline.c:1940

2013-03-20 Thread jan.sm...@alcatel-lucent.com


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



 Bug #: 56664

   Summary: internal compiler error: in

estimate_function_body_sizes, at ipa-inline.c:1940

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: other

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

ReportedBy: jan.sm...@alcatel-lucent.com





perl -e print 'void test(void) { __asm__ volatile ('; print '\.byte

,,,,,,,,,,,,,,,;\n\'x150;

print ');}';  /tmp/test.c


[Bug c/55882] unaligned load/store : incorrect struct offset

2013-01-08 Thread jan.sm...@alcatel-lucent.com


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



--- Comment #9 from Jan Smets jan.sm...@alcatel-lucent.com 2013-01-08 
21:45:23 UTC ---

Patch verified.


[Bug rtl-optimization/54524] [4.6/4.7 Regression] Spurious add on sum of bitshifts (forward-propagate issue)

2013-01-07 Thread jan.sm...@alcatel-lucent.com


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



Jan Smets jan.sm...@alcatel-lucent.com changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #10 from Jan Smets jan.sm...@alcatel-lucent.com 2013-01-07 
13:30:40 UTC ---

Verified


[Bug c/55882] unaligned load/store : incorrect struct offset

2013-01-07 Thread jan.sm...@alcatel-lucent.com


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



--- Comment #3 from Jan Smets jan.sm...@alcatel-lucent.com 2013-01-07 
16:20:32 UTC ---





 testfunction: testfunction:

...

  20:   03c21021  adduv0,s8,v0  20:   03c21021  adduv0,s8,v0



  24:   8c44000c  lw  a0,12(v0) |   24:   8c44000a  lw  a0,10(v0)  



  28:   3c03000f  lui v1,0xf|   28:   3c03  lui v1,0x

  2c:   3463  ori v1,v1,0x  |   2c:   3463000f  ori v1,v1,0xf

  30:   00831824  and v1,a0,v1  30:   00831824  and v1,a0,v1



  34:   ac43000c  sw  v1,12(v0) |   34:   ac43000a  sw  v1,10(v0)   



  38:   03c0e82d  movesp,s8 38:   03c0e82d  movesp,s8

  3c:   8fbe03ec  lw  s8,1004(sp)   3c:   8fbe03ec  lw  s8,1004(sp)

  40:   27bd03f0  addiu   sp,sp,100840:   27bd03f0  addiu   sp,sp,1008

  44:   03e8  jr  ra44:   03e8  jr  ra

  48:     nop   48:     nop


[Bug c/55882] unaligned load/store : incorrect struct offset

2013-01-07 Thread jan.sm...@alcatel-lucent.com


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



--- Comment #4 from Jan Smets jan.sm...@alcatel-lucent.com 2013-01-07 
16:22:17 UTC ---

Created attachment 29099

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29099

testcase-pr55882.c


[Bug c/55882] New: unaligned load/store : incorrect struct offset

2013-01-04 Thread jan.sm...@alcatel-lucent.com


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



 Bug #: 55882

   Summary: unaligned load/store : incorrect struct offset

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

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

ReportedBy: jan.sm...@alcatel-lucent.com





void testfunction(somestruct * chip)

{

unsigned i;

for (i = 0; i  4; i++)

{

   {

tUint64 mask = ((chip-pp_mask)  (0x0020)) ? (0x08) :

(((chip-pp_mask)  (0x0200)) ? (0x0C) : 0xDEADBEEF-1) - (0) +

1)==64)?0ull:((1ull)((chip-pp_mask)  (0x0020)) ? (0x08) :

(((chip-pp_mask)  (0x0200)) ? (0x0C) : 0xDEADBEEF-1) - (0) + 1) 

(63)) ? (((chip-pp_mask)  (0x0020)) ? (0x08) : (((chip-pp_mask) 

(0x0200)) ? (0x0C) : 0xDEADBEEF-1) - (0) + 1) : (63) - 1)  ((1) ?

(0) : ((chip-pp_mask)  (0x0020)) ? (0x08) : (((chip-pp_mask) 

(0x0200)) ? (0x0C) : 0xDEADBEEF - 1 - ((chip-pp_mask) 

(0x0020)) ? (0x08) : (((chip-pp_mask)  (0x0200)) ? (0x0C) :

0xDEADBEEF-1)));

chip-config-smth[i].xyz = chip-config-smth[i].xyz  ~mask;

};

}



The structure 'somestruct' is hard to reduce and for various reasons I can not

disclose it. 



GCC 4.6 :

=

 testfunction:

   0:   27bdffe8addiu   sp,sp,-24

   4:   afbe0014sw  s8,20(sp)

   8:   03a0f02dmoves8,sp

   c:   afc40018sw  a0,24(s8)

  10:   afc0sw  zero,0(s8)

  14:   0859j   164 testfunction+0x164

  18:   nop

  1c:   8fc20018lw  v0,24(s8)

  20:   8c431ab8lw  v1,6840(v0)

  24:   3c020020lui v0,0x20

  28:   00621024and v0,v1,v0

  2c:   1446bnezv0,48 testfunction+0x48

  30:   nop

  34:   8fc20018lw  v0,24(s8)

  38:   8c421ab8lw  v0,6840(v0)

  3c:   30420200andiv0,v0,0x200

  40:   10400018beqzv0,a4 testfunction+0xa4

  44:   nop

  48:   8fc20018lw  v0,24(s8)

  4c:   8c431ab8lw  v1,6840(v0)

  50:   3c020020lui v0,0x20

  54:   00621024and v0,v1,v0

  58:   144ebnezv0,94 testfunction+0x94

  5c:   nop

  60:   8fc20018lw  v0,24(s8)

  64:   8c421ab8lw  v0,6840(v0)

  68:   30420200andiv0,v0,0x200

  6c:   1045beqzv0,84 testfunction+0x84

  70:   nop

  74:   24030fffli  v1,4095

  78:   102dmovev0,zero

  7c:   0823j   8c testfunction+0x8c

  80:   nop

  84:   2403li  v1,-1

  88:   2402li  v0,-1

  8c:   0827j   9c testfunction+0x9c

  90:   nop

  94:   240300ffli  v1,255

  98:   102dmovev0,zero

  9c:   082cj   b0 testfunction+0xb0

  a0:   nop

  a4:   2403li  v1,-1

  a8:   3c027ffflui v0,0x7fff

  ac:   3442ori v0,v0,0x

  b0:   afc3000csw  v1,12(s8)

  b4:   afc20008sw  v0,8(s8)

  b8:   8fc20018lw  v0,24(s8)

  bc:   8c461ac0lw  a2,6848(v0)

  c0:   8fc20018lw  v0,24(s8)

  c4:   8c451ac0lw  a1,6848(v0)

  c8:   8fc4lw  a0,0(s8)

  cc:   0080182dmovev1,a0

  d0:   00031080sll v0,v1,0x2

  d4:   0040182dmovev1,v0

  d8:   00031080sll v0,v1,0x2

  dc:   00431023subuv0,v0,v1

  e0:   00441023subuv0,v0,a0

  e4:   000211c0sll v0,v0,0x7

  e8:   00a21021adduv0,a1,v0

  ec:   8c4212d0lw  v0,4816(v0)

  f0:   00021502srl v0,v0,0x14

  f4:   3042andiv0,v0,0x

  f8:   0040182dmovev1,v0

  fc:   97c2000elhu v0,14(s8)

 100:   00021027nor v0,zero,v0

 104:   3042andiv0,v0,0x

 108:   00621024and v0,v1,v0

 10c:   3042andiv0,v0,0x

 110:   30420fffandiv0,v0,0xfff

 114:   3045andia1,v0,0x

 118:   8fc4lw  a0,0(s8)

 11c:   0080182dmovev1,a0

 120:   00031080sll v0,v1,0x2

 124:   0040182dmovev1,v0

 128:   00031080sll v0,v1,0x2

 12c:   00431023subuv0,v0,v1

 130:   00441023subuv0,v0,a0

 134:   000211c0sll v0,v0,0x7

 138:   00c21021adduv0,a2,v0

 13c:   00051d00sll v1,a1,0x14

 140:   8c4512d0lw  a1,4816(v0)  !

 144:   3c04000flui a0,0xf

 148:   3484ori a0,a0,0x

 14c:   00a42024and a0,a1,a0

 150:   00831825or  v1,a0,v1

 154:   ac4312d0sw  v1,4816(v0)  !

 158:   8fc2lw  v0,0(s8)

 15c:   24420001addiu   v0,v0,1

 160:   afc2sw  v0,0(s8)

 164:   8fc2lw  v0,0(s8)

 168:   2c420004sltiu   v0,v0,4

 16c:   1440ffabbnezv0,1c testfunction+0x1c

 170:   nop

 174:   03c0e82dmovesp,s8

 178:   8fbe0014lw  s8,20(sp)

 17c:   27bd0018addiu   sp,sp,24

 180:   03e8jr  ra

 184:   nop

[Bug c/55882] unaligned load/store : incorrect struct offset

2013-01-04 Thread jan.sm...@alcatel-lucent.com


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



Jan Smets jan.sm...@alcatel-lucent.com changed:



   What|Removed |Added



 Target||mips*



--- Comment #1 from Jan Smets jan.sm...@alcatel-lucent.com 2013-01-05 
01:43:46 UTC ---

Mips isa lvl 2, o32 

Optimizations off


[Bug middle-end/55851] New: ICE in size_binop_loc, at fold-const.c:1385

2013-01-02 Thread jan.sm...@alcatel-lucent.com


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



 Bug #: 55851

   Summary: ICE in size_binop_loc, at fold-const.c:1385

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

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

ReportedBy: jan.sm...@alcatel-lucent.com





Created attachment 29074

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29074

testcase



Trunk, testcase attached.





/tmp/ice.c: In function 'test':

/tmp/ice.c:36:45: internal compiler error: in size_binop_loc, at

fold-const.c:1385

 if ((found_bit_mask[dqs][word]  (1  j)) == 0)

 ^

0x6de9b5 size_binop_loc(unsigned int, tree_code, tree_node*, tree_node*)

../../trunk/gcc/fold-const.c:1385

0x74c4ec gimplify_compound_lval

../../trunk/gcc/gimplify.c:2239

0x744f5f gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,

bool (*)(tree_node*), int)

../../trunk/gcc/gimplify.c:7146

0x7442b5 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,

bool (*)(tree_node*), int)

../../trunk/gcc/gimplify.c:7459

0x74530b gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,

bool (*)(tree_node*), int)

../../trunk/gcc/gimplify.c:7814

0x74530b gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,

bool (*)(tree_node*), int)

../../trunk/gcc/gimplify.c:7814

0x74530b gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,

bool (*)(tree_node*), int)

../../trunk/gcc/gimplify.c:7814

0x7512bc gimplify_cond_expr

../../trunk/gcc/gimplify.c:3285

0x74542d gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,

bool (*)(tree_node*), int)

../../trunk/gcc/gimplify.c:7150

0x74d978 gimplify_stmt(tree_node**, gimple_statement_d**)

../../trunk/gcc/gimplify.c:5726

0x7449e3 gimplify_statement_list

../../trunk/gcc/gimplify.c:1562

0x7449e3 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,

bool (*)(tree_node*), int)

../../trunk/gcc/gimplify.c:7583

0x74d978 gimplify_stmt(tree_node**, gimple_statement_d**)

../../trunk/gcc/gimplify.c:5726

0x74e898 gimplify_bind_expr

../../trunk/gcc/gimplify.c:1254

0x7455fe gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,

bool (*)(tree_node*), int)

../../trunk/gcc/gimplify.c:7365

0x74d978 gimplify_stmt(tree_node**, gimple_statement_d**)

../../trunk/gcc/gimplify.c:5726

0x751845 gimplify_cond_expr

../../trunk/gcc/gimplify.c:3349

0x74542d gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,

bool (*)(tree_node*), int)

../../trunk/gcc/gimplify.c:7150

0x74d978 gimplify_stmt(tree_node**, gimple_statement_d**)

../../trunk/gcc/gimplify.c:5726

0x7449e3 gimplify_statement_list

../../trunk/gcc/gimplify.c:1562


[Bug debug/54402] [4.8 Regression] var-tracking does not scale

2012-12-23 Thread jan.sm...@alcatel-lucent.com


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



--- Comment #25 from Jan Smets jan.sm...@alcatel-lucent.com 2012-12-24 
00:37:18 UTC ---

55793 may be a duplicate, but the testcase is really different.


[Bug other/55793] New: Compile hog with -gdwarf-4 and -O2 (-fvar-tracking issue)

2012-12-22 Thread jan.sm...@alcatel-lucent.com


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



 Bug #: 55793

   Summary: Compile hog with -gdwarf-4 and -O2 (-fvar-tracking

issue)

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: other

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

ReportedBy: jan.sm...@alcatel-lucent.com





Created attachment 29029

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29029

testcase



Following testcase takes a very long time to compile when debugging info is

enabled.



The 'real life' scenario contained around 900 entries. 

The testcase is reduced to 500.  



With more than 500 entries - variable tracking size limit exceeded.





gcc -c test.c -o test.o -O2 -gdwarf-4  -fno-builtin


[Bug other/55793] Compile hog with -gdwarf-4 and -O2 (-fvar-tracking issue)

2012-12-22 Thread jan.sm...@alcatel-lucent.com


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



--- Comment #1 from Jan Smets jan.sm...@alcatel-lucent.com 2012-12-22 
20:44:32 UTC ---

85%+ of the time is spent in var-tracking dataflow. This may just be a

duplicate of #54402 but the testcase there is different.


[Bug middle-end/52640] [4.8 Regression] performance bottleneck: gcc/tree.c;value_member

2012-12-11 Thread jan.sm...@alcatel-lucent.com


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



--- Comment #19 from Jan Smets jan.sm...@alcatel-lucent.com 2012-12-11 
16:55:30 UTC ---

Steven's example only contains 10 000 entries. I need to recompile a symbol

table of 270.000 entries a dozen times each day. (and so do a lot of other

people)

With the 'fix' it still takes 12+ seconds to compile it on a state of the art

machine and then another 4+ seconds to assemble. CLANG2.8 spends 15.5 sec and

CLANG3.1 16.5 sec.



I'm already happy with the work around but I'd really like to see a more

structural solution, whichever that may be.  Thanks


[Bug rtl-optimization/54524] [4.6/4.7 Regression] Spurious add on sum of bitshifts (forward-propagate issue)

2012-11-03 Thread jan.sm...@alcatel-lucent.com


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



--- Comment #9 from Jan Smets jan.sm...@alcatel-lucent.com 2012-11-03 
18:25:32 UTC ---

Verified. Thanks Andrew.

(Should I mark it as Resolved?)


[Bug rtl-optimization/54524] Spurious add on sum of bitshifts (forward-propagate issue)

2012-09-18 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54524

Jan Smets jan.sm...@alcatel-lucent.com changed:

   What|Removed |Added

   Severity|normal  |major


[Bug rtl-optimization/54524] Spurious add on sum of bitshifts (forward-propagate issue)

2012-09-18 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54524

Jan Smets jan.sm...@alcatel-lucent.com changed:

   What|Removed |Added

 Target|mips|mipsisa64-octeon-elf
  Known to work||4.5.0, 4.5.4
  Known to fail||4.6.0, 4.6.3, 4.7.1, 4.8.0

--- Comment #2 from Jan Smets jan.sm...@alcatel-lucent.com 2012-09-18 
12:41:43 UTC ---
GCC 4.5.4 = CORRECT


   0:   27bdffd0addiu   sp,sp,-48
   4:   97a5001clhu a1,28(sp)
   8:   000427c0sll a0,a0,0x1f
   c:   00053600sll a2,a1,0x18
  10:   3c030040lui v1,0x40
  14:   00052a02srl a1,a1,0x8
  18:   00a42821addua1,a1,a0
  1c:   00c33821addua3,a2,v1
  20:   3c024000lui v0,0x4000
  24:   00e6302bsltua2,a3,a2
  28:   00a21021adduv0,a1,v0
  2c:   3c04lui a0,0x0
2c: R_MIPS_HI16 .rodata
  30:   2484addiu   a0,a0,0
30: R_MIPS_LO16 .rodata
  34:   afbf002csw  ra,44(sp)
  38:   0c00jal 0 function
38: R_MIPS_26   printf
  3c:   00c23021addua2,a2,v0 = !
  40:   8fbf002clw  ra,44(sp)
  44:   03e8jr  ra
  48:   27bd0030addiu   sp,sp,48



GCC 4.6.3
=
   0:   27bdffd0addiu   sp,sp,-48
   4:   97a5001clhu a1,28(sp)
   8:   3c030040lui v1,0x40
   c:   3c024000lui v0,0x4000
  10:   00054600sll t0,a1,0x18
  14:   01033821addua3,t0,v1
  18:   00052a02srl a1,a1,0x8
  1c:   00e8402bsltut0,a3,t0
  20:   00a21021adduv0,a1,v0
  24:   000427c0sll a0,a0,0x1f
  28:   01023021addua2,t0,v0
  2c:   00c43021addua2,a2,a0
  30:   3c04lui a0,0x0
30: R_MIPS_HI16 .rodata
  34:   2484addiu   a0,a0,0
34: R_MIPS_LO16 .rodata
  38:   afbf002csw  ra,44(sp)
  3c:   0c00jal 0 function
3c: R_MIPS_26   printf
  40:   24c60001addiu   a2,a2,1   = !
  44:   8fbf002clw  ra,44(sp)
  48:   03e8jr  ra
  4c:   27bd0030addiu   sp,sp,48


GCC 4.8.0
=
   0:   27bdffd0addiu   sp,sp,-48
   4:   97a6001clhu a2,28(sp)
   8:   3c030040lui v1,0x40
   c:   00062e00sll a1,a2,0x18
  10:   00a33821addua3,a1,v1
  14:   00063202srl a2,a2,0x8
  18:   3c024000lui v0,0x4000
  1c:   00e5282bsltua1,a3,a1
  20:   00c21021adduv0,a2,v0
  24:   000427c0sll a0,a0,0x1f
  28:   00a21021adduv0,a1,v0
  2c:   00443021addua2,v0,a0
  30:   3c04lui a0,0x0
30: R_MIPS_HI16 .rodata
  34:   2484addiu   a0,a0,0
34: R_MIPS_LO16 .rodata
  38:   afbf002csw  ra,44(sp)
  3c:   0c00jal 0 function
3c: R_MIPS_26   printf
  40:   24c60001addiu   a2,a2,1= !
  44:   8fbf002clw  ra,44(sp)
  48:   03e8jr  ra
  4c:   27bd0030addiu   sp,sp,48


[Bug rtl-optimization/54524] [4.6/4.7/4.8 Regression] Spurious add on sum of bitshifts (forward-propagate issue)

2012-09-18 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54524

--- Comment #3 from Jan Smets jan.sm...@alcatel-lucent.com 2012-09-18 
21:49:21 UTC ---
This commit introduced the bug:

http://gcc.gnu.org/viewcvs?view=revisionrevision=161655
(or 182cf5a9a415f31df0f9a10e46faed1221484a35 in git)


[Bug rtl-optimization/54524] New: Spurious add on sum of bitshifts

2012-09-08 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54524

 Bug #: 54524
   Summary: Spurious add on sum of bitshifts
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.sm...@alcatel-lucent.com


There is an spurious addiua2,a2,1   which causes the result to be
incorrect.


tUint32 is unsigned long long


MIPS O32
GCC 4.6.3

 -nostdinc -funsigned-char  -fno-builtin -march=mips2 -G 0 -mno-gpopt
-msoft-float -fno-merge-constants -pipe -Wall -O2 -fno-optimize-sibling-calls
-fno-partial-inlining -fno-reorder-blocks -fno-strict-aliasing 


PUBLIC void function(
tUint32  index160,
tUint8 * data)
{
tUint8temp_data[160/8];
tUint32   scrambled_address;

*(tUint64*)(temp_data+8)  = *(tUint64*)(data+8);

scrambled_address = index160;

printf(%16llX.\n,
   0x4040ull +
   (((tUint64)*(tUint16*)(temp_data+12))  24) +
   ((tUint64)(scrambled_address  0xFF)  56));
}


0x364c70c  27bdffd0addiusp,sp,-48
0x364c710  afbf002csw   ra,44(sp)
0x364c714  8ca8000clw   t0,12(a1)   t0 = pp qq rr ss
0x364c718  3c030040lui  v1,0x40 v1 = 00 40 00 00
0x364c71c  3c024000lui  v0,0x4000   v0 = 40 00 00 00
0x364c720  00085402srl  t2,t0,16t2 = 00 00 pp qq
0x364c724  000a4e00sll  t1,t2,24t1 = qq 00 00 00
0x364c728  01233821addu a3,t1,v1a3 = qq 40 00 00
0x364c72c  000a5202srl  t2,t2,8 t2 = 00 00 00 pp
0x364c730  00e9482bsltu t1,a3,t1t1 = carry?
0x364c734  01421021addu v0,t2,v0v0 = 40 00 00 pp
0x364c738  00042600sll  a0,a0,24a0 = index160  24
0x364c73c  8ca30008lw   v1,8(a1)
0x364c740  01221021addu v0,t1,v0v0 += carry
0x364c744  00443021addu a2,v0,a0a2 = v0 + index160  24
0x364c748  3c04066elui  a0,0x66e\_ String address
0x364c74c  24842084addiua0,a0,8324  /
0x364c750  24c60001addiua2,a2,1 - Spurious add
0x364c754  afa30018sw   v1,24(sp)
0x364c758  0cb402e1jal  printf  - Takes a0 = string. a1 = low word,
a2 = high word
0x364c75c  afa8001csw   t0,28(sp)
0x364c760  8fbf002clw   ra,44(sp)
0x364c764  8fe0lw   zero,0(ra)   (internal extension)
0x364c768  03e8jr   ra
0x364c76c  27bd0030addiusp,sp,48


[Bug rtl-optimization/54524] Spurious add on sum of bitshifts

2012-09-08 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54524

--- Comment #1 from Jan Smets jan.sm...@alcatel-lucent.com 2012-09-08 
13:18:48 UTC ---
Created attachment 28152
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28152
testcase

The result is correct with -fno-forward-propagate

tUint64 is unsigned long long I meant. 


An even more reduced testcase is attached. Compile it with a MIPS cross
compiler:

./gcc  -nostdinc -funsigned-char  -fno-builtin -G 0 -mno-gpopt -msoft-float
-fno-merge-constants -pipe -Wall -O2 -fno-optimize-sibling-calls
-fno-partial-inlining -fno-reorder-blocks -fno-strict-aliasing  -c /tmp/test.c
-o test -mabi=32


[Bug c/53874] New: -Wswitch-enum not properly working with bitfields

2012-07-06 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53874

 Bug #: 53874
   Summary: -Wswitch-enum not properly working with bitfields
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.sm...@alcatel-lucent.com


typedef enum
{
A,
B,
C
} tEnum;


typedef struct t_A
{
 tEnum my_enum:4;
} tA;


int test(tA * bla)
{
 switch(bla-my_enum)
 {
 default:
 return 0;
 }
}



I expect the compiler to complain:

test-enum.c:23: warning: enumeration value `A' not handled in switch
test-enum.c:23: warning: enumeration value `B' not handled in switch
test-enum.c:23: warning: enumeration value `C' not handled in switch

I verified this works in GCC 3.4 but not in GCC 4.6.

Thanks


[Bug c/53874] -Wswitch-enum not properly working with bitfields

2012-07-06 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53874

--- Comment #1 from Jan Smets jan.sm...@alcatel-lucent.com 2012-07-06 
13:09:29 UTC ---
And if the :4 is removed, then it works as expected.


[Bug c/52640] performance bottleneck: gcc/tree.c;value_member

2012-03-21 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640

--- Comment #6 from Jan Smets jan.sm...@alcatel-lucent.com 2012-03-21 
15:51:22 UTC ---
Comment on attachment 26941
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26941
Needs an ASM_OUTPUT_EXTERNAL platform for testing

Where does  deferred_global_decls come from? Can this be modified to apply to
4.6.3 ?

Target is i686-wrs-vxworks / mips-wrs-vxworks


[Bug middle-end/52640] [4.5/4.6/4.7/4.8 Regression] performance bottleneck: gcc/tree.c;value_member

2012-03-21 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640

--- Comment #10 from Jan Smets jan.sm...@alcatel-lucent.com 2012-03-21 
19:46:31 UTC ---
Works. ~13 sec for 243k entries. Still slower than GCC 3.4 but at least better
than 80+ seconds.


[Bug c/52640] performance bottleneck: gcc/tree.c;value_member

2012-03-20 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640

--- Comment #1 from Jan Smets jan.sm...@alcatel-lucent.com 2012-03-20 
23:45:27 UTC ---
I'd like to note that this code compiles in a few seconds in GCC 3.4.
Thanks Neil for making this profile.


[Bug target/47739] gcc 4.4.5 with target powerpc-wrs-vxworks fails to compile

2011-06-08 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47739

Jan Smets jan.sm...@alcatel-lucent.com changed:

   What|Removed |Added

 CC||jan.sm...@alcatel-lucent.co
   ||m

--- Comment #1 from Jan Smets jan.sm...@alcatel-lucent.com 2011-06-08 
12:49:26 UTC ---
I have this issue as well.

My source (4.6) has #ifdef TARGET_POSIX_IO in libgcov.c to pick the correct
mkdir (when TARGET_POSIX_IO is undefined). My target is i686-wrs-vxworks (and
--with-headers=..)  and TARGET_POSIX_IO is defined somehow.

I tried disabling gcov with --disable-coverage or --enable-coverage=no , but it
did not prevent the compile problems.


[Bug other/47733] psignal (int, const? char*) in libiberty/strsignal.h

2011-06-01 Thread jan.sm...@alcatel-lucent.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47733

Jan Smets jan.sm...@alcatel-lucent.com changed:

   What|Removed |Added

 CC||jan.sm...@alcatel-lucent.co
   ||m

--- Comment #1 from Jan Smets jan.sm...@alcatel-lucent.com 2011-06-01 
15:05:34 UTC ---
I've seen this on 4.6.0 too.

Solutions works.