On 2/27/14, 2:02 PM, Nicholas Nethercote wrote:
So I'm pleased to hear that -W{sometimes,maybe}-initialized have lower
false positive rates. Investigating them sounds like the most
promising avenue for progress.
Just to be clear: gcc's -Wmaybe-uninitialized is still very spammy.
gcc's -Wuninit
On Thu, Feb 27, 2014 at 07:33:39PM +0900, Mike Hommey wrote:
> On Thu, Feb 27, 2014 at 01:30:58AM +0100, Andreas Gal wrote:
> >
> > Could we compress major parts of omni.ja en block? We could for
> > example stick all JS we load at startup into a zip with zero
> > compression and then compress tha
- Original Message -
> On 2/27/2014 10:00 AM, Nathan Froyd wrote:
> > - If there is a TEST-FAIL or a TEST-UNEXPECTED-PASS, then the failure
> > itself is logged, along with some number of messages (currently capped at
> > 100) since the start of the test or the last failure. The intent her
On Thu, Feb 27, 2014 at 12:44 PM, Zack Weinberg wrote:
>>>
>> Treating these as warnings, not errors, is probably the best thing
>> here. If you see the warning and you've recently changed that
>> code, then check it. If you haven't, you see the "may be" and
>> ignore it.
>
> This is exactly the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/2014 12:57 PM, L. David Baron wrote:
>> I also defy anyone to demonstrate a measurable performance impact
>> from the tiny amount of additional machine code that might be
>> emitted if we added initializations to squelch all those
>> warnings.
I think it would be nice if there were a way of suppressing
the warning on a case-by-case basis, like with an
__attribute__((uninitialized)) or something. We could add
that annotation to places where we know not initializing
is safe, and treat the remaining cases as errors.
Cheers,
Botond
- O
On 2/27/2014 10:00 AM, Nathan Froyd wrote:
- If there is a TEST-FAIL or a TEST-UNEXPECTED-PASS, then the failure itself is
logged, along with some number of messages (currently capped at 100) since the
start of the test or the last failure. The intent here was to provide most of
the benefits
On Thursday 2014-02-27 15:44 -0500, Zack Weinberg wrote:
> This is exactly the same thing dbaron said the last time I brought
> this up (quite some time ago - 2010, maybe?) I didn't buy it then and
> I don't buy it now. I think it is far more likely that a
> maybe-used-uninitialized true positive
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/27/2014 03:11 PM, Karl Tomlinson wrote:
> Daniel Holbert writes:
>
>> On 02/27/2014 10:26 AM, Zack Weinberg wrote:
>>> Does that mean a patch to squelch the uninitialized variable
>>> warnings in layout will now be accepted? Those are the on
Daniel Holbert writes:
> On 02/27/2014 10:26 AM, Zack Weinberg wrote:
>> Does that mean a patch to squelch the uninitialized variable
>> warnings in layout will now be accepted? Those are the only
>> warnings in layout on my (Linux, debug) builds.
>>
>>> layout/base/FrameLayerBuilder.cpp:3462:56
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/2014 10:26 AM, Zack Weinberg wrote:
> Does that mean a patch to squelch the uninitialized variable
> warnings in layout will now be accepted? Those are the only
> warnings in layout on my (Linux, debug) builds.
>
>> layout/base/FrameLayerBui
On 2/27/14, 10:26 AM, Zack Weinberg wrote:
Does that mean a patch to squelch the uninitialized variable warnings
in layout will now be accepted? Those are the only warnings in layout
on my (Linux, debug) builds.
configure.in sets gcc -Wno-error=maybe-uninitialized, but perhaps it
should simpl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/23/2014 11:54 PM, Daniel Holbert wrote:
> On 02/22/2014 12:26 PM, Hubert Figuière wrote:
>
> FWIW, I (and others) have been working on that, as a side project,
> for a while now, and I think we're actually in pretty good shape
> right now.
>
On 2/27/2014, 12:30 AM, Axel Hecht wrote:
The feature of zip we want is the index, that let's us seek to a
position in the bundle and start unpacking, just given the filename.
How hard is to actually create a datastructure for the same purpose for
a tar.xz or so? I don't know really anything abo
On Thu, Feb 27, 2014 at 6:27 AM, Benjamin Smedberg wrote:
> On 2/26/2014 4:36 PM, Bobby Holley wrote:
>
>> On Wed, Feb 26, 2014 at 12:58 PM, Wesley Hardman > >wrote:
>>
>> It seems like it would be trivial to add a button in the Preferences UI to
>> let people precache all dynamically-loaded data.
Hi,
Mochitest (M1, M2, M3, M4, M5, and M-oth on TBPL) logging has seen several
changes over the past couple of weeks. The intent of these changes is to
reduce the runtime of the tests, particularly for tests which produce many
messages, and reduce the log file sizes. The current status on inb
On 2/26/2014 4:36 PM, Bobby Holley wrote:
On Wed, Feb 26, 2014 at 12:58 PM, Wesley Hardman wrote:
It seems like it would be trivial to add a button in the Preferences UI to
let people precache all dynamically-loaded data.
I don't think that would be trivial. In particular, which spellchecking
On 2014-02-27, 7:40 AM, Neil wrote:
On 2014-02-24, 1:25 PM, Chris Peterson wrote:
To avoid developers and reviewers from having to remember special
cases, maybe MOZ_ARRAY_LENGTH should just be the standard everywhere.
They're not quivalent.
Would you mind xpanding on that?
Sure. mozilla:
Andreas Gal wrote:
Could we compress major parts of omni.ja en block? We could for example stick
all JS we load at startup into a zip with zero compression and then compress
that into an outer zip. I think we already support nested containers like that.
Assuming your math is correct even with
Ehsan Akhgari wrote:
On 2014-02-26, 4:52 AM, Neil wrote:
The one that I spotted is that MSVC is unable to optimise static
variables, e.g. when you write static const length =
ArrayLength(array); If you write this as a local then the compiler is
able to optimise it away in release builds.
S
On Fri, Feb 21, 2014 at 11:38 PM, Nicholas Nethercote
wrote:
> We now live in a memory-constrained world. By "we", I mean anyone
> working on Mozilla platform code.
I realize that .so size matters much less than per-process
heap-allocated stuff, but still:
On the i18n front, there are binary siz
On Thu, Feb 27, 2014 at 01:30:58AM +0100, Andreas Gal wrote:
>
> Could we compress major parts of omni.ja en block? We could for
> example stick all JS we load at startup into a zip with zero
> compression and then compress that into an outer zip. I think we
> already support nested containers lik
On Thu, Feb 27, 2014 at 09:30:22AM +0100, Axel Hecht wrote:
> The feature of zip we want is the index, that let's us seek to a
> position in the bundle and start unpacking, just given the filename.
>
> How hard is to actually create a datastructure for the same purpose
> for a tar.xz or so? I don'
The feature of zip we want is the index, that let's us seek to a
position in the bundle and start unpacking, just given the filename.
How hard is to actually create a datastructure for the same purpose for
a tar.xz or so? I don't know really anything about the uncompression
algorithms to know
24 matches
Mail list logo
