Internal compiler error with -O2 and optimize(O0)
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
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
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
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
lower-subreg and IBM long double
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/target.def (revision 199781)
+++ gcc/target.def
aprovechas las mejores ofertas
si te gusta la fortuna de san carlos. dale me gusta a nuestro sitio en fb https://www.facebook.com/fortunacostarica?ref=tn_tnmn https://www.facebook.com/fortunacostarica?ref=nf La Fortuna Costa Rica https://www.facebook.com/fortunacostarica 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=unsubscribeuid=b791d01f225480b98558fc8681a252ec para actualizar su correo http://ticosviajando.com/lista/?p=preferencesuid=b791d01f225480b98558fc8681a252ec reenviar a un amigo http://ticosviajando.com/lista/?p=forwarduid=b791d01f225480b98558fc8681a252ecmid=35 -- powered by phpList, www.phplist.com --
aprovechas las mejores ofertas
si te gusta la fortuna de san carlos. dale me gusta a nuestro sitio en fb https://www.facebook.com/fortunacostarica?ref=tn_tnmn https://www.facebook.com/fortunacostarica?ref=nf La Fortuna Costa Rica https://www.facebook.com/fortunacostarica 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=unsubscribeuid=528a17b39bf348e3df10b064df474c25 para actualizar su correo http://ticosviajando.com/lista/?p=preferencesuid=528a17b39bf348e3df10b064df474c25 reenviar a un amigo http://ticosviajando.com/lista/?p=forwarduid=528a17b39bf348e3df10b064df474c25mid=35 -- powered by phpList, www.phplist.com --
Re: lower-subreg and IBM long double
On Mon, Jun 10, 2013 at 8:26 PM, Alan Modra amo...@gmail.com 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
On Mon, Jun 10, 2013 at 6:00 PM, David Edelsohn dje@gmail.com wrote: On Mon, Jun 10, 2013 at 8:26 PM, Alan Modra amo...@gmail.com 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
On Mon, Jun 10, 2013 at 06:31:55PM -0700, Andrew Pinski wrote: On Mon, Jun 10, 2013 at 6:00 PM, David Edelsohn dje@gmail.com wrote: On Mon, Jun 10, 2013 at 8:26 PM, Alan Modra amo...@gmail.com 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
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?
[Bug regression/53964] regression: sparc64 FreeBSD: /usr/ports/lang/gcc46/work/build/./prev-gcc/include/stddef.h:150:26: error: two or more data types n declaration specifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53964 Anton Shterenlikht mexas at bristol dot ac.uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Anton Shterenlikht mexas at bristol dot ac.uk --- Fixes 4.7 and 4.8 too, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308
[Bug middle-end/55308] /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol __emutls_v._ThreadRuneLocale
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308 Anton Shterenlikht mexas at bristol dot ac.uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #12 from Anton Shterenlikht mexas at bristol dot ac.uk --- Fixed by a binutils patch in the latest version, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53964
[Bug other/57482] [4.7.3][AVR] --help=optimizers reports a wrong list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57482 --- Comment #3 from Christophe christophe.beausoleil at sogeti dot com --- 2) -f[no-]short-enums is not an optimization option; Hum, I do not really agree although it is strongly related to ABI, no doubt. Anyway, it is a very special option as I can see in opts.c : /* Set this to a special uninitialized value. The actual default is set after target options have been processed. */ opts-x_flag_short_enums = 2; A few specific options are also treated here, but it seems to me that -fshort-enum is the only optimization option concerned. Am I wrong ? Could it be the only option which is not reported correctly by --help=optimizers ? Reading target.def is really instructive, but I still do not understand (yet) how the optimizations list is built, and how options are overwritten... All this is very confusing.
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 --- Comment #6 from Kai Koehne kai.koehne at digia dot com --- The issue is still there with 4.8.1 . It understand that the discussion on Kai Tietz' original patch has stalled ... Any suggestion on how we can move this forward?
[Bug target/57571] linux kernel function memcpy() execute with low efficiency on Intel Ivybridge platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57571 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-10 Ever confirmed|0 |1
[Bug tree-optimization/57567] Missed optimisation: compare + or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57567 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-10 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. ISTR Jakub did some work in this area.
[Bug rtl-optimization/57559] [4.9 Regression] S/390: ICE with lra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57559 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 Summary|S/390: ICE with lra |[4.9 Regression] S/390: ICE ||with lra
[Bug tree-optimization/57558] Issue with number of iterations calculation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57558 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Blocks||53947 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- That's because the first variant can loop infinitely for n == ULONG_MAX and that infinite cannot be represented using new induction variable as the vectorizer wants to. Well, not easily at least.
[Bug c++/41725] g++ accepts compounded unnamed type in template (violates 14.3.1-2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41725 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Do we have DR # for this issue?
[Bug c++/57390] Fixed point types on AVR are not available in C++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57390 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target||avr Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-10 CC||gjl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org --- It's not about enabling, it's about extending the C++ language and front end in GCC and maintaining such extension.
[Bug target/57501] [avr] generated collect2 crttn24a.o missing path with -mmcu=attiny24a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57501 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target|attiny24a |avr Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Host|Linux 3.9.2-1-ARCH x86_64 |x86_64-linux-gnu Resolution|--- |INVALID --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org --- This looks like an artifact of missing feature AVR-LibC #35407, cf. http://savannah.nongnu.org/bugs/?35407 In your installation there must be a directory avr/lib/avr25/tiny-stack and therein -- amongst others -- the object file crttn24a.
[Bug target/56987] gcc/config/avr/avr.opt:80: change - changed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56987 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target||avr Priority|P3 |P5 Status|UNCONFIRMED |ASSIGNED Keywords||documentation Last reconfirmed||2013-06-10 Component|translation |target CC||gjl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |gjl at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |trivial
[Bug c++/57576] New: Using declaration hides template for purposes of explicit instantiation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57576
Bug ID: 57576
Summary: Using declaration hides template for purposes of
explicit instantiation
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
The following is incorrectly rejected by all active releases:
namespace std
{
templatetypename T, typename U
void remove(T, U)
{ }
}
int remove(char);
namespace std
{
using ::remove;
}
namespace std
{
template void remove(int, long);
}
r.cc:17:33: error: ‘void std::remove(int, long int)’ is not declared in ‘std’
Reversing the order of the two declarations of std::remove makes it compile.
Using remove for the explicit instantiation makes it compile.
This causes
libstdc++-v3/testsuite/25_algorithms/remove/requirements/explicit_instantiation/2.cc
to fail in C++11 mode.
[Bug c++/57576] Using declaration hides template for purposes of explicit instantiation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57576 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-10 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Ah!
[Bug c++/57575] lvalue function accepted as an rvalue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57575
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com ---
Your assumptions are mistaken. In C++ it is valid to bind a function value to
an rvalue reference of that function type. It is only so, that binding to an
lvalue reference is preferred.
In other words, the following is valid as well:
float f() { return 0.f; }
float (r)(void) = f;
See for example [over.ics.ref] p3 (emphasis mine):
Except for an implicit object parameter, for which see 13.3.1, a standard
conversion sequence cannot be formed if it requires [..] binding an rvalue
reference to an lvalue **other than a function lvalue**.
[Bug other/57482] [4.7.3][AVR] --help=optimizers reports a wrong list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57482 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Christophe from comment #3) Reading target.def is really instructive, but I still do not understand (yet) how the optimizations list is built, and how options are overwritten... All this is very confusing. How options are set is a bit of a mess. For fshort-enums, there is the main definition in the c.opt file, there is the dummy value that denotes uninitialized in ./opts.c, and toplev.c that calls the target hook if short_enums is uninitialized. The options help list is built before calling the target hook, so it probably uses 2 and understands that as enabled. The way to fix this is to call process_options before print_specific_help (In fact, print_specific_help is called too early, --help=optimizers ignores everything that appears after it in the command-line). Ideally, the fact that fshort-enums requires a target hook to set its value if uninitialized should be encoded in the .opt files. And it should not use a magic uninitialized value 2, but opts_set to test whether the solution was set.
[Bug c++/57524] internal compiler error on dump translation unit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524 --- Comment #10 from James Michael DuPont JamesMikeDuPont at googlemail dot com --- I have reported the problem in the code to boost, they have fixed it. https://svn.boost.org/trac/boost/ticket/8651#comment:1 The problem is having to do with underspecifed namespace selection. They changed the code to remove the crash. mike
[Bug middle-end/57577] New: internal compiler error: tree check: expected class 'expression', have 'constant' (integer_cst) in tree_operand_check, at tree.h:4123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57577 Bug ID: 57577 Summary: internal compiler error: tree check: expected class 'expression', have 'constant' (integer_cst) in tree_operand_check, at tree.h:4123 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: anna.m.tikhonova at gmail dot com Created attachment 30284 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30284action=edit Reproducer Hi, attached test case fails with ICE: $ gcc -fcilkplus 1.c 1.c: In function 'main': 1.c:7:1: internal compiler error: tree check: expected class 'expression', have 'constant' (integer_cst) in tree_operand_check, at tree.h:4123 } ^ 0xae7d99 tree_class_check_failed(tree_node const*, tree_code_class, char const*, int, char const*) /home/anna/trunk/gcc/tree.c:9110 0x4c3cef expr_check /home/anna/trunk/gcc/tree.h:3859 0x4c3cef tree_operand_check /home/anna/trunk/gcc/tree.h:4123 0x531755 tree_operand_check(tree_node*, int, char const*, int, char const*) /home/anna/trunk/gcc/tree.h:4111 0x55255d build_array_notation_expr(unsigned int, tree_node*, tree_node*, tree_code, unsigned int, tree_node*, tree_node*) /home/anna/trunk/gcc/c/c-array-notation.c:1264 0x555cf8 expand_array_notation_exprs(tree_node*) /home/anna/trunk/gcc/c/c-array-notation.c:2777 0x555b90 expand_array_notation_exprs(tree_node*) /home/anna/trunk/gcc/c/c-array-notation.c:2765 0x5438f3 c_parser_compound_statement /home/anna/trunk/gcc/c/c-parser.c:4098 0x5447aa c_parser_declaration_or_fndef /home/anna/trunk/gcc/c/c-parser.c:1758 0x54958b c_parser_external_declaration /home/anna/trunk/gcc/c/c-parser.c:1363 0x549ff6 c_parser_translation_unit /home/anna/trunk/gcc/c/c-parser.c:1251 0x549ff6 c_parse_file() /home/anna/trunk/gcc/c/c-parser.c:11000 0x59c954 c_common_parse_file() /home/anna/trunk/gcc/c-family/c-opts.c:1046 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Compiler used is: Target: x86_64-unknown-linux-gnu Configured with: /home/anna/trunk/configure --with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld --enable-cloog-backend=isl --with-fpmath=sse --enable-languages=c,c++,fortran,java,lto Thread model: posix gcc version 4.9.0 20130608 (experimental) (GCC)
[Bug middle-end/57577] internal compiler error: tree check: expected class 'expression', have 'constant' (integer_cst) in tree_operand_check, at tree.h:4123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57577 --- Comment #1 from Anna anna.m.tikhonova at gmail dot com --- Also, when I change A[:] = foo (B[:][:]); to A[0] = foo (B[:][:]); compilation hangs.
[Bug middle-end/57541] [Cilkplus]: internal compiler error: in gimplify_expr, at gimplify.c:7809
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57541 --- Comment #5 from Anna anna.m.tikhonova at gmail dot com --- (In reply to Balaji V. Iyer from comment #4) Hello, This issue should be fixed in trunk revision 199837. Please let me know otherwise. Thanks, Balaji V. Iyer. Hi Balaji, I still can reproduce segfault mentioned in Comment 2.
[Bug middle-end/57541] [Cilkplus]: internal compiler error: in gimplify_expr, at gimplify.c:7809
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57541 --- Comment #6 from Anna anna.m.tikhonova at gmail dot com --- Created attachment 30285 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30285action=edit Another test case reproducing the original thing
[Bug middle-end/57541] [Cilkplus]: internal compiler error: in gimplify_expr, at gimplify.c:7809
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57541
--- Comment #7 from Anna anna.m.tikhonova at gmail dot com ---
(In reply to Anna from comment #6)
Created attachment 30285 [details]
Another test case reproducing the original thing
And another issue in slightly changed test case from this attachment:
int A[10];
int main () {
int a;
a = __sec_reduce_add ();
}
$ gcc -fcilkplus 1.c
1.c: In function 'main':
1.c:6:1: internal compiler error: tree check: accessed operand 4 of call_expr
with 3 operands in fix_builtin_array_notation_fn, at c/c-array-notation.c:158
}
^
0xaf30d7 tree_operand_check_failed(int, tree_node const*, char const*, int,
char const*)
/home/anna/trunk/gcc/tree.c:9258
0x54a7e6 tree_operand_check
/home/anna/trunk/gcc/tree.h:4125
0x54a7e6 fix_builtin_array_notation_fn
/home/anna/trunk/gcc/c/c-array-notation.c:158
0x5511ec build_array_notation_expr(unsigned int, tree_node*, tree_node*,
tree_code, unsigned int, tree_node*, tree_node*)
/home/anna/trunk/gcc/c/c-array-notation.c:731
0x555218 expand_array_notation_exprs(tree_node*)
/home/anna/trunk/gcc/c/c-array-notation.c:2311
0x554e50 expand_array_notation_exprs(tree_node*)
/home/anna/trunk/gcc/c/c-array-notation.c:2299
0x543d43 c_parser_compound_statement
/home/anna/trunk/gcc/c/c-parser.c:4098
0x544bfa c_parser_declaration_or_fndef
/home/anna/trunk/gcc/c/c-parser.c:1758
0x5499db c_parser_external_declaration
/home/anna/trunk/gcc/c/c-parser.c:1363
0x54a446 c_parser_translation_unit
/home/anna/trunk/gcc/c/c-parser.c:1251
0x54a446 c_parse_file()
/home/anna/trunk/gcc/c/c-parser.c:11000
0x59c024 c_common_parse_file()
/home/anna/trunk/gcc/c-family/c-opts.c:1046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
Compiler used to get Comment-5, Comment-6 and this issue is:
Target: x86_64-unknown-linux-gnu
Configured with: /home/anna/trunk/configure --with-arch=corei7
--with-cpu=corei7 --enable-clocale=gnu --with-system-zlib --enable-shared
--with-demangler-in-ld --enable-cloog-backend=isl --with-fpmath=sse
--enable-languages=c,c++,fortran,java,lto
Thread model: posix
gcc version 4.9.0 20130608 (experimental) (GCC)
[Bug middle-end/57541] [Cilkplus]: internal compiler error: in gimplify_expr, at gimplify.c:7809
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57541
--- Comment #8 from Anna anna.m.tikhonova at gmail dot com ---
Thing from Comment 1 is still reproducible with this case:
int A[10];
int main () {
int a;
a = __sec_reduce_add (1);
}
$ gcc -fcilkplus 1.c
1.c: In function 'main':
1.c:5:5: internal compiler error: in gimplify_var_or_parm_decl, at
gimplify.c:2042
a = __sec_reduce_add (1);
^
0x78b57b gimplify_var_or_parm_decl
/home/anna/trunk/gcc/gimplify.c:2042
0x78d24b gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/home/anna/trunk/gcc/gimplify.c:7565
0x798883 gimplify_modify_expr
/home/anna/trunk/gcc/gimplify.c:4851
0x78d213 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/home/anna/trunk/gcc/gimplify.c:7160
0x790836 gimplify_stmt(tree_node**, gimple_statement_d**)
/home/anna/trunk/gcc/gimplify.c:5692
0x78cafb gimplify_statement_list
/home/anna/trunk/gcc/gimplify.c:1521
0x78cafb gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/home/anna/trunk/gcc/gimplify.c:7549
0x790836 gimplify_stmt(tree_node**, gimple_statement_d**)
/home/anna/trunk/gcc/gimplify.c:5692
0x78cafb gimplify_statement_list
/home/anna/trunk/gcc/gimplify.c:1521
0x78cafb gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/home/anna/trunk/gcc/gimplify.c:7549
0x790836 gimplify_stmt(tree_node**, gimple_statement_d**)
/home/anna/trunk/gcc/gimplify.c:5692
0x78cafb gimplify_statement_list
/home/anna/trunk/gcc/gimplify.c:1521
0x78cafb gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/home/anna/trunk/gcc/gimplify.c:7549
0x790836 gimplify_stmt(tree_node**, gimple_statement_d**)
/home/anna/trunk/gcc/gimplify.c:5692
0x791ec1 gimplify_body(tree_node*, bool)
/home/anna/trunk/gcc/gimplify.c:8193
0x792376 gimplify_function_tree(tree_node*)
/home/anna/trunk/gcc/gimplify.c:8325
0x62951f analyze_function
/home/anna/trunk/gcc/cgraphunit.c:629
0x62c514 analyze_functions
/home/anna/trunk/gcc/cgraphunit.c:913
0x62d9c5 finalize_compilation_unit()
/home/anna/trunk/gcc/cgraphunit.c:2097
0x50a333 c_write_global_declarations()
/home/anna/trunk/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 http://gcc.gnu.org/bugs.html for instructions.
[Bug middle-end/57541] [Cilkplus]: internal compiler error: in gimplify_expr, at gimplify.c:7809
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57541
--- Comment #9 from Anna anna.m.tikhonova at gmail dot com ---
Issue that is very alike to issue mentioned in Comment 7:
int A[10];
int main () {
int a;
a = __sec_reduce (1);
}
$ gcc -fcilkplus 1.c
1.c: In function 'main':
1.c:6:1: internal compiler error: tree check: accessed operand 6 of call_expr
with 4 operands in fix_builtin_array_notation_fn, at c/c-array-notation.c:145
}
^
0xaf30d7 tree_operand_check_failed(int, tree_node const*, char const*, int,
char const*)
/home/anna/trunk/gcc/tree.c:9258
0x531b89 tree_operand_check(tree_node*, int, char const*, int, char const*)
/home/anna/trunk/gcc/tree.h:4125
0x54a9e7 fix_builtin_array_notation_fn
/home/anna/trunk/gcc/c/c-array-notation.c:145
0x5511ec build_array_notation_expr(unsigned int, tree_node*, tree_node*,
tree_code, unsigned int, tree_node*, tree_node*)
/home/anna/trunk/gcc/c/c-array-notation.c:731
0x555218 expand_array_notation_exprs(tree_node*)
/home/anna/trunk/gcc/c/c-array-notation.c:2311
0x554e50 expand_array_notation_exprs(tree_node*)
/home/anna/trunk/gcc/c/c-array-notation.c:2299
0x543d43 c_parser_compound_statement
/home/anna/trunk/gcc/c/c-parser.c:4098
0x544bfa c_parser_declaration_or_fndef
/home/anna/trunk/gcc/c/c-parser.c:1758
0x5499db c_parser_external_declaration
/home/anna/trunk/gcc/c/c-parser.c:1363
0x54a446 c_parser_translation_unit
/home/anna/trunk/gcc/c/c-parser.c:1251
0x54a446 c_parse_file()
/home/anna/trunk/gcc/c/c-parser.c:11000
0x59c024 c_common_parse_file()
/home/anna/trunk/gcc/c-family/c-opts.c:1046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug rtl-optimization/57569] [4.8/4.9 Regression] wrong code for struct copy at -O3 on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57569 --- Comment #2 from Michael Matz matz at gcc dot gnu.org --- My guess is that it's again somewhere using the wrong predicate to test directed rw/wr/ww dependencies.
[Bug c++/54207] [4.7 Regression][C++0x] ICE in build_noexcept_spec when bool is #defined/typedef'd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54207 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||ai.azuma at gmail dot com --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 52371 has been marked as a duplicate of this bug. ***
[Bug c++/52371] [C++11] ICE in noexcept with constexpr conversion function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52371 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 54207 ***
[Bug c++/52440] [C++11] Wrong template argument deduction/substitution failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52440 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed in 4.7.3. I'm adding the testcase and closing the bug.
[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Assignee|hubicka at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Jun 10 15:41:52 2013 New Revision: 199898 URL: http://gcc.gnu.org/viewcvs?rev=199898root=gccview=rev Log: PR target/56564 * varasm.c (align_variable): Don't use DATA_ALIGNMENT or CONSTANT_ALIGNMENT if !decl_binds_to_current_def_p (decl). Use DATA_ABI_ALIGNMENT for that case instead if defined. (get_variable_align): New function. (get_variable_section, emit_bss, emit_common, assemble_variable_contents, place_block_symbol): Use get_variable_align instead of DECL_ALIGN. (assemble_noswitch_variable): Add align argument, use it instead of DECL_ALIGN. (assemble_variable): Adjust caller. Use get_variable_align instead of DECL_ALIGN. * config/i386/i386.h (DATA_ALIGNMENT): Adjust x86_data_alignment caller. (DATA_ABI_ALIGNMENT): Define. * config/i386/i386-protos.h (x86_data_alignment): Adjust prototype. * config/i386/i386.c (x86_data_alignment): Add opt argument. If opt is false, only return the psABI mandated alignment increase. * config/c6x/c6x.h (DATA_ALIGNMENT): Renamed to... (DATA_ABI_ALIGNMENT): ... this. * config/mmix/mmix.h (DATA_ALIGNMENT): Renamed to... (DATA_ABI_ALIGNMENT): ... this. * config/mmix/mmix.c (mmix_data_alignment): Adjust function comment. * config/s390/s390.h (DATA_ALIGNMENT): Renamed to... (DATA_ABI_ALIGNMENT): ... this. * doc/tm.texi.in (DATA_ABI_ALIGNMENT): Document. * doc/tm.texi: Regenerated. * gcc.target/i386/pr56564-1.c: New test. * gcc.target/i386/pr56564-2.c: New test. * gcc.target/i386/pr56564-3.c: New test. * gcc.target/i386/pr56564-4.c: New test. * gcc.target/i386/avx256-unaligned-load-4.c: Add -fno-common. * gcc.target/i386/avx256-unaligned-store-1.c: Likewise. * gcc.target/i386/avx256-unaligned-store-3.c: Likewise. * gcc.target/i386/avx256-unaligned-store-4.c: Likewise. * gcc.target/i386/vect-sizes-1.c: Likewise. * gcc.target/i386/memcpy-1.c: Likewise. * gcc.dg/vect/costmodel/i386/costmodel-vect-31.c (tmp): Initialize. * gcc.dg/vect/costmodel/x86_64/costmodel-vect-31.c (tmp): Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr56564-1.c trunk/gcc/testsuite/gcc.target/i386/pr56564-2.c trunk/gcc/testsuite/gcc.target/i386/pr56564-3.c trunk/gcc/testsuite/gcc.target/i386/pr56564-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/c6x/c6x.h trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/mmix/mmix.c trunk/gcc/config/mmix/mmix.h trunk/gcc/config/s390/s390.h trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/costmodel/i386/costmodel-vect-31.c trunk/gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-vect-31.c trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-4.c trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-1.c trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-3.c trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-4.c trunk/gcc/testsuite/gcc.target/i386/memcpy-1.c trunk/gcc/testsuite/gcc.target/i386/vect-sizes-1.c trunk/gcc/varasm.c
[Bug c++/41725] g++ accepts compounded unnamed type in template (violates 14.3.1-2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41725 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- DR 62 clarified that G++ is correct here. http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#62
[Bug c++/41725] g++ accepts compounded unnamed type in template (violates 14.3.1-2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41725 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|SUSPENDED Resolution|INVALID |--- --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Jason Merrill from comment #5) DR 62 clarified that G++ is correct here. http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#62 Actually, it didn't really; this case is still unclear in the new wording for DR 62.
[Bug c++/52440] [C++11] Wrong template argument deduction/substitution failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52440 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.7.3, 4.8.0, 4.9.0 Resolution|--- |FIXED Target Milestone|--- |4.7.3 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug target/57578] New: SPE detection broken on Linux (bits/predefs.h: No such file or directory)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57578 Bug ID: 57578 Summary: SPE detection broken on Linux (bits/predefs.h: No such file or directory) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: stigge at antcom dot de SPE detection broken on Linux (bits/predefs.h: No such file or directory) The build of powerpc spe on Linux aborts like this: [...] /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -B/usr/lib/gcc-snapshot/powerpc-linux-gnuspe/bin/ -B/usr/lib/gcc-snapshot/powerpc-linux-gnuspe/lib/ -isystem /usr/lib/gcc-snapshot/powerpc-linux-gnuspe/include -isystem /usr/lib/gcc-snapshot/powerpc-linux-gnuspe/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -mlong-double-128 -mno-minimal-toc -I. -I. -I../.././gcc -I../../../src/libgcc -I../../../src/libgcc/. -I../../../src/libgcc/../gcc -I../../../src/libgcc/../include -I../../../src/libgcc/../libdecnumber/dpd -I../../../src/libgcc/../libdecnumber -DHAVE_CC_TLS -o _gcov_merge_single.o -MT _gcov_merge_single.o -MD -MP -MF _gcov_merge_single.dep -DL_gcov_merge_single -c ../../../src/libgcc/libgcov.c In file included from /usr/include/stdio.h:28:0, from ../../../src/libgcc/../gcc/tsystem.h:87, from ../../../src/libgcc/libgcov.c:27: /usr/include/features.h:323:26: fatal error: bits/predefs.h: No such file or directory #include bits/predefs.h ^ compilation terminated. [...] Turns out that the detection of the SPE case is done via rs6000/e500-double.h in $(tm_file_list), but e500-double.h was removed recently, and hence not added anymore to $(tm_file_list). However, in the SPE (i.e. e500v2) case, with_cpu is set exactly to 8548 in config.gcc. I solved this in gcc/config/rs6000/t-linux by replacing the line MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring rs6000/e500-double.h, $(tm_file_list)),,v1) with MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring 8548,$(with_cpu)),,v1) Thanks!
[Bug fortran/47680] [OOP] ICE with polymorphic array elements as dummy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47680 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Per comment #3, this PR should probably be closed.
[Bug fortran/48939] ICE in code involving procedure pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48939 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Works for me with revisions 4.6.4, 4.7.3, 4.8.1, and trunk. Closing as fixed.
[Bug fortran/49397] [F03] ICE with proc pointer assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49397 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-10 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 199873.
[Bug fortran/50539] Internal error gfc_match_entry(): Bad state (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50539 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-10 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 199873.
[Bug fortran/47680] [OOP] ICE with polymorphic array elements as dummy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47680 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #4) Per comment #3, this PR should probably be closed. Let's do it then.
[Bug fortran/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957 --- Comment #13 from Anthony Falzone prop_design at yahoo dot com --- My previous post needs a correction. Comparing gfortran O3 to Intel Fortran O3 I see a 60% speed improvement in favor of the Intel Fortran compiler. There is a 40% improvement over past releases of PROP_DESIGN, which used gfortran Ofast. There is not much difference between Intel Fortran O3 and Ofast, so I am using O3 to ensure accurate calculations.
[Bug tree-optimization/57539] [4.9 Regression] ice in ipa_edge_duplication_hook
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57539 --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org --- Created attachment 30286 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30286action=edit Proposed fix I'm currently bootstrapping and testing this patch to fix the issue. I'll give one more thought to creating a testcase for the testsuite but constructing one is not entirely trivial.
[Bug debug/48163] [4.7 Regression]: ICEs for cris-elf, like gcc.c-torture/compile/calls.c gcc.c-torture/execute/complex-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48163
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
vt_add_function_parameter needs to be adjusted after the assign_parms change:
if (!vt_get_decl_and_offset (incoming, decl, offset))
{
if (REG_P (incoming) || MEM_P (incoming))
{
/* This means argument is passed by invisible reference. */
offset = 0;
decl = parm;
incoming = gen_rtx_MEM (GET_MODE (decl_rtl), incoming);
}
else
{
if (!vt_get_decl_and_offset (decl_rtl, decl, offset))
return;
offset += byte_lowpart_offset (GET_MODE (incoming),
GET_MODE (decl_rtl));
}
}
This generates MEM of MEM incoming locations.
[Bug c++/57579] New: Problem with vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57579
Bug ID: 57579
Summary: Problem with vectorization
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.carminati at cern dot ch
Good evening,
all my apologises if this is a stupid question, however I have a terribly
simple loop
include math.h
typedef struct
{
double x,y,z;
double dummy;
} P;
void foo(const P * __restrict__ points, double * __restrict__ d)
{
for(int i=0;i100;++i) {
d[i]=points[i].x*points[i].x*points[i].x*points[i].x+
points[i].y*points[i].y*points[i].y+
points[i].z*points[i].z*points[i].z;
}
}
if I compile with
/opt/gcc-4.8.1/bin/g++ -c -std=c++0x -O3 -msse4.1 -Wall -Wstrict-aliasing=2
-ftree-vectorizer-verbose=2
I obtain the diagnostic at the bottom of the page. Is there a place where I can
find an explanation for the g++ vectorizer diagnostic messages? I frankly do
not understand what it is talking about and google does not seem to be willing
to help me this time. Any help in deciphering these messages would be greatly
appreciated. Thanks and sorry for the bother
Analyzing loop at testvec1.cxx:12
testvec1.cxx:12: note: Data access with gaps requires scalar epilogue loop
testvec1.cxx:12: note: vector alignment may not be reachable
testvec1.cxx:12: note: virtual phi. skip.
testvec1.cxx:12: note: not ssa-name.
testvec1.cxx:12: note: use not simple.
testvec1.cxx:12: note: not ssa-name.
testvec1.cxx:12: note: use not simple.
testvec1.cxx:12: note: no array mode for V2DF[4]
testvec1.cxx:12: note: not ssa-name.
testvec1.cxx:12: note: use not simple.
testvec1.cxx:12: note: not ssa-name.
testvec1.cxx:12: note: use not simple.
testvec1.cxx:12: note: no array mode for V2DF[4]
testvec1.cxx:12: note: not ssa-name.
testvec1.cxx:12: note: use not simple.
testvec1.cxx:12: note: not ssa-name.
testvec1.cxx:12: note: use not simple.
testvec1.cxx:12: note: no array mode for V2DF[4]
Vectorizing loop at testvec1.cxx:12
testvec1.cxx:12: note: virtual phi. skip.
testvec1.cxx:12: note: no array mode for V2DF[4]
testvec1.cxx:12: note: no array mode for V2DF[4]
testvec1.cxx:12: note: no array mode for V2DF[4]
testvec1.cxx:10: note: vectorized 1 loops in function.
testvec1.cxx:10: note: not vectorized: not enough data-refs in basic block.
testvec1.cxx:13: note: not vectorized: no vectype for stmt: vect_var_.10_29 =
MEM[(const struct P *)vect_ppoints.6_31];
scalar_type: const vector(2) double
testvec1.cxx:13: note: Failed to SLP the basic block.
testvec1.cxx:13: note: not vectorized: failed to find SLP opportunities in
basic block.
testvec1.cxx:13: note: Build SLP failed: grouped loads have gaps _59 = _60-x;
testvec1.cxx:13: note: Failed to SLP the basic block.
testvec1.cxx:13: note: not vectorized: failed to find SLP opportunities in
basic block.
testvec1.cxx:10: note: not vectorized: not enough data-refs in basic block.
[Bug target/57379] [4.9 Regression]: Segfault in invalidate_any_buried_refs (x=0x0) at ../../gcc-svn/trunk/gcc/gcse.c:3850
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57379 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|4.9.0 |4.7.4 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- Fixed in mainline and backported to 4.8.1 and 4.7.4 branches.
[Bug c++/57575] lvalue function accepted as an rvalue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57575
Anass Lasram anass.lasram at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Anass Lasram anass.lasram at gmail dot com ---
(In reply to Daniel Krügler from comment #1)
Your assumptions are mistaken. In C++ it is valid to bind a function value
to an rvalue reference of that function type. It is only so, that binding to
an lvalue reference is preferred.
In other words, the following is valid as well:
float f() { return 0.f; }
float (r)(void) = f;
See for example [over.ics.ref] p3 (emphasis mine):
Except for an implicit object parameter, for which see 13.3.1, a standard
conversion sequence cannot be formed if it requires [..] binding an rvalue
reference to an lvalue **other than a function lvalue**.
Thanks Daniel for the rectification.
[Bug preprocessor/57580] New: Repeated _Pragma message directives in macro causes problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57580 Bug ID: 57580 Summary: Repeated _Pragma message directives in macro causes problems Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: drussel at gmail dot com Input: #define BROKEN\ _Pragma(message(\message0\)) \ _Pragma(message(\message1\)) BROKEN Output: gcc -c test.cpp test.cpp:5:2: error: stray ‘#’ in program test.cpp:5:27: note: #pragma message: message0 test.cpp:5:3: error: ‘pragma’ does not name a type gcc 4.6.3 and clang are both happy with the code.
[Bug regression/57551] [4.9 Regression]: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57551 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Assignee|jason at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Reassigning since Honza has been working on this.
[Bug tree-optimization/57579] Problem with vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57579 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|federico.carminati at cern dot ch | Component|c++ |tree-optimization --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- In any case, doesn't look like a C++ front end issue
[Bug debug/37132] Debug: No DW_TAG_namelist emitted for NAMELISTS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37132 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org --- New draft patch: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00534.html
[Bug c++/57581] New: abi_tag vs. demangler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57581
Bug ID: 57581
Summary: abi_tag vs. demangler
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bkoz at gcc dot gnu.org
Some member functions in libstdc++ have been decorated with the abi_tag
attribute.
Any abi_tag attribution renders these names unable to be demangled.
For instance:
iterator
erase(const_iterator __first, const_iterator __last)
{ return _M_t.erase(__first, __last); }
For set turns from:
_ZNSt3setIiSt4lessIiESaIiEE5eraseESt23_Rb_tree_const_iteratorIiES5_
into:
_ZNSt3setIiSt4lessIiESaIiEE5eraseB5cxx11ESt23_Rb_tree_const_iteratorIiES5_
The first can be de-mangled into:
std::setint, std::lessint, std::allocatorint
::erase(std::_Rb_tree_const_iteratorint, std::_Rb_tree_const_iteratorint)
The second, not so much.
[Bug c++/57581] abi_tag vs. demangler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57581 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- Try using a newer demangler. $ ./cxxfilt _ZNSt3setIiSt4lessIiESaIiEE5eraseB5cxx11ESt23_Rb_tree_const_iteratorIiES5_ std::setint, std::lessint, std::allocatorint ::erase[abi:cxx11](std::_Rb_tree_const_iteratorint, std::_Rb_tree_const_iteratorint)
[Bug fortran/52332] Internal compiler error in in gfc_get_symbol_decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52332 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-10 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Self contained reduced test module m_xfunit_assertion_character implicit none private public t_string, character, t_xfunit_assertion, t_xfunit_assertion_character type t_string private character, dimension(:), allocatable :: string ! String buffer integer :: length = 0 ! String length integer :: size = 0 ! Total buffer size end type t_string type, abstract :: t_xfunit_assertion end type t_xfunit_assertion type, extends(t_xfunit_assertion) :: t_xfunit_assertion_character private contains procedure :: get_expected end type t_xfunit_assertion_character interface character module procedure string_to_char end interface character contains elemental function string_to_char( s ) result(res) type(t_string),intent(in) :: s character(len=size(s%string)) :: res end function string_to_char pure function get_expected( ast ) result(res) class(t_xfunit_assertion_character), intent(in) :: ast type(t_string) :: res end function get_expected end module m_xfunit_assertion_character module m_xfunit_assertion_array_character use m_xfunit_assertion_character implicit none private public t_xfunit_assertion_array_character type, extends(t_xfunit_assertion) :: t_xfunit_assertion_array_character private type(t_xfunit_assertion_character), dimension(:), allocatable :: rast contains procedure :: get_expected end type t_xfunit_assertion_array_character contains pure function get_expected( ast ) result(res) class(t_xfunit_assertion_array_character), intent(in) :: ast character, dimension(size(ast%rast)) :: res integer :: i res = (/ (character(ast%rast(i)%get_expected()), i=1, size(ast%rast)) /) end function get_expected end module m_xfunit_assertion_array_character
RE: new mul* patterns U constraint in rl78
Hi DJ, Uses a U constraint. What should that constraint do? Could you post a patch to add it? The U constraint was part of a source tree we worked on previously. I have provided the patch for it below. I have also set the valloc attribute for the multiplication insns to 'umul'. Would that be the correct setting as 'macax' is used for the other SI multiplication insns which seem to also include accumulation? Please let me know if OK. Thanks Regards, Kaushik 2013-06-10 Kaushik Phatak kaushik.pha...@kpitcummins.com * config/rl78/constraints.md (U): New constraint. * config/rl78/rl78.md (mulqi3_rl78,mulhi3_rl78,mulhi3_g13): Add valloc attribute. Index: gcc/config/rl78/constraints.md === --- gcc/config/rl78/constraints.md (revision 199879) +++ gcc/config/rl78/constraints.md (working copy) @@ -256,6 +256,19 @@ (match_test !rl78_far_p (op) rl78_as_legitimate_address (VOIDmode, XEXP (op, 0), true, ADDR_SPACE_GENERIC))) ) +(define_memory_constraint U + memory references valid with mov to/from a/ax + (and (match_code mem) + (match_test rl78_virt_insns_ok () +|| satisfies_constraint_Wab (op) +|| satisfies_constraint_Wbc (op) +|| satisfies_constraint_Wde (op) +|| satisfies_constraint_Wd2 (op) +|| satisfies_constraint_Whl (op) +|| satisfies_constraint_Wh1 (op) +|| satisfies_constraint_Whb (op) +|| satisfies_constraint_Ws1 (op) +|| satisfies_constraint_Wfr (op) ))) (define_memory_constraint Qbi built-in compare types Index: gcc/config/rl78/rl78.md === --- gcc/config/rl78/rl78.md (revision 199879) +++ gcc/config/rl78/rl78.md (working copy) @@ -276,6 +276,7 @@ mova, x mov%h0, a ; end of mulqi macro + [(set_attr valloc umul)] ) (define_insn *mulhi3_rl78 @@ -290,6 +291,7 @@ mulhu ; bcax = bc * ax movw%h0, ax ; end of mulhi macro + [(set_attr valloc umul)] ) (define_insn *mulhi3_g13 @@ -309,6 +311,7 @@ movwax, 0x6 ; MDBL movw%h0, ax ; end of mulhi macro + [(set_attr valloc umul)] ) ;; 0x0 is MACR(L). 0x2 is MACR(H) but we don't care about it
Re: RFA: Switching LRA on for s390
On 08/06/13 20:41, Vladimir Makarov wrote: On 13-06-07 11:12 AM, Vladimir Makarov wrote: On 13-06-07 10:57 AM, Andreas Krebbel wrote: I've applied the attached patch. This helps me getting a little further when bootstrapping with lra and --with-arch=zEC12. 2013-06-07 Andreas Krebbel andreas.kreb...@de.ibm.com * config/s390/s390.md (cpu_facility): Add cpu_zarch. (*movmem_short, *clrmem_short, *cmpmem_short): Use cpu_zarch for last alternative in the cpu_facility attribute. --- gcc/config/s390/s390.md | 13 ! 1 file changed, 4 insertions(+), 9 modifications(!) Thanks, Andreas. I am not a specialist in 390 architecture. You are the expert. I'll check the bootstrap with this option too on a machine available for me. I've checked the bootstrap without any -with-arch option before submitting the patch for approval. If I find some problems, I'll work on them too. I'll work on PR57599 you just reported too. I've fixed PR57599. Unfortunately, I can not bootstrap with --with-arch=zEC12 as a machine available for me does not support this subtarget. Thanks. I would be happy to test the patch for you. Bye, -Andreas-
Re: [GOOGLE] More strict checking for call args
Hi, On Thu, Jun 06, 2013 at 08:10:13AM -0700, Dehao Chen wrote: Hi, Martin, Yes, your patch can fix my case. Thanks a lot for the fix. good. However, as usual when I'm trying to do things too quickly, I made a stupid mistaker and testing has revealed I picked exactly the wrong branch in the second hunk. So this is the correct patch, now after proper bootstrapping and testing on x86_64-linux. Since the intent is clearly the same as the approved patch, I intend to commit it later today/early tomorrow, unless there are any objections. Thanks and sorry again, Martin 2013-06-07 Martin Jambor mjam...@suse.cz * ipa-cp.c (ipa_get_indirect_edge_target_1): Check that param_index is within bounds at the beginning of the function. Index: src/gcc/ipa-cp.c === --- src.orig/gcc/ipa-cp.c +++ src/gcc/ipa-cp.c @@ -1481,7 +1481,8 @@ ipa_get_indirect_edge_target_1 (struct c tree otr_type; tree t; - if (param_index == -1) + if (param_index == -1 + || known_vals.length () = (unsigned int) param_index) return NULL_TREE; if (!ie-indirect_info-polymorphic) @@ -1516,8 +1517,7 @@ ipa_get_indirect_edge_target_1 (struct c t = NULL; } else - t = (known_vals.length () (unsigned int) param_index -? known_vals[param_index] : NULL); + t = known_vals[param_index]; if (t TREE_CODE (t) == ADDR_EXPR
Re: [RFC] Implement Undefined Behavior Sanitizer (take 2)
On Sat, Jun 08, 2013 at 07:48:27PM +0200, Marc Glisse wrote:
+ tt = fold_build2 (EQ_EXPR, boolean_type_node, op1,
+integer_minus_one_node);
Don't we usually try to have both operands of a comparison of the
same type?
Will fix.
+ t = fold_build2 (EQ_EXPR, boolean_type_node, op0,
+ TYPE_MIN_VALUE (TREE_TYPE (op0)));
I didn't see where this test was restricted to the signed case
(0u/-1 is well defined)?
Will fix.
+ t = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, t, tt);
+ tt = build2 (EQ_EXPR, boolean_type_node,
+ op1, integer_zero_node);
Why not fold this one?
Sure, will do.
Name unsigned_type_for (TREE_TYPE (op1)) and TYPE_PRECISION
(TREE_TYPE (op0)) that are used several times?
Yeah.
@@ -4070,8 +4077,15 @@ cp_build_binary_op (location_t location,
{
enum tree_code tcode0 = code0, tcode1 = code1;
tree cop1 = fold_non_dependent_expr_sfinae (op1, tf_none);
+ cop1 = maybe_constant_value (cop1);
- warn_for_div_by_zero (location, maybe_constant_value (cop1));
+ if (!processing_template_decl tcode0 == INTEGER_TYPE
+ (TREE_CODE (cop1) != INTEGER_CST
+ || integer_zerop (cop1)
+ || integer_minus_onep (cop1)))
+doing_div_or_mod = true;
Aren't you already doing this test in ubsan_instrument_division?
Yep, I'll throw it out of cp/typeck.c.
Thanks for the review!
Marek
Re: [RFC] Implement Undefined Behavior Sanitizer (take 2)
On Mon, Jun 10, 2013 at 11:24:16AM +0200, Marek Polacek wrote:
@@ -4070,8 +4077,15 @@ cp_build_binary_op (location_t location,
{
enum tree_code tcode0 = code0, tcode1 = code1;
tree cop1 = fold_non_dependent_expr_sfinae (op1, tf_none);
+cop1 = maybe_constant_value (cop1);
-warn_for_div_by_zero (location, maybe_constant_value (cop1));
+if (!processing_template_decl tcode0 == INTEGER_TYPE
+ (TREE_CODE (cop1) != INTEGER_CST
+|| integer_zerop (cop1)
+|| integer_minus_onep (cop1)))
+ doing_div_or_mod = true;
Aren't you already doing this test in ubsan_instrument_division?
Yep, I'll throw it out of cp/typeck.c.
Note that the above one actually performs more than what you do in
ubsan_instrument_division, because it works on maybe_constant_value result.
So, perhaps typeck.c should ensure that the ubsan functions are always
called with arguments passed through
maybe_constant_value (fold_non_dependent_expr_sfinae (opX, tf_none)).
Jakub
Re: [RFC] Implement Undefined Behavior Sanitizer (take 2)
On Mon, Jun 10, 2013 at 11:32:22AM +0200, Jakub Jelinek wrote:
On Mon, Jun 10, 2013 at 11:24:16AM +0200, Marek Polacek wrote:
@@ -4070,8 +4077,15 @@ cp_build_binary_op (location_t location,
{
enum tree_code tcode0 = code0, tcode1 = code1;
tree cop1 = fold_non_dependent_expr_sfinae (op1, tf_none);
+ cop1 = maybe_constant_value (cop1);
- warn_for_div_by_zero (location, maybe_constant_value (cop1));
+ if (!processing_template_decl tcode0 == INTEGER_TYPE
+ (TREE_CODE (cop1) != INTEGER_CST
+ || integer_zerop (cop1)
+ || integer_minus_onep (cop1)))
+doing_div_or_mod = true;
Aren't you already doing this test in ubsan_instrument_division?
Yep, I'll throw it out of cp/typeck.c.
Note that the above one actually performs more than what you do in
ubsan_instrument_division, because it works on maybe_constant_value result.
So, perhaps typeck.c should ensure that the ubsan functions are always
called with arguments passed through
maybe_constant_value (fold_non_dependent_expr_sfinae (opX, tf_none)).
Ah, ok, will add it there. Thanks.
Marek
[Patch wwwdocs] gcc-4.9 changes: mention support of the Intel Silvermont microarchitecture
Hi! This patch mentions support of Silvermont architecture in the gcc-4.9/changes.html page. OK to install? Thanks, Igor Index: htdocs/gcc-4.9/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v retrieving revision 1.17 diff -c -1 -r1.17 changes.html *** htdocs/gcc-4.9/changes.html 6 Jun 2013 11:15:24 - 1.17 --- htdocs/gcc-4.9/changes.html 10 Jun 2013 10:11:24 - *** *** 177,178 --- 177,185 + h3IA-32/x86-64/h3 + ul + li GCC now supports new Intel microarchitecture named Silvermont + through code-march=slm/code. + /li + /ul + h3 id=rxRX/h3
Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)
On 06/07/2013 10:43 PM, Richard Henderson wrote: But these I think require a good hard look to see if they really intended an ABI alignment: c6x comment explicitly mentions abi The ABI specifies a minimum alignment for arrays. Bernd
[PATCH][ARM][6/n] Partial IT block deprecation in ARMv8 AArch32 - VFP patterns
Hi all, This patch makes the changes to the various floating point patterns in vfp.md. Since pretty much all floating point instruction are always encoded in 32 bits, they cannot be used inside an IT block by the -mrestrict-it rules. Therefore this patch just goes and disables the predicable variants of the offending VFP patterns. The conditional floating point move patterns are disabled altogether for arm_restrict_it because they explicitly use IT blocks in their output template and the corresponding expanders in arm.md are updated to make sure we use the new vsel instruction that is available in ARMv8 when appropriate. Tested arm-none-eabi on qemu and model as part of the whole series and also independently bootstrapped with -mrestrict-it enabled on a Cortex-A15. Ok for trunk? Thanks, Kyrill 2013-06-10 Kyrylo Tkachov kyrylo.tkac...@arm.com * config/arm/predicates.md (arm_cond_move_operator): New predicate. * config/arm/arm.md (movsfcc): Use arm_cond_move_operator predicate. (movdfcc): Likewise. * config/arm/vfp.md (*thumb2_movsf_vfp): Disable predication for arm_restrict_it. (*thumb2_movsfcc_vfp): Disable for arm_restrict_it. (*thumb2_movdfcc_vfp): Likewise. (*abssf2_vfp, *absdf2_vfp, *negsf2_vfp, *negdf2_vfp, *addsf3_vfp, *adddf3_vfp, *subsf3_vfp, *subdf3_vfpc, *divsf3_vfp, *divdf3_vfp, *mulsf3_vfp, *muldf3_vfp, *mulsf3negsf_vfp, *muldf3negdf_vfp, *mulsf3addsf_vfp, *muldf3adddf_vfp, *mulsf3subsf_vfp, *muldf3subdf_vfp, *mulsf3negsfaddsf_vfp, *fmuldf3negdfadddf_vfp, *mulsf3negsfsubsf_vfp, *muldf3negdfsubdf_vfp, *fmaSDF:mode4, *fmsubSDF:mode4, *fnmsubSDF:mode4, *fnmaddSDF:mode4, *extendsfdf2_vfp, *truncdfsf2_vfp, *extendhfsf2, *truncsfhf2, *truncsisf2_vfp, *truncsidf2_vfp, fixuns_truncsfsi2, fixuns_truncdfsi2, *floatsisf2_vfp, *floatsidf2_vfp, floatunssisf2, floatunssidf2, *sqrtsf2_vfp, *sqrtdf2_vfp, *cmpsf_vfp, *cmpsf_trap_vfp, *cmpdf_vfp, *cmpdf_trap_vfp, vrint_patternSDF:mode2): Disable predication for arm_restrict_it. it-depr-vfp.patch Description: Binary data
Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)
On Mon, Jun 10, 2013 at 12:51:05PM +0200, Bernd Schmidt wrote: On 06/07/2013 10:43 PM, Richard Henderson wrote: But these I think require a good hard look to see if they really intended an ABI alignment: c6x comment explicitly mentions abi The ABI specifies a minimum alignment for arrays. Thus after the patch c6x.h (DATA_ALIGNMENT) should be renamed to DATA_ABI_ALIGNMENT, right? Jakub
Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)
On 06/10/2013 12:55 PM, Jakub Jelinek wrote: On Mon, Jun 10, 2013 at 12:51:05PM +0200, Bernd Schmidt wrote: On 06/07/2013 10:43 PM, Richard Henderson wrote: But these I think require a good hard look to see if they really intended an ABI alignment: c6x comment explicitly mentions abi The ABI specifies a minimum alignment for arrays. Thus after the patch c6x.h (DATA_ALIGNMENT) should be renamed to DATA_ABI_ALIGNMENT, right? I think so. Bernd
Re: [Patch wwwdocs] gcc-4.9 changes: mention support of the Intel Silvermont microarchitecture
Igor Zamyatin wrote:
+ li GCC now supports new Intel microarchitecture named Silvermont
+ through code-march=slm/code.
Not related to the release notes, but I think it should also be added to
gcc/doc/invoke.texi's @item -march=@var{cpu-type} - presumably after
the item:
@item atom
Intel Atom CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3
instruction set support.
Tobias
Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)
Richard Henderson wrote: s390 comment mentions LARL instruction On s390(x) it is indeed an ABI requirement that all global symbols are at least 2-aligned. (Note that we skip that alignment requirement if a symbol is marked as attribute((aligned(1)), but that attribute must then be present for every use, too.) Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
[PATCH] Do not redirect ld stdout/stderr in collect2 with -debug
This fixes one very annoying thing collect2 does when trying to
debug LTO WPA issues. Even with -v you need to wait until all
LTRANS stages completed to see the lto1 -fwpa invocation which
is because collect2 buffers and replays stdout/stderr of ld
(to avoid duplicating that in some cases). But I really want
to see the output immediately but there is no way to do that.
The easiest is to disable the buffering with -debug (that is,
-Wl,-debug to the -flto driver command line).
Tested with/without -debug.
Ok for trunk?
Thanks,
Richard.
2013-06-10 Richard Biener rguent...@suse.de
* collect2.c (main): Do not redirect ld stdout/stderr when
debugging.
Index: gcc/collect2.c
===
--- gcc/collect2.c (revision 199732)
+++ gcc/collect2.c (working copy)
@@ -1189,8 +1189,11 @@ main (int argc, char **argv)
#ifdef COLLECT_EXPORT_LIST
export_file = make_temp_file (.x);
#endif
- ldout = make_temp_file (.ld);
- lderrout = make_temp_file (.le);
+ if (!debug)
+{
+ ldout = make_temp_file (.ld);
+ lderrout = make_temp_file (.le);
+}
*c_ptr++ = c_file_name;
*c_ptr++ = -x;
*c_ptr++ = c;
Document Intel Silvermont support in invoke.texi
Hi! Following patch documents Intel Silvermont support. OK to install? Thanks, Igor Changelog: 2013-06-10 Igor Zamyatin igor.zamya...@intel.com * doc/invoke.texi: Document slm. diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index b7b32f7..e4f1d45 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -13837,6 +13837,10 @@ set support. Intel Atom CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support. +@item slm +Intel Silvermont CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3, +SSE4.1, SSE4.2 instruction set support. + @item k6 AMD K6 CPU with MMX instruction set support.
Re: Document Intel Silvermont support in invoke.texi
On Mon, Jun 10, 2013 at 3:25 PM, Igor Zamyatin izamya...@gmail.com wrote: Following patch documents Intel Silvermont support. OK to install? Thanks, Igor Changelog: 2013-06-10 Igor Zamyatin igor.zamya...@intel.com * doc/invoke.texi: Document slm. diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index b7b32f7..e4f1d45 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -13837,6 +13837,10 @@ set support. Intel Atom CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support. +@item slm +Intel Silvermont CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3, +SSE4.1, SSE4.2 instruction set support. SSE4.1 and SSE4.2 instruction set support. OK with this change. Thanks, Uros.
Re: Document Intel Silvermont support in invoke.texi
On Mon, Jun 10, 2013 at 05:25:36PM +0400, Igor Zamyatin wrote: Following patch documents Intel Silvermont support. OK to install? 2013-06-10 Igor Zamyatin igor.zamya...@intel.com * doc/invoke.texi: Document slm. diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index b7b32f7..e4f1d45 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -13837,6 +13837,10 @@ set support. Intel Atom CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support. +@item slm +Intel Silvermont CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3, +SSE4.1, SSE4.2 instruction set support. Shouldn't it also list MOVBE (similarly for atom and core-avx2, btver2 already lists it). core-avx2 isn't even documented at all in invoke.texi. Jakub
Re: [RFA PATCH, alpha]: Fix PR 57379, segfault in invalidate_any_buried_refs
On Thu, May 23, 2013 at 7:20 PM, Richard Henderson r...@redhat.com wrote: On 05/23/2013 12:38 AM, Uros Bizjak wrote: 2013-05-23 Uros Bizjak ubiz...@gmail.com * config/alpha/alpha.md (unspec): Add UNSPEC_XFLT_COMPARE. * config/alpha/alpha.c (alpha_emit_xfloating_compare): Construct REG_EQUAL note as UNSPEC_XFLT_COMPARE unspec. Patch was bootstrapped and regression tested on alphaev68-linux-gnu. OK for mainline and release branches? [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57379 Ok. Actually, backport uncovered the problem with different compares, which now shared the same REG_EQUAL note. Attached patch fixes this oversight. 2013-06-10 Uros Bizjak ubiz...@gmail.com * config/alpha/alpha.c (alpha_emit_xfloating_compare): Also use cmp_code to construct REG_EQUAL note. Tested on alphaev68-pc-linux-gnu and committed to mainline SVN. Uros. Index: alpha.c === --- alpha.c(revision 199788) +++ alpha.c(working copy) @@ -3068,7 +3068,8 @@ alpha_emit_xfloating_compare (enum rtx_code *pcode out = gen_reg_rtx (DImode); /* What's actually returned is -1,0,1, not a proper boolean value. */ - note = gen_rtx_UNSPEC (DImode, gen_rtvec (2, op0, op1), UNSPEC_XFLT_COMPARE); + note = gen_rtx_fmt_ee (cmp_code, VOIDmode, op0, op1); + note = gen_rtx_UNSPEC (DImode, gen_rtvec (1, note), UNSPEC_XFLT_COMPARE); alpha_emit_xfloating_libcall (func, out, operands, 2, note); return out;
Re: [RFC] Implement Undefined Behavior Sanitizer (take 2)
On Sat, 8 Jun 2013, Marek Polacek wrote: + if (code == LSHIFT_EXPR + !TYPE_UNSIGNED (TREE_TYPE (op0)) + (flag_isoc99 || flag_isoc11)) flag_isoc11 implies flag_isoc99, you only need to check flag_isoc99 here. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Fix for PR c/57563
On Sun, 9 Jun 2013, Iyer, Balaji V wrote: Attached, please find a patch that will fix the bug reported in PR 57563. There are a couple issues that went wrong. First, in the test case, we have a double multiplied to a double. When -std=c99 flag is used, they get converted to long double. The way to fix this is to add a type cast to the array notation to the same type as identity variable and thus they will all be double. You don't say what the actual error was, and neither does the original PR. But if it was an ICE from an EXCESS_PRECISION_EXPR getting to the gimplifier, that suggests that c_fully_fold isn't getting called somewhere it should be - and probably calling c_fully_fold is the correct fix rather than inserting a cast. If you can get such ICEs for EXCESS_PRECISION_EXPR, it's quite possible you might get them for C_MAYBE_CONST_EXPR as well (e.g. try using 0 / 0, or compound literals of variably modified type, in various places in the affected expressions), which should be fixed by using c_fully_fold but not by inserting a cast. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Do not redirect ld stdout/stderr in collect2 with -debug
On Mon, 10 Jun 2013, Richard Biener wrote: This fixes one very annoying thing collect2 does when trying to debug LTO WPA issues. Even with -v you need to wait until all LTRANS stages completed to see the lto1 -fwpa invocation which is because collect2 buffers and replays stdout/stderr of ld (to avoid duplicating that in some cases). But I really want to see the output immediately but there is no way to do that. The easiest is to disable the buffering with -debug (that is, -Wl,-debug to the -flto driver command line). Tested with/without -debug. Ok for trunk? OK. -- Joseph S. Myers jos...@codesourcery.com
Re: [c++-concepts] code review
On 2013-06-09 20:34 , Gabriel Dos Reis wrote: So, my advice is for GCC source code to forget about the cxxx headers for the most part. I can see an instance where cmath or cstring would make a difference but given point (1) above, no it doesn't. Just use the traditional xxx.h headers and be done with it. Maybe I should have included this in our C++ coding standards, but I don't know how Benjamin, Lawrence, and Diego fee about it. Sounds reasonable to me. Diego.
Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)
On 06/07/2013 02:14 PM, Jakub Jelinek wrote:
When the linker merges common blocks, it chooses both maximum size and
maximum
alignment. Thus for any common block for which we can prove the block must
reside in the module (any executable, or hidden common in shared object),
we
can go ahead and use the increased alignment.
But consider say:
one TU:
struct S { char buf[15]; } s __attribute__((aligned (32)));
another TU:
char c = 7;
struct S { char buf[15]; } s = { { 1, 2 } };
char d = 8;
int main () { return 0; }
(the aligned(32) is there just to simulate the DATA_ALIGNMENT optimization
increase). Linker warns about this (thus the question is if we want to
increase the alignment for optimization on commons at all) and doesn't align
it.
Oh, right. I hadn't considered commons unifying with non-common variables,
and the failure of commoning in that case. I'd mostly been thinking of
uninitialized Fortran-like common blocks, where it is more common for the
blocks to have nothing in common but the name.
r~
RE: [PATCH] Fix for PR c/57563
-Original Message- From: Joseph Myers [mailto:jos...@codesourcery.com] Sent: Monday, June 10, 2013 10:40 AM To: Iyer, Balaji V Cc: gcc-patches@gcc.gnu.org; Jakub Jelinek; mpola...@gcc.gnu.org Subject: Re: [PATCH] Fix for PR c/57563 On Sun, 9 Jun 2013, Iyer, Balaji V wrote: Attached, please find a patch that will fix the bug reported in PR 57563. There are a couple issues that went wrong. First, in the test case, we have a double multiplied to a double. When -std=c99 flag is used, they get converted to long double. The way to fix this is to add a type cast to the array notation to the same type as identity variable and thus they will all be double. You don't say what the actual error was, and neither does the original PR. But if it was an ICE from an EXCESS_PRECISION_EXPR getting to the gimplifier, that suggests that c_fully_fold isn't getting called somewhere it should be - and probably calling c_fully_fold is the correct fix rather than inserting a cast. If you can get such ICEs for EXCESS_PRECISION_EXPR, it's quite possible you might get them for C_MAYBE_CONST_EXPR as well (e.g. try using 0 / 0, or compound literals of variably modified type, in various places in the affected expressions), which should be fixed by using c_fully_fold but not by inserting a cast. It was not. It was actually a type mismatch between double and long double caught in verify_gimple_in_seq function. So, is it OK for trunk? Thanks, Balaji V. Iyer. -- Joseph S. Myers jos...@codesourcery.com
RE: [PATCH] Fix for PR c/57563
On Mon, 10 Jun 2013, Iyer, Balaji V wrote: You don't say what the actual error was, and neither does the original PR. But if it was an ICE from an EXCESS_PRECISION_EXPR getting to the gimplifier, that suggests that c_fully_fold isn't getting called somewhere it should be - and probably calling c_fully_fold is the correct fix rather than inserting a cast. If you can get such ICEs for EXCESS_PRECISION_EXPR, it's quite possible you might get them for C_MAYBE_CONST_EXPR as well (e.g. try using 0 / 0, or compound literals of variably modified type, in various places in the affected expressions), which should be fixed by using c_fully_fold but not by inserting a cast. It was not. It was actually a type mismatch between double and long double caught in verify_gimple_in_seq function. So, is it OK for trunk? A cast still doesn't make sense conceptually. Could you give a more detailed analysis of what the trees look like at this point where you are inserting this cast, and how you get to a mismatch? EXCESS_PRECISION_EXPR can be thought of as a conversion operator. It should only appear at the top level of an expression. At the point where excess precision should be removed - the value converted to its semantic type - either the expression with excess precision should be folded using c_fully_fold (if this is the expression of an expression statement, or otherwise will go inside a tree that c_fully_fold does not recurse inside), or the operand of the EXCESS_PRECISION_EXPR should be converted to the semantic type with the convert function. In neither case is generating a cast appropriate; that's for when the user actually wrote a cast in their source code. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] ARMv6-M MI thunk fix
On 07/06/13 17:50, Cesar Philippidis wrote:
On 6/6/13 9:00 AM, Richard Earnshaw wrote:
The pipeline offset is 4 for Thumb2 as well. So at the very least you
need to explain why your change doesn't apply then as well.
Yes some context is lost in that comment. Thunks are usually emitted in
ARM mode, except for Thumb-only targets. Is the new comment OK? If so,
please check it in since I do not have SVN write access.
So what about ARMv7-M, which is thumb2 but no ARM state?
R.
Thanks,
Cesar
2013-06-07 Julian Brown jul...@codesourcery.com
Cesar Philippidis ce...@codesourcery.com
gcc/
* config/arm/arm.c (arm_output_mi_thunk): Fix offset for
TARGET_THUMB1_ONLY.
ARM-fix-mi-thunks-TARGET_THUMB1_ONLY-rev2.patch
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 199695)
+++ gcc/config/arm/arm.c(working copy)
@@ -25217,7 +25217,12 @@
{
/* Output .word .LTHUNKn-7-.LTHUNKPCn. */
rtx tem = XEXP (DECL_RTL (function), 0);
- tem = gen_rtx_PLUS (GET_MODE (tem), tem, GEN_INT (-7));
+ /* When supported, thunks are generated in ARM mode. But for
+TARGET_THUMB1_ONLY the thunk is in Thumb mode, so the PC
+pipeline offset is four rather than eight. Adjust the
+offset accordingly. */
+ tem = gen_rtx_PLUS (GET_MODE (tem), tem,
+ GEN_INT (TARGET_THUMB1_ONLY ? -3 : -7));
tem = gen_rtx_MINUS (GET_MODE (tem),
tem,
gen_rtx_SYMBOL_REF (Pmode,
Re: [PATCH, rs6000] power8 patches, patch #6, direct move basic quad load/store
Mike, This patch is okay, but something seems really broken with respect to TImode. I don't know if we have to separate TImode from V1TImode or some distinction for atomics from other uses of TImode. This isn't like float modes where they mostly live in FPRs and only occassionally need to live in GPRs. TImode between VSX and GPRs really is bimodal. Something is wrong with this preferencing design. Maybe we need a separate set of logical TImode instructions for the atomic ops with a neutral set of preferences on the constraints for movti. Then the registers chosen for the computation will correctly drive the register allocation decisions. Thanks, David
Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)
On Mon, Jun 10, 2013 at 07:51:54AM -0700, Richard Henderson wrote:
On 06/07/2013 02:14 PM, Jakub Jelinek wrote:
When the linker merges common blocks, it chooses both maximum size and
maximum
alignment. Thus for any common block for which we can prove the block
must
reside in the module (any executable, or hidden common in shared
object), we
can go ahead and use the increased alignment.
But consider say:
one TU:
struct S { char buf[15]; } s __attribute__((aligned (32)));
another TU:
char c = 7;
struct S { char buf[15]; } s = { { 1, 2 } };
char d = 8;
int main () { return 0; }
(the aligned(32) is there just to simulate the DATA_ALIGNMENT optimization
increase). Linker warns about this (thus the question is if we want to
increase the alignment for optimization on commons at all) and doesn't align
it.
Oh, right. I hadn't considered commons unifying with non-common variables,
and the failure of commoning in that case. I'd mostly been thinking of
uninitialized Fortran-like common blocks, where it is more common for the
blocks to have nothing in common but the name.
Ok, here is what I've committed to trunk (will wait for some time before
backporting). As discussed with Honza on IRC, decl_binds_to_current_def_p
will need further fixing, it does the wrong thing for extern int var
__attribute__((visibility (hidden))) or hidden DECL_COMMON symbols.
And, we don't have any feedback about SPE/E500 rs6000 - DATA_ALIGNMENT vs.
DATA_ABI_ALIGNMENT yet.
2013-06-10 Jakub Jelinek ja...@redhat.com
PR target/56564
* varasm.c (align_variable): Don't use DATA_ALIGNMENT or
CONSTANT_ALIGNMENT if !decl_binds_to_current_def_p (decl).
Use DATA_ABI_ALIGNMENT for that case instead if defined.
(get_variable_align): New function.
(get_variable_section, emit_bss, emit_common,
assemble_variable_contents, place_block_symbol): Use
get_variable_align instead of DECL_ALIGN.
(assemble_noswitch_variable): Add align argument, use it
instead of DECL_ALIGN.
(assemble_variable): Adjust caller. Use get_variable_align
instead of DECL_ALIGN.
* config/i386/i386.h (DATA_ALIGNMENT): Adjust x86_data_alignment
caller.
(DATA_ABI_ALIGNMENT): Define.
* config/i386/i386-protos.h (x86_data_alignment): Adjust prototype.
* config/i386/i386.c (x86_data_alignment): Add opt argument. If
opt is false, only return the psABI mandated alignment increase.
* config/c6x/c6x.h (DATA_ALIGNMENT): Renamed to...
(DATA_ABI_ALIGNMENT): ... this.
* config/mmix/mmix.h (DATA_ALIGNMENT): Renamed to...
(DATA_ABI_ALIGNMENT): ... this.
* config/mmix/mmix.c (mmix_data_alignment): Adjust function comment.
* config/s390/s390.h (DATA_ALIGNMENT): Renamed to...
(DATA_ABI_ALIGNMENT): ... this.
* doc/tm.texi.in (DATA_ABI_ALIGNMENT): Document.
* doc/tm.texi: Regenerated.
* gcc.target/i386/pr56564-1.c: New test.
* gcc.target/i386/pr56564-2.c: New test.
* gcc.target/i386/pr56564-3.c: New test.
* gcc.target/i386/pr56564-4.c: New test.
* gcc.target/i386/avx256-unaligned-load-4.c: Add -fno-common.
* gcc.target/i386/avx256-unaligned-store-1.c: Likewise.
* gcc.target/i386/avx256-unaligned-store-3.c: Likewise.
* gcc.target/i386/avx256-unaligned-store-4.c: Likewise.
* gcc.target/i386/vect-sizes-1.c: Likewise.
* gcc.target/i386/memcpy-1.c: Likewise.
* gcc.dg/vect/costmodel/i386/costmodel-vect-31.c (tmp): Initialize.
* gcc.dg/vect/costmodel/x86_64/costmodel-vect-31.c (tmp): Likewise.
--- gcc/config/c6x/c6x.h.jj 2013-02-26 16:39:34.0 +0100
+++ gcc/config/c6x/c6x.h2013-06-10 17:36:44.850082918 +0200
@@ -134,7 +134,7 @@ extern c6x_cpu_t c6x_arch;
Really only externally visible arrays must be aligned this way, as
only those are directly visible from another compilation unit. But
we don't have that information available here. */
-#define DATA_ALIGNMENT(TYPE, ALIGN)\
+#define DATA_ABI_ALIGNMENT(TYPE, ALIGN)
\
(((ALIGN) BITS_PER_UNIT * 8 TREE_CODE (TYPE) == ARRAY_TYPE) \
? BITS_PER_UNIT * 8 : (ALIGN))
--- gcc/config/mmix/mmix.h.jj 2013-01-11 09:03:16.0 +0100
+++ gcc/config/mmix/mmix.h 2013-06-10 17:36:05.585730695 +0200
@@ -164,7 +164,7 @@ struct GTY(()) machine_function
/* Copied from elfos.h. */
#define MAX_OFILE_ALIGNMENT (32768 * 8)
-#define DATA_ALIGNMENT(TYPE, BASIC_ALIGN) \
+#define DATA_ABI_ALIGNMENT(TYPE, BASIC_ALIGN) \
mmix_data_alignment (TYPE, BASIC_ALIGN)
#define CONSTANT_ALIGNMENT(CONSTANT, BASIC_ALIGN) \
--- gcc/config/mmix/mmix.c.jj 2013-03-26 10:03:58.0 +0100
+++ gcc/config/mmix/mmix.c 2013-06-10 17:36:28.012360493 +0200
@@ -313,7 +313,7 @@
Re: [PATCH] ARMv6-M MI thunk fix
On 6/10/13 8:32 AM, Richard Earnshaw wrote: On 07/06/13 17:50, Cesar Philippidis wrote: On 6/6/13 9:00 AM, Richard Earnshaw wrote: The pipeline offset is 4 for Thumb2 as well. So at the very least you need to explain why your change doesn't apply then as well. Yes some context is lost in that comment. Thunks are usually emitted in ARM mode, except for Thumb-only targets. Is the new comment OK? If so, please check it in since I do not have SVN write access. So what about ARMv7-M, which is thumb2 but no ARM state? Thumb2 is handled differently. This patch is inside an if (TARGET_THUMB1) block. Cesar
RE: [patch, mips] Fix for PR target/56942
Steven,
The assert has been in ToT for over a week now and I haven't seen any problems
reported.
Is it time to move on to the next step?
Steve Ellcey
sell...@mips.com
From: Steven Bosscher [stevenb@gmail.com]
Sent: Wednesday, May 29, 2013 3:15 PM
To: Steve Ellcey; gcc-patches@gcc.gnu.org; Andrew Bennett;
rdsandif...@googlemail.com
Subject: Re: [patch, mips] Fix for PR target/56942
OK for trunk?
If it causes any trouble, please file a PR and assign it to me.
And when the dust has settled, I can clean up the FIXME for
JUMP_TABLE_DATA in next_active_insn, and fix up the back ends.
Ciao!
Steven
* rtlanal.c (tablejump_p): Expect table and label to be adjacent.
Index: rtlanal.c
===
--- rtlanal.c (revision 199324)
+++ rtlanal.c (working copy)
@@ -2711,6 +2711,7 @@ tablejump_p (const_rtx insn, rtx *labelp, rtx *tab
(table = next_active_insn (label)) != NULL_RTX
JUMP_TABLE_DATA_P (table))
{
+ gcc_assert (table == NEXT_INSN (label));
if (labelp)
*labelp = label;
if (tablep)
[C++ testcase, committed] PR 52440
Hi,
committed to mainline.
Thanks,
Paolo.
2013-06-10 Paolo Carlini paolo.carl...@oracle.com
PR c++/52440
* g++.dg/cpp0x/pr52440.C: New.
Index: g++.dg/cpp0x/pr52440.C
===
--- g++.dg/cpp0x/pr52440.C (revision 0)
+++ g++.dg/cpp0x/pr52440.C (working copy)
@@ -0,0 +1,27 @@
+// PR c++/52440
+// { dg-do compile { target c++11 } }
+
+templatebool
+struct V
+{
+ typedef void type;
+};
+
+templatetypename T
+struct X
+{
+ templatetypename
+ static constexpr bool always_true()
+ {
+return true;
+ }
+
+ templatetypename U,
+ typename = typename Valways_trueU()::type
+ X(U ) {}
+};
+
+int main()
+{
+ Xint x(42);
+}
Re: [c++-concepts] code review
On 06/09/2013 08:34 PM, Gabriel Dos Reis wrote: I strongly suggest prefering stdlib.h over cstdlib for GCC source code base. The problem is that including stdlib.h does not define _GLIBCXX_CSTDLIB, so if one of the C++ library headers includes cstdlib the contents are added then, but by that point e.g. malloc is poisoned, so the mentions of malloc in cstdlib cause errors. Because we are poisoning these names, we need to #include *both* headers in system.h. Jason
Re: [c++-concepts] code review
On 06/09/2013 08:49 PM, Gabriel Dos Reis wrote: If you put the function in an unnamed namespace you would expect GCC to treat is as if it was of internal linkage for many purposes including automatic inlining, but it doesn't:-( For example, you lose the defined but not used warning, and the used but not defined warnings :-(( Indeed, G++ currently only gives those warnings for things declared 'static', but that's trivial to fix, and shouldn't affect other things in the compiler. Jason
RE: [PATCH] Fix for PR c/57563
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Joseph S. Myers
Sent: Monday, June 10, 2013 11:16 AM
To: Iyer, Balaji V
Cc: gcc-patches@gcc.gnu.org; Jakub Jelinek; mpola...@gcc.gnu.org
Subject: RE: [PATCH] Fix for PR c/57563
On Mon, 10 Jun 2013, Iyer, Balaji V wrote:
You don't say what the actual error was, and neither does the original PR.
But if it was an ICE from an EXCESS_PRECISION_EXPR getting to the
gimplifier, that suggests that c_fully_fold isn't getting called
somewhere it should be - and probably calling c_fully_fold is the
correct fix rather than inserting a cast. If you can get such ICEs
for EXCESS_PRECISION_EXPR, it's quite possible you might get them
for C_MAYBE_CONST_EXPR as well (e.g. try using 0 / 0, or compound
literals of variably modified type, in various places in the affected
expressions), which should be fixed by using c_fully_fold but not by
inserting a
cast.
It was not. It was actually a type mismatch between double and long
double caught in verify_gimple_in_seq function. So, is it OK for trunk?
A cast still doesn't make sense conceptually. Could you give a more detailed
analysis of what the trees look like at this point where you are inserting
this cast,
and how you get to a mismatch?
EXCESS_PRECISION_EXPR can be thought of as a conversion operator. It should
only appear at the top level of an expression. At the point where excess
precision should be removed - the value converted to its semantic type -
either
the expression with excess precision should be folded using c_fully_fold (if
this is
the expression of an expression statement, or otherwise will go inside a tree
that c_fully_fold does not recurse inside), or the operand of the
EXCESS_PRECISION_EXPR should be converted to the semantic type with the
convert function. In neither case is generating a cast appropriate; that's
for
when the user actually wrote a cast in their source code.
I looked into it a bit more detail. It was an error on my side. I was removing
the excess precision expr layer instead of fully folding it. I did that change
(i.e. fully fold the expression) and all the errors seem to go away. Here is
the fixed patch that fixes PR c/57563. It passes for 32 bit and 64 bit tests.
Here are the changelog entries:
gcc/c/ChangeLog
2013-06-10 Balaji V. Iyer balaji.v.i...@intel.com
* c-array-notation.c (fix_builtin_array_notation_fn): Fully folded
excessive precision expressions in function parameters.
gcc/testsuite/ChangeLog
2013-06-10 Balaji V. Iyer balaji.v.i...@intel.com
PR c/57563
* c-c++-common/cilk-plus/AN/builtin_fn_mutating.c (main): Fixed a bug
in how we check __sec_reduce_mutating function's result.
Thanks,
Balaji V. Iyer.
--
Joseph S. Myers
jos...@codesourcery.com
diff --git a/gcc/c/c-array-notation.c b/gcc/c/c-array-notation.c
index b1040da..9298ae0 100644
--- a/gcc/c/c-array-notation.c
+++ b/gcc/c/c-array-notation.c
@@ -158,10 +158,13 @@ fix_builtin_array_notation_fn (tree an_builtin_fn, tree
*new_var)
func_parm = CALL_EXPR_ARG (an_builtin_fn, 0);
while (TREE_CODE (func_parm) == CONVERT_EXPR
-|| TREE_CODE (func_parm) == EXCESS_PRECISION_EXPR
|| TREE_CODE (func_parm) == NOP_EXPR)
func_parm = TREE_OPERAND (func_parm, 0);
+ /* Fully fold any EXCESSIVE_PRECISION EXPR that can occur in the function
+ parameter. */
+ func_parm = c_fully_fold (func_parm, false, NULL);
+
location = EXPR_LOCATION (an_builtin_fn);
if (!find_rank (location, an_builtin_fn, an_builtin_fn, true, rank))
diff --git a/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_fn_mutating.c
b/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_fn_mutating.c
index 6635565..7c194c2 100644
--- a/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_fn_mutating.c
+++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_fn_mutating.c
@@ -44,11 +44,11 @@ int main(void)
max_value = array3[0] * array4[0];
for (ii = 0; ii 10; ii++)
if (array3[ii] * array4[ii] max_value) {
- max_value = array3[ii] * array4[ii];
max_index = ii;
}
-
+ for (ii = 0; ii 10; ii++)
+my_func (max_value, array3[ii] * array4[ii]);
#if HAVE_IO
for (ii = 0; ii 10; ii++)
Re: [announce] New scalar-storage-order branch in GCC repository
On 05/27/2013 01:13 PM, Eric Botcazou wrote:
I have just created a new branch off the trunk named scalar-storage-order to
host the (experimental) support to specify a reverse storage order (byte/word
order, aka endianness) for scalar components of aggregate types.
I will be maintaining the branch and start by porting AdaCore's GCC 4.7-based
implementation for the Ada compiler to this branch. Once this is done, I'll
welcome suggestions and ideas to support this new feature in other languages.
I experimented with something like this a while ago. The goal was to
have a -f{big,little}-endian switch that changes the default byteorder,
and also to add endianness attributes. It didn't go very far, but I
could compile some simple testcases and it seemed to behave as expected
for those.
The patch is attached for reference. The interesting problems are
byteswapping pointers and how to deal with function arguments; neither
is dealt with in this patch (except for a crummy attempt to get varargs
right). At the moment I don't intend to do further work on this.
Bernd
Index: gcc/c-family/c-pretty-print.c
===
--- gcc/c-family/c-pretty-print.c (revision 189318)
+++ gcc/c-family/c-pretty-print.c (working copy)
@@ -474,6 +474,10 @@
pp_c_specifier_qualifier_list (pp, TREE_TYPE (t));
break;
+case MOD_TYPE:
+ pp_c_ws_string (pp, bswapped);
+ break;
+
case VECTOR_TYPE:
case COMPLEX_TYPE:
if (code == COMPLEX_TYPE)
Index: gcc/c-family/c.opt
===
--- gcc/c-family/c.opt (revision 189318)
+++ gcc/c-family/c.opt (working copy)
@@ -772,6 +772,10 @@
C++ ObjC++ Joined RejectNegative UInteger Var(max_constexpr_depth) Init(512)
-fconstexpr-depth=number Specify maximum constexpr recursion depth
+fbig-endian
+C Var(flag_big_endian)
+Compile code outside system headers as big-endian
+
fdebug-cpp
C ObjC C++ ObjC++
Emit debug annotations during preprocessing
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 189318)
+++ gcc/c-family/c-common.c (working copy)
@@ -417,6 +417,9 @@
{ _Fract, RID_FRACT, D_CONLY | D_EXT },
{ _Accum, RID_ACCUM, D_CONLY | D_EXT },
{ _Sat, RID_SAT, D_CONLY | D_EXT },
+ { _NativeEndian,RID_SAT, D_CONLY | D_EXT },
+ { _LittleEndian,RID_SAT, D_CONLY | D_EXT },
+ { _BigEndian, RID_SAT, D_CONLY | D_EXT },
{ _Static_assert, RID_STATIC_ASSERT, D_CONLY },
{ _Noreturn,RID_NORETURN, D_CONLY },
{ __FUNCTION__, RID_FUNCTION_NAME, 0 },
@@ -10850,6 +10853,9 @@
case RID_DFLOAT128:
case RID_FRACT:
case RID_ACCUM:
+case RID_NATIVE:
+case RID_LE:
+case RID_BE:
case RID_BOOL:
case RID_WCHAR:
case RID_CHAR16:
Index: gcc/c-family/c-common.h
===
--- gcc/c-family/c-common.h (revision 189318)
+++ gcc/c-family/c-common.h (working copy)
@@ -105,6 +105,7 @@
RID_TYPES_COMPATIBLE_P, RID_BUILTIN_COMPLEX, RID_BUILTIN_SHUFFLE,
RID_DFLOAT32, RID_DFLOAT64, RID_DFLOAT128,
RID_FRACT, RID_ACCUM,
+ RID_NATIVE, RID_BE, RID_LE,
/* C11 */
RID_ALIGNAS,
Index: gcc/c/c-convert.c
===
--- gcc/c/c-convert.c (revision 189318)
+++ gcc/c/c-convert.c (working copy)
@@ -92,6 +92,31 @@
STRIP_TYPE_NOPS (e);
+ if (TREE_CODE (TREE_TYPE (expr)) == MOD_TYPE)
+{
+ switch (TYPE_PRECISION (TREE_TYPE (expr)))
+ {
+ case 8:
+ e = fold_build1 (NOP_EXPR, TREE_TYPE (expr), e);
+ break;
+ case 16:
+ e = fold_build_call_array_loc (loc, TREE_TYPE (expr),
+ build_fold_addr_expr (builtin_decl_explicit (BUILT_IN_BSWAP16M)),
+ 1, e);
+ break;
+ case 32:
+ e = fold_build_call_array_loc (loc, TREE_TYPE (expr),
+ build_fold_addr_expr (builtin_decl_explicit (BUILT_IN_BSWAP32M)),
+ 1, e);
+ break;
+ case 64:
+ e = fold_build_call_array_loc (loc, TREE_TYPE (expr),
+ build_fold_addr_expr (builtin_decl_explicit (BUILT_IN_BSWAP64M)),
+ 1, e);
+ break;
+ }
+}
+
if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (TREE_TYPE (expr)))
return fold_convert_loc (loc, type, expr);
if (TREE_CODE (TREE_TYPE (expr)) == ERROR_MARK)
@@ -107,6 +132,31 @@
case VOID_TYPE:
return fold_convert_loc (loc, type, e);
+case MOD_TYPE:
+ e = convert (TREE_TYPE (type), e);
+ switch (TYPE_PRECISION (TREE_TYPE (e)))
+ {
+ case 8:
+ ret = fold_build1 (NOP_EXPR, TREE_TYPE (e), e);
+ break;
+ case 16:
+ ret = fold_build_call_array_loc (loc, type,
+ build_fold_addr_expr (builtin_decl_explicit (BUILT_IN_BSWAPM16)),
+ 1, e);
+ break;
+ case 32:
+ ret = fold_build_call_array_loc (loc, type,
+ build_fold_addr_expr
Re: PR57548 - Call to multiversioned function from global namespace
On Sat, Jun 8, 2013 at 4:03 PM, David Edelsohn dje@gmail.com wrote: FYI, gcc/cp has it's own ChangeLog file. Yes, it is confusing that some directories have their own and others do not. Fixed now. Sri. - David
Re: [patch] install host specific {bits,ext}/opt_random.h headers in host specific c++ incdir
Am 22.05.2013 11:18, schrieb Paolo Carlini: On 05/21/2013 10:25 AM, Matthias Klose wrote: Am 19.05.2013 11:40, schrieb Paolo Carlini: On 05/19/2013 11:35 AM, Andreas Schwab wrote: Tests that now fail, but worked before: Thanks Andreas. Matthias, please revert ASAP, thanks. you already did that. Looks like ext/random includes opt_random.h, which is not on any include dir, so make it ext/opt_random.h. tests all pass, and check the include with an installed version too. Ok, if nobody has further comments over the next day or so, let's try again ;) now on the trunk for some weeks. ok for the 4.8 branch as well? Matthias
[cilkplus] pragma simd C++: fix more testcases
The following patch fixes the remaining problems in the C++ front-end to
bring the pragma simd implementation on equal footing with the C FE.
Herein lie some small changes to the code parsing the initialization
statement in the for loop, as well as the condition. I also separated
out the for2.c test, since both frontends were sufficiently different
to warrant different tests.
The remaining Cilk Plus failure (for both C and C++) is
c-c++-common/cilk-plus/PS/for5.c, which I'm still investigating how to fix.
Pushed to branch.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index c93ea9e..d68bdf7 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -30236,6 +30236,17 @@ cp_parser_simd_for_init_statement (cp_parser *parser,
tree *init,
error_at (loc, expected iteration declaration);
return error_mark_node;
}
+
+ if (cp_lexer_next_token_is_keyword (parser-lexer, RID_STATIC)
+ || cp_lexer_next_token_is_keyword (parser-lexer, RID_REGISTER)
+ || cp_lexer_next_token_is_keyword (parser-lexer, RID_EXTERN)
+ || cp_lexer_next_token_is_keyword (parser-lexer, RID_MUTABLE)
+ || cp_lexer_next_token_is_keyword (parser-lexer, RID_THREAD))
+{
+ error_at (loc, storage class is not allowed);
+ cp_lexer_consume_token (parser-lexer);
+}
+
cp_parser_parse_tentatively (parser);
cp_parser_type_specifier_seq (parser, true, false, type_specifiers);
if (cp_parser_parse_definitely (parser))
@@ -30332,7 +30343,8 @@ cp_parser_simd_for_init_statement (cp_parser *parser,
tree *init,
}
else
{
- decl = NULL_TREE;
+ if (decl != error_mark_node)
+ decl = NULL;
cp_parser_abort_tentative_parse (parser);
*init = cp_parser_expression (parser, false, NULL);
}
@@ -30379,6 +30391,7 @@ cp_parser_cilk_for (cp_parser *parser, enum rid
for_keyword, tree clauses)
return error_mark_node;
}
+ /* Parse initialization. */
if (for_keyword == RID_FOR)
decl = cp_parser_simd_for_init_statement (parser, init, pre_body);
@@ -30410,6 +30423,13 @@ cp_parser_cilk_for (cp_parser *parser, enum rid
for_keyword, tree clauses)
valid = false;
}
+ if (!valid)
+{
+ /* Skip to the semicolon ending the init. */
+ cp_parser_skip_to_end_of_statement (parser);
+}
+
+ /* Parse condition. */
if (!cp_parser_require (parser, CPP_SEMICOLON, RT_SEMICOLON))
return error_mark_node;
if (cp_lexer_next_token_is (parser-lexer, CPP_SEMICOLON))
@@ -30426,7 +30446,8 @@ cp_parser_cilk_for (cp_parser *parser, enum rid
for_keyword, tree clauses)
if (cond == error_mark_node)
valid = false;
cp_parser_consume_semicolon_at_end_of_statement (parser);
-
+
+ /* Parse increment. */
if (cp_lexer_next_token_is (parser-lexer, CPP_CLOSE_PAREN))
{
error_at (loc, missing increment);
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 16e2472..f8c5d82 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -6058,7 +6058,7 @@ finish_omp_cancellation_point (tree clauses)
tree
finish_cilk_for_cond (tree cond)
{
- return maybe_convert_cond (cond);
+ return cp_truthvalue_conversion (cond);
}
/* Begin a __transaction_atomic or __transaction_relaxed statement.
diff --git a/gcc/testsuite/c-c++-common/cilk-plus/PS/body.c
b/gcc/testsuite/c-c++-common/cilk-plus/PS/body.c
index 5ecefd5..fe8b630 100644
--- a/gcc/testsuite/c-c++-common/cilk-plus/PS/body.c
+++ b/gcc/testsuite/c-c++-common/cilk-plus/PS/body.c
@@ -12,7 +12,7 @@ void foo()
for (int i=0; i 1000; ++i)
{
if (c == 5)
- return; /* { dg-error return statments are not allowed } */
+ return; /* { dg-error \(return statments are not allowed\|invalid
exit\) } */
if (c == 6)
__builtin_setjmp (jmpbuf); /* { dg-error calls to setjmp are not
allowed } */
a[i] = b[i];
diff --git a/gcc/testsuite/c-c++-common/cilk-plus/PS/for2.c
b/gcc/testsuite/c-c++-common/cilk-plus/PS/for2.c
deleted file mode 100644
index dc0a41e..000
--- a/gcc/testsuite/c-c++-common/cilk-plus/PS/for2.c
+++ /dev/null
@@ -1,66 +0,0 @@
-/* { dg-do compile } */
-/* { dg-options -O3 -fcilkplus } */
-
-// Test storage classes in the initialization of a #pragma simd for
-// loop.
-
-int *a, *b;
-
-void foo()
-{
-#pragma simd
- for (static int foo=5; foo 10; ++foo)
-a[foo] = b[foo];
- /* { dg-error declaration of static variable storage class1 { target
*-*-* } 12 } */
- /* { dg-error induction variable cannot be static storage class2 {
target *-*-* } 12 } */
-
- static int bar;
-#pragma simd
- for (bar=0; bar 1000; ++bar) /* { dg-error induction variable cannot be
static } */
-a[bar] = bar;
-
-#pragma simd
- for (extern int var=0; var 1000; ++var)
-a[var] = var;
- /* { dg-error has both 'extern' and initializer extern { target *-*-* }
23 } */
- /* { dg-error declaration of static variable { target *-*-* } 23 } */
- /* { dg-error induction variable
