[Bug c/109316] New: incorrect "warning: declaration does not declare anything" for anonymous enums in structs, for -std=(gnu|c)-17

[jason.vas.dias at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109316

Bug ID: 109316
   Summary: incorrect "warning: declaration does not declare
anything" for anonymous enums in structs, for
-std=(gnu|c)-17
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.vas.dias at gmail dot com
  Target Milestone: ---

Just a niggle:

I don't think this code should produce a warning,
but under GCC 12, with -std=gnu17 or -std=c17,
or without any '-std=' setting in C language mode,
 it does:

 'struct S { int a; enum { S_O_a = 0 }; }'; 

/tmp/b.c:1:37: warning: declaration does not declare anything
1 | struct S { int a; enum { S_O_a = 0 }; };
  |

Yes, I know the enumeration declaration does not 
add anything to the struct declaration, (intentionally!),
but in fact GCC HAS inserted DWARF debuginfo for the
enumerator 'S_O_a' in the debug_info section , which
can be used by code in which case the constant is 
interpolated into the output machine code, so something
HAS been declared here ...

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908

--- Comment #14 from Jason Vas Dias  ---


RE: Comment #13:
> You said that Andi Kleen had a comment.  Can you point me to it?

Here is a quote, from LKML message :

Subject: Re: [PATCH v4.16-rc5 2/2] x86/vdso: \
 VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) \
 without syscall   Kernel 
From: Andi Kleen   
Date: 17 March 2018 at 23:00
To: jason.vas.d...@gmail.com
Cc: linux-ker...@vger.kernel.org, x...@kernel.org, t...@linutronix.de,
mi...@kernel.org, pet...@infradead.org, a...@firstfloor.org


>On Sat, Mar 17, 2018 at 02:29:34PM +, jason.vas.d...@gmail.com wrote:
>>  This patch allows compilation to succeed with compilers that 
>>  support -DRETPOLINE -
>>  it was kindly contributed by H.J. Liu in GCC Bugzilla: 84908 :
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908
>>
>>  Apparently the GCC retpoline implementation has a limitation 
>>  that it cannot handle switch statements with more than 5 clauses,
>>  which vclock_gettime.c's
>> __vdso_clock_gettime function now conts.
>
>That's quite a mischaracterization of the issue. gcc works as intended,
>but the kernel did not correctly supply a indirect call retpoline thunk
>to the vdso, and it just happened to work by accident with the old
>vdso.
>
>>
>>  The automated test builds should now succeed with this patch.
>
>How about just adding the thunk function to the vdso object instead of
>this cheap hack?
>
>The other option would be to build vdso with inline thunks.
>
>But just disabling is completely the wrong action.
>
>-Andi

So, in their wisdom, the kernel developers have decided it is
best to compile the VDSO with indirect-branch("thunk-extern,register"),
and we need to work around the limitations this imposes.

RE: Comment #13:
> I also think that static inlines have anything to do with it.  
> Nor so I see why any function attributes make any sense.

On the contrary, I think function attributes and static inline-ness
have ALOT to do with it - the problem does not occur if the 
called functions have the SAME indirect-branch attributes as
the caller function, or if the called function is not static inline.

It definitely appears to be something to do with GCC having to
instantiate a callable version of a static inline, when that
inline has different indirect-branch attributes than its caller.

The '-mindirect-branch=thunk-extern -mindirect-branch-register -DRETPOLINE'
flags should have the effect of making the default function attributes to be
  '__attribute__((indirect-branch("thunk-extern,register"))'
for any function that does not specify other indirect-branch attributes,
so when instantiating this callable version of the inline GCC needs to
generate a thunk-extern relocation. The code which produces the special
stripped & augmented version of the VDSO object does not include support for
such relocations and complains about them, failing the builds.


I also have many unanswered questions about this bug, mentioned above -
perhaps H.J. could clarify ? :
o why exactly is it that the 6-clause switch in the first post triggers
  the relocation, and the 5-clause switch does not?
  why cannot this limitation be removed from GCC?
o why should GCC be trying to generate an extern thunk for 
  an indirect branch to a static inline function anyway ? 
  I think static-inlineness should always trump
indirect-branch("thunk-extern").
o GCC appears to provide no way for users to construct their own jump tables
  without relocations - why does every reference to a PC-relative label
  produce a relocation?





I do believe this

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908

--- Comment #12 from Jason Vas Dias  ---
RE: Comment #11 :
>   notrace int _RETPOLINE_FUNC_ATTR_ 
>   __vdso_clock_gettime(clockid_t clock, struct timespec *ts)
should of course be
   notrace _RETPOLINE_FUNC_ATTR_ 
   int __vdso_clock_gettime(clockid_t clock, struct timespec *ts)
- sorry, I was typing from memory, not pasting.

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908

--- Comment #11 from Jason Vas Dias  ---
In reply to Comment #9 :
Thanks Andy -

I think it is because when the retpoline flags are enabled ,
the 'static inline' function calls in vclock_gettime.c
have default function attributes which differ from those that 
__vdso_clock_gettime
( the function containing the switch ) gets, 
so GCC finds it must instantiate a
callable version of the normally static inline function calls 
this function makes, and
generates relocations for them which are not getting
copied into the VDSO for some reason.
Rather than making more radical changes to the VDSO assembly
code to handle these types of relocations, I think it is better
to avoid them being generated by either:
 A) compiling vclock_gettime.c without 
'-mindirect-branch=thunk-extern -mindirect-branch-register -DRETPOLINE'
(rejected by Andi Kleen)
 B) Specifying ALL entry points that __vdso_clock_gettime calls
to have attributes that do not require relocation for GCC
to handle if the above flags are in effect:



#ifdef RETPOLINE
+#  define  _NO_THUNK_RELOCS_()(indirect_branch("keep"),\
+   function_return("keep"))
+#  define  _RETPOLINE_FUNC_ATTR_   __attribute__(_NO_THUNK_RELOCS_())
+#  define  _RETPOLINE_INLINE_  inline
+#else
+#  define  _RETPOLINE_FUNC_ATTR_
+#  define  _RETPOLINE_INLINE_  __always_inline
+#endif

So then one declares any function called by __vdso_clock_gettime() like:

   notrace static _RETPOLINE_FUNC_ATTR_ _RETPOLINE_INLINE_
   int do_monotonic_raw( int clock, struct timespec *ts ) { ... }

and then must declare 

   notrace int _RETPOLINE_FUNC_ATTR_ 
   __vdso_clock_gettime(clockid_t clock, struct timespec *ts)
   {... do_monotonic_raw(ts); ...}

to avoid the relocations being generated. 
I did submit a patch to vclock_gettime.c
to do this - should I re-submit it?

Or one could fix the code which produces the resulting vdso
to include the generated (unecessary and redundant) relocations,
or generate the relocation functions in assembler somehow, but
I don't think this is the way the VDSO should go. There is no
reason to make functions in the VDSO have function attributes
 indirect_branch("thunk-extern,register") - they always WILL
generate relocations if more that 5 such calls are made in same
switch,  with all current versions of GCC, it seems. 
Every function that directly invokes these functions (in glibc),
must also have these function attributes, which are entirely
unnecessary and inefficient compared to the indirect_branch("keep")
style; and those relocations then must be in the VDSO for callers
to invoke.

[Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491

--- Comment #6 from Jason Vas Dias  ---
Thanks Andrew!

But, please explain, why does using a static reference cause
anonymous namespace issues ?
Where is this mandated in the C++ standards ?

I understand that any reference to a static object can violate the ODR
rule IFF multiple translation units that contain references to the "same"
static object are combined. But how does that involve anonymous namespace
issues?

Maybe GCC should provide some mechanism to detect static references,
report them separately as a new  "-Wstatic-reference"? warning ,
and NOT bring in 'anonymous namespace' usage issues at all ?
It is purely a semantic difference - I agree SOME warning should
have been issued - but complaining about 'anonymous namespace'
when it means 'static reference' is really confusing.
There are NO objects named '{anon::}' in the program.
Couldn't GCC have some trigger on the creation of an '{anon}::'
reference, and use it to report the anonymous namespace usage,
and if none existed, complain about the static reference usage ?

Thanks & Best Regards,
Jason


On 11/07/2018, pinskia at gcc dot gnu.org  wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491
>
> Andrew Pinski  changed:
>
>What|Removed |Added
> 
>Keywords||diagnostic
>
> --- Comment #5 from Andrew Pinski  ---
> It is not complaining about d in main but rather N::D.  The warning is done
> before it reaches main.
>
> Really the warning should be clearer as you are not using an anonymous
> namespace rather static linkage which is also causes an anonymous namespace
> issues.

[Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491

--- Comment #4 from Jason Vas Dias  ---
Aha! It is simply that the object pointer template parameter cannot
have static (translation unit) linkage here:

  namespace NA 
  {  class C { ... };
 static C c_;
   /*^^*/
  }

If I remove the 'static', no warning is generated .

This -Wsubobject-linkage warning is therefore doubly confusing !

Since I am instantiating an object whose symbol has automatic storage class,
('d' in main()), 
why should gcc complain that I have an object containing a static reference ?

And why does it have anything to do with -Wsubobject-linkage or use of 
anonymous namespaces ?

There really is no anonymous namespace usage going on in this code.

I really do want all users of the 'NT' template to get a pointer to the same
global 'class C' 'c_' object , which is ONLY defined in the one place, 
but multiple files must be able to include the same 't2.h' header .

I see now I should have used 'extern C c_', and defined it in tM.C.

But actually, in the context in which it was used, since there was no
other defining translation unit, and it was only instantiated in a main()
program, I do not think the warning should have been issued. If I was
actually trying to instantiate multiple 'class D' objects from multiple
translation units, there would be a problem, but I was not.

And really, that '-Wsubobject-linkage' should be split into:
  A) Detect genuine anonymous namespace use
  B) Detect usage of static object references in headers that can be
 included by multiple files, and issue a separate warning message like 
  'static object reference may not be to same object\
   if used in multiple translation units'
 or something like that.

It is highly confusing to claim that code uses anonymous namespaces 
when it does not.

[Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491

--- Comment #3 from Jason Vas Dias  ---
Of course, these lines of t2.h from Comment #1 :

template < class _C_, _C_ *_C_OBJ_, void (_C_::*_M_)() >
  class NT
  { static constexpr _C_ *c_ = _C_OBJ_;
 public:
NT()
{ (c_->*_M_)();


could be replaced by:

template < class _C_, _C_ *_C_OBJ_, void (_C_::*_M_)() >
  class NT
  { static constexpr _C_ *c_ = _C_OBJ_;
 public:
NT()
{ (c_->*_M_)();


and the same problem would occur (-Wsubobject-linkage warning) .

(the existence of the 'c_' static const copy of '_C_' is irrelevant.

It is simply that any occurrence of, in file A:
namespace N {
  template   
class T { ... /* something that uses C */}
}
and in file B :
namespace N {
namespace X { 
  class Y  { ... };
  Y y;
}
class C : T< Y, , retval (::a_Y_method) (,..) >
{...};
} // end namespace N

will trigger this bug.

I am trying to figure out why, and how it can be avoided.

I do not want to trigger C++'s special 'anonymous namespace object'
processing in any way here, and I do not see why it is being triggered.

[Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491

--- Comment #2 from Jason Vas Dias  ---
Created attachment 44384
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44384=edit
More readable (diff -ur) patch against 6.4.1's cp/decl2.c

Here is a more readable version of the patch 
to print out information on the exact component
of the base class structure which GCC thinks
uses the anonymous namespace. 
In this case, it is of not much use, but does
inform the user that GCC thinks the whole structure
declaration somehow uses the anonymous namespace,
which obviously it does not, so does signal the
existence of this GCC bug to the user.

[Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491

--- Comment #1 from Jason Vas Dias  ---
In investigating this problem, I actually modified 6.4.1's gcc/cp/decl2.c
with the following patch to print out which component of the
base struct it thinks uses the anonymous namespace:

BEGIN PATCH:
--- decl2.c,r260630 2018-05-18 14:47:27.0 +0100
+++ decl2.c 2018-07-11 16:16:13.816541340 +0100
@@ -2154,0 +2155,5 @@
+struct tree_vis
+{ tree *tp;
+  int  vis;
+};
+
@@ -2158 +2163 @@
-  int *vis_p = (int *)data;
+  struct tree_vis *tree_vis_p = (struct tree_vis *)data;
@@ -2166 +2171,2 @@
-  *vis_p = VISIBILITY_ANON;
+  tree_vis_p->tp  = tp;
+  tree_vis_p->vis = VISIBILITY_ANON;
@@ -2170,2 +2176,4 @@
-  && CLASSTYPE_VISIBILITY (*tp) > *vis_p)
-*vis_p = CLASSTYPE_VISIBILITY (*tp);
+  && CLASSTYPE_VISIBILITY (*tp) > tree_vis_p->vis)
+  { tree_vis_p->vis = CLASSTYPE_VISIBILITY (*tp);
+tree_vis_p->tp = tp;
+  }
@@ -2181,3 +2189,8 @@
-  int vis = VISIBILITY_DEFAULT;
-  cp_walk_tree_without_duplicates (, min_vis_r, );
-  return vis;
+  struct tree_vis tv = { NULL, VISIBILITY_DEFAULT };
+  cp_walk_tree_without_duplicates (, min_vis_r, );
+  return tv.vis;
+}
+
+static void
+tree_type_visibility (tree_vis *tvis)
+{ cp_walk_tree_without_duplicates (tvis->tp, min_vis_r, tvis);
@@ -2607 +2620,4 @@
-  int subvis = type_visibility (TREE_TYPE (t));
+  tree_vis tvis = { &(TREE_TYPE (t)), VISIBILITY_DEFAULT };
+  tree_type_visibility ();
+
+  int subvis = tvis.vis;
@@ -2627,2 +2643,2 @@
-%qT has a base %qT whose type uses the anonymous namespace",
-type, TREE_TYPE (t));
+%qT has a base %qT whose type uses the anonymous namespace because of its
component %qT",
+type, TREE_TYPE (t), *tvis.tp);
:END PATCH


But the offending component is actually the whole base class:

 N::NT<_C_, _C_OBJ_, _M_>::NT() void N::NA::C::m()
In file included from /tmp/tM.C:1:0:
/tmp/t2.H: At global scope:
/tmp/t2.H:14:9: warning: ‘N::D’ has a base ‘N::NT’ whose type uses the anonymous namespace because of its component
‘N::NT’ [-Wsubobject-linkage]
   class D : public NT
 ^
 N::D::D() N::D::D() N::D::D() int main() N::NT<_C_, _C_OBJ_, _M_>::NT() [with
_C_ = N::NA::C; _C_* _C_OBJ_ = (& N::NA::c_); void (_C_::* _M_)() =
::NA::C::m] N::NT<_C_, _C_OBJ_, _M_>::NT() [with _C_ = N::NA::C; _C_* _C_OBJ_
= (& N::NA::c_); void (_C_::* _M_)() = ::NA::C::m] N::NT<_C_, _C_OBJ_,
_M_>::NT() [with _C_ = N::NA::C; _C_* _C_OBJ_ = (& N::NA::c_); void (_C_::*
_M_)() = ::NA::C::m]
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   
   Assembling
functions:
  void N::NA::C::m() N::D::D() int main() N::NT<_C_, _C_OBJ_,
_M_>::NT() [with _C_ = N::NA::C; _C_* _C_OBJ_ = (& N::NA::c_); void (_C_::*
_M_)() = ::NA::C::m]
Execution times (seconds)
 phase setup :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
  1386 kB (62%) ggc
 phase opt and generate  :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 (100%) wall
169 kB ( 8%) ggc
 integrated RA   :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 (100%) wall
 96 kB ( 4%) ggc
 TOTAL :   0.00 0.00 0.01  
2223 kB


It would be nice if the fix for this could also print out more information
about precisely which component of the structure the compiler thinks uses
the anonymous namespace - it has taken me 2 days of analysis to get this 
far, which could have been avoided if GCC printed out information like
the above in the first place.

[Bug c++/86491] New: bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491

Bug ID: 86491
   Summary: bogus and unsuppressible warning: 'YYY' has a base
'ZZZ' whose type uses the anonymous namespace
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.vas.dias at gmail dot com
  Target Milestone: ---

Created attachment 44383
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44383=edit
test code demonstrating problem as described above.

This could be a duplicate of (now closed) bug #57317 , 
or a demonstration that the fix for that bug is not complete.

It occurs with all versions of GCC on Linux x86_64 - tested:
 o RHEL7 system compiler: 4.8.5 (rpm: 4.8.5-28.el7_5.1.x86_64)
My own builds of:
 o gcc 5.4.0
 o gcc 6.4.1 (from gcc-6-branch r260630)
 o gcc 7.3.1 (r260631)
 o gcc 8.1.0 (r261026) 
.

The following test code triggers a -Wsubobject-linkage warning,
with all the above compilers :

./t2.H:14:9: warning: 'N::D' has a base 'N::NT whose type uses the anonymous namespace \
 [enabled by default]
  class D : public NT
^

I have constructed the following test code,
which triggers the same -Wsubobject-linkage warning
I am seeing in a large more complex real-world example.

I am not intentionally using the anonymous namespace
in any of this code, and I cannot for the life of me
see how any part of it uses the anonymous namespace:

Test Code :

File t1.H:

// t1.H :
namespace N
{
  template < class _C_, _C_ *_C_OBJ_, void (_C_::*_M_)() >
  class NT
  { static constexpr _C_ *c_ = _C_OBJ_;
  public:
NT()
{ (c_->*_M_)();
}
  };
}


File t2.H:

// t2.H :
#include 
namespace N
{
  namespace NA
  {
class C
{ public:
  void m()
  {}
};
static C c_;
  }

  class D : public NT
  {public:
typedef NT NT_t;
D(): NT_t()
{}
  };
}
file tM.C (main program):


#include 

extern int main()
{ N::D d;
  (void)d;
  return 0;
}



The above files are included in the attached 
'Wsubobject-linkage-anon-base-bug.tar' file, which includes a make file:

$ tar -xpf Wsubobject-linkage-anon-base-bug.tar
$ cd Wsubobject-linkage-anon-base-bug
$ make
g++ -std=gnu++14 -I. -Wall -Wextra -Werror -o tM tM.C
In file included from tM.C:1:0:
./t2.H:14:9: error: 'N::D' has a base 'N::NT' whose type uses the anonymous namespace [-Werror]
   class D : public NT
 ^
cc1plus: all warnings being treated as errors
make: *** [Makefile:4: tM] Error 1

[Bug sanitizer/85924] [6 Regression] ASAN: segfault in __interceptor_clock_gettime ( because 'asan_linux.o' for libasan.a built with -DPIC )

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85924

--- Comment #1 from Jason Vas Dias  ---
Aha! Sorry, it appears that when run from command line, just the -fPIC
option appears, not the -DPIC, but in my make.log for the original
GCC build, I do see:

checking for shl_load in -ldld... libtool: compile: 
/home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc/xgcc -shared-libgcc
-B/home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc -nostdinc++
-L/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/src
-L/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/src/.libs
-L/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-linux-gnu/bin/ -B/usr/local/x86_64-linux-gnu/lib/ -isystem
/usr/local/x86_64-linux-gnu/include -isystem
/usr/local/x86_64-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-DASAN_HAS_EXCEPTIONS=1 -DASAN_NEEDS_SEGV=1 -DCAN_SANITIZE_UB=0
-D_OBSTACK_SIZE_T=SIZE_T -I. -I../../.././libsanitizer/asan -I.. -I
../../.././libsanitizer/include -I ../../.././libsanitizer -Wall -W
-Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC
-fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables
-fvisibility=hidden -Wno-variadic-macros -fno-ipa-icf
-I../../libstdc++-v3/include -I../../libstdc++-v3/include/x86_64-linux-gnu
-I../../.././libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 -g -O2
-D_GNU_SOURCE -MT asan_linux.lo -MD -MP -MF .deps/asan_linux.Tpo -c
../../.././libsanitizer/asan/asan_linux.cc  -fPIC -DPIC -o asan_linux.o
>/dev/null 2>&1
no
checking for dlopen... no


So the asan/asan_linux.o object IS getting built with -fPIC -DPIC !

this means instant infinite recursion for every syscall if -static-libasan
used.

[Bug sanitizer/85924] New: [6 Regression] ASAN: segfault in __interceptor_clock_gettime ( because 'asan_linux.o' for libasan.a built with -DPIC )

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85924

Bug ID: 85924
   Summary: [6 Regression] ASAN: segfault in
__interceptor_clock_gettime ( because 'asan_linux.o'
for libasan.a built with -DPIC )
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.vas.dias at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

This is a re-occurence of bug #59063, as tested by 
gcc/testsuite/c-c++-common/asan/pr59063-2.c ,
which fails for builds of gcc-6-branch r260671 .

Problem: on an up-to-date RHEL-7.5 x86_64 system (SL) , where
libtool resolves to /usr/bin/libtool (v2.4.2), after
building in GCC_SRC='.' & running 'make check' :

 $ cd x86_64-linux-gnu  # default $OBJDIR
 $ cd libsanitizer/asan
 $ rm -f asan_linux.o
 $ make  asan_linux.o 2>&1 | tee make_asan_linux.build.log
 /home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc/xgcc -shared-libgcc
-B/home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc -nostdinc++
-L/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/src
-L/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/src/.libs
-L/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-linux-gnu/bin/ -B/usr/local/x86_64-linux-gnu/lib/ -isystem
/usr/local/x86_64-linux-gnu/include -isystem
/usr/local/x86_64-linux-gnu/sys-include-D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-DASAN_HAS_EXCEPTIONS=1 -DASAN_NEEDS_SEGV=1 -DCAN_SANITIZE_UB=0
-D_OBSTACK_SIZE_T="SIZE_T"  -I. -I../../.././libsanitizer/asan -I..  -I
../../.././libsanitizer/include -I ../../.././libsanitizer  -Wall -W
-Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long \
  -fPIC \
# ^OUCH! causes infinite recursion and core dump in 
#  __interception::sigaction
-no-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables
-fvisibility=hidden -Wno-variadic-macros -fno-ipa-icf
-I../../libstdc++-v3/include -I../../libstdc++-v3/include/x86_64-linux-gnu 
   -I../../.././libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 -g -O2
-D_GNU_SOURCE -MT asan_linux.o -MD -MP -MF .deps/asan_linux.Tpo -c -o
asan_linux.o ../../.././libsanitizer/asan/asan_linux.cc
mv -f .deps/asan_linux.Tpo .deps/asan_linux.Po

(Same happens for './asan_rtl.o') .

For some reason, for only the gcc-6-branch (NOT the gcc-{4,5,7}-branches,
libtool 2.4.2 is appending '-fPIC' to the compile options for 
   ./asan_linux.o
( which is meant ONLY to be included in the static .libs/libasan.a ;
  .libs/asan_linux.o is always correctly compiled with '-fPIC -DPIC' ,
  and is destined for inclusion in .libs/libasan.so.*
). 
Unfortunately, setting -fPIC does make 'PIC' defined() .
So the __asan_init method thinks it is in a SHARED LIBRARY,
and invokes :
dlsym(RTLD_NEXT,'sigaction');
but since the default load module now interposes its
'__interception::sigaction' ,
(which is called by REAL(sigaction)) ,
 __interception::sigaction , which dereferences that
dlsym return value, calls itself in an infinite loop until
the process runs out of stack and coredumps .

I cannot understand why the build scripts or libtool should be appending -fPIC 
here - they do not in gcc-{4,5,7}-branches .

[Bug tree-optimization/85891] [6 Regression] Simple loop is not SLP-vectorized after r196872

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85891

--- Comment #7 from Jason Vas Dias  ---
Aha!
Yes, I was experimenting with the new '-march=haswell' and
'-mtune=intel' options
(  which seem to me to be the wrong way round - shouldn't 'haswell' be an
   '-mtune' option and 'intel' be an '-march' option ? but this is not
the case,
  according to documentation.
) .
GCC 6.4.1 was configured with :

./configure \
   --prefix=/usr/local --libdir=/usr/local/lib64 --enable-languages=all \
  --enable-targets=all --enable-multilib --enable-threads=posix --enable-lto \
  --with-cpu-64=intel --with-cpu-32=generic \
  --with-arch-64=haswell --with-tune-64=intel --with-arch-32=i686 \
  --with-fp=sse+387 --with-tune-32=generic --enable-shared \
  --with-pic --with-gmp=/usr/local --with-isl=/usr/local \
  --with-cloog=/usr/local --with-mpc=/usr/local --with-isl=/usr/local \
  --with-system-zlib --with-gnu-ld --with-gnu-as --enable-serial-configure \
  --host=x86_64-linux-gnu --build=x86_64-linux-gnu --target=x86_64-linux-gnu
'

What I am trying to achieve is that the DEFAULT 64-bit platform for the
compiler
(the target the compiler builds for without any  '-m=yyy' options)   should
be '-march=haswell -mtune=intel', which  I think should be the equivalent
to the older options  '-march=x86-64 -mtune=haswell' , and to
 '-mtune=native' on this platform - please let me know if this is not the
case .

The 5.5.0 & 7.3.1 compilers were built with
  '--with-arch64=x86-64 --with-cpu64=haswell' ,
but re-reading the updated 6.4.1 '-mtune'/'-march' documentation led
me to believe
that the new '--with-arch-64=haswell --with-tune-64=intel' options were
more appropriate . I guess not ?
(The 5.5.0 and 7.3.1 builds are 6months & 2months old, before the
'-march=haswell' support.
).

I will try rebuilding 6.3.1 with '--with-arch64=x86-64
--with-cpu64=haswell' and
retest.  Thanks!


On 24/05/2018, rguenth at gcc dot gnu.org  wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85891
>
> --- Comment #6 from Richard Biener  ---
> The log file shows the loop was already vectorized by loop vectorization.
> How
> did you configure gcc?  It might be you configured a default -march/tune
> that
> doesn't match the testcase expectation (and the testcase could probably use
> -ftree-slp-vectorize instead of -ftree-vectorize).
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug tree-optimization/85891] [6 Regression] Simple loop is not SLP-vectorized after r196872

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85891

--- Comment #5 from Jason Vas Dias  ---
Could it be an issue to do with running on different hardware?
The CPU on the machine is a rather old 4-core (8 with HyperThreading)
Haswell :



processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 60
model name  : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
stepping: 3
microcode   : 0x22
cpu MHz : 3400.000
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc a
perfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3
sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb tpr_shadow vnmi
flexpriority ept vpid
fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat
pln pts
bogomips: 6784.22
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

[Bug tree-optimization/85891] [6 Regression] Simple loop is not SLP-vectorized after r196872

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85891

--- Comment #4 from Jason Vas Dias  ---
Same commands run by GCC 5.5.0 or GCC 7.3.1 succeed:

$ g++5 slp-pr56812.cc -nostdinc++ -std=c++98 -O2 -ftree-vectorize
-fno-vect-cost-model -msse2 -fdump-tree-slp-details=gcc5.out -O3 -funroll-loops
-fvect-cost-model=dynamic -S -o slp-pr56812.gcc5.s
$ grep 'basic block vectorized' gcc5.out
slp-pr56812.cc:17:16: note: basic block vectorized
$ gcc_7_3_env
$ g++7 slp-pr56812.cc -nostdinc++ -std=c++14 -O2 -ftree-vectorize
-fno-vect-cost-model -msse2 -fdump-tree-slp-details=gcc7.out -O3 -funroll-loops
-fvect-cost-model=dynamic -S -o slp-pr56812.gcc7.s
$ grep 'basic block vectorized' gcc7.out
slp-pr56812.cc:18:1: note: basic block vectorized

[Bug tree-optimization/85891] [6 Regression] Simple loop is not SLP-vectorized after r196872

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85891

--- Comment #3 from Jason Vas Dias  ---
Created attachment 44174
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44174=edit
slp1 log file

Here is the slp1 log file produced by command:
$
/home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc/testsuite/g++/../../xg++
-B/home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc/testsuite/g++/../../
/home/devel/OS/gcc-6-branch/gcc/testsuite/g++.dg/vect/slp-pr56812.cc
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/include/x86_64-linux-gnu
-I/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/include
-I/home/devel/OS/gcc-6-branch/libstdc++-v3/libsupc++
-I/home/devel/OS/gcc-6-branch/libstdc++-v3/include/backward
-I/home/devel/OS/gcc-6-branch/libstdc++-v3/testsuite/util -fmessage-length=0
-std=c++14 -O2 -ftree-vectorize -fno-vect-cost-model -msse2
-fdump-tree-slp-details -O3 -funroll-loops -fvect-cost-model=dynamic -S -o
slp-pr56812.s


It does not contain the string 'basic block vectorized', so the test fails.

[Bug tree-optimization/85891] [6 Regression] Simple loop is not SLP-vectorized after r196872

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85891

--- Comment #2 from Jason Vas Dias  ---
Created attachment 44173
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44173=edit
log file produced by 'make check-g++ 'RUNTESTFLAGS=vect.exp=slp-pr56812*'

Log file showing test failures as requested

[Bug lto/85893] New: [regression] Variables promoted to Gimple registers by aliasing are not getting debug statements (if -flto used).

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85893

Bug ID: 85893
   Summary: [regression] Variables promoted to Gimple registers by
aliasing are not getting debug statements (if -flto
used).
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.vas.dias at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

After building gcc-5-branch, gcc-6-branch, and gcc-7-branch,
on an x86_64 Linux glibc-2.17 + binutils 2.30 (also on a 
glibc-2.27 + binutils 2.30 system), they all fail the
gcc.dg/guality/pr41616-1.C testsuite test with any
'-flto' enabling arguments:

Without -flto enabled, the tests pass:

../xgcc -B../gcc/ ../gcc.dg/guality/pr41616-1.c ...\
   -flto -fno-use-linker-plugin -flto-partition=none \
   -O2 -g -fgnu89-inline -lm -o ./pr41616-1.exe
spawn [open ...]
PASS: b is -1
PASS: b is 1
PASS: 2 PASS, 0 FAIL, 0 UNRESOLVED
PASS: gcc.dg/guality/pr41616-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
...

With -flto enabled, they fail:
../xgcc -B../gcc/ ../gcc.dg/guality/pr41616-1.c ...\
   -flto -fuse-linker-plugin -fno-fat-lto-objects \
   -O2 -g -fgnu89-inline -lm -o ./pr41616-1.exe

spawn [open ...]
PASS: b is -1
FAIL: b is -1, not 1
FAIL: 1 PASS, 1 FAIL, 0 UNRESOLVED
FAIL: gcc.dg/guality/pr41616-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test


This happens with builds of gcc-5.5.0, gcc-6.4.1, and gcc-7.3.1 .

All other -flto testsuite tests of these builds are passing.

[Bug tree-optimization/85891] New: [6.4.1 regression] Simple loop is not SLP-vectorized after r196872

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85891

Bug ID: 85891
   Summary: [6.4.1 regression] Simple loop is not SLP-vectorized
after r196872
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.vas.dias at gmail dot com
  Target Milestone: ---

Building GCC 6.4.1 from gcc-6-branch of 20180521 (SVN Revision 260441) ,
for x86_64 under Linux (RHEL-7.5, glibc-2.17, binutils 2.30) ,
now gets testsuite failures:

FAIL: g++.dg/vect/slp-pr56812.cc  -std=c++98  scan-tree-dump-times slp1 "basic
block vectorized" 1

FAIL: g++.dg/vect/slp-pr56812.cc  -std=c++11  scan-tree-dump-times slp1 "basic
block vectorized" 1

FAIL: g++.dg/vect/slp-pr56812.cc  -std=c++14  scan-tree-dump-times slp1 "basic
block vectorized" 1

These tests succeed with GCC 7.3.1 and GCC 5.5.0 .

[Bug debug/85887] [6.4.1 & 7.3.1 Regression] Missing DW_TAG_lexical_block PC range

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85887

--- Comment #2 from Jason Vas Dias  ---
Also affects gcc-5.4.0 and gcc-5.5.0 builds.

[Bug debug/85887] [6.4.1 & 7.3.1 Regression] Missing DW_TAG_lexical_block PC range

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85887

--- Comment #1 from Jason Vas Dias  ---
No, it looks like the patch 
( https://gcc.gnu.org/bugzilla/attachment.cgi?id=28937 )
is applied to 6.4.1's and 7.3.1's tree-inline.c, only 
for some reason it is not working for those compilers.

[Bug debug/85887] New: [6.4.1 & 7.3.1 Regression] Missing DW_TAG_lexical_block PC range

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85887

Bug ID: 85887
   Summary: [6.4.1 & 7.3.1 Regression] Missing
DW_TAG_lexical_block PC range
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.vas.dias at gmail dot com
  Target Milestone: ---

Bug #55665 has reappeared in builds of the gcc-6-branch and gcc-7-branch SVN 
trees, and its test case ( g++.dg/guality/pr55665.C ) now fails, on my 
up-to-date RHEL7.5 Linux x86_64 system (glibc 2.17, with
either gdb-8.1 built from source or the distro gdb-7.6.1-110.el7:

Under GCC 6.4.1 ( 20180521, SVN revision # 260441, gdb 8.1 ):

After 'make check' fails, cd to $GCC_BUILD_DIR/host-x86_64-linux-gnu/gcc, 
and run:

$ make check-g++ RUNTESTFLAGS='guality.exp=pr55665*'
...
Running /home/devel/OS/gcc-6-branch/gcc/testsuite/g++.dg/guality/guality.exp
...
FAIL: g++.dg/guality/pr55665.C   -O2  line 23 p == 40
FAIL: g++.dg/guality/pr55665.C   -O3 -g  line 23 p == 40

Here is the detailed gcc/testsuite/g++/g++.log extract showing errors:

spawn gdb -nx -nw -quiet -batch -x pr55665.gdb ./pr55665.exe
[?1034hBreakpoint 1 at 0x4007cb: file
/home/devel/OS/gcc-6-branch/gcc/testsuite/g++.dg/guality/pr55665.C, line 23.

Breakpoint 1, A::A (this=0x7fffccac, x=) at
/home/devel/OS/gcc-6-branch/gcc/testsuite/g++.dg/guality/pr55665.C:23
23foo (p);  // { dg-final { gdb-test 23 "p" "40" } }
$1 = 0
$2 = 40
0 != 40
FAIL: g++.dg/guality/pr55665.C   -O2  line 23 p == 40


spawn gdb -nx -nw -quiet -batch -x pr55665.gdb ./pr55665.exe
[?1034hBreakpoint 1 at 0x4007cb: file
/home/devel/OS/gcc-6-branch/gcc/testsuite/g++.dg/guality/pr55665.C, line 23.

Breakpoint 1, A::A (this=0x7fffccac, x=) at
/home/devel/OS/gcc-6-branch/gcc/testsuite/g++.dg/guality/pr55665.C:23
23foo (p);  // { dg-final { gdb-test 23 "p" "40" } }
$1 = 0
$2 = 40
0 != 40
FAIL: g++.dg/guality/pr55665.C   -O3 -g  line 23 p == 40


spawn gdb -nx -nw -quiet -batch -x pr55665.gdb ./pr55665.exe
[?1034hBreakpoint 1 at 0x4007cb: file
/home/devel/OS/gcc-6-branch/gcc/testsuite/g++.dg/guality/pr55665.C, line 23.

Breakpoint 1, A::A (this=0x7fffccac, x=) at
/home/devel/OS/gcc-6-branch/gcc/testsuite/g++.dg/guality/pr55665.C:23
23foo (p);  // { dg-final { gdb-test 23 "p" "40" } }
pr55665.gdb:3: Error in sourced command file:
No symbol "p" in current context.
UNSUPPORTED: g++.dg/guality/pr55665.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 23 p == 40



spawn gdb -nx -nw -quiet -batch -x pr55665.gdb ./pr55665.exe
[?1034hBreakpoint 1 at 0x400680: file
/home/devel/OS/gcc-6-branch/gcc/testsuite/g++.dg/guality/pr55665.C, line 23.

Breakpoint 1, A::__base_ctor (x=42, this=) at
/home/devel/OS/gcc-6-branch/gcc/testsuite/g++.dg/guality/pr55665.C:23
23foo (p);  // { dg-final { gdb-test 23 "p" "40" } }
pr55665.gdb:3: Error in sourced command file:
No symbol "p" in current context.
UNSUPPORTED: g++.dg/guality/pr55665.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 23 p == 40


The tests pass with GCC 4.8.5 (distro compiler).


Perhaps the fix for 4.8.5 has not been ported to 7.3 / 6.4 ? investigating.

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908

--- Comment #8 from Jason Vas Dias  ---
Thanks for the clarification, and I hope the kernel
developers stop compiling the mainline vDSO with
-mindirect-branch=thunk-extern -mindirect-branch-register 
.

But there are still a few things I am trying to figure out :

 o Why is the thunk entry reference & relocation inserted
   for 6 switch clauses and not for 5 ?


 o So do I understand correctly: 

__x86_indirect_thunk_rax

   is resolved and jumped to save %rax , jump to the address in %rcx, 
   and then restore %rax, and return ?

   it is normally 
A) generated for libraries / executable as required or 
B) is in libgcc ?

   If (A), then what triggers it and why is it not being generated for the
vDSO?
   If (B), then where is the code in libgcc ? I can't find it.


I'd also like more details on why it is wrong to compile the vDSO with these 
flags - it does work, and yes causes compilation problems like this one which
can be worked around by declaring all 'notrace static inline' entry points
in vclock_gettime.c to have the function attributes:
   static inline 
   __attribute__((
 indirect_branch("keep"),
 function_return("keep")
   ))
   int do_monotonic_raw( int clock, struct timespec *ts );
which effectively disables the effect of 
   -mindirect-branch=thunk-extern -mindirect-branch-register
for these functions ; also __vdso_clock_gettime itself MUST
be then declared:
   __attribute__((
 indirect_branch("keep"),
 function_return("keep")
   )) 
   int __vdso_clock_gettime ( ... ) { ...

But does it cause any other issues ?

I did investigate changing the switch in __vdso_clock_gettime
to :

#define _GTOD_LABEL_PREFIX_ _vcg_
#define _SYMCAT_(_S1_,_S2_) _S1_##_S2_
#define _GTOD_CLK_LABEL_(_CLK_) _SYMCAT_(_GTOD_LABEL_PREFIX_,_CLK_)

notrace int __vdso_clock_gettime(clockid_t clock, struct timespec *ts)
{
static const void * clk_jmp_tbl[ MAX_CLOCKS ]   = {
[ CLOCK_REALTIME  ] =
&&_GTOD_CLK_LABEL_(CLOCK_REALTIME) ,
[ CLOCK_MONOTONIC ] =
&&_GTOD_CLK_LABEL_(CLOCK_MONOTONIC) ,
[ CLOCK_PROCESS_CPUTIME_ID ]= & ,
[ CLOCK_THREAD_CPUTIME_ID  ]= & ,
[ CLOCK_MONOTONIC_RAW  ]=
&&_GTOD_CLK_LABEL_(CLOCK_MONOTONIC_RAW) ,
[ CLOCK_REALTIME_COARSE]=
&&_GTOD_CLK_LABEL_(CLOCK_REALTIME_COARSE) ,
[ CLOCK_MONOTONIC_COARSE   ]=
&&_GTOD_CLK_LABEL_(CLOCK_MONOTONIC_COARSE) ,
[ CLOCK_BOOTTIME   ]= & ,
[ CLOCK_BOOTTIME_ALARM ]= & ,
[ CLOCK_SGI_CYCLE  ]= & ,
[ CLOCK_TAI]= & , // unused clocks
[ 12   ]= &_supported ,
[ 13   ]= &_supported ,
[ 14   ]= &_supported ,
[ 15   ]= &_supported
};

goto *clk_jmp_tbl [ clock & 0xf ] ;

 _GTOD_CLK_LABEL_(CLOCK_REALTIME):
if (do_realtime(ts) == VCLOCK_NONE)
goto fallback;
goto return_ok;
 _GTOD_CLK_LABEL_(CLOCK_MONOTONIC)   :
if (do_monotonic(ts) == VCLOCK_NONE)
goto fallback;
goto return_ok;
 _GTOD_CLK_LABEL_(CLOCK_MONOTONIC_RAW)   :
if (do_monotonic_raw(ts) == VCLOCK_NONE)
goto fallback;
goto return_ok;
 _GTOD_CLK_LABEL_(CLOCK_REALTIME_COARSE) :
do_realtime_coarse(ts);
goto return_ok;
 _GTOD_CLK_LABEL_(CLOCK_MONOTONIC_COARSE):
do_monotonic_coarse(ts);
goto return_ok;
 return_ok:
return 0;
 not_supported:
return -1;
 fallback:
return vdso_fallback_gettime(clock, ts);
}

Results in 16 dynamic relocations,

shown in objdump -R arch/x86/entry/vdso/vdso64.so.dbg output:

DYNAMIC RELOCATION RECORDS
OFFSET   TYPE  VALUE
04a0 R_X86_64_RELATIVE  *ABS*+0x0c49
...
518 R_X86_64_RELATIVE  *ABS*+0x0b31

what's the problem with dyn relocs ?


I can't understand why GCC decides to generate relocations 
here - it knows all the information before hand - why 
can't it insert code to compute 
( ( LOAD_ADDRESS_OF(__vdso_clock_gettime) == %pc at entry) + label_offset )
and populate the clk_jmp_table in an initializer in the
above version of the function rather than generate 
relocations ? 

Thanks & Best Regards,
Jason

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908

--- Comment #2 from Jason Vas Dias  ---
Thanks H.J. -

RE:
> vDSO isn't compiled with -mindirect-branch=thunk-extern in kernel
> 4.16-rc5.  Why isn't it the case for you? 

All I know is ,  when submitting a patched vclock_gettime.c 
in which the switch in vdso_clock_gettime() had 6 clauses
instead of 5, I received in response a mail from 
kbuild test robot:

>Hi
>
>Thank you for the patch! Yet something to improve:
>
>[auto build test ERROR on v4.16-rc4]
>[also build test ERROR on next-20180315]
>[if your patch is applied to the wrong git tree, please drop us a note to help 
>>improve the system]
>
>url:
>https://github.com/0day-ci/linux/commits/jason-vas-dias-gmail-com/x86-vdso-on-Intel-VDSO-should-handle-CLOCK_MONOTONIC_RAW/20180316-070319
>config: x86_64-rhel (attached as .config)
>compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
>reproduce:
># save the attached .config to linux build tree
>make ARCH=x86_64
>
>All errors (new ones prefixed by >>):
>
>   arch/x86/entry/vdso/vclock_gettime.o: In function `__vdso_clock_gettime':
>   vclock_gettime.c:(.text+0xf7): undefined reference to 
> >`__x86_indirect_thunk_rax'
>   /usr/bin/ld: arch/x86/entry/vdso/vclock_gettime.o: relocation R_X86_64_PC32 
> >against undefined symbol `__x86_indirect_thunk_rax' can not be used when 
> making >a shared object; recompile with -fPIC
>   /usr/bin/ld: final link failed: Bad value
>>> collect2: error: ld returned 1 exit status
>--
>>> arch/x86/entry/vdso/vdso32.so.dbg: undefined symbols found
>--
>>> objcopy: 'arch/x86/entry/vdso/vdso64.so.dbg': No such file
>---
>0-DAY kernel test infrastructureOpen Source Technology Center
>https://lists.01.org/pipermail/kbuild-all   Intel Corporation

That github URL does not point to anything anymore.

So it was 4.16-rc4 they were compiling against.
Maybe it is fixed in 4.16-rc5.

I had seen exactly the same problem when compiling the same
patch with the RHEL-7 4.8.5-16-el7_4.2.x86_64 compiler,
which did not happen when compiling the same code with
the previous RHEL-7 4.8.5-16-el7_4.1.x86_64 compiler.

So it is caused by  -mindirect-branch=thunk-extern ?


Aha, I see in kernel Makefile of the RHEL 3.10.0-21.1.el7 kernel:
  RETPOLINE_CFLAGS += $(call cc-option,-mindirect-branch=thunk-extern
-mindirect-branch-register)

And it is still in the CFLAGS of the kernel tagged 'v4.16-rc5:'

$ grep RETPOLINE linux-4.16-rc5/Makefile
RETPOLINE_CFLAGS_GCC := -mindirect-branch=thunk-extern
-mindirect-branch-register
RETPOLINE_CFLAGS_CLANG := -mretpoline-external-thunk
RETPOLINE_CFLAGS := $(call cc-option,$(RETPOLINE_CFLAGS_GCC),$(call
cc-option,$(RETPOLINE_CFLAGS_CLANG)))

But the compiler I am using for the 4.x builds is 6.4.1 , which
does not support -mindirect-branch=thunk-extern / -mindirect-branch-register .

I will get round to building one of the latest compilers with
retpoline support eventually, but it is not a priority for me
at the moment, for my Linux 4.x builds.

I just want to be able to build the patched vclock_gettime.c
under RHEL, with the new 4.8.5-16 retpoline supporting compiler,
and to be able to submit patches that don't break to the 4.16-rc5
branch .


YES, I have just tested, removing 
  '-mindirect-branch=thunk-extern -mindirect-branch-register'
from the 3.10.0-693.21.1.el7 build DOES allow it to succeed 
with the 6-clause version of the switch in vclock_gettime.c .

But I don't want my patch to have to depend on this being removed -
the removal of these flags effectively removes retpoline support, no ?
It is a shame to have to do that after it was carefully added.

My gripe is really that nothing in GCC should work with a switch
with < 6 clauses, and fail with a switch with >= 6 clauses.

Just reporting this issue so it can be fixed.

Thanks & Best Regards,
Jason

[Bug c/84908] New: retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908

Bug ID: 84908
   Summary: retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC:
R_X86_64_PC32 against undefined symbol
`__x86_indirect_thunk_rax'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.vas.dias at gmail dot com
  Target Milestone: ---

This bug occurs under Linux x86_64 with 
  gcc-4.8.5-16, as delivered in the latest RHEL7-4x package:
  gcc-4.8.5-16.el7_4.2.x86_64
and with the compiler used by kernel.org's automated patch tester:
  kbuild test robot<l...@intel.com>
  config: x86_64-rhel
  compiler: gcc-7 (Debian 7.3.0-1) 7.3.0  ,
ONLY when trying to build the Linux vDSO,
ONLY IFF the switch in 
  ${LINUX_KERNEL_SOURCE}/arch/x86/entry/vclock_gettime.c 's
__vdso_gettime() function contains MORE THAN 5 CLAUSES,
such as:


notrace int __vdso_clock_gettime(clockid_t clock, struct timespec *ts)
{
switch (clock) {
case CLOCK_REALTIME:
if (do_realtime(ts) == VCLOCK_NONE)
goto fallback;
break;
case CLOCK_MONOTONIC:
if (do_monotonic(ts) == VCLOCK_NONE)
goto fallback;
break;
case CLOCK_MONOTONIC_RAW:
if (do_monotonic_raw(ts) == VCLOCK_NONE)
goto fallback;
break;
case CLOCK_REALTIME_COARSE:
do_realtime_coarse(ts);
break;
case CLOCK_MONOTONIC_COARSE:
do_monotonic_coarse(ts);
break;
default:
goto fallback;
}

return 0;
fallback:
return vdso_fallback_gettime(clock, ts);
}






The 7.3.0-1 compiler and 4.8.5-16 compilers both now complain
on the final link :


arch/x86/entry/vdso/vclock_gettime.o: In function `__vdso_clock_gettime':
   vclock_gettime.c:(.text+0xf7): undefined reference to
`__x86_indirect_thunk_rax'
   /usr/bin/ld: arch/x86/entry/vdso/vclock_gettime.o: relocation R_X86_64_PC32
against undefined symbol `__x86_indirect_thunk_rax' can not be used when making
a shared object; recompile with -fPIC
   /usr/bin/ld: final link failed: Bad value


Note all objects are being compiled with -fPIC in this case.

I can reproduce this with the 4.8.5-16 compiler under RHEL-7.4 :




$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC)


$ cd $LINUX_KERNEL_SOURCE
$ make arch/x86/vdso/
...
make KBUILD_MODULES=1 \
-f scripts/Makefile.build obj=arch/x86/vdso
  gcc -Wp,-MD,arch/x86/vdso/.vclock_gettime.o.d  -nostdinc -isystem
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/include -I./arch/x86/include
-Iarch/x86/include/generated  -Iinclude -I./arch/x86/include/uapi
-Iarch/x86/include/generated/uapi -I./include/uapi -Iinclude/generated/uapi
-include ./include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security
-fno-delete-null-pointer-checks -std=gnu89 -Werror -O2 -m64 -mno-mmx -mno-sse
-mpreferred-stack-boundary=3 -mtune=generic -mno-red-zone -mcmodel=kernel
-funit-at-a-time -maccumulate-outgoing-args -Wframe-larger-than=2048
-DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
-DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1
-DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno-sign-compare
-fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx
-mindirect-branch=thunk-extern -mindirect-branch-register -DRETPOLINE
-Wframe-larger-than=2048 -fstack-protector-strong -Wno-unused-but-set-variable
-fno-omit-frame-pointer -fno-optimize-sibling-calls -g -mfentry
-DCC_USING_FENTRY -fno-inline-functions-called-once
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-ov

[Bug c++/80920] warnings get position wrong - very confusing

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80920

--- Comment #5 from Jason Vas Dias  ---
I think if GCC cannot get the position of an error correct, 
then it should not show the position at all .

[Bug c++/81279] variadic template regression : compiles without error under 5.4.0 , 6.3.0 with error under 7.1.0

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81279

--- Comment #7 from Jason Vas Dias  ---
Created attachment 41665
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41665=edit
Fixed version - also demonstrates point : addresses of members increase

So when I mangle it to actually print each member's address in order,
whenever the tuple is printed :

std::ostream ::operator <<(std::ostream ) const
{
  std::cerr << " out: @ :" 
  << (static_cast
  (reinterpret_cast(this)))
  << std::endl;
  return _t.operator<<( out << head() << " " );
}   

$ ./tTuple < /tmp/t
 out: @ :0x7ffc6f93d410
one  out: @ :0x7ffc6f93d430
two  out: @ :0x7ffc6f93d450
three
 fun( one two three )
one
two
three

This would not be the case had std::tuple been used - the addresses would be
DECREASING .

But I am now able to use with no problems in C++14, C++17 under 7.1.0 . Thanks!

[Bug c++/81279] variadic template regression : compiles without error under 5.4.0 , 6.3.0 with error under 7.1.0

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81279

Jason Vas Dias  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Vas Dias  ---
Wow! Problem SOLVED! Need a different pair of eyes sometimes ...
But I can't find where this is flagged in gcc 7.1.0  NEWS or ReleaseNotes .
It is a major change of behavior WRT to Variadic Macros, IMHO .

On 02/07/2017, d25fe0be at outlook dot com  wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81279
>
> --- Comment #4 from d25fe0be@  ---
> '_t::_call' is a dependent name, adding 'template' before '_call' fixes the
> compilation error.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/81279] variadic template regression : compiles without error under 5.4.0 , 6.3.0 with error under 7.1.0

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81279

--- Comment #5 from Jason Vas Dias  ---
Wow! Problem SOLVED! Need a different pair of eyes sometimes ...
But I can't find where this is flagged in gcc 7.1.0  NEWS or ReleaseNotes .
It is a major change of behavior WRT to Variadic Macros, IMHO .

On 02/07/2017, d25fe0be at outlook dot com  wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81279
>
> --- Comment #4 from d25fe0be@  ---
> '_t::_call' is a dependent name, adding 'template' before '_call' fixes the
> compilation error.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/81279] variadic template regression : compiles without error under 5.4.0 , 6.3.0 with error under 7.1.0

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81279

Jason Vas Dias  changed:

   What|Removed |Added

  Attachment #41663|0   |1
is obsolete||

--- Comment #3 from Jason Vas Dias  ---
Created attachment 41664
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41664=edit
Example PieceWise Constructed (PWC) Tuple class - as plain text - improved,
same error

[Bug c++/81279] variadic template regression : compiles without error under 5.4.0 , 6.3.0 with error under 7.1.0

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81279

Jason Vas Dias  changed:

   What|Removed |Added

  Attachment #41662|0   |1
is obsolete||

--- Comment #2 from Jason Vas Dias  ---
Created attachment 41663
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41663=edit
Example PieceWise Constructed (PWC) Tuple class - as plain text

[Bug c++/81279] variadic template regression : compiles without error under 5.4.0 , 6.3.0 with error under 7.1.0

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81279

--- Comment #1 from Jason Vas Dias  ---
Obviously, G++ 5.4.0 and 6.3.0 are able to expand the 
text '_HeadList...' here into the list of types:
Line 184:
   _t._call<  _HeadList...

But G++ 7.1.0 is not able to do so, and gives no clue
as to why not. I guess I must consider variadic template
arguments simply "broken" in this release of GCC ?

[Bug c++/81279] New: variadic template regression : compiles without error under 5.4.0 , with error under 7.1.0

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81279

Bug ID: 81279
   Summary: variadic template regression : compiles without error
under 5.4.0 , with error under 7.1.0
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.vas.dias at gmail dot com
  Target Milestone: ---

Created attachment 41662
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41662=edit
Example PieceWise Constructed (PWC) Tuple class

I would really appreciate some pointers as to how to diagnose what may be at
fault from error messages such as :


$ gcc_7_1_env
# select to use newly build GCC 7.1.0 version, installed in /usr/gcc7_1bin/ ,
# and with LD_LIBRARY_PATH set to pick up 7.1.0 libraries first

$ g++ -I. -std=gnu++14 -mtune=native -g -O2 -fPIC -pipe -pthread -D_REENTRANT \
-Wall -Wextra -Wno-unused -fno-pretty-templates -Wno-register  \
tTuple.C -o tTuple

In file included from tTuple.C:2:0:
./tuple.H: In member function 'void U::PWC::tuple<_Head,
_Tail>::_call(U::PWC::tuple<_Head, _Tail>::_ThisConstPtr_u, size_t,
U::PWC::tuple<_Head, _Tail>::_FunctionPtr_u, const _HeadList& ...) const':
./tuple.H:184:23: error: expected primary-expression before '...' token
   _t._call<  _HeadList...
   ^~~
./tuple.H:184:23: error: expected ';' before '...' token
./tuple.H: In member function 'void U::PWC::tuple<_Head,
_Tail>::_call(U::PWC::tuple<_Head, _Tail>::_ThisConstPtr_u, size_t,
U::PWC::tuple<_Head, _Tail>::_FunctionPtr_u) const':
./tuple.H:210:19: error: expected primary-expression before '>' token
   _t._call< _Head >
   ^
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/gcc_7_1_bin/../libexec/gcc/x86_64-pc-linux-gnu/7.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /usr/os_src/gcc-7.1.0/configure --prefix=/usr
--program-suffix=_7_1 --libdir=/usr/lib64 --enable-shared
--enable-languages=all --enable-bootstrap --enable-multilib
--with-cpu-64=haswell --with-cpu-32=atom --with-arch-64=x86-64
--with-tune-64=haswell --with-arch-32=i686 --with-tune-32=atom
--enable-targets=all --enable-threads=posix --enable-lto
--enable-serial-configure --enable-checking=release --with-gmp=/usr
--with-gmp-lib=/usr/lib64 --with-mpfr=/usr --with-mpfr-lib=/usr/lib64
--with-mpc=/usr --with-mpc-lib=/usr/lib64 --with-isl=/usr
--with-isl-lib=/usr/lib64 --with-cloog=/usr --with-cloog-lib=/usr/lib64
--with-gnu-ld --with-gnu-as --enable-linker-build-id
--disable-libunwind-exceptions --disable-nls
--enable-version-specific-runtime-libs --enable-__cxa_atexit
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-system-zlib --enable-java-home --with-arch-directory=x86_64
--disable-libjava-multilib --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu
Thread model: posix
gcc version 7.1.0 (GCC)




If I run :

$ un_gcc_7_1_env
# this removes /usr/gcc7_1bin from $PATH and unsets LD_LIBRARY_PATH
$ g++ -v
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/5.4.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /usr/os_src/gcc-5.4.0/configure --prefix=/usr
--libdir=/usr/lib64 --enable-shared --enable-languages=all --enable-bootstrap
--enable-multilib --with-cpu-64=haswell --with-cpu-32=atom
--with-arch-64=x86-64 --with-tune-64=haswell --with-arch-32=i686
--with-tune-32=atom --enable-targets=all --enable-threads=posix --enable-lto
--enable-serial-configure --enable-checking=release --with-gmp=/usr
--with-gmp-lib=/usr/lib64 --with-mpfr=/usr --with-mpfr-lib=/usr/lib64
--with-mpc=/usr --with-mpc-lib=/usr/lib64 --with-isl=/usr
--with-isl-lib=/usr/lib64 --with-cloog=/usr --with-cloog-lib=/usr/lib64
--with-gnu-ld --with-gnu-as --enable-linker-build-id
--disable-libunwind-exceptions --disable-nls
--enable-version-specific-runtime-libs --enable-__cxa_atexit
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-system-zlib --enable-java-home --with-arch-directory=x86_64
--disable-libjava-multilib --with-stage1-ldflags=-lstdc++
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
Thread model: posix
gcc version 5.4.0 (GCC)

G++ 5.4.0 compiles the same code without error or warning :

$ g++ -I. -std=gnu++14 -mtune=native -g -O2 -fPIC -pipe -pthread -D_REENTRANT
-Wall -Wextra -Wno-unused -fno-pretty-templates -Wno-register  tTuple.C -o
tTuple
$ ./tTuple
# type three strings:
one
two
three
# output:
one two three
 fun( one two three )
one
two
three
$

The example class is one I wrote several years ago for C++11, which is now
somehow broken by C++17 .  The same error is emitted by 7.1.0 regardless of 
'-std=gnu++11' OR 

[Bug c++/66944] ICE on static thread_local member in class template

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66944

--- Comment #7 from Jason Vas Dias  ---
And there is no workaround, really - one cannot initialize a 
C++ class object member of a static thread_local C++ template class object
member in one place, outside the class, and use that same object in a 
non-static member function of the template class,
and instantiate another instance of the same template (with different
parameters) in the same translation unit - re-declaration in each
using member function allows compilation to succeed, but just hides
the static class member, so you can't actually use the single initialized 
static member in a non-static member function. 

So you HAVE to access thread_local static class members ONLY through pointers ?
I will try this.

[Bug c++/66944] ICE on static thread_local member in class template

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66944

--- Comment #6 from Jason Vas Dias  ---
(In reply to Jason Vas Dias from comment #5)
> It also happens with GCC 5.4.0 -

Also happens in GCC 6.3.0 .

[Bug c++/66944] ICE on static thread_local member in class template

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66944

Jason Vas Dias  changed:

   What|Removed |Added

 CC||jason.vas.dias at gmail dot com

--- Comment #5 from Jason Vas Dias  ---
Very glad to find this bug, enabling my sanity to be preserved .

It also happens with GCC 5.4.0 - and yes, re-declaring as
'static thread_local' in each member function that uses a
static thread_local class member object appears to be the only workaround - 

thanks!
I hope this is fixed in 7.1 ...

[Bug c++/81047] New: thread local storage static class members of class type cannot be initialized

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81047

Bug ID: 81047
   Summary: thread local storage static class members of class
type cannot be initialized
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.vas.dias at gmail dot com
  Target Milestone: ---

I am not seeing how it is possible to initialize a static TLS structure
member that is of a class type :

#include 
#include 
struct in_tls
{ int a;
  std::string b;
};
bool tls_init=false;
struct A
{ static __thread in_tls _in_tls ;
  void f()
  { _in_tls.a = 1;
  }
  A()
  { if( !tls_init )
{ _in_tls = { 0, std::string() };
  tls_init = true;
}
  }
};
__thread in_tls A::_in_tls = { 0 };
// = { 0, "" } | 
// = { 0, std::string() } : tried both, same result
void init(void)
{ A::_in_tls.b=std::string();
  tls_init=true;
}
void init(void)  __attribute__((constructor));
int main(int argc, char *const* argv)
{ A a; a.f();
  return 0;
}


G++ 5.4.0 refuses to accept that 'in_tls.b' is initialized:

$ g++ -std=gnu++11 -I. -D_REENTRANT -pthread -fPIC -pipe -Wall -Wextra \
 -Wno-unused -o /tmp/t /tmp/tTLS.C
/tmp/tTLS.C:20:34: warning: missing initializer for member 'in_tls::b'
[-Wmissing-field-initializers]
 __thread in_tls A::_in_tls = { 0 };
  ^
/tmp/tTLS.C:20:34: error: non-local variable 'A::_in_tls' declared '__thread'
needs dynamic initialization
/tmp/tTLS.C:20:17: note: C++11 'thread_local' allows dynamic initialization and
destruction
 __thread in_tls A::_in_tls = { 0 };
 ^

But I cannot seem to find ANY way to initialize a member like 'b' of a 
static TLS member .

The test code compiles fine (with a warning about uninitialized '_in_tls.b',
(unless its initializer is specified like '{0, std::string()}', then no
warning) - but does succeed, if either of :
1. '__thread' is undefined and redefined as nothing ;
 #undef __thread
 #define __thread
 (not a  workaround!)
OR
2. '_in_tls.b' is made to be not a C++ class object, like 'const char *' -
 (again, not a workaround)
changes are made.

There is no way to put C++ object structure members in TLS and get them
initialized ?

I have tried compiling with '-std=gnu++1'{4,7} with same result.

Is there any special magic I need to do to get the example
std::string '_in_tls.b' initialized so that compiler sees it and 
does not fail with the error?

Incidentally, the error is very confusing - it first claims that it
is an error to attempt to initialize the TLS variable dynamically, and
then issues a 'note:' that C++11 supports dynamic initialization of 
TLS objects - but it doesn't ?

thanks in advance for any advice,
Jason

[Bug c++/80920] New: warnings get position wrong - very confusing

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80920

Bug ID: 80920
   Summary: warnings get position wrong - very confusing
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.vas.dias at gmail dot com
  Target Milestone: ---

Attempts to compile the following demo code :
$ echo '
#include 
struct A
{ char _a[256];
  std::initializer_list _al;
  A( std::initializer_list l )
: _a({0}),
  _al(l)
  {}  
};
' > b.C

produce the warning:

$ c++ -std=c++17 -Wall -Wextra -c b2.C
b.C: In constructor 'A::A(std::initializer_list)':
b.C:7:12: warning: list-initializer for non-class type must not be
parenthesized
   _al(l)
^

This is very confusing, since the code that produces the warning is :
   _a({0})
 ^

Please could gcc point out the relevant element in the initializer list
that causes the problem, rather than the end of the initializer list, 
which makes it appear as if that line causes the problem .

Incidentally, why should it be illegal to specify an initializer for 
an array of non-class types ?  How else is one meant to ensure that
all elements of A::_a[] are initialized to zero ? Must one put :
   memset(_a, '\0', sizeof(_a))
inside the initializer - there is no other way ?

[Bug bootstrap/70519] genmatch fails to compile under gcc-5.2.0 - missing '-lstdc++' .

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70519

--- Comment #9 from Jason Vas Dias  ---
(In reply to Jakub Jelinek from comment #8)
> Where do you see -nostdlib being used?  I see it neither in your #c0, nor in
> #c1.
> Looking at my buildlog, -nostdlib is used to link only some libraries, like
> libstdc++.so.6 itself, or libvtv, libsanitizer libraries,
> libcc1/libcc1plugin, libcilkrts, libgcj, libgcj_bc, libgij, libjvm,
> libgcj-tools, but certainly not when linking build/*, or gcov, or cc1, ...

Yes, sorry, -nostdlib is not being used explicitly - but we seem to be 
getting the same effect with xg++ .

The problem is then that the stage2 xg++ is not adding -lstd++ automatically, 
and the scripts are not adding it to the stage2 configure's LDFLAGS - I think
they should be, or the part of them that is meant to be doing this has failed
to do so in my case . 
Any pointers as to where precisely in the build script code to look for where
-lstdc++ should be being added to the stage2 build LDFLAGS , or is it that 
xg++ should have been adding -lstdc++ if required , but wasn't ? 
Some clarification on that last point would be greatly appreciated.

[Bug bootstrap/70519] genmatch fails to compile under gcc-5.2.0 - missing '-lstdc++' .

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70519

--- Comment #7 from Jason Vas Dias  ---
So since I've produced a working Stage3 compiler in the build directory, './',
'./prev-gcc' should be the directory containing the Stage2 gcc build, and
it does in my case, with a config.log :


$ grep '^LDFLAGS=' prev-gcc/config.log
LDFLAGS='-static-libstdc++ -static-libgcc '

Now I think that this command should produce the output :


$ grep '^LDFLAGS=' prev-gcc/config.log
LDFLAGS='-static-libstdc++ -static-libgcc -lstdc++'

because we know that all the executables are produced with xg++  
given the '-nostdlib' option, and all C++ executables should be
linked against libstdc++ .

My question is simply why isn't the missing '-lstdc++' there ?

Next question: where is the code that is meant to be adding it somehow ?

[Bug bootstrap/70519] genmatch fails to compile under gcc-5.2.0 - missing '-lstdc++' .

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70519

--- Comment #6 from Jason Vas Dias  ---
Yes, Jakub, thanks, I know :
> If you link with g++ or xg++ instead of gcc or xgcc, then the driver is 
> adding 
> -lstdc++ automatically.

But it is not ME linking, it is the gcc-5.3.0 Makefile.in / configure.ac
scripts .

It seems to me on cursory inspection of these huge scripts that neither of them
are explicitly adding '-lstdc' anywhere onto the link lines for xg++ links, nor 
to LDFLAGS or ALL_LINKERFLAGS or BUILD_LDFLAGS or any link line containing
LDFLAGS
, as shown by this grep in the unmodified GCC 5.3.0 source directory:
[root@localhost:/usr/os_src/gcc-5.3.0 [4360] 16:23:17 #:8!:4399]
$ egrep '(LINKER|LD)FLAGS' Makefile.in Makefile.def Makefile.tpl
gcc/Makefile.in | egrep -i stdc\\+\\+\|stdc\[xp\]+
[root@localhost:/usr/os_src/gcc-5.3.0 $

ie. no references to 'stdc++' or stdcxx (case insensitive) in any line
containing
LDFLAGS or LINKER in any make script .

So it is very difficult to find the exact line of code that is meant to be 
adding the '-lstdc++' and somehow failed to do so in my case ! 

Is it meant to be added to LDFLAGS during the stage2 gcc configure using xg++
as the compiler ($CC) ? A search of the huge configure.ac scripts yields no
results :

$ egrep '(LINKER|LD)FLAGS' configure.ac gcc/configure.ac | egrep -i
stdc\\+\\+\|stdc\[xp]+
configure.ac:  LDFLAGS="$LDFLAGS -static-libstdc++ -static-libgcc"
$

So how are the build scripts meant to be adding '-lstdc++' to the link lines
of executables produced by the stage2 xg++ ? This is far from clear.

[Bug bootstrap/70519] genmatch fails to compile under gcc-5.2.0 - missing '-lstdc++' .

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70519

--- Comment #4 from Jason Vas Dias  ---
Thanks for having a look at this, Richard .

Yes, "some weirdness" is definitely going on -
but I'd like to determine precisely which "weirdness". 

This occurred when building my new LFS system's system compiler
for the first time, with a GCC-5.2.0 instance built for RHEL-6,
whose installation directories were all mounted with the 'bind'
option ( /usr/lib/gcc/x86_64-redhat-linux/5.2.0 ,
 /usr/libexec/gcc/x86_64-redhat-linux/5.2.0 , etc. )
and where $PATH picked up all gcc binaries from a 
'bin/' directory containing links like :
   gcc -> /${path_to_rhel6_usr_bin}/gcc5.2.0 
   ... etc.

My configure options were :

/usr/os_src/gcc-5.3.0/configure --prefix=/usr --libdir=/usr/lib64
--enable-shared \
  --enable-languages=all \
  --enable-bootstrap \
  --enable-multilib \
  --with-cpu-64=haswell \
  --with-cpu-32=atom \
  --with-arch-64=x86-64 \
  --with-tune-64=haswell \
  --with-arch-32=i686 \
  --with-tune-32=atom \
  --enable-targets=all \
  --enable-threads=posix \
  --enable-lto \
  --enable-serial-configure \
  --enable-checking=release \
  --with-stage1-ldflags='-L/usr/lib64 -L/usr/local/lib64 -L/usr/lib32
-L/usr/local/lib32
-Wl,-R,/usr/lib64:/usr/local/lib64:/usr/lib32:/usr/local/lib32' \
  --with-gmp=/usr   --with-gmp-lib=/usr/lib64 \
  --with-mpfr=/usr  --with-mpfr-lib=/usr/lib64 \
  --with-mpc=/usr   --with-mpc-lib=/usr/lib64 \
  --with-isl=/usr   --with-isl-lib=/usr/lib64 \
  --with-cloog=/usr --with-cloog-lib=/usr/lib64 \
  --with-gnu-ld \
  --with-gnu-as \
  --enable-linker-build-id \
  --disable-libunwind-exceptions \
  --disable-nls \
  --enable-version-specific-runtime-libs \
  --enable-__cxa_atexit \
  --without-x \
  --disable-gtk-cairo \
  --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre \
  --enable-libgcj-multifile \
  --with-ecj-jar=/usr/share/java/eclipse-ecj.jar \
  --with-system-zlib \
  --enable-java-home \
  --with-arch-directory=x86_64 \
  --disable-libjava-multilib \
  --build=x86_64-pc-linux-gnu \
  --host=x86_64-pc-linux-gnu


I had to radically modify the ./gcc/Makefile of the build directory 
to add '-static-libstdc++ -lstdc++' to EVERY executable's link command ,
finally the 'make' completed with 0 exit status, and 'make DESTDIR=... install' 
created the installation directory , and the test suite passed (with some
expected failures - details on request). 

The translated gcc/Makefile.in produced a gcc/Makefile containing  :

LDFLAGS = -static-libstdc++ -static-libgcc

Note: no -lstdc++ - I think the '-static-libstdc++' option on its own
does NOT imply '-lstdc++' - you have to add it to actually link against
libstdc++.a .

So that is what I did , modifying the above lines:

NEEDS_STDCXX = -static-libstdc++ -lstdc++
LDFLAGS = -static-libgcc $(NEEDS_STDCXX)

and I had to add this into many other places where an executable
is being produced and LDFLAGS is not referenced:

...
ALL_LINKERFLAGS = $(ALL_CXXFLAGS) -static-libgcc $(NEEDS_STDCXX)
...

# For stage1 and when cross-compiling use the build libcpp which is
# built with NLS disabled.  For stage2+ use the host library and
# its dependencies.
ifeq ($(build_objdir),$(build_libobjdir))
BUILD_CPPLIB = $(build_libobjdir)/libcpp/libcpp.a
else
BUILD_CPPLIB = $(CPPLIB) $(LIBIBERTY) 
build/genmatch$(build_exeext): BUILD_LIBDEPS += $(LIBINTL_DEP) $(LIBICONV_DEP) 
build/genmatch$(build_exeext): BUILD_LIBS += $(LIBINTL) $(LIBICONV)
$(NEEDS_STDCXX)
endif

...


I suggest making the gcc/Makefile.in / $TOPDIR/{configure.ac,Makefile.am}
add '-lstdc++' every time it writes '-static-libstdc++' to the Makefile ,
eg. $TOPDIR/configure.ac @ line 1376:

# Check whether -static-libstdc++ -static-libgcc is supported.
have_static_libs=no
if test "$GCC" = yes; then
  saved_LDFLAGS="$LDFLAGS"

  LDFLAGS="$LDFLAGS -static-libstdc++ -static-libgcc"
#   ^- add ' -lstdc++' here

@ line 1718:

[stage1_ldflags=
 # In stage 1, default to linking libstdc++ and libgcc statically with GCC
 # if supported.  But if the user explicitly specified the libraries to use,
 # trust that they are doing what they want.
 if test "$stage1_libs" = "" -a "$have_static_libs" = yes; then
   stage1_ldflags="-static-libstdc++ -static-libgcc"
 # ^- add ' -lstdc++' here

 fi])


@ line 1741:

[poststage1_ldflags=
 # In stages 2 and 3, default to linking libstdc++ and libgcc
 # statically.  But if the user explicitly specified the libraries to
 # use, trust that they are doing what they want.
 if test "$poststage1_libs" = ""; then
   poststage1_ldflags="-static-libstdc++ -static-libgcc"
 # ^- add ' -lstdc++' here
 fi])


I can't put my finger on the component that is meant to add '-lstdc++' 
to the poststage1_ldflags if not above modified lines ATM - what is meant
to be doing this ?

I will try building with the configure.ac so modified 

[Bug bootstrap/70519] genmatch fails to compile under gcc-5.2.0 - missing '-lstdc++' .

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70519

--- Comment #2 from Jason Vas Dias  ---
In fact, it happens for EVERY executable produced by stage2 compiler!
Why is this - do I need to add '-lstdc++' to LDFLAGS or to 
--with-stage1-ldflags / --with-boot-ldflags in order to build gcc-5.3.0 ?

[Bug bootstrap/70519] genmatch fails to compile under gcc-5.2.0 - missing '-lstdc++' .

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70519

--- Comment #1 from Jason Vas Dias  ---
And it happens for gcov also:


/usr/build/linux/gcc-5.3.0/./prev-gcc/xg++
-B/usr/build/linux/gcc-5.3.0/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/
-nostdinc++
-B/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
 -I/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/include 
-I/usr/os_src/gcc-5.3.0/libstdc++-v3/libsupc++
-L/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
  -g -O2 -gtoggle -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-static-libstdc++ -static-libgcc  gcov.o libcommon.a ../libcpp/libcpp.a  
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a  -o gcov
libcommon.a(pretty-print.o): In function `pretty_printer::~pretty_printer()':
pretty-print.c:(.text+0x1ce): undefined reference to `operator delete(void*)'
libcommon.a(input.o): In function `diagnostic_file_cache_init() [clone
.part.5]':
input.c:(.text+0x1da): undefined reference to `operator new[](unsigned long)'
libcommon.a(input.o): In function `diagnostic_file_cache_fini()':
input.c:(.text+0x88d): undefined reference to `operator delete[](void*)'
collect2: error: ld returned 1 exit status
Makefile:2673: recipe for target 'gcov' failed
make[3]: *** [gcov] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory '/usr/build/linux/gcc-5.3.0/gcc'
Makefile:4411: recipe for target 'all-stage2-gcc' failed
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory '/usr/build/linux/gcc-5.3.0'
Makefile:21905: recipe for target 'stage2-bubble' failed
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory '/usr/build/linux/gcc-5.3.0'
Makefile:902: recipe for target 'all' failed
make: *** [all] Error 2
[root@[Linux]:/usr/build/linux/gcc-5.3.0 [5067] 14:07:38 #:111!:1990]
$ cd gcc
[root@[Linux]:/usr/build/linux/gcc-5.3.0/gcc [5067] 14:08:10 #:112!:1991]
$ /usr/build/linux/gcc-5.3.0/./prev-gcc/xg++
-B/usr/build/linux/gcc-5.3.0/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/
-nostdinc++
-B/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
 -I/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/include 
-I/usr/os_src/gcc-5.3.0/libstdc++-v3/libsupc++
-L/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
  -g -O2 -gtoggle -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-static-libstdc++ -static-libgcc  gcov.o libcommon.a ../libcpp/libcpp.a  
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a  -o gcov
libcommon.a(pretty-print.o): In function `pretty_printer::~pretty_printer()':
pretty-print.c:(.text+0x1ce): undefined reference to `operator delete(void*)'
libcommon.a(input.o): In function `diagnostic_file_cache_init() [clone
.part.5]':
input.c:(.text+0x1da): undefined reference to `operator new[](unsigned long)'
libcommon.a(input.o): In function `diagnostic_file_cache_fini()':
input.c:(.text+0x88d): undefined reference to `operator delete[](void*)'
collect2: error: ld returned 1 exit status
[root@[Linux]:/usr/build/linux/gcc-5.3.0/gcc [5067] 14:08:21 #:113!:1992]
$ /usr/build/linux/gcc-5.3.0/./prev-gcc/xg++
-B/usr/build/linux/gcc-5.3.0/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/
-nostdinc++
-B/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
 -I/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/include 
-I/usr/os_src/gcc-5.3.0/libstdc++-v3/libsupc++
-L/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
  -g -O2 -gtoggle -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic

[Bug bootstrap/70519] New: genmatch fails to compile under gcc-5.2.0 - missing '-lstdc++' .

[jason.vas.dias at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70519

Bug ID: 70519
   Summary: genmatch fails to compile under gcc-5.2.0 - missing
'-lstdc++' .
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.vas.dias at gmail dot com
  Target Milestone: ---

I am trying to build gcc-5.3.0 with gcc-5.2.0 , on an x86-64 (Haswell) Linux
box, and am getting this unexpected compilation failure building the unmodified
gcc-5.3.0 source after configuration,  with 'make' :

/usr/build/linux/gcc-5.3.0/./prev-gcc/xg++
-B/usr/build/linux/gcc-5.3.0/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/
-nostdinc++
-B/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
 -I/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/include 
-I/usr/os_src/gcc-5.3.0/libstdc++-v3/libsupc++
-L/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
  -g -O2 -gtoggle -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-DGENERATOR_FILE -static-libstdc++ -static-libgcc  -o build/genmatch \
build/genmatch.o ../libcpp/libcpp.a ../libiberty/libiberty.a build/errors.o
build/vec.o build/hash-table.o .././libiberty/libiberty.a  
build/genmatch.o: In function `lower_cond(operand*) [clone .constprop.91]':
genmatch.c:(.text+0xc7a): undefined reference to `operator new(unsigned long)'
genmatch.c:(.text+0xe2e): undefined reference to `operator new(unsigned long)'
genmatch.c:(.text+0x125d): undefined reference to `operator new(unsigned long)'
genmatch.c:(.text+0x146b): undefined reference to `operator new(unsigned long)'
genmatch.c:(.text+0x15ef): undefined reference to `operator new(unsigned long)'
build/genmatch.o:genmatch.c:(.text+0x17b5): more undefined references to
`operator new(unsigned long)' follow
build/genmatch.o: In function `main':
genmatch.c:(.text.startup+0x6015): undefined reference to `operator
delete(void*)'
genmatch.c:(.text.startup+0x60d6): undefined reference to `operator
new(unsigned long)'
genmatch.c:(.text.startup+0x6148): undefined reference to `operator
new(unsigned long)'
collect2: error: ld returned 1 exit status
Makefile:2613: recipe for target 'build/genmatch' failed


Adding '-lstdc++' to the xg++ command above enables it to succeed .
Why the missing '-lstdc++' ?  Intentional ? An error ? 
Only when compiling under 5.2.0 ?
I can check in a Makefile.in patch if it would help ...

[Bug testsuite/55621] no gcc or g++ tests run for solaris2.11 target : missing $OBJDIR/gcc/testsuite/config/unix_{gcc,g++}.exp files

[jason.vas.dias at gmail dot com]

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



--- Comment #1 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-12-09 
08:15:58 UTC ---

After successfully building gcc-4.7.2 for multi-lib i386-pc-solaris2.11 

target ( x86_64 Solaris 11 ) ,  with configure arguments :



$ gcc -v

Target: i386-pc-solaris2.11

Configured with: ../configure --prefix=/usr/GNU --enable-languages=c,c++

--enable-threads --enable-version-specific-runtime-libs --disable-nls

--with-as=/usr/bin/as --with-ld=/usr/bin/ld --with-gmp=/usr/GNU

--with-mpfr=/usr/GNU --with-mpc=/usr/GNU

Thread model: posix

gcc version 4.7.2 (GCC) 

$



I try to run:

$ make check

or 

$ make check-gcc

or 

$ make check-g++



but all fail with a DeJaGNU expect error:



...

Target is i386-pc-solaris2.11

Host   is i386-pc-solaris2.11



=== gcc tests ===



ERROR: errors in tool init file

/usr/src/gnu/gcc-4.7.2/gcc/testsuite/config/unix

-gcc.exp

couldn't read file /usr/src/gnu/gcc-4.7.2/gcc/testsuite/config/unix-gcc.exp:

N

o such file or directory

while executing

source /usr/src/gnu/gcc-4.7.2/gcc/testsuite/config/unix-gcc.expmake[3]:

[check

-parallel-gcc] Error 1 (ignored)

make[3]: Leaving directory `/usr/share/src/gnu/gcc-4.7.2/solaris11-amd64/gcc'



...

=== g++ tests ===



ERROR: errors in tool init file

/usr/src/gnu/gcc-4.7.2/gcc/testsuite/config/unix

-g++.exp

couldn't read file /usr/src/gnu/gcc-4.7.2/gcc/testsuite/config/unix-g++.exp:

N

o such file or directory

while executing

source /usr/src/gnu/gcc-4.7.2/gcc/testsuite/config/unix-g++.expmake[3]:

[check

-parallel-g++] Error 1 (ignored)

make[3]: Leaving directory `/usr/share/src/gnu/gcc-4.7.2/solaris11-amd64/gcc'





The only tests which are run are the libiberty tests:



make[3]: Entering directory

`/usr/share/src/gnu/gcc-4.7.2/solaris11-amd64/libibe

rty/testsuite'

./test-demangle  ../../../libiberty/testsuite/demangle-expected

./test-demangle: 874 tests, 0 failures

./test-pexecute

./test-expandargv

PASS: test-expandargv-0.

PASS: test-expandargv-1.

PASS: test-expandargv-2.

PASS: test-expandargv-3.

PASS: test-expandargv-4.

PASS: test-expandargv-5.

PASS: test-expandargv-6.

make[3]: Leaving directory

`/usr/share/src/gnu/gcc-4.7.2/solaris11-amd64/libiber

ty/testsuite'





I installed SUNWguile ( guile 1.8.6 ) , SUNWautogen ( autogen 5.9 ) , and built

and installed dejagnu-1.1.1 against installed SUNWtcl-8 ( 8.5.9 ), and also 

tried using the installed /usr/bin/expect ( --version : 5.45 ) and runtest,

with the same result .  

A successful make check on linux does not create any

$OBJDIR/gcc/testsuite/config/*.exp files - the only file there is default.exp

, and there does

not seem to be anything generating these files.  

Please advise - thanks in advance!

[Bug testsuite/55621] no gcc or g++ tests run for solaris2.11 target : missing $OBJDIR/gcc/testsuite/config/unix_{gcc,g++}.exp files

[jason.vas.dias at gmail dot com]

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



--- Comment #5 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-12-09 
08:55:38 UTC ---

Created attachment 28903

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

/usr/GNU/lib/dejagnu/runtest.exp

[Bug testsuite/55621] no gcc or g++ tests run for solaris2.11 target : missing $OBJDIR/gcc/testsuite/config/unix_{gcc,g++}.exp files

[jason.vas.dias at gmail dot com]

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



--- Comment #6 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-12-09 
08:59:34 UTC ---

Oops, I picked the last of :

$ lftp ftp.gnu.org

lftp ftp.gnu.org:~ cd pub/gnu/dejagnu  

cd ok, cwd=/pub/gnu/dejagnu   

lftp ftp.gnu.org:/pub/gnu/dejagnu ls -ltr

-rw-r--r--1 3003 65534 1553267 Feb 15  1996 dejagnu-1.3.tar.gz

-rw-r--r--1 3003 65534 2119630 Mar 25  2001 dejagnu-1.4.0.tar.gz

-rw-r--r--1 3003 65534 1330595 May 06  2001 dejagnu-1.4.1.tar.gz

-rw-r--r--1 3003 65534 1414450 Sep 13  2001 dejagnu-1.4.2.tar.gz

-rw-r--r--1 3003 65534 1817399 Sep 23  2002 dejagnu-1.4.3.tar.gz

-rw-r--r--1 3003 65534 1080346 Jan 30  2004 dejagnu-1.4.4.tar.gz

-rw-r--r--1 3003 65534  65 Jan 30  2004

dejagnu-1.4.4.tar.gz.sig

-rw-r--r--1 3003 65534  576269 Mar 10  2011 dejagnu-1.5.tar.gz

-rw-r--r--1 3003 65534  65 Mar 10  2011 dejagnu-1.5.tar.gz.sig

-rw-r--r--1 3003 65534 1220452 Mar 24  2011 dejagnu-1.2.tar.gz

-rw-r--r--1 3003 65534  65 Mar 24  2011 dejagnu-1.2.tar.gz.sig

-rw-r--r--1 3003 65534 1029828 Mar 24  2011 dejagnu-1.1.1.tar.gz

-rw-r--r--1 3003 65534  65 Mar 24  2011

dejagnu-1.1.1.tar.gz.sig



I'll try dejagnu-1.4.4.tar.gz . Sorry ! Usually, most recent packages are 

latest versions :-)

[Bug testsuite/55621] no gcc or g++ tests run for solaris2.11 target : missing $OBJDIR/gcc/testsuite/config/unix_{gcc,g++}.exp files

[jason.vas.dias at gmail dot com]

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



Jason Vas Dias jason.vas.dias at gmail dot com changed:



   What|Removed |Added



 Status|WAITING |RESOLVED

 Resolution||WORKSFORME



--- Comment #7 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-12-09 
09:11:38 UTC ---

Yes, that was it. Sorry - maybe the dejagnu version could be detected and

complained about if insufficient ?

[Bug testsuite/55621] New: no gcc or g++ tests run for solaris2.11 target : missing $OBJDIR/gcc/testsuite/config/unix_{gcc,g++}.exp files

[jason.vas.dias at gmail dot com]

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



 Bug #: 55621

   Summary: no gcc or g++ tests run for solaris2.11 target :

missing

$OBJDIR/gcc/testsuite/config/unix_{gcc,g++}.exp files

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: testsuite

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

ReportedBy: jason.vas.d...@gmail.com

[Bug c++/54348] New: wrong error reported for type mismatch in conditional expression : error: no match for ternary 'operator?:' in 'false ?

[jason.vas.dias at gmail dot com]

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

 Bug #: 54348
   Summary: wrong error reported for type mismatch in conditional
expression : error: no match for ternary 'operator?:'
in 'false ?
Classification: Unclassified
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jason.vas.d...@gmail.com


Having  made the simple mistake of returning an object of a different type
in the '? ( ... )' and ': ( ... )' clauses of a ternary expression ,
I'd expect and it would be helpful if g++ would emit the C error
  error: type mismatch in conditional expression and not
  error: no match for ternary 'operator?:' in 'false ? ...
This is extremely confusing, as it suggests that the ternary expression
 somehow contains an unbalanced number of parentheses or something.

This code triggers the issue:

code
#include string
#include list
using namespace std;
void f()
{
  struct strct { string name, items ;};
  list string myItems;
  string myName();
  string as  ( (   strct*)0)  - items)) 
== strct*)0) - name))
   ) ? myItems 
 : myName
 )
 ;
}
/code

Compilation with gcc-4.6.0  gcc-4.6.3 returns this error:

$ g++ -c gxx_bug.cpp
gxx_bug.cpp: In function 'void f()':
gxx_bug.cpp:12:14: error: no match for ternary 'operator?:' in 'false ? myItems
: myName'

whereas changing 'list string myItems' to 'string myItems' allows compilation
to succeed.

Shouldn't g++ be complaining about initializing a string with a liststring
rather than this cryptic no match for ternary 'operator?:' here ?

[Bug c++/54348] confusing error reported for type mismatch in conditional expression : error: no match for ternary 'operator?:' in 'false ?

[jason.vas.dias at gmail dot com]

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

--- Comment #5 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-08-21 
20:27:36 UTC ---
Oops, I was interrupted adding this comment to my initial comment - will
respond
to subsequent commment next :

Incidentally, I found this issue while developing a C++-98 replacement for
C-99 designated initializers for specific structs with generated macros :
code
#include string
#include list
using namespace std;

struct strct 
{
string name, items ;
strct (string n, string i) : name(n), items(i){}
};

#define tok(t) t

#define the_struct_strct_member( member, a0, a1, a2, a3 )\
( struct strct*)0) - member ) == (((struct strct*)0) - a0)) \
   ? a1\
   :( ( (((struct strct*)0) - member) ==  (((struct strct*)0) - a2) ) \
  ? a3\
  : NULL\
)\
)

#define struct_strct( a0, a1, a2, a3 )\
(the_struct_strct_member( tok(name)  , a0, a1, a2, a3 ),\
 the_struct_strct_member( tok(items) , a0, a1, a2, a3 )\
)

void f()
{

  string myItems;
  string myName();

  strct s  struct_strct( items, myItems, name, myName ) ;
}
/code

This works!

[Bug c++/54348] confusing error reported for type mismatch in conditional expression : error: no match for ternary 'operator?:' in 'false ?

[jason.vas.dias at gmail dot com]

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

--- Comment #6 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-08-21 
20:29:53 UTC ---
(In reply to comment #1)
 In mainline the diagnostics is better because we output the types. But I agree
 that given that the conditional operator cannot be overloaded the error 
 message
 could be more clear.

yes, that is all I'm saying

[Bug c++/54348] confusing error reported for type mismatch in conditional expression : error: no match for ternary 'operator?:' in 'false ?

[jason.vas.dias at gmail dot com]

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

--- Comment #7 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-08-21 
20:34:06 UTC ---
(In reply to comment #2)
 (In reply to comment #0)
  Shouldn't g++ be complaining about initializing a string with a liststring
  rather than this cryptic no match for ternary 'operator?:' here ?
 
 No, not really.
 
 The object being initialized by the result of the condition expression is
 irrelevant, the conditional expression isn't valid whether or not you're using
 it to initialize another object.
 
 In this reduced version it wouldn't make sense to refer to initializing any
 object with any other:
 
 struct A {} a;
 struct B {} b;
 
 void f()
 {
 false ? a : b;
 }

but this is not the same. surely ? the above is not a valid statement -
I was saying:

  some_type some_object = false ? a : b;

[Bug c++/54348] confusing error reported for type mismatch in conditional expression : error: no match for ternary 'operator?:' in 'false ?

[jason.vas.dias at gmail dot com]

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

--- Comment #8 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-08-21 
20:52:12 UTC ---
All I'm suggesting is that g++ should try to find the most basic error, 
which is that different type objects are returned as the result of a
conditional expression, and not  no match for ternary 'operator?:' -
what does this mean, it was searching namespace std:: for string::operator::?:
?
then this succeeded, and it found it could not apply it because the types
were different - shouldn't it complain about the root cause, that the types
were different, rather than the symptom of not being able to satisfy
operator std::string::?:() ?

[Bug c/54179] New: please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

 Bug #: 54179
   Summary: please split insn-emit.c !
Classification: Unclassified
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jason.vas.d...@gmail.com


I've been attempting to build a C only bootstrap 4.7.1 compiler on x86_64
Linux.

Building the Stage1 and Stage2 compilers takes @ 8 hours on my 2.2Ghz machine -
which I have to continually cycle down to 800Mhz for 2 seconds every 8 seconds
with a script under Linux 3.4.4, otherwise I get overheating emergency reboots
-
 nice!

But with -lto enabled, the build of Stage 3 compiler gets to trying to build
insn-emit.c , but has not yet completed given a previous two-day run - during
which I have to be careful not to do any extra activity which might tip the
machine past the 105 degree emergency reboot trip-point - so basically 
I have to lock up my laptop in a freezer for 3-days plus in order to build
gcc :

   $ ps -lp $(pgrep cc1)
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY  TIME CMD
0 R 0  3863  3862 99  80   0 - 64611 -  pts/520:43:01 cc1

   $ tr '\0' ' '  /proc/3863/cmdline
/mnt/sda3/gcc/./prev-gcc/cc1 -quiet -I . -I . -I /usr/build2/gcc/gcc-4.7.1/gcc
-I /usr/build2/gcc/gcc-4.7.1/gcc/. -I /usr/build2/gcc/gcc-4.7.1/gcc/../include
-I /usr/build2/gcc/gcc-4.7.1/gcc/../libcpp/include -I
/usr/build2/gcc/gcc-4.7.1/gcc/../libdecnumber -I
/usr/build2/gcc/gcc-4.7.1/gcc/../libdecnumber/bid -I ../libdecnumber -iprefix
/mnt/sda3/gcc/prev-gcc/../lib64/gcc/x86_64-pc-linux-gnu/4.7.1/ -isystem
/mnt/sda3/gcc/./prev-gcc/include -isystem
/mnt/sda3/gcc/./prev-gcc/include-fixed -D IN_GCC -D HAVE_CONFIG_H -isystem
/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include
insn-emit.c -quiet -dumpbase insn-emit.c -mtune=k8 -march=x86-64 -auxbase-strip
insn-emit.o -g -gtoggle -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat -o /tmp/ccgsb5Pk.s 
$ ls -l /mnt/sda3/gcc/gcc/insn-emit.c
-rw-r--r-- 1 root devel 1793209 Jul 22 22:13 /mnt/sda3/gcc/gcc/insn-emit.c
$ ls -l /tmp/ccgsb5Pk.s
-rw--- 1 root root 1101824 Aug  5 11:00 /tmp/ccgsb5Pk.s
   $ cat /proc/3863/map

$ cat /proc/3863/maps | wc -l
5310

Wow, that's alot of maps !

0040-05c2 r-xp  08:03 132489
/mnt/sda3/gcc/prev-gcc/cc1
05e1f000-05e2b000 rw-p 0581f000 08:03 132489
/mnt/sda3/gcc/prev-gcc/cc1
7fd59f821000-7fd59f836000 r-xp  08:03 135449
/mnt/sda3/gcc/prev-gcc/libgcc_s.so.1
7fd59f836000-7fd59fa35000 ---p 00015000 08:03 135449
/mnt/sda3/gcc/prev-gcc/libgcc_s.so.1
7fd59fa35000-7fd59fa36000 rw-p 00014000 08:03 135449
/mnt/sda3/gcc/prev-gcc/libgcc_s.so.1
7fd59fa36000-7fd59fb2e000 r-xp  08:06 772762
/lib64/libm-2.16.so 
7fd59fb2e000-7fd59fd2d000 ---p 000f8000 08:06 772762
/lib64/libm-2.16.so 
7fd59fd2d000-7fd59fd2e000 r--p 000f7000 08:06 772762
/lib64/libm-2.16.so
7fd59fd2e000-7fd59fd2f000 rw-p 000f8000 08:06 772762
/lib64/libm-2.16.so
7fd59fd2f000-7fd59fe13000 r-xp  08:06 184127
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libstdc++.so.6.0.15
7fd59fe13000-7fd5a0013000 ---p 000e4000 08:06 184127
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libstdc++.so.6.0.15
7fd5a0013000-7fd5a001b000 r--p 000e4000 08:06 184127
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libstdc++.so.6.0.15
7fd5a001b000-7fd5a001d000 rw-p 000ec000 08:06 184127
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libstdc++.so.6.0.15
7fd5a0032000-7fd5a0063000 r-xp  08:06 147372
/usr/lib64/libpolylib64.so.8.1.0
7fd5a0063000-7fd5a0263000 ---p 00031000 08:06 147372
/usr/lib64/libpolylib64.so.8.1.0
7fd5a0263000-7fd5a0264000 rw-p 00031000 08:06 147372
/usr/lib64/libpolylib64.so.8.1.0
7fd5a0268000-7fd5a0405000 r-xp  08:06 868371
/lib64/libc-2.16.so
7fd5a0405000-7fd5a0604000 ---p 0019d000 08:06 868371
/lib64/libc-2.16.so
7fd5a0604000-7fd5a0608000 r--p 0019c000 08:06 868371
/lib64/libc-2.16.so
7fd5a0608000-7fd5a060a000 rw-p 001a 08:06 868371
/lib64/libc-2.16.so
7fd5a060e000-7fd5a0626000 r-xp  08:06 150900
/usr/lib64/libz.so.1.2.5
7fd5a0626000-7fd5a0825000 ---p 00018000 08:06 150900
/usr/lib64/libz.so.1.2.5
7fd5a0825000-7fd5a0826000 rw-p 00017000 08:06 150900   

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

--- Comment #1 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-08-05 
11:11:28 UTC ---
Why must we compile 1.8MB of insn-emit.c ?

Can't it be split up ?

Why is gcc-4.7.1 SO much slower ?
  ie. evidently the Stage1 and Stage2 compilers were able to build insn-emit.c
  in acceptable time. Why is the Stage3 compiler unable to do it in over 2 days
??

Why over 5000 memory maps ? 

When I strace the process, all it seems to be doing is managing this vast
amount
of memory :
$ strace -tfp 3863
Process 3863 attached - interrupt to quit
11:10:24 madvise(0x7fd59ef79000, 16384, MADV_DONTNEED) = 0
11:10:24 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0
11:10:33 madvise(0x7fd3f95b8000, 4096, MADV_DONTNEED) = 0
11:10:33 madvise(0x7fd4d9c15000, 4096, MADV_DONTNEED) = 0
11:10:33 madvise(0x7fd4d9c11000, 4096, MADV_DONTNEED) = 0
11:10:33 madvise(0x7fd3f95b7000, 4096, MADV_DONTNEED) = 0

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

--- Comment #3 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-08-05 
11:36:05 UTC ---
RE:
 Your PC is broken.
Comments such as these don't help much.
No, only Linux 3.4+ temperature management is.
I'm working with the Linux developers to resolve this .
Meanwhile, I'm stuck with gcc-4.6.0, which I'd like to do something about.

 C only build with 3 stages takes about 18 minutes with -j2
 on my PC.

And what type of super-computer is that ?

 Compilation of small count of big files is faster than big count of small
 files.

Not in my experience. Why force such huge memory resource demands ?

I guess as usual no help is to be expected from gcc-bugs - I'll have to
modify genemit.c myself.

One final try before I go modifying genemit.c :
Can anyone suggest what state cc1 is in when it shows this 20 minute strace:

$ strace -tfp 3863   
Process 3863 attached - interrupt to quit
11:10:24 madvise(0x7fd59ef79000, 16384, MADV_DONTNEED) = 0
11:10:24 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 
11:10:33 madvise(0x7fd3f95b8000, 4096, MADV_DONTNEED) = 0 
11:10:33 madvise(0x7fd4d9c15000, 4096, MADV_DONTNEED) = 0 
11:10:33 madvise(0x7fd4d9c11000, 4096, MADV_DONTNEED) = 0 
11:10:33 madvise(0x7fd3f95b7000, 4096, MADV_DONTNEED) = 0 
11:11:09 madvise(0x7fd59ef79000, 16384, MADV_DONTNEED) = 0
11:11:09 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 
11:11:20 madvise(0x7fd3f95b1000, 4096, MADV_DONTNEED) = 0 
11:11:20 madvise(0x7fd4d9c17000, 4096, MADV_DONTNEED) = 0 
11:11:56 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 
11:11:56 madvise(0x7fd3f95b1000, 4096, MADV_DONTNEED) = 0 
11:12:04 write(3, ax, %rsi\n\tjmp\t.L1804\n\t.cfi_endpr..., 4096) = 4096
11:12:04 madvise(0x7fd3f95a6000, 4096, MADV_DONTNEED) = 0 
11:12:04 madvise(0x7fd59ef75000, 16384, MADV_DONTNEED) = 0
11:12:04 madvise(0x7fd4d9c1b000, 4096, MADV_DONTNEED) = 0 
11:12:04 madvise(0x7fd4d9c16000, 4096, MADV_DONTNEED) = 0 
11:12:46 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 
11:12:46 madvise(0x7fd3f95a6000, 4096, MADV_DONTNEED) = 0 
11:12:55 madvise(0x7fd3f95ec000, 4096, MADV_DONTNEED) = 0 
11:12:55 madvise(0x7fd3f95ab000, 4096, MADV_DONTNEED) = 0 
11:12:55 madvise(0x7fd4971f4000, 4096, MADV_DONTNEED) = 0 
11:12:55 madvise(0x7fd4d9c21000, 4096, MADV_DONTNEED) = 0 
11:12:55 madvise(0x7fd4d9c0e000, 4096, MADV_DONTNEED) = 0 
11:13:31 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 
11:13:31 madvise(0x7fd3f95ec000, 4096, MADV_DONTNEED) = 0 
11:13:44 madvise(0x7fd3f95a8000, 4096, MADV_DONTNEED) = 0 
11:13:44 madvise(0x7fd4d9c24000, 4096, MADV_DONTNEED) = 0 
11:13:44 madvise(0x7fd4d9c2, 4096, MADV_DONTNEED) = 0 
11:13:44 madvise(0x7fd3f95a4000, 4096, MADV_DONTNEED) = 0 
11:14:14 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 
11:14:14 madvise(0x7fd3f95a8000, 4096, MADV_DONTNEED) = 0 
11:14:22 madvise(0x7fd3f95a1000, 4096, MADV_DONTNEED) = 0 
11:14:22 madvise(0x7fd4d9fda000, 4096, MADV_DONTNEED) = 0 
11:14:22 madvise(0x7fd4d9c27000, 4096, MADV_DONTNEED) = 0 
11:14:53 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 
11:14:53 madvise(0x7fd3f95a1000, 4096, MADV_DONTNEED) = 0 
11:14:59 madvise(0x7fd3f959d000, 4096, MADV_DONTNEED) = 0 
11:14:59 madvise(0x7fd4d9c2a000, 4096, MADV_DONTNEED) = 0 
11:14:59 madvise(0x7fd4d9c25000, 4096, MADV_DONTNEED) = 0 
11:15:29 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 
11:15:29 madvise(0x7fd3f959d000, 4096, MADV_DONTNEED) = 0 
11:15:36 madvise(0x7fd3f9599000, 4096, MADV_DONTNEED) = 0 
11:15:36 madvise(0x7fd4d9c2c000, 4096, MADV_DONTNEED) = 0 
11:16:10 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 
11:16:10 madvise(0x7fd3f9599000, 4096, MADV_DONTNEED) = 0 
11:16:16 write(3, 1699:\n\t.cfi_startproc\n\tmovq\t%rbx..., 4096) = 4096
11:16:17 madvise(0x7fd3f9596000, 4096, MADV_DONTNEED) = 0 
11:16:17 madvise(0x7fd4d9c2d000, 4096, MADV_DONTNEED) = 0 
11:16:17 madvise(0x7fd4d9c2b000, 4096, MADV_DONTNEED) = 0 
11:16:17 madvise(0x7fd3f9594000, 4096, MADV_DONTNEED) = 0 
11:16:50 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 
11:16:50 madvise(0x7fd3f9596000, 4096, MADV_DONTNEED) = 0 
11:16:57 madvise(0x7fd3f95e1000, 4096, MADV_DONTNEED) = 0 
11:16:57 madvise(0x7fd3f958e000, 4096, MADV_DONTNEED) = 0 
11:16:57 madvise(0x7fd4d9c3, 4096, MADV_DONTNEED) = 0 
11:17:18

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

--- Comment #4 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-08-05 
11:43:03 UTC ---
in case the configuration is relevant:

quote file=config.log
It was created by configure, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ /usr/build2/gcc/gcc-4.7.1/configure --prefix=/usr --libdir=/usr/lib64
--with-cpu-32=i686 --with-cpu-64=k8 --enable-languages=c
--disable-build-with-cxx --disable-
build-poststage1-with-cxx --enable-stage1-checking=all
--enable-stage1-languages=c --enable-targets=all --enable-multilib
--enable-threads=posix --enable-tls --enable
-lto --enable-shared --enable-checking=release --with-build-time-tools=/usr/bin
--with-ld=/usr/bin/ld --with-gnu-ld --with-as=/usr/bin/as --with-gnu-as
--enable-versi
on-specific-runtime-libs --with-system-zlib --without-included-gettext
--enable-bootstrap --enable-serial-configure --host=x86_64-pc-linux-gnu
--build=x86_64-pc-linux
-gnu

## - ##
## Platform. ##
## - ##

hostname = jvdspc
uname -m = x86_64
uname -r = 3.4.4-jvd+
uname -s = Linux
uname -v = #4 SMP Fri Jul 6 20:19:44 GMT 2012

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = x86_64
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: .
PATH: /bin
PATH: /usr/bin
PATH: /sbin
PATH: /usr/sbin


## --- ##
## Core tests. ##
## --- ##

configure:2237: checking build system type
configure:2251: result: x86_64-pc-linux-gnu
/quote

And I ran :

$ make -j2 bootstrap 21 | tee make.bootstrap.log

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

--- Comment #7 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-08-05 
12:21:10 UTC ---
Thanks for your response !
I think the cc1 process is somehow operating in slow motion,
even though I've pinned the CPU frequency to 1.8 GHz (it 
will crash if I don't reduce it soon - so this is not a slow
machine issue!) .

cc1 is writing about one line every 2 minutes to its assembler output file:
...
12:10:14 write(3, 3\n.L2088:\n\tmovq\t(%rbx), %rdi\n\tca..., 4096) = 4096
...
12:12:24 write(3, %edi\n\tmovq\t32(%rbx), %rbx\n\tcall\t..., 4096) = 4096
...

I think this is because it has to hold a huge chunk of contiguous 
memory :

$ ps -o 'vsz rss %mem' -p 3863
   VSZ   RSS %MEM
258444 125752  7.3

So it is trying to hold @1.25GB of contiguous RAM. (my machine has 2GB).

These memory requirements are solely due to the size of the .c file (1.8MB) .

Why can't they be reduced somewhat?

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

--- Comment #11 from Jason Vas Dias jason.vas.dias at gmail dot com 
2012-08-05 13:16:03 UTC ---


Thanks for the responses - I will try again with
'--enable-checking=release'.
But, I still don't think this bug is a non-issue - here's why:

RE: wbrana 2012-08-05 12:27:52 UTC
 2 GB RAM isn't enough.
 It isn't good idea to use x86_64 with 2 GB RAM.

Sorry, but gcc shouldn't be enforcing this on us - I thought it was
supposed to be capable of being an embedded systems compiler - are
you saying gcc cannot be compiled or run on any embedded system with
less than 2GB RAM ?  Surely not!


RE:
[reply] [-] Comment 9 Steven Bosscher 2012-08-05 12:33:56 UTC

Thanks for your response Steven!

 (In reply to comment #7)
 cc1 is writing about one line every 2 minutes to its assembler output
file:
 If you've really configured with --enable-stage1-checking=all, you've
enabled
..
 All forms of --enable-checking=all are really for debugging purposes only
...
 Can you please try without -enable-stage1-checking=all?

Fair enough, OK, I will.  

But I'd still like some kind of answer - why MUST insn-emit.c be so large ?
The answer compiling lots of small .c files is slower that one large one
is demonstrably false on my machine and on many other machines with not
much
RAM I suspect, and must be qualified with if you have a platform with X
RAM
and X CPU speed . 
If the gcc build scripts detect they are running on a platform with less
than
4GB of RAM, say, they could decide to split insn-emit.c .
Why is it so inconceivable that they might in future do something like this
?

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

--- Comment #13 from Jason Vas Dias jason.vas.dias at gmail dot com 
2012-08-05 13:43:21 UTC ---
RE:  Steven Bosscher 2012-08-05 12:37:28 UTC \
(In reply to comment #7)
 These memory requirements are solely due to the size of the .c file (1.8MB) .

 This is indeed excessive, we'll have to look into this. If you have
 preprocessed source and the compilation flags, can you please attach it? Or if
 you feel like helping out today, try to do a (non-bootstrap) build with
 --enable-gather-statistics, compile the file, and report back the resulting
 time and memory reports.

compilation flags given in previous comment:
 $  tr '\0' ' '  /proc/3863/cmdline
/mnt/sda3/gcc/./prev-gcc/cc1 -quiet -I . -I . -I /usr/build2/gcc/gcc-4.7.1/gcc
-I /usr/build2/gcc/gcc-4.7.1/gcc/. -I /usr/build2/gcc/gcc-4.7.1/gcc/../include
-I /usr/build2/gcc/gcc-4.7.1/gcc/../libcpp/include -I
/usr/build2/gcc/gcc-4.7.1/gcc/../libdecnumber -I
/usr/build2/gcc/gcc-4.7.1/gcc/../libdecnumber/bid -I ../libdecnumber -iprefix
/mnt/sda3/gcc/prev-gcc/../lib64/gcc/x86_64-pc-linux-gnu/4.7.1/ -isystem
/mnt/sda3/gcc/./prev-gcc/include -isystem
/mnt/sda3/gcc/./prev-gcc/include-fixed -D IN_GCC -D HAVE_CONFIG_H -isystem
/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include
insn-emit.c -quiet -dumpbase insn-emit.c -mtune=k8 -march=x86-64 -auxbase-strip
insn-emit.o -g -gtoggle -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat -o /tmp/ccgsb5Pk.s 

Sorry I for the word-wrap in your website form - in my day, bugzilla / firefox
didn't do that.

Adding pre-processed source 'xz --compress -9' insn-emit.i.xz file of the
PRE-PROCESSED C source - you mean the output of the previous command with '-o
/tmp/ccgsb5Pk.s' replaced by '-E -o insn-emit.i' ?

So the config options I'll now use (for my initial C-only build,  which 
enables ONLY the C language, sufficient ONLY to pass the C-only test suite,
and to recompile binutils, gmp, mpfr, mpc, and ppl + cloog for C only, making
sure they pass their test suites, before rebuilding glibc and then GCC + G++
with '--enable-languages=all' and the new glibc, binutils, gmp, mpfr, mpc +
ppl/cloog built with the C-only compiler.  (this is the way I've always done
it)
:
$ /usr/build2/gcc/gcc-4.7.1/configure --prefix=/usr --libdir=/usr/lib64 \
--enable-multilib --with-cpu-32=i686 --with-cpu-64=k8 \
--enable-version-specific-runtime-libs \
--enable-languages=c \
--enable-bootstrap \
--enable-stage1-languages=c \
--disable-build-with-cxx  --disable-build-poststage1-with-cxx \
--enable-checking=release --enable-stage1-checking=release \
--enable-gather-statistics \
--enable-targets=all \
--enable-threads=posix --enable-tls \
--enable-lto --enable-shared \
--with-build-time-tools=/usr/bin \
--with-ld=/usr/bin/ld --with-gnu-ld \
--with-as=/usr/bin/as --with-gnu-as  \
--with-system-zlib --without-included-gettext 
--enable-serial-configure \
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu

??

I'll post the statistics files gathered after the build - where are they ?

If any suggested changes, please advise soon. 

Thanks  Regards,
Jason Vas Dias

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

--- Comment #14 from Jason Vas Dias jason.vas.dias at gmail dot com 
2012-08-05 13:46:26 UTC ---
$ time /mnt/sda3/gcc/./prev-gcc/xgcc -B/mnt/sda3/gcc/./prev-gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/bin/
-B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include
-isystem /usr/x86_64-pc-linux-gnu/sys-include-g -O2 -gtoggle -DIN_GCC   -W
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition
-Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I/usr/build2/gcc/gcc-4.7.1/gcc
-I/usr/build2/gcc/gcc-4.7.1/gcc/. -I/usr/build2/gcc/gcc-4.7.1/gcc/../include
-I/usr/build2/gcc/gcc-4.7.1/gcc/../libcpp/include 
-I/usr/build2/gcc/gcc-4.7.1/gcc/../libdecnumber
-I/usr/build2/gcc/gcc-4.7.1/gcc/../libdecnumber/bid -I../libdecnumber   
insn-emit.c -E  insn-emit.c  insn-emit.i

real0m6.243s
user0m5.862s
sys 0m0.284s


now attaching insn-emit.i.xz

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

--- Comment #15 from Jason Vas Dias jason.vas.dias at gmail dot com 
2012-08-05 13:51:27 UTC ---
Created attachment 27939
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27939
pre-processed C from previous comment command

$ xz --uncompress  insn-emit.i.xz  insn-emit.i 
# pre-processed C from previous comment command

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

--- Comment #20 from Jason Vas Dias jason.vas.dias at gmail dot com 
2012-08-05 18:10:24 UTC ---
RE:  --disable-bootstrap if you're doing --enable-gather-statistics

but for me this defeats the whole purpose of building a C-only 
bootstrap compiler.

I see no point in proceeding to build C++ , Java, Obj-C et al
until binutils, glibc, gmp, mpfr, mpc, ppl/cloog, gettext, zlib
et al have been re-built and tested using the pure-c compiler ;
to me, the first thing I'd do with a default 'configure  make'
GCC with --enable-languages=all is re-compile binutils + glibc
et al and then repeat the GCC build - so why use --enable-languages=all
until GCC's dependencies have been rebuilt using the new GCC ?

Anyway, my laptop is in the cooler now, producing around 1 PAGE of assembler 
every two minutes (sorry, strace was truncating) , it has produced around 2MB
of assembler so far, so I might as well let it continue for the next week
or so until it finishes ...

thanks for all the responses explaining why this takes so long with
--enable-checking=all - I'll remember not to use this again.

Couldn't there be a new enable all checks except garbage collection checks
option ?

Thanks  Regards, Jason

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

--- Comment #22 from Jason Vas Dias jason.vas.dias at gmail dot com 
2012-08-05 19:48:45 UTC ---
RE:
 If you want a C-only compiler then you should just configure with 
 --enable-languages=c only

of course, I tried that first, but that is no longer possible with gcc-4.7.1+ .

My post to gcc-bugs about this issue was bounced:
Jonathan Wakely jwakely@gmail.com

Jul 8

Reply
to me, gcc-bugs
Hi,

The gcc-bugs mailing list is for automated emails from our Bugzilla
database.  Your question is not about a bug, so would be more
appropriate on the gcc-help mailing list.

The answer to your question is that GCC itself is now built using a
C++ compiler, so it needs to build the C++ compiler to build itself,
see http://gcc.gnu.org/install/configure.html

--enable-build-poststage1-with-cxx
When bootstrapping, build stages 2 and 3 of GCC using a C++
compiler rather than a C compiler. Stage 1 is still built with a C
compiler. This is enabled by default and may be disabled using
--disable-build-poststage1-with-cxx.


Re: gcc-4.7.1 build system question : why is make bootstrap with configure
option '--enable-languages=c' building the C++ compiler ?
GCC
x
Jason Vas Dias

Jul 8

Reply
to gcc-bugs
OK, so I'm reconfiguring with :
--enable-languages=c --disable-build-with-cxx
--disable-build-poststage1-with-cxx --enable-stage1-checking=all
--enable-stage1-languages=c
but why should I have to ? Shouldn't --enable-languages=c be enough
to disable building the C++ compiler and libstdc++ ?
Thanks  Regards,
 Jason

On Sun, Jul 8, 2012 at 4:06 PM, Jason Vas Dias jason.vas.d...@gmail.com
wrote:
 Hi -  I've been regularly building gcc for nearly two decades, and now
 attempting to build a bootstrap
 C only gcc-4.7.1 sufficient only to build binutils (my initial first
 step is always to rebuild binutils
 with the bootstrap C only compiler before doing a complete make
 with --enable-languages=all -
 a shame that support for configuring and building binutils along with
 gcc has been withdrawn ,
 so now I attempt to rebuild binutils separately with the C only
 bootstrap compiler) .

 Now this doesn't work - building C-only ( --enable-languages=c )
 bootstrap fails building C++ :

 /mnt/sda3/gcc/./prev-gcc/g++ -B/mnt/sda3/gcc/./prev-gcc/
 -B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++
 -B/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
 -B/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
 -I/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
 -I/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
 -I/usr/build2/gcc/gcc-4.7.1/libstdc++-v3/libsupc++
 -L/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
 -L/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
  -g -O2 -gtoggle -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall
 -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
 -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
  -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o cc1 c-lang.o
 c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o
 c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o
 c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
 c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o
 c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o
 c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o
 c-family/c-semantics.o c-family/c-ada-spec.o i386-c.o default-c.o \
   cc1-checksum.o main.o  libbackend.a libcommon-target.a libcommon.a
 ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
 ../libcpp/libcpp.a   ../libiberty/libiberty.a
 ../libdecnumber/libdecnumber.a  -lcloog -lppl_c -lppl -lpwl -lgmpxx
 -lmpc -lmpfr -lgmp -rdynamic -ldl  -lz
 lto/lto.o: In function `lto_ft_typed(tree_node*)':
 lto.c:(.text+0x326): undefined reference to `tree_code_type'
 lto/lto.o: In function `lto_ft_common(tree_node*)':
 lto.c:(.text+0x38b): undefined reference to `tree_code_type'
 lto/lto.o: In function `lto_ft_decl_common(tree_node*)':
 lto.c:(.text+0x3fb): undefined reference to `tree_code_type'
 lto.c:(.text+0x432): undefined reference to `tree_code_type'
 lto.c:(.text+0x469): undefined reference to `tree_code_type'
 lto/lto.o:lto.c:(.text+0x49e): more undefined references to
 `tree_code_type' follow

 Boy, does it really mean it when it says more undefined references to
 `tree_code_type' follow :

  $ grep 'undefined reference' make.bootstrap-cntnd.log  | wc -l
 18127

 My config.log command :


  generated by GNU Autoconf 2.64.  Invocation command line was

   $ /usr/build2/gcc/gcc-4.7.1/configure --prefix=/usr
 --libdir=/usr/lib64 --with-cpu-32=i686 --with-cpu-64=k8
 --enable-languages=c --enable-targets=all --enable-multi
 lib --enable-threads=posix --enable-tls --enable-lto --enable-shared
 --enable-checking=release --with-build-time-tools=/usr/bin
 --with-ld=/usr/bin/ld --with-gnu-ld

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

--- Comment #23 from Jason Vas Dias jason.vas.dias at gmail dot com 
2012-08-05 19:51:56 UTC ---
Yes, I was wondering how long it would take to close this bug as INVALID, 
which seems to be the standard response to uncomfortable bug reports these
days.

It turned out to be less time than gcc is taking to generate the assembler for
insn-emit.c :-) !

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

--- Comment #24 from Jason Vas Dias jason.vas.dias at gmail dot com 
2012-08-05 20:10:36 UTC ---
$ ps -lp 3863
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY  TIME CMD
0 R 0  3863  3862 99  80   0 - 64611 -  pts/51-05:55:03 cc1

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

--- Comment #26 from Jason Vas Dias jason.vas.dias at gmail dot com 
2012-08-05 20:57:59 UTC ---
Well, when I read on the documentation page 

http://gcc.gnu.org/install/configure.html


--enable-build-with-cxx
Build GCC using a C++ compiler rather than a C compiler. This is an 
experimental option which may become the default in a later release.


--enable-bootstrap
In special cases, you may want to perform a 3-stage build even if the
target and host triplets are different. This is possible when the host can run
code compiled for the target (e.g. host is i686-linux, target is i486-linux).
Starting from GCC 4.2, to do this you have to configure explicitly with
--enable-bootstrap.


--enable-checking
--enable-checking=list
When you specify this option, the compiler is built to perform internal
consistency checks of the requested complexity. This does not change the
generated code, but adds error checking within the compiler. This will slow
down the compiler and may only work properly if you are building the compiler
with GCC. This is `yes' by default when building from SVN or snapshots, but
`release' for releases. The default for building the stage1 compiler is `yes'.
More control over the checks may be had by specifying list. The categories of
checks available are `yes' (most common checks
`assert,misc,tree,gc,rtlflag,runtime'), `no' (no checks at all), `all' (all but
`valgrind'), `release' (cheapest checks `assert,runtime') or `none' (same as
`no'). Individual checks can be enabled with these flags `assert', `df',
`fold', `gc', `gcac' `misc', `rtl', `rtlflag', `runtime', `tree', and
`valgrind'.

The `valgrind' check requires the external valgrind simulator, available
from http://valgrind.org/. The `df', `rtl', `gcac' and `valgrind' checks are
very expensive. To disable all checking, `--disable-checking' or
`--enable-checking=none' must be explicitly requested. Disabling assertions
will make the compiler and runtime slightly faster but increase the risk of
undetected internal errors causing wrong code to be generated.






Where does it say I cannot build C and not C++ without specifying 

--enable-languages=c --disable-build-with-cxx 
--disable-build-poststage1-with-cxx --enable-stage1-languages=c

which is in fact the case ?

Where does it say that users should never use --enable-checking=all 
with --enable-bootstrap ?

And what has any of this to do with the simple question posed in the title
of this bug report : why can't insn-emit.c be split ?

[Bug lto/49424] New: ICE in lhd_set_decl_assembler_name at langhooks.c:158 with '-flto'

[jason.vas.dias at gmail dot com]

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

   Summary: ICE in lhd_set_decl_assembler_name at langhooks.c:158
with '-flto'
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jason.vas.d...@gmail.com


When building qt-4.7.1 (from git:  git://anongit.kde.org/qt-kde.git )
with GCC 4.6.0, built unmodified source in gcc-4.6.0.tar.bz2, on a
Linux x86_64 platform ( binutils: 2.21.51.20110407 glibc:2.13 kernel: 2.38.8.8) 
g++ suffers an internal compiler error when compiling Qt's 
qt-kde/src/3rdparty/javascriptcore/JavaScriptCore/API/JSStringRef.cpp :

...
 /usr/bin/g++ -c -march=x86-64 -mtune=k8 -O2 -g -pipe -flto -Wall -Wreturn-type
-fno-strict-aliasing -Wcast-align -Wchar-subscripts -Wformat-security
-Wreturn-type -Wno-unused-parameter -Wno-sign-compare -Wno-switch
-Wno-switch-enum -Wundef -Wmissing-noreturn -Winit-self -fno-stack-protector -g
-fvisibility=hidden -fvisibility-inlines-hidden -D_REENTRANT -fPIC ...
src/3rdparty/javascriptcore/JavaScriptCore/API/JSStringRef.cpp
/usr/x/kde/4.1/KDE/qt-kde/src/3rdparty/javascriptcore/JavaScriptCore/API/JSStringRef.cpp:
In function 'JSStringGetUTF8CString':
/usr/x/kde/4.1/KDE/qt-kde/src/3rdparty/javascriptcore/JavaScriptCore/API/JSStringRef.cpp:112:1:
internal compiler error: in lhd_set_decl_assembler_name, at langhooks.c:158
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

When I remove the '-flto' option, this ICE does not occur and the compilation
succeeds .

Line 112 of that source file is the end of file :

bool JSStringIsEqualToUTF8CString(JSStringRef a, const char* b)
{
JSStringRef bBuf = JSStringCreateWithUTF8CString(b);
bool result = JSStringIsEqual(a, bBuf);
JSStringRelease(bBuf);

return result;
} // this is line 112
// FILE ENDS

If you need any more info here, let me know.
Thanks  Regards, Jason

[Bug c/49077] New: gcjwebplugin.cc doesn't compile against latest xulrunner 2.0b13 sdk

[jason.vas.dias at gmail dot com]

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

   Summary: gcjwebplugin.cc doesn't compile against latest
xulrunner 2.0b13 sdk
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jason.vas.d...@gmail.com


When attempting to build gcc-4.6.0 with libjava, AWT peers, and browser plugin,
 gcjwebplugin.cc does not compile because these headers are missing from
 xulrunner-2.0b13 (the latest stable mozilla build, but checked out out from
HG):
   nsIPluginInstancePeer.h
   nsIPluginTagInfo2.h
 These exist only in my previous xulrunner directory :
  /usr/include/xulrunner-1.9.0.12pre/unstable/nsIPluginInstancePeer.h
 I don't think the gappletviewer should be choosing to use the 'unstable' API !
Since I've removed the old versions of xulrunner, I'll have to port
gappletviewer
to use the new xulrunner API, and will post patch here when done, unless
someone
has already done it ? If so, please post patch or tell me where I can find one.
Thanks  Regards,
Jason

[Bug java/49077] gcjwebplugin.cc doesn't compile against latest xulrunner 2.0b13 sdk

[jason.vas.dias at gmail dot com]

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

--- Comment #1 from Jason Vas Dias jason.vas.dias at gmail dot com 2011-05-20 
10:07:20 UTC ---
my config:

  $ /usr/build2/gcc/gcc-4.6.0/configure --prefix=/usr --libdir=/usr/lib64\
--with-cpu-32=i686 --with-cpu-64=k8 --enable-languages=all \
--enable-targets=all --enable-multilib --enable-threads=posix --enable-tls\
--enable-lto --enable-shared --enable-checking=release \
--with-build-time-tools=/usr/bin --with-ld=/usr/bin/ld --with-gnu-ld \
--with-as=/usr/bin/as --with-gnu-as --enable-__cxa_atexit \
--disable-libunwind-exceptions --with-gxx-include-dir=/usr/include/c++\
--enable-version-specific-runtime-libs --with-system-zlib --disable-werror\
--enable-classpath --with-x --enable-gtk-cairo --enable-java-awt=gtk,xlib\
--withjava-home=/usr/java --with-jvm-root-dir=/usr/java/jvm \
--with-jvm-jar-dir=/usr/java/jvm_exports --enable-browser-plugin\ 
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu \
--without-included-gettext --enable-serial-configure

with /usr/build2/gcc/gcc-4.6.0 containing GCC source identical to that shipped
in gcc-4.6.0.tar.bz2 except for this patch which I use for my distro defaults :

diff -up gcc/config/i386/linux.h~ gcc/config/i386/linux.h
--- gcc/config/i386/linux.h~2011-01-14 18:45:06.0 +
+++ gcc/config/i386/linux.h 2011-04-05 22:17:10.0 +0100
@@ -92,7 +92,7 @@ along with GCC; see the file COPYING3.

 /* These macros may be overridden in k*bsd-gnu.h and i386/k*bsd-gnu.h. */
 #define LINK_EMULATION elf_i386
-#define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.2
+#define GLIBC_DYNAMIC_LINKER /lib32/ld-linux.so.2

 #undef  ASM_SPEC
 #define ASM_SPEC \
diff -up gcc/config/i386/linux64.h~ gcc/config/i386/linux64.h
--- gcc/config/i386/linux64.h~  2011-03-02 22:35:36.0 +
+++ gcc/config/i386/linux64.h   2011-04-05 22:17:33.0 +0100
@@ -62,7 +62,7 @@ see the files COPYING3 and COPYING.RUNTI
When the -shared link option is used a final link is not being
done.  */

-#define GLIBC_DYNAMIC_LINKER32 /lib/ld-linux.so.2
+#define GLIBC_DYNAMIC_LINKER32 /lib32/ld-linux.so.2
 #define GLIBC_DYNAMIC_LINKER64 /lib64/ld-linux-x86-64.so.2

 #if TARGET_64BIT_DEFAULT

[Bug java/49077] gcjwebplugin.cc doesn't compile against latest xulrunner 2.0b13 sdk

[jason.vas.dias at gmail dot com]

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

--- Comment #2 from Jason Vas Dias jason.vas.dias at gmail dot com 2011-05-20 
10:17:10 UTC ---
See https://developer.mozilla.org/en/firefox_3.6_for_developers :

Interfaces merged

The following interfaces have been combined together:

nsIPluginTagInfo2 has been merged into nsIPluginTagInfo.
nsIPluginInstanceInternal, nsIPPluginInstancePeer, nsIPluginInstancePeer1,
nsIPluginInstancePeer2, and nsIPluginInstancePeer3 have all been merged into
nsIPluginInstance.
nsIWindowlessPlugInstPeer has been merged into nsIPluginInstance.
nsIPluginManager and nsIPluginManager2 have been merged into nsIPluginHost.

[Bug java/49077] gcjwebplugin.cc doesn't compile against latest xulrunner 2.0 (firefox-3.6) sdk

[jason.vas.dias at gmail dot com]

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

--- Comment #4 from Jason Vas Dias jason.vas.dias at gmail dot com 2011-05-20 
11:19:25 UTC ---
Created attachment 24298
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24298
patch to gcjwebplugin.cc to compile against xulrunner-2.0

First attempt that compiles

[Bug java/49077] gcjwebplugin.cc doesn't compile against latest xulrunner 2.0 (firefox-3.6) sdk

[jason.vas.dias at gmail dot com]

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

--- Comment #5 from Jason Vas Dias jason.vas.dias at gmail dot com 2011-05-20 
12:56:44 UTC ---
(In reply to comment #3)
 gcjwebplugin is dead, it should have been removed, but nobody has done that.
 Just don't enable it in configure.

Well then what replaces the Firefox plugin functionality - ie.
what happens when I include '--enable-browser-plugin' in configure args ?
A JVM environment and Java SDK is hardly worthy of the name unless it
can be used to run java applets embedded in webpages from the system
browser - how else is one meant to do this using only GCJ components ?

This problem appears to be the ONLY reason gcjwebplugin fails to build ;
are you sure rumors of its demise are not premature ?

[Bug java/49077] gcjwebplugin.cc doesn't compile against latest xulrunner 2.0 (firefox-3.6) sdk

[jason.vas.dias at gmail dot com]

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

Jason Vas Dias jason.vas.dias at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WONTFIX |

--- Comment #8 from Jason Vas Dias jason.vas.dias at gmail dot com 2011-05-20 
18:47:00 UTC ---
(In reply to comment #7)
 this currently supports only IcedTea as the JDK.  I'd like to see it 
 eventually
 support gcj too, but it would need work on both sides for this to happen.
 
 OpenJDK itself (as provided by Oracle) doesn't have applet support, 
 hence the need for the IcedTea-Web project to provide a Free implementation.

IMHO, also hence the need to maintain gappletbrowser + gcjwebplugin in the
interim .  Why must I install yet another whole subsystem just to get 
a java applet displaying in my browser with GCJ + libjava, when it
used not to require one ?  
If gappletbrowser + gcjwebplugin is so thoroughly deprecated, then
gcc's configure should refuse to accept the '--enable-browser-plugin'
option, or, if it does accept it, something like the patch attached
to this bug must be applied to enable the browser plugin to compile.

 
 BTW, regarding the subject, isn't xulrunner 2.0 firefox 4.0, not 3.6?


Yes, I am building against firefox-4.0 / xulrunner-2.0 but the same problem 
will occur if user try to '--enable-browser-plugin' against firefox-3.6 SDK,
because as Comment #2 shows, they removed the nsIPluginTagInfo2 interface
in firefux-3.6 .

[Bug other/49055] New: 4.6.0 libjava 64-bit + 32-bit multilib compile fails due missing -isystem and -nostdinc++ with $OBJDIR != $topsrcdir build

[jason.vas.dias at gmail dot com]

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

   Summary: 4.6.0 libjava 64-bit + 32-bit multilib compile fails
due missing -isystem and -nostdinc++ with $OBJDIR !=
$topsrcdir  build
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jason.vas.d...@gmail.com


Hi -

Thanks for the great new gcc-4.6.0, which built and passed C + C++ tests OK ;
especially thanks for the new  --enable-version-specific-runtime-libs
option, which I believe a bug I raised a while ago may have contributed
to inspiring - but I ended up with these libs installed :


$ find /usr/lib64/gcc/x86_64-pc-linux-gnu/{4.6.0,lib{32,64}} \
  -name 'lib*.so*' -a -type f
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/libobjc.so.3.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/libgfortran.so.3.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/libquadmath.so.0.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/libssp.so.0.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/libmudflapth.so.0.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/libmudflap.so.0.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/libstdc++.so.6.0.15-gdb.py
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/libstdc++.so.6.0.15
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libobjc.so.3.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libgfortran.so.3.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libquadmath.so.0.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libssp.so.0.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libmudflapth.so.0.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libmudflap.so.0.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libstdc++.so.6.0.15-gdb.py
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libstdc++.so.6.0.15
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libgcjgc.so.1.0.2
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libffi.so.4.0.1
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libgomp.so.1.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/lib32/libgcc_s.so.1
/usr/lib64/gcc/x86_64-pc-linux-gnu/lib64/libgcc_s.so.1


And 'make install' still created links to the shared libraries in $LIBDIR !

Why the special treatment for libgcc_s.so.1 ?

I'd suggest :
1. Ensure NO shared libraries or links are shipped direct into $LIBDIR if
--enable-version-specific-runtime-libs given to configure ;
and either :
  o put libgcc_s.so.1 in
${DESTDIR}/${LIBDIR}/gcc/${GCC_PLATFORM}/${GCC_VERSION}{32/,}
or :
  o put ${DESTDIR}/${LIBDIR}/gcc/${GCC_PLATFORM}/${GCC_VERSION}{32/,}/lib*.so*
into /usr/lib64/gcc/x86_64-pc-linux-gnu/lib{32,64}/ 
NOT both .

Here's my gcc build details :

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /usr/build2/gcc/gcc-4.6.0/configure --prefix=/usr
--libdir=/usr/lib64 --with-cpu-32=i686 --with-cpu-64=k8 --enable-languages=all
--enable-targets=all --enable-multilib --enable-threads=posix --enable-tls
--enable-lto --enable-shared --enable-checking=release
--with-build-time-tools=/usr/bin --with-ld=/usr/bin/ld --with-gnu-ld
--with-as=/usr/bin/as --with-gnu-as --enable-__cxa_atexit
--disable-libunwind-exceptions --with-gxx-include-dir=/usr/include/c++
--enable-version-specific-runtime-libs --with-system-zlib --disable-werror
--enable-classpath --with-x --enable-gtk-cairo --enable-java-awt=gtk,xlib
--with-java-home=/usr/java --with-jvm-root-dir=/usr/java/jvm
--with-jvm-jar-dir=/usr/java/jvm_exports --enable-browser-plugin
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu
--without-included-gettext --enable-serial-configure
Thread model: posix
gcc version 4.6.0 (GCC)


And also, though C, C++, objc, and gfortran and other gcj components build OK,
libjava fails because the libjava configure run as part of main gcc 'make '
does NOT add these to CPPFLAGS ( where my $OBJDIR=/mnt/sda3/gcc and topsrcdir=
 /usr/build2/gcc/gcc-4.6.0 ) :

-isystem /mnt/sda3/gcc/stage1-gcc/include -isystem
/mnt/sda3/gcc/stage1-gcc/include-fixed
-I/mnt/sda3/gcc/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/usr/build2/gcc/gcc-4.6.0/libstdc++-v3/libsupc++
-I/mnt/sda3/gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/mnt/sda3/gcc/x86_64-pc-linux-gnu/32/

I had to edit the make files to add the above cpp flags to get libjava to
build.