Stack allocation

[Alexandru Juncu]

Hello!

I have a curiosity with something I once tested. I took a simple C
program and made an assembly file with gcc -S.

The C file looks something like this:
int main(void)
{
   int a=1, b=2;
   return 0;
}

The assembly instructions look like this:

subl$16, %esp
movl$1, -4(%ebp)
movl$2, -8(%ebp)

The subl $16, means the allocation of local variables on the stack,
right? 16 bytes are enough for 4 32bit integers.
If I have 1,2,3 or 4 local variables declared, you get those 16 bytes.
If I have 5 variables, we have "subl$32, %esp". 5,6,7,8 variables ar
the same. 9, 10,11,12, 48 bytes.

The observation is that gcc allocates increments of 4 variables (if
they are integers). If I allocate 8bit chars, increments of 16 chars.

So the allocation is in increments of 16 bytes no matter what.

OK, that's the observation... my question is why? What's the reason
for this, is it an optimization (does is matter what's the -O used?)
or is it architecture dependent (I ran it on x86) and is this just in
gcc, just in a certain version of gcc or this is universal?

Thank you!

-- 
Alexandru Juncu
ROSEdu

Re: a question about IVOPTS: find_interesting_uses_address

[Richard Guenther]

On Fri, Nov 18, 2011 at 2:07 AM, Yuehai Du  wrote:
> 2011/11/18 Richard Guenther :
>> On Thu, Nov 17, 2011 at 6:49 AM, Yuehai Du  wrote:
>>> 2011/11/17 Richard Guenther :
 On Wed, Nov 16, 2011 at 12:28 PM, Eric Botcazou  
 wrote:
>> Huh, IVOPTs should never cause a different size memory read.  I wonder
>> if the original issue would still reproduce with the fix reverted.
>
> The original issue was unaligned arrays in packed structures.  I don't 
> see what
> could have changed since then.

 Ah, so it was expand being confused about the constructed access (not 
 seeing
 a component-ref), thus the usual old issue we have there.  There's indeed 
 no
 trivial fix for this but to create the [TARGET_]MEM_REF with an explicitely
 unaligned type and hope that the target implements the movmisalign optab
 (the only case this explicit alignment is honored).  And double-check the
 TARGET_MEM_REF expansion code properly duplicates the movmisalign
 path from the MEM_REF expander.

 I'd wish somebody fixed this path for non-movmisalign strict-align targets.

>>>
>>>  I'm a little bit confused, and i don't know if i understand you correctly.
>>> are you saying that we can remove those check in 
>>> find_interesting_uses_address,
>>> and handle this misalign memory reference as aligned memory reference,
>>> just attach the
>>> misalign information in type and let expander to choose correct
>>> expansion dependent on
>>> movmisalign optab icode ?
>>
>> Yes.  But only if movmisalign is available.
>>
>>>  In that case if Target don't support misalign memory access, the
>>> result of IVOPTS will
>>> be non-optimal since the cost of IV used in misalign memory access is
>>> wrong,  right?
>>
>> No, the cost of the IV is the same, independent on whether it is aligned or 
>> not.
>>
>> Richard.
>
>  I got you,thanks.
>  Would it be ok if i file a bug about this,like missed optimization
> for misaligned
> memory access in IVOPTS?
>
>  and since the path for non-movmisalign strict-align targets don't
> exist now, could i
> add a condition in that check to avoid this. like:
>
>       if (STRICT_ALIGNMENT && may_be_unaligned_p (base, step)
>           && optab_handler (movmisalign_optab, mode) == CODE_FOR_nothing)
>        goto fail;
>
>  I don't know if it is appropriate to check optab in IVOPTS, sorry if
> i go too far.

Yes, that's currently the only way.  I'd rather eliminate this gap in expand
though and simply go the bitfield expansion way there.

Richard.

> --
> Yuehai
>
>>
>>> --
>>> Yuehai
>>>
>>>
 Richard.

> --
> Eric Botcazou
>

>>>
>>
>

installing cross compiler

[esmaeil mirzaee]

Hi
apologize for interrupt and weak English.

I need to install gcc cross compiler into Ubuntu 11.10 operating
system on Intel core2due.

-- 
Best
Esmaeil
https://sites.google.com/site/esmaeilmirzaee

Re: installing cross compiler

[Jonathan Wakely]

On 18 November 2011 09:57, esmaeil mirzaee wrote:
> Hi
> apologize for interrupt and weak English.

This email is not appropriate for this mailing list, for help using or
installing gcc please use the gcc-h...@gcc.gnu.org mailing list.
Please follow up on that list instead, thanks.

> I need to install gcc cross compiler into Ubuntu 11.10 operating
> system on Intel core2due.

A cross compiler for what architecture?  I think Ubuntu includes an
arm cross compiler, if that's what you want then you should install it
from the Ubuntu package manager.

Re: Stack allocation

[David Brown]

On 18/11/2011 10:27, Alexandru Juncu wrote:

Hello!

I have a curiosity with something I once tested. I took a simple C
program and made an assembly file with gcc -S.

The C file looks something like this:
int main(void)
{
int a=1, b=2;
return 0;
}

The assembly instructions look like this:

subl$16, %esp
movl$1, -4(%ebp)
movl$2, -8(%ebp)

The subl $16, means the allocation of local variables on the stack,
right? 16 bytes are enough for 4 32bit integers.
If I have 1,2,3 or 4 local variables declared, you get those 16 bytes.
If I have 5 variables, we have "   subl$32, %esp". 5,6,7,8 variables ar
the same. 9, 10,11,12, 48 bytes.

The observation is that gcc allocates increments of 4 variables (if
they are integers). If I allocate 8bit chars, increments of 16 chars.

So the allocation is in increments of 16 bytes no matter what.

OK, that's the observation... my question is why? What's the reason
for this, is it an optimization (does is matter what's the -O used?)
or is it architecture dependent (I ran it on x86) and is this just in
gcc, just in a certain version of gcc or this is universal?

Thank you!



This is the wrong mailing list for questions like this - this is the 
list for development of gcc itself, rather than for using it.


However, in answer to your question, the compiler will try to keep the 
stack aligned in units of a suitable size for the processor architecture 
in use.  Typically, the processor will be most efficient if the stack is 
aligned with cache lines.  I don't know the details of the x86, but 
presumably (level 1) cache lines are 16 bytes wide - or at least, that 
number fits things like internal bus widths, prefetch buffers, etc. 
Thus the compiler makes the tradeoff of using slightly more memory to 
improve the speed of the program.

About TYPE_DECL, typedefs and TYPE_NEXT_VARIANT

[Alberto Lozano Alelu]

Hello.
First at all. This is my first message in this mailing list.

I'm developing a static source analyzer from c++ frontend (in future
it will be a gcc plugin) and I get problems when I access to type of
typedef.
When I get a typedef, I would like to show the definition. I use:

tree v_next_type=DECL_ORIGINAL_TYPE(TYPE_NAME(v_type));

But this expression isn't always correct.

In the next source code when I get pp typedef (1) node the type
defined is  my_pair@int>::my_class>::my_class

I would like to get the node my_pair::my_public_class

P.S: I'm sorry if the style isn't correct for mailing list. I'm sure I
will improve the next time.
Thanks.

-
using namespace std;
template 
class my_pair {
private:
 class my_class {
 private:
   int r_a; };
public:
 typedef my_class my_public_class;
};

template 
class my_pair_2 {
private:
 class my_class {
 private:
   int r_a; };
public:
 typedef my_class my_public_class;
};

class Srv {
private:
 class SrvNested {
 };
public:
 typedef my_pair_2::my_public_class ItemId;
};

typedef my_pair::my_public_class pp;   <- (1)
-

Re: Stack allocation

[Alexandru Juncu]

On Fri, Nov 18, 2011 at 1:24 PM, David Brown  wrote:
> On 18/11/2011 10:27, Alexandru Juncu wrote:
>>
>> Hello!
>>
>> I have a curiosity with something I once tested. I took a simple C
>> program and made an assembly file with gcc -S.
>>
>> The C file looks something like this:
>> int main(void)
>> {
>>    int a=1, b=2;
>>    return 0;
>> }
>>
>> The assembly instructions look like this:
>>
>> subl    $16, %esp
>> movl    $1, -4(%ebp)
>> movl    $2, -8(%ebp)
>>
>> The subl $16, means the allocation of local variables on the stack,
>> right? 16 bytes are enough for 4 32bit integers.
>> If I have 1,2,3 or 4 local variables declared, you get those 16 bytes.
>> If I have 5 variables, we have "        subl    $32, %esp". 5,6,7,8
>> variables ar
>> the same. 9, 10,11,12, 48 bytes.
>>
>> The observation is that gcc allocates increments of 4 variables (if
>> they are integers). If I allocate 8bit chars, increments of 16 chars.
>>
>> So the allocation is in increments of 16 bytes no matter what.
>>
>> OK, that's the observation... my question is why? What's the reason
>> for this, is it an optimization (does is matter what's the -O used?)
>> or is it architecture dependent (I ran it on x86) and is this just in
>> gcc, just in a certain version of gcc or this is universal?
>>
>> Thank you!
>>
>
> This is the wrong mailing list for questions like this - this is the list
> for development of gcc itself, rather than for using it.

Thank you for still answering. I apologize, but I looked at the lists
and this one seemed the most generic.  Can you redirect me to another
list where this thread would be appropriate?

>
> However, in answer to your question, the compiler will try to keep the stack
> aligned in units of a suitable size for the processor architecture in use.
>  Typically, the processor will be most efficient if the stack is aligned
> with cache lines.  I don't know the details of the x86, but presumably
> (level 1) cache lines are 16 bytes wide - or at least, that number fits
> things like internal bus widths, prefetch buffers, etc. Thus the compiler
> makes the tradeoff of using slightly more memory to improve the speed of the
> program.

I tried to compile with --param l1-cache-size... nothing seemed to change.

Re: Stack allocation

[Mihai Donțu]

On Fri, 18 Nov 2011 15:38:25 +0200 Alexandru Juncu wrote:
> Thank you for still answering. I apologize, but I looked at the lists
> and this one seemed the most generic.  Can you redirect me to another
> list where this thread would be appropriate?
> 

See 'gcc-help': http://gcc.gnu.org/lists.html

-- 
Mihai Donțu

Re: Stack allocation

[David Brown]

On 18/11/2011 14:38, Alexandru Juncu wrote:

On Fri, Nov 18, 2011 at 1:24 PM, David Brown  wrote:

On 18/11/2011 10:27, Alexandru Juncu wrote:


Hello!

I have a curiosity with something I once tested. I took a simple C
program and made an assembly file with gcc -S.

The C file looks something like this:
int main(void)
{
int a=1, b=2;
return 0;
}

The assembly instructions look like this:

subl$16, %esp
movl$1, -4(%ebp)
movl$2, -8(%ebp)

The subl $16, means the allocation of local variables on the stack,
right? 16 bytes are enough for 4 32bit integers.
If I have 1,2,3 or 4 local variables declared, you get those 16 bytes.
If I have 5 variables, we have "subl$32, %esp". 5,6,7,8
variables ar
the same. 9, 10,11,12, 48 bytes.

The observation is that gcc allocates increments of 4 variables (if
they are integers). If I allocate 8bit chars, increments of 16 chars.

So the allocation is in increments of 16 bytes no matter what.

OK, that's the observation... my question is why? What's the reason
for this, is it an optimization (does is matter what's the -O used?)
or is it architecture dependent (I ran it on x86) and is this just in
gcc, just in a certain version of gcc or this is universal?

Thank you!



This is the wrong mailing list for questions like this - this is the list
for development of gcc itself, rather than for using it.


Thank you for still answering. I apologize, but I looked at the lists
and this one seemed the most generic.  Can you redirect me to another
list where this thread would be appropriate?


That would be gcc-h...@gcc.gnu.org.

There is a certain amount of overlap between the lists, and many (most?) 
of the gcc developers follow both of them.






However, in answer to your question, the compiler will try to keep the stack
aligned in units of a suitable size for the processor architecture in use.
  Typically, the processor will be most efficient if the stack is aligned
with cache lines.  I don't know the details of the x86, but presumably
(level 1) cache lines are 16 bytes wide - or at least, that number fits
things like internal bus widths, prefetch buffers, etc. Thus the compiler
makes the tradeoff of using slightly more memory to improve the speed of the
program.


I tried to compile with --param l1-cache-size... nothing seemed to change.



That would only affect the cache size in total, not the cache line width 
- "--param l1-cache-line-size" is the one you are looking for.  And 
there are other reasons why a 16-byte stack alignment might be 
considered optimal for the x86, so even if you change 
"l1-cache-line-size" it might not change the stack alignment.

Re: Links to release criteria?

[Gerald Pfeifer]

On Thu, 17 Nov 2011, Diego Novillo wrote:
> I was thinking changing the text:
> 
> Active development: GCC 4.7.0 (changes)
> 
> to
> 
> Active development: GCC 4.7.0 (changes, release criteria)

Sounds good to me!

> Or simply make 'GCC 4.7.0' a link to a 4.7-specific page.

I'm not sure one would expect release criteria there?  And I think it's 
nice to have a larger difference between "released" and "forthcoming"
as we currently have it, but that's more of a feeling.

How about you making this an explicit link as you suggest?

Gerald

GNU Tools Cauldron 2012 - Call for Abstracts and Participation

[Diego Novillo]

==
 GNU Tools Cauldron 2012
  http://gcc.gnu.org/wiki/cauldron2012


   Call for Abstracts

July 2012
   Charles University, Prague, Czech Republic


 Co-organized by

  UIUK (Computer Science Institute, Charles University)
   CE-ITI (Institute for Theoretical Computer Science)
 Google


Current Sponsors

 AdaCore
 Google
   IBM


  Abstract submission deadline: 31 January 2012 

==

We are pleased to announce another gathering of GNU tools
developers. The basic format of this meeting will be similar to
the last one at the Google offices in London
(http://gcc.gnu.org/wiki/GCCGathering2011).

The purpose of this workshop is to gather all GNU tools
developers, discuss current/future work, coordinate efforts,
exchange reports on ongoing efforts, discuss development plans
for the next 12 months, developer tutorials and any other related
discussions.

Initially, we are thinking of meeting for 2 to 3 days. This time
we will meet at the Lesser Town Campus of Charles University in
Prague (Malostranske Namesti 25, Prague, Czech Republic) in July
2012.  We are still in the planning process, so these dates are
tentative.

We are inviting every developer working in the GNU toolchain:
GCC, GDB, binutils, runtimes, etc.  The basic format of the
meeting will be similar, but in addition to discussion topics
selected at the conference, we are looking for advance
submissions.

If you have a topic that you would like to present, please submit
an abstract describing what you plan to present.  We are
accepting three types of submissions:

- Prepared presentations: demos, project reports, etc.
- BoFs: coordination meetings with other developers.
- Tutorials for developers.  No user tutorials, please.

Note that we will not be doing in-depth reviews of the
presentations.  Mainly we are looking for applicability and to
decide scheduling.  There will be time at the conference to add
other topics of discussion, similarly to what we did at the
London meeting.

To register your abstract, send e-mail to
tools-cauldron-ad...@googlegroups.com.

Your submission should contain the following information:

Title:
Authors:
Abstract:

If you intend to participate, but not necessarily present, please
let us know as well.  Send a message to
tools-cauldron-ad...@googlegroups.com stating your intent to
participate.

The Linux binutils 2.22.51.0.1 is released

[H.J. Lu]

Hi,

This release has been delayed for several months.  There are no
tarballs. Please get it directly from linux/release/2.22.51.0.1 branch
at

http://git.kernel.org/?p=linux/kernel/git/hjl/binutils.git;a=summary

H.J.

This is the beta release of binutils 2.22.51.0.1 for Linux, which is
based on binutils 2011 1115 in CVS on sourceware.org plus various
changes. It is purely for Linux.

All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.

Starting from the 2.21.51.0.3 release, you must remove .ctors/.dtors
section sentinels when building glibc or other C run-time libraries.
Otherwise, you will run into:

http://sourceware.org/bugzilla/show_bug.cgi?id=12343

Starting from the 2.21.51.0.2 release, BFD linker has the working LTO
plugin support. It can be used with GCC 4.5 and above. For GCC 4.5, you
need to configure GCC with --enable-gold to enable LTO plugin support.

Starting from the 2.21.51.0.2 release, binutils fully supports compressed
debug sections.  However, compressed debug section isn't turned on by
default in assembler. I am planning to turn it on for x86 assembler in
the future release, which may lead to the Linux kernel bug messages like

WARNING: lib/ts_kmp.o (.zdebug_aranges): unexpected non-allocatable section.

But the resulting kernel works fine.

Starting from the 2.20.51.0.4 release, no diffs against the previous
release will be provided.

You can enable both gold and bfd ld with --enable-gold=both.  Gold will
be installed as ld.gold and bfd ld will be installed as ld.bfd.  By
default, ld.bfd will be installed as ld.  You can use the configure
option, --enable-gold=both/gold to choose gold as the default linker,
ld.  IA-32 binary and X64_64 binary tar balls are configured with
--enable-gold=both/ld --enable-plugins --enable-threads.

Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts

fnstsw %eax

fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use

fnstsw %ax

Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.

For

.data.init_task : { *(.data.init_task) }

LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use

.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }

to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior.  You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.

The new x86_64 assembler no longer accepts

monitor %eax,%ecx,%edx

You should use

monitor %rax,%ecx,%edx

or
monitor

which works with both old and new x86_64 assemblers. They should
generate the same opcode.

The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,

movl (%eax),%ds
movl %ds,(%eax)

To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,

mov (%eax),%ds
mov %ds,(%eax)

should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support

movw (%eax),%ds
movw %ds,(%eax)

without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at

http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch

The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add

ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif

to arch/ia64/Makefile in your kernel source tree.

Please report any bugs related to binutils 2.22.51.0.1 to
hjl.to...@gmail.com

and

http://www.sourceware.org/bugzilla/

Changes from binutils 2.21.53.0.2:

1. Update from binutils 2011 1118.
2. Fix ar --plugin on archive with mixed IR/non-IR objects.  PR 13298.
3. Preserve the maximum alignment and size for common symbols.  PR 13250.
4. Fix LTO linker with -as-needed.  PR 13287.
5. Fix --plugin support on thin archive.  PR 13257.
6. Fix LTO linker on thin archive.  PR 13183.
7. Fix --plugin slim object support on archive.  PR 13278.
8. Support LDPR_PREVAILING_DEF_IRONLY_EXP in linker plugin.  PR 13229.
9. Don't make make IR symbols dynamic.  PR 13244.
10. Fix LTO linker with --as

ICE in int_mode_for_mode()

[David Miller]

For a few days a lot of new testsuite failures have popped up on sparc,
wherein int_mode_for_mode() gets called with "VOIDmode" as an argument
from extract_bit_field_1 because "op0" is "(const_int 0)"

I have a feeling this is a known problem, but I couldn't find any
discussions about this.

I strongly suspect the following change caused this problem:

2011-11-16  Andreas Krebbel  

PR middle-end/50325
* expmed.c (store_bit_field_1): Use extract_bit_field on big
endian targets if the source cannot be exactly covered by word
mode chunks.

Re: ICE in int_mode_for_mode()

[David Edelsohn]

David,

See PR 50325.

- David

On Fri, Nov 18, 2011 at 3:22 PM, David Miller  wrote:
>
> For a few days a lot of new testsuite failures have popped up on sparc,
> wherein int_mode_for_mode() gets called with "VOIDmode" as an argument
> from extract_bit_field_1 because "op0" is "(const_int 0)"
>
> I have a feeling this is a known problem, but I couldn't find any
> discussions about this.
>
> I strongly suspect the following change caused this problem:
>
> 2011-11-16  Andreas Krebbel  
>
>        PR middle-end/50325
>        * expmed.c (store_bit_field_1): Use extract_bit_field on big
>        endian targets if the source cannot be exactly covered by word
>        mode chunks.
>

ICE

[François Dumont]

Hi

While working on hashtable I have added this kind of expression to 
decide to cache or not hash code:


  template,
   class _Pred = std::equal_to<_Value>,
   class _Alloc = std::allocator<_Value>,
   bool __cache_hash_code =
 __not_<__and_,
   integral_constant  noexcept(declval()(declval_Value&>()))>>

>::value>
class __unordered_set

In normal mode it works fine however in debug mode it generates an ICE:

Executing on host: /home/fdt/dev/gcc-trunk-build/./gcc/g++ 
-shared-libgcc -B/home/fdt/dev/gcc-trunk-build/./gcc -nostdinc++ 
-L/home/fdt/dev/gcc-trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/fdt/dev/gcc-trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs 
-B/usr/local/x86_64-unknown-linux-gnu/bin/ 
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem 
/usr/local/x86_64-unknown-linux-gnu/include -isystem 
/usr/local/x86_64-unknown-linux-gnu/sys-include 
-B/home/fdt/dev/gcc-trunk-build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs 
-g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections 
-fdata-sections -g -O2 -D_GNU_SOURCE  -DLOCALEDIR="." -nostdinc++ 
-I/home/fdt/dev/gcc-trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu 
-I/home/fdt/dev/gcc-trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include 
-I/home/fdt/dev/gcc-trunk/libstdc++-v3/libsupc++ 
-I/home/fdt/dev/gcc-trunk/libstdc++-v3/include/backward 
-I/home/fdt/dev/gcc-trunk/libstdc++-v3/testsuite/util 
/home/fdt/dev/gcc-trunk/libstdc++-v3/testsuite/23_containers/unordered_multiset/erase/1.cc   
-std=gnu++0x ./libtestc++.a -Wl,--gc-sections  -lm   -D_GLIBCXX_DEBUG -o 
./1.exe(timeout = 600)
In file included from 
/home/fdt/dev/gcc-trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/unordered_set:46:0,
 from 
/home/fdt/dev/gcc-trunk/libstdc++-v3/testsuite/23_containers/unordered_multiset/erase/1.cc:22:
/home/fdt/dev/gcc-trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/unordered_set.h:282:58: 
internal compiler error: tree check: accessed elt 6 of tree_vec with 5 
elts in tsubst, at cp/pt.c:11144

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
compiler exited with status 1

I know that 4.7 is going to be released soon so I prefer to report it 
quickly. I should be able to submit a complete patch for hashtable 
generating this ICE if the error message is not enough.


François

more pointer mode madness

[DJ Delorie]

I can't produce a small test case for this because it involves copied
variables vanishing, but...

in expand_debug_locations() we have an assert thusly:

gcc_assert (mode == GET_MODE (val)

In the failing case I'm seeing (s390) I've got a pointer variable
that's SImode, being set from the address of another variable
(simplified example):

t = &s;

The vartrack stuff sees that t's own storage goes away, and sets its
var_location to an expression involving s.  However, the expression is
DImode (the default pointer mode) where T is SImode, and the assert
fails.  I.e. there's a lost cast somewhere.

I can work around this by testing for this specific case and just tossing
the debug info:

if (targetm.valid_pointer_mode (mode)
&& targetm.valid_pointer_mode (GET_MODE (val))
&& mode != GET_MODE (val))
  {
val = gen_rtx_UNKNOWN_VAR_LOC ();
  }
else
  ... the assert ...

but this smells like a hack.  However, i'm having a hard time finding
out where this stuff is being set up.

Suggestions?

Re: ICE

[Paolo Carlini]

On 11/18/2011 10:05 PM, François Dumont wrote:
I know that 4.7 is going to be released soon so I prefer to report it 
quickly. I should be able to submit a complete patch for hashtable 
generating this ICE if the error message is not enough.
Well, the error message is very, very often not enough. Please file in 
any case a normal PR, possibly reduced via 'delta'. In the meanwhile, we 
shall use a workaround or delay these specific bits, I suppose...


Thanks,
Paolo.

gcc-4.6-20111118 is now available

[gccadmin]

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

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

You'll find:

 gcc-4.6-2018.tar.bz2 Complete GCC

  MD5=b6c069941f6bbba4dcf38266cba32018
  SHA1=d223993343cd7884d48af3325dbe803f8ee68326

Diffs from 4.6-2011 are available in the diffs/ subdirectory.

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

Re: Links to release criteria?

[Diego Novillo]

On Fri, Nov 18, 2011 at 07:54, Gerald Pfeifer  wrote:
> On Thu, 17 Nov 2011, Diego Novillo wrote:
>> I was thinking changing the text:
>>
>> Active development: GCC 4.7.0 (changes)
>>
>> to
>>
>> Active development: GCC 4.7.0 (changes, release criteria)
>
> Sounds good to me!
>
>> Or simply make 'GCC 4.7.0' a link to a 4.7-specific page.
>
> I'm not sure one would expect release criteria there?  And I think it's
> nice to have a larger difference between "released" and "forthcoming"
> as we currently have it, but that's more of a feeling.
>
> How about you making this an explicit link as you suggest?

Sure.  I committed the following change:

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.824
diff -u -d -u -p -r1.824 index.html
--- index.html  15 Nov 2011 06:01:24 -  1.824
+++ index.html  18 Nov 2011 23:03:21 -
@@ -170,7 +170,7 @@ Any additions?  Don't be shy, send them
 

 Active development:
-  GCC 4.7.0 (changes)
+  GCC 4.7.0 (changes, release criteria)
 
   Status: