On 02/12/15 12:34, Bernd Edlinger wrote:
> Hi,
>
>> Surely in code like that, you would make "x" volatile? Memory clobbers
>> are not a substitute for correct use of volatile accesses.
>
> No,
>
> It is as I wrote, a memory clobber is the only way to guarantee that
> the asm statement is not mo
On 12/2/2015 3:34 AM, Bernd Edlinger wrote:
Hi,
Surely in code like that, you would make "x" volatile? Memory clobbers
are not a substitute for correct use of volatile accesses.
No,
It is as I wrote, a memory clobber is the only way to guarantee that
the asm statement is not move somewhere e
On 12/1/2015 7:41 PM, Jeff Law wrote:
> My strong preference is still to document the desired semantics for
GCC and treat anything that does not adhere to those semantics as a bug.
Despite nearly 100 posts over 2 threads, we don't seem to be reaching
either a consensus or a conclusion. How do
On 12/12/2015 1:51 AM, Andrew Haley wrote:
Solution 2:
Change the docs to say that basic asm clobbers everything (memory, all
registers, etc) or perhaps just memory (some debate here), but that due
to bugs that will eventually be addressed, it doesn't currently work
this way.
You've missed the m
Is there a decision maker still teetering on the edge of making a call
here? Or have they all moved on and we are just talking among
ourselves? I keep worrying that if I don't reply, someone will swoop
in, read the last message in the thread, and charge off to make a
changes based on that. S
Not enough to call it a consensus, but perhaps the beginning
of one:
- Andrew Haley
- David Wohlferd
- Richard Henderson
- Segher Boessenkool
- Bernd Schmidt
Anyone else want to add their name here?
Maybe it's the implementation details that have other people concerned.
My thought is tha
On 12/15/2015 12:42 PM, paul_kon...@dell.com wrote:
In the codebase for the product I work on, I see about 200 of them. Many of those are the likes of
asm("sync") for MIPS, which definitely wants to be treated as if it were asm ("sync" : :
: "memory").
That's right, I meant to ask you about
On 12/15/2015 1:13 PM, Jeff Law wrote:
Sadly, I'm putting most of this discussion into my gcc-7 queue anyway.
Fair enough. If "clobbers" is what we're going to do, that sounds more
like a phase 1 thing.
That said, some people who have this problem may prefer to fix it sooner
rather than la
On 12/15/2015 5:01 PM, paul_kon...@dell.com wrote:
On Dec 15, 2015, at 5:22 PM, David Wohlferd wrote:
On 12/14/2015 1:53 AM, Andrew Haley wrote:
This just seems like another argument for deprecating basic asm and pushing
people to extended.
Yes. I am not arguing against deprecation. We
On 12/15/2015 2:43 PM, Joseph Myers wrote:
On Tue, 15 Dec 2015, David Wohlferd wrote:
Unlike top level, using basic asm within a function is deprecated. No new code
should use this feature, but should use extended asm instead. Existing code
should begin replacing such usage. Instances of
On 17/12/15 11:39, Andrew Haley wrote:
> On 17/12/15 01:41, David Wohlferd wrote:
>> On the contrary, I would be surprised to learn that there are ANY
>> compilers (other than clang) that support gcc's extended asm format.
>
> Prepare to be surprised: Sun Studio co
On 12/17/2015 6:03 AM, Jeff Law wrote:
On 12/17/2015 03:39 AM, Andrew Haley wrote:
On 17/12/15 01:41, David Wohlferd wrote:
On the contrary, I would be surprised to learn that there are ANY
compilers (other than clang) that support gcc's extended asm format.
Prepare to be surprised
On 12/17/2015 11:30 AM, Bernd Edlinger wrote:
On Thu, 17 Dec 2015 15:13:07, Bernd Schmidt wrote:
What's your take on making -Wonly-top-basic-asm a default (either now or
v7)? Is making it a non-default a waste of time because no one will
ever see it? Or is making it a default too aggr
I am pleased to announce that the GCC Steering Committee has
appointed Martin Jambor as HSA maintainer.
Please join me in congratulating Martin on his new role.
Martin, please update your listing in the MAINTAINERS file.
Happy hacking!
David
On 12/18/2015 11:55 AM, Bernd Edlinger wrote:
On 18.12.2015 10:27, David Wohlferd wrote:
On 12/17/2015 11:30 AM, Bernd Edlinger wrote:
Adding this warning to -Wall is too quickly and will bring the ia64,
tilegx and mep ports into trouble.
It doesn't look to me like adding the warnings
I have been discussing adding some content to the basic asm docs. As
part of this work, I want to add a discussion of "How to convert basic
asm to extended asm." However it doesn't seem like this is a good fit
for the User Guide. This is both because the UG doesn't generally talk
about "How T
On 12/20/2015 10:26 AM, Bernd Edlinger wrote:
On 19.12.2015 19:54, David Wohlferd wrote:
mep: mep_interrupt_saved_reg looks for ASM_INPUT in the body, and
saves different registers if found.
I'm trying to follow this code. A real challenge since I know nothing
about mep. But what I s
On Mon, 2015-12-21 at 19:20 +0100, Marek Polacek wrote:
> On Mon, Dec 21, 2015 at 01:12:33PM -0500, Patrick Palka wrote:
> > GCC 6, compared to GCC 5, now emits an extra newline between error
> > messages. Is this intended?
> >
> > $ cat error.c
> > int x = a;
> > int y = b;
> > $ gcc-5 error.c
>
On Mon, 2016-01-11 at 15:20 +0800, Gerald Pfeifer wrote:
> Compiling Wine with GCC trunk (to become GCC 6) I noticed four
> dozen of warnings triggered by -Wmisleading-indentation.
>
> Some are simply weird formatting, some may be indicative of
> real issues -- and I have started to look into the
On 11/01/16 08:20, Gerald Pfeifer wrote:
Compiling Wine with GCC trunk (to become GCC 6) I noticed four
dozen of warnings triggered by -Wmisleading-indentation.
Some are simply weird formatting, some may be indicative of
real issues -- and I have started to look into them one by
one and submitti
On Mon, 2016-01-25 at 21:54 +, Manuel López-Ibáñez wrote:
> On 25 January 2016 at 20:17, Mikhail Maltsev wrote:
> > As I understand, the bug report suggests that we say "suggest || instead of
> > |
> > when joining booleans" instead. We now have the API to show fix-it hints,
> > so it
> > wo
On Fri, 2016-01-22 at 08:27 +0100, Matthias Klose wrote:
> On 22.01.2016 06:09, Martin Michlmayr wrote:
> > In terms of build failures, I reported 520 bugs to Debian. Most of them
> > were new GCC errors or warnings (some packages use -Werror and many
> > -Werror=format-security).
> >
> > Here are
It is well known that on i386, the "cc" clobber is always set for
extended asm, whether it is specified or not. I was wondering how much
difference it might make if the generated code actually followed what
the user specified (expectation: not much). But implementing this
turned up a differen
On Thu, 2016-01-28 at 21:07 +0100, Thomas Koenig wrote:
> Hello world,
>
> the attached patch fixes the regression of PR 60526 by checking for
> the presence of a type with the same name as the variable. Types
> effectively have their separate namespace because the names of their
> symtrees start
On 1/26/2016 4:31 PM, Bernd Schmidt wrote:
On 01/27/2016 12:12 AM, David Wohlferd wrote:
I started by just commenting out the code in ix86_md_asm_adjust that
unconditionally clobbered the flags. I figured this would allow the
'normal' "cc" handling to occur. But apparently
On 2/1/2016 6:58 AM, Ulrich Weigand wrote:
I think on many targets a clobber "cc" works because the backend
actually defines a register named "cc" to correspond to the flags.
Therefore the normal handling of clobbering named hard registers
catches this case as well.
This doesn't work on i386 bec
On 2/1/2016 12:40 PM, Richard Henderson wrote:
On 02/02/2016 01:58 AM, Ulrich Weigand wrote:
I think on many targets a clobber "cc" works because the backend
actually defines a register named "cc" to correspond to the flags.
Therefore the normal handling of clobbering named hard registers
catche
dd GCC Runtime Library Exception to include/plugin-api.h
>>> so that the linker plug-in can have non-GPL licenses.
>>
>> This is OK with me.
>>
>> -cary
>
> Here is a patch. OK for trunk?
You have not explained why this actually is needed and only the FSF
can agree to license changes.
- David
On Thu, 2016-02-04 at 02:31 +0530, Prasad Ghangal wrote:
> Hi !
> I am new to gcc. I would like to solve bug
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973 (Bug 49973 -
> Column
> numbers count special characters as multiple columns ). Can somebody
> guide me?
>
> I tried to debug gcc under
On Thu, 2016-02-11 at 19:54 +0100, Basile Starynkevitch wrote:
> Hello All,
>
> I am busy merging the GCC trunk branch (i.e. future GCC 6) into the
> MELT
> branch & plugin.
>
> I am noticing a strange thing.
>
> I was able to merge GCC trunk svn rev. 227945 into the MELT branch
> (svn
> rev.
gcc-python-plugin is a plugin for GCC 4.6 onwards which embeds the
CPython interpreter within GCC, allowing you to write new compiler
warnings in Python, generate code visualizations, etc.
It ships with "gcc-with-cpychecker", which implements static analysis
passes for GCC aimed at finding bugs in
t; > introspection
> > API?
>
> It's a proposal, follow the thread here (also up-thread). There were
> similar
> threads with another (python?) plugin API from David Malcom(?) IIRC.
>
> https://gcc.gnu.org/ml/gcc/2012-09/msg00098.html
>
> > In https://gcc.g
On Tue, 2016-02-16 at 12:25 +0530, Prasad Ghangal wrote:
> Hi !
> I am trying to fix bug 38612
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38612).
> As mentioned in comment 4, I am changing warning message in
> typeck2.c. TREE_TYPE(datum) gives type as 'X', but I want 'X*'
I believe you want
is that rpmlint gives an error on empty files, and macro_list
is empty at least for h8300 and sh64.
David
.h is empty at least for m68k.
David
On Thu, 2016-02-18 at 14:28 +, Manuel López-Ibáñez wrote:
> On 18/02/16 11:40, Prasad Ghangal wrote:
> > Wouldn't it be nice instead of multiple warnings if gcc gives
> > single
> > warning like :
> >
> > 68425.c:3:34: warning: excess elements in array initializer (6
> > elements, expected 2)
, David
I am pleased to announce that the GCC Steering Committee has
appointed David Malcolm as libcpp and diagnostic messages maintainer.
Please join me in congratulating David on his new role.
David, please update your listing in the MAINTAINERS file.
Happy hacking!
David
On Mon, 2016-02-22 at 11:14 -0500, David Edelsohn wrote:
> I am pleased to announce that the GCC Steering Committee has
> appointed David Malcolm as libcpp and diagnostic messages maintainer.
>
> Please join me in congratulating David on his new role.
> David, ple
Hi, Jim
On Mon, Feb 22, 2016 at 12:53 PM, Jim Wilson wrote:
> On Mon, Feb 22, 2016 at 7:55 AM, David Edelsohn wrote:
>> If I remove extendqihi2 (extend:HI pattern) from the PowerPC port,
>> will that cause any problems for the GCC RTL type system or inhibit
>> optimization
On 25/02/16 14:32, Stefan Ring wrote:
> On Thu, Feb 25, 2016 at 10:20 AM, Richard Earnshaw (lists)
> wrote:
>> The point is to permit the compiler to use interworking compatible
>> sequences of code when generating ARM code, not to force users to use
>> Thumb code. The necessary instruction (BX)
I was looking for an easy task to start contributing to gcc, so I
choose a "trivial" bug (69733) from this list (cited in an old message
of Manuel López-Ibáñez):
https://gcc.gnu.org/bugzilla/buglist.cgi?keywords=diagnostic&limit=0&li
st_id=99232&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&q
Tobias and Maxim were the recent coordinators.
On Thu, Mar 3, 2016 at 8:47 AM, Joel Sherrill wrote:
> I may have missed this comment but GCC wouldn't need to apply as it's own
> GSoC project. The GNU Project applied as an umbrella organization and was
> accepted. Any GCC activities would be und
On Wed, 2016-02-24 at 17:56 +0530, Prasad Ghangal wrote:
> Thanks Prathamesh and Joseph for your suggestions.
>
> Here is my updated patch :
>
> for test cases:
>
> const int array[5] = {1, 2, 3};
> const int array1[3] = {1, 2, 3, 6};
> const int array2[4] = {1, 2, 3, 6, 89};
> c
sed changes to the heuristics may
benefit for the particular set of workloads that the framework tests
but why are those workloads and particular implementations of the
workloads representative for applications of interest to end users of
GCC? GCC is turned for an arbitrary set of workloads, but why are
the workloads from cTuning any better?
Thanks, David
On Mon, 2016-03-07 at 13:26 +0100, Richard Biener wrote:
> On Mon, Mar 7, 2016 at 7:27 AM, Prasad Ghangal <
> prasad.ghan...@gmail.com> wrote:
> > On 6 March 2016 at 21:13, Richard Biener <
> > richard.guent...@gmail.com> wrote:
> > >
> > > I'll be willing to mentor this. Though I'd rather have u
On Tue, 2016-03-08 at 16:56 +0100, Richard Biener wrote:
> On March 8, 2016 4:42:41 PM GMT+01:00, "Manuel López-Ibáñez" <
> lopeziba...@gmail.com> wrote:
> > On 08/03/16 00:24, Trevor Saunders wrote:
> > > > ...which suggests that we'd want to use gimple dumps as the
> > > > input
> > > > format to
On Tue, 2016-03-08 at 21:00 +, Manuel López-Ibáñez wrote:
> On 8 March 2016 at 16:47, David Malcolm wrote:
> > > > Isn't this what -fopt-info does?
> > > > https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html
> > >
> > > Yes.
> >
On Thu, 2016-03-10 at 11:50 +0100, Richard Biener wrote:
> On Thu, Mar 10, 2016 at 11:46 AM, Richard Biener
> wrote:
> > On Wed, Mar 9, 2016 at 8:45 PM, Manuel López-Ibáñez
> > wrote:
> > > On 9 March 2016 at 02:50, Trevor Saunders
> > > wrote:
> > > > On Tue, Mar 08, 2016 at 05:12:56PM -0500, D
On Mon, 2016-03-14 at 16:31 +0100, Andrey Tarasevich wrote:
> Hi,
>
> I have a source file with 700k lines of code 99% of which are
> printf() statements. Compiling this test case crashes GCC 5.3.0 with
> segmentation fault.
> Can such test case be considered valid
Yes.
> or source files of siz
On Mon, 2016-03-21 at 11:13 -0600, Jeff Law wrote:
> On 03/21/2016 11:15 AM, Trevor Saunders wrote:
> >
> > > I'll resist the urge for now to apply RAII principles in this
> > > code, but
> > > that'd probably a much cleaner way to think about the problem in
> > > general.
> >
> > I worked on a c
On Thu, 2016-03-24 at 14:31 +0100, Richard Biener wrote:
> On Thu, Mar 24, 2016 at 12:27 AM, Prasad Ghangal
> wrote:
> > Hi!
> >
> > I have attached my gsoc proposal, please review it. Let me know if
> > I
> > have missed or misunderstood anything
>
> Please re-word the Abstract, it is really we
2016-04-18 10:33 GMT+01:00 Richard Biener :
> On Mon, Apr 11, 2016 at 1:54 PM, Ilya Enkovich wrote:
>> 2016-04-10 3:34 GMT+03:00 David Guillen Fandos :
>>> On 07/04/16 09:09, Ilya Enkovich wrote:
>>>> 2016-04-07 0:49 GMT+03:00 David Guillen Fandos :
>>>&g
; etc as macros, since these are often used as
> method names in c++, but this would be a conforming
> libc implementation.
C++ headers cannot be included before GCC headers because some
systems, such as AIX, depend on macros defined in GCC system.h -- the
behavior of the system headers depend on definitions set by GCC. The
C++ headers would pull in system headers prior to the GCC headers and
cause build failures.
Thanks, David
I am pleased to announce that the GCC Steering Committee has
appointed Segher Boessenkool as rs6000/powerpc port co-maintainer.
Please join me in congratulating Segher on his new role.
Segher, please update your listing in the MAINTAINERS file.
Happy hacking!
David
On Wed, 2016-04-27 at 12:34 +0300, Cristina Georgiana Opriceana wrote:
> Hello,
>
> I tried to add a new global declaration of a pointer and I expected
> to
> see it in varpool nodes, but it does not appear there.
>
> ustackptr = build_decl (UNKNOWN_LOCATION,
> VAR_DE
As part of the work I've done on inline asm, I've been looking thru the
bugs for it. There appear to be a number that have been fixed or
overtaken by events over the years, but the bug is still open.
Is closing some of these old bugs of any value?
If so, how do I pursue this?
dw
On Mon, 2016-05-02 at 11:50 -0600, Martin Sebor wrote:
> Hi Jan,
>
> I just noticed the compilation errors in the attached file with
> the latest trunk. It seems as though your recent patch below may
> be incomplete:
>
>commit 46e5dccc6f188bd0fd5af4e9778f547ab63c9cae
>Author: hubicka
>
On Wed, 2016-05-04 at 18:15 +0200, Antonio Diaz Diaz wrote:
> [Please, CC me. I'm not subscribed to gcc@gcc.gnu.org].
>
> First of all, thank you very much for gcc.
>
> I am not an expert in gcc. Please, forgive any mistakes in this
> message. :-)
>
> After compiling all my projects with gcc-6.1
On 4/28/2016 2:01 AM, Richard Biener wrote:
On Thu, Apr 28, 2016 at 9:35 AM, David Wohlferd wrote:
As part of the work I've done on inline asm, I've been looking thru the bugs
for it. There appear to be a number that have been fixed or overtaken by
events over the years, but the bu
On 4/28/2016 9:41 AM, Martin Sebor wrote:
On 04/28/2016 01:35 AM, David Wohlferd wrote:
As part of the work I've done on inline asm, I've been looking thru the
bugs for it. There appear to be a number that have been fixed or
overtaken by events over the years, but the bug is still
On 4/28/2016 12:23 PM, Andrew Pinski wrote:
On Thu, Apr 28, 2016 at 12:35 AM, David Wohlferd
wrote:
As part of the work I've done on inline asm, I've been looking thru the bugs
for it. There appear to be a number that have been fixed or overtaken by
events over the years, but
Looking at the v6 release criteria
(https://gcc.gnu.org/gcc-6/criteria.html) there are about a dozen
supported platforms.
Looking at the Machine Constraints docs
(https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html), there are
34 architectures listed. That's a lot of entries to scrol
On 5/9/2016 6:42 AM, paul_kon...@dell.com wrote:
On May 8, 2016, at 6:27 PM, David Wohlferd wrote:
If these architectures aren't supported anymore, is it time to drop some of
these from this page?
Your theory is quite mistaken. A lot of the ones you labeled "drop" are
su
On Wed, 2016-06-01 at 12:49 +0530, Prathamesh Kulkarni wrote:
> On 30 May 2016 at 20:45, Prasad Ghangal
> wrote:
> > Hi,
> >
> > As David suggested in his rtlfe patch,
> > this patch recognizes __GIMPLE keyword and switches to
> > c_parser_parse_gimp
On Thu, 2016-06-02 at 14:46 -0500, Ethin Probst wrote:
[...snip...]
> (I've had to redo the
> compilation more than once because SSH decided to idle timeout and
> make noted the hangup, ending the compilation process immediately due
> to there being no TTY to send messages to, even though I'd had t
I am pleased to announce that the GCC Steering Committee has
appointed Jon Y as Cygwin and mingw-w64 maintainer.
Please join me in congratulating Jon on his new role.
Jon, please update your listing in the MAINTAINERS file.
Happy hacking!
David
Perhaps this post should be directed toward port maintainers?
Since several global maintainers have now suggested it, I have created a
patch that deprecates basic asm when used in a function (attached). It
excludes (ie does not deprecate) top level asm, asm in "naked"
functions, asm with empt
In the end, my problems with basic-asm-in-functions (BAIF) come down to
reliably generating correct code.
Optimizations are based on the idea of "you can safely modify x if you
can prove y." But given that basic asm are opaque blocks, there is no
way to prove, well, much of anything. Adding
On 6/21/2016 9:43 AM, Jeff Law wrote:
> I think there's enough resistance to deprecating basic asms within a
function that we should probably punt that idea.
I don't disagree that there has been pushback. I just wish less of it
was of the form "Because I don't wanna." A few examples of "Here
A user filed a bug about a bad location in a warning. It was marked as
an "easyhack" in bugzilla, and I had a go at fixing it.
I though it may be useful for new GCC developers if I document what I
did to fix it.
FWIW, the bug was PR c/71610
i.e. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=716
[spr] "i" (sp) ); \
res; })
#define writeSpr(sp, va) \
asm volatile (" mtspr %[spr], %[val] " : \
: \
[spr] "i" (sp), [val] "r" (va) )
mvh.,
David
On 08/07/16 16:16, Tran Tu Truong wrote:
> Dear
development of the compiler itself.
mvh.,
David
On 13/07/16 16:39, tutruong0...@gmail.com wrote:
> Hi,
>
> Thank you for your answer.
> It is very useful for me.
>
> Best regards;
>
> Truong TT
>
>> On Jul 8, 2016, at 11:07 PM, David Brown wrote:
>>
>>
On Tue, 2016-07-19 at 00:52 +0530, Prasad Ghangal wrote:
> On 19 July 2016 at 00:25, Richard Biener
> wrote:
> > On July 18, 2016 8:28:15 PM GMT+02:00, Prasad Ghangal <
> > prasad.ghan...@gmail.com> wrote:
> > > On 15 July 2016 at 16:13, Richard Biener <
> > > richard.guent...@gmail.com>
> > > wro
libcpp/charset.c has a helpful introductory comment describingcharacter
sets, including the source and execution character sets.
libcpp appears to attempt to support both UTF-8 and UTF-EBCDIC for the
source character set, via:
#if HOST_CHARSET == HOST_CHARSET_ASCII
#define SOURCE_CHARSET "UTF-8"
On Tue, Jul 19, 2016 at 12:05 PM, David Malcolm wrote:
> libcpp/charset.c has a helpful introductory comment describingcharacter
> sets, including the source and execution character sets.
>
> libcpp appears to attempt to support both UTF-8 and UTF-EBCDIC for the
> source cha
On Tue, 2016-07-19 at 12:24 -0400, David Edelsohn wrote:
> On Tue, Jul 19, 2016 at 12:05 PM, David Malcolm
> wrote:
> > libcpp/charset.c has a helpful introductory comment
> > describingcharacter
> > sets, including the source and execution character sets.
> >
&g
Hi, David
I don't believe that hardware easily is available. We probably could
arrange for access, if it is necessary, but it is not accessible
through the IBM Community Development system for Linux on z Systems
because this isn't Linux-based. GCC on the system is not self-hosting
--
On Tue, 2016-07-19 at 16:10 -0700, David Edelsohn wrote:
> Hi, David
>
> I don't believe that hardware easily is available. We probably could
> arrange for access, if it is necessary, but it is not accessible
> through the IBM Community Development system for Linux on z Sy
On 26/07/16 16:55, Warren D Smith wrote:
> On 7/26/16, Joseph Myers wrote:
>> On Tue, 26 Jul 2016, Warren D Smith wrote:
>>
>>> (And in the case of uint4_t, it actually would not even BE an
>>> "extension" since as I said,
>>> the standard already allows providing other sizes.)
>>
>> Only sizes wh
On 26/07/16 16:37, Warren D Smith wrote:
You would get on far better here if you tried a little politeness and
respect, rather than anger, accusations and confrontation.
The C standards were written by a group of very smart and experienced
people, refined over a long time based on real-world issu
I am assuming you intended to post this on the mailing list, so I have
restored the addresses.
On 26/07/16 19:55, Warren D Smith wrote:
> To the guy who falsely claimed MIPS fails to provide an add with carry
> instruction,
> a google search in 1 minute finds this:
>
> stackoverflow.com/questions
On 26/07/16 21:06, Warren D Smith wrote:
> OK, you just said you've used packed nybble arrays a couple of times.
Yes, a couple of times in 20+ years. And I work with the kind of
programming where something like nibble arrays could conceivably be
useful. For most C programmers, "int" is the only
On 29/07/16 10:25, Fredrik Hederstierna wrote:
> Some processor architectures do support bitwise access to memory, eg. ARM
> Cortex-M and 8051 (by ARM called bit-banding).
> In these architectures a single bit can somewhat be addressable, but only as
> an 'aliased' memory region for another memo
be appropriate.
gnulib does not have any support for the simple-object API to read and
write object files in different file formats.
- David
On 29/07/16 18:26, Warren D Smith wrote:
Booleans are very useful - they turn up all over the place in programming.
Nibbles, on the other hand, are almost totally useless. There are very,
very few situations where you need to store a number that is within the
range 0 .. 15, and are so tightly c
On 29/07/16 20:54, Warren D Smith wrote:
> On 7/29/16, Jonathan Wakely wrote:
>> Let's imagine we have a 4-bit type, called nibble.
>>
>> sizeof(nibble) == 1, because you can't have an object with a smaller size.
>>
>> nibble a[2];
>> sizeof(a) == 1;
>>
>> Because otherwise there isn't much benefi
I'm looking at gcc/config/i386/avx512fintrin.h, and I see this:
extern __inline __m256i
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
_mm512_cvtsepi64_epi32 (__m512i __A)
{
__v8si __O;
return (__m256i) __builtin_ia32_pmovsqd512_mask ((__v8di) __A,
On 17/08/16 02:21, Toshi Morita wrote:
I was involved in a discussion over the semantics of "const" in C, and the
following code was posted:
#include
int foo = 0;
const int *pfoo = &foo;
void bar (void)
{
foo +=3D;
I assume that's a typo?
}
int main(void)
{
int a, b;
a = *pfoo
On 18/08/16 00:44, Toshi Morita wrote:
> David Brown wrote:
>
>> No, it would not be valid. Declaring pfoo as a "const int*" tells the
>> compiler "I will not change anything via this pointer - and you can
>> optimise based on that promise". It doe
According to the docs
(https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html),
__builtin_ia32_fxsave() has return type 'void.' Given that, does this
code (from gcc/config/i386/fxsrintrin.h) make sense?
_fxsave (void *__P)
{
return __builtin_ia32_fxsave (__P);
}
Ret
Best regards,
lh_mouse
2016-08-19
-----
发件人：David Wohlferd
发送日期：2016-08-19 11:51
收件人：gcc@gcc.gnu.org
抄送：
主题：fxsrintrin.h
According to the docs
(https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html),
__builtin_ia32_fxsave() has return type 'void.'
On Fri, 2016-09-02 at 11:19 +0200, Richard Biener wrote:
> There seems to be plenty of slots available on the 2nd track to
> schedule additional BOFs. So I'd gather if there is interest
> in discussing
>
> A) Unit testing (GIMPLE FE, RTL FE, the existing unit-testing),
> basically how people
On Fri, 2016-09-09 at 14:28 +0200, Florian Weimer wrote:
> For compile-time fortify checks (such as the wrappers for type-safe
> open/openat), we need to add tests in glibc which examine the
> compiler
> output for warnings and errors.
>
> I do not want to add Dejagnu as a dependency to the glib
From: Eric Botcazou
Date: Fri, 16 Sep 2016 23:43:43 +0200
>> p.s. Are there plans for converting the SPARC port?
>
> There are more than plans - actual patches by DaveM that were installed at
> some point and then reverted quickly because of unexpected fallout.
Yeah, sparc64 failed to bootstr
From: Eric Botcazou
Date: Sat, 17 Sep 2016 10:18:23 +0200
>> I lacked the time to debug it properly so we reverted.
>
> Do you plan to give it a try again in the near future?
I was going to work on this over the past summer, but other
responsibilities took up all of my time.
Probably the earli
On Mon, 2016-09-19 at 10:09 +0200, Richard Biener wrote:
> On Mon, Sep 19, 2016 at 3:52 AM, Swati Rathi <
> swatira...@cse.iitb.ac.in> wrote:
> > Hello,
> >
> > We want to fetch fields of a record type from the formal arguments
> > of a
> > function.
> > For a RECORD_TYPE, we fetch the fields usin
On 22/09/16 09:23, Sebastian Huber wrote:
> Hello,
>
> for RTEMS we use linker sets to initialize the system. The following
> code worked up to GCC 6, but no longer in GCC 7:
>
> typedef void ( *rtems_sysinit_handler )( void );
>
> typedef struct {
> rtems_sysinit_handler handler;
> } rtems_sy
On 22/09/16 16:57, paul.kon...@dell.com wrote:
>
>> On Sep 22, 2016, at 6:17 AM, David Brown wrote:
>>
>> ...
>> Your trouble is that your two pointers, cur and end, are pointing at
>> different variables. Comparing two pointers that are independent (i.e.,
>
On 22/09/16 17:30, Richard Biener wrote:
On September 22, 2016 5:20:56 PM GMT+02:00, paul.kon...@dell.com
wrote:
On Sep 22, 2016, at 11:16 AM, David Brown
wrote:
On 22/09/16 16:57, paul.kon...@dell.com wrote:
On Sep 22, 2016, at 6:17 AM, David Brown
wrote:
... Your trouble is that
401 - 500 of 2761 matches
Mail list logo
