Re: GCC 5.4 Status report (2015-12-04)

[NightStrike]

Will there be another 4.9 release, too?  I'm really hoping that branch
can stay open a bit, since I can't upgrade to the new std::string
implementation yet.

On Fri, Dec 4, 2015 at 8:29 AM, Richard Biener  wrote:
>
> Status
> ==
>
> The GCC 5 branch is open again for regression and documentation fixes.
> If nothing unusual happens you can expect GCC 5.4 somewhen closely
> before GCC 6 is released.
>
>
> Quality Data
> 
>
> Priority  #   Change from last report
> ---   ---
> P10
> P2  109-  12
> P3   28+   8
> P4   85-   2
> P5   32
> ---   ---
> Total P1-P3 137+   4
> Total   254-   6
>
>
> Previous Report
> ===
>
> https://gcc.gnu.org/ml/gcc/2015-11/msg00113.html

4.9 backport request

[NightStrike]

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

Would anyone mind backporting these two dependent bug fixes to 4.9?

Minor documentation typo

[NightStrike]

On https://gcc.gnu.org/gcc-5/porting_to.html about two thirds of the way down:

"As the default mode changed to C11, the __STDC_VERSION__ standard
macro, introduced in C95, is now defined by default, and has the value
201112L."

That should probably be C99.

option -mprfchw on 2 different Opteron cpus

[NightStrike]

Reposting from here:
https://gcc.gnu.org/ml/gcc-help/2016-05/msg3.html

Not sure if this applies:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54210

If I compile on a k8 Opteron 248 with -march=native, I do not see
-mprfchw listed in the options in -fverbose-asm.  In the assembly, I
see this:

prefetcht0  (%rax)  # ivtmp.1160
prefetcht0  304(%rcx)   #
prefetcht0  (%rax)  # ivtmp.1160

If I compile on a bdver2 Opteron 6386 SE with -march=k8 (thus trying
to target the older system), I do see it listed in the options in
-fverbose-asm.  In the assembly, I see this:

prefetcht0  (%rax)  # ivtmp.1160
prefetcht0  304(%rcx)   #
prefetchw   (%rax)  # ivtmp.1160

(The third line is the only difference)

In both cases, I'm using gcc 4.9.3.  Which is correct for a k8 Opteron 248?

Also, FWIW:

1) The march=native version that uses prefetcht0 is very repeatably
faster by about 15% in the particular test case I'm looking at.

2) The compilers in both instances are not just the same version, they
are the same compiler binary installed on an NFS mount and shared to both
computers.

Re: option -mprfchw on 2 different Opteron cpus

[NightStrike]

On Mon, May 2, 2016 at 5:55 AM, Kumar, Venkataramanan
 wrote:
>> If I compile on a k8 Opteron 248 with -march=native, I do not see -mprfchw
>> listed in the options in -fverbose-asm.  In the assembly, I see this:
>>
>> prefetcht0  (%rax)  # ivtmp.1160
>> prefetcht0  304(%rcx)   #
>> prefetcht0  (%rax)  # ivtmp.1160
>
> In AMD processors -mprfchw flag  is used to enable "3dnowprefetch" ISA 
> support.
>
> (Snip)
> CPUID Fn8000_0001_ECX Feature Identifiers
> Bit 8
> 3DNowPrefetch: PREFETCH and PREFETCHW instruction support. See “PREFETCH” and
> “PREFETCHW” in APM3
> Ref: http://support.amd.com/TechDocs/25481.pdf
> (Snip)
>
> Can you please confirm what this CPUID flag returns on your k8 machine ?.
> I believe this ISA is not available on k8 machine so when -march=native is 
> added you don’t see  -mprfchw in verbose.

Looks like zero?  This was generated with the cpuid program from
http://www.etallen.com/cpuid.html

CPU 0:
   0x 0x00: eax=0x0001 ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65
   0x0001 0x00: eax=0x0f58 ebx=0x0800 ecx=0x edx=0x078bfbff
   0x8000 0x00: eax=0x8018 ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65
   0x8001 0x00: eax=0x0f58 ebx=0x0405 ecx=0x edx=0xe1d3fbff
   0x8002 0x00: eax=0x20444d41 ebx=0x6574704f ecx=0x286e6f72 edx=0x20296d74
   0x8003 0x00: eax=0x636f7250 ebx=0x6f737365 ecx=0x34322072 edx=0x0038
   0x8004 0x00: eax=0x ebx=0x ecx=0x edx=0x
   0x8005 0x00: eax=0xff08ff08 ebx=0xff20ff20 ecx=0x40020140 edx=0x40020140
   0x8006 0x00: eax=0x ebx=0x42004200 ecx=0x04008140 edx=0x
   0x8007 0x00: eax=0x ebx=0x ecx=0x edx=0x0009
   0x8008 0x00: eax=0x3028 ebx=0x ecx=0x edx=0x
   0x8009 0x00: eax=0x ebx=0x ecx=0x edx=0x
   0x800a 0x00: eax=0x ebx=0x ecx=0x edx=0x
   0x800b 0x00: eax=0x ebx=0x ecx=0x edx=0x
   0x800c 0x00: eax=0x ebx=0x ecx=0x edx=0x
   0x800d 0x00: eax=0x ebx=0x ecx=0x edx=0x
   0x800e 0x00: eax=0x ebx=0x ecx=0x edx=0x
   0x800f 0x00: eax=0x ebx=0x ecx=0x edx=0x
   0x8010 0x00: eax=0x ebx=0x ecx=0x edx=0x
   0x8011 0x00: eax=0x ebx=0x ecx=0x edx=0x
   0x8012 0x00: eax=0x ebx=0x ecx=0x edx=0x
   0x8013 0x00: eax=0x ebx=0x ecx=0x edx=0x
   0x8014 0x00: eax=0x ebx=0x ecx=0x edx=0x
   0x8015 0x00: eax=0x ebx=0x ecx=0x edx=0x
   0x8016 0x00: eax=0x ebx=0x ecx=0x edx=0x
   0x8017 0x00: eax=0x ebx=0x ecx=0x edx=0x
   0x8018 0x00: eax=0x ebx=0x ecx=0x edx=0x
   0x8086 0x00: eax=0x ebx=0x ecx=0x edx=0x
   0xc000 0x00: eax=0x ebx=0x ecx=0x edx=0x

CPU:
   vendor_id = "AuthenticAMD"
   version information (1/eax):
  processor type  = primary processor (0)
  family  = Intel Pentium 4/Pentium D/Pentium Extreme
Edition/Celeron/Xeon/Xeon MP/Itanium2, AMD Athlon 64/Athlon
XP-M/Opteron/Sempron/Turion (15)
  model   = 0x5 (5)
  stepping id = 0x8 (8)
  extended family = 0x0 (0)
  extended model  = 0x0 (0)
  (simple synth)  = AMD Opteron (DP SledgeHammer SH7-C0) / Athlon
64 FX (DP SledgeHammer SH7-C0), 940-pin, .13um
   miscellaneous (1/ebx):
  process local APIC physical ID = 0x0 (0)
  cpu count  = 0x0 (0)
  CLFLUSH line size  = 0x8 (8)
  brand index= 0x0 (0)
   brand id = 0x00 (0): unknown
   feature information (1/edx):
  x87 FPU on chip= true
  virtual-8086 mode enhancement  = true
  debugging extensions   = true
  page size extensions   = true
  time stamp counter = true
  RDMSR and WRMSR support= true
  physical address extensions= true
  machine check exception= true
  CMPXCHG8B inst.= true
  APIC on chip   = true
  SYSENTER and SYSEXIT   = true
  memory type range registers= true
  PTE global bit = true
  machine check architecture = true
  conditional move/compare instruction   = true
  page attribute table   = true
  page size extension= true
  processor serial number= f

Re: Please, take '-Wmisleading-indentation' out of -Wall

[NightStrike]

On Wed, May 4, 2016 at 3:35 PM, Manuel López-Ibáñez
 wrote:
> On 04/05/16 19:20, David Malcolm wrote:
>>
>> On Wed, 2016-05-04@18:15 +0200, Antonio Diaz Diaz wrote:
>>>
>>> - It can't be portably disabled; older versions of gcc do not
>>> accept
>>>   '-Wno-misleading-indentation'. (At least 4.1.2 does not accept
>>> it).
>>
>>
>> FWIW "-Wall -Wno-misleading-indentation" works for me with gcc 4.8.3
>
>
> It should work since GCC 4.4 (7 years old). See
> https://gcc.gnu.org/wiki/FAQ#wnowarning

4.1.2 is the system compiler for RHEL5, which is most likely why he
needs it (EL5 is still actively maintained)

Mirror out of date

[NightStrike]

The mirror here:

ftp://mirrors-usa.go-parts.com/gcc/releases/

Does not have gcc 6 from April.

Re: option -mprfchw on 2 different Opteron cpus

[NightStrike]

On Tue, May 3, 2016 at 12:40 AM, Kumar, Venkataramanan
 wrote:
> Hi
>
>> -Original Message-----
>> From: NightStrike [mailto:nightstr...@gmail.com]
>> Sent: Monday, May 2, 2016 10:31 PM
>> To: Kumar, Venkataramanan 
>> Cc: Uros Bizjak (ubiz...@gmail.com) ;
>> lopeziba...@gmail.com; Jan Hubicka ; Jakub Jelinek
>> ; gcc@gcc.gnu.org
>> Subject: Re: option -mprfchw on 2 different Opteron cpus
>>
>> On Mon, May 2, 2016 at 5:55 AM, Kumar, Venkataramanan
>>  wrote:
>> >> If I compile on a k8 Opteron 248 with -march=native, I do not see
>> >> -mprfchw listed in the options in -fverbose-asm.  In the assembly, I see
>> this:
>> >>
>> >> prefetcht0  (%rax)  # ivtmp.1160
>> >> prefetcht0  304(%rcx)   #
>> >> prefetcht0  (%rax)  # ivtmp.1160
>> >
>> > In AMD processors -mprfchw flag  is used to enable "3dnowprefetch" ISA
>> support.
>> >
>> > (Snip)
>> > CPUID Fn8000_0001_ECX Feature Identifiers Bit 8
>> > 3DNowPrefetch: PREFETCH and PREFETCHW instruction support. See
>> > “PREFETCH” and “PREFETCHW” in APM3
>> > Ref: http://support.amd.com/TechDocs/25481.pdf
>> > (Snip)
>> >
>> > Can you please confirm what this CPUID flag returns on your k8 machine ?.
>> > I believe this ISA is not available on k8 machine so when -march=native is
>> added you don’t see  -mprfchw in verbose.
>>
>> Looks like zero?  This was generated with the cpuid program from
>> http://www.etallen.com/cpuid.html
>>
>>   3DNow! instruction extensions = true
>>   3DNow! instructions   = true
>
> It has 3Dnow support.  "prefetchw" is available with 3dnow.
>
>>   misaligned SSE mode= false
>>   3DNow! PREFETCH/PREFETCHW instructions = false
>
> It does not have 3DNowprefetch enabling ISA flag -mprftchw is not correct for 
> -march=k8.
>
>>   OS visible workaround  = false
>>   instruction based sampling = false
>> >> If I compile on a bdver2 Opteron 6386 SE with -march=k8 (thus trying
>> >> to target the older system), I do see it listed in the options in
>> >> -fverbose-asm.  In the assembly, I see this:
>> >
>> > K8 has 3dnow support and there is a patch that replaced 3dnow with
>> prefetchw (3DNowPrefetch).
>> > https://gcc.gnu.org/ml/gcc-patches/2013-05/msg00866.html
>> > So when you add -march=k8 you see -mprfchw  getting listed in verbose.
>> >
>> >>
>> >> prefetcht0  (%rax)  # ivtmp.1160
>> >> prefetcht0  304(%rcx)   #
>> >> prefetchw   (%rax)  # ivtmp.1160
>> >>
>> >> (The third line is the only difference)
>> >>
>> >
>> > This is my guess without seeing the test case, when write  prefetching is
>> requested "prefetchw" is generated.
>> > 3dnow (TARGET_3DNOW) ISA has support for it.
>> >
>> > (Snip)
>> > Support for the PREFETCH and PREFETCHW instructions is indicated by
>> > CPUID Fn8000_0001_ECX[3DNowPrefetch] OR Fn8000_0001_EDX[LM] OR
>> > Fn8000_0001_EDX[3DNow] = 1.
>> > (Snip)
>> > Ref:
>> http://developer.amd.com/wordpress/media/2008/10/24594_APM_v3.pdf
>> >
>> >> In both cases, I'm using gcc 4.9.3.  Which is correct for a k8 Opteron 
>> >> 248?
>> >>
>> >> Also, FWIW:
>> >>
>> >> 1) The march=native version that uses prefetcht0 is very repeatably
>> >> faster by about 15% in the particular test case I'm looking at.
>> >>
>> >> 2) The compilers in both instances are not just the same version,
>> >> they are the same compiler binary installed on an NFS mount and
>> >> shared to both computers.
>> >
>> > As per GCC4.9.3 source.
>> >
>> > (Snip)
>> > (define_expand "prefetch"
>> >   [(prefetch (match_operand 0 "address_operand")
>> >  (match_operand:SI 1 "const_int_operand")
>> >  (match_operand:SI 2 "const_int_operand"))]
>> >   "TARGET_PREFETCH_SSE || TARGET_PRFCHW || TARGET_PREFETCHWT1"
>> > {
>> >   bool write = INTVAL (operands[1]) != 0;
>> >   int locality = INTVAL (operands[2]);
>> >
>> >   gcc_assert (IN_RANGE (locality, 0, 3));
>> >
>> >   /* Use 3dNOW prefetch in case we are asking for write pre

Re: Why are GCC Internals not Specification Driven ?

[NightStrike]

On Sun, Dec 18, 2016 at 11:37 AM, Andrew Haley  wrote:
> On 18/12/16 02:33, Seima Rao wrote:
>> Precisely, stuffs like GENERIC, GIMPLE, RTL, gas(inline assembly),
>> GCC extensions internals, ... and gnu's own debugging tied to gcc
>> (if such exist nowadays), ... are not documented in a specification
>> driven way.
>
> That's interesting.  Can you explain what you mean by a specification-
> driven way?

I believe he's referring to top down system design, where you start
from requirements (a la IEEE 830 or IEEE 29148), make design documents
that meet those requirements, model them with something like IEEE 1016
(which is basically UML), and only at the end provide implementation.
On GCC, the implementation tends to come earlier in the process.  At
least, there's probably no UML representation of GCC's design.

Re: GCC version bikeshedding

[NightStrike]

On Wed, Jul 30, 2014 at 8:00 PM, Jonathan Wakely  wrote:
> On 30 July 2014 23:18, Eric Botcazou wrote:
>>> What are you objecting to, calling the next release from trunk 5.0,
>>> and the next one after that 6.0? Or the wording chosen to describe the
>>> new versioning scheme?
>>
>> Let's not start another subthread, please, this will be even more confusing.
>
> I'm not. I'm trying to get your message back on topic.
>
>> You can reply to my reply to Ian's message if you deem it necessary.
>
> Are you objecting to the numbering scheme, or Ian's description of it?
>
> If you have an objection to the concrete plan it would be nice if you
> stated clearly what it is.

One thing you might want to consider is that with the typical X.Y.Z
versioning of most GNU projects, changing X allows breaking
compatibility in a significant way with previous versions.  While Z
fixes regressions and Y adds new features, X is a place to make
infrequent but paradigm shifting changes that are unconstrained by a
desire to stay backwards compatible with older values of X.

By going to what is essentially a Y.Z.0 release mechanism, you lose
that ability to some degree.  Maybe that's ok in a mature project like
GCC.

Re: volatile access optimization (C++ / x86_64)

[NightStrike]

On Mon, Jan 5, 2015 at 12:53 PM, DJ Delorie  wrote:
>
> Matt Godbolt  writes:
>> GCC's code generation uses a "load; add; store" for volatiles, instead
>> of a single "add 1, [metric]".
>
> GCC doesn't know if a target's load/add/store patterns are
> volatile-safe, so it must avoid them.  There are a few targets that have
> been audited for volatile-safe-ness such that gcc *can* use the combined
> load/add/store when the backend says it's OK.  x86 is not yet one of
> those targets.

Really?  I thought x86 was one of the few that were known to be ok
here.  What is involved with the auditing?

Re: Successful bootsrap of gcc 8.2.0 on x86_64-w64-mingw32

[NightStrike]

On Fri, Aug 31, 2018 at 9:24 AM Jonathan Wakely  wrote:
>
> On Thu, 30 Aug 2018 at 21:22, Rainer Emrich wrote:
> >
> > Am 30.08.2018 um 14:38 schrieb Jonathan Wakely:
> > > Thanks for these logs, they're very helpful. Trunk revision r263976
> > > fixes a number of the libstdc++ FAILs (compilation errors) and trunk
> > > revision r263977 fixes a load more (linker errors).
> > >
> > > I'm about to fix one more FAIL, a recent regression that only affects
> > > LLP64 targets (i.e. only Windows) where sizeof(size_t) !=
> > > sizeof(long).
> > >
> > > For your next trunk build, would it be possible to add
> > > --enable-libstdcxx-filesystem-ts to the configure options? That will
> > > test the filesystem TS and C++17 code. I know there are quite a few
> > > failures on mingw but it would be good to see a full set of results.
> > Here we go https://gcc.gnu.org/ml/gcc-testresults/2018-08/msg03827.html
> > trunk rev. 263988, using --enable-languages=all 
> > --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts
> > Full build and testsuite logs at 
> > https://cloud.emrich-ebersheim.de/index.php/s/B9J89N94Rc8cgJZ
>
> Thanks, the libstdc++ result are looking pretty good. I'll go through
> the logs next week.

Here are some build warnings if you like:

../../../../../../gccsvn/libstdc++-v3/src/filesystem/ops.cc:539:42:
warning: unused parameter 'to' [-Wunused-parameter]
../../../../../../gccsvn/libstdc++-v3/src/filesystem/ops.cc:539:58:
warning: unused parameter 'new_symlink' [-Wunused-parameter]
../../../../../../gccsvn/libstdc++-v3/src/filesystem/ops.cc:590:32:
warning: unused parameter 'to' [-Wunused-parameter]
../../../../../../gccsvn/libstdc++-v3/src/filesystem/ops.cc:590:48:
warning: unused parameter 'new_symlink' [-Wunused-parameter]
../../../../../../gccsvn/libstdc++-v3/src/filesystem/std-ops.cc:769:42:
warning: unused parameter 'to' [-Wunused-parameter]
../../../../../../gccsvn/libstdc++-v3/src/filesystem/std-ops.cc:769:58:
warning: unused parameter 'new_symlink' [-Wunused-parameter]
../../../../../../gccsvn/libstdc++-v3/src/filesystem/std-ops.cc:820:32:
warning: unused parameter 'to' [-Wunused-parameter]
../../../../../../gccsvn/libstdc++-v3/src/filesystem/std-ops.cc:820:48:
warning: unused parameter 'new_symlink' [-Wunused-parameter]
../../../../../../gccsvn/libstdc++-v3/src/filesystem/ops.cc:539:42:
warning: unused parameter 'to' [-Wunused-parameter]
../../../../../../gccsvn/libstdc++-v3/src/filesystem/ops.cc:539:58:
warning: unused parameter 'new_symlink' [-Wunused-parameter]
../../../../../../gccsvn/libstdc++-v3/src/filesystem/ops.cc:590:32:
warning: unused parameter 'to' [-Wunused-parameter]
../../../../../../gccsvn/libstdc++-v3/src/filesystem/ops.cc:590:48:
warning: unused parameter 'new_symlink' [-Wunused-parameter]
../../../../../../gccsvn/libstdc++-v3/src/filesystem/std-ops.cc:769:42:
warning: unused parameter 'to' [-Wunused-parameter]
../../../../../../gccsvn/libstdc++-v3/src/filesystem/std-ops.cc:769:58:
warning: unused parameter 'new_symlink' [-Wunused-parameter]
../../../../../../gccsvn/libstdc++-v3/src/filesystem/std-ops.cc:820:32:
warning: unused parameter 'to' [-Wunused-parameter]
../../../../../../gccsvn/libstdc++-v3/src/filesystem/std-ops.cc:820:48:
warning: unused parameter 'new_symlink' [-Wunused-parameter]

w64 cross, testsuite under wine, escape sequences

[NightStrike]

Host: x86_64-pc-linux (Cent 6)
Target: x86_64-w64-mingw32 (wine)

When I build the linux > w64 cross compiler under linux and run the
testsuite under wine, it all basically works for the most part.
However, the log files get filled with what appears to be ANSI escape
sequences of the form:

^[[?1h^[=^[[?1l^[>

For instance:

^[[?1h^[=^[[?1l^[>PASS: gcc.dg/ipa/ipa-pta-1.c execution test

This generally doesn't cause a problem, except in the case of some
fortran output pattern tests that try to patch ^string$.  In that
case, the regex fails, as it pulls in the escape sequences as part of
"string".

To run the testsuite under wine, I created a simulator board that uses
"wine64" as the simulator that prefixes every spawned test.  I ran
this manually myself, and I do not get any extra characters, so I do
not think that it's wine related.

Does anyone have any experience with this, or suggestions on what to do?

Re: w64 cross, testsuite under wine, escape sequences

[NightStrike]

On Thu, Sep 6, 2018 at 9:08 AM NightStrike  wrote:
>
> Host: x86_64-pc-linux (Cent 6)
> Target: x86_64-w64-mingw32 (wine)
>
> When I build the linux > w64 cross compiler under linux and run the
> testsuite under wine, it all basically works for the most part.
> However, the log files get filled with what appears to be ANSI escape
> sequences of the form:
>
> ^[[?1h^[=^[[?1l^[>
>
> For instance:
>
> ^[[?1h^[=^[[?1l^[>PASS: gcc.dg/ipa/ipa-pta-1.c execution test
>
> This generally doesn't cause a problem, except in the case of some
> fortran output pattern tests that try to patch ^string$.  In that
> case, the regex fails, as it pulls in the escape sequences as part of
> "string".
>
> To run the testsuite under wine, I created a simulator board that uses
> "wine64" as the simulator that prefixes every spawned test.  I ran
> this manually myself, and I do not get any extra characters, so I do
> not think that it's wine related.
>
> Does anyone have any experience with this, or suggestions on what to do?

It looks like this is definitely wine.  Running it standalone under
strace shows this towards the end:

stat("/etc/terminfo", {st_mode=S_IFDIR|0755, st_size=2, ...}) = 0
access("/etc/terminfo/x/xterm-256color", R_OK) = -1 ENOENT (No such
file or directory)
stat("/usr/share/terminfo", {st_mode=S_IFDIR|0755, st_size=22, ...}) = 0
access("/usr/share/terminfo/x/xterm-256color", R_OK) = 0
open("/usr/share/terminfo/x/xterm-256color", O_RDONLY) = 10
read(10, "\32\1%\0&\0\17\0\235\1\251\5xterm-256color|xterm"..., 4097) = 3322
close(10)   = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=68, ws_col=209, ws_xpixel=0, ws_ypixel=0}) = 0
open("/proc/meminfo", O_RDONLY|O_CLOEXEC) = 10
fstat(10, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7ff2b72f9000
read(10, "MemTotal:   297772936 kB\nMem"..., 1024) = 1024
close(10)   = 0
munmap(0x7ff2b72f9000, 4096)= 0
write(1, "\33", 1 = 1
write(1, "[", 1[)= 1
write(1, "?", 1?)= 1
write(1, "1", 11)= 1
write(1, "h", 1h)= 1
write(1, "\33", 1 = 1
write(1, "=", 1=)= 1



Any idea how to tell dejagnu to strip this out?

Re: w64 cross, testsuite under wine, escape sequences

[NightStrike]

On Thu, Sep 6, 2018 at 4:58 PM NightStrike  wrote:
>
> On Thu, Sep 6, 2018 at 9:08 AM NightStrike  wrote:
> >
> > Host: x86_64-pc-linux (Cent 6)
> > Target: x86_64-w64-mingw32 (wine)
> >
> > When I build the linux > w64 cross compiler under linux and run the
> > testsuite under wine, it all basically works for the most part.
> > However, the log files get filled with what appears to be ANSI escape
> > sequences of the form:
> >
> > ^[[?1h^[=^[[?1l^[>
> >
> > For instance:
> >
> > ^[[?1h^[=^[[?1l^[>PASS: gcc.dg/ipa/ipa-pta-1.c execution test
> >
> > This generally doesn't cause a problem, except in the case of some
> > fortran output pattern tests that try to patch ^string$.  In that
> > case, the regex fails, as it pulls in the escape sequences as part of
> > "string".
> >
> > To run the testsuite under wine, I created a simulator board that uses
> > "wine64" as the simulator that prefixes every spawned test.  I ran
> > this manually myself, and I do not get any extra characters, so I do
> > not think that it's wine related.
> >
> > Does anyone have any experience with this, or suggestions on what to do?
>
> It looks like this is definitely wine.  Running it standalone under
> strace shows this towards the end:
>
> stat("/etc/terminfo", {st_mode=S_IFDIR|0755, st_size=2, ...}) = 0
> access("/etc/terminfo/x/xterm-256color", R_OK) = -1 ENOENT (No such
> file or directory)
> stat("/usr/share/terminfo", {st_mode=S_IFDIR|0755, st_size=22, ...}) = 0
> access("/usr/share/terminfo/x/xterm-256color", R_OK) = 0
> open("/usr/share/terminfo/x/xterm-256color", O_RDONLY) = 10
> read(10, "\32\1%\0&\0\17\0\235\1\251\5xterm-256color|xterm"..., 4097) = 3322
> close(10)   = 0
> ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
> TCGETS, {B38400 opost isig icanon echo ...}) = 0
> ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
> TCGETS, {B38400 opost isig icanon echo ...}) = 0
> ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
> TCGETS, {B38400 opost isig icanon echo ...}) = 0
> ioctl(1, TIOCGWINSZ, {ws_row=68, ws_col=209, ws_xpixel=0, ws_ypixel=0}) = 0
> open("/proc/meminfo", O_RDONLY|O_CLOEXEC) = 10
> fstat(10, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7ff2b72f9000
> read(10, "MemTotal:   297772936 kB\nMem"..., 1024) = 1024
> close(10)   = 0
> munmap(0x7ff2b72f9000, 4096)= 0
> write(1, "\33", 1 = 1
> write(1, "[", 1[)= 1
> write(1, "?", 1?)= 1
> write(1, "1", 11)= 1
> write(1, "h", 1h)= 1
> write(1, "\33", 1 = 1
> write(1, "=", 1=)= 1
>
>
>
> Any idea how to tell dejagnu to strip this out?

I rebuilt wine with --without-curses, and it looks like the problem
has gone away.  Success!

Re: CFG generation from C/C++ and JAVA

[NightStrike]

On Thu, Jun 27, 2019 at 11:32 AM charfi asma via gcc  wrote:
>
>  Thank you for your help.
> Yes, It seems that gcj6 is not well installaed.
> Could you please help me to install it ? which installation instruction 
> should I follow ?
>
> I can not installed with apt-get
> should I checkout the gcj 6 from git and setup it manually ?
> If yes, can you please give me the steps to follow ?
> Thank you again for your help
>
> Le jeudi 27 juin 2019 à 11:24:41 UTC+2, Richard Biener 
>  a écrit :
>
>  On Wed, Jun 26, 2019 at 5:33 PM charfi asma via gcc  wrote:
> >
> > Hello,
> > I am interested in generating the CFG from several gcc front ends. All 
> > works fine for GCC and G++, and we are also interrested in JAVA.
> > we have seen that GCJ is no longer maintained/distributed by GCCHowever, we 
> > do not like to compile input java code into assembly or binary code, we 
> > would like just to analyze (with our tools) the CFG produced from each 
> > front ends including the gcj front end.
> > we downloaded the gcc 6.5.0 that contains gcj but when trying to call "gcj 
> > -v" we got this error : "libgcj.spec : Nosuch file or directory."
> > Any idea ? we really need to evaluate the java front end even in a previous 
> > version of GCC (just to dump the Generic, gimple and cfg intermediate 
> > representations)
> > Thank you very much !
>
> it looks like you failed to build and install libjava.  Please follow
> the install instructions, in particular you need to download
> ecj.jar which you likely forgot.
>
> Richard.
>
> > Asma

https://gcc.gnu.org/install/

Re: Hello, I would like to know how to download gcc 9.2 in windows from here. https://ftp.gnu.org/gnu/gcc/gcc-9.2.0/ Thanks.

[NightStrike]

On Mon, Nov 4, 2019, 2:59 PM Aditya Guharoy 
wrote:

> Hello,
> I would like to know how to download gcc 9.2 in windows from here.
> https://ftp.gnu.org/gnu/gcc/gcc-9.2.0/
> Thanks.
>

Https://mingw-w64.sf.net

>

Cygwin + zlib

[NightStrike]

Currently, to build natively on cygwin, this patch is required to zlib:

https://github.com/Alexpux/MSYS2-packages/blob/master/zlib/1.2.11-cygwin-no-widechar.patch

Otherwise, this error occurs:

./../zlib/libz.a(libz_a-gzlib.o):gzlib.c:(.text+0x646): undefined
reference to `_wopen'
./../zlib/libz.a(libz_a-gzlib.o):gzlib.c:(.text+0x646): relocation
truncated to fit: R_X86_64_PC32 against undefined symbol `_wopen'


Given that cygwin is a supported system, and given that zlib is
in-tree (and was recently updated), does it make sense to include this
patch in the gcc in-tree version of zlib?

Re: dejagnu version update?

[NightStrike]

On Sat, May 13, 2017 at 4:39 PM, Jeff Law  wrote:
> On 05/13/2017 04:38 AM, Jakub Jelinek wrote:
>>
>> On Sat, May 13, 2017 at 12:24:12PM +0200, Bernhard Reutner-Fischer wrote:
>>>
>>> I guess neither redhat
>>> (https://access.redhat.com/downloads/content/dejagnu/ redirects to a
>>> login page but there seem to be 1.5.1 packages) nor SuSE did update
>>> dejagnu in the meantime.
>>
>>
>> Fedora has dejagnu-1.6 in Fedora 25 and later, dejagnu-1.5.3 in Fedora 24,
>> older
>> Fedora versions are EOL.  RHEL 7 has dejagnu-1.5.1, RHEL 6 as well as RHEL
>> 5 has
>> dejagnu-1.4.4, older RHEL versions are EOL.
>
> RHEL-5 is old enough that IMHO it ought not figure into this discussion.
> RHEL-6 is probably close to if not past that same point as well.

FWIW, I still run the testsuite on RHEL 6.

Re: Killing old dead bugs

[NightStrike]

On Mon, Jul 17, 2017 at 11:23 AM, Martin Sebor  wrote:
> you did for the bugs below is ideal.  Adding a test case if one
> doesn't exist in the test suite is also very useful, though quite
> a bit more work.

Isn't a testcase always required?

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[NightStrike]

On Mon, Aug 14, 2017 at 11:10 PM, Martin Sebor  wrote:
> On 08/14/2017 04:22 PM, Eric Gallager wrote:
>>
>> I'm emailing this manually to the list because Bugzilla is down and I
>> can't file a bug on Bugzilla about Bugzilla being down. The error
>> message looks like this:
>
> Bugzilla and the rest of gcc.gnu.org have been down much of
> the afternoon/evening due to a hard drive upgrade (the old disk
> apparently failed).  You're not the only one who found out about

There's no RAID?

Re: How to get GCC on par with ICC?

[NightStrike]

On Wed, Jun 6, 2018 at 11:57 AM, Joel Sherrill  wrote:
>
> On Wed, Jun 6, 2018 at 10:51 AM, Paul Menzel <
> pmenzel+gcc.gnu@molgen.mpg.de> wrote:
>
> > Dear GCC folks,
> >
> >
> > Some scientists in our organization still want to use the Intel compiler,
> > as they say, it produces faster code, which is then executed on clusters.
> > Some resources on the Web [1][2] confirm this. (I am aware, that it’s
> > heavily dependent on the actual program.)
> >
>
> Do they have specific examples where icc is better for them? Or can point
> to specific GCC PRs which impact them?
>
>
> GCC versions?
>
> Are there specific CPU model variants of concern?
>
> What flags are used to compile? Some times a bit of advice can produce
> improvements.
>
> Without specific examples, it is hard to set goals.

If I could perhaps jump in here for a moment...  Just today I hit upon
a series of small (in lines of code) loops that gcc can't vectorize,
and intel vectorizes like a madman.  They all involve a lot of heavy
use of std::vector>.  Comparisons were with gcc
8.1, intel 2018.u1, an AMD Opteron 6386 SE, with the program running
as sched_FIFO, mlockall, affinity set to its own core, and all
interrupts vectored off that core.  So, as close to not-noisy as
possible.

I was surprised at the results results, but using each compiler's methods of
dumping vectorization info, intel wins on two points:

1) It actually vectorizes
2) It's vectorizing output is much more easily readable

Options were:

gcc -Wall -ggdb3 -std=gnu++17 -flto -Ofast -march=native

vs:

icc -Ofast -std=gnu++14


So, not exactly exact, but pretty close.


So here's an example of a chunk of code (not very readable, sorry
about that) that intel can vectorize, and subsequently make about 50%
faster:

std::size_t nLayers { input.nn.size() };
//std::size_t ySize = std::max_element(input.nn.cbegin(),
input.nn.cend(), [](auto a, auto b){ return a.size() < b.size();
})->size();
std::size_t ySize = 0;
for (auto const & nn: input.nn)
ySize = std::max(ySize, nn.size());

float yNorm[ySize];
for (auto & y: yNorm)
y = 0.0f;
for (std::size_t i = 0; i < xSize; ++i)
yNorm[i] = xNorm[i];
for (std::size_t layer = 0; layer < nLayers; ++layer) {
auto & nn = input.nn[layer];
auto & b = nn.back();
float y[ySize];
for (std::size_t i = 0; i < nn[0].size(); ++i) {
y[i] = b[i];
for (std::size_t j = 0; j < nn.size() - 1; ++j)
y[i] += nn.at(j).at(i) * yNorm[j];
}
for (std::size_t i = 0; i < ySize; ++i) {
if (layer < nLayers - 1)
y[i] = std::max(y[i], 0.0f);
yNorm[i] = y[i];
}
}


If I was better at godbolt, I could show the asm, but I'm not.  I'm
willing to learn, though.

Re: ChangeLog's: do we have to?

[NightStrike]

On Thu, Jul 5, 2018 at 6:28 AM, Richard Biener
 wrote:
> On Thu, Jul 5, 2018 at 12:13 PM Eric Botcazou  wrote:
>>
>> > They are definitely useful in my day-to-day work when tracking down changes
>> > given I can easily grep them.
>>
>> Seconded.
>>
>> > I think that any change here should be _after_ we've switched to git
>> > (finally).
>>
>> Well, git doesn't make anything easier than subversion in this area so...
>
> I was told there's git grep which may be used to grep commit logs?

svn log | grep   ?

Re: ChangeLog's: do we have to?

[NightStrike]

On Thu, Jul 5, 2018 at 7:53 AM, Richard Biener
 wrote:
> On Thu, Jul 5, 2018 at 1:48 PM NightStrike  wrote:
>>
>> On Thu, Jul 5, 2018 at 6:28 AM, Richard Biener
>>  wrote:
>> > On Thu, Jul 5, 2018 at 12:13 PM Eric Botcazou  
>> > wrote:
>> >>
>> >> > They are definitely useful in my day-to-day work when tracking down 
>> >> > changes
>> >> > given I can easily grep them.
>> >>
>> >> Seconded.
>> >>
>> >> > I think that any change here should be _after_ we've switched to git
>> >> > (finally).
>> >>
>> >> Well, git doesn't make anything easier than subversion in this area so...
>> >
>> > I was told there's git grep which may be used to grep commit logs?
>>
>> svn log | grep   ?
>
> Given that puts load on the server (and is also slow) I'd rather avoid
> that, but yes.

Addendum:  svn log --search is quite a lot faster, has minimal server
side load, and has the added benefit of searching the entire commit
message as an entity vs grep being line-oriented.  Of course, nothing
is as fast as querying a local file, but I'm just mentioning it for
completeness, as the --search option to log is often overlooked.

Re: ChangeLog's: do we have to?

[NightStrike]

On Fri, Jul 6, 2018 at 1:17 AM, Siddhesh Poyarekar  wrote:
> On 07/05/2018 05:02 PM, Richard Biener wrote:
>>
>> I assumed you just want to remove the ChangeLog files, not change
>> contents.
>> Thus I assumed the commit message would simply contain the ChangeLog
>> entry as we requie it today?  In that case git log --grep would still
>> provide
>> everything grepping ChangeLogs does - maybe apart from reducing noise
>> because you can automatically grep specific ChangeLogs only (like only in
>> cp/).
>
>
> We had discussed making addition of ChangeLog entries into the commit
> message mandatory but the issue there is that commit logs cannot be (or more
> precisely, should not be) modified after they're pushed so errors in
> ChangeLog entries will remain.  Carlos had suggested git notes, but I don't
> know off the top of my head how they work; I vaguely remember them being
> editable.

You could do this now under svn, I believe, as svn allows --rev-prop
changes to modify the log.

Re: Successful bootsrap of gcc 8.2.0 on x86_64-w64-mingw32

[NightStrike]

On Tue, Aug 21, 2018 at 9:52 AM, Rainer Emrich
 wrote:
> Bootstrap is done with msys2 on Windows 7. For the testsuite results see
> https://gcc.gnu.org/ml/gcc-testresults/2018-08/msg02651.html

Did you get SEH to work?

Re: Successful bootsrap of gcc 8.2.0 on x86_64-w64-mingw32

[NightStrike]

On Tue, Aug 21, 2018 at 2:05 PM, Alexey Pavlov  wrote:
>
> вт, 21 авг. 2018 г. в 20:46, NightStrike :
>>
>> On Tue, Aug 21, 2018 at 9:52 AM, Rainer Emrich
>>  wrote:
>> > Bootstrap is done with msys2 on Windows 7. For the testsuite results see
>> > https://gcc.gnu.org/ml/gcc-testresults/2018-08/msg02651.html
>>
>> Did you get SEH to work?
>
>
> MSYS2 have 64-bit GCC-8.2.0 toolchain in repo with SEH.
> 32-bit GCC build fail because of gnat segfaults

Can either of you try trunk to see if SEH works?

Re: Successful bootsrap of gcc 8.2.0 on x86_64-w64-mingw32

[NightStrike]

On Wed, Aug 22, 2018 at 3:29 AM, Rainer Emrich
 wrote:
> Am 22.08.2018 um 04:03 schrieb NightStrike:
>> On Tue, Aug 21, 2018 at 2:05 PM, Alexey Pavlov  wrote:
>>> вт, 21 авг. 2018 г. в 20:46, NightStrike :
>>>> On Tue, Aug 21, 2018 at 9:52 AM, Rainer Emrich
>>>>  wrote:
>>>>> Bootstrap is done with msys2 on Windows 7. For the testsuite results see
>>>>> https://gcc.gnu.org/ml/gcc-testresults/2018-08/msg02651.html
>>>>
>>>> Did you get SEH to work?
>>>
>>> MSYS2 have 64-bit GCC-8.2.0 toolchain in repo with SEH.
>>> 32-bit GCC build fail because of gnat segfaults
>>
>> Can either of you try trunk to see if SEH works?
>>
> I can do that tommorow. I'm bootstrapping and testing 7.3.1 at the moment.

Ok.  See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86941 for more
information.

Re: Successful bootsrap of gcc 8.2.0 on x86_64-w64-mingw32

[NightStrike]

On Wed, Aug 22, 2018 at 9:57 AM, Rainer Emrich
 wrote:
> Am 22.08.2018 um 15:24 schrieb NightStrike:
>> On Wed, Aug 22, 2018 at 3:29 AM, Rainer Emrich
>>  wrote:
>>> Am 22.08.2018 um 04:03 schrieb NightStrike:
>>>> On Tue, Aug 21, 2018 at 2:05 PM, Alexey Pavlov  wrote:
>>>>> вт, 21 авг. 2018 г. в 20:46, NightStrike :
>>>>>> On Tue, Aug 21, 2018 at 9:52 AM, Rainer Emrich
>>>>>>  wrote:
>>>>>>> Bootstrap is done with msys2 on Windows 7. For the testsuite results see
>>>>>>> https://gcc.gnu.org/ml/gcc-testresults/2018-08/msg02651.html
>>>>>>
>>>>>> Did you get SEH to work?
>>>>>
>>>>> MSYS2 have 64-bit GCC-8.2.0 toolchain in repo with SEH.
>>>>> 32-bit GCC build fail because of gnat segfaults
>>>>
>>>> Can either of you try trunk to see if SEH works?
>>>>
>>> I can do that tommorow. I'm bootstrapping and testing 7.3.1 at the moment.
>>
>> Ok.  See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86941 for more
>> information.
>>
> Here are the test results for 9.0.0 20180504 (experimental) [trunk
> revision 259948]
> https://gcc.gnu.org/ml/gcc-testresults/2018-05/msg00644.html
>
> I don't know what's changed since this revision.

Ok, it looks like SEH is working for you (at least, I don't see the
test failures).  To confirm, SEH is enabled in this build?  If you
look at the logs, you see passes for the SEH tests?

Re: GCC 4.3.5 Status Report (2010-05-22)

[NightStrike]

On Mon, Jan 31, 2011 at 7:51 AM, Richard Guenther
 wrote:
> On Mon, Jan 31, 2011 at 3:43 AM, Dongsheng Song
>  wrote:
>> It's very simple (only for trunk, although it maybe more useful for
>> branches):
>
> Or simply put Last-Changed-Date into DATESTAMP, not the
> current date.

This has other benefits as well, since it means that the date in the
gcc version string becomes the date of the last actual revision,
instead of the date that the datestamp change is committed.

Re: GCC 4.3.5 Status Report (2010-05-22)

[NightStrike]

On Tue, Feb 1, 2011 at 5:31 AM, Richard Guenther
 wrote:
> On Mon, Jan 31, 2011 at 6:56 PM, Joseph S. Myers
>  wrote:
>> On Mon, 31 Jan 2011, NightStrike wrote:
>>
>>> On Mon, Jan 31, 2011 at 7:51 AM, Richard Guenther
>>>  wrote:
>>> > On Mon, Jan 31, 2011 at 3:43 AM, Dongsheng Song
>>> >  wrote:
>>> >> It's very simple (only for trunk, although it maybe more useful for
>>> >> branches):
>>> >
>>> > Or simply put Last-Changed-Date into DATESTAMP, not the
>>> > current date.
>>>
>>> This has other benefits as well, since it means that the date in the
>>> gcc version string becomes the date of the last actual revision,
>>> instead of the date that the datestamp change is committed.
>>
>> Not in the case where you have no datestamp changes for a month, say, then
>> some other change is committed, but a new datestamp change hasn't yet been
>> committed after that other change; then you have, for a limited period, a
>> compiler with a datestamp value long before the last commit.  (That's the
>> main case I can think of for not making snapshots if only DATESTAMP has
>> changed, rather than the simpler approach of omitting some DATESTAMP
>> updates and not making snapshots if nothing at all has changed.)
>
> The DATESTAMP change could also be in a post-commit hook (doing
> nothing if the date didn't change, of course).  No idea whether this
> is technically possible of course.
>
> Richard.
>

I can't find it right now, but I read something recently about using
hooks to put revision numbers inside source controlled files.

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Fri, Oct 8, 2010 at 12:06 PM, Jonathan Wakely  wrote:
> On 8 October 2010 16:56, NightStrike wrote:
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00624.html
>
> There are a lot of failures there, including quite a few tests which
> don't look platform-dependent.
>
> Can you send me the libstdc++-v3/testsuite/libstdc++.log so I can see
> what's failing?  A lot of them look locale-related, so could just be
> disabled if the platform doesn't support them.  Others are more
> concerning and shouldn't be failing on any platform.
>

Updated tests:
http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg02657.html

Re: Target library disabling at toplevel

[NightStrike]

On Tue, Mar 22, 2011 at 6:07 PM, Ian Lance Taylor  wrote:
> "Joseph S. Myers"  writes:
>
>> Why do a great many targets disable libgcj by default in the toplevel
>> configure.ac?
>
> I believe that it's just a hack: libgcj doesn't build on the target, but
> gcc/java does.  Disabling libgcj lets the gcc configure/make complete in
> a natural way.
>
> unsupported_languages is a clearly superior approach, but it postdates
> many of the cases in which libgcj is added to noconfigdirs.

In some cases, like for x86_64-w64-mingw (Win64), we can build gcj
fine, and we intend to support a java compiler.  However, at present,
we cannot build libgcj because the boehm-gc in the tree is several
years out of date.  Once Hans, or someone else with enough skill,
updates that, we can turn on libgcj.  Until then, we'd like to make
sure that building the compiler doesn't break.

Given how out of date certain dependencies are for libgcj, I would not
be surprised if other targets suffered the same fate.

Re: GCC 4.6.0 Released

[NightStrike]

On Tue, Mar 29, 2011 at 10:45 AM, Dave Korn  wrote:
> On 29/03/2011 15:32, Jakub Jelinek wrote:
>> On Tue, Mar 29, 2011 at 03:13:07PM +0100, Dave Korn wrote:
>>> On 28/03/2011 08:25, Jakub Jelinek wrote:
 The GNU Compiler Collection version 4.6.0 has been released.
>>>   Were there any changes (other than perhaps repackaging) after the second 
>>> RC
>>> (dated 20110321)?
>>
>> You can easily look at svn.
>
>  True but takes rather a long time on a cygwin host that's already running
> "make -j8 check"!  So I asked.  Apologies for minor laziness, hope you didn't
> feel /obligated/ to respond.

[Slightly off-topic]

How did you manage to run make check on cygwin with -j8 without
getting tons of spurious errors about all kinds of weird things?  I
can't run anything over -j1 on a 4 core machine.

Re: Installing multiple versions of GCC

[NightStrike]

On Mon, Aug 17, 2009 at 7:24 PM, Ian Lance Taylor wrote:
> Angelo Graziosi  writes:
>
>> Ian Lance Taylor ha scritto:
>>> Angelo Graziosi  writes:
>>>
 Is there a way to send libiberty.a where go the other libs (i.e
 /usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.4.1/, for example)?
>>>
>>> Really libiberty should not be installed at all by default.
>>
>> I suspected that. :-)
>>
>> Why, then, 'make install' installs 'libiberty.a'?
>
> I think it's a bug.

Has it ever not been that way?

r150960 changed ltmain.sh and broke the build

[NightStrike]

Dave,

You checked in r150960 here:
http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00642.html

This change affected ltmain.sh:
http://gcc.gnu.org/viewcvs/trunk/ltmain.sh?r1=150960&r2=150959&pathrev=150960

All of those changes to sed now make sed fail miserably on any mingw
host during the build:

libtool: link: 
/c/buildbot/vista64-mingw32/mingw-x86-x86/build/build/root/i686-w64-mingw32/bin/ar
rc .libs/libssp.a  ssp.o gets-chk.o memcpy-chk.o memmove-chk.o
mempcpy-chk.o memset-chk.o snprintf-chk.o sprintf-chk.o stpcpy-chk.o
strcat-chk.o strcpy-chk.o strncat-chk.o strncpy-chk.o vsnprintf-chk.o
vsprintf-chk.o
libtool: link: 
/c/buildbot/vista64-mingw32/mingw-x86-x86/build/build/root/i686-w64-mingw32/bin/ranlib
.libs/libssp.a
/bin/sed: -e expression #2, char 22: Invalid content of \{\}

Re: Anyone for slush?

[NightStrike]

On Sat, Sep 19, 2009 at 5:51 AM, Dave Korn
 wrote:
>
>  Should we perhaps, again?  I'm having trouble fixing one bootstrap-breaking
> bug because of a second one that's piled in on top of it right now; how is it
> for other targets?
>
>    cheers,
>      DaveK
>
>

What is slush?

Re: No c++0x threads using win32 threading model (with MinGW-w64)

[NightStrike]

On Tue, Sep 8, 2009 at 2:38 PM, Heiko Harders  wrote:
> Hello,
>
> (first of all: sorry to post this message to a second list, I've sent it to
> the wrong list at first)
>
> I am using g++ in MinGW-w64 running in a Windows environment. I'm especially
> interested in the c++0x threads because it allows standard cross-platform
> multi-threading.
>
> Unfortunately I didn't get this to work (using a very recent Mingw-w64
> snapshot that uses gcc 4.5.0). I did some research and I think I found out
> why. Perhaps somebody on this list could confirm this and/or answer some of
> the questions I have about the win32 threading model.
>
> First of all, the c++0x threads don't seem to work because in the `thread'
> header file the file `gthr.h' is included, which includes in turn some
> threading model specific files (like `gthr_posix.h'). While the header
> `gthr_win32.h' does exist, it is not included from `gthr.h'. The comments in
> `gthr.h' further mention support for several threading models, but the win32
> threading model is not amongst these. Am I looking in the right direction
> for reasons why the c++0x threads do not work with the win32 threading
> model?
>
> If the above is correct: is support for win32 c++0x threads being worked on
> at the moment? If that is the case, any indication when it will be in a
> usable state? What must be undertaken to implement this support?
>
> I hope somebody can give me some insight in these questions.
>
> Regards,
> Heiko
>

Adding Kai and gcc-help to this email.

Re: [gcc-as-cxx] enum conversion to int

[NightStrike]

On Mon, Jan 4, 2010 at 7:40 PM, Matt  wrote:
> Hi,
>
> I'm trying to fix some errors/warnings to make sure that gcc-as-cxx doesn't
> bitrot too much.

Wasn't that branch already merged to trunk?

Re: [gcc-as-cxx] enum conversion to int

[NightStrike]

On Tue, Jan 5, 2010 at 1:40 PM, Ian Lance Taylor  wrote:
> The gcc-in-cxx branch is no longer active.  All the work was merged to
> trunk, where it is available via --enable-build-with-cxx.

Is that option regularly tested?

Will it ever become the default?

Re: legitimate parallel make check?

[NightStrike]

On Tue, Mar 9, 2010 at 2:27 PM, IainS  wrote:
> I do build gmp/mpfr/mpc in-tree...

How?  Last I tried, it didn't work, as mpc used the system gmp/mpfr,
not the just-built in-tree versions.  Therefore, it's not really an
"in-tree" build, and you can't build on a system that doesn't already
have gmp/mpfr installed.  At least, that's what it was... does that
work now?

Re: GCC 4.5 Status Report (2010-03-15)

[NightStrike]

On Mon, Mar 15, 2010 at 12:18 PM, Richard Guenther  wrote:
> As maintainers do not care for P1 bugs in their maintainance area
> so will the release managers not consider them P1.

Probably not the best reason to downgrade a bug, eh?

Re: Application for maintainer role for mingw

[NightStrike]

On Mon, Dec 1, 2008 at 3:22 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> On Sat, 8 Nov 2008, Gerald Pfeifer wrote:
>> On Sat, 8 Nov 2008, Kai Tietz wrote:
>>> Hello Steering Committee,
>> I raised this on the steering committee...
>
> You've got the hat, Kai, congratulations!  Please update the MAINTAINERS
> file accordingly.
>
> Happy hacking,
> Gerald
>

Congratulations!!

Makefile support requested - enabling multilib for target

[NightStrike]

Currently, gcc doesn't support a multilib build for win64.  I have
been looking at how to do this, and have so far come up with a
beginning to a solution.  The work done thus far is part of this PR:

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

The current blocker is in building libgcc.  At some point in building
libgcc, it gets down to the final compilation.  In doing so, gcc is
invoked with a -B option pointing to the 32-bit lib directory instead
of the 64-bit lib directory.  This works for building the 32-bit
libgcc, but not the 64-bit default version.

>From what I can tell, the -B option pointing to the 32-bit lib
directory is in $(GCC_FOR_TARGET).  Is that where it's supposed to be?
 Is there a way to make gcc search the right directory first (or at
all)?  What steps am I missing for enabling the multilib build?

For reference, the system root and all of its libraries are installed into:

$prefix/$target/lib and $prefix/$target/lib64, the latter of course
being the 64-bit version of all the libs.

Re: Makefile support requested - enabling multilib for target

[NightStrike]

On Sun, Dec 21, 2008 at 2:38 PM, NightStrike  wrote:
> Currently, gcc doesn't support a multilib build for win64.  I have
> been looking at how to do this, and have so far come up with a
> beginning to a solution.  The work done thus far is part of this PR:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38294
>
> The current blocker is in building libgcc.  At some point in building
> libgcc, it gets down to the final compilation.  In doing so, gcc is
> invoked with a -B option pointing to the 32-bit lib directory instead
> of the 64-bit lib directory.  This works for building the 32-bit
> libgcc, but not the 64-bit default version.
>
> From what I can tell, the -B option pointing to the 32-bit lib
> directory is in $(GCC_FOR_TARGET).  Is that where it's supposed to be?
>  Is there a way to make gcc search the right directory first (or at
> all)?  What steps am I missing for enabling the multilib build?
>
> For reference, the system root and all of its libraries are installed into:
>
> $prefix/$target/lib and $prefix/$target/lib64, the latter of course
> being the 64-bit version of all the libs.
>

Ping

Re: Makefile support requested - enabling multilib for target

[NightStrike]

On Fri, Dec 26, 2008 at 5:07 PM, NightStrike  wrote:
> On Sun, Dec 21, 2008 at 2:38 PM, NightStrike  wrote:
>> Currently, gcc doesn't support a multilib build for win64.  I have
>> been looking at how to do this, and have so far come up with a
>> beginning to a solution.  The work done thus far is part of this PR:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38294
>>
>> The current blocker is in building libgcc.  At some point in building
>> libgcc, it gets down to the final compilation.  In doing so, gcc is
>> invoked with a -B option pointing to the 32-bit lib directory instead
>> of the 64-bit lib directory.  This works for building the 32-bit
>> libgcc, but not the 64-bit default version.
>>
>> From what I can tell, the -B option pointing to the 32-bit lib
>> directory is in $(GCC_FOR_TARGET).  Is that where it's supposed to be?
>>  Is there a way to make gcc search the right directory first (or at
>> all)?  What steps am I missing for enabling the multilib build?
>>
>> For reference, the system root and all of its libraries are installed into:
>>
>> $prefix/$target/lib and $prefix/$target/lib64, the latter of course
>> being the 64-bit version of all the libs.
>>
>
> Ping
>

Ping

Re: proposal for improved management bugzilla priorities/release criteria

[NightStrike]

On Fri, Feb 6, 2009 at 11:30 AM, Paolo Bonzini  wrote:
> The current system for managing bugzilla priorities has a major problem,
> in that it does not identify bugs that reasonably cannot be fixed before
> the release.
>
> The current set of priorities is in practice like this:
>
> - P1: most wrong code bugs, and other absolutely blocking problems
> - P2: problems worth a look on important platforms
> - P3: uncategorized
> - P4: problems worth a look on less important platforms
> - P5: other
>
> The problem with this set is that while P1 bugs will absolutely be fixed
> before the release (and backported usually), P2 bugs are a one-catch-all
> group for everything else that's worth looking at.  It is impossible to
> distinguish stuff that will probably be fixed before the release (and
> presumably backported to all branches), and what instead requires new
> stage1/stage2 material.
>
> As a result, the release criteria we have are not really a measure of
> the quality of the release, and especially are not really a measure of
> the work being done towards a release.
>
> I propose two solutions to this problem.
>
> - The more conservative one is to use more aggressively the release
> milestone field.  Hard-to-fix bugs would be left as P2, but bumped to
> the next major release at the beginning of stage 3.
>
> Advantages: no need for churn in the bug database---very easy to implement
> Disadvantages: the milestone field is not visible in search lists (maybe
> this can be changed)?
>
> - Alternatively, we could add a new priority "P--" for uncategorized
> bugs, and split P2/P3 like this: P2 bugs will be fixed in stage 3/4, P3
> bugs will most likely be postponed to stage 1/2.
>
> Advantages: quicker impression from the bug searches, especially during
> bug triage
> Disadvantages: need to rethink bugzilla queries
>
>
> I think any of these two approaches would provide a serious added value
> to judging a release quality.  Meeting the release criteria ("no more
> than 50 P2 regressions") in the past included the release managers
> downgrading bugs from P2 to P4, which is in my opinion cheating.  In the
> proposed scheme, this would be less necessary, because the release
> criteria could take into account a broader view, such as respectively
> for the two approaches:
>
> - At most 60 P2 regressions, of which at most 15 should have release
> milestone 4.4.0.
>
> - No more than 15 P2 regressions and 45 P3 regressions.
>
> Any opinions?
>
> Paolo
>
>

You could also make use of the severity field.  "blockers" must be
fixed, "enhancements" can wait, etc etc.

Re: GCC 4.4.0 Status Report (2009-03-13)

[NightStrike]

On Fri, Mar 13, 2009 at 1:58 PM, Joseph S. Myers
 wrote:
> Given the SC request we need to stay in Stage 4 rather than trying to work
> around it.

What if GCC went back to stage 3 until the issue is resolved, thus
opening the door for a number of stage3-type patches that don't affect
1) licensing and 2) plugin frameworks, but are merely bug fixes which
would have long been shaken out by now.

Re: GCC 4.4.0 Status Report (2009-03-13)

[NightStrike]

On Sun, Mar 15, 2009 at 2:35 PM, Dominique Dhumieres  wrote:
> NightStrike wrote:
>> What if GCC went back to stage 3 until the issue is resolved, thus
>> opening the door for a number of stage3-type patches that don't affect
>> 1) licensing and 2) plugin frameworks, but are merely bug fixes which
>> would have long been shaken out by now.
>
> It would be indeed nice, but it is probably a too obvious solution.

Too obvious?

Re: Proposed gfortran development branch

[NightStrike]

On Thu, Mar 19, 2009 at 3:06 PM, Steve Kargl
 wrote:
>
> On Thu, Mar 19, 2009 at 07:46:37PM +0100, Toon Moene wrote:
> >
> > I agree about the bisecting-in-case-of-bugs issue.
> >
> > However, what I see happening in practice is that all GCC developers
> > keep on doing their development work on branches - only the gfortran
> > developers are left out, because they do not have a branch.
> >
> > Of course we can create branches for all the subprojects that are
> > pending on the creation of a 4.4 branch and freeing up trunk - it just
> > doesn't seem very efficient to us.
> >
> > Of course I pleaded with the FSF (on the Steering Committee mailing list
> > *and* the gcc list) for speed in the case of the 4.4 branch - in vain.
> >
> > We might be heading for a fork a la the EGCS fork - and I don't like it.
> >  It took a lot of effort (I was part of the EGCS cabal and I didn't
> > even do a lot of that foot-work).
> >
>
> "Those who do not learn from history are doomed to repeat it."
> George Santayana
>
> http://home.schmorp.de/egcs.html
>
>  Why are we doing this?  It's become increasingly clear in the course
>  of hacking events that the FSF's needs for gcc2 are at odds with the
>  objectives of many in the community who have done lots of hacking and
>  improvment over the years.  GCC is part of the FSF's publicity for the
>  GNU project, as well as being the GNU system's compiler, so stability
>  is paramount for them.  On the other hand, Cygnus, the Linux folks,
>  the pgcc folks, the Fortran folks and many others have done
>  development work which has not yet gone into the GCC2 tree despite
>  years of efforts to make it possible.
>
> This can be amended by replacing "so stability is paramount for them"
> with "so utopian philosophical pander is paramount for them"
>
> --
> Steve

http://gcc.gnu.org/ml/gcc/2009-03/msg00439.html

Re: GCC 4.4.0 Status Report (2009-03-13)

[NightStrike]

On Mon, Mar 16, 2009 at 6:10 AM, Paolo Bonzini  wrote:
> NightStrike wrote:
>> On Fri, Mar 13, 2009 at 1:58 PM, Joseph S. Myers
>>  wrote:
>>> Given the SC request we need to stay in Stage 4 rather than trying to work
>>> around it.
>>
>> What if GCC went back to stage 3 until the issue is resolved, thus
>> opening the door for a number of stage3-type patches that don't affect
>> 1) licensing and 2) plugin frameworks, but are merely bug fixes which
>> would have long been shaken out by now.
>
> No, not at all.  The only benefit we're having from this is that GCC 4.4
> should be quite stable already in GCC 4.4.0, let's not destroy this one too.

Stage 3 is bug fix only, so I'm not sure if you agree with me or
not  I was advocating that we take the time to fix more bugs that
are new for 4.4 and so aren't regressions.  We have several that are
in the win64 port that we will have to support for a while in our
first official release.

Re: Deprecating Itanium1 for GCC 4.4

[NightStrike]

On Fri, Mar 20, 2009 at 7:10 AM, Steven Bosscher  wrote:
> On Fri, Mar 20, 2009 at 10:31 AM, Andi Kleen  wrote:
>> Steven Bosscher  writes:
>>
>>>      case OPT_mfixed_range_:
>>> @@ -5245,6 +5247,13 @@ ia64_handle_option (size_t code, const char *arg,
>>>         if (!strcmp (arg, processor_alias_table[i].name))
>>>           {
>>>             ia64_tune = processor_alias_table[i].processor;
>>> +           if (ia64_tune == PROCESSOR_ITANIUM
>>> +               && ! warned_merced_deprecated)
>>> +             {
>>> +               inform ("value %<%s%> for -mtune= switch is deprecated", 
>>> arg);
>>> +               inform ("GCC 4.4 is the last release with Itanium1 
>>> support");
>>
>> "... with Itanium1 tuning support"?
>>
>> I assume it will be still possible to generate executables that work
>> there, just not tuned. iirc there are new instructions in I2, but I
>> assume you don't plan to drop the code to not generate those, just the
>> scheduling descriptions.
>
> I plan to drop both.

So because Itanium1 has fallen into disuse, you are dropping support
for Itanium2?  Or have I misread this?

Re: GCC 4.4.0 Status Report (2009-03-13)

[NightStrike]

On Fri, Mar 20, 2009 at 7:07 PM, Richard Kenner
 wrote:
>> > The  GCC maintainers work on behalf of the FSF and in some matters defer
>> > to the FSF.  It's that simple.
>>
>> Yes, but it's not written anywhere that release and especially branching
>> policies are one of this matters.
>
> The matters to which we defer to the FSF are any matters that they *ask*
> us to!  They own the code.  If RMS, for some reason, decides that he doesn't
> like the phrasing of a comment somewhere, we have to either convince RMS
> he's wrong or change the comment.
>
> As a practical matter, the FSF *delegates* most of their responsibilities
> to the maintainer of the package, but they can undo that delegation as to
> any matter any time they want.
>

By this, FSF == RMS ?

Re: GCC 4.4.0 Status Report (2009-03-13)

[NightStrike]

On Mon, Mar 23, 2009 at 2:38 AM, Joe Buck  wrote:
> GCC uses are the ones developed in the egcs days.  Remember the old
> days when the location of the development tree and the snapshots was
> a secret, and people were threatened with banning if they let it out?

Are you serious?  Why would it be handled that way?

Re: GCC 4.4.0 Status Report (2009-03-13)

[NightStrike]

On Mon, Mar 23, 2009 at 2:32 AM, Joe Buck  wrote:
> one.  RMS wanted to have gcc use machines administered by the FSF; we
> pushed back.  gcc.gnu.org is sourceware.org.  We did agree that we

A little off-topic, but why *is* gcc on sourceware.org?

ICE during build of libobjc

[NightStrike]

/bin/sh ./libtool --mode=compile
/home/nightstrike/a/build/gcc/obj/./gcc/xgcc
-B/home/nightstrike/a/build/gcc/obj/./gcc/
-L/home/nightstrike/a/build/gcc/obj/x86_64-w64-mingw32/winsup/mingw
-L/home/nightstrike/a/build/gcc/obj/x86_64-w64-mingw32/winsup/w32api/lib
-isystem /home/nightstrike/a/build/gcc/gcc/winsup/mingw/include
-isystem /home/nightstrike/a/build/gcc/gcc/winsup/w32api/include
-B/home/nightstrike/a/build/root/x86_64-w64-mingw32/bin/
-B/home/nightstrike/a/build/root/x86_64-w64-mingw32/lib/ -isystem
/home/nightstrike/a/build/root/x86_64-w64-mingw32/include -isystem
/home/nightstrike/a/build/root/x86_64-w64-mingw32/sys-include-c
-I. -I/home/nightstrike/a/build/gcc/gcc/libobjc   -g -O2 -W -Wall
-Wwrite-strings -Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS
-fno-strict-aliasing -fexceptions
-I/home/nightstrike/a/build/gcc/gcc/libobjc/objc
-I/home/nightstrike/a/build/gcc/gcc/libobjc/../gcc
-I/home/nightstrike/a/build/gcc/gcc/libobjc/../gcc/config
-I../.././gcc -I/home/nightstrike/a/build/gcc/gcc/libobjc/../include
/home/nightstrike/a/build/gcc/gcc/libobjc/archive.c
libtool: compile:  /home/nightstrike/a/build/gcc/obj/./gcc/xgcc
-B/home/nightstrike/a/build/gcc/obj/./gcc/
-L/home/nightstrike/a/build/gcc/obj/x86_64-w64-mingw32/winsup/mingw
-L/home/nightstrike/a/build/gcc/obj/x86_64-w64-mingw32/winsup/w32api/lib
-isystem /home/nightstrike/a/build/gcc/gcc/winsup/mingw/include
-isystem /home/nightstrike/a/build/gcc/gcc/winsup/w32api/include
-B/home/nightstrike/a/build/root/x86_64-w64-mingw32/bin/
-B/home/nightstrike/a/build/root/x86_64-w64-mingw32/lib/ -isystem
/home/nightstrike/a/build/root/x86_64-w64-mingw32/include -isystem
/home/nightstrike/a/build/root/x86_64-w64-mingw32/sys-include -c -I.
-I/home/nightstrike/a/build/gcc/gcc/libobjc -g -O2 -W -Wall
-Wwrite-strings -Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS
-fno-strict-aliasing -fexceptions
-I/home/nightstrike/a/build/gcc/gcc/libobjc/objc
-I/home/nightstrike/a/build/gcc/gcc/libobjc/../gcc
-I/home/nightstrike/a/build/gcc/gcc/libobjc/../gcc/config
-I../.././gcc -I/home/nightstrike/a/build/gcc/gcc/libobjc/../include
/home/nightstrike/a/build/gcc/gcc/libobjc/archive.c  -DDLL_EXPORT
-DPIC -o .libs/archive.o
In file included from
/home/nightstrike/a/build/gcc/gcc/libobjc/objc/runtime.h:38,
 from /home/nightstrike/a/build/gcc/gcc/libobjc/archive.c:26:
/home/nightstrike/a/build/gcc/gcc/libobjc/objc/objc-api.h:365:
internal compiler error: tree check: expected function_decl, have
var_decl in handle_dll_attribute, at tree.c:4172
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [archive.lo] Error 1
make[2]: Leaving directory
`/home/nightstrike/a/build/gcc/obj/x86_64-w64-mingw32/libobjc'
make[1]: *** [all-target-libobjc] Error 2
make[1]: Leaving directory `/home/nightstrike/a/build/gcc/obj'
make: *** [all] Error 2
nightstr...@gcc16:~/a/build/gcc/obj$

Re: diagnostics-branch merged into mainline

[NightStrike]

On Fri, Jun 12, 2009 at 9:49 PM, Aldy Hernandez wrote:
> On Sat, Jun 13, 2009 at 01:51:42AM +0100, Dave Korn wrote:
>> Aldy Hernandez wrote:
>> > Hi folks.
>> >
>> > At the last minute Ian got a patch in that touched a bunch of places
>> > that I was also changing.  I resolved the conflicts, and bootstrapped
>> > and tested for C and C++.  Unfortunately, people kept committing stuff
>> > that caused conflicts, so I broke down and committed after a minor C/C++
>> > bootstrap.
>>
>>   Did you tell anyone that you were merging a branch to mainline?  I honestly
>> didn't see an announcement.  (Is there any reason why you shouldn't have
>> requested a freeze?)
>
> The branch was approved by a GWP, I didn't know you needed to make a
> special announcement.
>
> I will be fixing any regressions shortly.
>

Your committal of r148442 has caused an ICE during the build of libgcc
for targetting win64:

../../../gcc/libgcc/../gcc/libgcc2.c:2054:1: warning: no previous
prototype for ‘getpagesize’
../../../gcc/libgcc/../gcc/libgcc2.c:2064:1: warning: no previous
prototype for ‘mprotect’
../../../gcc/libgcc/../gcc/libgcc2.c:1:0: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [_divdi3.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [all-target-libgcc] Error 2
make: *** [all] Error 2

Re: diagnostics-branch merged into mainline

[NightStrike]

On Mon, Jun 15, 2009 at 9:52 AM, Aldy Hernandez wrote:
>> Your committal of r148442 has caused an ICE during the build of libgcc
>> for targetting win64:
>
> I have this pending patch, which may or may not fix this.
>
> http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01113.html
>
> Can you try and see if it fixes it?  Otherwise, can you find out where
> the compiler is dying so I can fix this.
>
> Aldy
>

I tried applying your patch to HEAD, but it looks like it already is.
So, using r148494, we now don't get to the libgcc part even:

../../gcc/gcc/config/i386/winnt.c: In function ‘i386_pe_encode_section_info’:
../../gcc/gcc/config/i386/winnt.c:288: error: too few arguments to
function ‘make_decl_one_only’
make[1]: *** [winnt.o] Error 1
make: *** [all-gcc] Error 2

Re: diagnostics-branch merged into mainline

[NightStrike]

On Mon, Jun 15, 2009 at 2:05 PM, Aldy Hernandez wrote:
>> ../../gcc/gcc/config/i386/winnt.c: In function ?i386_pe_encode_section_info?:
>> ../../gcc/gcc/config/i386/winnt.c:288: error: too few arguments to
>> function ?make_decl_one_only?
>
> make_decl_one_only expects one argument, and that's what's being fed.
> Could you please debug this and find out what's going on?
>

I don't really know how to.  Hopefully, Kai can help (I have him on the CC list)

Re: diagnostics-branch merged into mainline

[NightStrike]

On Mon, Jun 15, 2009 at 2:18 PM, NightStrike wrote:
> On Mon, Jun 15, 2009 at 2:05 PM, Aldy Hernandez wrote:
>>> ../../gcc/gcc/config/i386/winnt.c: In function 
>>> ?i386_pe_encode_section_info?:
>>> ../../gcc/gcc/config/i386/winnt.c:288: error: too few arguments to
>>> function ?make_decl_one_only?
>>
>> make_decl_one_only expects one argument, and that's what's being fed.
>> Could you please debug this and find out what's going on?
>>
>
> I don't really know how to.  Hopefully, Kai can help (I have him on the CC 
> list)
>

With the decl fix, everything builds again.  Thanks, all!

GCC and boehm-gc

[NightStrike]

Given the recent issues with libffi being so drastically out of synch
with upstream, I was curious about boehm-gc and how that is handled.
In getting gcj to work on Win64, the next step is boehm-gc now that
libffi works just fine.  However, the garbage collector is in terrible
shape and will need a bit of work.  Do we send those fixes here to
GCC, or to some other project?  Who handles it?  How is the synching
done compared to other external projects?

Re: GCC and boehm-gc

[NightStrike]

On Thu, Jun 18, 2009 at 12:27 PM, David Daney wrote:
> NightStrike wrote:
>>
>> Given the recent issues with libffi being so drastically out of synch
>> with upstream, I was curious about boehm-gc and how that is handled.
>> In getting gcj to work on Win64, the next step is boehm-gc now that
>> libffi works just fine.  However, the garbage collector is in terrible
>> shape and will need a bit of work.  Do we send those fixes here to
>> GCC, or to some other project?  Who handles it?  How is the synching
>> done compared to other external projects?
>>
>
> Your analysis of the situation is essentially correct.
>
> Hans (now CCed) is good about merging changes to the upstream sources,
> but we haven't updated GCC/libgcj's copy in quite some time.  A
> properly motivated person would have to import a newer version of the
> GC checking that all GCC local changes were either already merged, or
> if not port them to the new GC (those that are not upstream should
> then be evaluated to see if they should be).

So it seems that boehm-gc is in the exact state as libffi.

This is yet another example of why we shouldn't duplicate sources...

Hans, would you be willing to bring boehm-gc up to speed so that we
can start getting it to work for Win64?  Without this, we obviously
cannot add gcj to our list of supported compilers.

Re: GCC and boehm-gc

[NightStrike]

On Thu, Jun 18, 2009 at 12:58 PM, Andrew Haley wrote:
> NightStrike wrote:
>> On Thu, Jun 18, 2009 at 12:27 PM, David Daney 
>> wrote:
>>> NightStrike wrote:
>>>> Given the recent issues with libffi being so drastically out of synch
>>>> with upstream, I was curious about boehm-gc and how that is handled.
>>>> In getting gcj to work on Win64, the next step is boehm-gc now that
>>>> libffi works just fine.  However, the garbage collector is in terrible
>>>> shape and will need a bit of work.  Do we send those fixes here to
>>>> GCC, or to some other project?  Who handles it?  How is the synching
>>>> done compared to other external projects?
>>>>
>>> Your analysis of the situation is essentially correct.
>>>
>>> Hans (now CCed) is good about merging changes to the upstream sources,
>>> but we haven't updated GCC/libgcj's copy in quite some time.  A
>>> properly motivated person would have to import a newer version of the
>>> GC checking that all GCC local changes were either already merged, or
>>> if not port them to the new GC (those that are not upstream should
>>> then be evaluated to see if they should be).
>>
>> So it seems that boehm-gc is in the exact state as libffi.
>
> No, it's not.  The problem with libffi is that it was updated in gcc and
> upstream; that is much less of a problem with boehm-gc.

That's what David just described -- that there are both GCC local
changes and upstream changes.

Regardless, someone with the knowledge and background needs to do this merge.

Re: GCC and boehm-gc

[NightStrike]

On Thu, Jun 18, 2009 at 2:02 PM, Andrew Haley wrote:
> NightStrike wrote:
>> Given the recent issues with libffi being so drastically out of synch
>> with upstream, I was curious about boehm-gc and how that is handled.
>> In getting gcj to work on Win64, the next step is boehm-gc now that
>> libffi works just fine.  However, the garbage collector is in terrible
>> shape and will need a bit of work.  Do we send those fixes here to
>> GCC, or to some other project?  Who handles it?  How is the synching
>> done compared to other external projects?
>
> When people post patches I always send ask them to send to the
> g...@napali.hpl.hp.com list.

Does that mean that you work on this, too?  Can you handle getting
everything in the gcc trunk to a point at which we can start working?
I'd greatly appreciate it.

Re: GCC and boehm-gc

[NightStrike]

On Thu, Jun 18, 2009 at 5:25 PM, Hans Boehm wrote:
> What has been a problem is that while the 6.8 -> 7.0 changes cleaned
> up the code substantially, and a lot of contributed patches since then
> have done a lot more of that, that step also introduced a fair amount of
> instability.  I think we're largely over that now.  But 7.1 is fairly old,
> so the merge would either have to use the CVS trunk or wait for 7.2 (which
> I'm trying to find time to get out real soon now).

Can you bring gcc up to speed with cvs HEAD?

Re: Phase 1 of gcc-in-cxx now complete

[NightStrike]

On Sat, Jun 27, 2009 at 6:25 PM, Ian Lance Taylor wrote:
> Richard Guenther  writes:
>
>> All that above said - do you expect us to carry both vec.h (for VEC in
>> GC memory) and std::vector (for VECs in heap memory) (and vec.h
>> for the alloca trick ...)?  Or do you think we should try to make the GTY
>> machinery C++ aware and annotate the standard library (ick...)?
>
> I expect us to write a GC allocator, and use that with std::vector.
> This will require more hooks into the GC code, but I think it is doable.

I'm curious about this.  I thought c++ wasn't a garbage collected
language on purpose.  Why does GCC have one?  What purpose does it
serve?  I'm not suggesting otherwise, but just trying to learn more
about the way things are done.

Re: Can't run gfortran testsuite

[NightStrike]

On Thu, Jul 9, 2009 at 2:52 PM, Steve
Kargl wrote:
> On Thu, Jul 09, 2009 at 12:34:00PM -0400, NightStrike wrote:
>> I have been trying to run the gfortran testsuite for a while now, and
>> it keeps falling apart.  Dominiq tried to find a revision that might
>> attribute to it, and though r147421 might have something to do with
>> it:  http://gcc.gnu.org/viewcvs?view=rev&revision=147421
>>
>> These are the errors I get that prevent the testsuite from running
>> more than a few thousand tests:
>>
>> ERROR: tcl error sourcing
>> /dev/shm/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/dg.exp.
>> ERROR: can't read "status": no such variable
>> ERROR: tcl error sourcing
>> /dev/shm/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/gomp/gomp.exp.
>> ERROR: torture-init: torture_without_loops is not empty as expected
>> ERROR: tcl error sourcing
>> /dev/shm/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/vect/vect.exp.
>> ERROR: torture-init: torture_without_loops is not empty as expected
>> ERROR: tcl error sourcing
>> /dev/shm/build/gcc-svn/gcc/gcc/testsuite/gfortran.fortran-torture/compile/compile.exp.
>> ERROR: torture-init: torture_without_loops is not empty as expected
>> ERROR: tcl error sourcing
>> /dev/shm/build/gcc-svn/gcc/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp.
>> ERROR: torture-init: torture_without_loops is not empty as expected
>
> This appears to be a general testsuite issue.  You try pinging Janis
> on IRC.  She may have an idea on the cause.

I'm also emailing the general gcc list about this.  Does anyone have
any idea on how to handle this situation?

Re: Can't run gfortran testsuite

[NightStrike]

On Fri, Jul 10, 2009 at 12:14 PM, NightStrike wrote:
> On Thu, Jul 9, 2009 at 2:52 PM, Steve
> Kargl wrote:
>> On Thu, Jul 09, 2009 at 12:34:00PM -0400, NightStrike wrote:
>>> I have been trying to run the gfortran testsuite for a while now, and
>>> it keeps falling apart.  Dominiq tried to find a revision that might
>>> attribute to it, and though r147421 might have something to do with
>>> it:  http://gcc.gnu.org/viewcvs?view=rev&revision=147421
>>>
>>> These are the errors I get that prevent the testsuite from running
>>> more than a few thousand tests:
>>>
>>> ERROR: tcl error sourcing
>>> /dev/shm/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/dg.exp.
>>> ERROR: can't read "status": no such variable
>>> ERROR: tcl error sourcing
>>> /dev/shm/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/gomp/gomp.exp.
>>> ERROR: torture-init: torture_without_loops is not empty as expected
>>> ERROR: tcl error sourcing
>>> /dev/shm/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/vect/vect.exp.
>>> ERROR: torture-init: torture_without_loops is not empty as expected
>>> ERROR: tcl error sourcing
>>> /dev/shm/build/gcc-svn/gcc/gcc/testsuite/gfortran.fortran-torture/compile/compile.exp.
>>> ERROR: torture-init: torture_without_loops is not empty as expected
>>> ERROR: tcl error sourcing
>>> /dev/shm/build/gcc-svn/gcc/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp.
>>> ERROR: torture-init: torture_without_loops is not empty as expected
>>
>> This appears to be a general testsuite issue.  You try pinging Janis
>> on IRC.  She may have an idea on the cause.
>
> I'm also emailing the general gcc list about this.  Does anyone have
> any idea on how to handle this situation?
>

More info:

ERROR: tcl error sourcing
/home/nightstrike/work/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/dg.exp.
ERROR: can't read "status": no such variable
while executing
"list $status [lindex $result 1]"
(procedure "gfortran_load" line 10)
invoked from within
"${tool}_load $output_file"
(procedure "saved-dg-test" line 228)
invoked from within
"saved-dg-test 
/home/nightstrike/work/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/char_bounds_check_fail_1.f90
{ -O0 } { -pedantic-errors}"
("eval" body line 1)
invoked from within
"eval saved-dg-test $args "
(procedure "dg-test" line 9)
invoked from within
"dg-test $test $flags ${default-extra-flags}"
(procedure "gfortran-dg-runtest" line 27)
invoked from within
"gfortran-dg-runtest [lsort \
   [glob -nocomplain $srcdir/$subdir/*.\[fF\]{,90,95,03,08} ] ]
$DEFAULT_FFLAGS"
(file 
"/home/nightstrike/work/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/dg.exp"
line 32)
invoked from within
"source 
/home/nightstrike/work/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/dg.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source
/home/nightstrike/work/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/dg.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
Running 
/home/nightstrike/work/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/gomp/gomp.exp
...
ERROR: tcl error sourcing
/home/nightstrike/work/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/gomp/gomp.exp.
ERROR: torture-init: torture_without_loops is not empty as expected
while executing
"error "torture-init: torture_without_loops is not empty as expected""
invoked from within
"if [info exists torture_without_loops] {
error "torture-init: torture_without_loops is not empty as expected"
}"
(procedure "torture-init" line 4)
invoked from within
"torture-init"
(procedure "gfortran-dg-runtest" line 5)
invoked from within
"gfortran-dg-runtest [lsort \
   [find $srcdir/$subdir *.\[fF\]{,90,95,03,08} ] ] " -fopenmp""
(file 
"/home/nightstrike/work/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/gomp/gomp.exp"
line 32)
invoked from within
"source 
/home/nightstrike/work/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/gomp/gomp.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source
/home/nightstrike/work/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/gomp/gomp.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
Running 
/home/nightstrike/work/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/graphite/graphite.exp
...
Running 
/home/nightstrike/work/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/vect/vect.exp
...
ERROR: tcl error

Re: RM Q&A Session on May 27th

[NightStrike]

On Tue, May 18, 2010 at 11:36 PM, Mark Mitchell  wrote:
> Several people have asked that there be a forum for asking questions of
> and providing feedback to the GCC RMs.  Since this is of course a very
> widely distributed community, the best medium for this seems to be an
> IRC chat.  To that end, I'll be hosting a 1-hour session on May 27th at
> 9:00 AM Pacific.  I'm hoping that Jakub, Joseph, and Richard will also
> be able to participate.
>
> If anyone would like to volunteer to set up a channel and/or moderate
> the chat itself, please let me know.  Otherwise, I'll do that.
>
> For those who do not find that a convenient time, please add questions to:
>
>  http://gcc.gnu.org/wiki/Release%20Manager%20Q%26A
>
> We'll try to give somewhat intelligent answers to those questions, as
> well as to those asked live.
>
> Thanks!
>
> --
> Mark Mitchell
> CodeSourcery
> m...@codesourcery.com
> (650) 331-3385 x713
>

Can you just do it in #gcc on oftc?

Re: toplevel out of sync

[NightStrike]

On Tue, May 25, 2010 at 4:38 PM, DJ Delorie  wrote:
>
>> Also, I would like to make a new policy that from now on patches to
>> the toplevel cannot be committed by anyone who doesn't have write
>> access to both gcc and src.  Is there any agreement on this?
>
> Our current policy certainly doesn't work, either we come up with
> something that will, or abandon the whole idea and let chaos reign.

Ideas:
Switch to svn and use svn:externals to link the two repos
Make binutils be part of the gcc repository to begin with
Lock the files on the binutils side and only allow a specific user to
commit; Make that user a bot that's hooked onto the gcc commit

Patch pinging

[NightStrike]

Recently on #gcc, I have been conversing with several others on the
topic of patches lost in the tides of the gcc-patches mailing list.  I
flagged Jeff Downs' recent message as an example of a patch that has
been waiting since November
(http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00177.html).  I then
volunteered to be a patch pinger, to watch the mailing list and ping
patches that don't get responses.  I currently do this for Win64 work
anyway, so I already read most of the mailing list as it is.

To do this between Kai and myself for Win64, he posts a commit message
at the end of the thread (Committed rev ###) to signify to me to
delete the thread from my inbox.  Every so often, I ask him about any
threads that haven't been addressed.  I offered to Ian to do the same
thing for the whole mailing list if we can make it a policy that
people who commit changes do what Kai is doing so that it's clear that
the thread is done with.  I don't mind throwing a few pings down, and
I already have the whole ML tagged with a gmail label.

Re: Patch pinging

[NightStrike]

On Wed, Jun 2, 2010 at 3:17 PM, Diego Novillo  wrote:
> On Wed, Jun 2, 2010 at 14:09, NightStrike  wrote:
>
>> threads that haven't been addressed.  I offered to Ian to do the same
>> thing for the whole mailing list if we can make it a policy that
>> people who commit changes do what Kai is doing so that it's clear that
>> the thread is done with.  I don't mind throwing a few pings down, and
>> I already have the whole ML tagged with a gmail label.
>
> Seems like a good idea to me.  I do not usually read the list every
> day (or every week some times), so if a patch is in my area and I had
> not been directly CC'd, it can take me up to 2 weeks to get to it.
>
> Most of the areas I'm on had good coverage (particularly since I share
> much with richi who is a very prolific patch reviewer), so it's not
> too much of a problem.

Ok.  Is one person responding enough for me to start doing that?  I
don't know how this sort of approval / acceptance process works for
GCC.

Re: Patch pinging

[NightStrike]

On Mon, Jun 7, 2010 at 1:01 PM, Eric Botcazou  wrote:
>> Recently on #gcc, I have been conversing with several others on the
>> topic of patches lost in the tides of the gcc-patches mailing list.  I
>> flagged Jeff Downs' recent message as an example of a patch that has
>> been waiting since November
>> (http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00177.html).  I then
>> volunteered to be a patch pinger, to watch the mailing list and ping
>> patches that don't get responses.  I currently do this for Win64 work
>> anyway, so I already read most of the mailing list as it is.
>
> I'd avoid sending random "Ping.. was this committed" messages though, that's
> rather annoying.  The gcc-cvs archives are http://gcc.gnu.org/ml/gcc-cvs/

Annoying or not, I wasn't offering to sift through svn commit logs.
It's very trivial for me to read through a mailing list that I already
read, and scan for messages that say "committed to branch B at
revision R."  It's a lot more complicated to find out if something has
been committed myself, for every single patch out there, when the
committer already knows and can send his followup message saying that
the patch went in.  Ideally, after a day of this, people will start
sending such messages to effectively close threads, and then you'll
see very few messages from me.

Re: Patch pinging

[NightStrike]

On Mon, Jun 7, 2010 at 4:23 PM, Joern Rennecke
 wrote:
> Quoting NightStrike :
>
>> Annoying or not, I wasn't offering to sift through svn commit logs.
>
> How about requiring that a patch should have an associated open PR with the
> patch keyword to be considered for pinging.
> Then you can do a bugzilla search for all open PRs with the patch keyword.
>

I suggested that a long time ago on irc, but was brutally shot down
for it.  Apparently, most people hate bugzilla :(  To be clear, what I
suggested was that every patch should have a PR.  There is way too
much duplication of purpose between bugzilla, gcc-bugs, and
gcc-patches.

TBH, I was sort of doing this manually to start for Jakub's patches
that had a PR with "Fixed" at the bottom of them.  I didn't ping on
any of those.  That was extra work, but it was doable.

Reading gcc-cvs, or ChangeLogs, or other things like that is just way
too much time.

Re: Patch pinging

[NightStrike]

On Tue, Jun 8, 2010 at 3:53 AM, Eric Botcazou  wrote:
>> Reading gcc-cvs, or ChangeLogs, or other things like that is just way
>> too much time.
>
> What about writing a small script that parses the main ChangeLogs?  They are
> supposed to be uniformly formatted.  And ping messages shouldn't contain all
> the junk of previous messages, just the ChangeLog (and optionally the URL).
>
> --
> Eric Botcazou
>

Are you volunteering to write that small script?

Re: Patch pinging

[NightStrike]

On Mon, Jun 7, 2010 at 8:34 PM, Paolo Carlini  wrote:
> On 06/08/2010 02:20 AM, Manuel López-Ibáńez wrote:
>> Perhaps NightStrike can fine-tune his approach.
> By the way, I wonder how many contributors can even think taking
> seriously a message coming from "NightStrike". Not me, for sure...
>
> Paolo.
>

That's just being mean.  This is 2010.  People use aliases.  Would it
make you happier if my alias was Neil Samson instead of NightStrike?
Is it any more "real"?

Look, you don't want me to be here... fine.  I get it.  Enough is
enough already.  Technical disagreements are one thing.  Personal
attacks on me are just juvenile.

Re: Patch pinging

[NightStrike]

On Tue, Jun 8, 2010 at 7:03 PM, Martin Guy  wrote:
> On 6/8/10, NightStrike  wrote:
>> Are you volunteering to write that small script?
>
> DUnno, are you volunteering to write that small script?

Sorry, no :(

> You're the only one here actually volunteering a forwardgoing
> commitment of their time here to improve GCC's development in this
> way, it seems (and mostly just getting vilified for it, for using a
> bizarre camelcase name!)

Thanks for noticing :)

> What I expected to happen was that you would start doing whta you
> envision should happen by hand, and would then get so bored at doing
> it that out of laziness you'd automate it somehow. :)

I was thinking of ways to make it a little easier.  What I proposed
was really not all that time consuming, though.

> Still, we'll see...

Apparently not :(

Re: Patch pinging

[NightStrike]

On Mon, Jun 14, 2010 at 12:05 PM, Manuel López-Ibáñez
 wrote:
> What we would need is some way to detect that patches have been
> committed. Otherwise that list will grow uncontrollably very fast.

Imagine that :)

Re: Patch pinging

[NightStrike]

On Sun, Jun 27, 2010 at 11:35 PM, David Edelsohn  wrote:
> On Sun, Jun 27, 2010 at 3:45 PM, Manuel López-Ibáñez
>  wrote:
>
>> I do believe that it is odd that one of the most important
>> free-software projects in terms of widespread use, a free-software
>> project that has a technical quality comparable and often superior to
>> the closed-source counterparts, is still using a bugzilla version that
>> reached end-of-life more than 2 years ago.
>>
>> I didn't feel that was right to ask for volunteers again to do
>> something, when there have been volunteers and they have been ignored.
>> It is true that frustration does not justify an outburst, specially
>> since I am not volunteering anymore.
>>
>> Your last two sentences are definitely right. I don't have anything
>> else new to propose. It is a difficult situation. Good luck. Sorry for
>> the noise.
>
> Manuel,
>
> As you mention, GCC is one of the most important Free Software
> projects.  We rely on the infrastructure, like Bugzilla and
> Subversion.  While we appreciate someone volunteering to upgrade the
> infrastructure, that someone needs to be experienced and
> knowledgeable.  It would not help the project to have a failed
> conversion or partial conversion or a lack of future support.  The
> current infrastructure may be old, but it works and the system
> administrators are able to keep it running.
>
> I do not know what happened in the past with your previous offer.  I
> am sorry that you are unable to help now.  Not only do we need a
> volunteer, but we need a volunteer with realistic goals that the
> leaders of the project have confidence in and one who shows
> perseverance.
>
> Thanks, David
>

Ian had confidence in me.  He also liked the proposal I set for how to
go about it.

Re: Patch pinging

[NightStrike]

On Mon, Jun 28, 2010 at 7:39 AM, David Edelsohn  wrote:
> On Mon, Jun 28, 2010 at 12:10 AM, NightStrike  wrote:
>
>> Ian had confidence in me.  He also liked the proposal I set for how to
>> go about it.
>
> So who actually said no?
>
> David
>

The Frederic guy didn't like my fake-looking fake name, and wanted a
real-looking-but-just-as-fake name, or he wouldn't create a sourceware
account for me.  He then ignored my followup emails asking for
clarification.

You guys need to realize how online identities work in this century.

Re: Patch pinging

[NightStrike]

On Mon, Jun 28, 2010 at 7:39 AM, David Edelsohn  wrote:
> On Mon, Jun 28, 2010 at 12:10 AM, NightStrike  wrote:
>
>> Ian had confidence in me.  He also liked the proposal I set for how to
>> go about it.
>
> So who actually said no?
>
> David
>

The Frederic guy didn't like my fake-looking fake name, and wanted a
real-looking-but-just-as-fake name, or he wouldn't create a sourceware
account for me.  He then ignored my followup emails asking for
clarification.

You guys need to realize how online identities work in this century.

Re: Patch pinging

[NightStrike]

On Mon, Jun 28, 2010 at 1:13 PM, David Edelsohn  wrote:
> On Mon, Jun 28, 2010 at 10:08 AM, NightStrike  wrote:
>
>> The Frederic guy didn't like my fake-looking fake name, and wanted a
>> real-looking-but-just-as-fake name, or he wouldn't create a sourceware
>> account for me.  He then ignored my followup emails asking for
>> clarification.
>
> Other people can create sourceware accounts. And ignore self-righteous people.
>
> Are you still volunteering to do the work?
>
> David
>

Yup

Re: Patch pinging

[NightStrike]

On Mon, Jun 28, 2010 at 7:39 PM, Ian Lance Taylor  wrote:
> NightStrike  writes:
>
>> On Mon, Jun 28, 2010 at 7:39 AM, David Edelsohn  wrote:
>>> On Mon, Jun 28, 2010 at 12:10 AM, NightStrike  wrote:
>>>
>>>> Ian had confidence in me.  He also liked the proposal I set for how to
>>>> go about it.
>>>
>>> So who actually said no?
>>>
>>> David
>>>
>>
>> The Frederic guy didn't like my fake-looking fake name, and wanted a
>> real-looking-but-just-as-fake name, or he wouldn't create a sourceware
>> account for me.  He then ignored my followup emails asking for
>> clarification.
>>
>> You guys need to realize how online identities work in this century.
>
> The overseers as a whole were not comfortable giving an account to
> somebody who was not willing to provide his real name.  I concurred in
> that decision.

It would have been courteous for you -- or Frederic, or anyone else --
to have communicated that to me instead of just ignoring me.

> Giving somebody a shell account on gcc.gnu.org means
> giving them a very high level of trust.

Then you should consider using legitimate account creation policies.
If I just put "John Smith" in the sign up form, I would have gotten an
account.  How does that change anything?  Again, welcome to 2010.

> There are quite a few people
> who could translate a shell account on gcc.gnu.org into a number of
> difficult-to-detect attacks on the entire FLOSS infrastructure,
> including the kernel, the source code control systems, etc.  It's hard
> for us to get to the required level of trust in somebody whom we have
> never met and who won't provide any real world contact information.

No one ever asked for any real world contact information.  Frederic
asked for a real-looking name.  That's just dumb.  If I wanted to
launch attacks on "the entire FLOSS infrastructure," do you really
think I would be going about it this way?

> NightStrike, thanks for volunteering, and thanks for being honest about
> the name issue rather than simply making something up.  I'm sorry that
> it won't work out.

What you guys need to realize is that if I did just make something up,
there wouldn't be an issue.  Your policies are vintage computer
security circa 1963.  That's what's so darn frustrating about this
whole entire thing.  You don't have any actual security, but yet you
think I'm going to try to bring down everything GNU.  That's just
awesome.



Recently there was a thread about why people don't contribute to GCC.
Well, here you go.  I tried.  Twice in quick succession.  I was flamed
vigorously, much more off-list than on.  I've been getting personal
emails from people angry about my pseudonym since the day I started
posting on your mailing lists.  I was lambasted by countless people,
ignored by the ones that matter, and eventually shut out because of a
security policy that has no place in present day computing.
Wonderful.  Way to make someone feel welcome.

Why don't people contribute to GCC?  I've found my answer.

Re: Patch pinging

[NightStrike]

On Tue, Jun 29, 2010 at 6:14 AM, Manuel López-Ibáñez
 wrote:
> Still, I don't understand why a shell account is required to start
> working on this. From what I understand, the scripts that need
> conversion are not secret, so anyone can work on them. The bugzilla
> customizations can be accessed with anonymous cvs, so whatever custom
> changes we have made, they are accessible anonymously and they can be
> ported to a new local bugzilla installation. In any case, patches
> against a pristine bugzilla installation would need review. I am not
> sure if copyright assignment is needed for all this. If so, then it
> depends whether NightStrike would agree to sign papers for the FSF
> with his real name. But...

When I first offered to do it, several people told me that FSF
paperwork is not required for this effort.

I presented what I would need - access to the current code, as well as
the database.  That didn't have to be the real stuff, but what I
ultimately did is what jsm28 and iant told me to do.  A snapshot of
the database, as long as it is complete, would suffice.  It's not just
a matter of the bugzilla code, it's the db itself, too.

> NightStrike, even just starting a wiki page and making a list of
> everything that needs adjusting and suggestions on how to implement
> the changes would help incredibly whoever ends up committing the
> changes. Right now, I wouldn't know where to start!

Creating an outline of how to go about things that someone else will
ignore / throw away sounds like a bigger waste of time than trying to
jump through the patch pinging horror.

> This whole issue has focussed in a little problem about the final step
> (installing bugzilla in sourceware.org), whereas there is so much work
> to do before reaching that step, that probably the person that starts
> this work won't be the same that finally installs the new bugzilla
> version. Take the opportunity that people are paying attention right
> now and collect all the information that would be needed for this.
> Then you will know if you need a shell account, a cvs account, a
> copyright or just someone else to do that part on your behalf (I will
> be willing to review and commit stuff).

I already did all of that.  I was ready to start actually creating
incremental patches.

> Yes, I know that contributing to GCC seems sometimes like a fight and
> finding the right loop-hole to achieve what you want. And sometimes,
> you lose. On the other hand, the lack of a strong leadership means
> that many times despite all the resistance and obstacles, you can find
> a way to get done stuff if you manage to find the correct way to do it
> (either by means of technical or social engineering, with the latter
> being sometimes more important than the former)

That's not how you run a welcoming project that's trying to attract
new people and *grow*.  That's a recipe for stagnation.  When it takes
just as much if not more effort to fight your way through beligerent
curmudgeons than it does to do the actual work, then something is
wrong in the state of Denmark.

> Personally, I don't give a fig what your real name is. I don't support
> giving you (or anyone without a paper trail) shell access to
> sourceware.org, but I don't think this is needed to contribute to GCC.
> There is such a long list of useful stuff to be done that I could keep
> a horde of anonymous contributors busy for years.

Re: Patch pinging

[NightStrike]

On Tue, Jun 29, 2010 at 7:24 AM, Richard Kenner
 wrote:
>> The free software community works on a web of trust and personal
>> relationships.  If you prefer to remain pseudonymous, then you must
>> accept that you will not be at the center of that web.
>
> I agree.  Openness is an important part of the free software community
> and I don't believe that applies only to source code.  I think it's important
> that the community know the people within it.
>
> I reject the analogy with social forums, where anonymity has indeed become
> an important part of Internet culture.  This is a professional, not a
> social, community.  Nobody would expect to be able to work on software
> development for a company if they refused to give their real name.  I don't
> see why they should expect to be able to be part of the free software
> community under similar circumstances.
>

It's not just present on "social community" sites.  Look at the
entirety of sourceforge.  That's quite a large respository of free
software, and yet it consists 100% of fake-named people (and please
understand what I mean by that.)  It's even a place where projects get
tons of donations, and yet these people are completely anonymous.
I've received donations myself through SF, even from not just one, but
several very large corporations -- one of which you wouldn't believe
if I showed you the proof.

Re: Patch pinging

[NightStrike]

On Tue, Jun 29, 2010 at 4:34 AM, Jonathan Wakely  wrote:
> On 29 June 2010 05:40, NightStrike wrote:
>>
>> Then you should consider using legitimate account creation policies.
>> If I just put "John Smith" in the sign up form, I would have gotten an
>> account.
>
> Not necessarily, there are maintainers with approval rights who
> haven't got shell access, it's very restricted.
>

I was referring to the form I had to fill out, and the reason for rejection.

Re: Patch pinging

[NightStrike]

On Tue, Jun 29, 2010 at 7:49 AM, Manuel López-Ibáñez
 wrote:
> On 29 June 2010 13:23, NightStrike  wrote:
>>
>>> This whole issue has focussed in a little problem about the final step
>>> (installing bugzilla in sourceware.org), whereas there is so much work
>>> to do before reaching that step, that probably the person that starts
>>> this work won't be the same that finally installs the new bugzilla
>>> version. Take the opportunity that people are paying attention right
>>> now and collect all the information that would be needed for this.
>>> Then you will know if you need a shell account, a cvs account, a
>>> copyright or just someone else to do that part on your behalf (I will
>>> be willing to review and commit stuff).
>>
>> I already did all of that.  I was ready to start actually creating
>> incremental patches.
>>
>
> So what is stopping you from posting these patches to gcc-patches or
> sending them to the relevant maintainers? I still do not see the need
> for a shell account.
>
> Manuel.
>

I think I've gotten a pretty good indication of what THAT would be
like.  But even then, I need a place to test the changes against the
db, and further, a place to make changes to said db.

Re: Patch pinging

[NightStrike]

On Tue, Jun 29, 2010 at 10:30 AM, Ian Lance Taylor  wrote:
> NightStrike  writes:
>
>> It's not just present on "social community" sites.  Look at the
>> entirety of sourceforge.  That's quite a large respository of free
>> software, and yet it consists 100% of fake-named people (and please
>> understand what I mean by that.)  It's even a place where projects get
>> tons of donations, and yet these people are completely anonymous.
>> I've received donations myself through SF, even from not just one, but
>> several very large corporations -- one of which you wouldn't believe
>> if I showed you the proof.
>
> It is quite true that gcc operates by different rules.  We've
> established that you can contribute patches to gcc under a pseudonym,
> but the FSF does require that you reveal your name to them.  The FSF
> requirements are widely recognized as an obstacle to contributing to
> gcc.  However, there are good reasons for requiring a paper trail, and
> those reasons are based on events that actually happened, not merely on
> theory.  I would like to change things too, but, because of that
> history, saying "other projects do it this way" is not a sufficient
> argument for change.
>
> Ian
>

Maybe there's a way to look at how other projects handle the same
issue, and find a different solution that's more workable for more
people.  I don't know what event you are specifically referring to in
the GCC history that created this situation, but I don't think it's
unreasonable to think that there'd be an alternate method of achieving
the same results.

Re: Patch pinging

[NightStrike]

On Wed, Jun 30, 2010 at 1:13 PM, Frank Ch. Eigler  wrote:
>
> NightStrike  writes:
>
>> [...]
>>> So who actually said no?
>>
>> The Frederic guy didn't like my fake-looking fake name, and wanted a
>> real-looking-but-just-as-fake name, or he wouldn't create a account
>> for me.
>
> In consultation with other overseers, I rejected your request.  I did
> not ask for a "real-looking-but-just-as-fake name", but a "real name".
> You falsely presume zero vetting.

You missed my point, then.  What's in a name?  How would you know if
what I told you was true or not?

>> He then ignored my followup emails asking for clarification.
>
> You said no.  There was nothing further to discuss.

Not exactly.  I offered you an alternative, and I asked you a
question.  You ignored both.  You could very well have given me
feedback, explained what was going on, let me know that I was
rejected, or any of a dozen other things.

Re: Patch pinging

[NightStrike]

On Wed, Jun 30, 2010 at 1:41 PM, Paolo Carlini  wrote:
> On 06/30/2010 07:32 PM, NightStrike wrote:
>>> In consultation with other overseers, I rejected your request.  I did
>>> not ask for a "real-looking-but-just-as-fake name", but a "real name".
>>> You falsely presume zero vetting.
>>>
>> You missed my point, then.  What's in a name?  How would you know if
>> what I told you was true or not?
>>
> How many liars do you think are actively contributing to GCC? Just a
> guess...
>
> Paolo.
>

No idea.  I've been emailed offlist by 3 people that used fake names.
Or at least claimed to.

Re: Patch pinging

[NightStrike]

On Wed, Jun 30, 2010 at 3:24 PM, David Edelsohn  wrote:
> He understood your point very well.  That is why Frank said, "You
> falsely presume zero vetting."

Maybe I didn't get the zero vetting part, then.  I thought I did, but
apparently not.  What does that mean in this context?  Google isn't
telling me.

> Do you realize that your email message convey a very smug tone?

No, I do not realize that.  I was intending to speak matter-of-fact-ly.

Re: Problems with upstream versions of gmp, mpfr, and mpc [Was: Bug in Build System of gcc-4.5.1? Cannot Find libmpc.so.2]

[NightStrike]

On Sat, Aug 28, 2010 at 12:45 PM, Eric Botcazou  wrote:
>> I'm very sceptical about "or any later version" instructions when
>> building the gcc prerequisites.  In practice this can never be certain
>> to work, because the upstream maintainers of these tools can change
>> them in ways that break gcc.
>
> Indeed, on the SPARC we seem to have problems (miscompilations: fortran/45277,
> target/45363, c/45407) with any newer versions of GMP/MPFR/MPC.  So I'm going
> to add a blurb to the platform-specific instructions about that.

Wouldn't it be worthwhile to push fixes upstream?  Granted, doing so
for GMP is a Herculean task, but it's important to make sure that
dependencies stay working, even past the minimum requirement version.

Re: 2010 GCC and GNU Toolchain Developers' Summit

[NightStrike]

On Thu, Aug 12, 2010 at 4:22 PM, Toon Moene  wrote:
> Andrew J. Hutton wrote:
>
>> The annual GCC & GNU Toolchain Developers’ Summit brings together the core
>> development team of the GNU Compiler Collection with those working on the
>> other toolchain components to discuss the state of the art. We focus on
>> providing a vendor neutral environment to encourage open dialog, technology
>> demonstrations, as well as long term technical roadmap development.
>>
>> The 2010 Summit will be taking place in Ottawa, Canada from October 25th
>> to 27th and located in the SITE building at the uOttawa campus in the
>> central core of the city.
>>
>> The CFP is now available at http://www.gccsummit.org/2010/cfp.php and
>> additional information is available on the Summit website at
>> http://www.gccsummit.org.
>
> Thanks for the invitation.  I'd like to join - unfortunately, I do not have
> a good subject for a talk.
>
> Perhaps some from the gfortran effort would like to give a talk.  As far  as
> I can see I can support one person financially (trip from Europe to Ottawa
> vice versa and stay in "Les Suites").

Only a gfortran person?  Because I'd like to nominate Kai Tietz for
that, if he's willing to accept.

Re: 2010 GCC and GNU Toolchain Developers' Summit

[NightStrike]

On Mon, Aug 30, 2010 at 1:33 PM, Toon Moene  wrote:
> NightStrike wrote:
>
>> On Thu, Aug 12, 2010 at 4:22 PM, I  wrote:
>
>>> Perhaps some from the gfortran effort would like to give a talk.  As far
>>>  as
>>> I can see I can support one person financially (trip from Europe to
>>> Ottawa
>>> vice versa and stay in "Les Suites").
>>
>> Only a gfortran person?  Because I'd like to nominate Kai Tietz for
>> that, if he's willing to accept.
>
> Well, obviously, I mostly interested in the progress of the Mother Of All
> Programming Languages, but I might be persuaded to fund a lesser cause.
>
> [ Add :-)'s to taste ]

Well, you might be interested to know that we've been working hard to
get the *best language in the world* to work on our target platform,
Win64.  In fact, the last testsuite I ran has it down to just 2 or
three distinct errors, depending on how you count.  A year or two ago,
we couldn't even run the front end without it segfaulting.  This makes
GCC a big competitor to Absoft for targetting 64-bit windows, and Kai
is the prime mover on that front.

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

We would like x86_64-w64-mingw32 to become a secondary target for 4.6.
 What has to be checked off for that to happen?  I have an
auto-testsuite-thinger running constantly now and posting results to
the ML (it takes several days to do a full dl/build/test, so it's not
daily, but it's continuous).

On Tue, Aug 31, 2010 at 11:59 AM, Mark Mitchell  wrote:
> We (GCC RMs) plan to close GCC 4.6 Stage 1 on or or about October 27,
> 2010 (the closing day of the GCC Summit).  Major features should be
> checked in prior to this point.  Please let us know if you have a major
> feature that you think you will not be able to get checked in prior to
> October 27th.
>
> Thank you,
>
> --
> Mark Mitchell
> CodeSourcery
> m...@codesourcery.com
> (650) 331-3385 x713
>

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Sun, Sep 5, 2010 at 2:03 PM, Mark Mitchell  wrote:
> On 9/4/2010 9:23 PM, NightStrike wrote:
>
>> We would like x86_64-w64-mingw32 to become a secondary target for 4.6.
>
> Who is "we" in this context?

Sorry, that would be Kai Tietz, myself, and the entire mingw-w64.sf.net project.

>> What has to be checked off for that to happen?
>
> It's not so much a matter of "checking off".  It's a combination of the
> SC's perception of the importance of the target and the technical stats
> of the port.  I can raise the issue with the SC, if you like, but,
> personally, I'm not sure that 64-bit Windows is significant enough as a
> target platform for GCC to merit that status.

Ouch.  What criteria do you use for that analysis?  I will endeavor to
prove our importance :)

Note that 32-bit windows is already a secondary platform.

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Sun, Sep 5, 2010 at 2:29 PM, Mark Mitchell  wrote:
> On 9/5/2010 11:23 AM, NightStrike wrote:
>
>>> It's not so much a matter of "checking off".  It's a combination of the
>>> SC's perception of the importance of the target and the technical stats
>>> of the port.  I can raise the issue with the SC, if you like, but,
>>> personally, I'm not sure that 64-bit Windows is significant enough as a
>>> target platform for GCC to merit that status.
>>
>> Ouch.  What criteria do you use for that analysis?
>
> I can't say what criteria the SC uses; I don't know what basis other SC
> members use to decide.
>
> I use my own instincts (which, I admit, is not a scientific basis) for
> deciding.  I spend much of my life talking to various stakeholders in
> GCC, and so I have a reasonable feel for where people are presently
> using GCC, and where they would like to use it.  Thus far, I've
> certainly heard of some interest in 64-bit Windows, but nowhere near as
> much as 32-bit Windows or Cygwin.
>
> I certainly don't mind raising the issue, if you want me to do that; I'm
> happy to carry messages to the SC independent of my own opinions.

Yes, definitely bring it up.  I'm just trying to get more cards
stacked in our favor :)

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther  wrote:
> On Mon, 6 Sep 2010, Tobias Burnus wrote:
>
>> Gerald Pfeifer wrote:
>> > Do you have a pointer to testresults you'd like us to use for reference?
>> >
>> >  From our release criteria, for secondary platforms we have:
>> >
>> >    • The compiler bootstraps successfully, and the C++ runtime library
>> >      builds.
>> >    • The DejaGNU testsuite has been run, and a substantial majority of the
>> >      tests pass.
>>
>> See for instance:
>>   http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html
>
> There are no libstdc++ results in that.
>
> Richard.

This is true.  I always run make check-gcc.  What should I be doing instead?

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Mon, Sep 6, 2010 at 12:21 PM, Richard Guenther
 wrote:
> On Mon, Sep 6, 2010 at 6:19 PM, NightStrike  wrote:
>> On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther  wrote:
>>> On Mon, 6 Sep 2010, Tobias Burnus wrote:
>>>
>>>> Gerald Pfeifer wrote:
>>>> > Do you have a pointer to testresults you'd like us to use for reference?
>>>> >
>>>> >  From our release criteria, for secondary platforms we have:
>>>> >
>>>> >    • The compiler bootstraps successfully, and the C++ runtime library
>>>> >      builds.
>>>> >    • The DejaGNU testsuite has been run, and a substantial majority of 
>>>> > the
>>>> >      tests pass.
>>>>
>>>> See for instance:
>>>>   http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html
>>>
>>> There are no libstdc++ results in that.
>>>
>>> Richard.
>>
>> This is true.  I always run make check-gcc.  What should I be doing instead?
>
> make -k check
>

Ugh.  And I thought I was golden :)

This apparently requires autogen to do something about
fixincludes/check.tpl.  I have no idea what that is or what that
means

I'll report back.  Any insight you can provide is greatly appreciated.

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Mon, Sep 6, 2010 at 1:24 PM, Andrew Haley  wrote:
> On 09/06/2010 06:18 PM, NightStrike wrote:
>> On Mon, Sep 6, 2010 at 12:21 PM, Richard Guenther
>>  wrote:
>>> On Mon, Sep 6, 2010 at 6:19 PM, NightStrike  wrote:
>>>> On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther  wrote:
>>>>> On Mon, 6 Sep 2010, Tobias Burnus wrote:
>>>>>
>>>>>> Gerald Pfeifer wrote:
>>>>>>> Do you have a pointer to testresults you'd like us to use for reference?
>>>>>>>
>>>>>>>  From our release criteria, for secondary platforms we have:
>>>>>>>
>>>>>>>    • The compiler bootstraps successfully, and the C++ runtime library
>>>>>>>      builds.
>>>>>>>    • The DejaGNU testsuite has been run, and a substantial majority of 
>>>>>>> the
>>>>>>>      tests pass.
>>>>>>
>>>>>> See for instance:
>>>>>>   http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html
>>>>>
>>>>> There are no libstdc++ results in that.
>>>>>
>>>>> Richard.
>>>>
>>>> This is true.  I always run make check-gcc.  What should I be doing 
>>>> instead?
>>>
>>> make -k check
>>>
>>
>> Ugh.  And I thought I was golden :)
>>
>> This apparently requires autogen to do something about
>> fixincludes/check.tpl.  I have no idea what that is or what that
>> means
>
> Just ignore the fixincludes test results.
>
> Andrew.
>

Thanks!  Life just got easier again :)

Running it with -j5.  Hopefully cygwin doesn't barf on that.. I know
cygwin used to have issues with -j.