On Fri, May 28, 2010 at 5:21 AM, Marcus G. Daniels wrote:
> Hi all,
>
> For the purposes of static analysis, can the output of
> -fdump-tree-original-raw complete for reconstructing GENERIC data?
To reconstruct GIMPLE completely? No. All data types definitions are
missing, for example.
Depending
Basile -
FYI I have started a page on gengtype and its improvement areas:
http://gcc.gnu.org/wiki/gengtype . Maybe you'd like to add some notes
there on e.g. what enhancements are required for better plugin support
and similar.
Cheers,
--
Laurynas
On Fri, May 28, 2010 at 12:28:57PM +0200, Laurynas Biveinis wrote:
> Basile -
>
> FYI I have started a page on gengtype and its improvement areas:
> http://gcc.gnu.org/wiki/gengtype . Maybe you'd like to add some notes
> there on e.g. what enhancements are required for better plugin support
> and
Hi,
I just noticed today that (implicit) loops of the kind
xmin = minval(nodes(1,inductor_number(1:number_of_nodes)))
(lines 5057 to 5062 of the polyhedron test induct.f90) are no longer
vectorized (the change occurred between revisions 158215 and
158921). With -ftree-vectorizer-verbose=
On 05/28/2010 06:36 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
Dear GCC developers,
Would you please consider suppressing (relatively new) warnings like
this one:
ignoring return value of 'int chdir(const char*)', declared with
attribute warn_unused_result
in cases when the source code ex
On 05/26/2010 07:03 PM, Ulrich Weigand wrote:
This is the reason why we implemented TARGET_ADDR_SPACE_KEYWORDS as
macro (note that all the other address-space related back-end
callbacks were already implemented as hooks to begin with).
One nice cleanup would be to merge the per-address-space ho
On Tue, May 11, 2010 at 6:39 AM, Marc Glisse
wrote:
> On Tue, 11 May 2010, Jakub Jelinek wrote:
>
>> And you can use -Wl,-O1 (pass -O1 to the linker) to let the linker
>> determine optimal size of the hash table (minimum number of collisions
>> for reasonably sized section).
>
> Was it considered
Hi Paolo,
Can this design please be changed (or, dare I say without being considered
impolite, improved) to better accommodate for the cases where there is indeed
no reason for checking the return value?
Making the developers jump through more complicated ad hoc hoops (instead of
just void-cas
Hi,
I want to generate vzeroupper when I know upper 128bits aren't used. I
can't find
a way to mark an pattern which zeros upper 128bits. So I added
;; Clear the upper 128bits of AVX registers, equivalent to a NOP.
;; This should be used only when the upper 128bits are unused.
(define_insn "avx_v
On Fri, May 28, 2010 at 18:12, Vakatov, Denis (NIH/NLM/NCBI) [E]
wrote:
> Hi Paolo,
>
> Can this design please be changed
By saying "by design" I was implying that it won't.
FWIW I agree with you, but I'm also very undecided whether it is not
glibc that was too greedy in applying __wur (which al
Quentin Neill writes:
> A little off topic, but by what facility does the compiler know the
> linker (or assembler for that matter) is gnu?
When you run configure, you can specify --with-gnu-as and/or
--with-gnu-ld. If you do, the compiler will assume the GNU assembler
or linker. If you do not
> By saying "by design" I was implying that it won't.
-- It's like saying "by divine design" then. Because, human-made designs
usually can -- and oftentimes should -- be changed :-).
Just think about it. All these little caveats work *against* the main cause,
and they accumulate with time.
>
"Vakatov, Denis (NIH/NLM/NCBI) [E]" writes:
> Can this design please be changed (or, dare I say without being
> considered impolite, improved) to better accommodate for the cases
> where there is indeed no reason for checking the return value?
>
> Making the developers jump through more complicat
On 5/28/2010 11:14 AM, Ian Lance Taylor wrote:
Quentin Neill writes:
A little off topic, but by what facility does the compiler know the
linker (or assembler for that matter) is gnu?
When you run configure, you can specify --with-gnu-as and/or
--with-gnu-ld. If you do, the compiler
Ian Lance Taylor wrote:
> We should handle must_use_result and warn_unused_result similarly, except
> that adding a cast to (void) disables the warn_unused_result warning.
> Perhaps there should also be other simple ways to disable the
> warn_unused_result warning.
>
> This is not a great solu
"Vakatov, Denis (NIH/NLM/NCBI) [E]" writes:
> Ian Lance Taylor wrote:
>
>> We should handle must_use_result and warn_unused_result similarly, except
>> that adding a cast to (void) disables the warn_unused_result warning.
>> Perhaps there should also be other simple ways to disable the
>> war
On Fri, May 28, 2010 at 11:25 PM, Ian Lance Taylor wrote:
> "Vakatov, Denis (NIH/NLM/NCBI) [E]" writes:
>
>> Ian Lance Taylor wrote:
>>
>>> We should handle must_use_result and warn_unused_result similarly, except
>>> that adding a cast to (void) disables the warn_unused_result warning.
>>> Pe
Tim Prince writes:
> On 5/28/2010 11:14 AM, Ian Lance Taylor wrote:
>>
>> When you run configure, you can specify --with-gnu-as and/or
>> --with-gnu-ld. If you do, the compiler will assume the GNU assembler
>> or linker. If you do not, the compiler will assume that you are not
>> using th
On 05/28/10 10:38, H.J. Lu wrote:
Hi,
I want to generate vzeroupper when I know upper 128bits aren't used. I
can't find
a way to mark an pattern which zeros upper 128bits. So I added
Presumably you can't use a zero_extract?
[ ... ]
before IRA,
(insn 2 4 3 2 x.i:9 (set (reg/v:V8SF 59 [ y
Ian Lance Taylor wrote:
> [...] developers can not always be trusted. Instead, we assume that there at
> least one trusted developer who can add warn_unused_result when
> appropriate. Then the compiler arranges matters such that other developers
> can not easily avoid the warning. Thus securi
On Fri, May 28, 2010 at 3:03 PM, Jeff Law wrote:
> On 05/28/10 10:38, H.J. Lu wrote:
>>
>> Hi,
>>
>> I want to generate vzeroupper when I know upper 128bits aren't used. I
>> can't find
>> a way to mark an pattern which zeros upper 128bits. So I added
>>
>
> Presumably you can't use a zero_extract
"Vakatov, Denis (NIH/NLM/NCBI) [E]" writes:
> The problem with the suggested scenario with one trusted developer
> that uses this option is that other developers won't see these
> warnings at all. However, IMO we can have our cake and eat it too --
> and, leave most of the involved parties genera
On 28/05/2010 19:32, Ian Lance Taylor wrote:
> As the compiler documentation states, warn_unused_result was intended
> for cases where failing to check the return value is always a security
^^
Note: "always".
> risk or a bug.
OK,
On 28/05/2010 22:25, Ian Lance Taylor wrote:
> "Vakatov, Denis (NIH/NLM/NCBI) [E]" > The reasonable (or, "great enough") solution would be to just trust
>> explicit developer's void-casting.
>>
>> Also, 'warn_unused_result' should be enough; there is no need to add
>> more levels to this simple par
Dave Korn writes:
> On 28/05/2010 19:32, Ian Lance Taylor wrote:
>
>> As the compiler documentation states, warn_unused_result was intended
>> for cases where failing to check the return value is always a security
>^^
> Note: "always
Dave Korn writes:
> On 28/05/2010 22:25, Ian Lance Taylor wrote:
>
>> The warn_unused_result extension was implemented specifically to catch
>> security problems. Permitting developers to just add a cast to void
>> would make it a very weak facility.
>
> But it's a weak and fundamentally flawe
On 29/05/2010 01:17, Ian Lance Taylor wrote:
> Dave Korn writes:
>
>> On 28/05/2010 22:25, Ian Lance Taylor wrote:
>>
>>> The warn_unused_result extension was implemented specifically to catch
>>> security problems. Permitting developers to just add a cast to void
>>> would make it a very weak f
On 29/05/2010 01:14, Ian Lance Taylor wrote:
> Dave Korn > there is *no* circumstances
>> under which ignoring the return from *any* function is *always* a bug.
> For practical purposes, it is always a bug to ignore the return value
> of realloc (I disregard the unusual case of passing 0 as the
On 05/28/2010 12:38 PM, H.J. Lu wrote:
Hi,
I want to generate vzeroupper when I know upper 128bits aren't used. I
can't find
a way to mark an pattern which zeros upper 128bits. So I added
;; Clear the upper 128bits of AVX registers, equivalent to a NOP.
;; This should be used only when the uppe
29 matches
Mail list logo
