Gcc bugzilla is down

2018-04-01 Thread Thomas König

Hi,

it seems that gcc bugzilla is currently down, error message is:

Software error:

Can't connect to the database.
Error: Can't connect to local MySQL server through socket 
'/var/lib/mysql/mysql.sock' (2)

  Is your database installed and up and running?
  Do you have the correct username and password selected in localconfig?

If somebody could bring it up again, it would certainly help my plans to
do some gcc hacking over the Easter weekdend :-)

Regards

Thomas


Successful bootstrap and install of gcc (GCC) 7.3.0 on sparc64-unknown-linux-gnu

2018-04-01 Thread Aaro Koskinen
Hi,

Here's a report of a successful build and install of GCC:

$ gcc-7.3.0/config.guess
sparc64-unknown-linux-gnu

$ newcompiler/bin/gcc -v
Using built-in specs.
COLLECT_GCC=newcompiler/bin/gcc
COLLECT_LTO_WRAPPER=/home/aaro/gcctest/newcompiler/libexec/gcc/sparc-unknown-linux-gnu/7.3.0/lto-wrapper
Target: sparc-unknown-linux-gnu
Configured with: ../gcc-7.3.0/configure --with-cpu=ultrasparc 
--enable-targets=all --disable-libsanitizer --disable-nls 
--prefix=/home/aaro/gcctest/newcompiler --enable-languages=c,c++ 
--host=sparc-unknown-linux-gnu --build=sparc-unknown-linux-gnu 
--target=sparc-unknown-linux-gnu --with-system-zlib --with-sysroot=/
Thread model: posix
gcc version 7.3.0 (GCC) 

-- Build environment --

host: sun-ultra-10
distro:   los.git rootfs=e263b native=e263b
kernel:   Linux 4.16.0-rc6-ultra-los_e263b
binutils: GNU binutils 2.30
make: GNU Make 4.2.1
libc: GNU C Library (GNU libc) stable release version 2.27.
zlib: 1.2.11
mpfr: 4.0.1
gmp:  60102

-- Time consumed --

configure:  real0m 26.04s
user0m 19.37s
sys 0m 3.79s

bootstrap:  real44h 48m 35s
user43h 51m 31s
sys 41m 24.99s

install:real2m 58.62s
user1m 6.04s
sys 0m 37.68s

-- Hardware details ---

MemTotal: 507728 kB

cpu : TI UltraSparc IIi (Sabre)
fpu : UltraSparc IIi integrated FPU
pmu : ultra12
prom: OBP 3.31.0 2001/07/25 20:36
type: sun4u
ncpus probed: 1
ncpus active: 1
D$ parity tl1   : 0
I$ parity tl1   : 0
Cpu0ClkTck  : 1a39de00
cpucaps : flush,stbar,swap,muldiv,v9,mul32,div32,v8plus,vis
MMU Type: Spitfire
MMU PGSZs   : 8K,64K,512K,4MB

A.


Re: Gcc bugzilla is down

2018-04-01 Thread Eric Gallager
Confirming, I got the same error message at around 7:29 AM Eastern
Daylight Time. Please fix!

Eric

On 4/1/18, Thomas König  wrote:
> Hi,
>
> it seems that gcc bugzilla is currently down, error message is:
>
> Software error:
>
> Can't connect to the database.
> Error: Can't connect to local MySQL server through socket
> '/var/lib/mysql/mysql.sock' (2)
>Is your database installed and up and running?
>Do you have the correct username and password selected in localconfig?
>
> If somebody could bring it up again, it would certainly help my plans to
> do some gcc hacking over the Easter weekdend :-)
>
> Regards
>
>   Thomas
>


why C++ cannot alias an inline function, C can ?

2018-04-01 Thread Jason Vas Dias
Good day -

I'm trying to understand why this code compiles fine
in  'gcc   -std=gnu11' mode, but not in
 'g++  -std=g++11' mode
(so far tried with gcc/g++ 5.4.0 , 7.3.1 on x86_64 linux) :

'
 static inline __attribute__((always_inline))
 void foo(void){}

 static inline __attribute__((always_inline,alias("foo")))
 void bar(void);

 static
 void f(void) { foo(); }
 // must have a usage to generate any code
 '

In C mode , no problems - I can invoke foo() or bar() to
reference the same inline, and it is always inlined .

In C++ however, it does not compile :

  $ g++ -g -std=gnu++11 -x c++ -c t.c
t.c:5:8: error: 'void bar()' aliased to undefined symbol 'foo'
   void bar(void);
^

Even though, if I compile the object with the declaration
of bar() commented out , I can see C++ is not mangling
the name "foo" :

$ objdump -g t.o

t.o: file format elf64-x86-64

Contents of the .debug_info section:

  Compilation Unit @ offset 0x0:
   Length:0x4d (32-bit)
   Version:   4
   Abbrev Offset: 0x0
   Pointer Size:  8
 <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
   DW_AT_producer: (indirect string, offset: 0x0): GNU
C++11 5.4.0 -mtune=haswell -march=x86-64 -g -std=gnu++11
<10>   DW_AT_language: 4(C++)
<11>   DW_AT_name: t.c
<15>   DW_AT_comp_dir: (indirect string, offset: 0x43): /tmp
<19>   DW_AT_low_pc  : 0x0
<21>   DW_AT_high_pc : 0x7
<29>   DW_AT_stmt_list   : 0x0
 <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
<2e>   DW_AT_name: foo
<32>   DW_AT_decl_file   : 1
<33>   DW_AT_decl_line   : 2
<34>   DW_AT_inline  : 3(declared as inline and inlined)
 <1><35>: Abbrev Number: 3 (DW_TAG_subprogram)
<36>   DW_AT_external: 1
<36>   DW_AT_name: f
<38>   DW_AT_decl_file   : 1
<39>   DW_AT_decl_line   : 10
<3a>   DW_AT_linkage_name: (indirect string, offset: 0x3d): _Z1fv
<3e>   DW_AT_low_pc  : 0x0
<46>   DW_AT_high_pc : 0x7
<4e>   DW_AT_frame_base  : 1 byte block: 9c (DW_OP_call_frame_cfa)
<50>   DW_AT_GNU_all_call_sites: 1
 <1><50>: Abbrev Number: 0

So there is a symbol "foo" declared, even though it is only a debug symbol .

Why does C++ not let me alias it ?  There appears to be no mangled name
for it .

And even worse, the obvious workaround does not work:

'
static inline __attribute__((always_inline))
void foo(void) {}

//  static inline __attribute__((always_inline, alias("foo")))
//  void bar(void);

static inline __attribute__((always_inline))
void (&bar)(void) = foo;

   void f(void)
   { bar();
   }
'
Fails to compile with:

t.c:8:19: error: 'bar' declared as an 'inline' variable
   void (&bar)(void) = foo;


So one has to do just
static
void (&bar) ( void ) = foo;

So now foo() has lost its inline-ness:

$ nm -C t.o
0007 T f()
 r bar
 t foo()

ie. the compiler did not warn that foo
has been made into an ordinary symbol:

'
$ cat t.c
static inline __attribute__((always_inline))
void foo(void) {}
static
void (&bar)(void) = foo;
void f(void){ bar();}
$ g++ -std=gnu++11 -x c++ -Wall -Wextra -c t.c
$
 '
I think g++ should have warned that it is not treating
an always inline function as inline here !

This problem is causing me grief in more real-world scenarios -
any advice on how to create an alias that is inline-able in C++
would be much appreciated.

Thanks & Best Regards,
Jason


Re: why C++ cannot alias an inline function, C can ?

2018-04-01 Thread Max Filippov
On Sun, Apr 1, 2018 at 4:34 AM, Jason Vas Dias  wrote:
> In C++ however, it does not compile :
>
>   $ g++ -g -std=gnu++11 -x c++ -c t.c
> t.c:5:8: error: 'void bar()' aliased to undefined symbol 'foo'
>void bar(void);
> ^
>
> Even though, if I compile the object with the declaration
> of bar() commented out , I can see C++ is not mangling
> the name "foo" :

gcc manual says the follwing about the alias attribute:
 "In C++, the mangled name for the target must be used."

so with the following modification your example compiles:

 static inline __attribute__((always_inline,alias("_ZL3foov")))
 void bar(void);

-- 
Thanks.
-- Max


Re: why C++ cannot alias an inline function, C can ?

2018-04-01 Thread Jason Vas Dias
On 01/04/2018, Max Filippov  wrote:
> On Sun, Apr 1, 2018 at 4:34 AM, Jason Vas Dias 
> wrote:
>> In C++ however, it does not compile :
>>
>>   $ g++ -g -std=gnu++11 -x c++ -c t.c
>> t.c:5:8: error: 'void bar()' aliased to undefined symbol 'foo'
>>void bar(void);
>> ^
>>
>> Even though, if I compile the object with the declaration
>> of bar() commented out , I can see C++ is not mangling
>> the name "foo" :
>


> gcc manual says the follwing about the alias attribute:
>  "In C++, the mangled name for the target must be used."
>
> so with the following modification your example compiles:
>
>  static inline __attribute__((always_inline,alias("_ZL3foov")))
>  void bar(void);
>
> --
> Thanks.
> -- Max
>


Aha!  But how to determine the mangled name beforehand ?

Even if I compile the object without the alias, then inspect
the object with objdump, there is no mangled symbol
_ZL3foov defined in the object file .

So I have to form the mangled name string beforehand,
even for symbols for which there is no linkage ?

ie. there should never be any symbol table entry for 'foo' -
only in the debuginfo there will be information about it .

So I must run some name mangler /  generator as a
pre-processing step to get the correct mangled name
string ?

Like, if I compile just :

static inline __attribute__((always_inline))
void foo(void) {}
void f(void)
{ foo();
}

Then both
   $ nm -a t.o | grep  ZL3foov
 and
   $ objdump -t t.o | grep ZL3foov
 and
   $ objdump -g t.o | grep ZL3foov

produce no output. So how does one determine that mangled name
a-priori ? There seems to be no way of getting cpp to do it, anyway ,
which is what it would have to do to be an acceptable solution -
there must be a string literal constant argument to '__attribute__(alias()))'.

I think some kind of new pragma is needed , to allow one to say
something like:

#define _S(_X) #X
#define QUOTED_STRING(_X) _S(_X)

static inline __attribute__((always_inline, alias(
QUOTED_STRING(
#pragma symbol_name(foo)
// insert mangled symbol name here
)
)));

I'm going to investigate patching GCC to support
something like that.

I think it is unacceptable to be forced to used
mangled symbol names for objects which are
not symbols (pure inline functions) .

Thanks & Regards,
Jason

))
 void bar(void) ;


Re: why C++ cannot alias an inline function, C can ?

2018-04-01 Thread Max Filippov
On Sun, Apr 1, 2018 at 5:33 AM, Jason Vas Dias  wrote:
> Aha!  But how to determine the mangled name beforehand ?
>
> Even if I compile the object without the alias, then inspect
> the object with objdump, there is no mangled symbol
> _ZL3foov defined in the object file .
>
> So I must run some name mangler /  generator as a
> pre-processing step to get the correct mangled name
> string ?

I guess so. Or you could define foo with C linkage:

 extern "C" {
  static inline __attribute__((always_inline))
  void foo(void){}
 };

 static inline __attribute__((always_inline,alias("foo")))
 void bar(void);

 static
 void f(void) { foo(); }
 // must have a usage to generate any code

> I think it is unacceptable to be forced to used
> mangled symbol names for objects which are
> not symbols (pure inline functions) .

Pure inline functions may be overloaded, how will you
decide which one to alias given only unmangled name?

-- 
Thanks.
-- Max


Re: GSoC (Improvements to GCC on Windows)

2018-04-01 Thread JonY
On 03/14/2018 05:13 PM, Martin Jambor wrote:
> Hello,
> 
> On Tue, Mar 13 2018, Ko Phyo wrote:
>> Hello
>>
>> I want to apply the project "Improvements to GCC on Windows" of GCC
>> foundation. As a student, I have some theorectical knowledges about C/C++
>> and compiler technologies. And I am sure that the Windows platform has
>> steps that are little behind than other open source platforms in pure C/C++
>> technology. So I decided to work on GSoC 2018 with your "Windows
>> Improvement program". Please let me know if I am selected as a mentored
>> student in yours great project. I will be waiting for your kind reply.
> 
> Well, please note that you still need to apply formally through the GSoC
> website to stand a chance to be selected, that does not happen here.
> We want students to contact us prior to applying so that their proposals
> and goals make sense.
> 
> As far as improving GCC on Windows is concerned, we may find it
> challenging to find you a mentor (I am CCing Jonathan Yong, the cygwin
> and mingw-w64 maintainer, maybe he has an idea what could be done in
> this area as a GSoC project and who might mentor it?).
> 
> Meanwhile, make sure you can build GCC from sources on Windows (I admit
> I would not know how to do it myself!) and run the testsuite.
> 
> Good luck,
> 
> Martin
> .
> 

Hi, I have been away for work this past month.

There is a demand for a proper C++11 threading implementation for
Windows using native Windows APIs (post Vista APIs), I have not looked
too much into it, nor do I know if the scope is too big or too small for
a summer project. Liu Hao has worked on it, and should be familiar with
the scope, I have CC'ed him.

Never having run any gsoc programs, are there any specific procedures to
get it started?



signature.asc
Description: OpenPGP digital signature


"file name" vs "filename"

2018-04-01 Thread Gerald Pfeifer
And now to the most important question of all. ;-)  Should we use
"file name" or "filename" when referring to the name of a file?

Our docs currently are about even and I think it would be good to
settle on one?

  % grep "filename" $GCC/gcc/doc/*.texi | wc -l
  92
  % grep "file name" $GCC/gcc/doc/*.texi | wc -l
  103

(Once we have consensus, I'll add that to codingconventions.html
and start by making the web pages consistent.)

Gerald


Re: "file name" vs "filename"

2018-04-01 Thread Joel Sherrill
On Sun, Apr 1, 2018, 3:16 PM Gerald Pfeifer  wrote:

> And now to the most important question of all. ;-)  Should we use
> "file name" or "filename" when referring to the name of a file?
>
> Our docs currently are about even and I think it would be good to
> settle on one?
>
>   % grep "filename" $GCC/gcc/doc/*.texi | wc -l
>   92
>   % grep "file name" $GCC/gcc/doc/*.texi | wc -l
>   103
>
> (Once we have consensus, I'll add that to codingconventions.html
> and start by making the web pages consistent.)


Searching and looking at online dictionaries, it  looks like filename is
the currently preferred form.

--joel

>
> Gerald
>


Re: why C++ cannot alias an inline function, C can ?

2018-04-01 Thread Marc Glisse

(should have been on gcc-help I believe)

On Sun, 1 Apr 2018, Max Filippov wrote:


On Sun, Apr 1, 2018 at 5:33 AM, Jason Vas Dias  wrote:

Aha!  But how to determine the mangled name beforehand ?

Even if I compile the object without the alias, then inspect
the object with objdump, there is no mangled symbol
_ZL3foov defined in the object file .

So I must run some name mangler /  generator as a
pre-processing step to get the correct mangled name
string ?


I guess so. Or you could define foo with C linkage:

extern "C" {
 static inline __attribute__((always_inline))
 void foo(void){}
};

static inline __attribute__((always_inline,alias("foo")))
void bar(void);


Or you can use an asm label to specify some arbitrary name.

--
Marc Glisse


gcc-8-20180401 is now available

2018-04-01 Thread gccadmin
Snapshot gcc-8-20180401 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/8-20180401/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 258999

You'll find:

 gcc-8-20180401.tar.xzComplete GCC

  SHA256=3a91c5a9cc4708211484b75e3e43a399c3d9d800e5d8773dc2c6a1169a99b835
  SHA1=cbcff51571de862f4d423c35583e90e7e8a82e3f

Diffs from 8-20180325 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.


Re: "file name" vs "filename"

2018-04-01 Thread Sandra Loosemore

On 04/01/2018 02:56 PM, Joel Sherrill wrote:



On Sun, Apr 1, 2018, 3:16 PM Gerald Pfeifer > wrote:


And now to the most important question of all. ;-)  Should we use
"file name" or "filename" when referring to the name of a file?

Our docs currently are about even and I think it would be good to
settle on one?

   % grep "filename" $GCC/gcc/doc/*.texi | wc -l
   92
   % grep "file name" $GCC/gcc/doc/*.texi | wc -l
   103

(Once we have consensus, I'll add that to codingconventions.html
and start by making the web pages consistent.)


Searching and looking at online dictionaries, it  looks like filename is 
the currently preferred form.


The C and C++ standards documents use "file name"; there are other 
places ("bit-field") where the GCC manual has adopted the C standard 
terminology.


In this case it might be more appropriate to adopt the POSIX 
conventions, since I suspect most of the uses in the GCC documentation 
refer to the host environment rather than the target language.  This 
looks like the POSIX glossary:


http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html

Here "filename" is given as the correct spelling, except that that 
glossary distinguishes between "filename" and "pathname" (a "filename" 
is the same as a "pathname component").  So perhaps many of the "file 
name"/"filename" uses in the GCC manual ought to be "pathname" instead?


-Sandra


Re: GSoC (Improvements to GCC on Windows)

2018-04-01 Thread Ko Phyo
Thank for your valuable information. I couldn't made it for GSoC 2018 due
to delay of my proposal application because of my University 1st semester
examination. If you guys allow me to apply this kind of project in future
(Not as GSoC applicant), I would be happily take part in it. Thanks in
advanced.

On Apr 1, 2018 9:39 PM, "JonY" <10wa...@gmail.com> wrote:

> On 03/14/2018 05:13 PM, Martin Jambor wrote:
> > Hello,
> >
> > On Tue, Mar 13 2018, Ko Phyo wrote:
> >> Hello
> >>
> >> I want to apply the project "Improvements to GCC on Windows" of
> GCC
> >> foundation. As a student, I have some theorectical knowledges about
> C/C++
> >> and compiler technologies. And I am sure that the Windows platform has
> >> steps that are little behind than other open source platforms in pure
> C/C++
> >> technology. So I decided to work on GSoC 2018 with your "Windows
> >> Improvement program". Please let me know if I am selected as a mentored
> >> student in yours great project. I will be waiting for your kind reply.
> >
> > Well, please note that you still need to apply formally through the GSoC
> > website to stand a chance to be selected, that does not happen here.
> > We want students to contact us prior to applying so that their proposals
> > and goals make sense.
> >
> > As far as improving GCC on Windows is concerned, we may find it
> > challenging to find you a mentor (I am CCing Jonathan Yong, the cygwin
> > and mingw-w64 maintainer, maybe he has an idea what could be done in
> > this area as a GSoC project and who might mentor it?).
> >
> > Meanwhile, make sure you can build GCC from sources on Windows (I admit
> > I would not know how to do it myself!) and run the testsuite.
> >
> > Good luck,
> >
> > Martin
> > .
> >
>
> Hi, I have been away for work this past month.
>
> There is a demand for a proper C++11 threading implementation for
> Windows using native Windows APIs (post Vista APIs), I have not looked
> too much into it, nor do I know if the scope is too big or too small for
> a summer project. Liu Hao has worked on it, and should be familiar with
> the scope, I have CC'ed him.
>
> Never having run any gsoc programs, are there any specific procedures to
> get it started?
>
>


Re: GSoC (Improvements to GCC on Windows)

2018-04-01 Thread Liu Hao
在 2018/4/2 13:54, Ko Phyo 写道:
> Thank for your valuable information. I couldn't made it for GSoC 2018 due
> to delay of my proposal application because of my University 1st semester
> examination. If you guys allow me to apply this kind of project in future
> (Not as GSoC applicant), I would be happily take part in it. Thanks in
> advanced.
> 
> On Apr 1, 2018 9:39 PM, "JonY" <10wa...@gmail.com> wrote:
>> Hi, I have been away for work this past month.
>>
>> There is a demand for a proper C++11 threading implementation for
>> Windows using native Windows APIs (post Vista APIs), I have not looked
>> too much into it, nor do I know if the scope is too big or too small for
>> a summer project. Liu Hao has worked on it, and should be familiar with
>> the scope, I have CC'ed him.
>>
>> Never having run any gsoc programs, are there any specific procedures to
>> get it started?
>>
>>

Well I thought I was almost forgotten.  XD

You might want to have a look at my benchmarking result at
. Prebuilt
binaries are available at .

I haven't heard of anyone using this new thread model in production
environments. So it would be very kind of you for advertising for it.

-- 
Best regards,
LH_Mouse