[Bug tree-optimization/57331] [4.9 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in int_fits_type_p, at tree.c

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Reduced testcase without missing return:
int
foo (int x)
{
  void *p = x ? (void *) 1 : (void *) 0;
  __INTPTR_TYPE__ b = (__INTPTR_TYPE__) p;
  if (b)
return 0;
  return 1;
}

The problem is that int_fits_type_p doesn't handle POINTER_TYPE_P on rhs.
range_fits_type_p should already ensure that innerop is INTEGER_TYPE_P or
POINTER_TYPE_P.  So, either we can give up for POINTER_TYPE_P (TREE_TYPE
(innerop)) always, or we could handle just the most important pointer constant
(NULL), instead of the unconditional int_fits_type_p do something like
  && (POINTER_TYPE_P (TREE_TYPE (innerop))
  ? integer_zerop (op1)
  : int_fits_type_p (op1, TREE_TYPE (innerop
(0 will fit in any pointer type), or we'd need to write larger code to do
essentially what int_fits_type_p does, but using lower_bound_in_type and
upper_bound_in_type instead of TYPE_{MIN,MAX}_VALUE.  I'd say the last one
would be overkill.

[Bug target/57333] Wrong detection of LZCNT instruction, -mno-lzcnt has no effect

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||tmsriram at google dot com
   Target Milestone|--- |4.7.4
   Severity|major   |normal

--- Comment #2 from Uroš Bizjak  ---
LZCNT insn is part of ABM abi, and is enabled with -mabm. Does LZCNT insn
really cause SIGILL on your target?

The issue with -mno-lzcnt will be fixed as part of patch at [1].

[1] http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01054.html

[Bug tree-optimization/57331] [4.9 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in int_fits_type_p, at tree.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-05-20
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.9.0
Summary|ICE: tree check: expected   |[4.9 Regression] ICE: tree
   |integer_type or |check: expected
   |enumeral_type or|integer_type or
   |boolean_type or real_type   |enumeral_type or
   |or fixed_point_type, have   |boolean_type or real_type
   |pointer_type in |or fixed_point_type, have
   |int_fits_type_p, at |pointer_type in
   |tree.c:8437 |int_fits_type_p, at
   ||tree.c:8437
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with r198582

[Bug sanitizer/57316] [4.8 regresion] build failure in libsanitizer

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
If you don't have __NR_exit_group, your kernel very likely doesn't have the
rest of NPTL support either (so e.g. __NR_futex), so I'm surprised this is the
only error.

[Bug sanitizer/57316] [4.8 regresion] build failure in libsanitizer

[kcc at gcc dot gnu.org]

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

--- Comment #1 from Kostya Serebryany  ---
Feel free to patch this in 4.8 branch directly. 
As for the trunk, please send the patches to the upstream (LLVM) repo first.

Sorry for the breakages, but we are unable to monitor build failures on old
kernels unless someone sets up a regular testing (build bot) with such kernels
for upstream code.

Also, please note, that even if the libsanitizer code builds with older
kernels, 
we can't guarantee that it actually works, because this is not what we test
with.

[Bug lto/57334] New: ICE: in input_gimple_stmt, at gimple-streamer-in.c:287

[dimhen at gmail dot com]

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

Bug ID: 57334
   Summary: ICE: in input_gimple_stmt, at gimple-streamer-in.c:287
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com

r199075 FAIL

$ cat main.ii 
extern "C" void soap_call_lcdpanel__AskLCDPanelYesNo ();
main ()
{
soap_call_lcdpanel__AskLCDPanelYesNo ();
}

$ cat a.i
soap_serializeheader ()
{
}

soap_getindependent ()
{
return;
}

$ cat b.i
static
soap_getindependent ()
{
}

soap_call_lcdpanel__AskLCDPanelYesNo ()
{
soap_serializeheader ();
}

$ g++ -fpreprocessed -flto -c main.ii
$ gcc -fpreprocessed -c -flto a.i
$ gcc -fpreprocessed -c -flto b.i
$ ar cru libx.a a.o b.o
$ g++ -Ofast -flto -flto-partition=none -o tst main.o libx.a 
In function ‘soap_getindependent’:
lto1: internal compiler error: in input_gimple_stmt, at
gimple-streamer-in.c:287
0x1062235 input_gimple_stmt
/home/dimhen/src/gcc_current/gcc/gimple-streamer-in.c:286
0x1062235 input_bb(lto_input_block*, LTO_tags, data_in*, function*, int)
/home/dimhen/src/gcc_current/gcc/gimple-streamer-in.c:345
0x864483 input_function
/home/dimhen/src/gcc_current/gcc/lto-streamer-in.c:887
0x864483 lto_read_body
/home/dimhen/src/gcc_current/gcc/lto-streamer-in.c:1011
0x864483 lto_input_function_body(lto_file_decl_data*, tree_node*, char const*)
/home/dimhen/src/gcc_current/gcc/lto-streamer-in.c:1055
0x587052 lto_materialize_function
/home/dimhen/src/gcc_current/gcc/lto/lto.c:226
0x587052 materialize_cgraph
/home/dimhen/src/gcc_current/gcc/lto/lto.c:3084
0x58e708 lto_main()
/home/dimhen/src/gcc_current/gcc/lto/lto.c:3348
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: g++ returned 1 exit status
/usr/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug c++/15272] lookup, dependent base

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|gcc-bugs at gcc dot gnu.org|
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #10 from Paolo Carlini  ---
It seems that when in instantiate_class_template_1 the base classes are
tsubst-ed the information about BINFO_DEPENDENT_BASE_P gets lost.

[Bug tree-optimization/57330] ICE: verify_gimple failed -O3 [tree-cfg.c:4792]

[dimhen at gmail dot com]

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

--- Comment #1 from Dmitry G. Dyachenko  ---
PASS versions from Fedora 18/19
gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC)
gcc version 4.8.0 20130412 (Red Hat 4.8.0-2) (GCC)

both configured with --enable-checking=release


FAIL
gcc-4.8: 196523, 196573, 196672
gcc-4.9: 197001, 198354, 198354,199000, 199075

configured with --enable-checking=yes

$ /usr/local/gcc_current/bin/gcc -v   
Using built-in specs.
COLLECT_GCC=/usr/local/gcc_current/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/dima/src/gcc-current/configure
--prefix=/usr/local/gcc_current --with-multilib-list=m64 --enable-__cxa_atexit
--enable-shared --enable-checking=yes --enable-gnu-unique-object
--enable-linker-build-id --enable-languages=c,c++,lto --enable-plugin
--with-tune=native --with-march=native --enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.9.0 20130517 (experimental) [trunk revision 199000] (GCC)

[Bug target/57333] Wrong detection of LZCNT instruction, -mno-lzcnt has no effect

[bernhard.hartleb at gmail dot com]

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

--- Comment #1 from bernhard.hartleb at gmail dot com ---
It seems the illegal instructions is caused by the use of LTO.
Without LTO everything is fine.

The second point is still valid, however.

[Bug fortran/46703] Wrong I/O output (only) when running under valgrind

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Jerry DeLisle  ---
Closing as invalid.

[Bug tree-optimization/57331] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in int_fits_type_p, at tree.c:8437

[dimhen at gmail dot com]

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

--- Comment #1 from Dmitry G. Dyachenko  ---
r198354 PASS

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current_198354/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/dima/src/gcc-current/configure
--prefix=/usr/local/gcc_current --with-multilib-list=m64 --enable-__cxa_atexit
--enable-shared --enable-checking=yes,df,fold,rtl,tree
--enable-gnu-unique-object --enable-linker-build-id
--enable-languages=c,c++,lto --enable-plugin --with-tune=native
--with-march=native --enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.9.0 20130427 (experimental) [trunk revision 198354] (GCC)

[Bug c/57332] Fedora 18 unable to compile any C code even hello world

[ray.brunkow at gmail dot com]

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

--- Comment #2 from ray.brunkow at gmail dot com ---
Thank you.  that was very simple fix.  I apologize for bothering you.  Very
very very new to coding and even more so to C .

Thank you again for the fast response.

[Bug c/57332] Fedora 18 unable to compile any C code even hello world

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Marek Polacek  ---
Not a GCC issue, you should simply install glibc-devel package.

[Bug target/57333] New: Wrong detection of LZCNT instruction, -mno-lzcnt has no effect

[bernhard.hartleb at gmail dot com]

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

Bug ID: 57333
   Summary: Wrong detection of LZCNT instruction, -mno-lzcnt has
no effect
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernhard.hartleb at gmail dot com

Sorry for describing two issues here, but I cant say how they are related:

1st: When using -march=native, gcc tries to use the LZCNT instruction. However
the CPUID of my processor does not show that this instruction is supported.

2nd: Trying to work around this, I noticed that -mno-lzcnt has no effect. When
using -march=amdfam10 (or native in my case) LZCNT will always be used and can
NOT be disabled.

Version:
gcc (Gentoo 4.7.3 p1.0, pie-0.5.5) 4.7.3

Relevant parts of /proc/cpuinfo:
vendor_id   : AuthenticAMD
cpu family  : 16
model   : 4
model name  : AMD Phenom(tm) II X4 810 Processor
stepping: 2
microcode   : 0x1c6
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb
rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni
monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a
misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock
nrip_save

(POPCNT is supported but LZCNT is not)

Testcase for the error:
$ echo | gcc -dM -E - -march=amdfam10 -mno-lzcnt | grep LZCNT
#define __LZCNT__ 1

Expected behaviour (like for POPCNT)
$ echo | gcc -dM -E - -march=amdfam10 -mno-popcnt | grep POP
(No output)

To sum it up: LZCNT is not detected correctly and can not be controlled.

[Bug c/57332] New: Fedora 18 unable to compile any C code even hello world

[ray.brunkow at gmail dot com]

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

Bug ID: 57332
   Summary: Fedora 18 unable to compile any C code even hello
world
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ray.brunkow at gmail dot com

gcc --version
gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ uname -a
Linux home.home 3.8.11-200.fc18.x86_64 #1 SMP Wed May 1 19:44:27 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/issue
Fedora release 18 (Spherical Cow)
Kernel \r on an \m (\l)

GCC was installed via YUM, no other options provided.

$ cat TEST.c 
#include 
int main(void){
printf("My first C program\n");
return 0;
}

$ gcc -Wall -Wextra -o TEST TEST.c 
In file included from /usr/include/features.h:399:0,
 from /usr/include/stdio.h:27,
 from TEST.c:1:
/usr/include/gnu/stubs.h:10:27: fatal error: gnu/stubs-64.h: No such file or
directory
compilation terminated.

$ gcc -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -o TEST
TEST.c 
gcc: error: unrecognized command line option
‘-fno-aggressive-loop-optimizations’

$ gcc -fno-strict-aliasing -fwrapv -o TEST TEST.c 
In file included from /usr/include/features.h:399:0,
 from /usr/include/stdio.h:27,
 from TEST.c:1:
/usr/include/gnu/stubs.h:10:27: fatal error: gnu/stubs-64.h: No such file or
directory
compilation terminated.

$ gcc -o TEST TEST.c 
In file included from /usr/include/features.h:399:0,
 from /usr/include/stdio.h:27,
 from TEST.c:1:
/usr/include/gnu/stubs.h:10:27: fatal error: gnu/stubs-64.h: No such file or
directory
compilation terminated.

 gcc -o TEST TEST.c -save-temps
In file included from /usr/include/features.h:399:0,
 from /usr/include/stdio.h:27,
 from TEST.c:1:
/usr/include/gnu/stubs.h:10:27: fatal error: gnu/stubs-64.h: No such file or
directory
compilation terminated.

$ cat TEST.i 
# 1 "TEST.c"
# 1 ""
# 1 "TEST.c"
# 1 "/usr/include/stdio.h" 1 3 4
# 27 "/usr/include/stdio.h" 3 4
# 1 "/usr/include/features.h" 1 3 4
# 345 "/usr/include/features.h" 3 4
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 346 "/usr/include/features.h" 2 3 4
# 375 "/usr/include/features.h" 3 4
# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 387 "/usr/include/sys/cdefs.h" 3 4
# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 388 "/usr/include/sys/cdefs.h" 2 3 4
# 376 "/usr/include/features.h" 2 3 4
# 399 "/usr/include/features.h" 3 4
# 1 "/usr/include/gnu/stubs.h" 1 3 4

This error occurs 100% of the time and does not matter what the code is.  Even
in this example a simple hello world is refusing to compile with the exact same
error.  As you can clearly see below the GCC being used on my Fedora 18 box is
the most current offered by RedHat.  Thanks in advance for advice and more
importantly a resolution. 

# yum -y update gcc
Loaded plugins: fastestmirror, langpacks, presto, refresh-packagekit
adobe-linux-x86_64 
 |  951 B  00:00:00 
fedora/18/x86_64/metalink  
 |  20 kB  00:00:00 
google-chrome  
 |  951 B  00:00:00 
rpmfusion-free-updates 
 | 3.3 kB  00:00:00 
rpmfusion-nonfree-updates  
 | 3.3 kB  00:00:00 
updates/18/x86_64/metalink 
 |  16 kB  00:00:00 
updates
 | 4.6 kB  00:00:00 
updates/primary_db 
 | 9.2 MB  00:00:12 
Loading mirror speeds from cached hostfile
 * fedora: mirror.hiwaay.net
 * rpmfusion-free: mirror.hiwaay.net
 * rpmfusion-free-updates: mirror.hiwaay.net
 * rpmfusion-nonfree: mirror.hiwaay.net
 * rpmfusion-nonfree-updates: mirror.hiwaay.net
 * updates: mirror.hiwaay.net
No Packages marked for Update


now in gcc-4.2.1 on my Mac I can compile with zero problems.

[Bug tree-optimization/57331] New: ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in int_fits_type_p, at tree.c:8437

[dimhen at gmail dot com]

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

Bug ID: 57331
   Summary: ICE: tree check: expected integer_type or
enumeral_type or boolean_type or real_type or
fixed_point_type, have pointer_type in
int_fits_type_p, at tree.c:8437
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com

r199075 FAIL

$ cat x.i
int J_0;
int a;
static void * foo(int * x)
{
  for(; 0http://gcc.gnu.org/bugs.html> for instructions.

[Bug fortran/57297] FAIL: gfortran.dg/select_type_4.f90 -O2 execution test

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

  Attachment #30138|0   |1
is obsolete||

--- Comment #9 from Mikael Morin  ---
Created attachment 30148
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30148&action=edit
frontend patch, third try

Another variant, yet not passing the testsuite.

This one moves the class_pointer attribute from the class container's type to
the class container, so that the type can be shared between non-pointer and
pointer variants.
It regresses on class_optional_2.f90 (among a few others) because some pointer
array specs become of type AS_ASSUMED_SHAPE instead of AS_DEFERRED without the
patch.  The reasons for that are beyond my understanding so far.

[Bug fortran/57297] FAIL: gfortran.dg/select_type_4.f90 -O2 execution test

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #8 from Mikael Morin  ---
(In reply to gretay from comment #7)
> This patch fixes the failure in this test, but causes ICE in some fortran
> tests on qemu for arm-none-eabi. For example:
> 
> FAIL: gfortran.dg/auto_dealloc_2.f90  -O  (internal compiler error)
> 
I'll need the help from an OOP expert.

Janus, what is the rationale for using so many different types for class
containers? It confuses the middle-end when assigning class containers.
For example in the case:
  class_ptr => class_target

class_ptr's container has type '__class_(blah)p' while class_target has type
'__class_(blah)', so we can't do the assignment.
However, even if the types are different the types' contents seems to be the
same, so they could be merged?

[Bug middle-end/48580] missed optimization: integer overflow checks

[glisse at gcc dot gnu.org]

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

--- Comment #20 from Marc Glisse  ---
(In reply to Zack Weinberg from comment #5)
> Addendum: what would *you* describe as the correct C idiom for
> ensuring that the product of two signed integers was positive and did
> not overflow the range of a same-sized signed integer, assuming
> nothing about either multiplicand?

The most natural way to do it depends on whether you have access to a wider
type (and may rely on modular casts to signed integer types as guaranteed by
gcc). For instance if you want a non-negative result that fits an int:

  return x * (unsigned long long)(y) <= __INT_MAX__;

or if you only care about signed overflow and not the sign of the result:

  long long l = x * (long long)(y);
  return l == (int) l;

The value of the overflow flags after a multiplication doesn't seem modeled in
i386.md currently (apart from "clobbered"), so it won't be used, but the code
generated is not too horrible.

[Bug tree-optimization/57330] New: ICE: verify_gimple failed -O3 [tree-cfg.c:4792]

[dimhen at gmail dot com]

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

Bug ID: 57330
   Summary: ICE: verify_gimple failed -O3 [tree-cfg.c:4792]
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com

r199075 FAIL

$ cat x.i
void foo ( int a)
{}

void *a;
void bar ()
{
  void **( *b ) (  ) = foo;
  a = b ( 0 );
}

$ gcc -fpreprocessed -O3 -c x.i
x.i: In function 'bar':
x.i:7:24: warning: initialization from incompatible pointer type [enabled by
default]
   void **( *b ) (  ) = foo;
^
x.i:5:6: error: invalid conversion in gimple call
 void bar ()
  ^
void * *

void

a.0_2 = foo.constprop.0 ();
x.i:5:6: internal compiler error: verify_gimple failed
0xa4f79c verify_gimple_in_cfg(function*)
/home/dimhen/src/gcc_current/gcc/tree-cfg.c:4792
0x939947 execute_function_todo
/home/dimhen/src/gcc_current/gcc/passes.c:1969
0x93a1d7 execute_todo
/home/dimhen/src/gcc_current/gcc/passes.c:2002
0x93bf41 execute_one_ipa_transform_pass
/home/dimhen/src/gcc_current/gcc/passes.c:2185
0x93bf41 execute_all_ipa_transforms()
/home/dimhen/src/gcc_current/gcc/passes.c:2215
0x6b48b8 expand_function
/home/dimhen/src/gcc_current/gcc/cgraphunit.c:1641
0x6b6616 expand_all_functions
/home/dimhen/src/gcc_current/gcc/cgraphunit.c:1752
0x6b6616 compile()
/home/dimhen/src/gcc_current/gcc/cgraphunit.c:2050
0x6b6ce9 finalize_compilation_unit()
/home/dimhen/src/gcc_current/gcc/cgraphunit.c:2127
0x591693 c_write_global_declarations()
/home/dimhen/src/gcc_current/gcc/c/c-decl.c:10118
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
The inlining is failed in ipa-inline.c, around line 294:

  /* TM pure functions should not be inlined into non-TM_pure
 functions.  */
  else if (is_tm_pure (callee->symbol.decl)
   && !is_tm_pure (e->caller->symbol.decl))
{
  e->inline_failed = CIF_UNSPECIFIED;
  inlinable = false;
}

[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #3 from Uroš Bizjak  ---
Actually, the difference begins in _c.018t.einline.

-O2 -fgnu-tm:

;; Function main (main, funcdef_no=1, decl_uid=1878, symbol_order=1)

  not inlinable: main/1 -> _mm_popcnt_u64/0, 
Considering inline candidate _mm_popcnt_u64.
  not inlinable: main/1 -> _mm_popcnt_u64/0, 
Iterations: 0
main ()
{
  int res;
  int _4;

  :
  res_1 = _mm_popcnt_u64 (0);
  printf ("Result res should be 0: %d\n", res_1);
  _4 = 0;
  return _4;

}

-O2:

;; Function main (main, funcdef_no=1, decl_uid=1722, symbol_order=1)

  Inlining _mm_popcnt_u64 into main (always_inline).
Iterations: 0
Merging blocks 2 and 4
Merging blocks 2 and 3

Symbols to be put in SSA form
{ D.1735 }
Incremental SSA update started at block: 0
Number of blocks in CFG: 3
Number of blocks to update: 2 ( 67%)


main ()
{
  int D.1735;
  int res;
  int _4;
  int _5;

  :
  _5 = 0;
  _6 = _5;
  res_1 = _6;
  printf ("Result res should be 0: %d\n", res_1);
  _4 = 0;
  return _4;

}

Adding CC.

[Bug c++/57327] 'derived' is an ambiguous base class of 'base' diagnostic is backwards

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|'derived' is an ambiguous   |'derived' is an ambiguous
   |base class of 'base'|base class of 'base'
   |diagnostic is bacwards  |diagnostic is backwards

--- Comment #2 from Jonathan Wakely  ---
Thanks, Paolo.  I've just realised the first line of the test case is missing,
sorry.

Here's a simpler form anyway:

template
struct A {};

template
void f(A&) {}

struct B : A {};

struct C : A {};

struct D : B, C {};

int main()
{
  D d;
  f(d);
}

t.cc:16:6: note:   ‘D’ is an ambiguous base class of ‘A’

[Bug c++/57327] 'derived' is an ambiguous base class of 'base' diagnostic is bacwards

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-05-19
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
Mine.

[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses fold

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org

--- Comment #6 from Marc Glisse  ---
I assume it would help with this?

int f(int a,int b){
  return (a<0)&(b<0);
}
int g(int a,int b){
  return (a<0)?(b<0):0;
}
int h(int a,int b){
  if (a<0) return (b<0);
  return 0;
}

where (on x86) we turn g into f, but we don't notice that h is the same. In
asm, that is:

movl%esi, %eax
andl%edi, %eax
shrl$31, %eax

((a<0)&(b<0) is later optimized to (a&b)<0)

vs

shrl$31, %esi
xorl%eax, %eax
testl%edi, %edi
cmovs%esi, %eax

[Bug c/57329] ICE with -O2 and -mthumb

[Martin.Jansa at gmail dot com]

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

--- Comment #1 from Martin Jansa  ---
Created attachment 30147
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30147&action=edit
pixman-ice.E

[Bug c/57329] New: ICE with -O2 and -mthumb

[Martin.Jansa at gmail dot com]

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

Bug ID: 57329
   Summary: ICE with -O2 and -mthumb
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Martin.Jansa at gmail dot com

Created attachment 30146
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30146&action=edit
pixman-ice.c

Hi, when compiling pixman for armv4t or armv5te with thumb enabled I've noticed
ICE, disabling thumb or O2 is enough to build it without ICE.

$ arm-oe-linux-gnueabi-gcc -march=armv5te -mthumb -O2 -c pixman-ice.c -o
pixman-ice.o
pixman-ice.c: In function 'prng_srand_r':
pixman-ice.c:113:1: internal compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

pixman-ice.c and preprocessed pixman-ice.E attached.