Internal compiler error with -O2 and optimize("O0")

[Aleksandr Platonov]

Hi,
-O2 command line option and optimize("O0") (#pragma GCC optimize ("O0")
or __attribute__((optimize("O0" sometimes leads to internal compiler
error with trace:
 internal compiler error: in parm_ref_data_preserved_p, at
ipa-prop.c:740
 }
 ^
0x898982b ipcp_generate_summary
/home/pam/tmp/gcc_source/gcc/ipa-cp.c:3640
0x84d5d13 execute_ipa_summary_passes(ipa_opt_pass_d*)
/home/pam/tmp/gcc_source/gcc/passes.c:2136
0x825bef4 ipa_passes
/home/pam/tmp/gcc_source/gcc/cgraphunit.c:1846
0x825bef4 compile()
/home/pam/tmp/gcc_source/gcc/cgraphunit.c:1952
0x825cf39 finalize_compilation_unit()
/home/pam/tmp/gcc_source/gcc/cgraphunit.c:2106
0x810addb c_write_global_declarations()
/home/pam/tmp/gcc_source/gcc/c/c-decl.c:10118

There is a bug about problem with example code to reproduce
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57358 comment #2) but no
responses there. Could anybody take a look at this? This problem appears
in 4.8.0 version and  still observed in latest gcc sources (4.9.0
20130610 (experimental))

-- 
Aleksandr Platonov

4.8.1 fails to build on x86_64-unknown-linux-gnu

[Piotr Wyderski]

I have a set of the required libraries built and installed into
separate directories, so when gcc is configured with:

../configure --prefix=/opt/tools/gcc-4.8.1
--with-gmp=/opt/tools/gmp-5.1.2 --with-mpfr=/opt/tools/mpfr-3.2.1
--with-mpc=/opt/tools/mfr=/opt/tools/mpfr-3.2.1
--with-mpc=/opt/tools/mpc-1.0.1 --with-ppl=/opt/tools/ppl-1.1
--with-cloog=/opt/tools/cloog-0.18.0 --enable-languages=c,c++
--disable-multilib

during configure-stage1-target-libgcc:

configure: error: cannot compute suffix of object files: cannot compile

and config.log contains:

configure:3565: checking for suffix of object files
configure:3587: /mnt/local/piotrw/build/gcc-4.8.1/objdir/./gcc/xgcc
-B/mnt/local/piotrw/build/gcc-4.8.1/objdir/./gcc/
-B/opt/tools/gcc-4.8.1/x86_64-unknown-linux-gnu/bin/
-B/opt/tools/gcc-4.8.1/x86_64-unknown-linux-gnu/lib/ -isystem
/opt/tools/gcc-4.8.1/x86_64-unknown-linux-gnu/include -isystem
/opt/tools/gcc-4.8.1/x86_64-unknown-linux-gnu/sys-include-c -g -O2
 conftest.c >&5
/mnt/local/piotrw/build/gcc-4.8.1/objdir/./gcc/cc1: error while
loading shared libraries: libmpc.so.3: cannot open shared object file:
No such file or directory
configure:3591: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3605: error: in
`/mnt/local/piotrw/build/gcc-4.8.1/objdir/x86_64-unknown-linux-gnu/libgcc':
configure:3608: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

which indicates that the configure scripts somehow failed to add the
mpc libpath to the command line.

Best regards, Piotr

Re: 4.8.1 fails to build on x86_64-unknown-linux-gnu

[Jonathan Wakely]

On 10 June 2013 16:59, Piotr Wyderski wrote:
> I have a set of the required libraries built and installed into
> separate directories, so when gcc is configured with:
>
> ../configure --prefix=/opt/tools/gcc-4.8.1
> --with-gmp=/opt/tools/gmp-5.1.2 --with-mpfr=/opt/tools/mpfr-3.2.1
> --with-mpc=/opt/tools/mfr=/opt/tools/mpfr-3.2.1
> --with-mpc=/opt/tools/mpc-1.0.1 --with-ppl=/opt/tools/ppl-1.1
> --with-cloog=/opt/tools/cloog-0.18.0 --enable-languages=c,c++
> --disable-multilib
>
> during configure-stage1-target-libgcc:
>
> configure: error: cannot compute suffix of object files: cannot compile
>
> and config.log contains:
>
> configure:3565: checking for suffix of object files
> configure:3587: /mnt/local/piotrw/build/gcc-4.8.1/objdir/./gcc/xgcc
> -B/mnt/local/piotrw/build/gcc-4.8.1/objdir/./gcc/
> -B/opt/tools/gcc-4.8.1/x86_64-unknown-linux-gnu/bin/
> -B/opt/tools/gcc-4.8.1/x86_64-unknown-linux-gnu/lib/ -isystem
> /opt/tools/gcc-4.8.1/x86_64-unknown-linux-gnu/include -isystem
> /opt/tools/gcc-4.8.1/x86_64-unknown-linux-gnu/sys-include-c -g -O2
>  conftest.c >&5
> /mnt/local/piotrw/build/gcc-4.8.1/objdir/./gcc/cc1: error while
> loading shared libraries: libmpc.so.3: cannot open shared object file:
> No such file or directory

FAQ: http://gcc.gnu.org/wiki/FAQ#configure_suffix


> which indicates that the configure scripts somehow failed to add the
> mpc libpath to the command line.

No, it means you haven't added /opt/tools/mpc-1.0.1 to the run-time
linker's path. That's your job, not the compiler's.

If there isn't a very good reason for installing the dependencies to
separate directories then you're doing it wrong, see
http://gcc.gnu.org/wiki/InstallingGCC

Re: 4.8.1 fails to build on x86_64-unknown-linux-gnu

[Jonathan Wakely]

I've just noticed this mail was sent to the gcc@  list, which is for
development of GCC itself. For help using and installing GCC please
use the gcc-help@ list instead, see http://gcc.gnu.org/lists.html

Re: [RS6000] strict alignment for little-endian

[Michael Meissner]

On Fri, Jun 07, 2013 at 10:54:39AM +0930, Alan Modra wrote:
> I'd like to remove -mstrict-align for little-endian powerpc, because
> the assumption that mis-aligned accesses are massively slow isn't true
> for current powerpc processors.  However I also don't want to break
> old machines, so probably should add -mstrict-align back for some set
> of cpus.  Can anyone tell me the set?

I don't know the set.  I recall the original PPC's (604, 603, etc.) had the
strict alignment rule in little endian rule, and the 750 relaxed it for GPRs
(but not FPRs), but I don't know about later machines.

> Index: gcc/config/rs6000/sysv4.h
> ===
> --- gcc/config/rs6000/sysv4.h (revision 199718)
> +++ gcc/config/rs6000/sysv4.h (working copy)
> @@ -538,12 +538,7 @@
> 
>  #define  CC1_ENDIAN_BIG_SPEC ""
> 
> -#define  CC1_ENDIAN_LITTLE_SPEC "\
> -%{!mstrict-align: %{!mno-strict-align: \
> -%{!mcall-i960-old: \
> - -mstrict-align \
> -} \
> -}}"
> +#define  CC1_ENDIAN_LITTLE_SPEC ""
> 
>  #define  CC1_ENDIAN_DEFAULT_SPEC "%(cc1_endian_big)"
> 
> 
> -- 
> Alan Modra
> Australia Development Lab, IBM
> 

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

lower-subreg and IBM long double

[Alan Modra]

Should lower-subreg be disabled for IBM long double TFmode?
On powerpc64-linux, this testcase

long double ld_abs (long double x)
{
  return __builtin_fabsl (x);
}

compiled with -m64 -O2 -S generates the horrible code shown on the
left.  The code on the right is ideal, as generated by gcc-4.2.  We
regressed with gcc-4.3.0, ie. with lower-subreg.

.L.ld_abs:  .L.ld_abs:
fabs 0,1fmr 0,1
stfd 2,-32(1)   fabs 1,1
fcmpu 7,1,0 fcmpu 7,0,1
ori 2,2,0   beqlr 7
ld 10,-32(1)fneg 2,2
mr 9,10 blr
beq 7,.L2
std 10,-24(1)
ori 2,2,0
lfd 13,-24(1)
fneg 13,13
stfd 13,-24(1)
ori 2,2,0
ld 9,-24(1)
.L2:
stfd 0,-32(1)
std 9,-8(1)
ori 2,2,0
ld 8,-32(1)
lfd 2,-8(1)
std 8,-16(1)
ori 2,2,0
lfd 1,-16(1)
blr

It isn't hard to see why we are going wrong.  IBM long double is
really a two element array of double, and the rs6000 backend uses
subregs to access the elements.  The problem is that lower-subreg
lowers to word_mode, so we get DImode.  word_mode makes sense for most
targets where subregs of FP modes might be used to narrow an access
for bit-twiddling operations on the sign bit.  It doesn't make sense
for us.  We want DFmode for FP operations.  An example is the expander
used by the testcase.

(define_expand "abstf2_internal"
  [(set (match_operand:TF 0 "gpc_reg_operand" "")
(match_operand:TF 1 "gpc_reg_operand" ""))
   (set (match_dup 3) (match_dup 5))
   (set (match_dup 5) (abs:DF (match_dup 5)))
   (set (match_dup 4) (compare:CCFP (match_dup 3) (match_dup 5)))
   (set (pc) (if_then_else (eq (match_dup 4) (const_int 0))
   (label_ref (match_operand 2 "" ""))
   (pc)))
   (set (match_dup 6) (neg:DF (match_dup 6)))]
  "!TARGET_IEEEQUAD
   && TARGET_HARD_FLOAT && TARGET_FPRS && TARGET_DOUBLE_FLOAT 
   && TARGET_LONG_DOUBLE_128"
  "
{
  const int hi_word = LONG_DOUBLE_WORDS_BIG_ENDIAN ? 0 : GET_MODE_SIZE (DFmode);
  const int lo_word = LONG_DOUBLE_WORDS_BIG_ENDIAN ? GET_MODE_SIZE (DFmode) : 0;
  operands[3] = gen_reg_rtx (DFmode);
  operands[4] = gen_reg_rtx (CCFPmode);
  operands[5] = simplify_gen_subreg (DFmode, operands[0], TFmode, hi_word);
  operands[6] = simplify_gen_subreg (DFmode, operands[0], TFmode, lo_word);
}")

The following patch disables lower-subreg for double double TFmode,
bootstrap and regression tests are OK, but I'm a little unsure whether
this is the right thing to do.

* rs6000.c (TARGET_INIT_LOWER_SUBREG): Define.
(rs6000_init_lower_subreg): New function.
* lower-subreg.c (init_lower_subreg): Call targetm.init_lower_subreg.
* target.def (init_lower_subreg): New.
* doc/tm.texi.in (TARGET_INIT_LOWER_SUBREG): Document.
* doc/tm.texi: Regenerate.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 199781)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -59,6 +59,7 @@
 #include "opts.h"
 #include "tree-vectorizer.h"
 #include "dumpfile.h"
+#include "lower-subreg.h"
 #if TARGET_XCOFF
 #include "xcoffout.h"  /* get declarations of xcoff_*_section_name */
 #endif
@@ -1317,6 +1318,8 @@
 #define TARGET_RTX_COSTS rs6000_rtx_costs
 #undef TARGET_ADDRESS_COST
 #define TARGET_ADDRESS_COST hook_int_rtx_mode_as_bool_0
+#undef TARGET_INIT_LOWER_SUBREG
+#define TARGET_INIT_LOWER_SUBREG rs6000_init_lower_subreg
 
 #undef TARGET_DWARF_REGISTER_SPAN
 #define TARGET_DWARF_REGISTER_SPAN rs6000_dwarf_register_span
@@ -26865,6 +26955,20 @@
   return ret;
 }
 
+static void
+rs6000_init_lower_subreg (void *data)
+{
+  if (!TARGET_IEEEQUAD
+  && TARGET_HARD_FLOAT
+  && (TARGET_FPRS || TARGET_E500_DOUBLE)
+  && TARGET_LONG_DOUBLE_128)
+{
+  struct target_lower_subreg *info = (struct target_lower_subreg *) data;
+  info->x_choices[0].move_modes_to_split[TFmode] = false;
+  info->x_choices[1].move_modes_to_split[TFmode] = false;
+}
+}
+
 /* Returns a code for a target-specific builtin that implements
reciprocal of the function, or NULL_TREE if not available.  */
 
Index: gcc/lower-subreg.c
===
--- gcc/lower-subreg.c  (revision 199781)
+++ gcc/lower-subreg.c  (working copy)
@@ -39,6 +39,7 @@
 #include "tree-pass.h"
 #include "df.h"
 #include "lower-subreg.h"
+#include "target.h"
 
 #ifdef STACK_GROWS_DOWNWARD
 # undef STACK_GROWS_DOWNWARD
@@ -287,6 +288,9 @@
   if (LOG_COSTS)
 fprintf (stderr, "\nSpeed costs\n===\n\n");
   compute_costs (true, &rtxes);
+
+  if (targetm.init_lower_subreg)
+targetm.init_lower_subreg (this_target_lower_subreg);
 }
 
 static bool
Index: gcc/target.def
===
--- gcc/targe

aprovechas las mejores ofertas

[info]

si te gusta la fortuna de san carlos.

dale me gusta a nuestro sitio en fb

https://www.facebook.com/fortunacostarica?ref=tn_tnmn

 

La Fortuna Costa Rica 

aqui estaremos publicando las mejores ofertas, tal como la que
publicamos en nuestro muro, 
oferta del Hotel Linda Vista
 
a precio super rebajado
 
gracias



Esta correspondencia no contiene fines de venta directa. Nuestro deseo es
mantenerle informado sobre los movimientos,
servicios y oportunidades que se brindan para su crecimiento profesional y
personal. Si usted est� interesado
en recibir informaci�n sobre el anuncio que observa puede comunicarse con
su proveedor.


Cumplimos con las normas mundiales del anti spam, Valoramos su desisi�n si
usted no desea permanecer en nuestra
lista de usuarios puede darse de baja 

si no desea recibir mas correos, 
http://ticosviajando.com/lista/?p=unsubscribe&uid=b791d01f225480b98558fc8681a252ec

para actualizar su correo 
http://ticosviajando.com/lista/?p=preferences&uid=b791d01f225480b98558fc8681a252ec
reenviar a un amigo 
http://ticosviajando.com/lista/?p=forward&uid=b791d01f225480b98558fc8681a252ec&mid=35


--
powered by phpList, www.phplist.com --

aprovechas las mejores ofertas

[info]

si te gusta la fortuna de san carlos.

dale me gusta a nuestro sitio en fb

https://www.facebook.com/fortunacostarica?ref=tn_tnmn

 

La Fortuna Costa Rica 

aqui estaremos publicando las mejores ofertas, tal como la que
publicamos en nuestro muro, 
oferta del Hotel Linda Vista
 
a precio super rebajado
 
gracias



Esta correspondencia no contiene fines de venta directa. Nuestro deseo es
mantenerle informado sobre los movimientos,
servicios y oportunidades que se brindan para su crecimiento profesional y
personal. Si usted est� interesado
en recibir informaci�n sobre el anuncio que observa puede comunicarse con
su proveedor.


Cumplimos con las normas mundiales del anti spam, Valoramos su desisi�n si
usted no desea permanecer en nuestra
lista de usuarios puede darse de baja 

si no desea recibir mas correos, 
http://ticosviajando.com/lista/?p=unsubscribe&uid=528a17b39bf348e3df10b064df474c25

para actualizar su correo 
http://ticosviajando.com/lista/?p=preferences&uid=528a17b39bf348e3df10b064df474c25
reenviar a un amigo 
http://ticosviajando.com/lista/?p=forward&uid=528a17b39bf348e3df10b064df474c25&mid=35


--
powered by phpList, www.phplist.com --

Re: lower-subreg and IBM long double

[David Edelsohn]

On Mon, Jun 10, 2013 at 8:26 PM, Alan Modra  wrote:

> The following patch disables lower-subreg for double double TFmode,
> bootstrap and regression tests are OK, but I'm a little unsure whether
> this is the right thing to do.
>
> * rs6000.c (TARGET_INIT_LOWER_SUBREG): Define.
> (rs6000_init_lower_subreg): New function.
> * lower-subreg.c (init_lower_subreg): Call targetm.init_lower_subreg.
> * target.def (init_lower_subreg): New.
> * doc/tm.texi.in (TARGET_INIT_LOWER_SUBREG): Document.
> * doc/tm.texi: Regenerate.

I agree with the rs6000 bits.  You need someone else to approve the
common bits.  This also needs a testcase.

Thanks, David

Re: lower-subreg and IBM long double

[Andrew Pinski]

On Mon, Jun 10, 2013 at 6:00 PM, David Edelsohn  wrote:
> On Mon, Jun 10, 2013 at 8:26 PM, Alan Modra  wrote:
>
>> The following patch disables lower-subreg for double double TFmode,
>> bootstrap and regression tests are OK, but I'm a little unsure whether
>> this is the right thing to do.
>>
>> * rs6000.c (TARGET_INIT_LOWER_SUBREG): Define.
>> (rs6000_init_lower_subreg): New function.
>> * lower-subreg.c (init_lower_subreg): Call targetm.init_lower_subreg.
>> * target.def (init_lower_subreg): New.
>> * doc/tm.texi.in (TARGET_INIT_LOWER_SUBREG): Document.
>> * doc/tm.texi: Regenerate.
>
> I agree with the rs6000 bits.  You need someone else to approve the
> common bits.  This also needs a testcase.

I thought there was a way already to disable lower subreg already for
some modes.

Thanks,
Andrew

>
> Thanks, David

Re: lower-subreg and IBM long double

[Alan Modra]

On Mon, Jun 10, 2013 at 06:31:55PM -0700, Andrew Pinski wrote:
> On Mon, Jun 10, 2013 at 6:00 PM, David Edelsohn  wrote:
> > On Mon, Jun 10, 2013 at 8:26 PM, Alan Modra  wrote:
> >
> >> The following patch disables lower-subreg for double double TFmode,
> >> bootstrap and regression tests are OK, but I'm a little unsure whether
> >> this is the right thing to do.
> >>
> >> * rs6000.c (TARGET_INIT_LOWER_SUBREG): Define.
> >> (rs6000_init_lower_subreg): New function.
> >> * lower-subreg.c (init_lower_subreg): Call 
> >> targetm.init_lower_subreg.
> >> * target.def (init_lower_subreg): New.
> >> * doc/tm.texi.in (TARGET_INIT_LOWER_SUBREG): Document.
> >> * doc/tm.texi: Regenerate.
> >
> > I agree with the rs6000 bits.  You need someone else to approve the
> > common bits.  This also needs a testcase.
> 
> I thought there was a way already to disable lower subreg already for
> some modes.

There is, via rtx_costs.  In fact that was my first approach, with the
following in rs6000_rtx_costs, but this potentially affects other
areas of the compiler.

case SET:
  if (GET_MODE (SET_DEST (x)) == TFmode
  && !TARGET_IEEEQUAD
  && TARGET_HARD_FLOAT
  && (TARGET_FPRS || TARGET_E500_DOUBLE)
  && TARGET_LONG_DOUBLE_128)
/* This hack is to persuade lower_subreg to not lower
   TFmode regs to DImode.  */
*total = COSTS_N_INSNS (2) - 1;
  break;


-- 
Alan Modra
Australia Development Lab, IBM

Memory dependence

[shmeel gutl]

In the architecture that I am using, there is a big pipeline penalty for 
read after write to the same memory location. Is it possible to tell the 
difference between a possible memory conflict and a definite memory 
conflict?