Dear all,
When I try to compile the sample code at the end of this report with
gcc -ansi -pedantic-errors -Wall essai.c -o essai, I get the error :
/usr/include/bits/resource.h:161: erreur: comma at end of enumerator list
If I remove the -pedantic-errors, the compilation goes fine.
Here is
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-24 06:16 ---
/usr/include/bits/resource.h is not controlled by GCC.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bpiguet at teaser dot fr 2009-06-24 06:28 ---
(In reply to comment #1)
/usr/include/bits/resource.h is not controlled by GCC.
OK.
Before I make the same error again, any hints on the project which controls
/usr/include/bits/resource.h ? I guess it might be
--- Comment #1 from ubizjak at gmail dot com 2009-06-24 06:35 ---
Can you put HAVE_C99_RUNTIME around problematic conversions (just copy the
approach from builtins-18.c) ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40532
--- Comment #6 from krebbel at gcc dot gnu dot org 2009-06-24 07:01 ---
Subject: Bug 40501
Author: krebbel
Date: Wed Jun 24 07:01:24 2009
New Revision: 148892
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148892
Log:
2009-06-24 Andreas Krebbel krebb...@de.ibm.com
PR
--- Comment #5 from redi at gcc dot gnu dot org 2009-06-24 07:06 ---
Subject: Bug 40297
Author: redi
Date: Wed Jun 24 07:06:17 2009
New Revision: 148893
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148893
Log:
2009-06-24 Jonathan Wakely jwakely@gmail.com
PR
--- Comment #6 from redi at gcc dot gnu dot org 2009-06-24 07:08 ---
Subject: Bug 40297
Author: redi
Date: Wed Jun 24 07:07:49 2009
New Revision: 148894
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148894
Log:
2009-06-24 Jonathan Wakely jwakely@gmail.com
PR
--- Comment #7 from jwakely dot gcc at gmail dot com 2009-06-24 07:09
---
Fixed for 4.4.1 and 4.5.0
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2009-06-24 07:42 ---
Couldn't this be fixed also by changing the initial gimplification from:
p.0 = p;
p = p + 1;
foo (p.0);
to:
p.0 = p;
foo (p.0);
p = p + 1;
?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34737
--- Comment #9 from steven at gcc dot gnu dot org 2009-06-24 07:45 ---
I agree with Comment #8
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2009-06-24 07:49 ---
How are things progressing with a fix for this, Richi? :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685
--- Comment #1 from gael dot guennebaud at gmail dot com 2009-06-24 08:07
---
Created an attachment (id=18055)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18055action=view)
a complete example showing the problem
usage:
Works:
g++ -O3 instr_dependency.cpp -o instr_dependency
--- Comment #5 from rguenther at suse dot de 2009-06-24 09:07 ---
Subject: Re: Scheduling of post-modified function
arguments is not good
On Wed, 24 Jun 2009, steven at gcc dot gnu dot org wrote:
--- Comment #4 from steven at gcc dot gnu dot org 2009-06-24 07:42
---
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-06-24 09:15 ---
:P
I am currently not working on a fix for this (heh, people may have noticed
that ...). My idea was to build an on-the-side CFG for this and use that
in tree-ssa-ifcombine.c - I just never came around
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-24 09:42 ---
ICEs with -O -ffast-math -floop-block:
source/blender/radiosity/intern/source/radfactors.c: In function
'calcSidefactors':
source/blender/radiosity/intern/source/radfactors.c:192: error: definition in
block 4 does
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-06-24 09:43 ---
It's not available.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40517
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-24 09:45 ---
Yes, it's from libc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40536
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-06-24 09:48 ---
I can't verify it (you do not provide complete source that can be compiled),
but I think this is a duplicate of PR40141 which is fixed in GCC 4.4.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-06-24 10:11 ---
This bug is fixed within ld (by using pseudo-relocation) and within startup
code. For new runtimes this bug is fixed also for 32-bit mingw. There is no
limit about const variables exported without dllimport anymore
--- Comment #10 from ktietz at gcc dot gnu dot org 2009-06-24 10:17 ---
Does this issue appears also, when using builtin alloca version? As I noticed
does the switch -fno-builtin shows explict broken _alloca for x64. The
call-save area isn't adjusted and compiler seems not to take care
--- Comment #25 from ktietz at gcc dot gnu dot org 2009-06-24 10:28 ---
This bug was fixed for 4.4 version. The real issue here was the changes happend
to ira and specifying one register via the constrains =a or +a. Both
variant don't work anymore. By expanding the stack_allocator
--- Comment #3 from gael dot guennebaud at gmail dot com 2009-06-24 10:53
---
There is a compilable example attached to comment #1.
Furthermore, I can reproduce the problem with gcc 4.1.3, 4.2.4, 4.3.2, and
4.4.0, so I don't think it is a duplicate of PR40141.
FYI, in the meantime I
--- Comment #2 from janus at gcc dot gnu dot org 2009-06-24 11:00 ---
Subject: Bug 40427
Author: janus
Date: Wed Jun 24 10:59:56 2009
New Revision: 148906
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148906
Log:
2009-06-24 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #3 from janus at gcc dot gnu dot org 2009-06-24 11:02 ---
Fixed with r148906. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from gael dot guennebaud at gmail dot com 2009-06-24 11:12
---
some additional info:
- compiling with -fno-strict-aliasing fix the issue, so perhaps this is not a
real bug but a feature ?
- on the other hand using the may_alias type attribute for casting does not
help:
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-06-24 11:23 ---
There are aliasing issues with your code / the intrinsics implementation:
float data[4] = {1, 2, 3, 4};
...
r = _mm_castpd_ps(_mm_load_sd((double*)(from)));
ends up loading from float data via a pointer to
--- Comment #11 from sherpya at netfarm dot it 2009-06-24 11:42 ---
I'm using 4.5 from svn, with -O2 and looks like not affected
4.3 and 4.4 are almost unusable on mingw (at least my builds)
something changed in 4.5 branch,
I've not tested further 4.3 or .4.4 since I was using 4.2 then
--- Comment #7 from ubizjak at gmail dot com 2009-06-24 11:57 ---
Adding x86 intrinsic expert...
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-06-24 11:57 ---
I tried to reproduce this with 4.4 and 4.5 and it seems to work for me. Do you
still have this issue?
Kai
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
I'm attaching a very simple reproducer which, if compiled like following way:
ifort -c lsame.f
gfortran repr.f lsame.o
produces a wrong negation of a logical value returned by function LSAME(a
simpified analogue for LAPACK one available in attach). The value for
.NOT.LSAME('D','D') and
--- Comment #12 from ktietz at gcc dot gnu dot org 2009-06-24 12:05 ---
As I read this. Would it make sense to use for x86-mingw the callabi feature
(as we do for the x64 variant)? This would be useful for 32-bit based multilib
version, too (but this is more a side-note for this).
Kai
--- Comment #1 from alexander dot v dot kobotov at intel dot com
2009-06-24 12:12 ---
Created an attachment (id=18056)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18056action=view)
The reproducer sources zipped
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-24 12:37 ---
Not a self-contained bug report: Impossible to reproduce unless you have the
intel compiler. Maybe you can attach the assembler output of ifort?
--
steven at gcc dot gnu dot org changed:
What
Since my update to version 4.5 06-18-2009 i have some errors on compiling.
Here are my logs for ppp-2.4.4 and xorg-server-1.6.1.901
These are my first packages after compiler update and i think many of the other
packages will post the same errors.
--
Summary: Error compiling with
--- Comment #1 from wuddja at yahoo dot de 2009-06-24 12:46 ---
Created an attachment (id=18057)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18057action=view)
build log for ppp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40540
--- Comment #2 from wuddja at yahoo dot de 2009-06-24 12:47 ---
Created an attachment (id=18058)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18058action=view)
build log for xorg-server
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40540
Found while looking at PR 39997. The following is not checked. The reason is
that the check contains:
if (rvalue-expr_type == EXPR_VARIABLE
while the example has EXPR_FUNCTION
program test
procedure(real), pointer :: p
p = f() ! Invalid f() returns a LOGICAL(1) function, but p is a
--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-24 12:59 ---
(In reply to comment #3)
Regarding the implicit typing: I think it would be easiest to apply the
implicit typing for
module m
external foo
end module m
at resolution time, such that foo is marked as ts.type
--- Comment #11 from christian dot joensson at gmail dot com 2009-06-24
13:03 ---
I have tried binutils cvs checkouts as of
20090608 12:00 UTC
20090519 12:00 UTC
20090502 12:00 UTC
20090402 12:00 UTC
20090309 12:00 UTC
as well as cygwin's provided binutils 2.18.50.20080625, all with
--- Comment #8 from hjl dot tools at gmail dot com 2009-06-24 13:09 ---
(In reply to comment #6)
_mm_load_sd( (const doubleA*)(from) )
does not work because the prototype of _mm_load_sd does not have a type
with the may-alias attribute, so it gets stripped again.
I think
gcc-4.3.3 (4.3.2 probably other versions, too)
seems to produce bad code when
accessing an array of small 'volatile'
objects -- it may try to access multiple
such objects in a 'parallel/vectorized' fashion.
-ftree-vectorize seems to be the option
that triggers this behavior.
E.g., instead of
Between revisions 148536 and 148750 the following failures appeared:
FAIL: g++.dg/pch/pch.C -g -I. (test for excess errors)
FAIL: g++.dg/pch/pch.C -g assembly comparison
FAIL: g++.dg/pch/pch.C -O2 -g -I. (test for excess errors)
FAIL: g++.dg/pch/pch.C -O2 -g assembly comparison
FAIL:
--- Comment #3 from hjl dot tools at gmail dot com 2009-06-24 13:20 ---
(In reply to comment #0)
Since my update to version 4.5 06-18-2009 i have some errors on compiling.
Here are my logs for ppp-2.4.4 and xorg-server-1.6.1.901
These are my first packages after compiler update and
--- Comment #1 from dominiq at lps dot ens dot fr 2009-06-24 13:21 ---
I have forgotten to say that the failures do not appear with -m64, see
http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg01990.html .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40543
--- Comment #2 from dominiq at lps dot ens dot fr 2009-06-24 13:25 ---
Also forgot to say it occurs on i686-apple-darwin9 but not on
powerpc-apple-darwin9.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
Since at least revision 148536, I see the following failures on
*-apple-darwin9:
FAIL: gcc.dg/torture/builtin-math-6.c -O0 (test for excess errors)
FAIL: gcc.dg/torture/builtin-math-6.c -O1 (test for excess errors)
FAIL: gcc.dg/torture/builtin-math-6.c -O2 (test for excess errors)
FAIL:
--- Comment #1 from dominiq at lps dot ens dot fr 2009-06-24 13:36 ---
Also seen on *-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40531
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-24 13:45 ---
I think the problem relates to what is regarded as TRUE and what is regarded as
FALSE by the compilers (the following output has been produced by
transfer(.true.,0), transfer(.false.,0)):
gfortran has: .true. =
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-24 14:02 ---
Confirmed.
void
volarr_cpy(char *d, volatile char *s)
{
int i;
for ( i=0; i16; i++ )
d[i]=s[i];
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
libgfortran/io/write.c: In function 'nml_write_obj':
libgfortran/io/write.c:1261:17: warning: comparison between 'bt' and 'enum
anonymous'
libgfortran/io/write.c:1303:5: warning: case value '6' not in enumerated type
'bt'
libgfortran/io/write.c:1339:15: warning: comparison between 'bt' and 'enum
--- Comment #4 from spop at gcc dot gnu dot org 2009-06-24 14:22 ---
(In reply to comment #3)
ICEs with -O -ffast-math -floop-block:
also ICEs the same way on the trunk.
This is fixed in the graphite branch, although -floop-block is not
available now, I tried with
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-24 14:45 ---
Most likely the same issue as PR 39131.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from alexander dot v dot kobotov at intel dot com
2009-06-24 15:04 ---
Created an attachment (id=18059)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18059action=view)
LSAME asm and object for Intel64 arch.
lsame.f from reproducer compiled with Intel 9.1 Fortran
--- Comment #1 from dominiq at lps dot ens dot fr 2009-06-24 15:07 ---
Forgot to say that the builds were with MPC enabled.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2009-06-24 15:28 ---
With option 3, we can check the return value of an ifunc
function since we know the return value is a pointer to
the ifunc function. We don't need a separate prototype
nor asm statement.
--
--- Comment #2 from hjl dot tools at gmail dot com 2009-06-24 15:31 ---
Created an attachment (id=18060)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18060action=view)
Ifunc examples
Here are some ifunc examples with option 3.
--
--- Comment #2 from ghazi at gcc dot gnu dot org 2009-06-24 15:46 ---
This is a problem with mpc-0.6, fixed in the MPC svn repo.
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01157.html
Testing with mpc-0.6 is still useful because it exercises major changes in the
fortran frontend.
--- Comment #3 from jakub at gcc dot gnu dot org 2009-06-24 15:54 ---
Option 2) is certainly the least intrusive in the compiler and you can use it
even with foo's prototype and calling it from the same CU, just use asm.
__typeof (foo) *
__attribute__ ((ifunc))
foo_ifunc (void) __asm
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #13 from mkuvyrkov at gcc dot gnu dot org 2009-06-24 16:02
---
Created an attachment (id=18061)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18061action=view)
Proposed patch
Here is a patch moving precedence handling of pointers to powerpc backend.
--
--- Comment #5 from alexander dot v dot kobotov at intel dot com
2009-06-24 16:02 ---
Thanks a lot, there is indeed different values for true:
For GFORTRAN: true = 1, false = 0
For Intel Fortran: true = -1, false = 0.
In IF expression both true values works, but NOT operand in GFORTRAN
--- Comment #4 from hjl dot tools at gmail dot com 2009-06-24 16:07 ---
(In reply to comment #3)
Option 2) is certainly the least intrusive in the compiler and you can use it
even with foo's prototype and calling it from the same CU, just use asm.
__typeof (foo) *
__attribute__
--- Comment #2 from jason at gcc dot gnu dot org 2009-06-24 16:26 ---
Subject: Bug 40342
Author: jason
Date: Wed Jun 24 16:25:52 2009
New Revision: 148910
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148910
Log:
PR c++/40342
* decl.c (decls_match): Check
--- Comment #2 from igodard at pacbell dot net 2009-06-24 16:34 ---
Probably not the same as 39131, because this ices only if the function is
declared. Both the typedef and the data declaration compile OK without the
function, whereas 39131 seems to ice without any use at all.
--
--- Comment #13 from jamborm at gcc dot gnu dot org 2009-06-24 16:38
---
Fix submitted to the mailing list, pending maintainer approval:
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01918.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40493
--- Comment #1 from janus at gcc dot gnu dot org 2009-06-24 16:43 ---
This is easily fixed by the following patchlet (I had just forgotten about this
case):
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision
--- Comment #3 from jason at gcc dot gnu dot org 2009-06-24 17:02 ---
Subject: Bug 40342
Author: jason
Date: Wed Jun 24 17:02:03 2009
New Revision: 148911
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148911
Log:
PR c++/40342
* decl.c (decls_match): Check
--- Comment #4 from jason at gcc dot gnu dot org 2009-06-24 17:04 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from kargl at gcc dot gnu dot org 2009-06-24 17:23 ---
(In reply to comment #5)
The real problem with the issue is that code compiled with GFORTRAN could have
issues if linked with a vendor library. I'm experiencing ones with Intel#174;
MKL.
It would be nice to
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-06-24 17:33 ---
Wait I don't think we should support this at all because the ABI between
gfortran and ifort are way different.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
--- Comment #8 from burnus at gcc dot gnu dot org 2009-06-24 17:59 ---
Alexander, I just filled Issue 553679 at premier.intel.com as associated bug. I
realized that the issue is even bigger:
C99's 6.3.1.2 has When any scalar value is converted to _Bool, the result is 0
if the value
--- Comment #9 from burnus at gcc dot gnu dot org 2009-06-24 18:11 ---
It would be nice to have an option to turn off that fast inversion, at least
for compatibility. Or at least to make -O0 case compatible.
How do other vendor's (Sun, Pathscale, Absoft, etc) represent .true.
and
--- Comment #5 from jakub at gcc dot gnu dot org 2009-06-24 19:26 ---
What do you do if the function has arguments, because ifunc shouldn't have
arguments? While C++ has unnamed arguments and you could perhaps enforce them,
C does not. How do you handle option 3 with:
--- Comment #6 from hjl dot tools at gmail dot com 2009-06-24 19:31 ---
(In reply to comment #5)
What do you do if the function has arguments, because ifunc shouldn't have
arguments? While C++ has unnamed arguments and you could perhaps enforce
them,
For unnamed arguments, see
--- Comment #5 from burnus at gcc dot gnu dot org 2009-06-24 21:53 ---
Created an attachment (id=18062)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18062action=view)
Initial patch, somewhat working, but still many failures
Draft patch for item 1 and item 2 - still incomplete.
--- Comment #1 from janis at gcc dot gnu dot org 2009-06-24 22:03 ---
GCC defines DEC_EVAL_METHOD to be 0: evaluate all operations just to the range
and precision of the type.
The arithmetic/comparison/conversion functions in libgcc (for DPD, not sure
about BID) use the range and
Compiling this test program with gcc-4.4-20090623 fails with a linker error:
cat pr39867-redux.c
int main (void)
{
int exp = -1;
/* Wrong folding of the LHS to an unsigned MIN leads to 2 != 4294967295. */
if ((exp 2 ? (unsigned int) exp : 2U) != -1U)
link_error ();
return 0;
}
gcc
--- Comment #1 from mikpe at it dot uu dot se 2009-06-24 22:25 ---
Created an attachment (id=18063)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18063action=view)
test case
test case illustrating the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40547
--- Comment #2 from mikpe at it dot uu dot se 2009-06-24 22:29 ---
Created an attachment (id=18064)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18064action=view)
proposed patch fixing this error
This patch adapts Paolo Bonzini's patch for PR39867 to handle the remaining two
--- Comment #12 from sherpya at netfarm dot it 2009-06-24 23:22 ---
however 4.5 is still far from being stable as 4.2, I get many crashes while
using complied mplayer (it's a stress test for gcc :))
Unfortunately I had no much time to debug mplayer builds
--
I have a directory on my PATH that contains a subdirectory named gcc. When I
run gcc (not fully-qualified) I get all sorts of very bizarre behavior. For
example:
$ cat t.c
#include limits.h
$ mkdir gcc
$ PATH=.:$PATH gcc -E t.c /dev/null
In file included from /tmp/t.c:1:
--- Comment #1 from hjl dot tools at gmail dot com 2009-06-25 00:15 ---
Can you provide a testcase?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2009-06-25
00:32 ---
Subject: Re: FAIL: gcc.dg/builtins-65.c (test for
excess errors)
Can you put HAVE_C99_RUNTIME around problematic conversions (just copy the
approach from builtins-18.c) ?
Attached diff.
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-25 01:25 ---
*** This bug has been marked as a duplicate of 38966 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-06-25 01:25 ---
*** Bug 40548 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from mckelvey at maskull dot com 2009-06-25 01:52 ---
I was able to build with --enable-clocale=generic. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40511
--- Comment #4 from kkojima at gcc dot gnu dot org 2009-06-25 04:39 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from psmith at gnu dot org 2009-06-25 05:00 ---
Ah, thanks for the pointer. I did search before I created a new bug but wasn't
successful in narrowing down my search to something reasonable. It would be
nice if the real bug mentioned PATH in the summary; I was trying to
88 matches
Mail list logo
