[Bug c++/37088] New: Functions with default parameters not correctly handled inside templates.
For this simple program (test.cc):
-
template
void AssertPred(Pred pred) {
pred("x", "y");
}
bool pred4(const char *, const char *, const char *x = "", const char *y = "");
bool pred2(const char *, const char *);
void foof() {
AssertPred(pred2);
AssertPred(pred4);
}
-
> $gcc421 -c test.ii (Success with gcc-4.2.1)
> $gcc431 -c test.ii (Failure with gcc-4.3.1)
test.ii: In function 'void AssertPred(Pred) [with Pred = bool (*)(const char*,
const char*, const char*, const char*)]':
test.ii: instantiated from here
test.ii: error: too few arguments to function
--
Summary: Functions with default parameters not correctly handled
inside templates.
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tmsriram at google dot com
GCC build triplet: x86_64
GCC host triplet: x86_64
GCC target triplet: x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37088
[Bug testsuite/55230] UNSUPPORTED: g++.dg/mv1.C -std=gnu++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55230
--- Comment #1 from Sriraman Tallam 2012-11-09
20:31:41 UTC ---
(In reply to comment #0)
> Caused by:
> http://gcc.gnu.org/viewcvs?view=revision&revision=193204
>
> /* { dg-do run { target i?86-*-* x86_64-*-* } } */
> /* { dg-require-ifunc "" } */
>
> If these tests are x86-x86_64 specific, they should be in the target-specific
> directory presumably?
>
> Thanks,
> Kyrill
I dont see any C++ tests in gcc.target. I also see other C++ tests doing the
same thing in g++.dg, example:
testsuite/g++.dg/pr45788.C:// { dg-do compile { target x86_64-*-* } }
Alright?
[Bug c++/57362] [4.8/4.9 Regression] unsupported __attribute__((target())) values appear to cause loop and/or pathological behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57362 --- Comment #3 from Sriraman Tallam --- Patch proposed to fix this problem, This happens when a subset of versions are invalid because of unrecognized target string name or if a dispatcher for that is not available. When constructing the versions array to dispatch, the index used here is wrong. PR 57362 * config/i386/i386.c (dispatch_function_versions): Use actual_versions to index into function_version_info. Index: config/i386/i386.c === --- config/i386/i386.c (revision 199219) +++ config/i386/i386.c (working copy) @@ -29061,10 +29061,10 @@ dispatch_function_versions (tree dispatch_decl, if (predicate_chain == NULL_TREE) continue; + function_version_info [actual_versions].version_decl = version_decl; + function_version_info [actual_versions].predicate_chain = predicate_chain; + function_version_info [actual_versions].dispatch_priority = priority; actual_versions++; - function_version_info [ix - 1].version_decl = version_decl; - function_version_info [ix - 1].predicate_chain = predicate_chain; - function_version_info [ix - 1].dispatch_priority = priority; } /* Sort the versions according to descending order of dispatch priority. The
[Bug c++/57375] gnu multiversioning selects different version depending on link order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57375 Sriraman Tallam changed: What|Removed |Added CC||davidxl at google dot com --- Comment #2 from Sriraman Tallam --- IMO, This is working as expected. You define corei7 only in mv12-aux1.cc, so the compilation of mv12.C and mv12-aux.cc do not see the corei7 version. The version resolver function that is generated is a comdat function, and there are 2 copies generated for the 2 source files with a call to foo, mv12.C and mv12-aux1.cc. However, one of the copies is different, that generated when compiling mv12-aux1.cc because it has the extra corei7 version. So, depending on the link order whichever comdat copy gets kept either calls the corei7 version or not. Usually, the linker keeps the first comdat copy seen so if you put mv12-aux1.cc ahead of mv12.C, the corei7 version will be called and the reverse will not call it. The fix is in the source. Either make every source file see the corei7 version or hide it from all. The linker can be made to complain that the comdats differ if it could be taught about version resolvers. This may be more involved.
[Bug c++/57378] gnu multiversioning gives assembler error: foo.resolver is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57378 Sriraman Tallam changed: What|Removed |Added CC||davidxl at google dot com --- Comment #2 from Sriraman Tallam --- First, what is happening here is the first call to foo is only seeing 2 versions and the second call to foo is seeing the 3rd corei7 version. Was this intentional? When the dispatcher/resovler decl is created, the cgraph nodes of all versions are mapped to this decl. However, the new version decl (corei7 version) is created later, after the first call, and hence it is not mapped to the dispatcher function decl that was previously generated. Hence the second call re-generates it. There are a couple of issues here. Should the first call to foo () even get access to the corei7 version which is not visible? If the corei7 version should not be visible to the first call I must create 2 resolvers, one for the first call and the other for the second call. This gets complicated and I want to leave this for future enhancement. Currently, what is supported is that all calls must see all the versions that will be created. I can create a patch to generate an appropriate error here so that this is made clear.
[Bug c++/57548] calling gnu multiversioned function at file scope causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57548
--- Comment #1 from Sriraman Tallam ---
Patch proposed to fix this problem:
The problem here is that the caller to fum not from a function and
current_function_decl is NULL when processing the
call. The simple fix in call.c to check current_function_decl before
calling can_inline_p target hook.
* cp/call.c (build_over_call): Check if current_function_decl is
NULL.
* testsuite/g++.dg/ext/pr57548.C: New test.
Index: cp/call.c
===
--- cp/call.c(revision 199662)
+++ cp/call.c(working copy)
@@ -7053,7 +7053,8 @@ build_over_call (struct z_candidate *cand, int fla
otherwise the call should go through the dispatcher. */
if (DECL_FUNCTION_VERSIONED (fn)
- && !targetm.target_option.can_inline_p (current_function_decl, fn))
+ && (current_function_decl == NULL
+ || !targetm.target_option.can_inline_p (current_function_decl, fn)))
{
fn = get_function_version_dispatcher (fn);
if (fn == NULL)
Index: testsuite/g++.dg/ext/pr57548.C
===
--- testsuite/g++.dg/ext/pr57548.C(revision 0)
+++ testsuite/g++.dg/ext/pr57548.C(revision 0)
@@ -0,0 +1,25 @@
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+/* { dg-require-ifunc "" } */
+
+int fum (); // Extra declaration that is merged with the second one.
+int fum () __attribute__ ((target("default")));
+
+
+int fum () __attribute__((target( "mmx")));
+int fum () __attribute__((target( "popcnt")));
+int fum () __attribute__((target( "sse")));
+int fum () __attribute__((target( "sse2")));
+int fum () __attribute__((target( "sse3")));
+int fum () __attribute__((target( "ssse3")));
+int fum () __attribute__((target( "sse4.1")));
+int fum () __attribute__((target( "sse4.2")));
+int fum () __attribute__((target( "avx")));
+int fum () __attribute__((target( "avx2")));
+
+int fum () __attribute__((target("arch=core2")));
+int fum () __attribute__((target("arch=corei7")));
+int fum () __attribute__((target("arch=atom")));
+
+int (*p)() = &fum;
+
+int j = fum();
[Bug target/57756] New: Function target attribute is retaining state of previously seen function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57756
Bug ID: 57756
Summary: Function target attribute is retaining state of
previously seen function
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tmsriram at google dot com
Simple repro:
foo.cc:
---
__attribute__((always_inline,target("sse4.2")))
inline int callee ()
{
return 0;
}
__attribute__((target("sse4.1")))
inline int caller ()
{
return callee();
}
int main ()
{
return caller();
}
$ g++ foo.cc
callee is inlined into caller. This is incorrect, the callee's target ISA is
higher and GCC must complain. Digging deeper, the x_ix86_isa_flags of both
caller and callee are the same. The problem is in ix86_set_current_function in
i386.c where
else if (new_tree)
{
cl_target_option_restore (&global_options,
TREE_TARGET_OPTION (new_tree));
target_reinit ();
}
where the restore, restores the previous decl's target options to global.
It is not clear to me how to fix this.
Replace the target attributes in the above source with the equivalent #pragma
GCC push_options and the program will fail as expected.
[Bug c++/57362] [4.8/4.9 Regression] unsupported __attribute__((target())) values appear to cause loop and/or pathological behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57362 --- Comment #5 from Sriraman Tallam --- Trunk rev. 200913 fixes this problem.
[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698
--- Comment #7 from Sriraman Tallam ---
Taking a stab at fixing this. Here is what is going on. In rev. 200179, this
change to tree-inline.c
Index: tree-inline.c
===
--- tree-inline.c (revision 200178)
+++ tree-inline.c (revision 200179)
@@ -3905,8 +3905,6 @@
for inlining, but we can't do that because frontends overwrite
the body. */
&& !cg_edge->callee->local.redefined_extern_inline
- /* Avoid warnings during early inline pass. */
- && cgraph_global_info_ready
/* PR 20090218-1_0.c. Body can be provided by another module. */
&& (reason != CIF_BODY_NOT_AVAILABLE || !flag_generate_lto))
{
made inline failure errors during early inlining reportable. Now, this
function is called when the early_inliner calls optimize_inline_calls. The
reason for the failure, CIF_INDIRECT_UNKNOWN_CALL, should not be reported
because it is not a valid reason,(see can_inline_edge_p in ipa-inline.c for the
list of reasons we intend to report) but it gets reported because of the above
change.
I have the following patch to tree-inline.c to fix this by enumerating all the
early inliner failures that should be reported. I took this list by simply
looking at can_inline_edge_p. Please see patch below. Comments please?
Index: tree-inline.c
===
--- tree-inline.c (revision 200912)
+++ tree-inline.c (working copy)
@@ -3838,6 +3838,32 @@ add_local_variables (struct function *callee, stru
}
}
+/* Should an error be reported when early inliner fails to inline an
+ always_inline function? That depends on the REASON. */
+
+static inline bool
+report_early_inliner_always_inline_failure (cgraph_inline_failed_t reason)
+{
+ /* Only the following reasons need to be reported when the early inliner
+ fails to inline an always_inline function. Called from
+ expand_call_inline.*/
+ switch (reason)
+ {
+ case CIF_BODY_NOT_AVAILABLE:
+ case CIF_FUNCTION_NOT_INLINABLE:
+ case CIF_OVERWRITABLE:
+ case CIF_MISMATCHED_ARGUMENTS:
+ case CIF_EH_PERSONALITY:
+ case CIF_UNSPECIFIED:
+ case CIF_NON_CALL_EXCEPTIONS:
+ case CIF_TARGET_OPTION_MISMATCH:
+ case CIF_OPTIMIZATION_MISMATCH:
+return true;
+ default:
+return false;
+ }
+}
+
/* If STMT is a GIMPLE_CALL, replace it with its inline expansion. */
static bool
@@ -3905,6 +3931,9 @@ expand_call_inline (basic_block bb, gimple stmt, c
for inlining, but we can't do that because frontends overwrite
the body. */
&& !cg_edge->callee->local.redefined_extern_inline
+ /* During early inline pass, check if the reason is reportable. */
+ && (cgraph_global_info_ready
+ || report_early_inliner_always_inline_failure (reason))
/* PR 20090218-1_0.c. Body can be provided by another module. */
&& (reason != CIF_BODY_NOT_AVAILABLE || !flag_generate_lto))
{
[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698
--- Comment #8 from Sriraman Tallam ---
One other alternative to the patch proposed earlier. The reported bug happens
only when optimization is turned on as the early inliner pass invokes
incremental inlining which calls optimize_inline_calls and triggers the above
failure. So, the fix is then as simple as:
Index: tree-inline.c
===
--- tree-inline.c (revision 200912)
+++ tree-inline.c (working copy)
@@ -3905,6 +3905,10 @@ expand_call_inline (basic_block bb, gimple stmt, c
for inlining, but we can't do that because frontends overwrite
the body. */
&& !cg_edge->callee->local.redefined_extern_inline
+ /* During early inline pass, report only when optimization is
+not turned on. */
+ && (cgraph_global_info_ready
+ || !optimize)
/* PR 20090218-1_0.c. Body can be provided by another module. */
&& (reason != CIF_BODY_NOT_AVAILABLE || !flag_generate_lto))
{
Seems like the right fix to me. Ok?
[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698 --- Comment #10 from Sriraman Tallam --- Patch committed. This should fix this. Sri
[Bug c++/57548] calling gnu multiversioned function at file scope causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57548 --- Comment #3 from Sriraman Tallam --- (In reply to Paolo Carlini from comment #2) > What happened to the patch? http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00426.html Patch has been submitted on Jun 7 in rev. 199842 to trunk. Sorry for not updating this bug. It can be marked fixed. Thanks Sri
[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 --- Comment #10 from Sriraman Tallam 2011-10-28 17:28:23 UTC --- On Fri, Oct 28, 2011 at 7:00 AM, vincenzo.innocente at cern dot ch wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 > > --- Comment #9 from vincenzo Innocente > 2011-10-28 14:00:18 UTC --- > That's a pity. > It would be very useful though to have at least a patch to test so that we can > have something to use in prototypes and eventually a working solution for 4.8 Still working on it. Will keep you posted as soon as I have a patch to test. > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug. >
[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 --- Comment #12 from Sriraman Tallam 2012-05-07 16:54:57 UTC --- Will do, thanks. -Sri. On Mon, May 7, 2012 at 6:05 AM, vincenzo.innocente at cern dot ch wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 > > --- Comment #11 from vincenzo Innocente > 2012-05-07 13:05:18 UTC --- > Please post on this PR when a version of 4.8 exists that supports the feature > (I saw several patches proposed and even committed) > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug.
[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 --- Comment #13 from Sriraman Tallam 2012-05-07 17:04:05 UTC --- Here is the patch to do function multiversioning which is under review: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00078.html
[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 --- Comment #15 from Sriraman Tallam 2012-05-08 17:09:43 UTC --- On Tue, May 8, 2012 at 2:18 AM, vincenzo.innocente at cern dot ch wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 > > --- Comment #14 from vincenzo Innocente > 2012-05-08 09:18:01 UTC --- > added your patch on top of > c++ -v > Using built-in specs. > COLLECT_GCC=c++ > COLLECT_LTO_WRAPPER=/afs/cern.ch/user/i/innocent/w2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper > Target: x86_64-unknown-linux-gnu > Configured with: ./configure --prefix=/afs/cern.ch/user/i/innocent/w2 > --enable-languages=c,c++,fortran -enable-gold=yes --enable-lto > --with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64 > --with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64 > --enable-cloog-backend=isl --with-cloog=/usr/local > --with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC' > CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden > -march=native' > -enable-libitm -disable-multilib : (reconfigured) ./configure > --prefix=/afs/cern.ch/user/i/innocent/w2 -enable-gold=yes --enable-lto > --with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64 > --with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64 > --enable-cloog-backend=isl --with-cloog=/usr/local > --with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC' > CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden > -march=native' > -enable-libitm -disable-multilib CC=gcc CXX=g++ > --enable-languages=c,c++,fortran,lto --no-create --no-recursion > Thread model: posix > gcc version 4.8.0 20120508 (experimental) [trunk revision 187276] (GCC) > > configured as above > > ad got > > ../.././gcc/multiversion.c:613: error: undefined reference to > 'cgraph_add_to_same_comdat_group' > collect2: ld returned 1 exit status > make[3]: *** [lto1] Error 1 > make[3]: *** Waiting for unfinished jobs > ../.././gcc/multiversion.c:613: error: undefined reference to > 'cgraph_add_to_same_comdat_group' Thanks, I will fix this asap. > collect2: ld returned 1 exit status > make[3]: *** [cc1] Error 1 > ../.././gcc/multiversion.c:613: error: undefined reference to > 'cgraph_add_to_same_comdat_group' > collect2: ld returned 1 exit status > make[3]: *** [cc1plus] Error 1 > rm gcov.pod cpp.pod gfdl.pod fsf-funding.pod gcc.pod > make[3]: Leaving directory > `/home/data/newsoft/gcc-trunk/host-x86_64-unknown-linux-gnu/gcc' > make[2]: *** [all-stage1-gcc] Error 2 > make[2]: Leaving directory `/home/data/newsoft/gcc-trunk' > make[1]: *** [stage1-bubble] Error 2 > make[1]: Leaving directory `/home/data/newsoft/gcc-trunk' > make: *** [all] Error 2 > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug.
[Bug target/53283] [4.8 Regression] Many failures on x86_64-apple-darwin10 after revision 186789
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53283 Sriraman Tallam changed: What|Removed |Added CC||tmsriram at google dot com --- Comment #1 from Sriraman Tallam 2012-05-08 17:23:00 UTC --- The builtin_target.c failure on Darwin seems related to this: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00455.html
[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 --- Comment #16 from Sriraman Tallam 2012-05-09 19:03:01 UTC --- Bug fixed, patch here: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00694.html Thanks for trying, -Sri. On Tue, May 8, 2012 at 2:18 AM, vincenzo.innocente at cern dot ch wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 > > --- Comment #14 from vincenzo Innocente > 2012-05-08 09:18:01 UTC --- > added your patch on top of > c++ -v > Using built-in specs. > COLLECT_GCC=c++ > COLLECT_LTO_WRAPPER=/afs/cern.ch/user/i/innocent/w2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper > Target: x86_64-unknown-linux-gnu > Configured with: ./configure --prefix=/afs/cern.ch/user/i/innocent/w2 > --enable-languages=c,c++,fortran -enable-gold=yes --enable-lto > --with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64 > --with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64 > --enable-cloog-backend=isl --with-cloog=/usr/local > --with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC' > CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden > -march=native' > -enable-libitm -disable-multilib : (reconfigured) ./configure > --prefix=/afs/cern.ch/user/i/innocent/w2 -enable-gold=yes --enable-lto > --with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64 > --with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64 > --enable-cloog-backend=isl --with-cloog=/usr/local > --with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC' > CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden > -march=native' > -enable-libitm -disable-multilib CC=gcc CXX=g++ > --enable-languages=c,c++,fortran,lto --no-create --no-recursion > Thread model: posix > gcc version 4.8.0 20120508 (experimental) [trunk revision 187276] (GCC) > > configured as above > > ad got > > ../.././gcc/multiversion.c:613: error: undefined reference to > 'cgraph_add_to_same_comdat_group' > collect2: ld returned 1 exit status > make[3]: *** [lto1] Error 1 > make[3]: *** Waiting for unfinished jobs > ../.././gcc/multiversion.c:613: error: undefined reference to > 'cgraph_add_to_same_comdat_group' > collect2: ld returned 1 exit status > make[3]: *** [cc1] Error 1 > ../.././gcc/multiversion.c:613: error: undefined reference to > 'cgraph_add_to_same_comdat_group' > collect2: ld returned 1 exit status > make[3]: *** [cc1plus] Error 1 > rm gcov.pod cpp.pod gfdl.pod fsf-funding.pod gcc.pod > make[3]: Leaving directory > `/home/data/newsoft/gcc-trunk/host-x86_64-unknown-linux-gnu/gcc' > make[2]: *** [all-stage1-gcc] Error 2 > make[2]: Leaving directory `/home/data/newsoft/gcc-trunk' > make[1]: *** [stage1-bubble] Error 2 > make[1]: Leaving directory `/home/data/newsoft/gcc-trunk' > make: *** [all] Error 2 > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug.
[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363
--- Comment #18 from Sriraman Tallam 2012-05-10
16:48:45 UTC ---
On Thu, May 10, 2012 at 3:16 AM, vincenzo.innocente at cern dot ch
wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363
>
> --- Comment #17 from vincenzo Innocente
> 2012-05-10 10:16:13 UTC ---
> I tested this
>
> float x[1024], y[1024], z[1024], w[1024];
>
> void foo() {
> for (int i=0; i!=1024; ++i)
> x[i]=y[i]*z[i]+w[i];
> }
>
>
> void __attribute__ ((target("arch=corei7"))) foo() {
> for (int i=0; i!=1024; ++i)
> x[i]=y[i]*z[i]+w[i];
> }
>
> void __attribute__ ((target("avx"))) foo() {
> for (int i=0; i!=1024; ++i)
> x[i]=y[i]*z[i]+w[i];
> }
>
>
> and see the three versions generated + the "resolver".
>
> As you notice the source code is identical as I'm exploiting compiler
> autovectorization here.
> In this case I was hoping that a single declaration such as __attribute__
> ((target("arch=corei7,avx")))
> or __attribute__ ((target("arch=corei7),target("avx"))) would generate the
> two
> versions w/o hang to duplicate the source code.
> Is this possible to support?
Yes, this is on the list of things to add. The front-end should clone
the bodies and tag the attributes appropriately.
Thanks,
-Sri,
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.
[Bug c/53661] New: Wrong narrowing conversion warning with -std=c++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53661
Bug #: 53661
Summary: Wrong narrowing conversion warning with -std=c++11
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tmsri...@google.com
test.cc
enum Code {
SUCCESS = 0
};
Code a;
int r[] = {a};
$ g++ test.cc -c -std=c++11
test.cc:7:13:warning: narrowing conversion of ‘a’ from ‘Code’ to ‘int’ inside {
} [-Wnarrowing]
int r[] = {a};
[Bug c++/53661] [gcc-4.7/4.8 regression] Wrong narrowing conversion warning with -std=c++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53661 Sriraman Tallam changed: What|Removed |Added Component|c |c++ Summary|Wrong narrowing conversion |[gcc-4.7/4.8 regression] |warning with -std=c++11 |Wrong narrowing conversion ||warning with -std=c++11 --- Comment #1 from Sriraman Tallam 2012-08-07 22:33:58 UTC --- Tip of trunk still fails.
[Bug other/52545] output.h: SECTION_EXCLUDE flag clobbers SECTION_MACH_DEP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545 --- Comment #3 from Sriraman Tallam 2012-03-09 19:36:21 UTC --- Right, I was not looking at SECTION_MACH_DEP when I defined the macro. Is it ok to just bump SECTION_MACH_DEP? The patch I have in mind is: -#define SECTION_MACH_DEP 0x200 /* subsequent bits reserved for target */ -#define SECTION_EXCLUDE 0x400 +#define SECTION_EXCLUDE 0x200 +#define SECTION_MACH_DEP 0x800 /* subsequent bits reserved for target */ I can bump SECTION_MACH_DEP even more to reserve more bits. -Sri.
[Bug other/52545] output.h: SECTION_EXCLUDE flag clobbers SECTION_MACH_DEP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545 --- Comment #5 from Sriraman Tallam 2012-03-09 21:30:54 UTC --- On Fri, Mar 9, 2012 at 12:27 PM, gjl at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545 > > --- Comment #4 from Georg-Johann Lay 2012-03-09 > 20:27:42 UTC --- > (In reply to comment #3) >> Right, I was not looking at SECTION_MACH_DEP when I defined the macro. Is it >> ok >> to just bump SECTION_MACH_DEP? >> >> The patch I have in mind is: >> >> -#define SECTION_MACH_DEP 0x200 /* subsequent bits reserved for target */ >> -#define SECTION_EXCLUDE 0x400 >> +#define SECTION_EXCLUDE 0x200 >> +#define SECTION_MACH_DEP 0x800 /* subsequent bits reserved for target */ >> >> I can bump SECTION_MACH_DEP even more to reserve more bits. > > The reserved bits start at SECTION_MACH_DEP, with the patch above you just > waste the bit at 0x400. I thought I will leave some bits for future flags but I guess whoever adds a flag can also bump SECTION_MACH_DEP. I will send a patch to fix this. Thanks, -Sri. > > Any bits covered by > SECTION_MACH_DEP * (~0) > are reserved for the machine. The bigger SECTION_MACH_DEP is, the less bits > are > left for machine specific needs. > > Machine specific section flag masks could be, e.g.: > > #define SECTION_FLAG_MACH_1 (SECTION_MACH_DEP) > #define SECTION_FLAG_MACH_2 (SECTION_MACH_DEP << 1) > #define SECTION_FLAG_MACH_3 (SECTION_MACH_DEP << 2) > ... > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug.
[Bug target/58115] testcase gcc.target/i386/intrinsics_4.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58115 --- Comment #3 from Sriraman Tallam --- (In reply to Bernd Edlinger from comment #1) > Hi Sriraman, > > I'm putting you on CC since you are the author of that test case: > I am not sure if the test case should use -msse2 instead of -msse, > but running on an assertion is certainly to be avoided in any case. I do not see why it *should* use msse2. Using msse2 however is perfectly fine as it preserves the test case's intent. Thanks Sri > > Regards > Bernd.
[Bug other/58944] [4.9 Regression] bogus -Wunused-macros warnings when compiling Libreoffice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944 Sriraman Tallam changed: What|Removed |Added CC||tmsriram at google dot com --- Comment #3 from Sriraman Tallam --- (In reply to octoploid from comment #1) > Started with r203634. I am able to reproduce the problem though I get the bogus warning: test.cc:4:24: warning: macro "__corei7__" is not used [-Wunused-macros] I am triaging.
[Bug other/58944] [4.9 Regression] bogus -Wunused-macros warnings when compiling Libreoffice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944 Sriraman Tallam changed: What|Removed |Added CC||davidxl at google dot com --- Comment #4 from Sriraman Tallam --- This patch seems to solve the problem Index: config/i386/i386.c === --- config/i386/i386.c(revision 204298) +++ config/i386/i386.c(working copy) @@ -4634,6 +4634,8 @@ be set. */ cl_target_option_restore (&func_options, TREE_TARGET_OPTION (target_option_default_node)); + func_options.x_ix86_arch_string = ix86_arch_string; + func_options.x_ix86_tune_string = ix86_tune_string; new_target = ix86_valid_target_attribute_tree (args, &func_options, &global_options_set); cl_target_option_restore does not touch ix86_arch_string and ix86_tune_string. This has to be managed explicitly. I am testing this patch now. Thanks, Sri
[Bug target/58944] [4.9 Regression] bogus -Wunused-macros warnings when compiling Libreoffice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944
Sriraman Tallam changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- Comment #5 from Sriraman Tallam ---
This also seems similar to the -mpreferred-stack-boundary issue that Bernd
reported recently. Cut and paste from that email:
Currently on trunk the option -mpreferred-stack-boundary does not work
together with #pragma GCC target("sse") or __attribute__((target("sse"))).
There is already a test case that detects this:
gcc.target/i386/fastcall-sseregparm.c
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c(revision 204101)
+++ gcc/config/i386/i386.c(working copy)
@@ -4626,6 +4626,9 @@ ix86_valid_target_attribute_p (tree fndecl,
memset (&func_options, 0, sizeof (func_options));
init_options_struct (&func_options, NULL);
lang_hooks.init_options_struct (&func_options);
+ if (global_options_set.x_ix86_preferred_stack_boundary_arg)
+func_options.x_ix86_preferred_stack_boundary_arg
+ = global_options.x_ix86_preferred_stack_boundary_arg;
cl_optimization_restore (&func_options,
TREE_OPTIMIZATION (func_optimize));
I will fix these generically by adding more fields to cl_target_option and
restoring from there.
[Bug target/58944] [4.9 Regression] bogus -Wunused-macros warnings when compiling Libreoffice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944 --- Comment #7 from Sriraman Tallam --- (In reply to tmsri...@gcc.gnu.org from comment #6) > Author: tmsriram > Date: Tue Dec 3 03:14:09 2013 > New Revision: 205616 > > URL: http://gcc.gnu.org/viewcvs?rev=205616&root=gcc&view=rev > Log: > This patch fixes PR 58944 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944 > > ix86_valid_target_attribute_tree in config/i386/i386.c was > refactored to not depend on global_options structure and to be able to > use any gcc_options structure. One clean way to fix this is by having > target_option_default_node save all the default target options which > can be restored to any gcc_options structure. The root cause of the > above bugs was that ix86_arch_string and ix86_tune_string was not > saved in target_option_deault_node. > > This patch saves all the target options used in i386.opt which are > either obtained from the command-line or set to some default. > > Testing: > Patch tested for bootstrap on all default languages(also obj-c++ and ada) > on x86_64 and regression testsuite checked for parity with RUNTESTFLAGS -m32 > and m64. > > > Added: > trunk/gcc/testsuite/gcc.target/i386/pr58944.c > Modified: > trunk/gcc/ChangeLog > trunk/gcc/config/i386/i386.c > trunk/gcc/config/i386/i386.opt > trunk/gcc/testsuite/ChangeLog Accidentally deleted ChangeLog entry to commit log and committed the patch. Here is the ChangeLog: 2013-12-02 Sriraman Tallam PR target/58944 * config/i386/i386.opt (ix86_arch_string): Mark this variable for saving in cl_target_option. (ix86_tune_string): Ditto. (ix86_cmodel): Ditto. (ix86_abi): Ditto. (ix86_asm_dialect): Ditto. (ix86_branch_cost): Ditto. (ix86_dump_tunes): Ditto. (ix86_force_align_arg_pointer): Ditto. (ix86_force_drap): Ditto. (ix86_incoming_stack_boundary_arg): Ditto. (ix86_pmode): Ditto. (ix86_preferred_stack_boundary_arg): Ditto. (ix86_recip_name): Ditto. (ix86_regparm): Ditto. (ix86_section_threshold): Ditto. (ix86_sse2avx): Ditto. (ix86_stack_protector_guard): Ditto. (ix86_stringop_alg): Ditto. (ix86_tls_dialect): Ditto. (ix86_tune_ctrl_string): Ditto. (ix86_tune_memcpy_strategy): Ditto. (ix86_tune_memset_strategy): Ditto. (ix86_tune_no_default): Ditto. (ix86_veclibabi_type): Ditto. * config/i386/i386.c (function_specific_save): Save the above variables in gcc_options to cl_target_option. (function_specific_restore): Do the reverse done in function_specific_save. (ix86_valid_target_attribute_tree): Change ix86_arch_string and ix86_tune_string to use the opts structure. (ix86_option_override_internal):Change ix86_incoming_stack_boundary_arg to opts->x_ix86_incoming_stack_boundary_arg PR target/58944 * testsuite/gcc.target/i386/pr58944.c: New test.
[Bug target/59390] presence of __attribute__((target("fma"))) declaration breaks __builtin_fma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59390 --- Comment #3 from Sriraman Tallam --- JFYI, I am seeing this issue even in gcc-4.7.
[Bug target/59385] gcc 4.9 fails to use fma with __attribute__((target("fma")))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59385 Sriraman Tallam changed: What|Removed |Added CC||davidxl at google dot com --- Comment #3 from Sriraman Tallam --- Removing the target attributes and using -ffast-math -ftree-vectorize -mfma on the command line is still not producing vfmadd132sd insn. Investigating.
[Bug target/59390] presence of __attribute__((target("fma"))) declaration breaks __builtin_fma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59390
--- Comment #4 from Sriraman Tallam ---
Here is the problem. GCC adds target-specific builtins on demand. The FMA
target-specific builtin __builtin_ia32_vfmaddpd gets added via this
declaration:
void fun() __attribute__((target("fma")));
Specifically, the builtin __builtin_ia32_vfmaddpd gets added when
ix86_add_new_builtins is called from ix86_valid_target_attribute_tree when
processing this target attribute.
Now, when the vectorizer is processing the builtin "__builtin_fma" in function
other_fn(), it checks to see if this function is vectorizable and calls
ix86_builtin_vectorized_function in i386.c. That returns the builtin stored
here:
case BUILT_IN_FMA:
if (out_mode == DFmode && in_mode == DFmode)
{
if (out_n == 2 && in_n == 2)
return ix86_builtins[IX86_BUILTIN_VFMADDPD];
ix86_builtins[IX86_BUILTIN_VFMADDPD] would have contained NULL_TREE had the
builtin not been added by the previous target attribute. That is why the code
works if we remove the previous declaration.
The fix then is to not just return the builtin but to also check if the current
function's isa allows the use of the builtin. For instance, this patch would
solve the problem:
@@ -33977,7 +33977,13 @@ ix86_builtin_vectorized_function (tree fndecl, tre
if (out_mode == DFmode && in_mode == DFmode)
{
if (out_n == 2 && in_n == 2)
-return ix86_builtins[IX86_BUILTIN_VFMADDPD];
+{
+ if (ix86_builtins_isa[IX86_BUILTIN_VFMADDPD].isa
+ & global_options.x_ix86_isa_flags)
+return ix86_builtins[IX86_BUILTIN_VFMADDPD];
+ else
+return NULL_TREE;
+}
but there are many instances of this usage in ix86_builtin_vectorized_function.
I will make a patch to cover all these cases and send for review.
[Bug target/59385] gcc 4.9 fails to use fma with __attribute__((target("fma")))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59385 --- Comment #4 from Sriraman Tallam --- The "widening_mult" has the answer. This pass converts this gimple sequence double _31; double _33; double _36; double _37; _31 = *a_4; _33 = *b_6; _34 = _33 * _31; _36 = *c_8; _37 = _34 + _36; into: _31 = *a_4; _33 = *b_6; _36 = *c_8; _37 = _33 * _31 + _36; (fma gets recognized from this pattern in rtl expand) for the compiler where the vfmadd132sd insn is generated. This conversion fails to happen in gcc-4.9. The problem should mostly be in this function convert_mult_to_widen in treessa-math-opts.c. I have not looked closely at this function yet.
[Bug target/59385] gcc 4.9 fails to use fma with __attribute__((target("fma")))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59385
--- Comment #5 from Sriraman Tallam ---
The root-cause is because floating point expression contraction is default
disabled in ISO C unless specified explicitly. So, adding -ffp-contract=fast
solves the problem.
Details:
The problem is in function convert_mult_to_fma in tree-ssa-math-opts.c. This
does not try to convert the mult into an fma expression because:
static bool
convert_mult_to_fma (gimple mul_stmt, tree op1, tree op2)
{
tree mul_result = gimple_get_lhs (mul_stmt);
tree type = TREE_TYPE (mul_result);
gimple use_stmt, neguse_stmt, fma_stmt;
use_operand_p use_p;
imm_use_iterator imm_iter;
if (FLOAT_TYPE_P (type)
&& flag_fp_contract_mode == FP_CONTRACT_OFF)
return false;
Here, flag_fp_contract_mode is set to FP_CONTRACT_OFF even though it was
initialized to FP_CONTRACT_FAST.
flag_fp_contract_mode gets reset to FP_CONTRACT_OFF here:
c-family/c-opts.c:
bool
c_common_post_options (const char **pfilename)
{
...
/* ISO C restricts floating-point expression contraction to within
source-language expressions (-ffp-contract=on, currently an alias
for -ffp-contract=off). */
if (flag_iso
&& !c_dialect_cxx ()
&& (global_options_set.x_flag_fp_contract_mode
== (enum fp_contract_mode) 0))
flag_fp_contract_mode = FP_CONTRACT_OFF;
That happened in rev. 204460. I do not understand this restriction. However,
specifying -ffp-contract=fast in the command-line disables this reset.
[Bug c++/55742] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
Sriraman Tallam changed:
What|Removed |Added
CC||davidxl at google dot com
--- Comment #1 from Sriraman Tallam 2012-12-19
23:29:51 UTC ---
(In reply to comment #0)
> The following code used to compile with GCC 4.7. It fails on trunk with:
>
> $ bld/xgcc -Bbld/ -c a.cc
> a.cc:10:6: error: prototype for 'void A::E(uint64*, uint64*, const void*,
> int64) const' does not match any in class 'A'
> void A::E(uint64 *l, uint64 *h, const void *b, int64 g) const
> ^
> a.cc:6:18: error: candidate is: virtual void A::E(uint64*, uint64*, const
> void*, int64) const
> virtual void E(uint64 *l, uint64 *h, const void *b, int64 g) const
>
>
> typedef unsigned long long uint64;
> typedef long long int64;
>
> class A {
> public:
> virtual void E(uint64 *l, uint64 *h, const void *b, int64 g) const
> __attribute__ ((__target__ ("sse4")));
> };
>
> void A::E(uint64 *l, uint64 *h, const void *b, int64 g) const
> {
> *l = *h + g;
> if (b) return;
> }
>
> This seems to be a bug in the multiversioning logic. We fail to match the
> function to its declaration in decl2.c:check_classfn because
> ix86_function_versions returns true.
>
> 676
> 677 /* While finding a match, same types and params are not
> enough
> 678 if the function is versioned. Also check version
> ("target")
> 679 attributes. */
> 680 if (same_type_p (TREE_TYPE (TREE_TYPE (function)),
> 681TREE_TYPE (TREE_TYPE (fndecl)))
> 682 && compparms (p1, p2)
> 683 && !targetm.target_option.function_versions (function,
> fndecl)
> 684 && (!is_template
> 685 || comp_template_parms (template_parms,
> 686 DECL_TEMPLATE_PARMS
> (fndecl)))
> 687 && (DECL_TEMPLATE_SPECIALIZATION (function)
> 688 == DECL_TEMPLATE_SPECIALIZATION (fndecl))
> 689 && (!DECL_TEMPLATE_SPECIALIZATION (function)
> 690 || (DECL_TI_TEMPLATE (function)
> 691 == DECL_TI_TEMPLATE (fndecl
> 692 break;
>
> While this agrees with the logic of the multiversion test, it is not the
> appropriate context to be checking for multiversions, I think.
>
> Here we are comparing a function *declaration* with a function *definition*.
> The function definition can never have attributes (only declarations do).
AFAIU, this is not true. Definitions can have target attributes too.
So, your example can be fixed by adding __attribute__ ((__target__ ("sse4")))
to the front of the definition:
__attribute__ ((__target__ ("sse4")))
void A::E(uint64 *l, uint64 *h, const void *b, int64 g) const
{
*l = *h + g;
if (b) return;
}
will now make that code compile.
Infact, I think this is necessary. It is *not correct* to add the target
attribute only to the declaration.
Example:
test.cc
===
char a[17];
char c[16];
int bar () __attribute__ ((target ("sse4.2")));
int bar ()
{
char *b = a+1;
fprintf (stderr, "Foo\n");
for (int i = 0; i< 16; i++)
c[i] = b[i];
return 255;
}
Here, only the declaration has sse4.2, not the definition.
$ g++ test.cc -ftree-vectorize -c -O2 -mno-sse
Now, test.o does not contain any sse4.2 instructions.
Add "__attribute__ ((target ("sse4.2")))" to the definition, and recompile with
same command. test.o will have movdqa and movdqu instructions. So, the target
attributes should also be on the definition for functionality to be correct.
With Multiversioning, this problem is exposed. I think the source change is the
correct way to go here.
So I
> *think* the right fix here is to not call the multiversion hook.
>
> Sri, could you take a look? This bug is causing build failures with our
> internal code base.
>
>
> Thanks.
[Bug c++/55742] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #3 from Sriraman Tallam 2012-12-20 18:21:26 UTC --- (In reply to comment #2) > After thinking about this more, I think the problem here is that the > attributes > specified in the declaration of the function are not being used in the > function > definition. > > Jason, shouldn't the attributes specified in the function declaration be > sufficient? Or does the user really need to apply attributes to both the > declaration and the definition? This can be done during decl merging, by adding the DECL_TARGET_SPECIFIC tree of the declaration decl to the definition decl. However, with function multiversioning, this will become a problem as multiversioning does not treat two decls with different target attributes as identical. Since we are enabling multiversioning by default, atleast in C++ front-end for now, IMO, it is better to insist that the definition and declaration contain identical target attributes. > > > Thanks.
[Bug c++/55742] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #5 from Sriraman Tallam 2012-12-20 19:36:53 UTC --- (In reply to comment #4) > On Thu, Dec 20, 2012 at 1:21 PM, tmsriram at google dot com > wrote: > > > However, with function multiversioning, this will become a problem as > > multiversioning does not treat two decls with different target attributes > > as > > identical. Since we are enabling multiversioning by default, atleast in > > C++ > > front-end for now, IMO, it is better to insist that the definition and > > declaration contain identical target attributes. > > Unfortunately, we cannot do that. A lot of existing code relies on > this attribute merging. The cleanest approach here is probably to add > an additional 'mv' attribute to explicitly enable multiversioning. > Breaking the existing semantics is going to break a lot of code. Ok, just to be clear, there are two problems here: 1) Target attribute merging. If the assumption that the target attributes of the decls must be merged is valid, there is a bug. Also, this means that using target attributes to do multiversioning is wrong. 2) Function multiversioning is exposing the bug, via build failures, the problem of declarations and definitions not having identical target attributes. First, we need to decide if target attribute merging is a valid assumption. If so, we fix the bug and make function multiversioning use a new attribute. If the assumption is not valid, changing the source is the only solution. The source is invalid now since the intended behaviour is not happening. > > > Diego.
[Bug c++/55742] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 Sriraman Tallam changed: What|Removed |Added CC||richard.guenther at gmail ||dot com --- Comment #7 from Sriraman Tallam 2013-01-10 22:10:14 UTC --- Jason/Richard, Would like to hear your thoughts on this.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #13 from Sriraman Tallam 2013-01-14 17:45:42 UTC --- (In reply to comment #12) > (In reply to comment #10) > > Either use a different name of the attribute (replace target with mv_target > > or > > whatever), or require a new attribute (mv?) to be present for > > multi-versioning > > (mv attribute on any of the decls would enable it, if mv attribute isn't > > present on either of the two decls being merged, then the target attribute > > is > > merged as before 4.8). > > > I like this proposal: I too like just using a different attribute name. I will prepare a patch asap for this. Thanks Sri. > > >require a new attribute (mv?) to be present for multi-versioning > > (mv attribute on any of the decls would enable it, if mv attribute isn't > > present on either of the two decls being merged, then the target attribute > > is > > merged as before 4.8) > > > David
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #15 from Sriraman Tallam 2013-01-14
18:07:28 UTC ---
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #12)
> > > (In reply to comment #10)
> > > > Either use a different name of the attribute (replace target with
> > > > mv_target or
> > > > whatever), or require a new attribute (mv?) to be present for
> > > > multi-versioning
> > > > (mv attribute on any of the decls would enable it, if mv attribute isn't
> > > > present on either of the two decls being merged, then the target
> > > > attribute is
> > > > merged as before 4.8).
> > >
> > >
> > > I like this proposal:
> >
> > I too like just using a different attribute name. I will prepare a patch
> > asap
> > for this.
> >
> > Thanks
> > Sri.
> >
> > >
> > > >require a new attribute (mv?) to be present for multi-versioning
> > > > (mv attribute on any of the decls would enable it, if mv attribute isn't
> > > > present on either of the two decls being merged, then the target
> > > > attribute is
> > > > merged as before 4.8)
> > >
> > >
> > > David
>
>
> I mean Jacub's second alternative -- adding additional attribute that alters
> the meaning of 'target' attribute -- when it is present, no merging will be
> done.
Ok, so the two options are :
1) int foo __attribute__ ((mv_target ("sse4.2")));
2) int foo __attribute__ ((target("sse4.2")), mv);
I dont have a strong preference.
>
>
> David
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #27 from Sriraman Tallam 2013-01-16
17:20:28 UTC ---
(In reply to comment #26)
> On Wed, Jan 16, 2013 at 5:02 PM, jakub at gcc dot gnu.org
> wrote:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
> >
> > --- Comment #25 from Jakub Jelinek 2013-01-16
> > 16:02:35 UTC ---
> > The actual merging of target attribute isn't that important, what would be
> > more
> > important is that other attributes are merged together in that case and the
> > decls treated as the same thing.
> >
> > Anyway, with target("any") attribute, what would happen for
> > void foo () __attribute__((target ("avx")));
> > void foo () __attribute__((target ("any")));
>
> IMHO the re-declaration with a different target attribute should be an error.
> A proper "forward" declaration for a function with MV applied shouldn't have
> any target attribute.
Richard, I am not sure I fully understand what you mean. In this example, with
your approach:
test.cc
--
int foo (); // forward declaration
int
main ()
{
foo ();
}
int foo ()
{
...
}
int foo () __attribute__ ("sse2")
{
}
How can you tell if the call to foo is multi-versioned or not?
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #28 from Sriraman Tallam 2013-01-16
17:25:21 UTC ---
(In reply to comment #25)
> The actual merging of target attribute isn't that important, what would be
> more
> important is that other attributes are merged together in that case and the
> decls treated as the same thing.
>
> Anyway, with target("any") attribute, what would happen for
> void foo () __attribute__((target ("avx")));
> void foo () __attribute__((target ("any")));
> void foo () {}
> Is the definition "any", something else?
Further, if we have these three declarations in this order:
void foo () __attribute__((target ("avx")));
void foo () __attribute__((target ("sse4.2")));
void foo () __attribute__((target ("any")));
This seems to mean that we want foo to be multi-versioned. However, when the
front-end is processing the second declaration, how would it decide between
merging or not without seeing the third? IMHO, I think each declaration should
be self-contained like Jakub proposed, and by just looking at the declaration
we should be able to tell if the target attribute affects the signature or not.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #36 from Sriraman Tallam 2013-01-18
18:03:21 UTC ---
(In reply to comment #32)
> Created attachment 29207 [details]
> gcc48-pr55742.patch
>
> This bug is open for way too long given its severity, so let's start talking
> over patches.
>
> This patch attempts to implement what I understand from Jason's comments, just
> with "default" instead of "any", because it is indeed the default target
> attribute (whatever you specify on the command line).
>
> Say on:
> void foo ();
> void foo () __attribute__((target ("avx")));
> void foo () __attribute__((target ("default")));
> __attribute__((target ("default"))) void foo ()
> {
> }
> __attribute__((target ("avx"))) void foo ()
> {
> }
> void (*fn) () = foo;
>
> first we merge the first two decls, because only if target attribute is
> present
> on both, we consider it for multi-versioning, for compatibility with 4.7 and
> older. On e.g.
> void foo ();
> void foo () __attribute__((target ("sse4")));
> void foo () __attribute__((target ("default")));
> void foo ()
> {
> }
> we reject the last fn definition, because at that point foo is already known
> to
> be multi-versioned, thus it is required that target attribute is specified for
> foo (either "default", or some other). Unfortunately, for this case the error
> is reported twice for some reason.
>
> The #c0 testcase now compiles.
>
> Now, the issues I discovered with multiversioning, still unfixed by the patch:
> 1) the mv*.C testcases should be moved, probably to g++.dg/ext/mv*.C
> 2) can you please explain the mess in handle_target_attribute?
> /* Do not strip invalid target attributes for targets which support function
> multiversioning as the target string is used to determine versioned
> functions. */
> else if (! targetm.target_option.valid_attribute_p (*node, name, args,
> flags)
>&& ! targetm.target_option.supports_function_versions ())
> *no_add_attrs = true;
> Why do you need that?
This was added because previously if I had two declarations of foo like this:
void foo ();
void foo __target__(("sse4.2")));
int main ()
{
foo ();
}
void foo ()
{
}
__target__(("sse4.2")));
void foo ()
{
}
The call to foo in main will be treated like 2 different versions of foo exist.
However with -msse4.2 on the command-line, the target attribute will be
stripped off the second declaration which makes foo no longer multi-versioned
when the call to foo is processed. The call to foo without -msse4.2 is
multi-versioned and with -msse4.2 is not. I wanted to avoid this behaviour.
Consider complete garbage in target attribute arguments,
> which is errored about, but the above for i386/x86_64 keeps the target
> attribute around anyway, leading to lots of ICEs everywhere:
> Consider e.g.:
> __attribute__((target ("default"))) void foo (void)
> {
> }
> __attribute__((target (128))) void foo (void)
> {
> }
> 3) the multiversioning code assumes that target has a single argument, but it
> can have more than one. Say for:
> __attribute__((target ("avx,popcnt"))) void foo (void)
> {
> }
> __attribute__((target ("popcnt","avx"))) void bar (void)
> {
> }
> the compiler handles those two as equivalent, but with -Dbar=foo
> multi-versioning only considers the first string out of that.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #37 from Sriraman Tallam 2013-01-18 18:07:08 UTC --- (In reply to comment #35) > Created attachment 29211 [details] > gcc48-pr55742.patch > > Updated patch with ChangeLog entry and code to prevent issuing errors for the > same bug multiple times. > > As for documentation, the multiversioning was checked in without proper > documentation, so there is nothing to adjust in documentation, the feature > simply needs documentation written. > > 1), 2) and 3) are unsolved by the patch, similarly extensive test coverage > (the > current one is insufficient). Perhaps that can be solved incrementally? > I'm going to bootstrap/regtest this version now. Thanks for the patch. Sorry I could not produce a patch earlier. I am working on addressing 1,2 and 3 and will provide more test coverage over the next couple of days.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #38 from Sriraman Tallam 2013-01-18
19:53:16 UTC ---
(In reply to comment #32)
> Created attachment 29207 [details]
> gcc48-pr55742.patch
>
> This bug is open for way too long given its severity, so let's start talking
> over patches.
>
> This patch attempts to implement what I understand from Jason's comments, just
> with "default" instead of "any", because it is indeed the default target
> attribute (whatever you specify on the command line).
>
> Say on:
> void foo ();
> void foo () __attribute__((target ("avx")));
> void foo () __attribute__((target ("default")));
> __attribute__((target ("default"))) void foo ()
> {
> }
> __attribute__((target ("avx"))) void foo ()
> {
> }
> void (*fn) () = foo;
>
> first we merge the first two decls, because only if target attribute is
> present
> on both, we consider it for multi-versioning, for compatibility with 4.7 and
> older. On e.g.
> void foo ();
> void foo () __attribute__((target ("sse4")));
> void foo () __attribute__((target ("default")));
> void foo ()
> {
> }
> we reject the last fn definition, because at that point foo is already known
> to
> be multi-versioned, thus it is required that target attribute is specified for
> foo (either "default", or some other). Unfortunately, for this case the error
> is reported twice for some reason.
>
> The #c0 testcase now compiles.
>
> Now, the issues I discovered with multiversioning, still unfixed by the patch:
> 1) the mv*.C testcases should be moved, probably to g++.dg/ext/mv*.C
> 2) can you please explain the mess in handle_target_attribute?
> /* Do not strip invalid target attributes for targets which support function
> multiversioning as the target string is used to determine versioned
> functions. */
> else if (! targetm.target_option.valid_attribute_p (*node, name, args,
> flags)
>&& ! targetm.target_option.supports_function_versions ())
> *no_add_attrs = true;
> Why do you need that? Consider complete garbage in target attribute
> arguments,
> which is errored about, but the above for i386/x86_64 keeps the target
> attribute around anyway, leading to lots of ICEs everywhere:
Without bringing in your patch, I removed this line with patch:
--- gcc/c-family/c-common.c(revision 195302)
+++ gcc/c-family/c-common.c(working copy)
@@ -8763,8 +8763,7 @@
multiversioning as the target string is used to determine versioned
functions. */
else if (! targetm.target_option.valid_attribute_p (*node, name, args,
- flags)
- && ! targetm.target_option.supports_function_versions ())
+ flags))
*no_add_attrs = true;
return NULL_TREE;
and then tried the new compiler on the following example:
int foo ();
int foo () __attribute__ ((target("mmx")));
int main ()
{
return foo ();
}
int
foo ()
{
return 0;
}
int __attribute__ ((target("mmx")))
foo ()
{
return 0;
}
and with -mno-mmx added to the compile options, everything is fine. However,
with -mmmx in the compile options, I get:
fe_example.cc: In function ‘int foo()’:
fe_example.cc:16:1: error: redefinition of ‘int foo()’
foo ()
^
fe_example.cc:10:1: error: ‘int foo()’ previously defined here
foo ()
Reason is the stripping of target attributes that do not make sense. But, for
MV that creates duplicate functions.
I can change this to only keep the attribute tagged it is recognized by the
target. That way I will strip out erroneous values for target attribute.
> Consider e.g.:
> __attribute__((target ("default"))) void foo (void)
> {
> }
> __attribute__((target (128))) void foo (void)
> {
> }
> 3) the multiversioning code assumes that target has a single argument, but it
> can have more than one. Say for:
> __attribute__((target ("avx,popcnt"))) void foo (void)
> {
> }
> __attribute__((target ("popcnt","avx"))) void bar (void)
> {
> }
> the compiler handles those two as equivalent, but with -Dbar=foo
> multi-versioning only considers the first string out of that.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #41 from Sriraman Tallam 2013-01-19 17:18:02 UTC --- (In reply to comment #40) > Created attachment 29217 [details] > gcc48-pr55742-2.patch > > The following I mean (incremental patch). No test coverage for that, of > course > that needs to be added. The incremental patch is fine, thanks. However, the supports_function_versions target hook is no longer necessary and can be removed. I will add the tests for it. > > BTW, I've noticed wrong ChangeLog entries, your gcc/ChangeLog-2012 CL entries > refer to c-family/ (and cp/) files, while those should be moved (without > prefix) to corresponding c-family/ChangeLog resp. cp/ChangeLog-2012. Sorry about this Thanks Sri
[Bug target/60906] target attribute causes other attributes to be ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60906
Sriraman Tallam changed:
What|Removed |Added
CC||tmsriram at google dot com
--- Comment #4 from Sriraman Tallam ---
(In reply to Harald van Dijk from comment #3)
> Speaking only as a user, the behaviour I personally naïvely expected would
> be to push the default function's attributes into each target-specific
> function's attributes, and use the already existing rules for diagnosing
> conflicting attributes. The dispatcher (ifunc) would take the attributes of
> the default function.
>
> Test cases:
>
> void f1() __attribute__((target("default")));
> void f1() __attribute__((target("arch=corei7"), noreturn));
> // valid, but would apply noreturn attribute only to arch=corei7 declaration
>
> void f2() __attribute__((target("default"), noreturn));
> void f2() __attribute__((target("arch=corei7")));
> // valid, would apply noreturn attribute to all three declarations
I do not understand why the default function's attributes should be applied to
all declarations?
>
> void f3() __attribute__((target("default"), regparm(3)));
> void f3() __attribute__((target("arch=corei7")));
> // valid, would apply regparm(3) attribute to all three declarations
>
> void f4() __attribute__((target("default")));
> void f4() __attribute__((target("arch=corei7"), regparm(3)));
> // invalid
>
> The f4 testcase would be analogous to
>
> int f(int x);
> int f(int x) __attribute__((regparm(3)));
>
> which is already a compile-time error (in 32-bit mode).
Nice list of examples. I think we can allow the various versions to have
distinct non-target attributes, I also think there is no need to apply the
default's functions attributes to all versions. Also, we should check if the
non-common attributes pose a risk like regparm and issue an error
appropriately. Then, apply only the common attributes to ifunc.
[Bug target/60906] target attribute causes other attributes to be ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60906
--- Comment #7 from Sriraman Tallam ---
(In reply to Jakub Jelinek from comment #6)
> GCC has like 60 or 70 target independent attributes plus sometimes various
> target dependent attributes. Figuring out which are ABI changing and must
> be errored out on mismatch, which are safe to ignore, which are only
> affecting function generation and not callers is going to be hard even for
> the existing ones, and would be a maintainance burden for the future, as for
> each new attribute (every year a few of them are added) it would be another
> place to modify and think about what the behavior should be. Keying
> something on default attribute would be weird, for multi-versioning you
> don't have to have target ("default") I think.
Multi-versioning needs the target("default") version or error.
If you want to inherit the
> attributes, perhaps from the first decl only, and if the second/further
> multi-versioned declarations or definitions add attributes (other than the
> target attribute), it would be only allowed if the attribute wouldn't modify
> the attribute list (i.e. contain attribute that is already present).
[Bug middle-end/61456] New: Unnecesary "may be used uninitialized" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456
Bug ID: 61456
Summary: Unnecesary "may be used uninitialized" warning
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tmsriram at google dot com
This test case:
problem.cc
==
int rand ();
class Funcs
{
public:
int *f1 ();
int *f2 ();
};
typedef decltype (&Funcs::f1) pfunc;
static int Set (Funcs * f, const pfunc & fp)
{
(f->*fp) ();
}
void
Foo ()
{
pfunc fp = &Funcs::f1;
if (rand ())
fp = &Funcs::f2;
Set (0, fp);
}
compiled with trunk compiler:
g++ ./problem.cc -O2 -std=c++0x -c -Werror=uninitialized
./problem.cc: In function ‘void Foo()’:
./problem.cc:13:15: error: ‘fp.int* (Funcs::* const)()::__delta’ is used
uninitialized in this function [-Werror=uninitialized]
(f->*fp) ();
^
./problem.cc:19:11: note: ‘fp.int* (Funcs::* const)()::__delta’ was declared
here
pfunc fp = &Funcs::f1
With -fdump-tree-all, the dce1 pass is deleting the statement:
fp.__delta = 0;
even though this is later used with the following gimple sequence:
_22 = fp.__delta;
_24 = (struct Funcs *) _22;
iftmp.2_25 (_24);
[Bug target/61599] New: [x86_64] With -mcmodel=medium, extern global arrays without size are not treated conservatively.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61599
Bug ID: 61599
Summary: [x86_64] With -mcmodel=medium, extern global arrays
without size are not treated conservatively.
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tmsriram at google dot com
CC: davidxl at google dot com, ppluzhnikov at google dot com
foo.cc
==
char c[1*1024*1024*1024];
extern int bar();
int main()
{
return bar() + c[225];
}
bar.cc
==
extern char c[];
int bar()
{
return c[225];
}
$ g++ -mcmodel=medium foo.cc bar.cc -fdata-sections
BFD linker warns:
bar.cc:(.text+0x7): relocation truncated to fit: R_X86_64_PC32 against symbol
`c' defined in .lbss.c section in foo.o
Reason is the compiler does not treat 'c' conservatively as being in .lbss when
it does not know its size. Worse, adding -mlarge-data-threshold=0 still does
not solve the problem.
Changing the declaration "extern char c[]" to "extern char c[1*1024*1024*1024]"
solves the problem.
[Bug rtl-optimization/67532] Add -fno-plt=file and -fno-plt=[symbol,...]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67532 --- Comment #1 from Sriraman Tallam --- On Wed, Sep 9, 2015 at 3:24 PM, hjl.tools at gmail dot com < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67532 > > Bug ID: 67532 >Summary: Add -fno-plt=file and -fno-plt=[symbol,...] >Product: gcc >Version: 6.0 > Status: UNCONFIRMED > Severity: normal > Priority: P3 > Component: rtl-optimization > Assignee: unassigned at gcc dot gnu.org > Reporter: hjl.tools at gmail dot com > CC: tmsriram at google dot com > Target Milestone: --- > > Drawbacks with -fno-plt and noplt attribute are > > 1. -fno-plt may force locally defined functions to be called via > their GOT slots through indirect branch, instead of direct branch. > 2. noplt attribute doesn't work on libcalls of builtin functions. > I am being bitten by this and want to fix it. I am working on a patch. > 3. noplt attribute requires modifying source codes which may not > be desirable for third party source packages. > > We can add -fno-plt=file and -fno-plt=[symbol,...] options to specify > which external functions should be called via their GOT slots to avoid > PLT. > Yes, I second this idea and I proposed doing -fno-plt=symbol originally but was shot down because it was felt using mangled symbols on command line is not desirable. This should be helpful however. Thanks Sri > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
[Bug rtl-optimization/67532] Add -fno-plt=file and -fno-plt=[symbol,...]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67532 --- Comment #2 from Sriraman Tallam --- On Wed, Sep 9, 2015 at 3:24 PM, hjl.tools at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67532 > > Bug ID: 67532 >Summary: Add -fno-plt=file and -fno-plt=[symbol,...] >Product: gcc >Version: 6.0 > Status: UNCONFIRMED > Severity: normal > Priority: P3 > Component: rtl-optimization > Assignee: unassigned at gcc dot gnu.org > Reporter: hjl.tools at gmail dot com > CC: tmsriram at google dot com > Target Milestone: --- > > Drawbacks with -fno-plt and noplt attribute are > > 1. -fno-plt may force locally defined functions to be called via > their GOT slots through indirect branch, instead of direct branch. > 2. noplt attribute doesn't work on libcalls of builtin functions. I am being bitten by this and want to fix it. I am working on a patch. > 3. noplt attribute requires modifying source codes which may not > be desirable for third party source packages. > > We can add -fno-plt=file and -fno-plt=[symbol,...] options to specify > which external functions should be called via their GOT slots to avoid > PLT. Yes, I second this idea and I proposed doing -fno-plt=symbol originally but was shot down because it was felt using mangled symbols on command line is not desirable. This should be helpful however. Thanks Sri > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug target/63538] New: [X86_64] With -mcmodel=medium .lrodata accesses do not use 64-bit addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63538
Bug ID: 63538
Summary: [X86_64] With -mcmodel=medium .lrodata accesses do not
use 64-bit addresses
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tmsriram at google dot com
CC: davidxl at google dot com
foo.cc
==
#include
const char *str = "Hello World";
int main() {
printf("str = %p %s\n",str, str);
return 0;
}
$ g++ --save-temps foo.cc -mcmodel=medium -mlarge-data-threshold=0 -O2
Linked with gold linker.
Look at foo.s:
===
.section.lrodata,"a",@progbits
.LC0:
.string "str = %p %s\n"
.
main:
...
movl $.LC0, %edi
This is the problem, it treats .LC0 as a 32-bit address when it should a 64-bit
address since it is placed in .lrodata
Now this bug will not manifest until .lrodata exceeds the 2GB limit. That can
be done by linking with -Wl,-Ttext=0x7000 which moves the start address of
.text to be very close to 2GB and enough to throw .lrodata out of the limit.
Program segfaults.
[Bug target/61599] [x86_64] With -mcmodel=medium, extern global arrays without size are not treated conservatively.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61599 Sriraman Tallam changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Sriraman Tallam --- Resolved with a simple fix.
