[Bug c/27445] New: create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps

[gary at intrepid dot com]

(see also: http://gcc.gnu.org/ml/gcc/2006-05/msg00158.html)

While following GCC's handling of 'volatile' and other type
qualifiers, I noticed that the gimplify pass created temporaries
with a type with 'volatile' asserted if the underlying type also
had 'volatile' asserted.

Temporaries are created by the create_tmp_var_raw() procedure
in gimplify.c, which reads as follows:

tree
create_tmp_var_raw (tree type, const char *prefix)
{
  tree tmp_var;
  tree new_type;

  /* Make the type of the variable writable.  */
  new_type = build_type_variant (type, 0, 0);
  TYPE_ATTRIBUTES (new_type) = TYPE_ATTRIBUTES (type);

  tmp_var = build_decl (VAR_DECL, prefix ? create_tmp_var_name (prefix) :
NULL,
type);
[...]

Note above that an unqualified type, new_type, is created but
then subsequently not used in the call to build_decl.  Because of
this omission, if 'type' originally had any qualifiers set
(such as volatile), they'll be propagated to the temporary, which
might have some unexpected effects on subsequent optimizations
and code generation.

The fix, I think, is to pass 'new_type'.


-- 
   Summary: create_tmp_var_raw (gimplify.c) inadventently asserts
'volatile' on temps
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gary at intrepid dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445

[Bug c/27445] create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps

[gary at intrepid dot com]

--- Comment #2 from gary at intrepid dot com  2006-05-05 16:06 ---
Created an attachment (id=11382)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11382&action=view)
create_tmp_var_raw patch: remove type qualifiers

This patch compiles, but hasn't been tested.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445

[Bug c/27445] create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps

[gary at intrepid dot com]

--- Comment #3 from gary at intrepid dot com  2006-05-05 16:12 ---
(In reply to comment #1)
> Do you have a testcase this will better understand the problem and to see if
> your patch is correct?

I'm not sure how to demonstrate that there is a problem.  I think it
is clear that the author of the function planned on using new_type
instaed of type, and that it is incorrect to assert 'volatile' on
a compiler temporary, but am uncertain as to whether asserting
'volatile' leads to any particular difficulties in the present
compiler.  I'm hoping one of the gimplify developers can help
construct a test case, if applicable.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445

[Bug middle-end/27445] create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps

[gary at intrepid dot com]

--- Comment #5 from gary at intrepid dot com  2006-05-05 16:37 ---
(In reply to comment #4)
> Then the real question is why do you think this is a bug?

1. it is a bug to create temporaries and assert 'volatile' on them
2. there is code in create_tmp_var_raw() that creates a type with
qualifiers removed, but this new_type is then not used at the
moment.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445

[Bug middle-end/27445] create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps

[gary at intrepid dot com]

--- Comment #7 from gary at intrepid dot com  2006-05-05 16:58 ---
Consider the following:

volatile int j;
void p()
{
  ++j;
}

Gimplify in its present form might transform the statement above into
something like the following:

volatile int j;
void p()
{
  volatile int T1;
  T1 = j + 1;
  j = T1;
}

Here, gimplify has created a local temporary but has tagged it as
volatile, because j is volatile.

Taken literally, (j + 1) must be evaluated, and its value stored
into T1, and T1 must be a _memory_ location, not a register,
which looks like this on an x86:

movlj, %eax
addl$1, %eax
movl%eax, -4(%ebp)
movl-4(%ebp), %eax
movl%eax, j

Now as it turns out, somehow gimplify and the follow-on optimization
passes don't seem to target T1 into a memory location, probably because
they "know" that temporary variables for scalars should live in registers.
But still the compiler does create a temporary like T1 above and
qualifies T1 as volatile.  The fact that subsequent passes seem to
ignore the qualifier is logically inconsistent, and at some level
incorrect.  Will they always ignore that qualifier?  Who can say?

Note also that at present "const" and "restricted" (on pointers)
can also be specified.  Can't say if applying them to temporaries
causes any real harm, but again, it is logically inconsistent.
If we believe that gimplify should create trees that are well-formed
unambiguous and that precisely describe the semantics of the program
that is being translated, then I think the type qualifiers should be
dropped when declaring compiler temporaries.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445

[Bug middle-end/27445] create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps

[gary at intrepid dot com]

--- Comment #9 from gary at intrepid dot com  2006-05-05 17:55 ---
> Your issue with ++j not using incr is not related to the gimplifier at all as
> it also happens in every compiler version since at least 2.95.3.

I agree that is unrelated.  I didn't file this bug thinking that it would help
"fix" the "incr issue".  In fact, I don't really have an "incr issue" -- it
was just something that came up while I was writing some tests.

> > Gimplify in its present form might transform the statement above into
> > something like the following:
[...]
> It will never get the wrong type. because create_tmp_from_val uses
> TYPE_MAIN_VARIANT.

Well, I originally noticed the problem in 4.0.1, which has the following
code:

static inline tree
create_tmp_from_val (tree val)
{
  return create_tmp_var (TREE_TYPE (val), get_name (val));
}

The dev tree now how this code:

static inline tree
create_tmp_from_val (tree val)
{
  return create_tmp_var (TYPE_MAIN_VARIANT (TREE_TYPE (val)), get_name (val));
}

I haven't looked into the rev. history, to see why/when this fix was made,
but will ask the hypothetical: was this fix made to workaround the
misbehavior in create_tmp_var_raw()?  Note that create_tmp_var_raw()
is exported from gimplify.c and appears to be called from quite a few
places.  The question arises: what are the preconditions for calling
create_tmp_var_raw()?  If you want to assert that it uses whatever
type was passed in and all the callers have to remove qualifiers
as necessary that's fine, but requires some knowledge of the original
intent behind create_tmp_var_raw() and the assumptions its callers make.
I'd be temtpted to add an assert that the type passed in has no qualifiers
if that is a pre-condition.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445

[Bug middle-end/27445] create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps

[gary at intrepid dot com]

--- Comment #12 from gary at intrepid dot com  2006-05-06 01:42 ---
Given the above, I suggest that my bug report be marked closed,
because the problem I was seeing in 4.0.1 is fixed by the
change to create_tmp_from_val that passes in TYPE_MAIN_VARIANT().
Note that the use of the main variant is stronger (removes more
qualifiers/attirbutes) than the code that sets new_type anyway.

It might be a good idea to remove the setting of new_type since
it isn't used.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445

[Bug c/28141] New: thread-local ptr initialized to address of thread-local misclassified as non-constant initializer

[gary at intrepid dot com]

Given the following:
 1  double __thread data;
 2  double __thread * ptr = &data;

leads to following error diagnostic:

% gcc -c t.c
t.c:3: error: initializer element is not constant

compiled with:
gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)

Given that both 'data' and 'ptr' are thread local, can the
address of 'data' be considered as constant?  If 'ptr' were declared
at file scope, then the initializer would be problematic, but as
a thread-local declaration, the initializer appears to be non-ambiguous.


-- 
   Summary: thread-local ptr initialized to address of thread-local
misclassified as non-constant initializer
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gary at intrepid dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28141

[Bug c/28141] thread-local ptr initialized to address of thread-local misclassified as non-constant initializer

[gary at intrepid dot com]

--- Comment #2 from gary at intrepid dot com  2006-06-23 16:44 ---
I agree this is definitely an enhancement, but will note the following:

1. On Fedora Core 5, x86_64, I was able to successfully link and run
a null program (written in assembly) that initializes thread local
'ptr' that points to thread local 'data'.  The declarations appear
as follows:
.globl data
.section.tbss,"awT",@nobits
.align 8
.type   data, @object
.size   data, 8
data:
.zero   8
.globl ptr
.align 8
.type   ptr, @object
.size   ptr, 8
ptr:
.quad   data
I didn't run extensive tests to verify this was doing the right thing, but
there were no complaints from the linker.

2. Given that __thread is an extension, we could choose to interpret
"constancy", as "constant from the perspective of the currently executing
thread" without doing much harm to "C" semantics.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28141

[Bug target/20020] New: x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

[Also posted to the GCC mailing list, http://gcc.gnu.org/ml/gcc/2005-
02/msg00692.html]


Given,

struct shared_ptr_struct
  {
unsigned int phase  : 24;
unsigned short thread : 16;
void *addr;
  };

On the x86_64 (ie, Opteron[tm]) platform, GCC appears to designate the
underlying mode of this type as a BLKmode, instead of a TImode.  This
has implications in terms of the quality of the code that is generated
to copy and manipulate 128 bit structures (as defined in the example
above).

The decision to commit this type to a BLKmode value, originates
in this logic in mode_for_size():

  if (limit && size > MAX_FIXED_MODE_SIZE)
 return BLKmode;

On the x86 platform, there appears to be no target definition for
MAX_FIELD_SIZE. Thus, the default in stor-layout.c applies:

#ifndef MAX_FIXED_MODE_SIZE
#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (DImode)
#endif

Other 64 bit targets define MAX_FIXED_MODE_SIZE along these lines
(some line wrapping may occur below):

config/i960/i960.h:#defineMAX_FIXED_MODE_SIZE GET_MODE_BITSIZE
(TImode)
config/ia64/ia64.h:#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TImode)
config/mips/mips.h:#define MAX_FIXED_MODE_SIZE LONG_DOUBLE_TYPE_SIZE
config/sh/sh.h:#define MAX_FIXED_MODE_SIZE (TARGET_SH5 ? 128 : 64)

on MIPS, LONG_DOUBLE_TYPE_SIZE is defined as follows:

/* A C expression for the size in bits of the type `long double' on
   the target machine.  If you don't define this, the default is two
   words.  */
#define LONG_DOUBLE_TYPE_SIZE \
  (mips_abi == ABI_N32 || mips_abi == ABI_64 ? 128 : 64)

In the 'dev' tree, the s390 defines MAX_FIXED_MODE_SIZE as follows:

config/s390/s390.h:#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE
(TARGET_64BIT ? TImode : DImode)

(Arguably, the s390 variant might be a better default value to be defined
in stor-layout.c)

-- 
   Summary: x86_64 - 128 bit structs not targeted to TImode
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: gary at intrepid dot com
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

--- Additional Comments From gary at intrepid dot com  2005-02-17 19:35 
---
The MAX_FIXED_REC_SIZE defintion is a relatively recent addition to 
config/rs6000.h (and from a quick review of the cvs log, it seems that this 
change hasn't yet been incorporated into a release.) Just fyi.

revision 1.330 
date: 2004/08/11 19:18:14;  author: dje;  state: Exp;  lines: +6 -0
* config/rs6000/rs6000.h (MAX_FIXED_MODE_SIZE): Define.
 
* config/rs6000/rs6000.md (mfcr rlwinm patterns): Set length to 8.
(mfcr rlwinm rlwinm patterns): Set length to 12.




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

--- Additional Comments From gary at intrepid dot com  2005-02-17 21:41 
---

> Also note MAX_FIXED_MODE_SIZE was changed on 
> rs6000 for a reason and not for an optimization issue.

Based on my interpretaion of the procedure call ABI, both this problem and a 
related Bug #19566 demonstrate a variance from the AMD 64 bit ABI (see "System 
V Application Binary Interface AMD64 Architecture Processor Supplement", Draft 
Version 0.95, January 14, 2005, section 3.2.3).

If this is a correct interpretation of the ABI, then both bugs are not just 
performance related.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

--- Additional Comments From gary at intrepid dot com  2005-02-17 22:39 
---

> I think that Bug #19566 is a real bug.  The ABI specifies to pass 16byte 
> structs in registers.  Anyway MAX_FIXED_MODE_SIZE doesn't influence 
> the calling convention ...

Thanks for the clarification.  After re-reading classify_argument()
in config/i386/i386.c, I agree.  I had thought that for all BLKmode
values that it would target the argument into memory, however, for
aggregate types (records/unions, etc) it ignores the mode and looks
at each field (per the ABI). Thus, I agree this Bug #20020 is
performance-related only, and Bug #19566 illustrates a variance from
the procedure call ABI.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

[Bug c/20319] New: -fkeep-static-consts with -O asserted doesn't keep consts

[gary at intrepid dot com]

Related discussion:
http://gcc.gnu.org/ml/gcc/2005-03/msg00181.html

Given the following,

static char const rcsid[] =
"$Id: f.c,v 5.4 1993/11/09 17:40:15 eggert Exp $";
int main() {}

When compiled with GCC 3.4.3, at -O2, the ident string above will _not_
appear in the executable.  This is apparently expected behavior.

However,
  gcc -fkeep-static-consts -O2 t.c
did not retain the ident string, rcsid, defined above.  Shouldn't
-fkepp-static-consts have ensured that this static constant would appear
in the executable?

The logic in wrapup_global_declarations (toplev.c) doesn't look quite right:

  else if (TREE_READONLY (decl) && !TREE_PUBLIC (decl)
   && (optimize || !flag_keep_static_consts 
   || DECL_ARTIFICIAL (decl))) 
needed = 0; 

If 'optimize' is asserted above then flag_keep_static_consts will
not be tested.  Perhaps it should read as follows?

   && ((optimize && !flag_keep_static_consts)

Alternatively, I wonder if flag_keep_static_consts should be tested earlier at a
higher level, for example:

   if (flag_keep_static_consts)
  /* needed */;

but I'm not sure about which of the earlier tests which assert needed = 0;
are mandatory and which are optional.

-- 
   Summary: -fkeep-static-consts with -O asserted doesn't keep
consts
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
    AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gary at intrepid dot com
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20319

[Bug c/20321] New: keep static constants if named section attribute asserted

[gary at intrepid dot com]

Related discussion:
http://gcc.gnu.org/ml/gcc/2005-03/msg00181.html
Related bug report: Bug #20319

I tried adding a section attribute to a static constant string declaration
which is otherwise not referenced, in the hope that the compiler would
retain the static constant because it had been explicitly
targeted to a named section,

static char const __attribute__ ((section("ident_sect"))) rcsid[] =
"$Id: f.c,v 5.4 1993/11/09 17:40:15 eggert Exp $";
int main() {}

but this didn't prevent the elimination of the const static defintion.

Enhancement request: If an explicit section attribute
is supplied for a static constant declaration (where the declaration
is not otherwise referenced), do not eliminate the static constant
definition.  The rationale for this policy is that it is
reasonable to assume that if the user is explicitly assigning the
static constant to a named section, then he/she intends to use that
static constant defintion, and does not want it eliminated from the
executable image.

-- 
   Summary: keep static constants if named section attribute
asserted
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: gary at intrepid dot com
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20321

[Bug c/20319] -fkeep-static-consts with -O asserted doesn't keep consts

[gary at intrepid dot com]

--- Additional Comments From gary at intrepid dot com  2005-03-04 20:24 
---
"Emit variables declared @code{static const} when optimization isn't turned 
on, even if the variables aren't referenced."

How odd.  I should've checked the docs, but this brief explanation in the
help line made a lot of sense to me.

  -fkeep-static-constsEmit static const variables even if they are not
  used

Also, since the constant *was kept* when I compiled _without_ optimization,
the idea of passing a switch telling the compiler to do something that
it seemed to already be doing by default didn't make sense to me.

The comments inside toplev.c say the following:

/* Nonzero means that we should emit static const variables
   regardless of whether or not optimization is turned on.  */ 

int flag_keep_static_consts = 1;


which makes sense to me.  Note that this is the default setting.

So ... coming back to the if statement in toplev.c:

  else if (TREE_READONLY (decl) && !TREE_PUBLIC (decl)
   && (optimize || !flag_keep_static_consts
   || DECL_ARTIFICIAL (decl)))
needed = 0;

At present,

If optimize is set, the unused static constant will always be eliminated
and -fkeep-static-consts will have no effect, and there is no way to override
this behavior (except for __attribute__ ((used))). 

This agrees with the documentation, but disagrees with the
comment in the code, and with the spirit of the help message.  It also
doesn't make sense to me that -fkeep-static-consts would be ignored. In
fact, it seems to me that -fkeep-static-consts should override the
optimization setting.  Otherwise, only -fno-keep-static-consts has
any effect and that is only when optimization is not enabled.

I think the behavior of -fkeep-static-consts should be modified so that
setting this switch overrides the optimization level.  Thus, the
documentation would need to be changed as well.  Otherwise, the internal
comments and the help line are wrong.

Regarding the "used" attibute, I thought that I'd tried that, and it
didn't work.  But upon retesting, it does seem to have the desired
effect of keeping the static const around (maybe I specified the "unused"
attribute by mistake in my test).

Note that the "used" attribute is described only under "function attributes"
and not under "variable attributes" in the documentation:

used
This attribute, attached to a function, means that code must be emitted for 
the function even if it appears that the function is not referenced. This is 
useful, for example, when the function is referenced only in inline assembly. 

(see: http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Function-
Attributes.html#Function-Attributes)

It would be helpful if the documentation were updated to describe the
behavior of the `used' attribute when apllied to variables.


-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20319

[Bug c/20319] -fkeep-static-consts with -O asserted doesn't keep consts

[gary at intrepid dot com]

--- Additional Comments From gary at intrepid dot com  2005-03-04 21:54 
---


Here is some detail on my proposed change in behavior:

1) Change the default setting to -fno-keep-static-consts:

/* Nonzero means that we should emit static const variables
   regardless of whether or not optimization is turned on.  */ 

int flag_keep_static_consts = 0;

2) have flag_keep_static_consts affect only the behavior of the
compiler when 'optimize' is asserted:

Change the logic in wrapup_global_declarations (toplev.c) to read:

  else if (TREE_READONLY (decl) && !TREE_PUBLIC (decl)
   && (optimize && !flag_keep_static_consts)
   || DECL_ARTIFICIAL (decl))) 
needed = 0;

This change would imply that:

1) -fkeep-static-consts and -fno-keep-static-consts will have no effect
at -O0.  Presently, -fno-keep-static-consts would eliminate the unreferenced
static const variable if it isn't referenced.  This would no longer be
the case. At -O0, the compiler would always leave unrefereced static
consts alone.

2) If optimization is asserted (ie, -O1 and above), then always eliminate
static const's that aren't referenced, unless -fkeep-static-consts is
asserted.




-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20319

[Bug c/20533] New: documentation: attribute 'used', applied to a variable

[gary at intrepid dot com]

See related discussion in Bug #20319, and at
http://gcc.gnu.org/ml/gcc/2005-03/msg00450.html

The "used" attribute is described only under "function attributes"
and not under "variable attributes" in the documentation:

used
This attribute, attached to a function, means that code must be emitted for 
the function even if it appears that the function is not referenced. This is 
useful, for example, when the function is referenced only in inline assembly. 

(see: http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Function-
Attributes.html#Function-Attributes)

It would be helpful if the documentation were updated to describe the
behavior of the `used' attribute when apllied to variables.

-- 
   Summary: documentation: attribute 'used', applied to a variable
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gary at intrepid dot com
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20533

[Bug c/20319] -fkeep-static-consts with -O asserted doesn't keep consts

[gary at intrepid dot com]

--- Additional Comments From gary at intrepid dot com  2005-03-18 16:16 
---
from http://gcc.gnu.org/ml/gcc/2005-03/msg00491.html

I think that the switch name
-fkeep-static-consts might be more consistenly named if it
was given the opposite sense and named something like
-fdelete-unused-static-consts.  The idea here is that by
asserting the switch a particular optimization is _enabled_.
Thus the optimizations performed at each level can be consistently
enumerated by asserting a particular set of switches which enable
specific optimizations.  This would change the present user interface,
however, I doubt that anyone is making extensive use of the current
interface because at present only -fno-keep-static-consts, asserted
at -O0 (no optimization), actually changes the default behavior of
the compiler.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20319

[Bug target/19566] x86_64 - inconsistent choice of parameter passing method for 16 byte struct

[gary at intrepid dot com]

--- Comment #9 from gary at intrepid dot com  2008-09-27 00:18 ---
(In reply to comment #8)
> It has been fixed in gcc 4.1.2.

FWIW, I just tried this on a gcc 4.0.1 that we have on hand here, and it also
appeared to be fixed in that version.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19566

[Bug target/54142] ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142

--- Comment #7 from Gary Funck  2012-08-11 01:24:37 
UTC ---
We're still running into this build failure on PPC64, using a recent revision
of the HEAD version.  Is there additional information that is needed to help
track down the cause of the build failure?

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

--- Comment #14 from Gary Funck  2012-08-11 03:22:34 
UTC ---
(In reply to comment #13)
> Is this bug obsolete now?

Comment #7 (2005-06-25) states that this is a valid bug, and near as I can tell
the current compiler still does not target 16-byte aligned (or potentially
aligned) struct's into TImode values.  Thus, I don't see any technical reason
mentioned in the subsequent comments that describe why this bug should be
marked  as obsolete.

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

--- Comment #16 from Gary Funck  2012-08-12 18:08:05 
UTC ---
Created attachment 27995
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27995
test case #1 - struct targeted to TImode

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

--- Comment #17 from Gary Funck  2012-08-12 18:11:25 
UTC ---
Created attachment 27996
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27996
test case #2 - struct targeted to TImode

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

--- Comment #18 from Gary Funck  2012-08-12 18:17:19 
UTC ---
Created attachment 27997
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27997
test case #3 - struct targeted to TImode

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

--- Comment #19 from Gary Funck  2012-08-12 18:30:25 
UTC ---
(In reply to comment #15)
> Do we have a run-time testcase?

I attached three compile-time test cases that check if the generated RTL refers
to TImode values.  The test cases are set up to only run on x86_64 and x86
targets. I confirmed that they work as expected on an x86_64 target (with and
without the MAX_FIXED_MODE_SIZE patch).  Not sure if it will work on x86 or
not.  The test case may have to be tweaked for x86.

Is this sufficient?  I don't know how a run-time test would demonstrate the use
of TImode, except in the form of a benchmark.

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

--- Comment #21 from Gary Funck  2012-08-12 21:24:40 
UTC ---
(In reply to comment #20) 
> X86 doesn't support __int128 and requires SSE for TImode.
> We may need to limit those testcases for int128 target.

OK, I'll add: /* { dg-require-effective-target int128 } */.

> If it is an ABI, we can add a testcase to gcc.target/x86_64/abi
> for x86-64.  If there is no additional issues for x86-64, I think
> we can close it after checking in those testcases.

This issue is performance-related, not ABI-related, per the discussion replies. 

The tests will FAIL on the current compiler because it does not assign TI mode
to 128 bit struct's.  The tests PASS if the suggested MAX_FIXED_MODE_SIZE
definition is added to config/i386/i386.h.

Note: Applying the new MAX_FIXED_MODE_SIZE definition patch will result in at
least one GCC test regression (see comment #9).

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

Gary Funck  changed:

   What|Removed |Added

  Attachment #27995|0   |1
is obsolete||

--- Comment #22 from Gary Funck  2012-08-12 21:45:09 
UTC ---
Created attachment 28000
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28000
test case #1 - struct targeted to TImode

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

Gary Funck  changed:

   What|Removed |Added

  Attachment #27996|0   |1
is obsolete||

--- Comment #23 from Gary Funck  2012-08-12 21:47:47 
UTC ---
Created attachment 28001
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28001
test case #2 - struct targeted to TImode

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

Gary Funck  changed:

   What|Removed |Added

  Attachment #27997|0   |1
is obsolete||

--- Comment #24 from Gary Funck  2012-08-12 21:50:33 
UTC ---
Created attachment 28002
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28002
test case #3 - struct targeted to TImode

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

--- Comment #25 from Gary Funck  2012-08-12 22:08:50 
UTC ---
(In reply to comment #20)
> X86 doesn't support __int128 and requires SSE for TImode.
> We may need to limit those testcases for int128 target.

If targeting struct's to TImode is supported on x86 targets then perhaps this
definition will need to be refer to 128 bit target support?

#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TARGET_64BIT ? TImode : DImode)

Off-hand, I don't know the target macro that does this.

something like this?

#define MAX_FIXED_MODE_SIZE targetm.scalar_mode_supported_p (TImode) ? TImode :
DImoe

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

--- Comment #26 from Gary Funck  2012-08-12 22:14:56 
UTC ---
Typo fixed below:

#define MAX_FIXED_MODE_SIZE targetm.scalar_mode_supported_p (TImode) ? TImode :
DImode

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

--- Comment #28 from Gary Funck  2012-08-12 22:43:16 
UTC ---
(In reply to comment #27)
> Please try this patch:
> 
> diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
> index c4d85b7..6c4c2ce 100644
> --- a/gcc/config/i386/i386.h
> +++ b/gcc/config/i386/i386.h
> @@ -1853,6 +1853,10 @@ do {\
> 
>  /* #define SLOW_UNALIGNED_ACCESS(MODE, ALIGN) 0 */
> 
> +/* An integer expression for the size in bits of the largest integer machine
> +   mode that should actually be used.  We allow pairs of registers.  */
> +#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TARGET_64BIT ? TImode : DImode)
> +
>  /* Define this macro if it is as good or better to call a constant
> function address than to call an address kept in a register.

That's the patch that I have been using and testing against (ref: comment #9).

I suggested this:
#define MAX_FIXED_MODE_SIZE targetm.scalar_mode_supported_p (TImode) ? TImode :
DImode
because it might allow x86 targets with SSE to also target TIMode for 128 bit
struct's (on the assumption that TImode will be more efficient).

[Bug target/54142] ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142

--- Comment #11 from Gary Funck  2012-08-13 23:00:57 
UTC ---
It is possible that revision 189908 introduced the 'mcom' change.

Index: src/gcc/config/rs6000/rs6000.h
===
--- src/gcc/config/rs6000/rs6000.h  (revision 189907)
+++ src/gcc/config/rs6000/rs6000.h  (revision 189908)
@@ -101,17 +101,12 @@
you make changes here, make them also there.  */
 #define ASM_CPU_SPEC \
 "%{!mcpu*: \
-  %{mpower: %{!mpower2: -mpwr}} \
-  %{mpower2: -mpwrx} \
   %{mpowerpc64*: -mppc64} \
   %{!mpowerpc64*: %{mpowerpc*: -mppc}} \
-  %{mno-power: %{!mpowerpc*: -mcom}} \
-  %{!mno-power: %{!mpower*: %(asm_default)}}} \
+  %{!mpowerpc*: -mcom}} \
[...]

r189908 | segher | 2012-07-27 04:44:37 -0700 (Fri, 27 Jul 2012) | 115 lines

2012-07-26  Segher Boessenkool  

gcc/
* common/config/rs6000/rs6000-common.c (rs6000_handle_option):
Delete code for -mno-power, -mpower, and -mpower2.
* config/rs6000/aix43.h (NON_POWERPC_MASKS): Delete.
(SUBTARGET_OVERRIDE_OPTIONS): Delete check for POWER together
with -maix64.
[...]

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

--- Comment #30 from Gary Funck  2012-08-14 04:24:54 
UTC ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00839.html

[Bug target/54142] [4.8 regression] ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142

--- Comment #15 from Gary Funck  2012-08-14 13:17:26 
UTC ---
(In reply to comment #14)
> Yeah, IMHO it should have added
>   %{!mpower*: %(asm_default)}} \
> line instead of
>   %{!mpowerpc*: -mcom}} \

That change fixed the build failure on a POWER7 system running RHEL 6.2 that I
tried it on, where it failed without the patch.

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

--- Comment #34 from Gary Funck  2012-08-14 23:55:57 
UTC ---
(In reply to comment #33)
> We must make sure that
> 
> ---
> union S160
> {
>   long double a;
> };
> extern union S160 check160 (void);
> extern void checkx160 (union S160);
> void
> test160 (void)
> {
>   checkx160 (check160 ());
> }
> ---
> 
> compiles.

I agree.  I looked into this briefly, but was unsure how to fix the issue.

What I can do is incorporate whatever fix is agreed upon into the patch, and
add this as an explicit test case.  Even though it is slightly duplicative, it
will be clearer what's going on if a regression occurs later on.

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

--- Comment #35 from Gary Funck  2012-08-15 00:00:43 
UTC ---
Note that for the test case in comment #34 (and comment #9) to fail that the
MAX_FIXED_MODE_SIZE patch has to be applied, and likely GCC internal checking
has to be enabled.

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

--- Comment #37 from Gary Funck  2012-08-15 03:34:55 
UTC ---
(In reply to comment #36)
> (In reply to comment #35)
> > Note that for the test case in comment #34 (and comment #9) to fail that the
> > MAX_FIXED_MODE_SIZE patch has to be applied, and likely GCC internal 
> > checking
> > has to be enabled.
> 
> This patch seems to work:
[...]

Thanks, I couldn't figure out how to successfully apply that git-svn formatted
patch to my svn based working copy.

Would you like to first apply your patch, update the trunk, and then I'll test
it against my patch, and then RFA if all goes well?

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

--- Comment #41 from Gary Funck  2012-08-15 13:47:37 
UTC ---
(In reply to comment #38)
> What are the code generation deficiencies you are targeting with this?  For
> testcase #1 I get
> 
> sptr_result:
> .LFB0:
> .cfi_startproc
> movqS+8(%rip), %rdx
> movqS(%rip), %rax
> ret
> 
> what would you expect instead?
> 
> I don't think we should change MAX_FIXED_MODE_SIZE, nor make use of
> TImode unconditionally.

All three test cases were designed simply to make them easy to check via an RTL
scan for the presence/use of TImode.  I chose three arbitrary small test cases
with the only criteria that they used the struct's differently.

As far as the motivation for suggesting the change, I noted that several other
targets assign 128-bit struct's into TImode values.  Therefore, I assumed that
there must be some benefit, and that this was an oversight in the x86_64
implementation.

In the GUPC implementation of the UPC programming language, a pointer into
shared space has three components (virtual-offset,thread,phase). This
pointer-to-shared (PTS) can be represented in a "packed" mode, where it uses 64
bits, but gives up some range for each of the fields.  The more general form is
the "struct" representation which provides full range for the fields and is
128-bits -- as the name implies, the underlying PTS representation manipulated
by the compiler is a struct.  Note that the packed representation could be a
struct also (with bit fields), but back when this project was started code
generation for structs and bit-fields wasn't very good; the code quality was
better if the compiler hand-crafted the necessary bit field manipulations.

Since UPC programs use PTS's frequently, we found that targeting them to TImode
containers improved various micro-benchmarks.  We noted that other targets like
MIPS and PPC did this and assumed it would be a good idea for x86_64 to follow
suit.  We don't have any hard data on the level of performance improvement,
though as Chip noted, some modest space savings were gained in libstdc++.

I can re-run some UPC tests, if that helps, but they have a rather specific
usage pattern.  Maybe something like the SPEC benchmarks would be more
compelling, but I don't have access to them.

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020

--- Comment #44 from Gary Funck  2012-08-15 14:45:42 
UTC ---
(In reply to comment #43)
> The problem is we return a TI union in XF register
> because the x86-64 psABI.

Is this the same problem documented in comment #9?

The patch that you suggested in comment #36 doesn't fix it?

[Bug other/54279] New: first stage build with g++ fails with "." as the first component of $PATH

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54279

 Bug #: 54279
   Summary: first stage build with g++ fails with "." as the first
component of $PATH
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@intrepid.com


Posted here:
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01032.html

This build failure is a likely result of the recent change to compile GCC with
the C++ compiler during the first stage.

1. I have "." on $PATH.

2. In one build of the latest GCC trunk, I specify
   CC=/usr/bin/gcc and CXX=/usr/bin/g++ and everything
   works.

3. In another build, I don't specify CC or CXX.
   Therefore they default to 'gcc' and 'g++'.
   This fails:
   g++: error trying to exec 'cc1plus': execvp: No such file or directory

If I remove "." from $PATH then the configuration in 3 will build.

The problem is that there is a g++ executable under the
built gcc directory, but cc1plus and other g++ component
parts haven't been built yet.

[Bug target/54308] [4.8 regression] build regression in 190498 on ppc64/linux: legitimate_indirect_address_p undefined

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54308

--- Comment #5 from Gary Funck  2012-08-18 18:39:42 
UTC ---
(In reply to comment #1)
> (Note, apparent s/4.2.1/4.1.2/g in initial description.)
> 
> I'd suggest updating to just a later gcc build, if you can find *only slightly
> newer* rpm:s; as for a x86_64-linux F 8 with gcc-4.1.2-33 ("gcc (GCC) 4.1.2
> 20070925 (Red Hat 4.1.2-33)"), I'm well into stage 1 for r190498.

FYI, the failing system has Redhat Release 8 (circa 2002).  Fedocra Core 8
didn't come out until circa 2007.  Thus, it would be surprising that an FC8 RPM
will build on the much older RH8 system.

[Bug other/54324] New: GCC install document does not list minimum required g++ versions

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54324

 Bug #: 54324
   Summary: GCC install document does not list minimum required
g++ versions
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@intrepid.com


Ref: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01223.html

Currently, install.texi states:

@heading Tools/packages necessary for building GCC
@table @asis
@item ISO C90 compiler
Necessary to bootstrap GCC, although versions of GCC prior
to 3.4 also allow bootstrapping with a traditional (K&R) C compiler.

To build all languages in a cross-compiler or other configuration where
3-stage bootstrap is not performed, you need to start with an existing
GCC binary (version 2.95 or later) because source code for language
frontends other than C might use GCC extensions.

This appears to be out-of-date with respect to new GCC 4.8 C++ stage 1
build requirement.

[Bug other/54326] New: GCC does not build with G++ version 3.4.0

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326

 Bug #: 54326
   Summary: GCC does not build with G++ version 3.4.0
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@intrepid.com


Ref: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01223.html
See also: Bug #54324 (install documentation does not list the minimum required
g++ version)

Paul Hargrove noted the following build failure on an older x86-32 Linux
(Redhat 8.0) system.

The g++ version is: g++ (GCC) 3.4.0

g++ -c   -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -fno-common
 -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
-I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc
-I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/build
-I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../include
-I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libcpp/include
-I/usr/local/pkg/gmp-4.2.4/include -I/usr/local/pkg/mpfr-2.4.2/include
-I/usr/local/pkg/mpc-0.8/include
 -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libdecnumber
-I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libdecnumber/bid
-I../libdecnumber\
-o build/genoutput.o
/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c
/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c: In function
`void note_constraint(rtx_def*, int)':
/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c:1178: error:
reinterpret_cast from type `const char (*)[1]' to type `char*' casts away
constness
make[2]: *** [build/genoutput.o] Error 1
make[2]: Leaving directory `/usr/local/pkg/upc/nightly/compiler/bld/gcc'
make[1]: *** [all-gcc] Error 2

[Bug other/54326] GCC does not build with G++ version 3.4.0

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326

--- Comment #1 from Gary Funck  2012-08-19 20:54:51 
UTC ---
Don't know if this is relevant, but a recent thread on the clang-dev list
explored the differences between GCC and clang in the handling of const and
constexpr.
"clang vs GCC error case: both ‘const’ and ‘constexpr’ cannot be used here"
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-August/023565.html

[Bug target/49743] -g enables var_tracking on -O0 - causes long compilations

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49743

--- Comment #3 from Gary Funck  2012-08-28 02:20:38 
UTC ---
Recently, I've been reviewing changes that we made on the GUPC branch (see
comment #2) that are candidates for the trunk revision (or in this case,
possibly the 4.7 branch).

Index: gcc/config/darwin.c
===
--- gcc/config/darwin.c (.../trunk) (revision 190707)
+++ gcc/config/darwin.c (.../branches/gupc) (revision 190718)
@@ -3039,6 +3039,7 @@ darwin_override_options (void)
 }

   if (flag_var_tracking
+  && optimize >= 1
   && generating_for_darwin_version >= 9
   && (flag_gtoggle ? (debug_info_level == DINFO_LEVEL_NONE)
   : (debug_info_level >= DINFO_LEVEL_NORMAL))

Reading the problem description, unless the option scanning logic has changed
for Darwin, it looks as if this change might still be necessary to suppress var
tracking at -O0?

[Bug rtl-optimization/55158] New: ICE: [4.8 Regreesion] [IA64] segv in schedule_region

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158

 Bug #: 55158
   Summary: ICE: [4.8 Regreesion] [IA64] segv in schedule_region
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@intrepid.com


Created attachment 28587
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28587
Test case: gcc segv when compiled at -O3 on IA64

See attached test case.

$ bld/gcc/cc1 -O3 gcc-ice-schedule-region.c -o gcc-ice-schedule-region.o
 gasneti_check_node_list
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   <*free_inline_summary>

Assembling functions:
 gasneti_check_node_list
gcc-ice-schedule-region.c: In function ‘gasneti_check_node_list’:
gcc-ice-schedule-region.c:53:1: internal compiler error: Segmentation fault
 }
 ^
0x40b7b22f crash_signal
src/gcc/toplev.c:333
0x40ac2aaf schedule_region
src/gcc/sched-rgn.c:2998
0x40ac2aaf schedule_insns()
src/gcc/sched-rgn.c:3343

Here is the schedule_region source at that location.

2993  f = find_fallthru_edge (last_bb->succs);
2994  if (f && f->probability * 100 / REG_BR_PROB_BASE >=
2995  PARAM_VALUE (PARAM_SCHED_STATE_EDGE_PROB_CUTOFF))
2996{
2997  memcpy (bb_state[f->dest->index], curr_state,
2998  dfa_state_size);
2999  if (sched_verbose >= 5)
3000fprintf (sched_dump, "saving state for edge %d->%d\n",
3001 f->src->index, f->dest->index);
3002}

Here is the value of f->dest->index at the pointed and the value of the
selected element of bb_state.

(gdb) p f->dest->index
$1 = 23
(gdb) p bb_state[23]
$2 = (state_t) 0x431

Clearly not a valid address.

(gdb) p bb_state[22]
$3 = (state_t) 0x602f3d58

While the element before it looks OK.

This issue seemed to be introduced by this check in.

2012-10-08  Bernd Schmidt  

* sched-int.h (schedule_block): Adjust declaration.
* sched-rgn.c (bb_state_array, bb_state): New static variables.
(sched_rgn_init): Initialize them.
(sched_rgn_free): Free them.
(schedule_region): Save scheduling state for future blocks, and

which is svn revision 192203.

[Bug rtl-optimization/55158] ICE: [4.8 Regreesion] [IA64] segv in schedule_region

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158



--- Comment #1 from Gary Funck  2012-11-01 00:15:54 
UTC ---

Some additional debugging information.



In sched_rgn_init(), the bb_state array is initialized.



3049{

3050  bb_state_array = (char *) xmalloc (last_basic_block *

dfa_state_size);

3051  bb_state = XNEWVEC (state_t, last_basic_block);

3052  for (i = 0; i < last_basic_block; i++)

3053{

3054  bb_state[i] = (state_t) (bb_state_array + i *

dfa_state_size);

3055  

3056  state_reset (bb_state[i]);

3057}

3058}



For the given test case.



(gdb) p last_basic_block

$3 = 23



Yet, it is the access of bb_state[23] that leads to the segfault.



The last basic block is 23, and the array bb_state[] is initialized only for

entries 0..22.  Perhaps the number entries allocated should be

(last_basic_block +  1) with the initialization loop adjusted accordingly?

[Bug rtl-optimization/55158] ICE: [4.8 Regreesion] [IA64] segv in schedule_region

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158



--- Comment #2 from Gary Funck  2012-11-01 00:35:41 
UTC ---

I tried making the change suggested in the previous comment and ran into a

segfault here:



5876dump_new_block_header (0, *target_bb, head, tail);

5877

5878  if (init_state == NULL)

5879state_reset (curr_state);

5880  else

5881memcpy (curr_state, init_state, dfa_state_size);

5882

5883  /* Clear the ready list.  */

5884  ready.first = ready.veclen - 1;

5885  ready.n_ready = 0;



(gdb) p init_state

$10 = (state_t) 0x431



init_state is an invalid pointer.



Going up one level.



2985  curr_bb = first_bb;

2986  if (dbg_cnt (sched_block))

2987{

2988  edge f;

2989

2990  schedule_block (&curr_bb, bb_state[first_bb->index]);

2991  gcc_assert (EBB_FIRST_BB (bb) == first_bb);

2992  sched_rgn_n_insns += sched_n_insns;

2993  f = find_fallthru_edge (last_bb->succs);

2994  if (f && f->probability * 100 / REG_BR_PROB_BASE >=



(gdb) p first_bb->index

$13 = 25



If the last basic block is 23, then this index is out-of-range.

[Bug rtl-optimization/55158] [4.8 Regression] [IA64] ICE: segv in schedule_region

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158



--- Comment #8 from Gary Funck  2012-11-09 15:26:46 
UTC ---

(In reply to comment #5)

> Completely untested patch for someone else to foster-parent:



> +   }

> +   }

>   f = find_fallthru_edge (last_bb->succs);

>   if (f && f->probability * 100 / REG_BR_PROB_BASE >=

>   PARAM_VALUE (PARAM_SCHED_STATE_EDGE_PROB_CUTOFF))



I could not apply the patch cleanly.  Perhaps it was garbled by line wraps,

etc.  Can you post the patch as an attachment?

[Bug bootstrap/50010] i386-unknown-freebsd bootstrap comparison failure

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50010

--- Comment #4 from Gary Funck  2011-08-20 17:03:58 
UTC ---
We ran a reghunt of sorts and came up with the following results.

The first confirmed bootstrap comparison failure occurred after
revision 177265 was applied.

r177265 | uros | 2011-08-03 03:46:04 -0700 (Wed, 03 Aug 2011) | 9 lines

However, the builds before that revision terminated with a compilation
error in config/linux/affinity.c, which was fixed by this revision.
The compilation error was introduced by this commit:

r177194 | jakub | 2011-08-02 09:13:29 -0700 (Tue, 02 Aug 2011) | 238 lines
Merge from gomp-3_1-branch branch:

Thus, it seems that revision 177194 or a subsequent revision preceding
177265 introduced the bootstrap comparison failure on i386 (we ran our tests
on i686 running CentOS).

[Bug bootstrap/50010] [4.7 regression] i386-unknown-freebsd bootstrap comparison failure

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50010

--- Comment #6 from Gary Funck  2011-08-20 19:35:11 
UTC ---
(In reply to comment #2)
> (In reply to comment #0)
> > x86_64-unknown-freebsd seems to work, and with nobody seeing this on 
> > GNU/Linux
> > I am wondering whether this may be due to i386 (vs i586)?
> 
> Can you trigger this bug on linux (either x86_64 or i686) using following
> configure string:
> 
> CC="gcc -m32" CXX="g++ -m32" /configure i586-linux

On FC14 x86_64, after installing the i686 libraries for
{gmp,libmpc,mpfr}{,-devel}, built against trunk
revision 177922 (last changed 2011-08-19 17:18:07 PDT),
the build completed *without* error.

I'll try trunk revision r177218 (reported by Gerald) for completeness,
and post the results.

[Bug bootstrap/50010] [4.7 regression] i386-unknown-freebsd bootstrap comparison failure

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50010

--- Comment #7 from Gary Funck  2011-08-20 20:52:08 
UTC ---
(In reply to comment #6)
> On FC14 x86_64, after installing the i686 libraries for
> {gmp,libmpc,mpfr}{,-devel}, built against trunk
> revision 177922 (last changed 2011-08-19 17:18:07 PDT),
> the build completed *without* error.
> 
> I'll try trunk revision r177218 (reported by Gerald) for completeness,
> and post the results.

This also completed *without* error.

[Bug bootstrap/50010] [4.7 regression] bootstrap comparison failure without CFI directives

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50010

--- Comment #12 from Gary Funck  2011-09-11 16:29:39 
UTC ---
(In reply to comment #10)
> Putting binutils 2.21.1 in PATH before the system versions of these tools,
> which are binutils 2.17.50 based, avoids the issue on FreeBSD 9/i386.

On the i686 CentOS release 5.6 system that we ran our tests on,
the installed binutils package is: binutils-2.17.50.0.6-14.el5.
Thus, confirming Gerald's observation.

[Bug bootstrap/50010] [4.7 regression] bootstrap comparison failure without CFI directives

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50010

--- Comment #16 from Gary Funck  2011-09-12 18:39:20 
UTC ---
(In reply to comment #14)
> Created attachment 25246 [details]
> gcc47-pr50010.patch

Bootstraps on i686 CentOS release 5.6 with installed packages.

Jakub, thanks for tracking this down.

[Bug rtl-optimization/50489] New: [UPC/IA64] mis-schedule of MEM ref with -ftree-vectorize and -fschedule-insns2

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489

 Bug #: 50489
   Summary: [UPC/IA64] mis-schedule of MEM ref with
-ftree-vectorize and -fschedule-insns2
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@intrepid.com
Target: IA64


After a change in GUPC's tree-lowering pass made a couple of months back (that
simplified the tree code being generated), we saw regressions where several
small test cases were failing on an IA64 target (SGI Altix, running SUSE).

We have been unable so far to reduce this to a "C" only test case that
demonstrates the problem, so we are submitting this as a "UPC" bug report,
along with a script that will build the UPC compiler from the GUPC branch, and
create the various bug artifacts.  Perhaps someone knowledgeable with the
instruction scheduler will understand how this mis-scheduling happens and
either reproduce the issue as a "C" test case, or propose a patch.

We also do not know at this time if the UPC compiler should be generating
memory barriers or generate some other metadata to avoid this mis-scheduling,
and would appreciate any suggestions in that regard.

The attached UPC test case works fine when "-O2 -ftree-vectorize
-fno-schedule-insns2" is asserted, but demonstrates a mis-schedule when "-O2
-ftree-vectorize" is asserted.

The following description is copied from the
README-ia64-upc-sched-insn2-bug.txt file that is included in the attached zip
file as well.

Background
--

On a 64-bit target (using the "struct PTS" configuration),
the UPC compiler represents UPC pointer-to-shared values 
as 128-bit structures with three fields: (vaddr, thread, phase)
as shown in the declaration below.

typedef struct shared_ptr_struct
  {
void *vaddr;
uint32_t thread;
uint32_t phase;
  } upc_shared_ptr_t
  __attribute__ ((aligned (16)))
  ;

In: ia64-upc-vaddr-bug.upc.143t.optimized, there is the following
sequence of tree statements.

  unsigned int D.3062;
  unsigned int D.3061;
  shared [8] struct foo * D.3060;
  shared [8] struct foo[1] * D.3059;
  struct upc_shared_ptr_t D.3058;
  unsigned int D.3057;

  D.3057_10 = D.3056_9 * 8;
  D.3058.vaddr = &_u_barray;
  MEM[(struct upc_shared_ptr_t *)&D.3058 + 8B] = { 0, 0 };
  D.3059_11 = VIEW_CONVERT_EXPR(D.3058);
  D.3060_12 = (shared [8] struct foo *) D.3059_11;
  D.3061_13 = VIEW_CONVERT_EXPR(D.3060_12).phase;
  D.3062_14 = D.3057_10 + D.3061_13;

D.3059_11 and D.3060_12 are UPC pointers-to-shared (PTS's);
these are 128-bit "fat" pointers with internal
{vaddr, thread, phase} fields.

D.3058 is a PTS representation struct that is initialized
to {&_u_barray, 0, 0}.  Note that D.3059_11 and D.3060_12
are copies of the PTS representation structure, D.3058
that have been recast into a UPC pointer-to-shared (PTS).

The casts above might impose inefficiencies, and there may
be ways to improve the code, but this is the current
tree code that is generated.

This assignment statement:
  D.3061_13 = VIEW_CONVERT_EXPR(D.3060_12).phase;
extracts the 'phase' field from D.3060_12, which is a copy
of the value of D.3058.phase.  The value of D.3058.phase was
previously initialized to zero by the MEM[] assignment.
The fetched phase value D.3061_13 should be zero when this
assignment is executed.

Bug
---

It is this latter access to D.3060_12.phase that expands
into incorrect RTL after the selective instruction scheduling
pass is run.  The access to D.3060_12.phase is scheduled
ahead of the code that sets D.3058.phase.

Valid RTL
-

The 'ok' and 'bug' compilations share the same RTL dump output all
the way through ia64-upc-vaddr-bug.upc.213r.compgotos.
In that file there RTL statements that are affected by the
mis-scheduling of instructions.  (additional notes added
as '#' comments):

# D.3058.vaddr = &_u_barray (the base address of barray.
#
# r34 was previously assigned the value of &_u_barray
# r47 = r12 + 32;
# r12 is the stack pointer and r47 points to the beginning
# of the D.3058 structure, which also happens to be the
# address of the first field, D.3058.vaddr.
# Therefore, r47 points to D.3058.vaddr

(insn 46 42 331 4 (set (mem/s/f/c:DI (reg/f:DI 47 r47 [532]) [2 D.3058.vaddr+0
S8 A128])
(reg/f:DI 34 r34 [533])) ia64-upc-vaddr-bug.upc:11 5 {movdi_internal}
 (nil))

# This vector op assigns: {D.3058.thread = 0; D.3058.phase = 0;}
#
# This is done by using r46 as the destination address and r36 as the source.
# r46 = r12 + 40, which is the base address of D.3058.thread.
# (D.3058.phase is the field following the D.3058.thread)
# r36 was previously set to {0, 0}.

(insn 52 69 65 4 (set (mem/s/c:V2SI (reg/f:DI 46 r46 [534]) [3 MEM[(struct
upc_shared_ptr_t *)&D.3058 + 8B]+0 S8 A64])
(reg:V2SI 36 r36 [536])) ia6

[Bug rtl-optimization/50489] [UPC/IA64] mis-schedule of MEM ref with -ftree-vectorize and -fschedule-insns2

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489

--- Comment #1 from Gary Funck  2011-09-22 19:21:54 
UTC ---
Created attachment 25343
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25343
UPC test case that demonstrates instruction mis-schedule

[Bug rtl-optimization/50489] [UPC/IA64] mis-schedule of MEM ref with -ftree-vectorize and -fschedule-insns2

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489

--- Comment #2 from Gary Funck  2011-09-22 19:31:04 
UTC ---
Created attachment 25344
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25344
zipped tar file with build script, readme, test case and test artifacts

[Bug rtl-optimization/50489] [UPC/IA64] mis-schedule of MEM ref with -ftree-vectorize and -fschedule-insns2

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489

--- Comment #4 from Gary Funck  2011-09-23 17:38:18 
UTC ---
(In reply to comment #3)
> Does the problem vanish if you add -fno-strict-aliasing?
> 
> One more thing, you mention -O2 in the flags, but then refer to selective
> scheduler, which is only enabled at -O3.  Perhaps you meant Haifa scheduler.

The tests still fail with "-O3 -fno-strict-aliasing".  They pass with "-O3
-fno-schedule-insns2".  We mentioned -O2 in the bug report, because it helped
rule out other optimizations that -O3 might imply.  Then we selectively added
"-ftree-vectorize" and "-fschedule-insns2" to demonstrate that the combination
of those additional optimizations will demonstrate the mis-scheduling.

If there are additional tests that you suggest that we can run to help narrow
this down, let us know, and we'll try to provide that additional information. 
Also, we can provide a script to run gdb on "cc1upc", if that helps.  Thanks.

[Bug rtl-optimization/50489] [UPC/IA64] mis-schedule of MEM ref with -ftree-vectorize and -fschedule-insns2

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489

--- Comment #6 from Gary Funck  2011-09-25 19:58:58 
UTC ---
(In reply to comment #5)
>   D.3059_11 = VIEW_CONVERT_EXPR(D.3058);
> 
> looks like bogus IL to me.  You view D.3058, a struct of size 16, as
> a pointer (of size 8).  I suppose you want to load D.3058.vaddr here?
> 
>   D.3060_12 = (shared [8] struct foo *) D.3059_11;
>   D.3061_13 = VIEW_CONVERT_EXPR(D.3060_12).phase;
> 
> looks bogus IL to me.  It views the pointer(!?) D.3060_12 as being a
> struct upc_shared_ptr_t and extracts a value that is not within that
> pointer.
> 
> But maybe I'm missing something because I don't recognize that 'shared [8]'
> qualification.  [...]

The syntax (shared [8] struct foo *) above is unique to UPC.  This is a pointer
to a "shared' qualified object with a "blocking factor" (layout qualifier) of
8.  This type of pointer is called a "pointer-to-shared" (PTS) in the UPC
language definition; it is a pointer that can span nodes.  On a 64-bit machine,
using the "sturct PTS" (as opposed to "packed PTS") representation it is a 16
byte quantity.  Thus the casts back/forth between (shared *) and "struct
upc_shared_ptr_t" do not violate the size assumptions of VIEW_CONVERT_EXPR().

The "blocking factor" (the [8] in "shared [8] *" above) is unique to UPC.  In
UPC, arrays are "block distributed".  This means that block 0 is on thread 0,
block 1 is on thread 1 and so on.  Thus, for a UPC program that is run with 2
threads, foo[0], foo[1] ... foo[7] are allocated on (have "affinity to") thread
0 and foo[8], foo[9] ... foo[13] are allocated on thread 1.  This blocking
factor provides for the ability to cast a pointer to a block of shared storage
into a regular "C" pointer (a "local" pointer) as long as the thread performing
the cast has affinity to the block.

What is potentially troublesome for the "middle end" tree optimizations and
"back end" RTL optimizations is that these pointers-to-shared (PTS's) are "fat"
pointers.  Note that after the lowering pass (performed in
upc/upc-genericize.c) that there will be no *indirections* through a PTS. 
Instead, indirections of a PTS in a value context will be converted into "get"
calls, which are implemented by the UPC runtime (libupc/smp).  Indirections
that are the targets of assignments are translated into "put" calls,
implemented by the UPC runtime. 

The lowering pass also translates UPC pointer-to-shared arithmetic operations
into their equivalent operations which do not involve PTS's, but rather cast
the PTS's to their representation type (struct upc_shared_ptr_t) and then
operate on the component parts of the PTS.  As you can see from the description
of blocking factors above, the mapping of foo[i] to its (global) address
requires a fairly complex arrangement of division and modulo operations.

The libupc runtime is unique in that parts of it may be inlined.  Inlining of
the runtime is enabled at optimization levels greater than 0, or it can be
explicitly inlined/not-inlined via the -fupc-inline-lib switch.  The inlining
is accomplished via a pre-include of a runtime header file, implemented by the
"upc" driver.  Inlining is enabled in the test case documented in this bug
report.  Thus, a simple assignment statement involving array indexing of a UPC
shared "blocked" array expands into a rather complex assortment of tree code,
and generated RTL.  (This complexity makes it difficult to create an equivalent
"C" test case.)

After lowering, any references to "shared *" (pointers-to-shared) should only
occur in casts to/from the representation type and in moves/copies of the PTS
container.  We have run into a few places where the middle end makes some
assumptions about regular pointers and tries to apply those assumptions to a
UPC pointer-to-shared; we have been able to exclude PTS's by adding additional
checks for them -- there are not many places that we have had to do this. 
Perhaps that sort of pointer-specific logic is kicking in here.

Arguably, the UPC lowering pass should fully lower PTS typed expressions, so
that they don't end up in the tree.  Potentially, a PTS hanging around in the
tree doesn't meet the strict (or even not-so-strict) definition of GENERIC. 
Fully lowering those expressions is on our "to do" list.  When we do that,
rather than using casts, we will likely rewrite the PTS type references into
references to the PTS representation type.  We have shied away from this
because it makes the resulting tree code even more difficult to follow, because
it loses logical correspondence to the original "C" source statements.

That said, this technique of casting a PTS to its representation type and then
extracting its sub-parts has been working for quite a while on several
different target architectures.  However, maybe this recast of a
pointer-to-shared is confusing the post-reload instruction scheduler and/or the
logic that creates the MEM_REF?.

We would like to see if we can find a way to make the current lowerin

[Bug rtl-optimization/50489] [UPC/IA64] mis-schedule of MEM ref with -ftree-vectorize and -fschedule-insns2

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489

--- Comment #7 from Gary Funck  2011-10-17 03:04:08 
UTC ---
Do you have any suggestions on additional tests, debug steps that we can
perform to narrow down the factors that lead to instructions being
mis-scheduled?

[Bug tree-optimization/53185] New: segmentation fault in vectorizable_load

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53185

 Bug #: 53185
   Summary: segmentation fault in vectorizable_load
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@intrepid.com
CC: ne...@intrepid.com
Target: x86_64


Created attachment 27280
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27280
script to demonstrate compiler segfault

GCC 4.8 trunk revision r187034 encounters a segfault when compiling the
attached test case.  This appears to be a relatively recent regression.

Here's the back trace.

Program received signal SIGSEGV, Segmentation fault.
0x00d93153 in vectorizable_load (stmt=0x71889460,
gsi=0x7fffd680, vec_stmt=0x7fffd5a0, slp_node=0x0,
slp_node_instance=0x0)
at gcc/tree-vect-stmts.c:4563
4563  ivstep = fold_build2 (MULT_EXPR, TREE_TYPE (ivstep), ivstep,
(gdb) where
#0  0x00d93153 in vectorizable_load (stmt=0x71889460,
gsi=0x7fffd680, vec_stmt=0x7fffd5a0, slp_node=0x0,
slp_node_instance=0x0)
at gcc/tree-vect-stmts.c:4563
#1  0x00d978e4 in vect_transform_stmt (stmt=0x71889460,
gsi=0x7fffd680, grouped_store=0x7fffd677 "", slp_node=0x0,
slp_node_instance=0x0)
at gcc/tree-vect-stmts.c:5639
#2  0x00dac324 in vect_transform_loop (loop_vinfo=0x1cd0630)
at gcc/tree-vect-loop.c:5461
#3  0x00dbfd08 in vectorize_loops ()
at gcc/tree-vectorizer.c:214
#4  0x00cbf6b4 in tree_vectorize ()
at gcc/tree-ssa-loop.c:218
#5  0x00a22eb0 in execute_one_pass (pass=0x19fdc40)
at gcc/passes.c:2181
#6  0x00a23096 in execute_pass_list (pass=0x19fdc40)
at gcc/passes.c:2236
#7  0x00a230b7 in execute_pass_list (pass=0x19fda60)
at gcc/passes.c:2237

To reproduce, copy the attached do-fail script and gasnet_core.i file to the
gcc build directory, and run do-fail.

The compiler was configured with --disable-bootstrap --disable-multilib and
--enable-checking, however, the failure occurred after a full bootstrap and
with various other configure switches as well.

[Bug tree-optimization/53185] segmentation fault in vectorizable_load

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53185

--- Comment #1 from Gary Funck  2012-05-02 06:11:21 
UTC ---
Created attachment 27281
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27281
pre-processed source that demonstrates compiler segfault

[Bug tree-optimization/53185] [4.8 Regression] segmentation fault in vectorizable_load

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53185

--- Comment #5 from Gary Funck  2012-05-08 16:01:50 
UTC ---
Ping.  Is there an ETA for a fix for this bug?  It is preventing us from being
able to merge from the GCC trunk.  Thanks.

[Bug tree-optimization/53185] [4.8 Regression] segmentation fault in vectorizable_load

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53185

--- Comment #8 from Gary Funck  2012-05-09 21:43:28 
UTC ---
(In reply to comment #7)
> Fixed.

Confirmed.  We're able to rebuild our app. without encountering the
segmentation fault.

Thanks!

[Bug tree-optimization/53390] New: ICE: tree check: expected integer_cst, have nop_expr in vect_compute_data_ref_alignmen on 32-bit x86 host

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53390

 Bug #: 53390
   Summary: ICE: tree check: expected integer_cst, have nop_expr
in vect_compute_data_ref_alignmen on 32-bit x86 host
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@intrepid.com
CC: phhargr...@lbl.gov
  Host: CentOS 6 x86-32
Target: x86-32


Built on x86-32 with GCC 4.8 trunk version 187616 (2012-05-16), the attached
test case fails with following internal error (with checks enabled).

test.i: In function ‘foo’:
test.i:10:6: internal compiler error: tree check: expected integer_cst, have
nop_expr in tree_int_cst_sgn, at tree.c:6601

Back trace:

#0  internal_error (gmsgid=0x8f57f68 "tree check: %s, have %s in %s, at %s:%d")
at gcc/diagnostic.c:955
#1  0x089e6b71 in tree_check_failed (node=0xb7c8a378, 
file=0x8f57148 "gcc/tree.c", line=6601, 
function=0x8f5958c "tree_int_cst_sgn")
at gcc/tree.c:8886
#2  0x089d7c50 in tree_int_cst_sgn (t=0xb7c8a378)
at gcc/tree.c:6601
#3  0x089d7108 in tree_int_cst_lt (t1=0xb7c8a378, t2=0xb7bec594)
at gcc/tree.c:6503
#4  0x089d7634 in tree_int_cst_compare (t1=0xb7c8a378, t2=0xb7bec594)
at gcc/tree.c:6525
#5  0x08e2abda in vect_compute_data_ref_alignment (dr=0x92a3768)
at gcc/tree-vect-data-refs.c:923
#6  0x08e2ae38 in vect_compute_data_refs_alignment (loop_vinfo=0x92a37e0, 
bb_vinfo=0x0) at gcc/tree-vect-data-refs.c:976
#7  0x08e2d99f in vect_analyze_data_refs_alignment (loop_vinfo=0x92a37e0, 
bb_vinfo=0x0)
at gcc/tree-vect-data-refs.c:2074

(gdb) f 5
#5  0x08e2abda in vect_compute_data_ref_alignment (dr=0x92a3768)
at gcc/tree-vect-data-refs.c:923
923   if (tree_int_cst_compare (DR_STEP (dr), size_zero_node) < 0)
(gdb) l
918   && DECL_ALIGN (base) >= TYPE_ALIGN (vectype)));
919
920   /* If this is a backward running DR then first access in the larger
921  vectype actually is N-1 elements before the address in the DR.
922  Adjust misalign accordingly.  */
923   if (tree_int_cst_compare (DR_STEP (dr), size_zero_node) < 0)
924 {
925   tree offset = ssize_int (TYPE_VECTOR_SUBPARTS (vectype) - 1);
926   /* DR_STEP(dr) is the same as -TYPE_SIZE of the scalar type,
927  otherwise we wouldn't be here.  */
(gdb) down
#4  0x089d7634 in tree_int_cst_compare (t1=0xb7c8a378, t2=0xb7bec594)
at gcc/tree.c:6525
6525  if (tree_int_cst_lt (t1, t2))
(gdb) p t1
$1 = (const_tree) 0xb7c8a378
(gdb) pt
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0xb7bff0c0 precision 32
min  max >

arg 0  unit size 
align 32 symtab 0 alias set -1 canonical type 0xb7bff3c0 precision
32 min  max 
pointer_to_this >

arg 0 

arg 0 
visited var def_stmt
pretmp.12_42 = var2;

version 42>>
arg 1 >>

I was unable to cause this to fail on an x86_64 *host* compiling with -m32, but
perhaps needed to try some other configuration options.  The failing compiler
above was built on an x86-32 (CentOS 6) host with --disable-bootstrap and
--enable-checking.

[Bug tree-optimization/53390] ICE: tree check: expected integer_cst, have nop_expr in vect_compute_data_ref_alignmen on 32-bit x86 host

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53390

--- Comment #1 from Gary Funck  2012-05-17 17:12:49 
UTC ---
Created attachment 27428
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27428
Test case to demonstrate ICE in tree check on 32-bit host

Test case attached.  Compile with "-fpreprocessed -O3".

[Bug tree-optimization/53390] ICE: tree check: expected integer_cst, have nop_expr in vect_compute_data_ref_alignmen on 32-bit x86 host

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53390

--- Comment #2 from Gary Funck  2012-05-17 17:25:23 
UTC ---
The following versions of the support packages were installed via RPM.

mpfr-devel-2.4.1-6.el6.i686
gmp-devel-4.3.1-7.el6.i686
libmpc-devel-0.8-3.el6.i686
binutils-2.20.51.0.2-5.28.el6.i686

[Bug tree-optimization/53419] New: loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419

 Bug #: 53419
   Summary: loop incorrectly optimized to endless loop at -O2 for
table delimited by extern addresses (x86-32)
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@intrepid.com
  Host: x86-32
Target: x86-32


The attached test case, duplicated below yields an infinite loop when compiled
by GCC 4.8 trunk version 187666.  This appears to be a relatively recent
regression
(likely between 185454 and 186243).

typedef unsigned int size_t;

typedef void (*func_ptr_t) (void);
extern func_ptr_t init_array_begin[1];
extern func_ptr_t init_array_end[1];

void
per_thread_init (void)
{
  size_t n_init = (init_array_end - init_array_begin);
  int i;
  for (i = 0; i < n_init; ++i)
{
  func_ptr_t init_func = init_array_begin[i];
  if (init_func)
(*init_func) ();
}
}

At -O1, the loop looks like this:

.L4:
movlinit_array_begin(,%ebx,4), %eax
testl   %eax, %eax
je  .L3
call*%eax
.L3:
addl$1, %ebx
cmpl%esi, %ebx
jne .L4

At -O2 it looks like this.

.L5:
movlinit_array_begin, %eax
testl   %eax, %eax
je  .L3
call*%eax
.L3:
cmpl$1, %ebx
jne .L5

The comparison "cmpl$1, %ebx" is problematic, as well as the lack of
indexing the array.

[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419

--- Comment #1 from Gary Funck  2012-05-19 19:41:25 
UTC ---
Created attachment 27442
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27442
test case demonstrating endless loop at -O2 on x86-32

[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419

--- Comment #2 from Gary Funck  2012-05-19 19:42:47 
UTC ---
Created attachment 27443
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27443
correct code generated at -O1

[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419

--- Comment #3 from Gary Funck  2012-05-19 19:43:25 
UTC ---
Created attachment 27444
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27444
endless loop generated at -O2

[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419

--- Comment #6 from Gary Funck  2012-05-19 22:08:26 
UTC ---
(In reply to comment #5)
> > extern func_ptr_t init_array_begin[1];
> > extern func_ptr_t init_array_end[1];
> 
> The array sizes say they are size of one.  If you want to be correct and not
> allow GCC to optimize away the check because array overflow, use [] instead of
> [1].

Good point.  Do you happen to know if
  extern func_ptr_t init_array_begin[];
  extern func_ptr_t init_array_end[];
is say, C89 compatible?  I ask, because I thought I ran into problems with some
older compilers given the above syntax.

typedef unsigned int size_t;

typedef void (*func_ptr_t) (void);
extern func_ptr_t init_array_begin[1];
extern func_ptr_t init_array_end[1];

void
per_thread_init (void)
{
  size_t n_init = (init_array_end - init_array_begin);
  int i;
  for (i = 0; i < n_init; ++i)
{
  func_ptr_t init_func = init_array_begin[i];
  if (init_func)
(*init_func) ();
}
}

Questions regarding the optimization of the above.

If the compiler concludes that n_init must be 1, then code that creates an
endless loop is not a valid optimization?

Simplifying so that the loop executes only once might be, but I'm still having
a little trouble adjusting to that idea.

Is there an -f option that disables this sort of optimization?



1

[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419

--- Comment #7 from Gary Funck  2012-05-19 22:11:42 
UTC ---
(In reply to comment #4)
> Do you have a self-contained run-time testcase?

I wasn't able to create a run-time tester easily, because the code above relies
upon external labels that are interposed at the beginning and end of a table,
via separate compilation and linking.  I can do that, but perhaps given
Andrew's reply, that may be unnecessary.

[Bug bootstrap/53832] [4.8 Regression] error: macro "ggc_alloc_cleared_lang_decl" passed 1 arguments, but takes just 0

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53832

Gary Funck  changed:

   What|Removed |Added

 CC||gary at intrepid dot com,
   ||nenad at intrepid dot com

--- Comment #5 from Gary Funck  2012-07-15 17:13:51 
UTC ---
(In reply to comment #4)
> This seems to have been caused by using a sparse checkout from svn (using
> --set-depth empty) to avoid having thousands of files from libjava and other
> dirs I don't use.
> 
> After restoring most of the absent files I get a proper gtype-desc.h
> 
> The bit that matters seems to be gcc/ada, without that dir being present I get
> a bad gtype-desc.h even though I'm using --enable-languages=c,c++

For GUPC, we build snapshots (and releases) that only have "C"+"C++"+"UPC". 
Recently, we have run into the failure documented in this bug report for
full bootstrap builds (which invoke the C++ compiler) and our truncated
source tree.  We merge almost weekly with the trunk, fyi.

I recall some time back some exchanges on the GCC list regarding the
difficulties
of releasing sub-parts of the GCC source tree, but don't recall the technical
details or the stated policy.

Our users run builds on some rather constrained machines, and for them the
extra 400MB of source may make a difference.

We can confirm that there is something in the 'ada' tree that fixes this build
failure.

Has a decision been made that sub-setting the GCC tree is unsupported?

Or ... perhaps this bug was marked as "RESOLVED INVALID" for a different
reason?

In any event, we would like to be able to continue to release sub-sets of the
GCC source tree if possible, and still run full bootstrap, etc. (note that
with --disable-bootstrap we don't see this failure).

Please advise.

[Bug rtl-optimization/52983] [4.8 Regression] internal compiler error: in df_uses_record, at df-scan.c:3243

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52983

Gary Funck  changed:

   What|Removed |Added

 CC||gary at intrepid dot com

--- Comment #11 from Gary Funck  2012-07-30 23:15:13 
UTC ---
We are also seeing this build failure on:
SUSE Linux Enterprise Server 11.1 (ia64)
against trunk revision 189777.

[Bug target/54142] New: ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142

 Bug #: 54142
   Summary: ppc64 build failure - Unrecognized opcode: `sldi' (and
`srdi`)
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@intrepid.com
Target: powerpc64


On several PPC64 systems, we are seeing the following build failure.

/home/garyf/gcc-4.8/wrk/./gcc/xgcc -B/home/garyf/gcc-4.8/wrk/./gcc/
[...]
 -I/home/garyf/gcc-4.8/src/libgcc/../libdecnumber -DHAVE_CC_TLS  -o
_gcov_execle.o -MT _g
cov_execle.o -MD -MP -MF _gcov_execle.dep -DL_gcov_execle -c /home/garyf/gcc-4.
8/src/libgcc/libgcov.c
/tmp/ccqVYRai.s: Assembler messages:
/tmp/ccqVYRai.s:63: Error: Unrecognized opcode: `sldi'
/tmp/ccqVYRai.s:66: Error: Unrecognized opcode: `srdi'
/tmp/ccqVYRai.s:67: Error: Unrecognized opcode: `sldi'
/tmp/ccqVYRai.s:73: Error: Unrecognized opcode: `srdi'
/tmp/ccqVYRai.s:74: Error: Unrecognized opcode: `sldi'
/tmp/ccqVYRai.s:88: Error: Unrecognized opcode: `sldi'

The failures above use the gcc-4.8-20120729 snapshot which is based on svn
revision 189947.

The configure target is: powerpc64-unknown-linux-gnu

This was built on a rather old (FC6) system running on a Mac G5, but we have
seen it also fail on newer PPC64 systems.

[Bug target/54142] ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142

--- Comment #1 from Gary Funck  2012-07-31 16:12:18 
UTC ---

We have determined that we can bypass the failure with the following configure
switches:

--with-long-double-128 --with-cpu-32=power4 --with-tune-32=power6
--with-cpu-64=power4 --with-tune-64=power6

This binutils email thread may be relevant:
http://sources.redhat.com/ml/binutils/2010-07/msg00260.html

The assembler that we're using is based on binutils 2.20.51.0.2 which is circa
the July, 2010 time frame.

[Bug target/54142] ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142

--- Comment #3 from Gary Funck  2012-07-31 16:53:52 
UTC ---
(In reply to comment #2)
> sldi and srdi are both standard PowerPC64 instructions.
> 
> How did you configure GCC?

No special switches.  For example,

$src/configure \
  CFLAGS='-O0 -g3' --prefix=$rls \
  --enable-languages='c,c++' \
  --enable-checking=yes \
  --disable-bootstrap \
  --disable-multilib

is sufficient to reproduce the failure.

[Bug target/54142] ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142

--- Comment #4 from Gary Funck  2012-07-31 16:57:55 
UTC ---
One of target platforms is running RHEL 6.2 on a POWER7 series processor.
The binutils RPM is:
binutils-2.20.51.0.2-5.28.el6.ppc64

[Bug target/54142] ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54142

--- Comment #5 from Gary Funck  2012-07-31 17:14:24 
UTC ---
Here is the complete output at the point of a make failure.

/home/garyf/gcc-4.8/wrk/./gcc/xgcc -B/home/garyf/gcc-4.8/wrk/./gcc/ -B/home/gar
yf/gcc-4.8/rls/powerpc64-unknown-linux-gnu/bin/ -B/home/garyf/gcc-4.8/rls/power
pc64-unknown-linux-gnu/lib/ -isystem /home/garyf/gcc-4.8/rls/powerpc64-unknown-
linux-gnu/include -isystem /home/garyf/gcc-4.8/rls/powerpc64-unknown-linux-gnu/
sys-include-O2 -O0 -g3 -O2  -O2 -O0 -g3 -DIN_GCC   -W -Wall -Wwrite-strings
 -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -
isystem ./include   -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -f
building-libgcc -fno-stack-protector   -fPIC -mlong-double-128 -mno-minimal-toc
 -I. -I. -I../.././gcc -I/home/garyf/gcc-4.8/src/libgcc -I/home/garyf/gcc-4.8/s
rc/libgcc/. -I/home/garyf/gcc-4.8/src/libgcc/../gcc -I/home/garyf/gcc-4.8/src/l
ibgcc/../include -I/home/garyf/gcc-4.8/src/libgcc/../libdecnumber/dpd -I/home/g
aryf/gcc-4.8/src/libgcc/../libdecnumber -DHAVE_CC_TLS  -o _mulvdi3.o -MT _mulvd
i3.o -MD -MP -MF _mulvdi3.dep -DL_mulvdi3 -c /home/garyf/gcc-4.8/src/libgcc/lib
gcc2.c -fvisibility=hidden -DHIDE_EXPORTS
/tmp/cci4OPcY.s: Assembler messages:
/tmp/cci4OPcY.s:384: Error: Unrecognized opcode: `srdi'
/tmp/cci4OPcY.s:430: Error: Unrecognized opcode: `srdi'
/tmp/cci4OPcY.s:481: Error: Unrecognized opcode: `srdi'
/tmp/cci4OPcY.s:535: Error: Unrecognized opcode: `srdi'

[Bug tree-optimization/44776] FAIL: gcc.dg/matrix/transpose-3.c execution, -fprofile-use -fipa-matrix-reorg -fdump-ipa-matrix-reorg -O3 -fwhole-program

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776

--- Comment #15 from Gary Funck  2012-02-08 07:14:29 
UTC ---
We're seeing a similar failure under openSUSE 12.1 running as a VM, which may
have a somewhat constrained memory environment.

*** glibc detected ***
/home/abuild/rpmbuild/BUILD/[...]/gcc/testsuite/gcc/transpose-3.x02:
free(): invalid pointer: 0x006030b0 ***
=== Backtrace: =
/lib64/libc.so.6(+0x74c06)[0x7fdcf08c6c06]
/home/abuild/rpmbuild/BUILD/[...]/gcc/testsuite/gcc/transpose-3.x02[0x400e62]
/lib64/libc.so.6(__libc_start_main+0xed)[0x7fdcf087323d]
/home/abuild/rpmbuild/BUILD/[...]/gcc/testsuite/gcc/transpose-3.x02[0x400ed9]

[Bug tree-optimization/44776] FAIL: gcc.dg/matrix/transpose-3.c execution, -fprofile-use -fipa-matrix-reorg -fdump-ipa-matrix-reorg -O3 -fwhole-program

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776

--- Comment #16 from Gary Funck  2012-02-08 07:23:31 
UTC ---
(In reply to comment #15)
> We're seeing a similar failure under openSUSE 12.1 running as a VM, which may
> have a somewhat constrained memory environment.

We built with trunk version 183751 circa 2012-01-31.

[Bug bootstrap/58572] [4.9 regression] make install uses -Wno-narrowing with system compiler which does not know about it

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58572

--- Comment #1 from Gary Funck  ---
We're seeing a similar failure on SUSE SLE 11.2. The installed version of gcc
is 4.3.4.

[Bug bootstrap/51072] Build with --disable-bootstrap fails in libitm

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51072

--- Comment #7 from Gary Funck  2011-11-21 02:53:42 
UTC ---
(In reply to comment #6)
> On Thu, 10 Nov 2011, rguenth at gcc dot gnu.org wrote:
> 
> > Shouldn't libitm be built with the "stage1" g++ as it is a target library,
> > even with --disable-bootstrap?
> 
> Yes, as I said in 
>  building it with 
> a pre-installed compiler is wrong.

Isn't it also an error to build libitm unless: (1) --enable-languages=c++ is
asserted, or (2) --enable-libitm is asserted?  For (2) arguably it should imply
that c++ will be built, or disallowed.

We're seeing two failure modes noted in comment #1 and comment #2 for systems
with not-so-modern versions of g++ installed.

[Bug preprocessor/33919] __BASE_FILE__ does not expand correctly when included from the command line

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33919

--- Comment #5 from Gary Funck  2011-12-22 04:03:55 
UTC ---
(In reply to comment #4)
> I'm having this problem too, and it's still happening with GCC 4.5. The ml
> message suggests that this may be hard to fix, but it looks surprisingly easy:
> instead of tracing back via INCLUDED_FROM, simply look at pfile->main_file
> which already contains the right file name. It just needs an accessor function
> because _cpp_file's definition is kept internal.

Per Harald's suggestion, I submitted a patch for review.
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01594.html

[Bug target/49743] -g enables var_tracking on -O0 - causes long compilations

[gary at intrepid dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49743

--- Comment #5 from Gary Funck  ---
(In reply to Eric Gallager from comment #4)
> Any plans to resubmit the GUPC branch again?

Eric, no not at this time.  Thanks.

[Bug c/24539] New: inconsistent handling of null-valued language hooks in GCC

[gary at intrepid dot com]

Also posted to the GCC mailing list:
http://gcc.gnu.org/ml/gcc/2005-10/msg00932.html
http://gcc.gnu.org/ml/gcc/2005-10/msg00938.html

While working with GCC's language hooks, we found that
certain places in GCC test for a null value of
lang_hooks.callgraph.expand_function, but
cgraph_expand_function() calls the hook directly:


In cgraphunit.c:

/* Expand function specified by NODE.  */

static void
cgraph_expand_function (struct cgraph_node *node)
{
  tree decl = node->decl;

  /* We ought to not compile any inline clones.  */
  gcc_assert (!node->global.inlined_to);

  if (flag_unit_at_a_time)
announce_function (decl);

  cgraph_lower_function (node);

  /* Generate RTL for the body of DECL.  */
  lang_hooks.callgraph.expand_function (decl);


In toplev.c:


  /* Disable unit-at-a-time mode for frontends not supporting callgraph
 interface.  */
  if (flag_unit_at_a_time && ! lang_hooks.callgraph.expand_function)
flag_unit_at_a_time = 0;


In function.c:


  /* Possibly warn about unused parameters.
 When frontend does unit-at-a-time, the warning is already
 issued at finalization time.  */
  if (warn_unused_parameter
  && !lang_hooks.callgraph.expand_function)
do_warn_unused_parameter (current_function_decl);


We tried setting lang_hooks.callgraph.expand_function to NULL:

/* For now, disable unit-at-a-time by setting expand_function to NULL */
#undef LANG_HOOKS_CALLGRAPH_EXPAND_FUNCTION
#define LANG_HOOKS_CALLGRAPH_EXPAND_FUNCTION NULL

which has the desired effect of disabling unit-at-a-time, but
runs aground in cgraph_expand_function() with a segfault,
when it attempts to call lang_hooks.callgraph.expand_function().

It seems that GCC is handling lang_hooks.callgraph.expand_function
in an inconsistent fashion.  Is a null value for expand_function
meaningful?  If it is, then what is the fix for cgraph_expand_function()?



In a follow-up note on the GCC list, Dueway Qi notes:

I have found another similar case.
lang_hooks.callgraph.analyze_expr  in  gcc/gcc/cgraphunit.c
490   if (lang_hooks.callgraph.analyze_expr)
491 return lang_hooks.callgraph.analyze_expr (tp,
walk_subtrees,
492   data);
but in another part of this file
517   if ((unsigned int) TREE_CODE (t) >= LAST_AND_UNUSED_TREE_CODE)
518 return lang_hooks.callgraph.analyze_expr (tp,
walk_subtrees, data);


-- 
   Summary: inconsistent handling of null-valued language hooks in
GCC
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: gary at intrepid dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24539

[Bug c/24540] New: inconsistent handling of null-valued language hooks in GCC

[gary at intrepid dot com]

Also posted to the GCC mailing list:
http://gcc.gnu.org/ml/gcc/2005-10/msg00932.html
http://gcc.gnu.org/ml/gcc/2005-10/msg00938.html

While working with GCC's language hooks, we found that
certain places in GCC test for a null value of
lang_hooks.callgraph.expand_function, but
cgraph_expand_function() calls the hook directly:


In cgraphunit.c:

/* Expand function specified by NODE.  */

static void
cgraph_expand_function (struct cgraph_node *node)
{
  tree decl = node->decl;

  /* We ought to not compile any inline clones.  */
  gcc_assert (!node->global.inlined_to);

  if (flag_unit_at_a_time)
announce_function (decl);

  cgraph_lower_function (node);

  /* Generate RTL for the body of DECL.  */
  lang_hooks.callgraph.expand_function (decl);


In toplev.c:


  /* Disable unit-at-a-time mode for frontends not supporting callgraph
 interface.  */
  if (flag_unit_at_a_time && ! lang_hooks.callgraph.expand_function)
flag_unit_at_a_time = 0;


In function.c:


  /* Possibly warn about unused parameters.
 When frontend does unit-at-a-time, the warning is already
 issued at finalization time.  */
  if (warn_unused_parameter
  && !lang_hooks.callgraph.expand_function)
do_warn_unused_parameter (current_function_decl);


We tried setting lang_hooks.callgraph.expand_function to NULL:

/* For now, disable unit-at-a-time by setting expand_function to NULL */
#undef LANG_HOOKS_CALLGRAPH_EXPAND_FUNCTION
#define LANG_HOOKS_CALLGRAPH_EXPAND_FUNCTION NULL

which has the desired effect of disabling unit-at-a-time, but
runs aground in cgraph_expand_function() with a segfault,
when it attempts to call lang_hooks.callgraph.expand_function().

It seems that GCC is handling lang_hooks.callgraph.expand_function
in an inconsistent fashion.  Is a null value for expand_function
meaningful?  If it is, then what is the fix for cgraph_expand_function()?



In a follow-up note on the GCC list, Dueway Qi notes:

I have found another similar case.
lang_hooks.callgraph.analyze_expr  in  gcc/gcc/cgraphunit.c
490   if (lang_hooks.callgraph.analyze_expr)
491 return lang_hooks.callgraph.analyze_expr (tp,
walk_subtrees,
492   data);
but in another part of this file
517   if ((unsigned int) TREE_CODE (t) >= LAST_AND_UNUSED_TREE_CODE)
518 return lang_hooks.callgraph.analyze_expr (tp,
walk_subtrees, data);


-- 
   Summary: inconsistent handling of null-valued language hooks in
GCC
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: gary at intrepid dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24540

[Bug c/24540] inconsistent handling of null-valued language hooks in GCC

[gary at intrepid dot com]

--- Comment #1 from gary at intrepid dot com  2005-10-26 14:39 ---


*** This bug has been marked as a duplicate of 24539 ***


-- 

gary at intrepid dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24540

[Bug c/24539] inconsistent handling of null-valued language hooks in GCC

[gary at intrepid dot com]

--- Comment #1 from gary at intrepid dot com  2005-10-26 14:39 ---
*** Bug 24540 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24539

[Bug middle-end/24539] inconsistent handling of null-valued language hooks in GCC

[gary at intrepid dot com]

--- Comment #3 from gary at intrepid dot com  2005-10-26 16:07 ---
All/most GCC-supplied dialects may support unit-at-a-time, however,
the dialect we're working on (UPC) does not at present support
unit-at-a-time.

For now, we're de-asserting flag_unit_at_a_time in the language
specific post_options routine.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24539

[Bug rtl-optimization/55158] [4.8 Regression] [IA64] ICE: segv in schedule_region

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158



--- Comment #10 from Gary Funck  2012-12-01 23:17:00 
UTC ---

(In reply to comment #9)

> OK, I applied it to our autotester and we will see tomorrow if it fixes the

> segfaults.

> If so, can I go ahead and commit it?

> 

> Honza



Ping: was this patch tested and then applied?



thanks.

[Bug bootstrap/55566] New: [4.8 regression] [IA64] ICE during bootstrap (related to recent "vec" re-implementation?)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566



 Bug #: 55566

   Summary: [4.8 regression] [IA64] ICE during bootstrap (related

to recent "vec" re-implementation?)

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: bootstrap

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: g...@intrepid.com





Created attachment 28854

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28854

build failure: IA64 segv - first seen in r193595



GCC fails to build, due to a segmentation violation while compiling libgcc2

during the bootstrap phase on an IA64 (altix) running SuSE SLES 11.1.  The

installed gcc compiler is "gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision

152973]", which is the compiler used to initially build gcc.



Bisection indicates that this started to fail with this svn revision.





r193595 | dnovillo | 2012-11-17 18:54:30 -0800 (Sat, 17 Nov 2012) | 537 lines



This patch rewrites the old VEC macro-based interface into a new one

based on the template class 'vec'.  The user-visible changes are

described in http://gcc.gnu.org/wiki/cxx-conversion/cxx-vec.

[...]



It has continued to fail subsequent to that commit at least through 2012-11-30.



Since about 2012-11-27, the segmentation violations that trace back originating

through vec.h persist, but now the failure occurs when compiling a configure

test when beginning to build libgcc.   This continues to fail for a recent

version of gcc trunk (r194044 2012-12-01).



An excerpt configure test failure traceback is as follows.



conftest.c: In function 'foo':

conftest.c:19:1: internal compiler error: Segmentation fault

 }

 ^

0x40b3b33f crash_signal

src/gcc/toplev.c:334

0x40466f30 vec::space(unsigned int) cons

t

src/gcc/vec.h:842

0x40466f30 vec::quick_push(df_ref_d* con

st&)

src/gcc/vec.h:947

0x40466f30 vec::quick_push(df_ref_d* const

&)

src/gcc/vec.h:1552

0x40466f30 vec::safe_push(df_ref_d* const&

)

src/gcc/vec.h:1565

0x40466f30 df_ref_create_structure

0x40466f30 df_ref_create_structure

src/gcc/df-scan.c:2804

0x40467b3f df_ref_record

src/gcc/df-scan.c:2873

0x4046923f df_get_call_refs

src/gcc/df-scan.c:3403

[...]



More complete logs with trace back are attached.

[Bug bootstrap/55566] [4.8 regression] [IA64] ICE during bootstrap (related to recent "vec" re-implementation?)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566



--- Comment #1 from Gary Funck  2012-12-02 20:32:03 
UTC ---

Created attachment 28855

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28855

build failure Ia64 segv - continues to fail in r194044 (in libgcc config. test)

[Bug bootstrap/55566] [4.8 regression] [IA64] ICE during bootstrap (related to recent "vec" re-implementation?)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566



--- Comment #2 from Gary Funck  2012-12-02 20:43:45 
UTC ---

The configure options specified are:



CC=/usr/bin/gcc

CXX=/usr/bin/g++

$src/configure --enable-languages=c,c++ 

--enable-checking --disable-bootstrap --disable-multilib

--disable-libmudflap --disable-libssa --disable-lto

--prefix=/eng/upc/dev/gary/gcc-trunk



Configure reports:



CFLAGS='-g -O2'

CFLAGS_FOR_BUILD='-g -O2'

CFLAGS_FOR_TARGET='-g -O2'

CXXFLAGS='-g -O2'

CXXFLAGS_FOR_BUILD='-g -O2'

CXXFLAGS_FOR_TARGET='-g -O2'

[Bug bootstrap/55566] [4.8 regression] [IA64] ICE during bootstrap (related to recent "vec" re-implementation?)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566



--- Comment #3 from Gary Funck  2012-12-02 21:32:14 
UTC ---

This failure may be related to the use of the installed gcc compiler (gcc (SUSE

Linux) 4.3.4 [gcc-4_3-branch revision 152973]).  I tried a gcc 4.7.0 compiler

that we built circa Feb, 2012 and it didn't segfault, but rather fails with an

apparently unrelated error while compiling 'gmp' ("redc_2.c:87:7: error: 'asm'

operand requires impossible reload").



I will try building svn revision 152973 on an x86-64 box, and see if the

problem can be reproduced there.

[Bug bootstrap/55566] [4.8 regression] segfault during build (related to recent "vec" re-implementation?)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566



--- Comment #5 from Gary Funck  2012-12-02 21:45:52 
UTC ---

Cancel the previous comment regarding the idea that this might be related to

using the system installed gcc.  The build failed while trying to build gmp,

and hadn't gotten to trying compile libgcc yet.

[Bug bootstrap/55566] [4.8 regression] segfault during build (related to recent "vec" re-implementation?)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566



--- Comment #6 from Gary Funck  2012-12-02 21:48:28 
UTC ---

"This isn't a bootstrap since you pass --disable-bootstrap to configure ..."



Agreed.  I didnt' know how to classify this problem.



Since the version of 4.7.0 that I used appears incompatible with the version of

gmp that we build as a pre-requisite, I will try a 4.6 compiler and see if I

get a different result.