[Bug target/45296] register long double ICE at -O2, -Os, -O3

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-08-17 06:12 ---
The GCC manual says that the register should be call-saved, that isn't the case
in your testcase, so it isn't valid.
But, more importantly, the i387 floating point stack is even more special, as
the st* registers change meaning during compilation - before reg-stack pass
they are just flat 8 registers and the reg-stack pass changes them into real
stacked registers, adding various fixup instructions.  So, what is st(1)
before reg-stack can be at various depths in the i387 stack during the
function.
There is really no way to make this work.  You can use inline-asm with t
resp. u constraints, but that's the only way you can directly influence the
operation of the i387 register stack.


-- 


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

[Bug c/38354] Spurious error: initializer element is not computable at load time

[adam at consulting dot net dot nz]

--- Comment #3 from adam at consulting dot net dot nz  2010-08-17 06:28 
---
AMD64 non-large code model. Functions occupy lower 2GB of the address space.
Cannot compile an array of 32-bit function addresses:

#include stddef.h
#include stdint.h
#include stdio.h

void fn() {
  printf(Hello, World\n);
}

uint32_t computable_at_load_time_a[]={fn};
uint32_t computable_at_load_time_b[]={(uint32_t) (ptrdiff_t) fn};

int main() {
  return 0;
}

$ gcc -m32 computable_at_load_time.c
computable_at_load_time.c:9: warning: initialization makes integer from pointer
without a cast

$ gcc computable_at_load_time.c
computable_at_load_time.c:9: warning: initialization makes integer from pointer
without a cast
computable_at_load_time.c:9: error: initializer element is not computable at
load time
computable_at_load_time.c:9: error: (near initialization for
‘computable_at_load_time_a[0]’)
computable_at_load_time.c:10: error: initializer element is not constant
computable_at_load_time.c:10: error: (near initialization for
‘computable_at_load_time_b[0]’)

The very good reason for wanting to compile a table of 32-bit function pointers
is to halve the data cache footprint of threaded code.


-- 

adam at consulting dot net dot nz changed:

   What|Removed |Added

 CC||adam at consulting dot net
   ||dot nz


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

[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2010-08-17 06:55 ---
Subject: Bug 45186

Author: jakub
Date: Tue Aug 17 06:55:25 2010
New Revision: 163293

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163293
Log:
PR fortran/45186
* trans.c (gfc_annotate_with_location): New function.
(trans_code): Use it.

Modified:
branches/gcc-4_5-branch/gcc/fortran/ChangeLog
branches/gcc-4_5-branch/gcc/fortran/trans.c


-- 


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

[Bug target/45296] register long double ICE at -O2, -Os, -O3

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2010-08-17 06:57 ---
(In reply to comment #3)

 Here's another example of valid gnu99 code:
 
 register long double F80a __asm__(st);
 register long double F80b __asm__(st(1));
 
 void x87_add() {
   F80a += F80b;
 }
 
 int main() {
   return 0;
 }
 
 This does not ICE at -O3. How does one construct this code if you reject st?

The code does not do what you think should be doing:

x87_add:
.LFB0:
.cfi_startproc
flds.LC0(%rip)
flds.LC0(%rip)
faddp   %st, %st(1)
flds.LC0(%rip)
fstp%st(0)
fstp%st(0)
ret

I'm testing following patch:

Index: reginfo.c
===
--- reginfo.c   (revision 163291)
+++ reginfo.c   (working copy)
@@ -798,6 +798,14 @@ fix_register (const char *name, int fixe
 void
 globalize_reg (int i)
 {
+#ifdef STACK_REGS
+  if (IN_RANGE (i, FIRST_STACK_REG, LAST_STACK_REG))
+{
+  error (stack register used for global register variable);
+  return;
+}
+#endif
+
   if (fixed_regs[i] == 0  no_global_reg_vars)
 error (global register variable follows a function definition);



-- 


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

[Bug fortran/45108] Namelist read: Not aborted when reading from STDIN

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2010-08-17 07:54 ---
(In reply to comment #4)
 There was some history regarding legacy codes as the reason why this does not
 error out. ie looping back and trying again was a feature.  I think I may put
 this behind -std=legacy.  It does seem odd the way we are doing this now.

Can you give an example how to use this? For ?, =, and =? this does not
seem to be needed as one does not return to the program. And while I see a
reason for staying in the dialog when an error occurs (i.e. to enter a correct
namelist), immediately returning to the program without setting iostat/=0 or
jumping to the err= label seems odd to me. -- I tried hard but I still fail to
come up with any usage scenario where it makes sense. Unless we find a (even
remotely) useful usage scenario, I would not even enable it with -std=legacy.


-- 


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

[Bug fortran/38936] F2003: ASSOCIATE construct / improved SELECT TYPE (a=expr)

[domob at gcc dot gnu dot org]

--- Comment #9 from domob at gcc dot gnu dot org  2010-08-17 08:20 ---
Subject: Bug 38936

Author: domob
Date: Tue Aug 17 08:20:03 2010
New Revision: 163295

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163295
Log:
2010-08-17  Daniel Kraft  d...@domob.eu

PR fortran/38936
* gfortran.h (struct gfc_association_list): New member `where'.
(gfc_is_associate_pointer) New method.
* match.c (gfc_match_associate): Remember locus for each associate
name matched and do not try to set variable flag.
* parse.c (parse_associate): Use remembered locus for symbols.
* primary.c (match_variable): Instead of variable-flag check for
associate names set it for all such names used.
* symbol.c (gfc_is_associate_pointer): New method.
* resolve.c (resolve_block_construct): Don't generate assignments
to give associate-names their values.
(resolve_fl_var_and_proc): Allow associate-names to be deferred-shape.
(resolve_symbol): Set some more attributes for associate variables,
set variable flag here and check it and don't try to build an
explicitely shaped array-spec for array associate variables.
* trans-expr.c (gfc_conv_variable): Dereference in case of association
to scalar variable.
* trans-types.c (gfc_is_nodesc_array): Handle array association
symbols.
(gfc_sym_type): Return pointer type for association to scalar vars.
* trans-decl.c (gfc_get_symbol_decl): Defer association symbols.
(trans_associate_var): New method.
(gfc_trans_deferred_vars): Handle association symbols.

2010-08-17  Daniel Kraft  d...@domob.eu

PR fortran/38936
* gfortran.dg/associate_1.f03: Extended to test newly supported
features like association to variables.
* gfortran.dg/associate_3.f03: Removed check for illegal change
of associate-name here...
* gfortran.dg/associate_5.f03: ...and added it here.
* gfortran.dg/associate_6.f03: No longer XFAIL'ed.
* gfortran.dg/associate_7.f03: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/associate_7.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/match.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/associate_1.f03
trunk/gcc/testsuite/gfortran.dg/associate_3.f03
trunk/gcc/testsuite/gfortran.dg/associate_5.f03
trunk/gcc/testsuite/gfortran.dg/associate_6.f03


-- 


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

[Bug fortran/38936] F2003: ASSOCIATE construct / improved SELECT TYPE (a=expr)

[domob at gcc dot gnu dot org]

--- Comment #10 from domob at gcc dot gnu dot org  2010-08-17 08:23 ---
This implements association to variables and removes the problems that were
still there with array expressions and bounds.  What's still missing is:

* Association to polymorphic entities
* Association to strings (works partially, but has a lot of problems)
* Association to derived types (should work in principle, but the parser does
not like component references on the associate-names)
* More checks for what is and is not a variable definition context and which
associate names may appear in it


-- 


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

[Bug c/40563] -Wc++-compat does not warn about uninitialized const field in struct

[pzhao at gcc dot gnu dot org]

--- Comment #1 from pzhao at gcc dot gnu dot org  2010-08-17 08:25 ---
Subject: Bug 40563

Author: pzhao
Date: Tue Aug 17 08:25:20 2010
New Revision: 163296

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163296
Log:
/gcc
2010-08-17  Shujing Zhao  pearly.z...@oracle.com

PR c/40563
* c-decl.c (diagnose_uninitialized_cst_member): New function.
(finish_decl): Use it to issue a -Wc++-compat warning about
uninitialized const field in struct or union.

(finish_struct): Use strip_array_types.

/gcc/testsuite
2010-08-17  Shujing Zhao  pearly.z...@oracle.com

PR c/40563
* gcc.dg/Wcxx-compat-20.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/Wcxx-compat-20.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c/40563] -Wc++-compat does not warn about uninitialized const field in struct

[pzhao at gcc dot gnu dot org]

--- Comment #2 from pzhao at gcc dot gnu dot org  2010-08-17 08:28 ---
Fix on trunk


-- 

pzhao at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug c/40563] -Wc++-compat does not warn about uninitialized const field in struct

[pzhao at gcc dot gnu dot org]

--- Comment #3 from pzhao at gcc dot gnu dot org  2010-08-17 08:30 ---
Fix on trunk


-- 

pzhao at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/45303] New: Compile error when not using -ftree-ter

[jobnoorman at gmail dot com]

I have the following program:

main.cpp
--
struct Foo
{
void foobar() {}
};

typedef void (*plain_foobar_t)(Foo*);

int main()
{
asm(push %0;
:
: i((plain_foobar_t)Foo::foobar));
}
--
If I compile this with

g++ -Wno-pmf-conversions main.cpp

I get the following:

main.cpp: In function 'void test()':
main.cpp:12: warning: asm operand 0 probably doesn't match constraints
main.cpp:12: error: impossible constraint in 'asm'

If I compile it using -ftree-ter, like this:

g++ -Wno-pmf-conversions -ftree-ter main.cpp

I do not get any error.

Some info about my system:

$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)

$ uname -a
Linux squatpc 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 06:07:29 UTC 2010
i686 GNU/Linux

I suspect this is a bug, but since I'm not completely sure, I posted this
question on the mailing list
(http://gcc.gnu.org/ml/gcc-help/2010-08/msg00126.html) but I didn't get any
answers.


-- 
   Summary: Compile error when not using -ftree-ter
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jobnoorman at gmail dot com


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

[Bug fortran/45304] New: Functions/subroutines without arguments always treated like varargs

[jakub at gcc dot gnu dot org]

In:
subroutine foo (i, j)
  integer :: i, j, k, l
  k = i
  l = j
  i = i * 10
  i = i + j
  call baz (i)
  i = i + j
end subroutine
subroutine bar (i, j)
  integer :: i, j, k, l
  k = i
  l = j
  i = i * 10
  i = i + j
  call baz (i)
  i = i + j
end subroutine
subroutine fn ()
end subroutine fn
program entryval
  interface bar
subroutine bar (i, j)
  integer :: i, j
end subroutine
  end interface
  integer :: i
  i = 6
  call foo (i, 7)
  i = 8
  call bar (i, 7)
  i = 10
  call foo (i, 7)
  i = 12
  call bar (i, 7)
  call fn ()
end
the calls to MAIN__, fn_ and baz_ are all treated like varargs call (on
x86_64-linux that means movl $0, %eax or xorl %eax, %eax has to precede each
such call).  The patch I'm going to attach fixes at least the callq MAIN__ case
(and should decrease memory consumption by sharing the terminating list nodes).

Unfortunately using if (!typelist) typelist = void_list_node; in
gfc_get_function_type unconditionally isn't right, while it would fix the fn_
case (in -fwhole-file mode we know it has no arguments), for baz_ case which is
external the function really has some arguments, but we don't know them in
gfc_get_function_type.  Is there any way to differentiate between the two cases
(when we know the subroutine/function has no arguments and is defined in the
current TU, or when it is unknown)?
Or better yet, can't we for the really extern decls make up the formal
parameters from the call?  As in, shouldn't:
subroutine foo (i)
  integer :: i
end subroutine foo
program nn
  integer :: i
  real :: f
  call foo (i)
  call foo (f)
  call bar (i)
  call bar (f)
end

warn not just about the argument mismatch to foo, but also about bar?


-- 
   Summary: Functions/subroutines without arguments always treated
like varargs
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug fortran/45304] Functions/subroutines without arguments always treated like varargs

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-08-17 08:59 ---
Created an attachment (id=21500)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21500action=view)
gcc46-pr45304-partial.patch

The partial patch.


-- 


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

[Bug c++/45303] Compile error when not using -ftree-ter

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-08-17 09:21 ---
IMHO this isn't a bug, to simplify that into an integer you really need some
optimizations.  The conversion looks very weird, if you use something saner
like (void *)Foo::foobar, it will even work with -O0.


-- 


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

[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2010-08-17 09:25 ---
Should be fixed for 4.5.2, 4.6 will use a different approach.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.5/4.6 Regression]|[4.6 Regression] Gfortran
   |Gfortran 4.5.0 emits wrong  |4.5.0 emits wrong
   |linenumbers |linenumbers


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

[Bug fortran/45304] Functions/subroutines without arguments always treated like varargs

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2010-08-17 09:34 ---
(In reply to comment #0)
 shouldn't:
  call bar (i)
  call bar (f)
 warn not just about the argument mismatch to foo, but also about bar?

Yes. One should construct the function interface from the argument usage - and
then warn if does not match. Cf. PR 44471.

 Is there any way to differentiate between the two cases (when we know the
 subroutine/function has no arguments and is defined in the current TU, or
 when it is unknown)?

Well, if the interface is known, one can check attr.ifsrc != IFSRC_UNKNOWN -
but I think that's not what you are looking for.

For the TU, one can try to find the global symbol via
  if (gfc_option.flag_whole_file)
{
  gfc_gsymbol *gsym;
  gsym =  gfc_find_gsymbol (gfc_gsym_root, sym-name);
  if (gsym) {  }
Though one needs to be careful if the symbol is an ENTRY and not a real
subroutine, cf. gfc_get_extern_function_decl


-- 


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

[Bug fortran/44471] Wrong call with variadic declaration

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2010-08-17 09:35 ---
Cf. PR 45304 for a partial fix.


-- 


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

[Bug c++/45303] Compile error when not using -ftree-ter

[redi at gcc dot gnu dot org]

--- Comment #2 from redi at gcc dot gnu dot org  2010-08-17 09:38 ---
(In reply to comment #1)
 IMHO this isn't a bug, to simplify that into an integer you really need some
 optimizations.  The conversion looks very weird, if you use something saner

The conversion uses this extension
http://gcc.gnu.org/onlinedocs/gcc/Bound-member-functions.html

 like (void *)Foo::foobar, it will even work with -O0.

Does that cast still use the extension?


-- 


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

[Bug target/45296] register long double ICE at -O2, -Os, -O3

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2010-08-17 09:38 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01226.html .


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2010-
   ||08/msg01226.html
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-17 09:38:43
   date||
   Target Milestone|--- |4.4.6


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[pault at gcc dot gnu dot org]

--- Comment #27 from pault at gcc dot gnu dot org  2010-08-17 09:42 ---
(In reply to comment #25)
 (In reply to comment #21)
  In my opinion revision 162487 is only a partial fix of the problem. If I 
  split
  a modified test case in two files: [...] I still get [...] Bus error
 
 (In reply to comment #24)
  Look at -fdump-tree-original-uid dumps and see if you find the
  same decl with two different UIDs.  I bet you will.
 
 One does. The problem is that when the module is not available.
 
 The variable c (of example in comment 21) created for the main program
 char_array_structure_constructor but if one searches for the symbol (in
 gfc_get_symbol_decl) via
   gsym =  gfc_find_gsymbol (gfc_gsym_root, sym-module);
 the result is NULL as the only gsym which exists in gfc_gsym_root is the one
 for char_array_structure_constructor as there is none for the module. One
 should create a fake gsym for modules, if the module does not exist, and put
 there the variables, functions, and type declarations - such that they can be
 found if needed.
 

Tobias,

This is a very good suggestion. I will have a think about how to implement it
and will come back to you.  It is consistent with what I had in mind to improve
the efficiency of module reading.  ie. read_module proceeds as follows:

(i) On encountering a USE statement, look for the module gsym.  If it does not
exist, use read_module, as at present, to construct the namespace, without any
exclusions or renames;
(ii) In the current scope, create symtrees using the ONLY and the renames and
point to the symbols in the gsym namespace;
(iii) Subsequent USEs of the same module proceed by using the gsym namespace.

I think that Andy was smoking something or was having a whimsical spell when he
wrote module.c.  Whilst it is very elegant, it is unnecessarily disjunct from
the rest of the frontend and could have been done as above.

Cheers

Paul


-- 


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

[Bug c++/45303] Compile error when not using -ftree-ter

[redi at gcc dot gnu dot org]

--- Comment #3 from redi at gcc dot gnu dot org  2010-08-17 09:42 ---
Looking at the diagnostics issued when -pedantic is added, I think the right
conversion is

(void*)(plain_foobar_t)Foo::foobar

That still uses the G++ extension, and doesn't give the asm error even without
optimisation.


-- 


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

[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom

[bernds at gcc dot gnu dot org]

--- Comment #24 from bernds at gcc dot gnu dot org  2010-08-17 09:47 ---
I think that's beginning to look reasonable.  So the problem was that without
alternative 2, such an add would match alternative 3 instead and be split?


-- 


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

[Bug testsuite/45266] [4.6 regression] FAIL: gfortran.dg/array_memcpy_3.f90

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-08-17 09:47 ---
Subject: Bug 45266

Author: rguenth
Date: Tue Aug 17 09:47:44 2010
New Revision: 163297

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163297
Log:
2010-08-17  Richard Guenther  rguent...@suse.de

PR testsuite/45266
* gfortran.dg/array_memcpy_3.f90: Adjust pattern.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/array_memcpy_3.f90


-- 


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

[Bug fortran/44471] Wrong call with variadic declaration

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-08-17 09:51 ---
The #c2 patch is problematic, because build_function_type shares function
types, so setting TYPE_ARG_TYPES on that I'm afraid will affect all functions
with
(...) arguments and the same return type.  So, the arglist needs to be passed
down to gfc_get_function_type or wherever build_function_type is called.
Furthermore, this doesn't help the case of functions that have no arguments
(when we build_function_decl instead gfc_get_extern_function_decl, yet
sym-formal is NULL or gfc_get_extern_function_decl for call noargsfn () ).


-- 


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

[Bug tree-optimization/45301] [4.6 Regression] ICE: SIGSEGV in instantiate_scev_r (tree-scalar-evolution.c:3391) with -O2 -ftree-loop-distribution -fgraphite-identity

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug c++/45303] Compile error when not using -ftree-ter

[jobnoorman at gmail dot com]

--- Comment #4 from jobnoorman at gmail dot com  2010-08-17 10:04 ---
(In reply to comment #1)
 IMHO this isn't a bug, to simplify that into an integer you really need some
 optimizations.  The conversion looks very weird, if you use something saner
 like (void *)Foo::foobar, it will even work with -O0.

I still think it's kind of weird to have an error without optimizations and
none with. Shouldn't an error always be an error, no matter what the
optimizations are?


-- 


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

[Bug target/45299] Dwarf information is wrong with optimised code.

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-08-17 10:06 ---
Sounds like a target bug.
After variable_tracking_main the notes look correct:
(note 88 23 89 2 (var_location array (reg:HI 0 R0 [ pass_through_array ]))
NOTE_INSN_VAR_LOCATION)

(note 89 88 90 2 (var_location size (reg:HI 1 R1 [ pass_through_size ]))
NOTE_INSN_VAR_LOCATION)

(note 90 89 32 2 (var_location i (const_int 0 [0])) NOTE_INSN_VAR_LOCATION)

(insn:TI 32 90 91 2 (set (reg/v:HI 0 R0 [orig:50 sum ] [50])
(mem:HI (reg/f:HI 0 R0 [orig:62 pass_through_array ] [62]) [2
*pass_through_array_1(D)+0 S2 A16])) b45299.c:12 15 {movhi}
 (nil))

(note 91 32 92 2 (var_location pass_through_array (reg/v/f:HI 5 R5 [orig:62
pass_through_array ] [62])) NOTE_INSN_VAR_LOCATION)

(note 92 91 93 2 (var_location array (reg/v/f:HI 5 R5 [orig:62
pass_through_array ] [62])) NOTE_INSN_VAR_LOCATION)

but then reorder_var_tracking_notes drops some notes on the floor and moves
others.  Clearly a target bug.  Dropping on the floor is certainly wrong, and
the moving results in invalid debug info too.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|debug   |target
   Keywords|wrong-debug |


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

[Bug c++/45303] Compile error when not using -ftree-ter

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-08-17 10:16 ---
For inline-asm?  Certainly not.  Consider much simpler:
void foo (void)
{
  int i;
  i = 6;
  asm volatile ( : : i (i));
}
which will work with -O and above, but not for -O0, for exactly the same
reason.


-- 


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

[Bug fortran/45305] New: Array-valued calles to elementals are not simplified

[burnus at gcc dot gnu dot org]

Found when looking at PR fortran/36158

If the argument is an initialization expression and not too large, it should be
expanded. While the following works:
  real, parameteR :: bes(2) = bessel_jn([1,2], 1.0)
  print *, bes
  end

The if is never optimized away for:

if (any (abs(bessel_jn([1,2], 1.0) - bessel_jn([1,2], 1.0)) 
  epsilon(0.0))) 
  call I_do_not_exist()

if (any (abs(bessel_jn(1, 2, 1.0) - bessel_jn([1,2], 1.0)) 
  epsilon(0.0))) 
  call I_do_not_exist()
end

such that one gets linkage errors:
  test.f90:(.text+0x8e): undefined reference to `i_do_not_exist_'
  test.f90:(.text+0x108): undefined reference to `i_do_not_exist_'


-- 
   Summary: Array-valued calles to elementals are not simplified
   Product: gcc
   Version: 4.6.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=45305

[Bug fortran/45305] Array-valued calles to elementals are not simplified

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-08-17 10:19 ---
Note: The middle end also does not see that the expression can be optimized -
and thus fails also to do so for -O3.


-- 


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

[Bug testsuite/45266] [4.6 regression] FAIL: gfortran.dg/array_memcpy_3.f90

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2010-08-17 10:47 ---
Fixed then.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/45303] Compile error when not using -ftree-ter

[jobnoorman at gmail dot com]

--- Comment #6 from jobnoorman at gmail dot com  2010-08-17 10:49 ---
(In reply to comment #5)
 For inline-asm?  Certainly not. Consider much simpler:
 void foo (void)
 {
   int i;
   i = 6;
   asm volatile ( : : i (i));
 }
 which will work with -O and above, but not for -O0, for exactly the same
 reason.

IMHO, your example should always give an error. The i constraint is to be
used for constant integer operands. A variable of type int just isn't
constant, even if GCC is smart enough to optimize the variable away and use a
constant instead. Your example will always work if you make i of type const
int.

I also think there is an important difference between your example and mine:
the expression (plain_foobar_t)Foo::foobar is a constant expression (please
correct me if I'm wrong) and thus should always be allowed when using the i
constraint.


-- 


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

[Bug c++/45049] [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in push_overloaded_decl, at cp/name-lookup.c:2160

[zsojka at seznam dot cz]

--- Comment #5 from zsojka at seznam dot cz  2010-08-17 10:55 ---
Created an attachment (id=21501)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21501action=view)
different testcase

This one has declaration of overloaded functions in function scope. The assert
is the same.

$ gcc pr45049-2.C 
pr45049-2.C: In function 'void foo()':
pr45049-2.C:6:16: internal compiler error: tree check: expected tree that
contains 'decl minimal' structure, have 'tree_list' in push_overloaded_decl, at
cp/name-lookup.c:2160


-- 


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

[Bug middle-end/45306] New: ICE (Segmentation fault) while building PyQt with -fgraphite-identity

[bero at arklinux dot org]

g++ -c -m64 -O2 -fgraphite-identity -DQT_USE_FAST_CONCATENATION
-DQT_USE_FAST_OPERATOR_PLUS -fPIC -Wall -W -D_REENTRANT -DNDEBUG
-DSIP_PROTECTED_IS_PUBLIC -Dprotected=public -DQT_NO_DEBUG -DQT_GUI_LIB
-DQT_CORE_LIB -I. -I/usr/src/ark/BUILD/PyQt-x11-gpl-4.7.3/qpy/QtGui
-I/usr/include/python2.7 -I/usr/lib64/qt4/mkspecs/default
-I/usr/lib64/qt4/include/QtGui -I/usr/lib64/qt4/include/QtCore
-I/usr/lib64/qt4/include -I/usr/X11R6/include -o sipQtGuiQMatrix2x3.o
sipQtGuiQMatrix2x3.cppsipQtGuiQMatrix2x3.cpp: In function ‘PyObject*
meth_QMatrix2x3_setToIdentity(PyObject*, PyObject*)’:
sipQtGuiQMatrix2x3.cpp:158:18: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.


Reducing the optimization level to -O1 -fgraphite-identity still causes a
segfault, but in a different place:

g++ -c -m64 -O1 -fgraphite-identity -DQT_USE_FAST_CONCATENATION
-DQT_USE_FAST_OPERATOR_PLUS -fPIC -Wall -W -D_REENTRANT -DNDEBUG
-DSIP_PROTECTED_IS_PUBLIC -Dprotected=public -DQT_NO_DEBUG -DQT_GUI_LIB
-DQT_CORE_LIB -I. -I/usr/src/ark/BUILD/PyQt-x11-gpl-4.7.3/qpy/QtGui
-I/usr/include/python2.7 -I/usr/lib64/qt4/mkspecs/default
-I/usr/lib64/qt4/include/QtGui -I/usr/lib64/qt4/include/QtCore
-I/usr/lib64/qt4/include -I/usr/X11R6/include -o sipQtGuiQMatrix2x3.o
sipQtGuiQMatrix2x3.cpp
In file included from
/usr/src/ark/BUILD/PyQt-x11-gpl-4.7.3/sip/QtGui/qgenericmatrix.sip:812:0:
/usr/lib64/qt4/include/QtGui/qgenericmatrix.h: In member function ‘void
QGenericMatrixN, M, T::setToIdentity() [with int N = 2, int M = 3, T =
double]’:
/usr/lib64/qt4/include/QtGui/qgenericmatrix.h:168:27: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.


-- 
   Summary: ICE (Segmentation fault) while building PyQt with -
fgraphite-identity
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bero at arklinux dot org


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

[Bug middle-end/45306] ICE (Segmentation fault) while building PyQt with -fgraphite-identity

[bero at arklinux dot org]

--- Comment #1 from bero at arklinux dot org  2010-08-17 11:13 ---
Created an attachment (id=21502)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21502action=view)
Preprocessed source


-- 


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

[Bug middle-end/45306] ICE (Segmentation fault) while building PyQt with -fgraphite-identity

[bero at arklinux dot org]

--- Comment #2 from bero at arklinux dot org  2010-08-17 11:14 ---
Seems to work on 32-bit x86


-- 

bero at arklinux dot org changed:

   What|Removed |Added

  GCC build triplet||x86_64-pc-linux-gnu
   GCC host triplet||x86_64-pc-linux-gnu
 GCC target triplet||x86_64-pc-linux-gnu
  Known to fail||4.5.1


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

[Bug libgomp/45192] OpenMP fails in DLLs

[john at quivinco dot com]

--- Comment #4 from john at quivinco dot com  2010-08-17 11:57 ---
The cause has been isolated to a problem with my C code. The DLL now works on
Windows XP, but not Vista 64!?


-- 

john at quivinco dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/45081] [4.3/4.4/4.5/4.6 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:4208

[pault at gcc dot gnu dot org]

--- Comment #6 from pault at gcc dot gnu dot org  2010-08-17 12:07 ---
(In reply to comment #1)
 Confirmed as a regression: it compiles with 4.2.4 (ppc-darwin), gives an ICE
 with 4.3.4, 4.4.2, 4.5.0 and trunk.
 

You did not mark the PR as confirmed  :-)

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-17 12:07:05
   date||


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

[Bug target/45296] register long double ICE at -O2, -Os, -O3

[uros at gcc dot gnu dot org]

--- Comment #7 from uros at gcc dot gnu dot org  2010-08-17 12:25 ---
Subject: Bug 45296

Author: uros
Date: Tue Aug 17 12:25:24 2010
New Revision: 163303

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163303
Log:
PR target/45296
* reginfo.c (globalize_reg): Reject stack registers.

testsuite/ChangeLog:

PR target/45296
* gcc.target/i386/pr45296.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr45296.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/reginfo.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/45307] New: Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

[hubicka at gcc dot gnu dot org]

Compilling:
 ./g++ -O2 ~/mozalloc.ii  -S -m32
gives me:
.type   _GLOBAL__I_moz_free, @function
_GLOBAL__I_moz_free:
.LFB58:
.cfi_startproc
rep
ret
.cfi_endproc
.LFE58:
.size   _GLOBAL__I_moz_free, .-_GLOBAL__I_moz_free
.section.ctors,aw,@progbits
.align 4
.long   _GLOBAL__I_moz_free
.local  _ZN7mozillaL8fallibleE
.comm   _ZN7mozillaL8fallibleE,1,1

I.e. an empty constructor function that can be eliminated and also 
local var   _ZN7mozillaL8fallibleE that is not used at all.
The reason is that constructor in .optimized stage looks like:
(static initializers for /mozilla-central/memory/mozalloc/mozalloc.cpp) ()
{
bb 2:
  fallible = {};
  return;

}

that later expands to nothing.  If we optimized this away during early opts I
already have patch that makes it easy to eliminate all global ctors/dtors that
are known to be pure.

Honza


-- 
   Summary: Stores expanding to no RTL not removed by tree
optimizers, Empty ctors/dtors not eliminated
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hubicka at gcc dot gnu dot org


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

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

[hubicka at gcc dot gnu dot org]

--- Comment #1 from hubicka at gcc dot gnu dot org  2010-08-17 12:38 ---
Created an attachment (id=21503)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21503action=view)
testcase.


-- 


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

[Bug c++/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-08-17 12:49 ---
It's the FEs job really.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org
  Component|middle-end  |c++


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

[Bug fortran/45308] New: DATE_AND_TIME does _not_ black-pad strings

[burnus at gcc dot gnu dot org]

The following program prints (with gfortran, NAG f95, ifort) something like
  20100817145358.302aa
expected, the number is black padded, i.e.
  20100817145659.787
(as g95, pathf95, openf95 do)

The problem was reported at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/6a2a3804f0f27a65#


CHARACTER(LEN=36) :: date, time

date = ''
time = ''

CALL DATE_AND_TIME(date, time)

print *, date, time

if (index(date, 'a') /= 0 .or. index(time, 'a') /= 0) 
  call abort ()
end


-- 
   Summary: DATE_AND_TIME does _not_ black-pad strings
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  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=45308

[Bug libstdc++/45300] in cstdio/cstdlib keyword restrict is used instead of __restrict

[mikpe at it dot uu dot se]

--- Comment #11 from mikpe at it dot uu dot se  2010-08-17 13:01 ---
Should libstdc++-v3/include/{c_global,c_std}/cwchar also get the restrict -
__restrict treatment?


-- 


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

[Bug libstdc++/45300] in cstdio/cstdlib keyword restrict is used instead of __restrict

[paolo dot carlini at oracle dot com]

--- Comment #12 from paolo dot carlini at oracle dot com  2010-08-17 13:07 
---
Sure, I forgot to grep, was in an hurry because I'm leaving for a few days of
vacations, but will do it momentarily.


-- 


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

[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

[iains at gcc dot gnu dot org]

--- Comment #49 from iains at gcc dot gnu dot org  2010-08-17 13:13 ---
the patch attached to 

http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01249.html

solves the problem by suppression of the epilogues in _eh_frames;
 the patch might be an incomplete solution to darwin-dwarf2 issues.


-- 


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

[Bug fortran/45308] DATE_AND_TIME does _not_ black-pad strings

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-08-17 13:13 ---
Created an attachment (id=21504)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21504action=view)
gcc46-pr45308.patch

Untested fix.


-- 


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

[Bug rtl-optimization/43494] [4.4/4.5/4.6 Regression] Overlooked dependency causes wrong scheduling, wrong code

[bernds at gcc dot gnu dot org]

--- Comment #22 from bernds at gcc dot gnu dot org  2010-08-17 13:14 ---
(In reply to comment #19)
 x_addr is a VALUE that has no locs:

That happens because it's an autoincrement, and cselib_subst_to_values just
creates an empty value.

It seems to me that we simply need to add a VALUE case to rtx_varies_p.  Can
you test that?


-- 


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

[Bug libstdc++/45300] in cstdio/cstdlib keyword restrict is used instead of __restrict

[paolo at gcc dot gnu dot org]

--- Comment #13 from paolo at gcc dot gnu dot org  2010-08-17 13:16 ---
Subject: Bug 45300

Author: paolo
Date: Tue Aug 17 13:15:41 2010
New Revision: 163304

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163304
Log:
2010-08-17  Paolo Carlini  paolo.carl...@oracle.com

PR libstdc++/45300
* include/c_std/cwchar: Replace 'restrict' - '__restrict'.
* include/c_global/cwchar: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/c_global/cwchar
trunk/libstdc++-v3/include/c_std/cwchar


-- 


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

[Bug fortran/45308] [F2003] DATE_AND_TIME does _not_ black-pad strings

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2010-08-17 13:19 ---
(In reply to comment #1)
 Created an attachment (id=21504)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21504action=view) [edit]
 gcc46-pr45308.patch

That's quick.

However, I wonder whether one should modify more, e.g. if SNPRINTF is
available, writing directly to __time instead of writing to a temporary - and
then call memset to pad the rest instead of copying the data. On the other
hand, date_and_time does not seem to be that time critical.

(Additionally, one should update the F95 comment before the function to match
better that one now used the F2003 version which does padding.)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|DATE_AND_TIME does _not_|[F2003] DATE_AND_TIME does
   |black-pad strings   |_not_ black-pad strings


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

[Bug fortran/45308] [F2003] DATE_AND_TIME does _not_ black-pad strings

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2010-08-17 13:23 ---
(Add lost mid-air collision text)

As Clive Page notes in c.l.f, the non-padding is required for F95 while the
padding is required in F2003 - though, I would not care for the F95 version and
always pad.

(F95, 13.14.27: DATE [...] Its leftmost 8 characters are assigned a value of
the form CCYYMMDD [...] If there is no date available, they are assigned
blanks.)

(F2003 -- and F2008, 13.7.44: DATE [...] It is assigned a value of the form
CCYYMMDD, [...] If there is no date available, DATE is assigned all blanks.)


-- 


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

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

[hubicka at gcc dot gnu dot org]

--- Comment #3 from hubicka at gcc dot gnu dot org  2010-08-17 13:34 ---
Adding Mark and Jason to CC then, but Jakub seems right about -Wuninitialized
warnings.


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at redhat dot com,
   ||mark at codesourcery dot com
  Component|c++ |middle-end


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

[Bug fortran/45308] [F2003] DATE_AND_TIME does _not_ black-pad strings

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-08-17 13:50 ---
Created an attachment (id=21505)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21505action=view)
gcc46-pr45308.patch

Updated patch.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #21504|0   |1
is obsolete||
 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug fortran/45309] New: [4.6 Regression] gfortran.dg/trim_optimize_1.f90 has 4 memmove

[burnus at gcc dot gnu dot org]

The test case for PR 40628 has:

! { dg-final { scan-tree-dump-times memmove 2 original } }

However, the original dump has:

__builtin_memmove ((void *) a, (void *) pstr.0, 3);
__builtin_memmove ((void *) a, (void *) pstr.0, (integer(kind=8)) D.1558);
__builtin_memmove ((void *) c, (void *) pstr.2, 4);
__builtin_memmove ((void *) c, (void *) pstr.2, (integer(kind=8)) D.1566);

For some reasons, regtestings FAILs for me but not for Daniel K (who never the
less has 4 memmoves) - also gcc-testresults shows no failures.

Please check whether 4 or 2 memove are correct.


-- 
   Summary: [4.6 Regression] gfortran.dg/trim_optimize_1.f90 has 4
memmove
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  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=45309

[Bug fortran/45309] [4.6 Regression] gfortran.dg/trim_optimize_1.f90 has 4 memmove

[domob at gcc dot gnu dot org]

--- Comment #1 from domob at gcc dot gnu dot org  2010-08-17 14:14 ---
Confirmed (from my point of view)


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||domob at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-17 14:14:32
   date||


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

[Bug middle-end/45306] ICE (Segmentation fault) while building PyQt with -fgraphite-identity

[bero at arklinux dot org]

--- Comment #3 from bero at arklinux dot org  2010-08-17 14:15 ---
Ignore the previous comment -- it working on x86 (32bit) was caused by not
having -fgraphite-identity in the CFLAGS there. It crashes everywhere.


-- 


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

[Bug target/45296] register long double ICE at -O2, -Os, -O3

[uros at gcc dot gnu dot org]

--- Comment #8 from uros at gcc dot gnu dot org  2010-08-17 14:22 ---
Subject: Bug 45296

Author: uros
Date: Tue Aug 17 14:22:16 2010
New Revision: 163306

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163306
Log:
PR target/45296
* reginfo.c (globalize_reg): Reject stack registers.

testsuite/ChangeLog:

PR target/45296
* gcc.target/i386/pr45296.c: New test.


Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr45296.c
  - copied unchanged from r163303,
trunk/gcc/testsuite/gcc.target/i386/pr45296.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/reginfo.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/45296] register long double ICE at -O2, -Os, -O3

[uros at gcc dot gnu dot org]

--- Comment #9 from uros at gcc dot gnu dot org  2010-08-17 14:26 ---
Subject: Bug 45296

Author: uros
Date: Tue Aug 17 14:25:52 2010
New Revision: 163307

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163307
Log:
PR target/45296
* reginfo.c (globalize_reg): Reject stack registers.

testsuite/ChangeLog:

PR target/45296
* gcc.target/i386/pr45296.c: New test.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr45296.c
  - copied unchanged from r163303,
trunk/gcc/testsuite/gcc.target/i386/pr45296.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/reginfo.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/45296] register long double ICE at -O2, -Os, -O3

[ubizjak at gmail dot com]

--- Comment #10 from ubizjak at gmail dot com  2010-08-17 14:27 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.4.6   |4.4.5


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

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

[mmitchel at gcc dot gnu dot org]

--- Comment #4 from mmitchel at gcc dot gnu dot org  2010-08-17 14:41 
---
I have no object to the FE removing trivial code if it can do so -- but I also
think that the middle-end should be able to deduce that a function is pure
later in the process and eliminate it then.

I don't understand Richard's comment about -Wuninitialized; I don't see any
comments from Jakub in this PR.


-- 


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

[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom

[hjl dot tools at gmail dot com]

--- Comment #25 from hjl dot tools at gmail dot com  2010-08-17 14:47 
---
(In reply to comment #24)
 I think that's beginning to look reasonable.  So the problem was that without
 alternative 2, such an add would match alternative 3 instead and be split?
 

Yes.


-- 


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

[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[jv244 at cam dot ac dot uk]

-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

   Target Milestone|4.5.2   |4.6.0


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

[Bug c++/45310] New: ICE: verify_stmts failed: Dead STMT in EH table with -O1 -fnon-call-exceptions

[zsojka at seznam dot cz]

Command line:
$ gcc -O1 -fnon-call-exceptions testcase.C

Compiler output:
$ gcc -O1 -fnon-call-exceptions testcase.C
testcase.C: In function 'void foo()':
testcase.C:23:1: error: Dead STMT in EH table
# VUSE .MEM_10
D.2166_8 = *a_7;

testcase.C:23:1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

Tested revisions:
r163261 - crash
r153685 - crash
4.4 r149995 - crash


-- 
   Summary: ICE: verify_stmts failed: Dead STMT in EH table with -O1
-fnon-call-exceptions
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug c++/45310] ICE: verify_stmts failed: Dead STMT in EH table with -O1 -fnon-call-exceptions

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-08-17 15:49 ---
Created an attachment (id=21506)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21506action=view)
reduced testcase


-- 


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

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-08-17 15:57 ---
I also wonder why we can't remove such stores based on ipa-reference analysis.

Reduced testcase:

struct __attribute__ ((visibility (default))) fallible_t { };
const fallible_t fallible = fallible_t();


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|rguenther at suse dot de|rguenth at gcc dot gnu dot
   ||org
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2010-08-17 15:57:59
   date||


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

[Bug fortran/45016] Support pointer assignment with bound-spec; wrong bounds for pointer assignment

[domob at gcc dot gnu dot org]

--- Comment #3 from domob at gcc dot gnu dot org  2010-08-17 16:00 ---
Also working on this, as suggested by Tobias in PR 29785 maybe this can be done
together.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |domob at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-17 16:00:55
   date||


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

[Bug middle-end/45310] ICE: verify_stmts failed: Dead STMT in EH table with -O1 -fnon-call-exceptions

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-08-17 16:03 ---
Confirmed.  Works on the 4.1 branch (there is no such verification).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c++ |middle-end
 Ever Confirmed|0   |1
  Known to fail|4.4.5 4.5.2 4.6.0   |4.3.5 4.4.5 4.5.2 4.6.0
   Last reconfirmed|-00-00 00:00:00 |2010-08-17 16:03:12
   date||


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

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

[hubicka at gcc dot gnu dot org]

--- Comment #6 from hubicka at gcc dot gnu dot org  2010-08-17 16:42 ---
We are not removing write only vars because richi told me that there is no
convenient way to tell aliasing that variable is write only.  It is easy to
detect for me, but bit harder to get rid of them, since at IPA pass I can't
modify body so I need to pass it down to local optimization and remove only
then.
I guess I will add the feature (detecting them and removing the statements in
transform pass). It just seemed not worth the hassle when I was looking into it
originally.

Concerning Mark's question, we briefly discussed this on IRC

So we now have

1) C++ frontend probably should not produce static constructor for empty struct
at all
2) We should be able to get rid of writes to empty structs in backend
3) Middle end should take away pure constructors
4) We should be able to optimize away write only variables

I will work on 3) and probably 4) later.

Mark, why C++ is not doing 1)? 


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|enhancement |normal
   Keywords|missed-optimization |


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

[Bug fortran/45309] [4.6 Regression] gfortran.dg/trim_optimize_1.f90 has 4 memmove

[mikael at gcc dot gnu dot org]

--- Comment #2 from mikael at gcc dot gnu dot org  2010-08-17 16:44 ---
I'm somewhat out of date (revision 163221) and I only see 2 memmoves.
I don't see any string_trim either. 
Note that the -O option changes the original tree dump. 
I thought it only impacted later dumps.


-- 


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

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

[hubicka at gcc dot gnu dot org]

--- Comment #7 from hubicka at gcc dot gnu dot org  2010-08-17 16:45 ---
oops, I've left IRC sentence unfinished.  At IRC Richi told that FEs should not
ever produce stores to empty structs at first place, so we don't need middle
end logic of taking them away.  Jakub thought that those stores are left to
keep -Wuninitialized safe.


-- 


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

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2010-08-17 16:53 ---
Perhaps related to PR43075, before that last commit there genericization was
removing empty struct assignments.


-- 


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

[Bug fortran/45309] [4.6 Regression] gfortran.dg/trim_optimize_1.f90 has 4 memmove

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2010-08-17 17:06 ---
(In reply to comment #2)
 Note that the -O option changes the original tree dump. 
 I thought it only impacted later dumps.

OK, with -O I also only get

(MEM[(c_char * {ref-all})b] = MEM[(c_char * {ref-all})abcd];, (void *) b;);
__builtin_memmove ((void *) a, (void *) b, 3);
__builtin_memmove ((void *) c, (void *) a, 3);

Though, it does not explain the failures which I saw:

FAIL: gfortran.dg/trim_optimize_1.f90  -O0  scan-tree-dump-times original
memmove 2
FAIL: gfortran.dg/trim_optimize_1.f90  -O0  scan-tree-dump-times original
string_trim 0

(Ditto for -O1 etc., but the -O in dg-options overrides the -O... options
from dg.exp thus one runs the program 8 times with the same options.)

However, currently,
  make check-gfortran RUNTESTFLAGS='dg.exp=trim_optimize_1.f90
shows no failures. Thus, I close it as INVALID. Hopefully, it will continue to
work.

Mikael, thanks for the analysis!


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug libgomp/45311] New: OpenMP a DLL cannot load libgomp on Windows Vista u64

[john at quivinco dot com]

I have a DLL which now works fine on Windows XP SP3 build with mingw GCC 4.4.0.
However on Vista my DLL will not even get to DllMain, so I assume the libgomp
is not being loaded successfully.

Do I need a Vista compatible build of gomp? Is there a difference in the msvcrt
maybe?


-- 
   Summary: OpenMP a DLL cannot load libgomp on Windows Vista u64
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john at quivinco dot com


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

[Bug c++/45293] ICE in iterative_hash_template_arg, at cp/pt.c:1589

[fang at csl dot cornell dot edu]

--- Comment #4 from fang at csl dot cornell dot edu  2010-08-17 17:26 
---
Created an attachment (id=21507)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21507action=view)
delta reduced, day 2

Slowly being reduced by delta, day 2 ...


-- 


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

[Bug fortran/29785] Fortran 2003: POINTER Rank Remapping

[domob at gcc dot gnu dot org]

--- Comment #7 from domob at gcc dot gnu dot org  2010-08-17 17:38 ---
Tobias (and all):  Do you think we should check for the size of data-target
shall not be less than the size of data-pointer-object at runtime when
-fcheck=bounds is given?


-- 


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

[Bug c++/45293] ICE in iterative_hash_template_arg, at cp/pt.c:1589

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2010-08-17 17:41 ---
It is caused by revision 145440:

http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00060.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||dseketel at redhat dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-17 17:41:03
   date||


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

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

[jason at gcc dot gnu dot org]

--- Comment #9 from jason at gcc dot gnu dot org  2010-08-17 17:41 ---
But that change was largely reversed by the fix for PR 43787.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|jason at redhat dot com |


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

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

[mmitchel at gcc dot gnu dot org]

--- Comment #10 from mmitchel at gcc dot gnu dot org  2010-08-17 17:50 
---
The problem with -Wuninitialized might be the same problem I've been
sermonizing about for years -- we're trying to issue sensible warnings from our
optimizers, which means that as the optimizers are perturbed, the set of
warnings will change in various ways.  But, there's no reason for
-Wuninitialized to warn about a use of an empty structure, so I don't see why
removing the stores is unreasonable.

I certainly think that the front-end could safely optimize away such stores,
and that it would be reasonably easy to do so in the trivial cases. 
(Obviously, the optimizers would be responsible for more complex cases where
things are not perhaps immediately obvious to the front-end.)  I don't think
there's any reason we don't do that in the front-end; it's just something we
haven't done.


-- 


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

[Bug fortran/45304] Functions/subroutines without arguments always treated like varargs

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-08-17 18:06 ---
Subject: Bug 45304

Author: jakub
Date: Tue Aug 17 18:06:18 2010
New Revision: 163311

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163311
Log:
PR fortran/45304
* trans-decl.c (build_library_function_decl_1): Chain on
void_list_node instead of creating a new TREE_LIST.
* trans-intrinsic.c (gfc_get_intrinsic_lib_fndecl): Likewise.
* trans-types.c (gfc_get_function_type): Likewise.  Set
typelist to void_list_node for the main program.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans-types.c


-- 


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

[Bug fortran/45308] [F2003] DATE_AND_TIME does _not_ black-pad strings

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-08-17 18:08 ---
Subject: Bug 45308

Author: jakub
Date: Tue Aug 17 18:08:05 2010
New Revision: 163312

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163312
Log:
PR fortran/45308
* intrinsics/date_and_time.c (date_and_time): Pass
__{zone,time,date}_len
instead of {ZONE,TIME,DATE}_LEN as second argument to fstrcpy.  Drop
asserts.  Adjust comment to the F2003 wording from the F95 wording.

* gfortran.dg/pr45308.f03: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr45308.f03
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/intrinsics/date_and_time.c


-- 


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

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

[jason at gcc dot gnu dot org]

--- Comment #11 from jason at gcc dot gnu dot org  2010-08-17 18:09 ---
There are two issues here:

1) expand_static_init decides whether a variable needs static initialization
before gimplification, and
2) Richard's MEM_REF-related change to cp_gimplify_expr caused us to stop
removing the copy in this example.

It sounds like if we fix #2 then the patch Honza mentions having should do the
trick.  I'll do that.


-- 


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

[Bug c/45312] New: GCC 4.4.4 miscompiles (?) the Linux kernel, makes kernel unusable

[t dot artem at mailcity dot com]

This bug is described here: https://bugzilla.kernel.org/show_bug.cgi?id=16612

In two words: this patch:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.35.y.git;a=commitdiff;h=568132624386f53e87575195d868db9afb2e9316

makes kernel 2.6.35.2 unusable on my PC.

The particular file that gets miscompiled is this one:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.35.y.git;a=blob;f=arch/x86/include/asm/cmpxchg_32.h;h=c1cf59d72f096e3825010681889eb6625c662d16;hb=HEAD

GCC 4.5.1 is not affected by this bug.


-- 
   Summary: GCC 4.4.4 miscompiles (?) the Linux kernel, makes kernel
unusable
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: t dot artem at mailcity dot com


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

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

[jason at gcc dot gnu dot org]

--- Comment #12 from jason at gcc dot gnu dot org  2010-08-17 18:18 ---
Actually, Richard's change didn't affect this; we were already missing it
because of the complex interoperation of cp_gimplify_expr and
gimplify_modify_expr_rhs.


-- 


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

[Bug fortran/29785] Fortran 2003: POINTER Rank Remapping

[mikael at gcc dot gnu dot org]

--- Comment #8 from mikael at gcc dot gnu dot org  2010-08-17 18:21 ---
(In reply to comment #7)
 Tobias (and all):  Do you think we should check for the size of data-target
 shall not be less than the size of data-pointer-object at runtime when
 -fcheck=bounds is given?
 

Yes.
The existing bounds-check code checks that we don't access an array beyond what
its descriptor permits. 
We have to check that we don't create a descriptor that has bounds beyond the
array limits, thus by-passing the bounds-check code.


-- 


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

[Bug c/45312] GCC 4.4.4 miscompiles (?) the Linux kernel, makes kernel unusable

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-08-17 18:24 ---
That is not a proper bug report, see http://gcc.gnu.org/bugs.html for what
needs to be provided.


-- 


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

[Bug tree-optimization/45313] New: [graphite] interchange-7.c is miscompiled

[spop at gcc dot gnu dot org]

In the graphite branch interchange-7.c is miscompiled with the following flags:

$ gcc -O3 -fgraphite  -fno-loop-block -floop-strip-mine -floop-interchange
interchange-7.c
$ ./a.out 
Aborted


-- 
   Summary: [graphite] interchange-7.c is miscompiled
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: spop at gcc dot gnu dot org
ReportedBy: spop at gcc dot gnu dot org


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

[Bug tree-optimization/45313] [graphite] interchange-7.c is miscompiled

[spop at gcc dot gnu dot org]

-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-17 19:00:25
   date||


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

[Bug c/45312] GCC 4.4.4 miscompiles (?) the Linux kernel, makes kernel unusable

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-08-17 19:07 ---
In particular, first bisect between object files compiled without/with the
patch to find one compilation unit where the problem is, provide preprocessed
source for it (both without and with the patch) and gcc command line options
used to compile that.


-- 


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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

--- Comment #80 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2010-08-17 20:17 ---
Comment #79:

-mpreferred-stack-boundary=2 adheres to the sysv ABI but it doesn't adhere to
the Linux ABI (that requires 16-byte alignment), so if you compile anything
with -mpreferred-stack-boundary=2, it may crash when entering other dynamic
libraries.

-mstackrealign does the right thing, it realigns the stack when needed, but
keeps it 16-byte aligned on function output. It should be used.

I would be nice if gcc developers made -mstackrealign default (with an option
to turn it off for scientists who need maximum performance and don't care about
ABI) so that this ABI madness will finally end when distributions get
recompiled with it.


-- 


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

[Bug middle-end/45229] gcc.c-torture/execute/20000412-4.c ICEs with -fgraphite-identity

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2010-08-17 20:41 ---
Subject: Bug 45229

Author: spop
Date: Tue Aug 17 20:41:26 2010
New Revision: 163319

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163319
Log:
Fix PR45229: gcc.c-torture/execute/2412-4.c ICEs with -fgraphite-identity.

2010-08-17  Sebastian Pop  sebastian@amd.com

PR middle-end/45229
* graphite-sese-to-poly.c (rewrite_cross_bb_scalar_deps): Do not
handle GIMPLE_CALLs with no LHS.

Modified:
branches/graphite/gcc/ChangeLog.graphite
branches/graphite/gcc/graphite-sese-to-poly.c


-- 


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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[jasmin at revisionfx dot com]

--- Comment #81 from jasmin at revisionfx dot com  2010-08-17 21:03 ---
(In reply to comment #80)
 Comment #79:
 

 -mstackrealign does the right thing, it realigns the stack when needed, but
 keeps it 16-byte aligned on function output. It should be used.
  

I don't have that option (-mstackrealign)
It's available in gcc linux from what released version?


-- 


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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

--- Comment #82 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2010-08-17 21:17 ---
-mstackrealign is available from gcc 4.5.0. For gcc 4.4 you can use my patch
GCC-4.4.1-ALIGN-PATCH from this bugzilla or H.J.Lu's last patch. It basically
does the same as -mstackrealign (but it doesn't add a command line option, it
sets this behavior as default).


-- 


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

[Bug middle-end/45314] New: ICE: error: in remove_unreachable_handlers, at tree-sh.c:3294 with -O2 -floop-interchange

[bero at arklinux dot org]

i586-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../..  -I../../librender
-I../../libcore -I../../libcore/asobj -I../../libcore/asobj/flash
-I../../libcore/swf -I../../libcore/abc -I../../libcore/parser -I../../libbase
-I../../libmedia -I../../libsound -I../../libltdl -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include-pthread  -D__STDC_CONSTANT_MACROS
-I/usr/include -O2 -floop-interchange -c -o VM.lo VM.cpp
VM.cpp: In member function 'gnash::VM::RNG gnash::VM::randomNumberGenerator()
const':
VM.cpp:126:1: internal compiler error: in remove_unreachable_handlers, at
tree-eh.c:3294
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.


-- 
   Summary: ICE: error: in remove_unreachable_handlers, at tree-
sh.c:3294 with -O2 -floop-interchange
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bero at arklinux dot org
 GCC build triplet: i586-pc-linux-gnu
  GCC host triplet: i586-pc-linux-gnu
GCC target triplet: i586-pc-linux-gnu


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

[Bug middle-end/45314] ICE: error: in remove_unreachable_handlers, at tree-sh.c:3294 with -O2 -floop-interchange

[bero at arklinux dot org]

--- Comment #1 from bero at arklinux dot org  2010-08-17 22:27 ---
Created an attachment (id=21508)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21508action=view)
Preprocessed source


-- 


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

[Bug c++/45315] New: ICE: tree check: expected aggr_init_expr, have call_expr in build_value_init, at cp/init.c:317

[zsojka at seznam dot cz]

Compiler output:
$ gcc testcase.C
testcase.C: In member function 'void Banonymous ::foo()':
testcase.C:10:18: internal compiler error: tree check: expected aggr_init_expr,
have call_expr in build_value_init, at cp/init.c:317
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

Tested revisions:
r163261 - crash
4.5 r160526 - crash
4.4 r160770 - crash
4.4 r149995 - crash


-- 
   Summary: ICE: tree check: expected aggr_init_expr, have call_expr
in build_value_init, at cp/init.c:317
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz


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

[Bug c++/45315] ICE: tree check: expected aggr_init_expr, have call_expr in build_value_init, at cp/init.c:317

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-08-17 23:32 ---
Created an attachment (id=21509)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21509action=view)
reduced testcase

I believe the code is valid


-- 


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

[Bug c++/45315] [4.4/4.5/4.6 Regression] ICE: tree check: expected aggr_init_expr, have call_expr in build_value_init, at cp/init.c:317

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-18 00:49:20
   date||
Summary|ICE: tree check: expected   |[4.4/4.5/4.6 Regression]
   |aggr_init_expr, have|ICE: tree check: expected
   |call_expr in|aggr_init_expr, have
   |build_value_init, at|call_expr in
   |cp/init.c:317   |build_value_init, at
   ||cp/init.c:317


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

[Bug middle-end/45316] New: [4.6 Regression] ICE: verify_flow_info failed: BB 3 can not throw but has an EH edge with -O1 -ftree-pre -fnon-call-exceptions

[zsojka at seznam dot cz]

Command line:
$ gcc -O1 -ftree-pre -fnon-call-exceptions testcase.C

Compiler output:
$ gcc -O1 -ftree-pre -fnon-call-exceptions testcase.C 
testcase.C: In function 'void foo()':
testcase.C:21:1: error: BB 3 can not throw but has an EH edge
testcase.C:21:1: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

Tested revisions:
r163261 - crash
r161659 - crash
r161170 - OK
4.5 r160526 - OK


-- 
   Summary: [4.6 Regression] ICE: verify_flow_info failed: BB 3 can
not throw but has an EH edge with -O1 -ftree-pre -fnon-
call-exceptions
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug middle-end/45316] [4.6 Regression] ICE: verify_flow_info failed: BB 3 can not throw but has an EH edge with -O1 -ftree-pre -fnon-call-exceptions

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-08-18 01:45 ---
Created an attachment (id=21510)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21510action=view)
reduced testcase


-- 


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

[Bug c/45286] kact.sa_restorer = restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64

[vapier at gentoo dot org]

--- Comment #17 from vapier at gentoo dot org  2010-08-18 03:23 ---
thanks for the shorter test case.  could you explain why a 64bit load is used
though ?  if you're looking for the address of something, and you're not going
through a pointer to that location, why isnt it a normal lea with a relocation
?

your short test case though doesnt show exactly the same as ours ... we arent
going through the GOT or have a relocation on the load ...

as for compiling glibc as it wasnt meant to be, that's pretty vague.  i think
the only way to get a glibc the way it is _meant_ to be compiled is by getting
a binary package from drepper himself.  and even then, who knows.  for a
project that doesnt support cross-compiling, doesnt support static linking,
doesnt support a good number of architectures, it's no wonder eglibc exists.  i
hate to point out that Gentoo was doing SSP/PIE light years before Redhat and
glibc/gcc, and that was unsupported for a long time too.  now it's a stock
part of glibc ...


-- 


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