<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel">
    <title>gmane.comp.gcc.devel</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126824"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126823"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126822"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126821"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126820"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126819"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126817"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126815"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126814"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126813"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126812"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126811"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126810"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126809"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126808"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126807"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126806"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126805"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126804"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gcc.devel/126803"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126824">
    <title>Vectorizer question</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126824</link>
    <description>&lt;pre&gt;Hello Everyone,
I have a question regarding the vectorizer. In the following code below...

Int func (int x, int y)
{
If (x==y)
Return (x+y);
Else
Return (x-y);
}

If we force the x and y to be vectors of vectorlength 4, then will the if-statement get a vector of booleans or does it get 1 boolean that compares 2 very large values? I guess another way to ask is that, will it logically break it up into 4 if-statements or just 1?

Any help is greatly appreciated!

Thanks,

Balaji V. Iyer.

PS. Please CC me in response  so that I can get to it quickly.

&lt;/pre&gt;</description>
    <dc:creator>Iyer, Balaji V</dc:creator>
    <dc:date>2012-05-16T23:01:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126823">
    <title>announce: The C Conference; San Diego, CA; August 28th</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126823</link>
    <description>&lt;pre&gt;The first C Conference is happening in San Diego, CA on August 28th
2012. It is focused on the C programming language and modern
developments in that ecosystem.  The conference is co-located with
LinuxCon and Linux Plumbers Conference.

  http://www.cconf.org/

The "Reverse CFP" is open now and tickets are available. Let us know
what you want to see at the conference.

  http://www.cconf.org/pfc/

See you there.

Brandon

&lt;/pre&gt;</description>
    <dc:creator>Brandon Philips</dc:creator>
    <dc:date>2012-05-16T20:28:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126822">
    <title>Probably inaccuracy in GCC 4.7.0 documentation.</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126822</link>
    <description>&lt;pre&gt;Hello, GNU GCC team.

It seems like I've found an inaccuracy in GCC 4.7.0 documentation. It is about -fdefer-pop optimization option. The point is that this option is mentioned in the list of optimization flags which -O1 turns on (Chapter 3: GCC Command Options, part 3.10 Options That Control Optimization, page 107/766 of http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc.pdf), but there are no any other allusions to -fdefer-pop in the document, even in 3.1 Option Summary, where it is expected to be. There is no explanation of what this flag does in HTML version of the document too (here [http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Optimize-Options.html#Optimize-Options] and here [http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Option-Summary.html#Option-Summary]). I'm guessing that this flag is not further supported by G
 CC, or not yet implemented.

The statements above are valid for May 16, 2012.

May I give you my best wishes,
Roman Sazhenkov

&lt;/pre&gt;</description>
    <dc:creator>Роман Саженков</dc:creator>
    <dc:date>2012-05-16T07:37:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126821">
    <title>Re: How do I set SIG_ATOMIC_TYPE to a variant of a C-type?</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126821</link>
    <description>&lt;pre&gt;

I just assumed that was the case, what with other ___xxx_TYPE__
being used throughout the test-suite.  My bad.


What I missed was more careful reading, the clue being: "The
string must exactly match one of the data type names defined in
the function..."  Hah, there you go, thanks and sorry for the
noise.

brgds, H-P

&lt;/pre&gt;</description>
    <dc:creator>Hans-Peter Nilsson</dc:creator>
    <dc:date>2012-05-15T21:44:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126820">
    <title>Re: How do I set SIG_ATOMIC_TYPE to a variant of a C-type?</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126820</link>
    <description>&lt;pre&gt;

GCC only needs to know this type for the purposes of defining limits for 
stdint.h.  Unless your signal.h does

typedef __SIG_ATOMIC_TYPE__ sig_atomic_t;

this should only affect the testcases gcc.dg/c99-stdint-[56].c, not actual 
user code.  And as you have discovered, there are rules for these type 
strings documented in tm.texi under SIZE_TYPE; to use some other variant 
you'll need to find and eliminate all the dependencies on whatever rule 
you wish to change.

Logically these macros should be hooks returning enumeration values from a 
defined set of possible types, not strings at all.  See past discussions 
with Joern, e.g. &amp;lt;http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02900.html&amp;gt; 
and &amp;lt;http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00964.html&amp;gt;.

&lt;/pre&gt;</description>
    <dc:creator>Joseph S. Myers</dc:creator>
    <dc:date>2012-05-15T20:06:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126819">
    <title>How do I set SIG_ATOMIC_TYPE to a variant of a C-type?</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126819</link>
    <description>&lt;pre&gt;I'm considering changing SIG_ATOMIC_TYPE for CRIS (*-elf and
*-linux-gnu) to the effect of
 #define SIG_ATOMIC_TYPE "int __attribute__((__aligned__(4)))"
but that by itself doesn't work.  It causes a SEGV on the 4.7
branch and no doubt also on trunk; the code is the same.  From a
gdb session it appears the type is expected to already exist as
a built-in C type, like the (undecorated) "int" or "char" types,
which are created much earlier in the same function.

How do I accomplish setting SIG_ATOMIC_TYPE as above?

Ok, someone is going to ask "why": in the ABI used for CRIS, all
types have byte alignment; structs are "packed".  Linux could
(AFAIU, theoretically) perform a context-switch if a process
gets a page-fault writing to a "sigatomic_t" plain "int" that's
straddling a page boundary where one of the pages isn't present
(say, not yet in the TLB, or paged out).  When the process gets
to execute again, a signal could be waiting (say, SIGALRM) and
the signal handler entered, but that plain "int" is not writt&lt;/pre&gt;</description>
    <dc:creator>Hans-Peter Nilsson</dc:creator>
    <dc:date>2012-05-15T19:34:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126817">
    <title>Re: Trying to track down a register allocation issue</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126817</link>
    <description>&lt;pre&gt;
On May 14, 2012, at 5:47 PM, Joern Rennecke wrote:


Hm.  But pdp11.h says:
#define MODES_TIEABLE_P(MODE1, MODE2) 0
so it seems that tying modes of different sizes should not be happening here.  Also, I don't see reg:SI 2 vs. reg:HI 3, I see reg:SI 2 vs. reg:HI 2.  So the overlap is explicit, it doesn't depend on endians or mode sizes.


paul



&lt;/pre&gt;</description>
    <dc:creator>Paul_Koning&lt; at &gt;Dell.com</dc:creator>
    <dc:date>2012-05-15T18:12:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126815">
    <title>Re: [discuss] [x86-64 psABI] RFC: Extend x86-64 psABI to support x32</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126815</link>
    <description>&lt;pre&gt;Hi,

On Mon, 14 May 2012, H.J. Lu wrote:


I'd prefer that.  x32 is a nice short-hand name for the whole thing, but 
not descriptive, unlike LP64.  So, yes, IMO it should be ILP32 in the ABI 
document.


Ciao,
Michael.&lt;/pre&gt;</description>
    <dc:creator>Michael Matz</dc:creator>
    <dc:date>2012-05-15T16:07:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126814">
    <title>Re: A question about loop ivopt</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126814</link>
    <description>&lt;pre&gt;
Well, I don't think we should feed arbitrary expressions to expand at
IVOPTs time.  What probably matters most is address costs, no?
At least that is where expand probably makes the most difference.
So why not improve force_expr_to_var_cost instead?

Richard.



&lt;/pre&gt;</description>
    <dc:creator>Richard Guenther</dc:creator>
    <dc:date>2012-05-15T14:16:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126813">
    <title>Re: A question about loop ivopt</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126813</link>
    <description>&lt;pre&gt;Hi,


no, not really (I haven't worked on this for a few years now), although
of course I did some measurements when ivopts were created.  Feel free
to experiment with that, if it turned out that the memory consumption
and extra time spent by it is negligible, it would be a nice cleanup.

Zdenek

&lt;/pre&gt;</description>
    <dc:creator>Zdenek Dvorak</dc:creator>
    <dc:date>2012-05-15T14:13:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126812">
    <title>Extension to compare-elim</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126812</link>
    <description>&lt;pre&gt;Hi,

I am looking at a missed optimization and I think this is something that 
could be added to compare-elim, if it's not already done somewhere else. 
I have a double word comparison to zero, so in C it's:
int le(long a) { return a &amp;lt;= 0; }

My expand uses the following transformation (in my current discussion y0 
and y1 are 0):
    if x0:x1 &amp;lt;= y0:y1 goto L
==&amp;gt;
    if x0 &amp;lt; y0 goto L
    if x0 &amp;gt; y0 goto K
    if x1 &amp;lt;= y1 goto L
K:


This generates the assembler:
$le:
         tst     &amp;lt; at &amp;gt;$XAP_AH
         bmi ?L7
         cmp     AH,#H'0000
         bgt ?L3
         tst     &amp;lt; at &amp;gt;$XAP_AL
         bne ?L3
?L7:
         ld      AL,#H'0001
         bra     0,X
?L3:
         ld      AL,#H'0000
         bra     0,X

My argument is that the tst &amp;lt; at &amp;gt;$XAP_AH above could be transformed into cmp 
AH, #H'0000 and the following compare could be removed getting this:
$le:
         cmp     AH,#H'0000
         bmi ?L7
         bgt ?L3
         tst     &amp;lt; at &amp;gt;$XAP_AL
         bne ?L3
?L7:
         ld      AL,#H'0001
         bra     0,X
?L3:&lt;/pre&gt;</description>
    <dc:creator>Paulo J. Matos</dc:creator>
    <dc:date>2012-05-15T13:00:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126811">
    <title>Help with 'ev_sl' PowerPC SPE Intrinsic</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126811</link>
    <description>&lt;pre&gt;Hello All,

I need some help regarding implementation of one of the SPE instructions.

I am planning to implement 'evsl' instrinsic.
d = __ev_sl (a,b) : The value in parameter 'a' is shifted left by no.
of  bit positions specified in parameter 'b', filling vacated bit
positions with zeros, and the result is placed into parameter d.

My question: Is it better to have parameter 'b' of single scalar type
[int a] or vector type [__ev64_u64__ g = { 3 } ]?

Looking at _ev_slb, _ev_slh, _ev_slw, where a single scalar type will
not work since the shift amounts are carried by a "vector" of bytes,
half-words, and words respectively, for uniformity can we consider
64-bit shift as similar, a "vector" of one shift amount?

Thanks in advance.

Regards,
Rohit

&lt;/pre&gt;</description>
    <dc:creator>Rohit Arul Raj</dc:creator>
    <dc:date>2012-05-15T12:26:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126810">
    <title>Re: A question about loop ivopt</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126810</link>
    <description>&lt;pre&gt;Hi,


computation_cost actually expands the expression to RTL.  Since cost estimates
are computed a lot in ivopts, using it directly would require a huge amount of memory,

Zdenek

&lt;/pre&gt;</description>
    <dc:creator>Zdenek Dvorak</dc:creator>
    <dc:date>2012-05-15T10:18:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126809">
    <title>Re: A question about loop ivopt</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126809</link>
    <description>&lt;pre&gt;
I suppose Zdenek may remember.

Richard.


&lt;/pre&gt;</description>
    <dc:creator>Richard Guenther</dc:creator>
    <dc:date>2012-05-15T09:11:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126808">
    <title>мой зайчик.)) </title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126808</link>
    <description>&lt;pre&gt;привееееет зай..!))) 
если скучно и хош зазнакомиться ПoлинaБeлoвa_ndivhfj.land.ru имя моё там. 

&lt;/pre&gt;</description>
    <dc:creator>Руся Эрнет</dc:creator>
    <dc:date>2012-05-15T09:43:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126807">
    <title>A question about loop ivopt</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126807</link>
    <description>&lt;pre&gt;Hi,

Why can't we replace function force_expr_to_var_cost directly with function
computation_cost in tree-ssa-loop-ivopt.c?

Actually I think it is inaccurate for the current recursive algorithm in
force_expr_to_var_cost to estimate expr cost. Instead computation_cost can
count some back-end factors and make the estimation more accurate.

For example, using computation_cost, we may check whether back-ends can tie
some modes transformation expressed by SUBREG or not. If we use
force_expr_to_var_cost, some more computations around type
promotion/demotion would increase the cost estimated.

Looking at the algorithm in force_expr_to_var_cost, it is just to analyze
the operator in the expression and give estimation. Should it be the same as
expanding EXPR to RTX and give estimation like in computation_cost?

Any thoughts?

Thanks,
-Jiangning




&lt;/pre&gt;</description>
    <dc:creator>Jiangning Liu</dc:creator>
    <dc:date>2012-05-15T05:05:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126806">
    <title>Re: confusion about fma description in section 16.9 of gccint doc.</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126806</link>
    <description>&lt;pre&gt;committed in revision 187494.

thanks.

On 05/14/2012 08:05 PM, Ian Lance Taylor wrote:

&lt;/pre&gt;</description>
    <dc:creator>Kenneth Zadeck</dc:creator>
    <dc:date>2012-05-15T01:19:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126805">
    <title>Re: confusion about fma description in section 16.9 of gccint doc.</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126805</link>
    <description>&lt;pre&gt;

Sure.

Ian

&lt;/pre&gt;</description>
    <dc:creator>Ian Lance Taylor</dc:creator>
    <dc:date>2012-05-15T00:05:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126804">
    <title>Re: How do I disable warnings across gcc versions?</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126804</link>
    <description>&lt;pre&gt;

The gcc mailing list is for gcc development, not
quetions about the use of gcc, please address such
questions to the gcc help list.

&lt;/pre&gt;</description>
    <dc:creator>Robert Dewar</dc:creator>
    <dc:date>2012-05-14T22:41:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126803">
    <title>How do I disable warnings across gcc versions?</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126803</link>
    <description>&lt;pre&gt;This code warns (incorrectly, but that's a whole separate issue):

double foo(double a, double b)
{
  bool option1_ok, option2_ok;
  double option1, option2;
  if (a == 0) {
    option1_ok = false;
  } else {
    option1 = b;
    option1_ok = true;
  }
  if (a == 1) {
    option2_ok = false;
  } else {
    option2 = b;
    option2_ok = true;
  }
  if (option1_ok) return option1;
  if (option2_ok) return option2;
  return 7;
}

Unfortunately, the bogus warning is -Wuninitialized in gcc 4.6 and
-Wmaybe-uninitialized in gcc 4.7.  The obvious way to silence the
warning is to wrap it in:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wuninitialized"
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
...
#pragma GCC diagnostic pop

It silences the original warning, but now gcc 4.6 says:
warning: unknown option after ‘#pragma GCC diagnostic’ kind [-Wpragmas]

This seems to defeat the purpose, and adding
#pragma GCC diagnostic ignored "-Wpragmas"
is a little gross.  How am I supposed to do thi&lt;/pre&gt;</description>
    <dc:creator>Andy Lutomirski</dc:creator>
    <dc:date>2012-05-14T22:26:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gcc.devel/126802">
    <title>Re: gcc 4.3.x: Bug in ieee754-{df,sf}.S</title>
    <link>http://permalink.gmane.org/gmane.comp.gcc.devel/126802</link>
    <description>&lt;pre&gt;Am 14.05.2012 23:01, schrieb James Dennett:

I see. So I will backport it myself.


Actually, the patch was committed long time before 4.3.6 (more than 2
years). I guess, the patch was never backported - at least not 4.3.x.

&lt;/pre&gt;</description>
    <dc:creator>Sven Köhler</dc:creator>
    <dc:date>2012-05-14T22:26:09</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.gcc.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.gcc.devel</link>
  </textinput>
</rdf:RDF>

