Re: atomic accesses

[Andrew Haley]

Ross Ridge wrote:
> Segher Boessenkool writes:
>> ... People are relying on this undocumented GCC behaviour already,
>> and when things break, chaos ensues.
> 
> GCC has introduced many changes over the years that have broken many
> programs that have relied on undocumented or unspecified behaviour.
> You won't find much sympathy for who people assume that GCC must behave
> in some way where there is no requirement for it to do so. 
> 
>> If we change this to be documented behaviour, at least it is clear
>> where the problem lies (namely, with the compiler), and things can be
>> fixed easily.
> 
> I don't think you'll find any support for imposing a requirement on GCC
> that would always require it to use an "atomic" instruction when there
> is alternative instruction or sequence of instructions that would be
> faster and/or shorter.  I think your best bet a long these lines would
> be adding __sync_fetch() and __sync_store() builtins, but doing so would
> be more difficult than a simple documentation change.

The proposed memory model partly described at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2492.html
http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2176.html
shows the way the C++ committee is moving.  This involves explicit
atomic operations.

Andrew.

Re: GCC 4.4 schedule

[Sebastian Pop]

On Mon, Mar 3, 2008 at 3:08 PM, Richard Guenther <[EMAIL PROTECTED]> wrote:
>  I am aware of the following merge candidates: the LTO branch, the
>  incremental compiler branch, the selective scheduling branch, the
>  YARA branch and of course the tuples branch.  Please announce those
>  I forgot so they have the chance of getting reviewed properly in time.
>

graphite-branch

Sebastian
--
AMD - GNU Tools

SPEC / testsuite results for disabling SFTs and the alias-oracle patches

[Richard Guenther]

Here are SPEC CPU 2000 results with plain trunk and the two alias-oracle
patches.  Base results are plain -O3 -ffast-math, peak results include
--param max-fields-for-field-sensitive=0 which effectively disables the
creation of SFTs.

Unpatched (three runs):

 Estimated Estimated
   Base  Base  Base  Peak  Peak  Peak
   BenchmarksRef Time  Run Time   RatioRef Time  Run Time   Ratio
   
   164.gzip  1400   100  1400* 140099.91402*
   175.vpr   140080.31742* 140080.51738*
   176.gcc   110048.12288* 110046.82353*
   181.mcf   1800   131  1371* 1800   131  1370*
   186.crafty100038.02635* 100036.62732*
   197.parser1800   134  1348* 1800   133  1353*
   252.eon   X X
   253.perlbmk   180070.82541* 180070.42557*
   254.gap   110057.31921* 110057.11925*
   255.vortexX X
   256.bzip2 150079.31892* 150079.91877*
   300.twolf 3000   114  2635* 3000   114  2633*
   Est. SPECint_base2000 1914
   Est. SPECint20001927


 Estimated Estimated
   Base  Base  Base  Peak  Peak  Peak
   BenchmarksRef Time  Run Time   RatioRef Time  Run Time   Ratio
   
   168.wupwise   1600  79.9  2002* 1600  80.0  2000*
   171.swim  3100 1551999* 3100 1551999*
   172.mgrid 1800  98.6  1825* 1800  98.4  1829*
   173.applu 2100 1781178* 2100 1781181*
   177.mesa  1400  57.8  2421* 1400  58.1  2411*
   178.galgel2900  69.0  4204* 2900  69.0  4203*
   179.art   2600  34.7  7482* 2600  34.1  7617*
   183.equake1300  74.1  1755* 1300  74.0  1757*
   187.facerec   1900  75.3  2523* 1900  75.3  2522*
   188.ammp  2200 1191845* 2200 1191843*
   189.lucas 2000 1191688* 2000 1181697*
   191.fma3d 2100 1321590* 2100 1311598*
   200.sixtrack  1100 120 919* 1100 120 918*
   301.apsi  2600 1711518* 2600 1721509*
   Est. SPECfp_base2000  2029
   Est. SPECfp2000 2032


Patched (three runs):


 Estimated Estimated
   Base  Base  Base  Peak  Peak  Peak
   BenchmarksRef Time  Run Time   RatioRef Time  Run Time   Ratio
   
   164.gzip  1400   100  1400* 140099.91401*
   175.vpr   140080.01751* 140080.11749*
   176.gcc   110047.42319* 110046.82352*
   181.mcf   1800   133  1358* 1800   133  1349*
   186.crafty100037.62656* 100036.82718*
   197.parser1800   133  1350* 1800   133  1349*
   252.eon   X X
   253.perlbmk   180070.42557* 180070.02573*
   254.gap   110057.31918* 110057.41918*
   255.vortexX X
   256.bzip2 150079.91877* 150080.61862*
   300.twolf 3000   114  2641* 3000   114  2638*
   Est. SPECint_base2000 1918
   Est. SPECint20001923


 Estimated Estimated
   Base  Base  Base  Peak  Peak  Peak
   BenchmarksRef Time  Run Time   RatioRef Time  Run Time   Ratio
   
   168.wupwise   1600  80.2  1995* 1600  80.1  1998*
   171.swim  3100 1561993* 3100 1551994*
   172.mgrid 1800  98.7  1824* 1800   

[tuples] Branch frozen (again)

[Diego Novillo]

The overnight tester has found hundreds of new regressions.  Please 
refrain from checking in anything in the branch until I figure out which 
patch broke them and revert it.



Thanks.  Diego.

Re: Interoperability of Fortran array and C vector?

[Sa Liu]

I noticed that in fortran/convert.c the convert() function calls 
convert_to_vector() if the target type is VECTOR_TYPE. When is that 
function triggered in Fortran frontend? Since Fortran language doesn't 
support vector type, why does it convert something to a vector expression? 


Thanks!
Sa

[PATCH] BIT_FIELD_REF_UNSIGNED considered harmful

[Richard Guenther]

While adding constant-folding for integral argument BIT_FIELD_REF I
noticed we have no way of passing down BIT_FIELD_REF_UNSIGNED to
fold_ternary.  Luckily references to BIT_FIELD_REF_UNSIGNED are
rare - only expansion cares for it, through the use of 
get_inner_reference.

So I propose to tighthen the type constraints we set on valid
BIT_FIELD_REF to force its result type precision to match the extracted
bit-field size.  Which makes BIT_FIELD_REF_UNSIGNED redundant, as
for integral type the signedness of the result will determine how
it is extended to its full mode.  For non-integral result types we
always use unsigned extension and can force the bit-field size to
match the mode precision here.

So, minus fixing SRA and removing all traces of BIT_FIELD_REF_UNSIGNED,
the following makes sense for me.

Comments?

Thanks,
Richard.


2008-03-05  Richard Guenther  <[EMAIL PROTECTED]>

* tree.def (BIT_FIELD_REF): Constrain result type and its precision.
* tree-cfg.c (verify_expr): Verify BIT_FIELD_REF constraints on
result type and precision.
* expr.c (get_inner_reference): Set unsignedp based on the result
type of BIT_FIELD_REF.

Index: tree.def
===
*** tree.def(revision 132894)
--- tree.def(working copy)
*** DEFTREECODE (COMPONENT_REF, "component_r
*** 391,398 
 Operand 0 is the structure or union expression;
 operand 1 is a tree giving the constant number of bits being referenced;
 operand 2 is a tree giving the constant position of the first referenced 
bit.
!The field can be either a signed or unsigned field;
!BIT_FIELD_REF_UNSIGNED says which.  */
  DEFTREECODE (BIT_FIELD_REF, "bit_field_ref", tcc_reference, 3)
  
  /* The ordering of the following codes is optimized for the checking
--- 391,399 
 Operand 0 is the structure or union expression;
 operand 1 is a tree giving the constant number of bits being referenced;
 operand 2 is a tree giving the constant position of the first referenced 
bit.
!The result type width has to match the number of bits referenced.
!If the result type is integral, its signedness specifies how it is extended
!to its mode width.  */
  DEFTREECODE (BIT_FIELD_REF, "bit_field_ref", tcc_reference, 3)
  
  /* The ordering of the following codes is optimized for the checking
Index: tree-cfg.c
===
*** tree-cfg.c  (revision 132894)
--- tree-cfg.c  (working copy)
*** verify_expr (tree *tp, int *walk_subtree
*** 3273,3278 
--- 3273,3294 
  error ("invalid position or size operand to BIT_FIELD_REF");
  return t;
}
+ if (INTEGRAL_TYPE_P (TREE_TYPE (t))
+ && (TYPE_PRECISION (TREE_TYPE (t))
+ != TREE_INT_CST_LOW (TREE_OPERAND (t, 1
+   {
+ error ("integral result type precision does not match "
+"field size of BIT_FIELD_REF");
+ return t;
+   }
+ if (!INTEGRAL_TYPE_P (TREE_TYPE (t))
+ && (GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (t)))
+ != TREE_INT_CST_LOW (TREE_OPERAND (t, 1
+   {
+ error ("mode precision of non-integral result does not "
+"match field size of BIT_FIELD_REF");
+ return t;
+   }
}
  
  t = TREE_OPERAND (t, 0);
Index: expr.c
===
*** expr.c  (revision 132893)
--- expr.c  (working copy)
*** get_inner_reference (tree exp, HOST_WIDE
*** 5893,5899 
else if (TREE_CODE (exp) == BIT_FIELD_REF)
  {
size_tree = TREE_OPERAND (exp, 1);
!   *punsignedp = BIT_FIELD_REF_UNSIGNED (exp);
  
/* For vector types, with the correct size of access, use the mode of
 inner type.  */
--- 5893,5900 
else if (TREE_CODE (exp) == BIT_FIELD_REF)
  {
size_tree = TREE_OPERAND (exp, 1);
!   *punsignedp = (! INTEGRAL_TYPE_P (TREE_TYPE (exp))
!|| TYPE_UNSIGNED (TREE_TYPE (exp)));
  
/* For vector types, with the correct size of access, use the mode of
 inner type.  */

Re: [PATCH] BIT_FIELD_REF_UNSIGNED considered harmful

[Diego Novillo]

On 03/05/08 07:18, Richard Guenther wrote:


Comments?


Makes sense to me.


+ if (INTEGRAL_TYPE_P (TREE_TYPE (t))
+ && (TYPE_PRECISION (TREE_TYPE (t))
+ != TREE_INT_CST_LOW (TREE_OPERAND (t, 1
+   {
+ error ("integral result type precision does not match "
+"field size of BIT_FIELD_REF");
+ return t;
+   }
+ if (!INTEGRAL_TYPE_P (TREE_TYPE (t))


'else if' here?



Diego.

Re: Interoperability of Fortran array and C vector?

[Tobias Schlüter]

Sa Liu wrote:
I noticed that in fortran/convert.c the convert() function calls 
convert_to_vector() if the target type is VECTOR_TYPE. When is that 
function triggered in Fortran frontend? Since Fortran language doesn't 
support vector type, why does it convert something to a vector expression?


At the top it says:
/* This file contains the functions for converting C expressions
   to different data types.  The only entry point is `convert'.
   Every language front end must have a `convert' function
   but what kind of conversions it does will depend on the language.  */

/* copied from the f77 frontend I think */

/* copied from c-convert.c without significant modification*/

I don't think this file has ever been modified in any non-mechanical 
way.  So I'd assume that its contents are historical / accidental.


Cheers,
- Tobi

--
Tobias Schlüter
Am Coulombwall 1, Zi. 326
85748 Garching b. München
Tel.: +49/89/289-14139

Re: SPEC / testsuite results for disabling SFTs and the alias-oracle patches

[Diego Novillo]

On 03/05/08 06:48, Richard Guenther wrote:


you can see that in both cases the runs without SFTs are significantly
better(!)  Which hints at the fact that we do a poor job with parititoning
and/or that partitioning triggers earlier with SFTs enabled.


All these differences seem to be less than 1%.  If I'm reading this 
table right, the alias oracle is not really having a significant effect 
on the scores



The oracle patches are able to slightly improve the results in the non-SFT
case, but overall there is less difference patched vs. unpatched compared
to the differences that result if you disable SFTs.


Without the alias oracle you get:

SFTs (base) No SFTs (peak)
SPECint 19141927 (+0.68%)
SPECfp  20292032 (+0.15%)


With the alias oracle you get:

SFTs (base) No SFTs (peak)
SPECint 19181923 (+0.26%)
SPECfp  20202039 (+0.94%)

The good news is that the oracle is not introducing any slowdowns.  So I 
think this is very positive.



Thus, with the above results I propose we disable generating SFTs by
default on the mainline (--para max-fields-for-field-sensitive=100
is still available for comparision).  I will prepare a patch to adjust
the false negative testcases above to check for optimization outcome
as well.


Yes, good idea.  Though I think we should just get rid of SFTs outright. 
 They are only going to be a maintenance problem.



Diego.

Re: [tuples] Branch frozen (again)

[Diego Novillo]

On 03/05/08 07:07, Diego Novillo wrote:

The overnight tester has found hundreds of new regressions.  Please 
refrain from checking in anything in the branch until I figure out which 
patch broke them and revert it.


cc1 had failed to build because of invalid C90 declarations.  Fixed with 
this patch.


The branch is open for commits now.


2008-03-05  Diego Novillo  <[EMAIL PROTECTED]>

* fold-const.c (tree_binary_nonnegative_warnv_p): Fix
invalid C90 declaration.
(tree_single_nonnegative_warnv_p): Likewise.
* gimplify.c (gimplify_bind_expr): Likewise.
(gimplify_return_expr): Likewise.

Index: fold-const.c
===
--- fold-const.c(revision 132891)
+++ fold-const.c(working copy)
@@ -14197,10 +14197,11 @@ tree_binary_nonnegative_warnv_p (enum tr
 static bool
 tree_single_nonnegative_warnv_p (tree t, bool *strict_overflow_p)
 {
+  enum tree_code code = TREE_CODE (t);
+
   if (TYPE_UNSIGNED (TREE_TYPE (t)))
 return true;

-  enum tree_code code = TREE_CODE (t);
   switch (code)
 {
 case SSA_NAME:
@@ -14238,10 +14239,11 @@ tree_single_nonnegative_warnv_p (tree t,
 static bool
 tree_invalid_nonnegative_warnv_p (tree t, bool *strict_overflow_p)
 {
+  enum tree_code code = TREE_CODE (t);
+
   if (TYPE_UNSIGNED (TREE_TYPE (t)))
 return true;

-  enum tree_code code = TREE_CODE (t);
   switch (code)
 {
 case TARGET_EXPR:
Index: gimplify.c
===
--- gimplify.c  (revision 132891)
+++ gimplify.c  (working copy)
@@ -1181,6 +1181,7 @@ gimplify_bind_expr (tree *expr_p, gimple
 static enum gimplify_status
 gimplify_return_expr (tree stmt, gimple_seq *pre_p)
 {
+  gimple ret;
   tree ret_expr = TREE_OPERAND (stmt, 0);
   tree result_decl, result;

@@ -1249,7 +1250,7 @@ gimplify_return_expr (tree stmt, gimple_

   gimplify_and_add (TREE_OPERAND (stmt, 0), pre_p);

-  gimple ret = gimple_build_return (result);
+  ret = gimple_build_return (result);
   gimple_set_no_warning (ret, TREE_NO_WARNING (stmt));
   gimple_seq_add_stmt (pre_p, ret);

Re: SPEC / testsuite results for disabling SFTs and the alias-oracle patches

[Richard Guenther]

On Wed, 5 Mar 2008, Diego Novillo wrote:

> On 03/05/08 06:48, Richard Guenther wrote:
> 
> > you can see that in both cases the runs without SFTs are significantly
> > better(!)  Which hints at the fact that we do a poor job with parititoning
> > and/or that partitioning triggers earlier with SFTs enabled.
> 
> All these differences seem to be less than 1%.  If I'm reading this table
> right, the alias oracle is not really having a significant effect on the
> scores

Yes.  SPEC 2000 is probably not a very good measure for our memory
optimization capabilities.  Still the oracle retains the optimizations
we test for in the testsuite and which were added as SFTs were able to
optimize them.

> > The oracle patches are able to slightly improve the results in the non-SFT
> > case, but overall there is less difference patched vs. unpatched compared
> > to the differences that result if you disable SFTs.
> 
> Without the alias oracle you get:
> 
>   SFTs (base) No SFTs (peak)
> SPECint   19141927 (+0.68%)
> SPECfp20292032 (+0.15%)
> 
> 
> With the alias oracle you get:
> 
>   SFTs (base) No SFTs (peak)
> SPECint   19181923 (+0.26%)
> SPECfp20202039 (+0.94%)
> 
> The good news is that the oracle is not introducing any slowdowns.  So I think
> this is very positive.

Right.  Especially that No SFTs doesn't introduce any slowdowns.

> > Thus, with the above results I propose we disable generating SFTs by
> > default on the mainline (--para max-fields-for-field-sensitive=100
> > is still available for comparision).  I will prepare a patch to adjust
> > the false negative testcases above to check for optimization outcome
> > as well.
> 
> Yes, good idea.  Though I think we should just get rid of SFTs outright. 
> They are only going to be a maintenance problem.

I agree, still it is probably nice to be able to compare testcase behavior
with/without SFTs with the same state of trunk for a while.  So I'd just
adjust the default of --para max-fields-for-field-sensitive for now
(after the oracle patches got in) and remove the code dealing with SFTs
only after stage2.  I am very positive we _will_ get some missed
optimization cases switching off SFTs and it will make our (my) life
easier in tracking them down if they were still available on demand.

Thanks,
Richard.

Re: [PATCH] BIT_FIELD_REF_UNSIGNED considered harmful

[Manfred Hollstein]

On Wed, 05 Mar 2008, 13:47:36 +0100, Diego Novillo wrote:
> On 03/05/08 07:18, Richard Guenther wrote:
> 
> >Comments?
> 
> Makes sense to me.
> 
> >+  if (INTEGRAL_TYPE_P (TREE_TYPE (t))
> >+  && (TYPE_PRECISION (TREE_TYPE (t))
> >+  != TREE_INT_CST_LOW (TREE_OPERAND (t, 1
> >+{
> >+  error ("integral result type precision does not match "
> >+ "field size of BIT_FIELD_REF");
> >+  return t;
> >+}
> >+  if (!INTEGRAL_TYPE_P (TREE_TYPE (t))
> 
> 'else if' here?

In theory, yes, but, why? If the first 'if' part evaluates to true,
control flow jumps out of the function, hence the following 'if' is
totally correct (unless someone #define's return to something else...),
or do the GCC/FSF codings conventions require this to be 'else if'?

> Diego.

Cheers.

l8er
manfred

Re: [tuples] Branch frozen (again)

[Rafael Espindola]

2008/3/5 Diego Novillo <[EMAIL PROTECTED]>:
>  cc1 had failed to build because of invalid C90 declarations.  Fixed with
>  this patch.

Strange. This was a problem with mainline bootstrap (see rev 132886)
but I don't understand why it failed on the test machine but not on my
workstation when both are using --disable-bootstrap?

Thanks,
-- 
Rafael Avila de Espindola

Google Ireland Ltd.
Gordon House
Barrow Street
Dublin 4
Ireland

Registered in Dublin, Ireland
Registration Number: 368047

Re: Help with GCC on Cygwin

[Ian Lance Taylor]

"Balaji V. Iyer" <[EMAIL PROTECTED]> writes:

> Thank you Ian. I did the modification you mentioned...now I am running
> into more problems.

Again: gcc@gcc.gnu.org is the wrong mailing list.  Please do not send
any more e-mail about this to [EMAIL PROTECTED]  Please take any
followups to [EMAIL PROTECTED]  Thanks.


> gcc -c -DHAVE_CONFIG_H -g -O2  -I.
> -I../../gcc-4.0.2/libiberty/../include  -W -Wall -Wtraditional -pedantic
> ../../gcc-4.0.2/libiberty/fibheap.c -o fibheap.o
> ../../gcc-4.0.2/libiberty/fibheap.c: In function `fibheap_delete_node':
> ../../gcc-4.0.2/libiberty/fibheap.c:285: error: `LONG_MIN' undeclared
> (first use in this function)
> ../../gcc-4.0.2/libiberty/fibheap.c:285: error: (Each undeclared
> identifier is reported only once
> ../../gcc-4.0.2/libiberty/fibheap.c:285: error: for each function it
> appears in.)

This is cygwin specific.  LONG_MIN should be defined in .  I
hope that somebody on the cygwin mailing list can help you.

Ian

Re: [PATCH] BIT_FIELD_REF_UNSIGNED considered harmful

[Richard Kenner]

> > >+if (INTEGRAL_TYPE_P (TREE_TYPE (t))
> > >+&& (TYPE_PRECISION (TREE_TYPE (t))
> > >+!= TREE_INT_CST_LOW (TREE_OPERAND (t, 1
> > >+  {
> > >+error ("integral result type precision does not match "
> > >+   "field size of BIT_FIELD_REF");
> > >+return t;
> > >+  }
> > >+if (!INTEGRAL_TYPE_P (TREE_TYPE (t))
> > 
> > 'else if' here?
> 
> In theory, yes, but, why? 

It's easier to read at-a-glance.  A reader can tell quickly that the 
intent is that only one of the options be taken.  It's easier to spot
the "else" than the "return" in the body.

Re: [tuples] Branch frozen (again)

[Diego Novillo]

On 03/05/08 09:19, Rafael Espindola wrote:


Strange. This was a problem with mainline bootstrap (see rev 132886)
but I don't understand why it failed on the test machine but not on my
workstation when both are using --disable-bootstrap?


Since the branch has bootstraps disabled, you are at the mercy of your 
host compiler.  It's a bad situation for us because we run into these 
little problems.


I'm working on getting the branch to bootstrap, but it will take a few 
more days.  In the meantime, we'll just have to live with odd breakages 
like this.


When porting patches to trunk, however, we have to do a full bootstrap 
and test cycle from absolute scratch.  Branch results are invalid on 
mainline.



Diego.

Re: SPEC / testsuite results for disabling SFTs and the alias-oracle patches

[Diego Novillo]

On 03/05/08 09:14, Richard Guenther wrote:


I agree, still it is probably nice to be able to compare testcase behavior
with/without SFTs with the same state of trunk for a while.  So I'd just
adjust the default of --para max-fields-for-field-sensitive for now
(after the oracle patches got in) and remove the code dealing with SFTs
only after stage2.  I am very positive we _will_ get some missed
optimization cases switching off SFTs and it will make our (my) life
easier in tracking them down if they were still available on demand.


Good point.  Sure, that sounds good to me.


Diego.

gcc 3.3.2 Wind River VxWorks PowerPC

[Duncan Purll]

Hi

I am in the process of verifying that the gnu assembler produces object code 
which corresponds on an instruction-by-instruction basis with the interleaved 
source / assembly language listing obtained via -Wa,-ahls. This is for the 
purposes of software certification. I need to create C source which causes the 
compiler to emit specific mnemonics (eg.mfctr instruction etc.) but do not know 
how to force this. I have looked in rs6000.md but this does not contain the 
instruction mnemonics I am looking for. Can you advise of a way in which I can 
determine / predict which mnemonics will be generated for particular C source 
constructs?

Thanks

Duncan







  ___ 
Rise to the challenge for Sport Relief with Yahoo! For Good  

http://uk.promotions.yahoo.com/forgood/

Re: gcc 3.3.2 Wind River VxWorks PowerPC

[David Edelsohn]

> Duncan Purll writes:

Duncan> I am in the process of verifying that the gnu assembler produces object 
code which corresponds on an instruction-by-instruction basis with the 
interleaved source / assembly language listing obtained via -Wa,-ahls. This is 
for the purposes of software certification. I need to create C source which 
causes the compiler to emit specific mnemonics (eg.mfctr instruction etc.) but 
do not know how to force this. I have looked in rs6000.md but this does not 
contain the instruction mnemonics I am looking for. Can you advise of a way in 
which I can determine / predict which mnemonics will be generated for 
particular C source constructs?

mfctr and similar instructions are generated by the movsi_internal1 and
movdi_internal1 patterns, the

mf%1 %0
mt%0 %1

alternatives.

"mfctr" will be very rare.  I'm not sure there is any easy C code that
would produce it.  GCC tries to avoid placing values into CTR unless it
specifically is needed for an instruction that requires that register,
such as a jump or a loop.  PowerPC does not generate any results in CTR.
Either GCC would need to spill the value to reuse CTR for some other
purpos or somehow want the iteration count of a loop only iterated in CTR.

David

Re: gcc 3.3.2 Wind River VxWorks PowerPC

[Richard Kenner]

> "mfctr" will be very rare.  I'm not sure there is any easy C code that
> would produce it.

Way back when I first was working on this stuff, I have seen it, though I
agree that it would be hard to find a test case.

Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Aurelien Jarno]

Hi all,

Since version 4.3, gcc changed its behaviour concerning the x86/x86-64 
ABI and the direction flag, that is it now assumes that the direction 
flag is cleared at the entry of a function and it doesn't clear once 
more if needed.

This causes some problems with the Linux kernel which does not clear
the direction flag when entering a signal handler. The small code below
(for x86-64) demonstrates that. 

If the signal handler is using code that need the direction flag cleared
(for example bzero() or memset()), the code is incorrectly executed.

I guess this has to be fixed on the kernel side, but also gcc-4.3 could
revert back to the old behaviour, that is clearing the direction flag
when entering a routine that touches it until most people are running a
fixed kernel.

Kind regards,
Aurelien

[1] http://gcc.gnu.org/gcc-4.3/changes.html


#include 
#include 
#include 
#include 

void handler(int signal) {
uint64_t rflags;

asm volatile("pushfq ; popq %0" : "=g" (rflags));

if (rflags & (1 << 10))
printf("DF = 1\n");
else
printf("DF = 0\n");
}

int main() {
signal(SIGUSR1, handler);

while(1)
{
asm volatile("std\r\n");
}

return 0;
}

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net

Re: atomic accesses

[kai-gcc]

On Tue, Mar 04, 2008 at 04:41:16PM -0500, Paul Koning wrote:
> > "Segher" == Segher Boessenkool <[EMAIL PROTECTED]> writes:
>  Segher> I disagree.  People are relying on this undocumented GCC
>  Segher> behaviour already, and when things break, chaos ensues.  If
>  Segher> we change this to be documented behaviour, at least it is
>  Segher> clear where the problem lies (namely, with the compiler), and
>  Segher> things can be fixed easily.
> 
>  Segher> The two big questions are:
> 
>  Segher> 1) Do we *want* to guarantee any behaviour in this area?
> 
>  Segher> 2) Exactly *what* behaviour?
> 
> Yes, that's the question.

> But what does such a statement guarantee?  Atomic access?
> 
> What exactly does "atomic access" mean?  It might mean, as one of the
> earlier notes said, that in a single writer multiple reader setting
> you will only ever see the "before" or the "after" states but not the
> one in between.
> 
> It's probably true for most architectures (perhaps even for all that
> GCC supports) that this limited interpretation of "atomic" is
> satisfied when the load or store is a single instruction, aligned, the
> right size, etc.
> 
> Another possible interpretation of "atomic" is "if there are multiple
> writers, one write won't interfere with the other". For example, if
> one writer updates X, and another updates Y, two aligned variables
> adjacent in memory, the final outcome has the new X and the new Y.
> 
> That interpretation in general is NOT satisfied simply by using a
> single instruction for store.  Maybe it is on x86 -- but not
> necessarily so on RISC machines.

Well, as I've both relied on that guarantee as well as recently
explained it to a colleague, maybe I should try to explain it.

First, though, two things:

A. There's something similar in the C standard: see sig_atomic_t. It
might be possible to steal some wording from there.

B. This guarantee - at least as I describe it below - cannot work for
every target. For example, it won't work on a typical 8 bit target. That
needs to be kept in mind when describing it.

Now, the guarantee as I understand it:

First, you need the somewhat nebulous concept of a "word". On a machine
where this guarantee holds, a pointer fits in a word, and so does an
int.

Now, the guarantee says that every change to a word will be atomic, in
the sense described for sig_atomic_t except it also works with threads
and in the presence of SMP. Anything that does not fit in a word needs a
lock if there is more than one thread. (Obviously, a sig_atomic_t ought
to be a word on such a machine.)

There is also no guarantee for anything that is only a part of a word
(bitfield, char, ...) unless it is unpacked enough to not share its word
(such as a typical standalone char variable outside of -Os).

It might be necessary to add some more conditions to make this work on
targets I am not familiar with. But it is clear that it cannot work on a
machine where a pointer does not fit in a sig_atomic_t sized thing (such
as where sig_atomic_t is only 8 bit, and storing a pointer needs several
instructions that might be interrupted by a thread switch).

Maybe targets that have that guarantee should #define something.

Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[H. Peter Anvin]

Aurelien Jarno wrote:

Hi all,

Since version 4.3, gcc changed its behaviour concerning the x86/x86-64 
ABI and the direction flag, that is it now assumes that the direction 
flag is cleared at the entry of a function and it doesn't clear once 
more if needed.


This causes some problems with the Linux kernel which does not clear
the direction flag when entering a signal handler. The small code below
(for x86-64) demonstrates that. 


If the signal handler is using code that need the direction flag cleared
(for example bzero() or memset()), the code is incorrectly executed.

I guess this has to be fixed on the kernel side, but also gcc-4.3 could
revert back to the old behaviour, that is clearing the direction flag
when entering a routine that touches it until most people are running a
fixed kernel.



Linux should definitely follow the ABI.  This is a bug, and a pretty 
serious such.


-hpa

Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[H.J. Lu]

Hi,

According to i386 psABI,

---
The direction flag must be set "forward" direction before entry and
upon exit from
a function.
---

So, asm statement should make sure that the direction flag is cleared before
function returns and kernel should make sure that the direction flag is cleared
when calling a signal handler.

H.J.
On Wed, Mar 5, 2008 at 7:30 AM, Aurelien Jarno <[EMAIL PROTECTED]> wrote:
> Hi all,
>
>  Since version 4.3, gcc changed its behaviour concerning the x86/x86-64
>  ABI and the direction flag, that is it now assumes that the direction
>  flag is cleared at the entry of a function and it doesn't clear once
>  more if needed.
>
>  This causes some problems with the Linux kernel which does not clear
>  the direction flag when entering a signal handler. The small code below
>  (for x86-64) demonstrates that.
>
>  If the signal handler is using code that need the direction flag cleared
>  (for example bzero() or memset()), the code is incorrectly executed.
>
>  I guess this has to be fixed on the kernel side, but also gcc-4.3 could
>  revert back to the old behaviour, that is clearing the direction flag
>  when entering a routine that touches it until most people are running a
>  fixed kernel.
>
>  Kind regards,
>  Aurelien
>
>  [1] http://gcc.gnu.org/gcc-4.3/changes.html
>
>
>  #include 
>  #include 
>  #include 
>  #include 
>
>  void handler(int signal) {
> uint64_t rflags;
>
> asm volatile("pushfq ; popq %0" : "=g" (rflags));
>
> if (rflags & (1 << 10))
> printf("DF = 1\n");
> else
> printf("DF = 0\n");
>  }
>
>  int main() {
> signal(SIGUSR1, handler);
>
> while(1)
> {
> asm volatile("std\r\n");
> }
>
> return 0;
>  }
>
>  --
>   .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
>   : :' :  Debian developer   | Electrical Engineer
>   `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
>`-people.debian.org/~aurel32 | www.aurel32.net
>

Re: atomic accesses

[Paul Koning]

> "kai-gcc" == kai-gcc  <[EMAIL PROTECTED]> writes:

 kai-gcc> A. There's something similar in the C standard: see
 kai-gcc> sig_atomic_t. It might be possible to steal some wording
 kai-gcc> from there.

 kai-gcc> B. This guarantee - at least as I describe it below - cannot
 kai-gcc> work for every target. For example, it won't work on a
 kai-gcc> typical 8 bit target. That needs to be kept in mind when
 kai-gcc> describing it.

 kai-gcc> Now, the guarantee as I understand it:

 kai-gcc> First, you need the somewhat nebulous concept of a
 kai-gcc> "word". On a machine where this guarantee holds, a pointer
 kai-gcc> fits in a word, and so does an int.

 kai-gcc> Now, the guarantee says that every change to a word will be
 kai-gcc> atomic, in the sense described for sig_atomic_t except it
 kai-gcc> also works with threads and in the presence of SMP. ...

 kai-gcc> Maybe targets that have that guarantee should #define
 kai-gcc> something.

I don't much like the notion of a "guarantee" about the semantics of a
supposedly portable language, where that guarantee is
target-dependent. 

So are you saying you want this property for plain ordinary C language
references to plain ordinary data types?  And the guarantee is
stronger than what C offers for sig_atomic_t?

It seems to me that sig_atomic_t exists because even the weak
guarantee it provides acts as a constraint on the implementation, so
you don't want that overhead for every variable, only for those where
you explicitly call for it by the use of that special type.

Given that, it clearly isn't a good idea to propose a stronger
guarantee for plain old int (or similar) types.  Instead, you could
tie it to a new type ("smp_atomic_t"?) and/or new functions
("smp_atomic_load"?)  That also serves the useful purpose of
explicitly calling out the places in the source where atomicity
assumptions are made.

paul

Lots of new test failures on trunk due to unrecognizable insn

[İsmail Dönmez]

Hi all,

regtesting on i686-apple-darwin9 I see :


FAIL: gcc.c-torture/compile/pr33009.c  -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr33009.c  -O3 -fomit-frame-pointer
(internal compiler error)
FAIL: gcc.c-torture/compile/pr33009.c  -O3 -fomit-frame-pointer  (test
for excess errors)
FAIL: gcc.c-torture/compile/pr33009.c  -O3 -fomit-frame-pointer
-funroll-loops  (internal compiler error)
FAIL: gcc.c-torture/compile/pr33009.c  -O3 -fomit-frame-pointer
-funroll-loops  (test for excess errors)
FAIL: gcc.c-torture/compile/pr33009.c  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gcc.c-torture/compile/pr33009.c  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (test for excess errors)
FAIL: gcc.c-torture/compile/pr33009.c  -O3 -g  (internal compiler error)
FAIL: gcc.c-torture/compile/pr33009.c  -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr33009.c  -Os  (internal compiler error)
FAIL: gcc.c-torture/compile/pr33009.c  -Os  (test for excess errors)


Log shows :

/Users/cartman/Sources/gcc/gcc/testsuite/gcc.c-torture/compile/pr11832.c:
In function 'foo':
/Users/cartman/Sources/gcc/gcc/testsuite/gcc.c-torture/compile/pr11832.c:30:
error: unrecognizable insn:
(insn 
177/Users/cartman/Sources/gcc/gcc/testsuite/gcc.c-torture/compile/pr11832.c:30:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

This is a new regression introduced under 48 hours. Any ideas?

Regards,
ismail

-- 
UNIX is basically a simple operating system, but you have to be a
genius to understand the simplicity. - Dennis Ritchie

Re: atomic accesses

[Martin Jambor]

On Tue, Mar 04, 2008 at 10:50:17PM +, Paul Brook wrote:
> > AFAIK the only reason we don't break this rule is that doing so would
> > be grossly inefficient; there's nothing to stop any gcc back-end with
> > (say) seriously slow DImode writes from using two SImode writes instead.
> 
> I'm fairly sure ARM already breaks this "rule".
> 

Hm, just out  of curiosity, does not Java require  32-bit stores to be
atomic?  I do not  know Java well but I think it  does.  Do we observe
this language-specific rule on ARM then? Do we do it because 32 bit is
small enough or do we have a mechanism for that?

Martin

Re: atomic accesses

[Andrew Haley]

Martin Jambor wrote:
> On Tue, Mar 04, 2008 at 10:50:17PM +, Paul Brook wrote:
>>> AFAIK the only reason we don't break this rule is that doing so would
>>> be grossly inefficient; there's nothing to stop any gcc back-end with
>>> (say) seriously slow DImode writes from using two SImode writes instead.
>> I'm fairly sure ARM already breaks this "rule".
>>
> 
> Hm, just out  of curiosity, does not Java require  32-bit stores to be
> atomic? 

Yes.

> I do not  know Java well but I think it  does.  Do we observe
> this language-specific rule on ARM then?

Yes.

> Do we do it because 32 bit is
> small enough or do we have a mechanism for that?

We do it because 32 bits is small enough.  I don't suppose anyone has
gone through any back-end to make sure we don't write 32-bit aligned
stores in two instructions.  If we do that, then Java will break, but
I think we have more important things to worry about.

Andrew.
 

Re: atomic accesses

[Jakub Jelinek]

On Wed, Mar 05, 2008 at 06:05:44PM +, Andrew Haley wrote:
> > Hm, just out  of curiosity, does not Java require  32-bit stores to be
> > atomic? 
> 
> Yes.

Linux uses typedef int sig_atomic_t; for all architectures, so if ARM
stores an int as two 16-bit guantities, it breaks ISO C requirements as
well.

Jakub

Soliciting help upgrading our bugzilla install

[Daniel Berlin]

Hi guys and gals,

Currently, gcc.gnu.org runs a custom version of bugzilla 2.18.

The main differences between our version and the regular 2.18 is that
we removed some fields (operating system and something else) and added
some fields (target triples).
We've also modified the email handling code a bit.
The db field changes were done because bugzilla had no support for
custom fields at the time.
2.18 is no longer supported, so we don't get security fixes, etc.
There are also significant speed and workflow improvements in the
newer versions.
It is time to upgrade.

Nowadays, bugzilla 3.0+ has support for custom fields, and as part of
upgrading our install, we should move to eliminate our schema changes
in favor of using custom fields.
Bugzilla 3.0's codebase is significantly different, and porting the
other changes we have is not completely trivial.

I no longer have the time to do all this work on my own.

This is not really hard work, it mainly is writing small amounts of
code and a lot of debugging/testing (I usually set up a mirror install
with the gcc database on dberlin.org and play with the code there).
If anyone who knows perl is willing to help port our custom changes to
bugzilla to the 3.0+ codebase, or is willing to help write a converter
from our current db to the bugzilla 3.0, please let me know.

Thanks,
Dan

Re: [PATCH] Make alias_sets_conflict_p less conservative

[Richard Kenner]

> >  But if it can't handle very simple cases correctly, I'd say it has some
> >  serious problems.
> 
> I await your design for a completely accurate def-use chain
> representation for memory accesses that does not take infinite amounts
> of memory at compile time.
> Until then, i have to laugh at your claim of "serious problems".
> We knew what we were doing when we made it, and we knew it would have
> some issues that would take further disambiguation to solve.
> This just happens to be one of those cases.

I moved this to the main list because I think it's of general interest.

I fail to understand how the issue of which alias set is used has any
appreciable effect on the amount of memory used at compile time.

The issue here is with something like:

struct X {int i; unsigned int iu; short s; unsigned short us;} x;

and then you have x.i as a reference someplace and you need to know
what it conflicts with.  The RTL pass correctly assigns this the alias
set corresponding to "int".  From what I'm reading here, the tree optimizers
assign this the alias set corresponding to "struct X".  That means that x.i
will conflict not just with accesses to int, but to unsigned int, short,
and unsigned short as well.  That's wrong and unnecessary and I don't
understand how fixing this will cost memory.

This is hardly a pathalogical corner case that it's OK to get wrong.  This
is the *central case* around which much of the aliasing system has been
designed.  I don't believe that getting this wrong is reasonable.

Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Joe Buck]

Aurelien Jarno wrote:
> >Since version 4.3, gcc changed its behaviour concerning the x86/x86-64 
> >ABI and the direction flag, that is it now assumes that the direction 
> >flag is cleared at the entry of a function and it doesn't clear once 
> >more if needed.
> >...
> >I guess this has to be fixed on the kernel side, but also gcc-4.3 could
> >revert back to the old behaviour, that is clearing the direction flag
> >when entering a routine that touches it until most people are running a
> >fixed kernel.

On Wed, Mar 05, 2008 at 08:00:42AM -0800, H. Peter Anvin wrote:
> Linux should definitely follow the ABI.  This is a bug, and a pretty 
> serious such.

Unfortunately, there are a lot of kernels out there already with this
problem, and the symptoms are likely to be subtle.  So even if it is true
that it is the kernel that is "in the wrong", I think we still are going
to need to give users a workaround from the gcc side as well.

So I think gcc at least needs an *option* to revert to the old behavior,
and there's a good argument to make it the default for now, at least for
x86/x86-64 on Linux.

Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Aurelien Jarno]

On Wed, Mar 05, 2008 at 11:58:34AM -0800, Joe Buck wrote:
> 
> Aurelien Jarno wrote:
> > >Since version 4.3, gcc changed its behaviour concerning the x86/x86-64 
> > >ABI and the direction flag, that is it now assumes that the direction 
> > >flag is cleared at the entry of a function and it doesn't clear once 
> > >more if needed.
> > >...
> > >I guess this has to be fixed on the kernel side, but also gcc-4.3 could
> > >revert back to the old behaviour, that is clearing the direction flag
> > >when entering a routine that touches it until most people are running a
> > >fixed kernel.
> 
> On Wed, Mar 05, 2008 at 08:00:42AM -0800, H. Peter Anvin wrote:
> > Linux should definitely follow the ABI.  This is a bug, and a pretty 
> > serious such.
> 
> Unfortunately, there are a lot of kernels out there already with this
> problem, and the symptoms are likely to be subtle.  So even if it is true
> that it is the kernel that is "in the wrong", I think we still are going
> to need to give users a workaround from the gcc side as well.
> 
> So I think gcc at least needs an *option* to revert to the old behavior,
> and there's a good argument to make it the default for now, at least for
> x86/x86-64 on Linux.

And for other kernels. I tested OpenBSD 4.1, FreeBSD 6.3, NetBSD 4.0,
they have the same behaviour as Linux, that is they don't clear DF
before calling the signal handler.

I also tested Hurd, and it causes a kernel crash.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net

Re: [PATCH][4.3] Deprecate -ftrapv

[Florian Weimer]

* Ross Ridge:

> At the risk of my curiousity getting me into more trouble, could any
> one explain to me how to access these "eip" and "trapno" members from
> a signal handler on Linux?  I can't find any relevent documention with
> man nor Google.

I think you need sigaction with a SA_SIGINFO, and chase structs from the
ucontext_t argument inside the signal handler.  MLton contains example
code, and likely GCJ and OpenJDK as well.

Re: [PATCH] Make alias_sets_conflict_p less conservative

[Michael Matz]

Hi,

On Wed, 5 Mar 2008, Richard Kenner wrote:

> I moved this to the main list because I think it's of general interest.
> 
> I fail to understand how the issue of which alias set is used has any
> appreciable effect on the amount of memory used at compile time.
> 
> The issue here is with something like:
> 
>   struct X {int i; unsigned int iu; short s; unsigned short us;} x;
> 
> and then you have x.i as a reference someplace and you need to know
> what it conflicts with.  The RTL pass correctly assigns this the alias
> set corresponding to "int".  From what I'm reading here, the tree optimizers
> assign this the alias set corresponding to "struct X".  That means that x.i
> will conflict not just with accesses to int, but to unsigned int, short,
> and unsigned short as well.  That's wrong and unnecessary and I don't
> understand how fixing this will cost memory.

The problem lies in the way how we represent load and store dependencies 
as virtual operands.  Conflicts between a pair of mem accesses are not 
evaluated by asking alias_set_conflicts_p() on both accesses, but instead 
via a chain of virtual def and use operands.  E.g. (for the following 
let's ignore SFTs and other means to get more precise again):

struct X {int i; unsigned int iu; short s; unsigned short us;} x, y;
x = something;   // 1
x.i = bla1;  // 2
x.s = bla2;  // 3
y = x;   // 4
bla3 = y.i;  // 5

We know that set(int) and set(X) conflict (like also set(short) and 
set(X)), so there needs to be a dependency from 2 and 3 to 1, from 
4 to 3, 2 and 1, and from 5 to 4.

These dependencies are represented as V2 = DEF pseudo effects attached 
to the individual statements.  The way it is implemented right now is by 
noting that the store to x.i and x.s "modify" a virtual variable 
associated with the whole struct X, so we have:

  #X_1 = DEF<...>
x = something;   // 1
  #X_2 = DEF
x.i = bla1;  // 2
  #X_3 = DEF
x.s = bla2;  // 3
  #Y_1 = DEF
y = x;   // 4
  # USE
bla3 = y.i;  // 5

The ordering is correct, but not the same as the ideal ordering from 
above.  In particular 3 depends on 2 now, which it doesn't in the ideal 
ordering.  But to represent the ideal ordering we would have to do 
something like this:

  #X_1 = DEF<...> // as point to attach further full reads of struct X
  #int_1 = DEF<...>   // to attach further reads from ints, the x.i member
  #uint_1 = DEF<...>  // same for x.iu
  #short_1 = DEF<...> // x.s
  #ushort_1 = DEF<...>// x.us
x = something;  // 1
  #int_2 = DEF
x.i = bla1; // 2
  #short_2 = DEF
x.s = bla2; // 3
  #Y_1 = DEF
  #int_3 = DEF
  #uint_2 = DEF
  #short_3 = DEF
  #ushort_2 = DEF
y = x   // 4
  # USE
bla3 = y.i; // 5

As you can see all stores to the full struct would require clobbering all 
virtual variables for the member types (otherwise there wouldn't be any 
mean to create a dependency from a further access to individual members to 
this store).

Needless to say that these virtual operands (vops) require space.  Indeed 
they require extremely much space when you want to have a precise 
description of memory access dependencies due to combinatoric explosion.

RTL doesn't have this problem because the dependencies are not represented 
explicitely but implicitely (they are evaluated on-demand whenever we have 
two mem accesses and wonder if they conflict or not).

Richis alias oracle work for tree-ssa tries to do something similar to 
what RTL already has.  Making the explicit dependencies even more 
imprecise (but needing less memory) while improving several optimization 
passes to ask questions in the same way as RTL passes do to disambiguate 
mem accesses.

> This is hardly a pathalogical corner case that it's OK to get wrong.  
> This is the *central case* around which much of the aliasing system has 
> been designed.  I don't believe that getting this wrong is reasonable.

I sort of agree with you.  The representation of mem access dependencies 
in tree-ssa is less than ideal for the real world.  It makes SSA 
optimizers work quite naturally also for loads and stores (all these vops 
are in SSA form too), but at a very high cost (either in memory or 
in imprecisness).


Ciao,
Michael.

GCC build problem

[Dasarath Weeratunge]

I added a field to struct basic_block_def in basic-block.h of type
struct pointer_set_t.

Now when I try to rebuild GCC build fails with error:

libbackend.a(gtype-desc.o): In function `gt_pch_nx_basic_block_def':
/scratch/dweeratu/gcc/build/gcc/gtype-desc.c:2472: undefined reference
to `gt_pch_nx_pointer_set_t'
/scratch/dweeratu/gcc/build/gcc/gtype-desc.c:2473: undefined reference
to `gt_pch_nx_pointer_set_t'
libbackend.a(gtype-desc.o): In function `gt_ggc_mx_basic_block_def':
/scratch/dweeratu/gcc/build/gcc/gtype-desc.c:708: undefined reference
to `gt_ggc_mx_pointer_set_t'
/scratch/dweeratu/gcc/build/gcc/gtype-desc.c:709: undefined reference
to `gt_ggc_mx_pointer_set_t'
collect2: ld returned 1 exit status

It looks as if some auto generated files are not been regenerated
properly. This happens
even if I completely redo the build.

How can this be fixed?

thanks,
-- dasarath

Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Michael Matz]

Hi,

On Wed, 5 Mar 2008, Aurelien Jarno wrote:

> > So I think gcc at least needs an *option* to revert to the old behavior,
> > and there's a good argument to make it the default for now, at least for
> > x86/x86-64 on Linux.
> 
> And for other kernels. I tested OpenBSD 4.1, FreeBSD 6.3, NetBSD 4.0, 
> they have the same behaviour as Linux, that is they don't clear DF 
> before calling the signal handler.

Sigh.  We could perhaps insert a cld for all functions which can be 
recognized as possible signal handlers and call other unknown or string 
functions.  But it's probably even faster to emit cld in front of the 
inline copies of mem functions again :-(


Ciao,
Michael.

Re: [PATCH] Make alias_sets_conflict_p less conservative

[Richard Kenner]

> The problem lies in the way how we represent load and store dependencies 
> as virtual operands.  Conflicts between a pair of mem accesses are not 
> evaluated by asking alias_set_conflicts_p() on both accesses, but instead 
> via a chain of virtual def and use operands.  

But I thought this whole discussion was about a change to
alias_sets_conflict_p.  So you've lost me.

Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Joe Buck]

On Wed, Mar 05, 2008 at 09:38:13PM +0100, Michael Matz wrote:
> Hi,
> 
> On Wed, 5 Mar 2008, Aurelien Jarno wrote:
> 
> > > So I think gcc at least needs an *option* to revert to the old behavior,
> > > and there's a good argument to make it the default for now, at least for
> > > x86/x86-64 on Linux.
> > 
> > And for other kernels. I tested OpenBSD 4.1, FreeBSD 6.3, NetBSD 4.0, 
> > they have the same behaviour as Linux, that is they don't clear DF 
> > before calling the signal handler.
> 
> Sigh.  We could perhaps insert a cld for all functions which can be 
> recognized as possible signal handlers and call other unknown or string 
> functions.  But it's probably even faster to emit cld in front of the 
> inline copies of mem functions again :-(

Yes, if there are four kernels that get it "wrong", that effectively means
that the ABI document doesn't describe reality and gcc has to adjust.

Re: atomic accesses

[Florian Weimer]

* Segher Boessenkool:

> Good point.  Suggestions for better wording?  How does
>
>   "any access to a naturally aligned scalar object in memory
>   that is not a bit-field and fits in a general purpose integer
>   machine register, will be performed by a single machine
>   instruction whenever possible"

Vectorization already breaks this promise, and so does dead store
elimination, at least if you interpret "single" as "exactly one".
"At most one" could be a better choice.

Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[H. Peter Anvin]

Michael Matz wrote:

Hi,

On Wed, 5 Mar 2008, Aurelien Jarno wrote:


So I think gcc at least needs an *option* to revert to the old behavior,
and there's a good argument to make it the default for now, at least for
x86/x86-64 on Linux.
And for other kernels. I tested OpenBSD 4.1, FreeBSD 6.3, NetBSD 4.0, 
they have the same behaviour as Linux, that is they don't clear DF 
before calling the signal handler.


Sigh.  We could perhaps insert a cld for all functions which can be 
recognized as possible signal handlers and call other unknown or string 
functions.  But it's probably even faster to emit cld in front of the 
inline copies of mem functions again :-(




Well, there is a (slight) difference: you know that a called function 
will not clobber your DF state; it's only the entry condition which is 
imprecise.


The best would be if this could be controlled by a flag, which we can 
flip once kernel fixes has been around for long enough.


-hpa

Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Jan Hubicka]

> On Wed, Mar 05, 2008 at 09:38:13PM +0100, Michael Matz wrote:
> > Hi,
> > 
> > On Wed, 5 Mar 2008, Aurelien Jarno wrote:
> > 
> > > > So I think gcc at least needs an *option* to revert to the old behavior,
> > > > and there's a good argument to make it the default for now, at least for
> > > > x86/x86-64 on Linux.
> > > 
> > > And for other kernels. I tested OpenBSD 4.1, FreeBSD 6.3, NetBSD 4.0, 
> > > they have the same behaviour as Linux, that is they don't clear DF 
> > > before calling the signal handler.
> > 
> > Sigh.  We could perhaps insert a cld for all functions which can be 
> > recognized as possible signal handlers and call other unknown or string 
> > functions.  But it's probably even faster to emit cld in front of the 
> > inline copies of mem functions again :-(
> 
> Yes, if there are four kernels that get it "wrong", that effectively means
> that the ABI document doesn't describe reality and gcc has to adjust.

Kernels almost never follow ABI used by applications to last detail.
Linux kernel is disabling red zone and use kernel code model, yet the
ABI is not going to be adjusted for that.

This is resonably easy to fix on kernel side in signal handling, or by
removing std usage completely (I believe it is not performance win, but
some benchmarking would be needed to double check)

Honza

Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Aurelien Jarno]

H. Peter Anvin a écrit :
> Michael Matz wrote:
>> Hi,
>>
>> On Wed, 5 Mar 2008, Aurelien Jarno wrote:
>>
 So I think gcc at least needs an *option* to revert to the old
 behavior,
 and there's a good argument to make it the default for now, at least
 for
 x86/x86-64 on Linux.
>>> And for other kernels. I tested OpenBSD 4.1, FreeBSD 6.3, NetBSD 4.0,
>>> they have the same behaviour as Linux, that is they don't clear DF
>>> before calling the signal handler.
>>
>> Sigh.  We could perhaps insert a cld for all functions which can be
>> recognized as possible signal handlers and call other unknown or
>> string functions.  But it's probably even faster to emit cld in front
>> of the inline copies of mem functions again :-(
>>
> 
> Well, there is a (slight) difference: you know that a called function
> will not clobber your DF state; it's only the entry condition which is
> imprecise.
> 
> The best would be if this could be controlled by a flag, which we can
> flip once kernel fixes has been around for long enough.

I have to agree there. Whatever the decision that gcc will take,
distributions will reenable the old behaviour for some time for to allow
upgrades from a previous version.

Providing a flag to switch the behaviour (whatever the default
behaviour) will help a lot.


-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net

Re: Lots of new test failures on trunk due to unrecognizable insn

[Dominique Dhumieres]

See my comments in PR33009.

Dominique d'Humieres

Re: [PATCH] Make alias_sets_conflict_p less conservative

[Michael Matz]

Hi,

On Wed, 5 Mar 2008, Richard Kenner wrote:

> > The problem lies in the way how we represent load and store dependencies 
> > as virtual operands.  Conflicts between a pair of mem accesses are not 
> > evaluated by asking alias_set_conflicts_p() on both accesses, but instead 
> > via a chain of virtual def and use operands.  
> 
> But I thought this whole discussion was about a change to
> alias_sets_conflict_p.  So you've lost me.

alias_sets_conflict_p() is used to determine if an addressable variable 
and a type conflict also from the tree-ssa alias machinery (in effect to 
determine which virtual variables need to be clobbered).  It just isn't 
feed COMPONENT_REFs, that's what you found very wrong, and I explained the 
reasons for not doing so.  If we were to do that (and hence become more 
precise) we would have to increase memory use as just explained.  You were 
asking how feeding COMPONENT_REFs would be connected with memory use, and 
I explained it.

Richis proposed change to alias_sets_conflict_p is not directly connected 
with this, or only insofar as it tries to say "no" in more cases even in 
the mediocre way tree-ssa asks conflict_p.  In the course of discussion 
it became clear that a much better fix would be to feed it COMPONENT_REFs, 
but we can't easily as explained.


Ciao,
Michael.

Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Michael Matz]

Hi,

On Wed, 5 Mar 2008, Jan Hubicka wrote:

> Kernels almost never follow ABI used by applications to last detail. 

But we aren't talking about the ABI the kernel uses internally, but about 
what is exposed to user-space via signal handlers.  _That_ part needs to 
be followed, and if it isn't it's a serious problem we somehow have to 
hack around.

> Linux kernel is disabling red zone and use kernel code model, yet the 
> ABI is not going to be adjusted for that.
> 
> This is resonably easy to fix on kernel side in signal handling, or by
> removing std usage completely

That is true.  But it requires updating the kernel to a fixed one if you 
want to run your programs compiled by 4.3 :-/  Not something we'd like to 
demand.


Ciao,
Michael.

Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[H. Peter Anvin]

Jan Hubicka wrote:

Yes, if there are four kernels that get it "wrong", that effectively means
that the ABI document doesn't describe reality and gcc has to adjust.


Kernels almost never follow ABI used by applications to last detail.
Linux kernel is disabling red zone and use kernel code model, yet the
ABI is not going to be adjusted for that.

This is resonably easy to fix on kernel side in signal handling, or by
removing std usage completely (I believe it is not performance win, but
some benchmarking would be needed to double check)


That's not the issue.  The issue is that the kernel leaks the DF from 
the code that took a signal to the signal handler.


-hpa

Re: [PATCH] Make alias_sets_conflict_p less conservative

[Richard Kenner]

> alias_sets_conflict_p() is used to determine if an addressable variable 
> and a type conflict also from the tree-ssa alias machinery (in effect to 
> determine which virtual variables need to be clobbered).  It just isn't 
> feed COMPONENT_REFs, that's what you found very wrong, and I explained the 
> reasons for not doing so.  If we were to do that (and hence become more 
> precise) we would have to increase memory use as just explained.  You were 
> asking how feeding COMPONENT_REFs would be connected with memory use, and 
> I explained it.

Why can't you keep the vops as they are now, but when you call
alias_sets_conflict_p, pass the actual reference from the op, not the vop?

Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[David Miller]

From: Aurelien Jarno <[EMAIL PROTECTED]>
Date: Wed, 05 Mar 2008 21:52:14 +0100

> H. Peter Anvin a écrit :
> > The best would be if this could be controlled by a flag, which we can
> > flip once kernel fixes has been around for long enough.
> 
> I have to agree there. Whatever the decision that gcc will take,
> distributions will reenable the old behaviour for some time for to allow
> upgrades from a previous version.

I don't think this approach is tenable.

If a distribution should ship with a "fixed" kernel and
compiler enabling the new direction flag behavior, any
binary you create on that system will be broken on any
other existing system.

I think we really are stuck with this forever, overwhelming
practice over the past 15 years has dictated to us what the
real ABI is.

RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Joe Buck]

On Wed, 5 Mar 2008, Jan Hubicka wrote:
> > Linux kernel is disabling red zone and use kernel code model, yet the 
> > ABI is not going to be adjusted for that.
> > 
> > This is resonably easy to fix on kernel side in signal handling, or by
> > removing std usage completely

On Wed, Mar 05, 2008 at 10:02:07PM +0100, Michael Matz wrote:
> That is true.  But it requires updating the kernel to a fixed one if you 
> want to run your programs compiled by 4.3 :-/  Not something we'd like to 
> demand.

I changed the title just for emphasis.

I think that we can't ship 4.3.0 if signal handlers on x86/x86_64
platforms for both Linux and BSD systems will mysteriously (to the users)
fail, and it doesn't matter whose fault it is.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Richard Guenther]

On Wed, Mar 5, 2008 at 10:20 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
>
>
>  On Wed, 5 Mar 2008, Jan Hubicka wrote:
>  > > Linux kernel is disabling red zone and use kernel code model, yet the
>  > > ABI is not going to be adjusted for that.
>  > >
>  > > This is resonably easy to fix on kernel side in signal handling, or by
>  > > removing std usage completely
>
>  On Wed, Mar 05, 2008 at 10:02:07PM +0100, Michael Matz wrote:
>  > That is true.  But it requires updating the kernel to a fixed one if you
>  > want to run your programs compiled by 4.3 :-/  Not something we'd like to
>  > demand.
>
>  I changed the title just for emphasis.
>
>  I think that we can't ship 4.3.0 if signal handlers on x86/x86_64
>  platforms for both Linux and BSD systems will mysteriously (to the users)
>  fail, and it doesn't matter whose fault it is.

We didn't yet run into this issue and build openSUSE with 4.3 since more than
three month.

Richard.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[H. Peter Anvin]

Richard Guenther wrote:


We didn't yet run into this issue and build openSUSE with 4.3 since more than
three month.



Well, how often do you take a trap inside an overlapping memmove()?

-hpa

Re: [PATCH] Make alias_sets_conflict_p less conservative

[Michael Matz]

Hi,

On Wed, 5 Mar 2008, Richard Kenner wrote:

> > alias_sets_conflict_p() is used to determine if an addressable variable 
> > and a type conflict also from the tree-ssa alias machinery (in effect to 
> > determine which virtual variables need to be clobbered).  It just isn't 
> > feed COMPONENT_REFs, that's what you found very wrong, and I explained the 
> > reasons for not doing so.  If we were to do that (and hence become more 
> > precise) we would have to increase memory use as just explained.  You were 
> > asking how feeding COMPONENT_REFs would be connected with memory use, and 
> > I explained it.
> 
> Why can't you keep the vops as they are now, but when you call
> alias_sets_conflict_p, pass the actual reference from the op, not the vop?

Because as explained already, making use of whatever alias_sets_conflict_p 
would tell us when given COMPONENT_REFs would require blowing up our 
explicit dependency representation.  It's not the case that we inherently 
can't call alias_sets_conflict_p() with the COMPONENT_REF if we have one.  
We could.  But we have no way to express the resulting dependencies 
without needing much more memory.


Ciao,
Michael.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Richard Guenther]

On Wed, Mar 5, 2008 at 10:34 PM, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>  >
>  > We didn't yet run into this issue and build openSUSE with 4.3 since more 
> than
>  > three month.
>  >
>
>  Well, how often do you take a trap inside an overlapping memmove()?

Right.  So this problem is over-exaggerated.  It's not like
"any binary you create on that system will be broken on any
other existing system."

Richard.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Joe Buck]

On Wed, Mar 05, 2008 at 01:34:14PM -0800, H. Peter Anvin wrote:
> Richard Guenther wrote:
> >
> >We didn't yet run into this issue and build openSUSE with 4.3 since more 
> >than
> >three month.
> >
> 
> Well, how often do you take a trap inside an overlapping memmove()?

Also, would it be possible to produce an exploit?  If you can get string
instructions to work "the wrong way", you might be able to overwrite data.

"We haven't seen a problem" isn't the right answer.  Can someone
deliberately *create* a problem?

And if we aren't sure, we should err on the side of safety.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Andrew Pinski]

There are already gcc 4.3.0 packages on the FTP site.

Sent from my iPhone

On Mar 5, 2008, at 13:20, Joe Buck <[EMAIL PROTECTED]> wrote:




On Wed, 5 Mar 2008, Jan Hubicka wrote:
Linux kernel is disabling red zone and use kernel code model, yet  
the

ABI is not going to be adjusted for that.

This is resonably easy to fix on kernel side in signal handling,  
or by

removing std usage completely


On Wed, Mar 05, 2008 at 10:02:07PM +0100, Michael Matz wrote:
That is true.  But it requires updating the kernel to a fixed one  
if you
want to run your programs compiled by 4.3 :-/  Not something we'd  
like to

demand.


I changed the title just for emphasis.

I think that we can't ship 4.3.0 if signal handlers on x86/x86_64
platforms for both Linux and BSD systems will mysteriously (to the  
users)

fail, and it doesn't matter whose fault it is.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Michael Matz]

Hi,

On Wed, 5 Mar 2008, Joe Buck wrote:

> 
> 
> On Wed, 5 Mar 2008, Jan Hubicka wrote:
> > > Linux kernel is disabling red zone and use kernel code model, yet the 
> > > ABI is not going to be adjusted for that.
> > > 
> > > This is resonably easy to fix on kernel side in signal handling, or by
> > > removing std usage completely
> 
> On Wed, Mar 05, 2008 at 10:02:07PM +0100, Michael Matz wrote:
> > That is true.  But it requires updating the kernel to a fixed one if you 
> > want to run your programs compiled by 4.3 :-/  Not something we'd like to 
> > demand.
> 
> I changed the title just for emphasis.
> 
> I think that we can't ship 4.3.0 if signal handlers on x86/x86_64
> platforms for both Linux and BSD systems will mysteriously (to the users)
> fail, and it doesn't matter whose fault it is.

FWIW I don't think it's a release blocker for 4.3.0.  The error is arcane 
and happens seldomly if at all.  And only on unfixed kernels.  A program 
needs to do std explicitely, which most don't do _and_ get hit by a signal 
while begin in a std region.  This happens so seldom that it didn't occur 
in building the next openSuSE 11.0, and it continually builds packages 
with 4.3 since months.

It should be worked around in 4.3.1 if at all.


Ciao,
Michael.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Richard Guenther]

On Wed, Mar 5, 2008 at 10:43 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
>
> On Wed, Mar 05, 2008 at 01:34:14PM -0800, H. Peter Anvin wrote:
>  > Richard Guenther wrote:
>  > >
>  > >We didn't yet run into this issue and build openSUSE with 4.3 since more
>  > >than
>  > >three month.
>  > >
>  >
>  > Well, how often do you take a trap inside an overlapping memmove()?
>
>  Also, would it be possible to produce an exploit?  If you can get string
>  instructions to work "the wrong way", you might be able to overwrite data.
>
>  "We haven't seen a problem" isn't the right answer.  Can someone
>  deliberately *create* a problem?
>
>  And if we aren't sure, we should err on the side of safety.

Oh, you mean releasing a kernel security update? ;)  What does ICC or
other compilers do?

Richard.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Aurelien Jarno]

Richard Guenther a écrit :
> On Wed, Mar 5, 2008 at 10:20 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
>>
>>  On Wed, 5 Mar 2008, Jan Hubicka wrote:
>>  > > Linux kernel is disabling red zone and use kernel code model, yet the
>>  > > ABI is not going to be adjusted for that.
>>  > >
>>  > > This is resonably easy to fix on kernel side in signal handling, or by
>>  > > removing std usage completely
>>
>>  On Wed, Mar 05, 2008 at 10:02:07PM +0100, Michael Matz wrote:
>>  > That is true.  But it requires updating the kernel to a fixed one if you
>>  > want to run your programs compiled by 4.3 :-/  Not something we'd like to
>>  > demand.
>>
>>  I changed the title just for emphasis.
>>
>>  I think that we can't ship 4.3.0 if signal handlers on x86/x86_64
>>  platforms for both Linux and BSD systems will mysteriously (to the users)
>>  fail, and it doesn't matter whose fault it is.
> 
> We didn't yet run into this issue and build openSUSE with 4.3 since more than
> three month.
> 

The problem can be easily reproduced by using a glibc built with gcc
4.3, with SBCL (the gcc version doesn't matter). The signal handler in
SBCL calls sigemptyset() which uses memset().


-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Chris Lattner]

On Mar 5, 2008, at 1:34 PM, H. Peter Anvin wrote:


Richard Guenther wrote:
We didn't yet run into this issue and build openSUSE with 4.3 since  
more than

three month.


Well, how often do you take a trap inside an overlapping memmove()?


How hard is it to change the kernel signal entry path from "pushf" to  
"pushf;cld"?  Problem solved, no?


-Chris

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Michael Matz]

Hi,

On Wed, 5 Mar 2008, Chris Lattner wrote:

> 
> On Mar 5, 2008, at 1:34 PM, H. Peter Anvin wrote:
> 
> >Richard Guenther wrote:
> > >We didn't yet run into this issue and build openSUSE with 4.3 since more
> > >than
> > >three month.
> >
> >Well, how often do you take a trap inside an overlapping memmove()?
> 
> How hard is it to change the kernel signal entry path from "pushf" to
> "pushf;cld"?  Problem solved, no?

The problem is with old kernels, which by definition stay unfixed.


Ciao,
Michael.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[H. Peter Anvin]

Chris Lattner wrote:


On Mar 5, 2008, at 1:34 PM, H. Peter Anvin wrote:


Richard Guenther wrote:
We didn't yet run into this issue and build openSUSE with 4.3 since 
more than

three month.


Well, how often do you take a trap inside an overlapping memmove()?


How hard is it to change the kernel signal entry path from "pushf" to 
"pushf;cld"?  Problem solved, no?


Not quite, but fixing it in the kernel is easy.

Still breaks for running on all old kernels.

-hpa

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Joe Buck]

On Wed, Mar 05, 2008 at 10:43:33PM +0100, Michael Matz wrote:
> Hi,
> 
> On Wed, 5 Mar 2008, Joe Buck wrote:
> 
> > 
> > 
> > On Wed, 5 Mar 2008, Jan Hubicka wrote:
> > > > Linux kernel is disabling red zone and use kernel code model, yet the 
> > > > ABI is not going to be adjusted for that.
> > > > 
> > > > This is resonably easy to fix on kernel side in signal handling, or by
> > > > removing std usage completely
> > 
> > On Wed, Mar 05, 2008 at 10:02:07PM +0100, Michael Matz wrote:
> > > That is true.  But it requires updating the kernel to a fixed one if you 
> > > want to run your programs compiled by 4.3 :-/  Not something we'd like to 
> > > demand.
> > 
> > I changed the title just for emphasis.
> > 
> > I think that we can't ship 4.3.0 if signal handlers on x86/x86_64
> > platforms for both Linux and BSD systems will mysteriously (to the users)
> > fail, and it doesn't matter whose fault it is.
> 
> FWIW I don't think it's a release blocker for 4.3.0.  The error is arcane 
> and happens seldomly if at all.  And only on unfixed kernels.  A program 
> needs to do std explicitely, which most don't do _and_ get hit by a signal 
> while begin in a std region.  This happens so seldom that it didn't occur 
> in building the next openSuSE 11.0, and it continually builds packages 
> with 4.3 since months.
> 
> It should be worked around in 4.3.1 if at all.

OK, I suppose that I over-reacted, and it seems that the ship has sailed
in any case.

I agree that it's obscure, and I think that the only reason to worry is
if it introduces a means of attack, which seems unlikely.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Adrian Bunk]

On Wed, Mar 05, 2008 at 10:59:21PM +0100, Michael Matz wrote:
> Hi,
> 
> On Wed, 5 Mar 2008, Chris Lattner wrote:
> 
> > 
> > On Mar 5, 2008, at 1:34 PM, H. Peter Anvin wrote:
> > 
> > >Richard Guenther wrote:
> > > >We didn't yet run into this issue and build openSUSE with 4.3 since more
> > > >than
> > > >three month.
> > >
> > >Well, how often do you take a trap inside an overlapping memmove()?
> > 
> > How hard is it to change the kernel signal entry path from "pushf" to
> > "pushf;cld"?  Problem solved, no?
> 
> The problem is with old kernels, which by definition stay unfixed.

Compiling older kernels with new gcc versions has never been supported.

You are e.g. aware that for many 32bit architectures (including i386) 
and kernels up to and including 2.6.25-rc4 even the build fails with
gcc 4.3?

> Ciao,
> Michael.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[David Miller]

From: "Richard Guenther" <[EMAIL PROTECTED]>
Date: Wed, 5 Mar 2008 22:40:59 +0100

> Right.  So this problem is over-exaggerated.  It's not like
> "any binary you create on that system will be broken on any
> other existing system."

I will be sure to hunt you down to help debug when someone reports
that once every few weeks their multi-day simulation gives incorrect
results :-)

This is one of those cases where the bug is going to be a huge
issue to people who actually hit it, and since we know about the
problem, knowingly shipping something in that state is unforgivable.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[David Miller]

From: Michael Matz <[EMAIL PROTECTED]>
Date: Wed, 5 Mar 2008 22:43:33 +0100 (CET)

> The error is arcane and happens seldomly if at all.  And only on
> unfixed kernels.

Which translates right now into "all kernels."

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[David Miller]

From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Thu, 6 Mar 2008 00:13:04 +0200

> On Wed, Mar 05, 2008 at 10:59:21PM +0100, Michael Matz wrote:
> > The problem is with old kernels, which by definition stay unfixed.
> 
> Compiling older kernels with new gcc versions has never been supported.

Adrian we're talking about userland binaries compiled by
gcc-4.3, not the kernel.

Please follow the discussion if you'd like to contribute.

Thanks.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Joe Buck]

On Wed, Mar 05, 2008 at 02:16:22PM -0800, David Miller wrote:
> From: "Richard Guenther" <[EMAIL PROTECTED]>
> Date: Wed, 5 Mar 2008 22:40:59 +0100
> 
> > Right.  So this problem is over-exaggerated.  It's not like
> > "any binary you create on that system will be broken on any
> > other existing system."
> 
> I will be sure to hunt you down to help debug when someone reports
> that once every few weeks their multi-day simulation gives incorrect
> results :-)
> 
> This is one of those cases where the bug is going to be a huge
> issue to people who actually hit it, and since we know about the
> problem, knowingly shipping something in that state is unforgivable.

In this case, it appears that the 4.3.0 tarballs already hit the
servers before the issue was discovered.

It's not the end of the world; quite often .0 releases have some issue,
and we can patch the 4_3 branch and recommend that the patch be used.

gcc-4.2-20080305 is now available

[gccadmin]

Snapshot gcc-4.2-20080305 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080305/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch 
revision 132956

You'll find:

gcc-4.2-20080305.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.2-20080305.tar.bz2 C front end and core compiler

gcc-ada-4.2-20080305.tar.bz2  Ada front end and runtime

gcc-fortran-4.2-20080305.tar.bz2  Fortran front end and runtime

gcc-g++-4.2-20080305.tar.bz2  C++ front end and runtime

gcc-java-4.2-20080305.tar.bz2 Java front end and runtime

gcc-objc-4.2-20080305.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.2-20080305.tar.bz2The GCC testsuite

Diffs from 4.2-20080227 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.2
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: [PATCH][4.3] Deprecate -ftrapv

[Ken Raeburn]

On Feb 29, 2008, at 19:13, Richard Guenther wrote:

We wrap the libcalls inside libcall notes using REG_EQUAL notes
which indicate the libcalls compute non-trapping +-* (there's no
RTX code for the trappingness), so we combine and simplify the
operations making the libcall possibly dead and remove it again.


My patch from September (http://gcc.gnu.org/ml/gcc-patches/2007-09/ 
msg01351.html) should help with the libcall issue a bit, by making  
the trapping libcalls not be considered dead, even if optimizations  
make the results not get used.  (Was I supposed to re-submit the  
patch in non-unidiff format?  I've had a couple of machine die on me  
recently, I might have to reconstruct the source tree.)  Of course,  
if the trapping math is optimized away before you get to emitting  
libcalls, that's a different bug.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Michael Matz]

Hi,

On Wed, 5 Mar 2008, David Miller wrote:

> I will be sure to hunt you down to help debug when someone reports that 
> once every few weeks their multi-day simulation gives incorrect results 
> :-)

Give them a LD_PRELOADable DSO that intercepts signal() and sig_action(), 
installing a trampoline that first does "cld" and then jumps to the real 
handler.  That ought to be a quick test if it's this or a different issue.  
A hack, yes, but well... :)

> This is one of those cases where the bug is going to be a huge issue to 
> people who actually hit it, and since we know about the problem, 
> knowingly shipping something in that state is unforgivable.

Many bugs are a big issue to people who actually hit them, and we had (and 
probably still have) far nastier corner case miscompilations here and 
there and nevertheless released.  It never was the end of the world :)

Let it be a data point that nobody noticed the problem which existed in 
trunk since more than a year (since 2006-12-06 to be precise).


Ciao,
Michael.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[H. Peter Anvin]

Michael Matz wrote:


Many bugs are a big issue to people who actually hit them, and we had (and 
probably still have) far nastier corner case miscompilations here and 
there and nevertheless released.  It never was the end of the world :)




This is the sort of stuff that security holes are made from.

-hpa

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Michael Matz]

Hi,

On Wed, 5 Mar 2008, H. Peter Anvin wrote:

> Michael Matz wrote:
> > 
> > Many bugs are a big issue to people who actually hit them, and we had (and
> > probably still have) far nastier corner case miscompilations here and there
> > and nevertheless released.  It never was the end of the world :)
> > 
> 
> This is the sort of stuff that security holes are made from.

For security problems I prefer fixes over work-arounds.  The fix lies in 
the kernel, the work-around in gcc.


Ciao,
Michael.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[David Miller]

From: Michael Matz <[EMAIL PROTECTED]>
Date: Thu, 6 Mar 2008 00:07:39 +0100 (CET)

> The fix lies in the kernel, the work-around in gcc.

This depends upon how you interpret this ABI situation.

There is at least some agreement that how things have
actually been implemented by these kernels for more
than 15 years trumps whatever a paper standard states.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Olivier Galibert]

On Thu, Mar 06, 2008 at 12:07:39AM +0100, Michael Matz wrote:
> For security problems I prefer fixes over work-arounds.  The fix lies in 
> the kernel, the work-around in gcc.

Incorrect.  The bugs are in the ABI documentation and in gcc, and the
fixes should be done there.  Doing it in the kernel is the workaround.

  OG.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Olivier Galibert]

On Thu, Mar 06, 2008 at 12:13:04AM +0200, Adrian Bunk wrote:
> Compiling older kernels with new gcc versions has never been supported.

You read the thread too fast.  It's not at all about compiling the
kernel.

  OG.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Joe Buck]

On Wed, Mar 05, 2008 at 03:10:12PM -0800, David Miller wrote:
> From: Michael Matz <[EMAIL PROTECTED]>
> Date: Thu, 6 Mar 2008 00:07:39 +0100 (CET)
> 
> > The fix lies in the kernel, the work-around in gcc.
> 
> This depends upon how you interpret this ABI situation.
> 
> There is at least some agreement that how things have
> actually been implemented by these kernels for more
> than 15 years trumps whatever a paper standard states.

We had a similar argument about the undefinedness of signed int
overflow.  That's what the standard says, yet code that assumes
otherwise is pervasive, including in gcc itself.

If a standard is widely violated in a very consistent way, the violation
in effect becomes standard.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Olivier Galibert]

On Wed, Mar 05, 2008 at 10:43:33PM +0100, Michael Matz wrote:
> FWIW I don't think it's a release blocker for 4.3.0.  The error is arcane 
> and happens seldomly if at all.  And only on unfixed kernels.  A program 
> needs to do std explicitely, which most don't do _and_ get hit by a signal 
> while begin in a std region.  This happens so seldom that it didn't occur 
> in building the next openSuSE 11.0, and it continually builds packages 
> with 4.3 since months.

How would you know whether it has happened?

  OG.

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[David Daney]

Olivier Galibert wrote:

On Wed, Mar 05, 2008 at 10:43:33PM +0100, Michael Matz wrote:
FWIW I don't think it's a release blocker for 4.3.0.  The error is arcane 
and happens seldomly if at all.  And only on unfixed kernels.  A program 
needs to do std explicitely, which most don't do _and_ get hit by a signal 
while begin in a std region.  This happens so seldom that it didn't occur 
in building the next openSuSE 11.0, and it continually builds packages 
with 4.3 since months.


How would you know whether it has happened?



The same way you do with other bugs: You would observe unexpected behavior.

In this case probably either corrupted memory or a SIGSEGV.

David Daney

[PING] Issues stopping us from removing libcall notes

[Steven Bosscher]

On Sat, Mar 1, 2008 at 12:31 AM, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> Please open a new bug report (enhancement request, probably)
>  for things that GCC still needs libcalls for, and make your new bug
>  report block PR34513.  Of course, it'd help if you then go on and
>  remove that dependency on libcall notes ;-)

This has so far triggered zero reactions, so I thought I'd remind
people about this request.  It might have gotten lost in all the long
ftrapv, alias, and ABI threads :-)

Gr.
Steven

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Chris Lattner]

Richard Guenther wrote:
We didn't yet run into this issue and build openSUSE with 4.3  
since more

than
three month.


Well, how often do you take a trap inside an overlapping memmove()?


How hard is it to change the kernel signal entry path from "pushf" to
"pushf;cld"?  Problem solved, no?


The problem is with old kernels, which by definition stay unfixed.


My impression was that the problem occurs in GCC compiled code in the  
kernel itself, not in user space:


1. User space has direction flag set.
2. signal occurs
3. kernel code is entered
4. kernel code does string operation 

Fixing this instance of the problem by changing GCC requires (at  
least) recompiling the kernel.


Changing the ABI for this seems like a pretty crazy solution to a very  
minor and easily fixable kernel bug.  Distros have control over what  
kernels they ship, they have absolute power to ensure this doesn't  
affect their users when running default kernels - without changing the  
compiler.


-Chris

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Aurelien Jarno]

Chris Lattner a écrit :
 Richard Guenther wrote:
> We didn't yet run into this issue and build openSUSE with 4.3 since
> more
> than
> three month.

 Well, how often do you take a trap inside an overlapping memmove()?
>>>
>>> How hard is it to change the kernel signal entry path from "pushf" to
>>> "pushf;cld"?  Problem solved, no?
>>
>> The problem is with old kernels, which by definition stay unfixed.
> 
> My impression was that the problem occurs in GCC compiled code in the
> kernel itself, not in user space:
> 
> 1. User space has direction flag set.
> 2. signal occurs
> 3. kernel code is entered
> 4. kernel code does string operation 

Wrong. Except maybe for the Hurd kernel. For other kernels:

  4. signal handler is called
  5. signal handler does string operation 

The GCC used to compile the kernel doesn't matter. Using gcc 4.3 to
compile the user code triggers the bug.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[H. Peter Anvin]

Chris Lattner wrote:

Richard Guenther wrote:
We didn't yet run into this issue and build openSUSE with 4.3 since 
more

than
three month.


Well, how often do you take a trap inside an overlapping memmove()?


How hard is it to change the kernel signal entry path from "pushf" to
"pushf;cld"?  Problem solved, no?


The problem is with old kernels, which by definition stay unfixed.


My impression was that the problem occurs in GCC compiled code in the 
kernel itself, not in user space:


That's wrong.

The issue is that the kernel is entered (due to a trap, interrupt or 
whatever) and the state is saved.  The kernel decides to revector 
userspace to a signal handler.  The kernel modifies the userspace state 
to do so, but doesn't set DF=0.


Upon return to userspace, the modified state kicks in.  Thus the signal 
handler is entered with DF from userspace at trap time, not DF=0.


So it's an asynchronous state leak from one piece of userspace to another.

-hpa

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Chris Lattner]

On Mar 5, 2008, at 4:47 PM, H. Peter Anvin wrote:


Chris Lattner wrote:

Richard Guenther wrote:
We didn't yet run into this issue and build openSUSE with 4.3  
since more

than
three month.


Well, how often do you take a trap inside an overlapping  
memmove()?


How hard is it to change the kernel signal entry path from  
"pushf" to

"pushf;cld"?  Problem solved, no?


The problem is with old kernels, which by definition stay unfixed.
My impression was that the problem occurs in GCC compiled code in  
the kernel itself, not in user space:


That's wrong.

The issue is that the kernel is entered (due to a trap, interrupt or  
whatever) and the state is saved.  The kernel decides to revector  
userspace to a signal handler.  The kernel modifies the userspace  
state to do so, but doesn't set DF=0.


Upon return to userspace, the modified state kicks in.  Thus the  
signal handler is entered with DF from userspace at trap time, not  
DF=0.


So it's an asynchronous state leak from one piece of userspace to  
another.


Fine, it can happen either way.  In either case, the distro vendor  
should fix the the signal handler in the kernels they distribute.  If  
you don't do that, you are still leaking information from one piece of  
user space code to another, you're just papering over it in a horrible  
way :)


GCC defines the direction flag to be clear before inline asm.  
Enforcing the semantics you propose would require issuing a cld before  
every inline asm, not just before every string operation.


-Chris

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[H. Peter Anvin]

Chris Lattner wrote:


Upon return to userspace, the modified state kicks in.  Thus the 
signal handler is entered with DF from userspace at trap time, not DF=0.


So it's an asynchronous state leak from one piece of userspace to 
another.


Fine, it can happen either way.  In either case, the distro vendor 
should fix the the signal handler in the kernels they distribute.  If 
you don't do that, you are still leaking information from one piece of 
user space code to another, you're just papering over it in a horrible 
way :)


GCC defines the direction flag to be clear before inline asm. Enforcing 
the semantics you propose would require issuing a cld before every 
inline asm, not just before every string operation.




It's a kernel bug, and it needs to be fixed.  The discussion is about 
what to do in the meantime.


(And yes, you're absolutely right: between global subroutine entry and 
the first asm or string operation, you'd have to emit cld.)


-hpa

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[Krzysztof Halasa]

"H. Peter Anvin" <[EMAIL PROTECTED]> writes:

> Not quite, but fixing it in the kernel is easy.
>
> Still breaks for running on all old kernels.

Many more things break on old kernels. I guess it's not worse than
a (local) root exploit, is it?

*-stable and distributions should take care of it, as they do in
others cases.
-- 
Krzysztof Halasa

Re: GCC build problem

[Jim Wilson]

Dasarath Weeratunge wrote:

I added a field to struct basic_block_def in basic-block.h of type
struct pointer_set_t.
Now when I try to rebuild GCC build fails with error:
libbackend.a(gtype-desc.o): In function `gt_pch_nx_basic_block_def':
/scratch/dweeratu/gcc/build/gcc/gtype-desc.c:2472: undefined reference
to `gt_pch_nx_pointer_set_t'


See   > 
http://gcc.gnu.org/onlinedocs/gccint/Type-Information.html#Type-Information

See also the gengtype.c file, and the doc/gty.texi file.

I'm just guessing, but you probably either need to add a GTY marker to 
the struct pointer_set_t definition, or else add a GTY skip marker to 
the new field in struct basic_block_def that uses the pointer_set_t 
type.  It depends on whether this info will be allocated in the garbage 
collection space (e.g. ggc_alloc).


Jim

Re: atomic accesses

[Marty Leisner]

Segher Boessenkool <[EMAIL PROTECTED]> writes  on Tue, 04 Mar
 2008 01:25:33 +0100
 > The Linux kernel, and probably some user-space applications and 
 > libraries
 > as well, depend on GCC guaranteeing (a variant of) the following:
 > 
 >  "any access to a naturally aligned scalar object in memory
 >  that is not a bit-field will be performed by a single machine
 >  instruction whenever possible"
 > 
 > and it seems the current compiler actually does work like this.
 > 
 > I propose we add this text to the GCC manual (where?), so at least they
 > are right if/when they blame us for breaking that promise :-)
 > 
 > Comments?  Flames?
 > 
 > 
 > Segher

And how  is "whenever possible" a guarantee?

Does this make a difference with the -O level?

marty