[bug #33399] Double-colon rules sometimes behave like if they were single-colon

Update of bug #33399 (project make): Status: Not A Bug => Fixed Assigned to:None => psmith Operating System: POSIX-Based => Any Fixed Release:

[bug #34519] Interrupt/Exception caught Program Files (x86)

Update of bug #34519 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #3: I believe this bug is

[bug #34608] comparison of unsigned expression < 0 is always false

Update of bug #34608 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operating System:

[bug #32567] make can not compile anymore on WINDOWS32 target from 2010-11-07

Update of bug #32567 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operating System:

[bug #15719] Test suite not reliable for parallel build support

Update of bug #15719 (project make): Operating System: MS Windows => Any Summary: Make jobserver feature not supported on WINDOWS32 platforms => Test suite not reliable for parallel build support ___

Re: fix for make gaining jobserver tokens

On Tue, 2011-10-25 at 13:34 -0700, Tim Newsome wrote: > We do a lot of builds (as in double-digit servers building non-stop). > Sometimes, when a part of the build fails, make -j8 would die with: > make: INTERNAL: Exiting with 9 jobserver tokens available; should be > 8 > > With -j16 the error wo

Re: [PATCH] High resolution file timestamp support for Mac OSX

On Wed, 2011-10-12 at 19:32 +, Troy Runkel wrote: > The GNU make configure script currently doesn’t enable high resolution > file timestamp support for the Mac OSX platform. However, nanosecond > file timestamps are available, they’re just stored in a different > location in the ‘struct stat’

[bug #34608] comparison of unsigned expression < 0 is always false

Follow-up Comment #8, bug #34608 (project make): Not sure why that happens although the C standard requires special handling of char in various ways. The warnings you're seeing in the source, though, are related to invoking this macro with uintmax_t not char.

[bug #34608] comparison of unsigned expression < 0 is always false

Follow-up Comment #7, bug #34608 (project make): Interesting. For you code (with "unsigned int") I get the warning, too. For "unsigned char", I don't. No warnings in either case for "> 0" (as opposed to ">= 0". ___ Reply to this item at:

[bug #34530] make (ab)uses the ASCII grave accent (0x60) as a left single quotation mark

Follow-up Comment #6, bug #34530 (project make): The strings are the keys to the translation lookup table, yes. So changing the string changes the lookup key. I don't know what you mean by "change the hashes at our end"? The hashes are generated at runtime by the gettext library when you ask fo

[bug #34608] comparison of unsigned expression < 0 is always false

Follow-up Comment #6, bug #34608 (project make): This is what I get: $ cat foo.c #define INTEGER_TYPE_SIGNED(t) !((t) -1 >= 0) int foo() { return INTEGER_TYPE_SIGNED(unsigned int); } $ gcc --version gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5 $ gcc -Wextra -g -c -o foo.o foo.c foo.c: In function

[bug #34608] comparison of unsigned expression < 0 is always false

Follow-up Comment #5, bug #34608 (project make): You mentioned !((t) -1 >= 0) . I do not get any warnings when using that in the mentioned code sample compiled with -Wall -Wextra and GCC 4.4.5. What warnings do you get? ___ Reply to this i

[bug #34530] make (ab)uses the ASCII grave accent (0x60) as a left single quotation mark

Follow-up Comment #5, bug #34530 (project make): I was assuming that the strings itself are they keys, already. Would technically be possible for us to fix the hashes on our end to save the translators the trouble but still fix the trouble? I'm unsure if bouncing this back up to GNU level is a st

[bug #34608] comparison of unsigned expression < 0 is always false

Update of bug #34608 (project make): Status: Not A Bug => None Open/Closed: Closed => Open ___ Reply to this item at:

[bug #34608] comparison of unsigned expression < 0 is always false

Follow-up Comment #4, bug #34608 (project make): Can you re-open the bug until you made a decision? ___ Reply to this item at: ___ Message sent via/by S

[bug #34530] make (ab)uses the ASCII grave accent (0x60) as a left single quotation mark

Follow-up Comment #4, bug #34530 (project make): Eli: Using '' or "" instead of `' is also pure ASCII...? I agree with Markus, really, that this is a throwback to broken terminal fonts from the 1980's, that it looks ugly in virtually every font available today, and I don't see any reason to perpe

[bug #34608] comparison of unsigned expression < 0 is always false

Follow-up Comment #3, bug #34608 (project make): Hm. This change is not identical to the original. To get that you'd need to write !((t) -1 >= 0) and if you do that then GCC warns again. However I'm not aware offhand of any numeric implementations where casting a -1 to an unsigned value yields

[bug #34530] make (ab)uses the ASCII grave accent (0x60) as a left single quotation mark

Follow-up Comment #3, bug #34530 (project make): If Markus is on a crusade for it, does that make him wrong? I thought we were on a joint crusade for free software with GNU make. Paul, are you sure such a change would even be hitting translators? Either `foo' has been translated to `foo' so we k

[bug #34530] make (ab)uses the ASCII grave accent (0x60) as a left single quotation mark

Follow-up Comment #2, bug #34530 (project make): I wouldn't worry about this. Markus is on a crusade to eliminate the use of `...' for many years. By contrast, in GNU projects it's a long-standing tradition and at least a de-facto standard to use this kind of quoting, because it's pure ASCII. S

[bug #34608] comparison of unsigned expression < 0 is always false

Follow-up Comment #2, bug #34608 (project make): Thanks for these details. Let me propose #define INTEGER_TYPE_SIGNED(t) !((t) -1 > 0) for a warning-less replacement then. Like it? Please re-open the bug for me, as I lack permissions to. I used the program below with # gcc -Wall -Wextra

[bug #34530] make (ab)uses the ASCII grave accent (0x60) as a left single quotation mark

Update of bug #34530 (project make): Status:None => Later Triage Status:None => Medium Effort ___ Follow-up Comment #1: I'm not too excited ab

[bug #34608] comparison of unsigned expression < 0 is always false

Update of bug #34608 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: It turns out that this

[bug #34806] target-specific variable with conditional assignment generates garbage

Follow-up Comment #2, bug #34806 (project make): Would it be easy to isolate the related patch for you? If so, distros could integrate that before 3.83 comes out. So if it's easy, please attach the patch applied. Thanks! ___ Reply to thi

[bug #34806] target-specific variable with conditional assignment generates garbage

Update of bug #34806 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #1: This has already been

Re: [rfc] Colorized output for GNU make?

On Fri, 2011-11-11 at 22:42 +0100, Sebastian Pipping wrote: > the copyright assignment form reached the FSF more than a week ago. > > Would be great to get some more review on my patch now. > I don't mind if on-list, off-list, half-half... Hi Sebastian. I got notified by the FSF that your discla