[Bug c++/36429] structure/array member reference/pointer as template argument

[firda at seznam dot cz]

--- Comment #3 from firda at seznam dot cz  2008-06-04 07:50 ---
To make things even worse... (allright, I will try ARMGNU 4.1.1 or give up, and
use copy-paste)

typedef unsigned uint;
//##
struct Now {
static volatile uint centi;
static uint synced;
static uint seconds; }
now;
//##
template
  class TTimer {
public:
TIME from;
public:
void start() {
from = NOW; }
TIME elapsed() {
return NOW - from; }
bool reached(TIME timeout) {
return NOW - from >= timeout; }
void fire(TIME timeout) {
from = NOW - timeout; }};
//##
typedef TTimer Timer;
typedef TTimerCsTimer;
typedef TTimer   SecTimer;
//##
int main() {
Timer timer;
timer.start();
while (!timer.reached(100))
now.centi++;
return 0; }

c:\devel\work>arm-uclibc-gcc -v
Reading specs from
/cygdrive/c/cygwin/arm-tools/bin/../lib/gcc-lib/arm-thumb-elf
/3.3.1/specs
Configured with: /home/Unknown/toolchain/build/gcc-3.3.1/configure
--target=arm-
thumb-elf --host=i686-pc-cygwin --build=i686-pc-cygwin --prefix=/arm-tools
--exe
c-prefix=/arm-tools --bindir=/arm-tools/bin --sbindir=/arm-tools/sbin
--sysconfd
ir=/arm-tools/etc --datadir=/arm-tools/share --localstatedir=/arm-tools/var
--ma
ndir=/arm-tools/man --infodir=/arm-tools/info --libdir=/arm-tools/lib
--included
ir=/arm-tools/include --with-local-prefix=/arm-tools/usr/local
--with-gxx-includ
e-dir=/arm-tools/include/c++ --enable-target-optspace --disable-nls
--with-gnu-a
s --with-gnu-ld --disable-__cxa_atexit --enable-languages=c,c++ --enable-shared
--program-prefix=arm-uclibc-
Thread model: single
gcc version 3.3.1

c:\devel\work>arm-uclibc-gcc -c -mcpu=arm7tdmi -mthumb -gdwarf-2 -MD -Wa
ll -Os -mapcs-frame -mthumb-interwork main.cpp
main.cpp: In member function `void TTimer::start() [with TIME =
   uint, const volatile TIME&NOW = Now::centi]':
main.cpp:29:   instantiated from here
main.cpp:15: internal compiler error: in build_modify_expr, at cp/typeck.c:5358
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


-- 


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

[Bug c++/36429] structure/array member reference/pointer as template argument

[firda at seznam dot cz]

--- Comment #4 from firda at seznam dot cz  2008-06-04 07:56 ---
c:\Program Files\GNUARM\bin>arm-elf-g++ -v
Using built-in specs.
Target: arm-elf
Configured with: ../gcc-4.1.1/configure --target=arm-elf
--prefix=/g/gnuarm-4.1.
1 --enable-interwork --enable-multilib --with-float=soft --with-newlib
--with-he
aders=../newlib-1.14.0/newlib/libc/include --enable-languages=c,c++
Thread model: single
gcc version 4.1.1

c:\Program Files\GNUARM\bin>arm-elf-g++ -c -mcpu=arm7tdmi -mthumb -gdwarf-2 -MD
-Wall -Os -mapcs-frame -mthumb-interwork c:\devel\positra\work\main.cpp
c:\devel\positra\work\main.cpp:23: error: 'now' cannot appear in a
constant-expr
ession
c:\devel\positra\work\main.cpp:23: error: `.' cannot appear in a
constant-expres
sion
c:\devel\positra\work\main.cpp:23: error: template argument 2 is invalid
c:\devel\positra\work\main.cpp:23: error: invalid type in declaration before
';'
 token
c:\devel\positra\work\main.cpp:24: error: 'now' cannot appear in a
constant-expr
ession
c:\devel\positra\work\main.cpp:24: error: `.' cannot appear in a
constant-expres
sion
c:\devel\positra\work\main.cpp:24: error: template argument 2 is invalid
c:\devel\positra\work\main.cpp:24: error: invalid type in declaration before
';'
 token
c:\devel\positra\work\main.cpp:25: error: 'now' cannot appear in a
constant-expr
ession
c:\devel\positra\work\main.cpp:25: error: `.' cannot appear in a
constant-expres
sion
c:\devel\positra\work\main.cpp:25: error: template argument 2 is invalid
c:\devel\positra\work\main.cpp:25: error: invalid type in declaration before
';'
 token
c:\devel\positra\work\main.cpp: In function 'int main()':
c:\devel\positra\work\main.cpp:29: error: request for member 'start' in
'timer',
 which is of non-class type 'Timer'
c:\devel\positra\work\main.cpp:30: error: request for member 'reached' in
'timer
', which is of non-class type 'Timer'


-- 


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

[Bug c++/23383] builtin array operator new is not marked with malloc attribute

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2008-06-04 07:58 
---
Interesting things start to happen once you inline allocator functions as well.
See PR29286 and PR33407 which we still don't handle 100% correct.


-- 


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

[Bug driver/35916] problem running GCC under Vista with relocated directory

[dannysmith at users dot sourceforge dot net]

--- Comment #11 from dannysmith at users dot sourceforge dot net  
2008-06-04 08:22 ---
This fixes for me on Vista host.  Can someone confirm?

config/ChangeLog

PR35916
* mh-mingw (CFLAGS): Add -D__USE_MINGW_ACCESS.


Index: config/mh-mingw
===
--- config/mh-mingw (revision 136350)
+++ config/mh-mingw (working copy)
@@ -1,3 +1,4 @@
 # Add -D__USE_MINGW_ACCESS to enable the built compiler to work on Windows
 # Vista (see PR33281 for details).
 BOOT_CFLAGS += -D__USE_MINGW_ACCESS
+CFLAGS += -D__USE_MINGW_ACCESS


-- 

dannysmith at users dot sourceforge dot net changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dannysmith at users dot
   |dot org |sourceforge dot net
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-06-03 04:31:48 |2008-06-04 08:22:20
   date||


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

[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2008-06-04 08:59 ---
The only code-generation changing part of the patch is

(insert_fake_stores): Handle all component-ref style stores
in addition to INDIRECT_REF.  Also handle complex types.

but that only fixes a missed-optimization, so it probably makes the problem
latent on the trunk.


-- 


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

[Bug target/36133] GCC creates suboptimal ASM : Code includes unneeded TST instructions

[gunnar at greyhound-data dot com]

--- Comment #4 from gunnar at greyhound-data dot com  2008-06-04 09:29 
---
I want to add that this wrong behavior is partly related to the compile option
"-Os".

There are two causes where GCC generates unneeded TST instructions.
A) General arithmetic 
 lsr.l #1,D0 
 tst.l d0
 jbne ...

This tst instruction is unneeded as the LSR is setting the flags correctly
already.

B) subq.l #1,D1
  tst.l d1
  jbne ...

This unneeded TST is related to the compile option used.
If you compile the source with "-O2" then the second unneeded TST instructions
are not included in the source.

It seems to me that a general important optimizations step - which used to be
in  "Os" in GCC 2.9 was removed from "Os" causing GCC to generate worse code
now.

Can you please be so kind and correct this?

I believe that this issue is quite serious for the performance of the generated
code.

1st The unneeded TST instructions are increasing code size, which is important
in embedded environments.

2nd
There are case were the instruction which really did set the condition codes
correctly in the first place is far enough away from the conditional branch and
no CC trashing instruction in between them - so that the instruction fetcher
can 100% correctly predict the branch and fold it away completely. The unneeded
TST instruction makes branch folding impossible and requires the CPU to guess
the branch instead. This will cause a serious performance impact in case of
mispredicting the branch.
It should be clear that the unneeded TST instruction doas not only bloat the
code but the above mentioned conditions can serious degrade the performance as
well, depending on your used CPU of course.

In the light of this, wouldn't it might sense to increase the Severity of this
issue?


Regards
Gunnar


-- 


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

[Bug c/36433] New: mregeparm

[gunnar at greyhound-data dot com]

-- 
   Summary: mregeparm
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gunnar at greyhound-data dot com
 GCC build triplet: m68k-linux-gnu
  GCC host triplet: m68k-linux-gnu
GCC target triplet: m68k-linux-gnu


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

[Bug c/36433] mregeparm not supported on 68k / Coldfire

[gunnar at greyhound-data dot com]

--- Comment #1 from gunnar at greyhound-data dot com  2008-06-04 09:54 
---
The parameter -mregparm is not supported on M68k / Coldfire.

As it its known from the X86 platform compiling with mregparm does improve the
size and performance of the generated code. On X86 an overall improvement of
5%-7% is generally stated. This parameter is unfortunately not supported for
the M68k and Coldfire platform. This is a serious drawback especiall as on 68k
there are operating systems which have parameter passing in registers as their
default behavior. (i.e AmigaOS)

Please be so kind and add the regparm feature to the 68k Coldfire.
It will certainly improve generated code a lot.

Many thanks in advance

Gunnar von Boehn


-- 

gunnar at greyhound-data dot com changed:

   What|Removed |Added

Summary|mregeparm   |mregeparm not supported on
   ||68k / Coldfire


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

[Bug c/36432] �incompatible pointer type� with pointer to array as a struct member

[jsm28 at gcc dot gnu dot org]

--- Comment #1 from jsm28 at gcc dot gnu dot org  2008-06-04 10:46 ---
GCC is wrongly treating any [] in a field declarator as meaning a flexible
array member, instead of only those declaring the field itself as an array.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||16620, 16989
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-06-04 10:46:01
   date||


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

[Bug target/16563] The compiler doesnt the necessary push/restore of r18/r19

[eric dot weddington at atmel dot com]

--- Comment #7 from eric dot weddington at atmel dot com  2008-06-04 13:06 
---
Bug closed based on comment #5.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.0.0


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

[Bug target/36433] mregeparm not supported on 68k / Coldfire

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug c++/36435] New: Partial ordering of explicit specialization should include return type

[jhs at edg dot com]

This example results in an ambiguity on the line marked "!!!:

ex.c:8: error: ambiguous template specialization ‘to_y’ for ‘Y X::to_y()’

This is currently rejected by g++, MSVC, and EDG, but we (EDG) believe it
should be accepted.

14.8.2.4 says that in contexts other than a call, the complete function type
should be used for partial ordering purposes.



template struct Y { };

struct X {
  template  Y< T, void *, int> to_y();
  template Y< T, U, int>  to_y();
};

template<> Y  X::to_y ();// !!!
template<> Y   X::to_y ();

void g() {
   X x;
   x.to_y ();
   x.to_y ();
}


-- 
   Summary: Partial ordering of explicit specialization should
include return type
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jhs at edg dot com
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/23383] builtin array operator new is not marked with malloc attribute

[davidxl at gcc dot gnu dot org]

--- Comment #13 from davidxl at gcc dot gnu dot org  2008-06-04 16:48 
---
(In reply to comment #12)
> Interesting things start to happen once you inline allocator functions as 
> well.
> See PR29286 and PR33407 which we still don't handle 100% correct.
> 

I browsed through the two bugs -- it seems that compiler should get this right
regardless -- local pointer analysis should detect the must aliasing and should
overrule the type based aliasing decision when the placement new is inlined. If
not inlined, compiler should know the exact semantics of placement new (return
== arg), or treat it conservatively. 

David


-- 


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

[Bug c++/23383] builtin array operator new is not marked with malloc attribute

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2008-06-04 17:03 
---
We do the exact opposite - type-based rules override points-to must-alias
information (or really may-alias information).  Also for the proposed scheme
to work you need to guarantee that you always can compute correct points-to
relations (I mean, if points-to information says pt_anything and if you
then assume must-alias and thus a conflict then you simply disable TBAA
completely).


-- 


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

[Bug c++/23383] builtin array operator new is not marked with malloc attribute

[davidxl at gcc dot gnu dot org]

--- Comment #15 from davidxl at gcc dot gnu dot org  2008-06-04 17:34 
---
(In reply to comment #14)
> We do the exact opposite - type-based rules override points-to must-alias
> information (or really may-alias information).  Also for the proposed scheme
> to work you need to guarantee that you always can compute correct points-to
> relations (I mean, if points-to information says pt_anything and if you
> then assume must-alias and thus a conflict then you simply disable TBAA
> completely).
> 

Right, in general, type alias rules should override field and flow insensitive
pointer aliasing information as they really have very low confidence level
(especially for pt_anything case which is just a baseless guess) -- but 
precise/trustworthy aliasing info should be checked before assertion based
alias information and decide whether to proceed. 

For example:

if (no_alias_according_to_conservative_pointer_info) return no_alias;
if (no_alias_according_to_precise_pointer_info) return no_alias;
if (must_alias or definitely_may_alias) return may/must_alias;   (1)

// now proceed with type based rules, etc.


This is in theory. In practice, it can be tricky to tag the confidence level of
aliasing info.

David


-- 


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

[Bug fortran/29600] MINLOC, MAXLOC and SHAPE take an optional KIND argument

[tkoenig at gcc dot gnu dot org]

--- Comment #7 from tkoenig at gcc dot gnu dot org  2008-06-04 19:06 ---
No time for now (Real Time is catching up with me big time).

Unassigning (for now).


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|tkoenig at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


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

[Bug fortran/36313] [F2003] {MIN,MAX}{LOC,VAL} should accept character arguments

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2008-06-04 19:06 ---
No time for now (Real Time is catching up with me big time).

Unassigning (for now).


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|tkoenig at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


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

[Bug tree-optimization/36436] New: -ftree-vrp -O1 -msse5 -ftree-vectorize leads to segfault during garbage collection

[gnu at the-meissners dot org]

If I compile the attached preprocessed file with -O1 -msse5 -ftree-vectorize
-ftree-vrp (or -O3), the compiler does a segmentation fault while garbage
collecting.  If I use the -fno-tree-vrp switch, the program compiles fine, even
with -O3.

(gdb) r -O1 -msse5 -ftree-vectorize -ftree-vrp sse5.i
Starting program: /data-gold1/fsf-build/trunk/gcc/cc1 -O1 -msse5
-ftree-vectorize -ftree-vrp sse5.i
 vprintf getchar fgetc_unlocked getc_unlocked getchar_unlocked putchar
fputc_unlocked putc_unlocked putchar_unlocked feof_unlocked ferror_unlocked
atof atoi atol atoll gnu_dev_major gnu_dev_minor gnu_dev_makedev __strcspn_c1
__strcspn_c2 __strcspn_c3 __strspn_c1 __strspn_c2 __strspn_c3 __strpbrk_c2
__strpbrk_c3 __strtok_r_1c __strsep_1c __strsep_2c __strsep_3c _mm_empty
_m_empty _mm_cvtsi32_si64 _m_from_int _m_from_int64 _mm_cvtsi64_m64
_mm_cvtsi64x_si64 _mm_set_pi64x _mm_cvtsi64_si32 _m_to_int _m_to_int64
_mm_cvtm64_si64 _mm_cvtsi64_si64x _mm_packs_pi16 _m_packsswb _mm_packs_pi32
_m_packssdw _mm_packs_pu16 _m_packuswb _mm_unpackhi_pi8 _m_punpckhbw
_mm_unpackhi_pi16 _m_punpckhwd _mm_unpackhi_pi32 _m_punpckhdq _mm_unpacklo_pi8
_m_punpcklbw _mm_unpacklo_pi16 _m_punpcklwd _mm_unpacklo_pi32 _m_punpckldq
_mm_add_pi8 _m_paddb _mm_add_pi16 _m_paddw _mm_add_pi32 _m_paddd _mm_add_si64
_mm_adds_pi8 _m_paddsb _mm_adds_pi16 _m_paddsw _mm_adds_pu8 _m_paddusb
_mm_adds_pu16 _m_paddusw _mm_sub_pi8 _m_psubb _mm_sub_pi16 _m_psubw
_mm_sub_pi32 _m_psubd _mm_sub_si64 _mm_subs_pi8 _m_psubsb _mm_subs_pi16
_m_psubsw _mm_subs_pu8 _m_psubusb _mm_subs_pu16 _m_psubusw _mm_madd_pi16
_m_pmaddwd _mm_mulhi_pi16 _m_pmulhw _mm_mullo_pi16 _m_pmullw _mm_sll_pi16
_m_psllw _mm_slli_pi16 _m_psllwi _mm_sll_pi32 _m_pslld _mm_slli_pi32 _m_pslldi
_mm_sll_si64 _m_psllq _mm_slli_si64 _m_psllqi _mm_sra_pi16 _m_psraw
_mm_srai_pi16 _m_psrawi _mm_sra_pi32 _m_psrad _mm_srai_pi32 _m_psradi
_mm_srl_pi16 _m_psrlw _mm_srli_pi16 _m_psrlwi _mm_srl_pi32 _m_psrld
_mm_srli_pi32 _m_psrldi _mm_srl_si64 _m_psrlq _mm_srli_si64 _m_psrlqi
_mm_and_si64 _m_pand _mm_andnot_si64 _m_pandn _mm_or_si64 _m_por _mm_xor_si64
_m_pxor _mm_cmpeq_pi8 _m_pcmpeqb _mm_cmpgt_pi8 _m_pcmpgtb _mm_cmpeq_pi16
_m_pcmpeqw _mm_cmpgt_pi16 _m_pcmpgtw _mm_cmpeq_pi32 _m_pcmpeqd _mm_cmpgt_pi32
_m_pcmpgtd _mm_setzero_si64 _mm_set_pi32 _mm_set_pi16 _mm_set_pi8 _mm_setr_pi32
_mm_setr_pi16 _mm_setr_pi8 _mm_set1_pi32 _mm_set1_pi16 _mm_set1_pi8 _mm_malloc
_mm_free _mm_setzero_ps _mm_add_ss _mm_sub_ss _mm_mul_ss _mm_div_ss _mm_sqrt_ss
_mm_rcp_ss _mm_rsqrt_ss _mm_min_ss _mm_max_ss _mm_add_ps _mm_sub_ps _mm_mul_ps
_mm_div_ps _mm_sqrt_ps _mm_rcp_ps _mm_rsqrt_ps _mm_min_ps _mm_max_ps _mm_and_ps
_mm_andnot_ps _mm_or_ps _mm_xor_ps _mm_cmpeq_ss _mm_cmplt_ss _mm_cmple_ss
_mm_cmpgt_ss _mm_cmpge_ss _mm_cmpneq_ss _mm_cmpnlt_ss _mm_cmpnle_ss
_mm_cmpngt_ss _mm_cmpnge_ss _mm_cmpord_ss _mm_cmpunord_ss _mm_cmpeq_ps
_mm_cmplt_ps _mm_cmple_ps _mm_cmpgt_ps _mm_cmpge_ps _mm_cmpneq_ps _mm_cmpnlt_ps
_mm_cmpnle_ps _mm_cmpngt_ps _mm_cmpnge_ps _mm_cmpord_ps _mm_cmpunord_ps
_mm_comieq_ss _mm_comilt_ss _mm_comile_ss _mm_comigt_ss _mm_comige_ss
_mm_comineq_ss _mm_ucomieq_ss _mm_ucomilt_ss _mm_ucomile_ss _mm_ucomigt_ss
_mm_ucomige_ss _mm_ucomineq_ss _mm_cvtss_si32 _mm_cvt_ss2si _mm_cvtss_si64
_mm_cvtss_si64x _mm_cvtps_pi32 _mm_cvt_ps2pi _mm_cvttss_si32 _mm_cvtt_ss2si
_mm_cvttss_si64 _mm_cvttss_si64x _mm_cvttps_pi32 _mm_cvtt_ps2pi _mm_cvtsi32_ss
_mm_cvt_si2ss _mm_cvtsi64_ss _mm_cvtsi64x_ss _mm_cvtpi32_ps _mm_cvt_pi2ps
_mm_cvtpi16_ps _mm_cvtpu16_ps _mm_cvtpi8_ps _mm_cvtpu8_ps _mm_cvtpi32x2_ps
_mm_cvtps_pi16 _mm_cvtps_pi8 _mm_shuffle_ps _mm_unpackhi_ps _mm_unpacklo_ps
_mm_loadh_pi _mm_storeh_pi _mm_movehl_ps _mm_movelh_ps _mm_loadl_pi
_mm_storel_pi _mm_movemask_ps _mm_getcsr _MM_GET_EXCEPTION_STATE
_MM_GET_EXCEPTION_MASK _MM_GET_ROUNDING_MODE _MM_GET_FLUSH_ZERO_MODE _mm_setcsr
_MM_SET_EXCEPTION_STATE _MM_SET_EXCEPTION_MASK _MM_SET_ROUNDING_MODE
_MM_SET_FLUSH_ZERO_MODE _mm_set_ss _mm_set1_ps _mm_set_ps1 _mm_load_ss
_mm_load1_ps _mm_load_ps1 _mm_load_ps _mm_loadu_ps _mm_loadr_ps _mm_set_ps
_mm_setr_ps _mm_store_ss _mm_cvtss_f32 _mm_store_ps _mm_storeu_ps _mm_store1_ps
_mm_store_ps1 _mm_storer_ps _mm_move_ss _mm_extract_pi16 _m_pextrw
_mm_insert_pi16 _m_pinsrw _mm_max_pi16 _m_pmaxsw _mm_max_pu8 _m_pmaxub
_mm_min_pi16 _m_pminsw _mm_min_pu8 _m_pminub _mm_movemask_pi8 _m_pmovmskb
_mm_mulhi_pu16 _m_pmulhuw _mm_shuffle_pi16 _m_pshufw _mm_maskmove_si64
_m_maskmovq _mm_avg_pu8 _m_pavgb _mm_avg_pu16 _m_pavgw _mm_sad_pu8 _m_psadbw
_mm_prefetch _mm_stream_pi _mm_stream_ps _mm_sfence _mm_pause _mm_set_sd
_mm_set1_pd _mm_set_pd1 _mm_set_pd _mm_setr_pd _mm_setzero_pd _mm_move_sd
_mm_load_pd _mm_loadu_pd _mm_load1_pd _mm_load_sd _mm_load_pd1 _mm_loadr_pd
_mm_store_pd _mm_storeu_pd _mm_store_sd _mm_cvtsd_f64 _mm_storel_pd
_mm_storeh_pd _mm_store1_pd _mm_store_pd1 _mm_storer_pd _mm_cvtsi128_si32
_mm_cvtsi128_si64 _mm_cvtsi128_si64x _mm_add_pd _mm_add_sd _mm_sub_pd
_mm_sub_sd _mm_mul_pd _mm_mul_sd _mm_div_pd _mm_div_sd _mm_sqrt_pd _mm_sqrt_sd
_mm_min_pd _mm_min_sd _mm_m

[Bug tree-optimization/36436] -ftree-vrp -O1 -msse5 -ftree-vectorize leads to segfault during garbage collection

[gnu at the-meissners dot org]

--- Comment #1 from gnu at the-meissners dot org  2008-06-04 19:36 ---
Created an attachment (id=15719)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15719&action=view)
Preprocessed source code that shows the problem.


-- 


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

[Bug fortran/36437] New: F2008: Support c_sizeof // Simplify argument to [c_]sizeof

[burnus at gcc dot gnu dot org]

-- 
   Summary: F2008: Support c_sizeof  // Simplify argument to
[c_]sizeof
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/36437] F2008: Support c_sizeof // Simplify argument to [c_]sizeof

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-06-04 20:19 ---
Created an attachment (id=15720)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15720&action=view)
Incomplete patch

Fortran 2008 supports c_sizeof which is identical to gfortran's sizeof.

This patch does the following:

- Implements c_sizeof (one line in intrinsic.c)
- Fixes argument (sizeof(x) not sizeof(i)) - intrinsic.c
- Document new option  - intrinsic.texi
- trans-intrinsic.c (gfc_conv_intrinsic_sizeof): Don't create
  {
integer(kind=8) bytes.1;
i = 4;
  }
  in the simple case but simply "i = 4".
- simplify.c: Add gfc_simplify_sizeof:
  This partially works, is currently quite hacky and fails for substrings.

TODO: Fix the last item.


-- 


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

[Bug fortran/36437] F2008: Support c_sizeof // Simplify argument to [c_]sizeof

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-06-04 20:21 ---
Created an attachment (id=15721)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15721&action=view)
The real incomplete patch

Previous patch was an older version of this patch.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #15720|0   |1
is obsolete||


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

[Bug fortran/36275] Binding label can be any scalar char initialisation expression

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2008-06-04 21:05 ---
Subject: Bug 36275

Author: janus
Date: Wed Jun  4 21:04:32 2008
New Revision: 136372

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136372
Log:
2008-06-04  Janus Weil  <[EMAIL PROTECTED]>

PR fortran/36322
PR fortran/36275
* resolve.c (resolve_symbol): Correctly copy the interface for a
PROCEDURE declaration.


2008-06-04  Janus Weil  <[EMAIL PROTECTED]>

PR fortran/36322
PR fortran/36275
* gfortran.dg/proc_decl_2.f90: Extended.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/proc_decl_2.f90


-- 


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

[Bug fortran/36322] ICE with PROCEDURE using a complicated interface

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2008-06-04 21:05 ---
Subject: Bug 36322

Author: janus
Date: Wed Jun  4 21:04:32 2008
New Revision: 136372

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136372
Log:
2008-06-04  Janus Weil  <[EMAIL PROTECTED]>

PR fortran/36322
PR fortran/36275
* resolve.c (resolve_symbol): Correctly copy the interface for a
PROCEDURE declaration.


2008-06-04  Janus Weil  <[EMAIL PROTECTED]>

PR fortran/36322
PR fortran/36275
* gfortran.dg/proc_decl_2.f90: Extended.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/proc_decl_2.f90


-- 


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

[Bug fortran/36275] Binding label can be any scalar char initialisation expression

[janus at gcc dot gnu dot org]

--- Comment #5 from janus at gcc dot gnu dot org  2008-06-04 21:10 ---
Rev. 136372 fixes the issue from comment #2 (but not the original test case in
comment #0).


-- 


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

[Bug fortran/36366] [4.3/4.4 Regression] ICE in gfc_conv_component_ref

[pault at gcc dot gnu dot org]

--- Comment #1 from pault at gcc dot gnu dot org  2008-06-04 21:15 ---
(In reply to comment #0)
This PR is totally vexacious!

A number of things get rid of the ICE:
(i) Interchange test2 and test3;
(ii) Interchange the USE statements in test2; or
(iii) Make the component of outer a non-pointer array.

At the moment, I cannot see what draws these together. Nor can I see any
difference in the .mod files for the cases that work

Paul


-- 


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

[Bug fortran/36322] ICE with PROCEDURE using a complicated interface

[janus at gcc dot gnu dot org]

--- Comment #5 from janus at gcc dot gnu dot org  2008-06-04 21:17 ---
The test case in comment #0 is fixed by rev. 136372, but when compiling the
full program at

http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ff7ae6c7a7860bca/60213205751117d4

one now gets the error:

 gp = get_funloc(make_mess,aux)
1
Error: Type/rank mismatch in argument 'x' at (1)


-- 


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

[Bug target/30243] [4.1/4.2/4.3/4.4 Regression][avr] signbit() causes an internal compiler error

[hutchinsonandy at gcc dot gnu dot org]

--- Comment #10 from hutchinsonandy at gcc dot gnu dot org  2008-06-04 
22:00 ---
Subject: Bug 30243

Author: hutchinsonandy
Date: Wed Jun  4 21:59:54 2008
New Revision: 136376

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136376
Log:
PR target/30243
* builtins.c (expand_builtin_signbit): Don't take lowpart when register is
already smaller or equal to required mode. 

Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c


-- 


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

[Bug target/27386] AVR: wrong code generated when passing three uint64_t arguments to function

[hutchinsonandy at gcc dot gnu dot org]

--- Comment #15 from hutchinsonandy at gcc dot gnu dot org  2008-06-04 
22:03 ---
Subject: Bug 27386

Author: hutchinsonandy
Date: Wed Jun  4 22:02:57 2008
New Revision: 136377

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136377
Log:
PR target/27386
* config/avr/avr.h: (PUSH_ROUNDING): Remove.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.h


-- 


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

[Bug target/30243] [4.1/4.2/4.3/4.4 Regression][avr] signbit() causes an internal compiler error

[hutchinsonandy at gcc dot gnu dot org]

--- Comment #11 from hutchinsonandy at gcc dot gnu dot org  2008-06-04 
22:05 ---
Fixed 4.4
Back port to 4.3.2 when its open.


-- 

hutchinsonandy at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|4.2.5   |4.3.2


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

[Bug target/27386] AVR: wrong code generated when passing three uint64_t arguments to function

[hutchinsonandy at gcc dot gnu dot org]

--- Comment #16 from hutchinsonandy at gcc dot gnu dot org  2008-06-04 
22:06 ---
Fixed 4.4


-- 

hutchinsonandy at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.2


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

[Bug middle-end/36414] g++ causes segmentation violation on template test program

[kemal dot ebcioglu at acm dot org]

--- Comment #4 from kemal dot ebcioglu at acm dot org  2008-06-04 22:40 
---
(In reply to comment #3)
> Fixed in 4.0.0
> 
Thanks! I also verified that the template test case works in g++ version 4.3.0
on VMWare/Linux/Fedora 9, with the -O option. 


-- 


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

[Bug fortran/36322] ICE with PROCEDURE using a complicated interface

[burnus at gcc dot gnu dot org]

--- Comment #6 from burnus at gcc dot gnu dot org  2008-06-04 22:45 ---
(In reply to comment #5)
> The test case in comment #0 is fixed by rev. 136372, but when compiling the
> full program [...]

I don't see whether the full program is valid or not. (Well, except of the
interface in the main program, which is *invalid*.) In any case the following
reduced test case produces an ICE. (NAG f95 compiles it.)

internal compiler error: in make_decl_rtl, at varasm.c:1297

module other_fun
   implicit none
   abstract interface
  function abstract_fun(x)
 implicit none
 integer :: x(:)
 character(size(x)) abstract_fun
  end function abstract_fun
   end interface
   contains
  subroutine test()
 procedure(abstract_fun) foo
 call get_funloc(foo)
  end subroutine test

  subroutine get_funloc(x)
 procedure(abstract_fun) x
  end subroutine get_funloc
end module other_fun


-- 


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

[Bug fortran/36322] ICE with PROCEDURE using a complicated interface

[burnus at gcc dot gnu dot org]

--- Comment #7 from burnus at gcc dot gnu dot org  2008-06-04 22:46 ---
The dump contains:

test ()
{
  get_funloc (foo, .x);

What I find strange is:
a) That foo gets never defined
b) That .x is passed (string length?)


-- 


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

[Bug target/36423] avr-gcc use don't saved registers in ISR with -O3 ('-frename-registers' ) optimization

[eric dot weddington at atmel dot com]

--- Comment #1 from eric dot weddington at atmel dot com  2008-06-04 22:55 
---


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


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/36424] avr-gcc use don't saved registers in ISR with -O3 ('-frename-registers' ) optimization

[eric dot weddington at atmel dot com]

--- Comment #2 from eric dot weddington at atmel dot com  2008-06-04 22:55 
---
*** Bug 36423 has been marked as a duplicate of this bug. ***


-- 


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

[Bug fortran/36322] ICE with PROCEDURE using a complicated interface

[janus at gcc dot gnu dot org]

--- Comment #8 from janus at gcc dot gnu dot org  2008-06-04 23:37 ---
This further reduced test case gives a different ICE:

abstract interface
  function abs_fun(x)
implicit none
integer :: x(:)
character(size(x)) abs_fun
  end function
end interface
procedure(abs_fun) :: p
integer :: i(3) = (/1,2,3/)
print *,p(i)
end

internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:926

The reason for this seems to be that the symbol "x" is missing a backend_decl.


-- 


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

[Bug fortran/36421] Gw.d edit descriptor for integer numbers: Wrong output

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2008-06-05 01:19 
---
The patch in comment#1 fails, printing nothing for a value of zero.  This patch
works OK:

Index: write.c
===
--- write.c (revision 136387)
+++ write.c (working copy)
@@ -368,6 +368,9 @@ write_decimal (st_parameter_dt *dtp, con

   digits = strlen (q);

+  if (f->format == FMT_G)
+m = 0;
+
   /* Select a width if none was specified.  The idea here is to always
  print something.  */

I will commit under simple and obvious rule.


-- 


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

[Bug driver/35916] problem running GCC under Vista with relocated directory

[dannysmith at gcc dot gnu dot org]

--- Comment #12 from dannysmith at gcc dot gnu dot org  2008-06-05 03:46 
---
Subject: Bug 35916

Author: dannysmith
Date: Thu Jun  5 03:45:41 2008
New Revision: 136389

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136389
Log:
PR driver/35916
* mh-mingw (CFLAGS): Add -D__USE_MINGW_ACCESS.

Modified:
trunk/config/ChangeLog
trunk/config/mh-mingw


-- 


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

[Bug fortran/36421] Gw.d edit descriptor for integer numbers: Wrong output

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2008-06-05 05:42 
---
Patch in comment #5 is not right either. There is a dependency on pr36420 which
requires m to be set to -1, not zero. Stay tuned.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||36420


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

[Bug driver/35916] problem running GCC under Vista with relocated directory

[dannysmith at users dot sourceforge dot net]

--- Comment #13 from dannysmith at users dot sourceforge dot net  
2008-06-05 06:23 ---
Closing, as this is fixed on trunk. 


-- 

dannysmith at users dot sourceforge dot net changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug rtl-optimization/36438] New: gcc ICE compiling code with mmx builtin

[davidxl at gcc dot gnu dot org]

Compiling the following code with latest compiler, got ice:

f.i: In function 'void foo(int __vector__*, int)':
f.i:33: internal compiler error: in trunc_int_for_mode, at explow.c:55
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


// f.i:
typedef unsigned short int16;
typedef int __m64 __attribute__ ((__vector_size__ (8), __may_alias__));
typedef long long __v1di __attribute__ ((__vector_size__ (8)));

extern __inline __m64 __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_slli_si64 (__m64 __m, int __count)
{
  return (__m64) __builtin_ia32_psllqi ((__v1di)__m, __count);
}

extern __inline __m64 __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_set_pi16 (short __w3, short __w2, short __w1, short __w0)
{
  return (__m64) __builtin_ia32_vec_init_v4hi (__w0, __w1, __w2, __w3);
}

inline __m64 __attribute__((__always_inline__)) SetS16(int16 a, int16 b, int16
c, int16 d) {
  return _mm_set_pi16(d, c, b, a);
}

void foo(__m64* dest, int n) {

  __m64 mask = SetS16(0x00FF, 0xFF00, 0x, 0x00FF);
  for ( int i = 0 ; i < n; ++i ) {

mask = _mm_slli_si64(mask, 8);
mask = _mm_slli_si64(mask, 8);

*dest = mask;
++dest;
  }
  __builtin_ia32_emms ();
}


-- 
   Summary: gcc ICE compiling code with mmx builtin
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davidxl at gcc dot gnu dot org


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

[Bug rtl-optimization/36438] gcc ICE compiling code with mmx builtin

[davidxl at gcc dot gnu dot org]

--- Comment #1 from davidxl at gcc dot gnu dot org  2008-06-05 06:41 ---

cse1 (RTL) does some expression simplification on the fly such as 

t = x << 4
r = t << 4

==>
r = x << 8

However for mmx shift operation, the mode (V1DI) for the const folding is
illegal -- resulting in ICE. 


-- 

davidxl at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||davidxl at gcc dot gnu dot
   ||org


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