[Bug target/45234] [4.4 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca

[truedfx at gentoo dot org]

--- Comment #14 from truedfx at gentoo dot org  2010-08-10 05:59 ---
In the original code, the patch fixes the problem too. Thanks again.


-- 


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

[Bug bootstrap/45206] [4.6 regression] ICE in ix86_expand_epilogue compiling libgcc

[ebotcazou at gcc dot gnu dot org]

--- Comment #6 from ebotcazou at gcc dot gnu dot org  2010-08-10 05:49 
---
> Does anyone know which combination of recent commits is causing this problem?

The set of RTH's patches.  Configure --with-tune=i686 to work around it.


-- 


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

[Bug c++/45245] Segmentation Fault

[gekus at aha dot ru]

--- Comment #1 from gekus at aha dot ru  2010-08-10 05:16 ---
Created an attachment (id=21445)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21445&action=view)
Preprocessed file


-- 


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

[Bug c++/45245] New: Segmentation Fault

[gekus at aha dot ru]

g++ -c -Wno-multichar -fexceptions -g3 -D_MT -DNDEBUG -O3
-funsafe-loop-optimizations -Wunsafe-loop-optimizations -static -v -save-temps
-DTESTINETD -fnon-call-exceptions -I. -I../Common -o ./GNURelease/DelaydSQL.o
DelaydSQL.cpp
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /usr/src/gcc-4.4.3/configure --prefix=/usr --libdir=/usr/lib64
Thread model: posix
gcc version 4.4.3 (GCC)
COLLECT_GCC_OPTIONS='-c' '-Wno-multichar' '-fexceptions' '-g3' '-D_MT'
'-DNDEBUG' '-O3' '-funsafe-loop-optimizations' '-Wunsafe-loop-optimizations'
'-static' '-v' '-save-temps' '-DTESTINETD' '-fnon-call-exceptions' '-I.'
'-I../Common' '-o' './GNURelease/DelaydSQL.o' '-mtune=generic'
 /usr/libexec/gcc/x86_64-unknown-linux-gnu/4.4.3/cc1plus -E -quiet -v -I.
-I../Common -dD -D_GNU_SOURCE -D_MT -DNDEBUG -DTESTINETD DelaydSQL.cpp
-mtune=generic -Wno-multichar -Wunsafe-loop-optimizations -fexceptions
-funsafe-loop-optimizations -fnon-call-exceptions -g3 -fworking-directory -O3
-fpch-preprocess -o DelaydSQL.ii
ignoring nonexistent directory
"/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 .
 ../Common
 /usr/lib64/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3

/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/x86_64-unknown-linux-gnu

/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../include/c++/4.4.3/backward
 /usr/local/include
 /usr/lib64/gcc/x86_64-unknown-linux-gnu/4.4.3/include
 /usr/lib64/gcc/x86_64-unknown-linux-gnu/4.4.3/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-c' '-Wno-multichar' '-fexceptions' '-g3' '-D_MT'
'-DNDEBUG' '-O3' '-funsafe-loop-optimizations' '-Wunsafe-loop-optimizations'
'-static' '-v' '-save-temps' '-DTESTINETD' '-fnon-call-exceptions' '-I.'
'-I../Common' '-o' './GNURelease/DelaydSQL.o' '-mtune=generic'
 /usr/libexec/gcc/x86_64-unknown-linux-gnu/4.4.3/cc1plus -fpreprocessed
DelaydSQL.ii -quiet -dumpbase DelaydSQL.cpp -mtune=generic -auxbase-strip
./GNURelease/DelaydSQL.o -g3 -O3 -Wno-multichar -Wunsafe-loop-optimizations
-version -fexceptions -funsafe-loop-optimizations -fnon-call-exceptions -o
DelaydSQL.s
GNU C++ (GCC) version 4.4.3 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.1.4, MPFR version 2.4.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 64ee06594ed86cd53109893e7ba2a6cf
DelaydSQL.cpp: In function ‘CDelaydSQLThread::CDelaydSQLThread()’:
DelaydSQL.cpp:757: internal compiler error: Segmentation fault

--
Comment:
If I skip "-fnon-call-exceptions" option - compilation became successfull.


-- 
   Summary: Segmentation Fault
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gekus at aha dot ru


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

[Bug middle-end/45242] [4.6 Regression] ICE in trunc_int_for_mode, at explow.c:57

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-08-10 04:29 ---


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


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/45182] [4.6 regression] Failed to build SPEC CPU 2000/2006

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2010-08-10 04:29 ---
*** Bug 45242 has been marked as a duplicate of this bug. ***


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||jv244 at cam dot ac dot uk


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

[Bug bootstrap/45206] [4.6 regression] ICE in ix86_expand_epilogue compiling libgcc

[kargl at gcc dot gnu dot org]

--- Comment #5 from kargl at gcc dot gnu dot org  2010-08-10 02:54 ---
Does anyone know which combination of recent commits
is causing this problem?  I've tried individually backing
out  several of the likely offenders, but I still can't
bootstrap.  So, I'm guessing that I need to back out
some set of commits.


-- 


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

[Bug fortran/45244] Incorrect passing of character string array argument triggers an internal compiler error

[kargl at gcc dot gnu dot org]

--- Comment #2 from kargl at gcc dot gnu dot org  2010-08-10 02:37 ---
Created an attachment (id=21444)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21444&action=view)
Reduced testcase

Reduced testcase.  gdb shows 

Program received signal SIGSEGV, Segmentation fault.
0x080ed4c0 in compare_actual_formal (ap=0x4969174c, formal=0x495054e8, 
ranks_must_agree=0, is_elemental=0, where=0x4969171c)
at ../../gcc4x/gcc/fortran/interface.c:1606
warning: Source file is more recent than executable.
1606if (ref->type == REF_ARRAY && ref->u.ar.type == AR_ELEMENT
(gdb) bt
#0  0x080ed4c0 in compare_actual_formal (ap=0x4969174c, formal=0x495054e8, 
ranks_must_agree=0, is_elemental=0, where=0x4969171c)
at ../../gcc4x/gcc/fortran/interface.c:1606
#1  0x080eec1c in gfc_procedure_use (sym=0x496973c0, ap=0x4969174c, 
where=0x4969171c) at ../../gcc4x/gcc/fortran/interface.c:2623
#2  0x0812a978 in resolve_call (c=0x49691710)
at ../../gcc4x/gcc/fortran/resolve.c:3288
#3  0x0812b341 in resolve_code (code=0x49691710, ns=0x49623200)
at ../../gcc4x/gcc/fortran/resolve.c:8617
#4  0x0812c453 in resolve_codes (ns=0x49623200)
at ../../gcc4x/gcc/fortran/resolve.c:13052
#5  0x0812c37c in resolve_codes (ns=0x49621d00)
at ../../gcc4x/gcc/fortran/resolve.c:13038
#6  0x0812c52c in gfc_resolve (ns=0x49621d00)
at ../../gcc4x/gcc/fortran/resolve.c:13079
#7  0x0811f4c7 in gfc_parse_file () at ../../gcc4x/gcc/fortran/parse.c:4379
#8  0x08153e30 in gfc_be_parse_file (set_yydebug=0)
at ../../gcc4x/gcc/fortran/f95-lang.c:236
#9  0x0848fc35 in do_compile () at ../../gcc4x/gcc/toplev.c:978
#10 0x084909c6 in toplev_main (argc=2, argv=0xbfbfe57c)
at ../../gcc4x/gcc/toplev.c:2374
#11 0x081ada92 in main (argc=4, argv=0x6) at ../../gcc4x/gcc/main.c:36


-- 


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

[Bug fortran/45244] Incorrect passing of character string array argument triggers an internal compiler error

[Eric dot Zurcher at csiro dot au]

--- Comment #1 from Eric dot Zurcher at csiro dot au  2010-08-10 02:16 
---
The FORTRAN code given below causes gfortran to fail with the message:
f951.exe: internal compiler error: Segmentation fault

I have tested this using the Mingw32 version of gfortran 4.5.0, and version
4.3.2 on SUSE Linux. 

The code does contain a known error: the argument "variable" should be passed
as an array of strings, not as just the first string in the array. However,
this incorrect code should not cause the compiler to segmentation fault.



  Module BugDemo

  integer M
  parameter (M=100)

  Type aRecord
  SEQUENCE
charactersoil_type(0:M)*20 
  End Type aRecord

  Type (aRecord),Pointer ::  p

  contains

! 
   subroutine read_char_array
 . (section_name, variable_name, size_of,
 .  units, variable, numvals)
! 
  implicit none

!+ Sub-Program Arguments
  character section_name*(*)   ! (INPUT) section name to search for
  character variable_name*(*)  ! (INPUT) Variable name to search for
  integer size_of  ! (INPUT) size_of of array
  character units*(*)  ! (INPUT) Units required by caller
  character variable(*)*(*)! (OUTPUT) Variable returned to caller
  integer numvals ! (OUTPUT) Number of values returned

  logical found

!- Implementation Section --

  found = .TRUE.
  return
  end subroutine

  subroutine dotest

  !Use ReadModule
  Implicit None
  integer numvals

  allocate(p)   

  call Read_char_array (
 :  'init',
 :  'soil_type',
 :  M+1,
 :  '(?)',
 :  p%soil_type(0),   ! THIS IS WRONG
 :  numvals)

  deallocate(p) 
  return

  end subroutine

  end module BugDemo


-- 


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

[Bug fortran/45244] New: Incorrect passing of character string array argument triggers an internal compiler error

[Eric dot Zurcher at csiro dot au]

-- 
   Summary: Incorrect passing of character string array argument
triggers an internal compiler error
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Eric dot Zurcher at csiro dot au


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

[Bug libstdc++/45226] the difference of fstream's open() in different GCC version

[china dot wenli dot wang at gmail dot com]

--- Comment #4 from china dot wenli dot wang at gmail dot com  2010-08-10 
01:07 ---
(In reply to comment #3)
> (In reply to comment #2)
> > Thank you,yeah,the code is not a self-contained testcase.I copile it with
> > another codes which not show here.
> 
> Yes, but we don't want to see a useless chunk of your program, it doesn't help
> anyone. You could have reduced the code to this and it would show the same
> problem:
> 
> #include 
> void f()
> {
>   std::ofstream txt_stream;
>   txt_stream.open("foo", "w");
> }
> 
> Your example is full of unrelated code that has nothing to do with the 
> problem.
> 
> > The main problem is open() function.For
> > calling open() of GCC 3.4.6,what can I do in may code and how to update my 
> > code
> > to ISO C++.Could please you give me specific example.Thank you in advance.
> 
> As I said, the second argument to ofstream::open is openmode
> e.g.
> 
>   txt_stream.open("foo", std::ios::out);
> 
> Please consult a C++ book or reference for more details.
> 
Hi,
Mr Wakely,as you said,I write a example:
using namespace std;
#include
#include
int main()
{
   std::ofstream txt_stream;
   int status=0;
   char txt_stream_file[100]; 
   const char *file;

  strcpy(txt_stream_file,"plots/");
  strcat(txt_stream_file,"results");
  strcat(txt_stream_file,".txt");   
  file=txt_stream_file;   
  txt_stream.open(file,std::ios::out);

if(txt_stream==NULL) 
 // if(!txt_stream.iis_open())
   cout<<"cannot open "

[Bug c++/45200] [4.5/4.6 Regression] ICE in template instantiation

[dodji at gcc dot gnu dot org]

--- Comment #7 from dodji at gcc dot gnu dot org  2010-08-09 23:56 ---
Created an attachment (id=21443)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21443&action=view)
Candidate patch

I am testing this patch atm that seems to be working for now.


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug tree-optimization/45243] Non-volatile variables don't need to be constantly modified at -Os

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-08-09 23:12 ---
Works with -O2 which means LIM is not working at -Os for some reason.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c++ |tree-optimization
 Ever Confirmed|0   |1
   GCC host triplet|x86_64-gnu-linux|
 GCC target triplet||x86_64-gnu-linux
   Last reconfirmed|-00-00 00:00:00 |2010-08-09 23:12:13
   date||
Summary|Non-volatile variables don't|Non-volatile variables don't
   |need to be constantly   |need to be constantly
   |modified|modified at -Os


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

[Bug c++/45243] New: Non-volatile variables don't need to be constantly modified

[msharov at users dot sourceforge dot net]

void foo (int& sz, int n)
{
for (++n; --n;)
sz += 5;
}

Produces (-Os):

_Z3fooRii:
incl%esi
jmp .L2
.L3:
addl$5, (%rdi)
.L2:
decl%esi
jne .L3
ret

gcc thinks that every little change to sz needs to be stored in memory, causing
the above inefficiency of emitting a loop instead of a multiplication. It would
be desirable to treat sz as a local variable and optimize as if:

void bar (int& sz, int n)
{
int tmp = sz;
for (++n; --n;)
tmp += 5;
sz = tmp;
}

Which compiles to:

_Z3barRii:
leal(%rsi,%rsi,4), %esi
addl%esi, (%rdi)
ret

much better code. If somebody really does need each variable access to be a
memory access, that variable should be declared volatile.

If you don't want to fix this, at least provide a variable attribute to tell
the compiler that it's ok to omit stores.


-- 
   Summary: Non-volatile variables don't need to be constantly
modified
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msharov at users dot sourceforge dot net
  GCC host triplet: x86_64-gnu-linux


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

[Bug fortran/45159] Unnecessary temporaries

[tkoenig at gcc dot gnu dot org]

--- Comment #16 from tkoenig at gcc dot gnu dot org  2010-08-09 22:56 
---
(In reply to comment #15)
> Here's another case where we generate a temporary:
> 
> program main
>   integer a(100)
>   a(10:16) = a(11:17:1)
> end program main

Here's a tentative patch:

Index: dependency.c 
=== 
--- dependency.c(Revision 163040)   
+++ dependency.c(Arbeitskopie)  
@@ -1023,6 +1023,7 @@ check_section_vs_section (gfc_array_ref *l_ar, gfc
   gfc_expr *r_lower;   
   gfc_expr *r_upper;   
   int r_dir;   
+  bool identical_strides;  

   /* If they are the same range, return without more ado.  */  
   if (gfc_is_same_range (l_ar, r_ar, n, 0))
@@ -1076,6 +1077,23 @@ check_section_vs_section (gfc_array_ref *l_ar, gfc   
   if (l_dir == 0 || r_dir == 0)
 return GFC_DEP_OVERLAP;

+  /* Determine if the strides are equal.  */   
+   
+  if (l_stride)
+{  
+  if (r_stride)
+   identical_strides = gfc_dep_compare_expr (l_stride, r_stride) == 1; 
+  else 
+   identical_strides = gfc_expr_is_one (l_stride, 0) == 0; 
+}  
+  else 
+{  
+  if (r_stride)
+   identical_strides = gfc_expr_is_one (r_stride, 0) == 1; 
+  else 
+   identical_strides = true;   
+}  
+   
   /* Determine LHS upper and lower bounds.  */ 
   if (l_dir == 1)  
 {  
@@ -1175,12 +1193,8 @@ check_section_vs_section (gfc_array_ref *l_ar, gfc   
   && l_start && r_start && gfc_dep_compare_expr (l_start, r_start) == -1
   && l_end && r_end && gfc_dep_compare_expr (l_end, r_end) == -1)   
 {   
-  /* Check that the strides are the same.  */
-  if (!l_stride && !r_stride)
+  if (identical_strides)
return GFC_DEP_FORWARD;
-  if (l_stride && r_stride
- && gfc_dep_compare_expr (l_stride, r_stride) == 0)
-   return GFC_DEP_FORWARD;
 }

   /* Check for forward dependencies x:y:-1 vs. x-1:z:-1.  */
@@ -1188,20 +1202,12 @@ check_section_vs_section (gfc_array_ref *l_ar, gfc
   && l_start && r_start && gfc_dep_compare_expr (l_start, r_start) == 1
   && l_end && r_end && gfc_dep_compare_expr (l_end, r_end) == 1)
 {
-  /* Check that the strides are the same.  */
-  if (!l_stride && !r_stride)
+  if (identical_strides)
return GFC_DEP_FORWARD;
-  if (l_stride && r_stride
- && gfc_dep_compare_expr (l_stride, r_stride) == 0)
-   return GFC_DEP_FORWARD;
 }


-  /*  Are the strides the same?  */
-  if ((!l_stride && !r_stride)
-   ||
-  (l_stride && r_stride
-   && gfc_dep_compare_expr (l_stride, r_stride) == 0))
+  if (identical_strides)
 {

   if (l_start && IS_ARRAY_EXPLICIT (l_ar->as))


-- 


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

[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6

[LpSolit at netscape dot net]

--- Comment #29 from LpSolit at netscape dot net  2010-08-09 22:21 ---
(In reply to comment #28)
> I think you should probably set yourself up an account on sourceware.
> Fill out this form: http://sourceware.org/cgi-bin/pdw/ps_form.cgi and
> list me as your referrer.

Done! I selected "sourceware" as project. I hope that was the correct one.


-- 


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

[Bug c++/45203] [Feature request] #pragma start_no_warn_regex

[eric_moyer at yahoo dot com]

--- Comment #4 from eric_moyer at yahoo dot com  2010-08-09 22:10 ---
That is great to hear.  I've wanted this feature for years (but never took the
time to create a bugzilla account.)  Thank you.


-- 


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

[Bug fortran/45159] Unnecessary temporaries

[tkoenig at gcc dot gnu dot org]

--- Comment #15 from tkoenig at gcc dot gnu dot org  2010-08-09 21:54 
---
Here's another case where we generate a temporary:

program main
  integer a(100)
  a(10:16) = a(11:17:1)
end program main
i...@linux-fd1f:~/Krempel/Dep-9> gfortran -Warray-temporaries d1.f90
d1.f90:3.13:

  a(10:16) = a(11:17:1)
 1
Warnung: Creating array temporary at (1)


-- 


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

[Bug c++/45236] [C++0x] Can't access nested type of a partial class specialization involving variadic parameters

[rodolfo at rodsoft dot org]

--- Comment #12 from rodolfo at rodsoft dot org  2010-08-09 21:35 ---
Thanks for the quick fix, I have already recompiled gcc and now it compiles the
snippets I've posted.


-- 


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

[Bug objc/24777] objc needs to use normal builtins for functions it declares

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2010-08-09 21:32 ---
This blocks 17982. There are assemble_external calls are for
objc_get_class_decl, objc_assign_global_decl, and objc_assign_strong_cast_decl.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||17982
  nThis||
   Last reconfirmed|2007-07-09 05:57:42 |2010-08-09 21:32:01
   date||


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

[Bug c++/45203] [Feature request] #pragma start_no_warn_regex

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2010-08-09 21:28 ---
(In reply to comment #2)
> I want to disable warnings for particular lines of code rather than whole
> files.

See
http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html#Diagnostic-Pragmas

And 
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01255.html

This has already been fixed for 4.6.0.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0


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

[Bug objc/24868] objc-act.c builds non-type-safe structure

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-08-09 21:19 ---
Fixed by:
gcc/objc/

PR objc/44140
(init_objc_symtab): Use integer_zero_node, make the short
integer type specific on relevant nodes.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/45236] [C++0x] Can't access nested type of a partial class specialization involving variadic parameters

[jason at gcc dot gnu dot org]

--- Comment #11 from jason at gcc dot gnu dot org  2010-08-09 21:14 ---
Fixed for 4.6.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/45236] [C++0x] Can't access nested type of a partial class specialization involving variadic parameters

[jason at gcc dot gnu dot org]

--- Comment #10 from jason at gcc dot gnu dot org  2010-08-09 21:13 ---
Subject: Bug 45236

Author: jason
Date: Mon Aug  9 21:13:12 2010
New Revision: 163042

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163042
Log:
PR c++/45236
* pt.c (lookup_template_class): Don't re-coerce outer parms.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-104.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/17982] stop calling assemble_external before final assembly output time

[steven at gcc dot gnu dot org]

--- Comment #34 from steven at gcc dot gnu dot org  2010-08-09 21:13 ---
The FIXME here is this one in varasm.c:

---
/* We delay assemble_external processing until
   the compilation unit is finalized.  This is the best we can do for
   right now (i.e. stage 3 of GCC 4.0) - the right thing is to delay
   it all the way to final.  See PR 17982 for further discussion.  */
static GTY(()) tree pending_assemble_externals;
---

According to http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00491.html:

The *proper* solution to this problem is to remove all calls to
assemble_external from the front ends and even the RTL expander; it
should only be done from final.c and varasm.c as we are emitting
assembly. 

$ grep assemble_external c* */*.[ch] ada/gcc-interface/*.[ch]
calls.c:  assemble_external (fndecl);
calls.c:  assemble_external_libcall (fun);
cp/cp-tree.h:   so that assemble_external will work properly.  So we have this
flag to
objc/objc-act.c:  assemble_external (objc_get_class_decl);
objc/objc-act.c:  assemble_external (func);
objc/objc-act.c:  assemble_external (objc_assign_global_decl);
objc/objc-act.c:  assemble_external (objc_assign_strong_cast_decl);
objc/objc-act.c:  assemble_external (super_class);

I think the ones in calls.c are OK.  So only ObjC still calls
assemble_external. Iain?


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||iains at gcc dot gnu dot org


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

[Bug fortran/44235] array temporary with high upper bound

[tkoenig at gcc dot gnu dot org]

--- Comment #12 from tkoenig at gcc dot gnu dot org  2010-08-09 19:35 
---
Subject: Bug 44235

Author: tkoenig
Date: Mon Aug  9 19:34:49 2010
New Revision: 163041

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163041
Log:
2010-08-09  Thomas Koenig  

PR fortran/44235
* array.c (gfc_ref_dimen_size):  Add end argument.
If end is non-NULL, calculate it.
(ref_size):  Adjust call to gfc_ref_dimen_size.
(gfc_array_dimen_size):  Likewise.
(gfc_array_res_shape):  Likewise.
* gfortran.h:  Adjust prototype for gfc_ref_dimen_size.
* resolve.c (resolve_array_ref):  For stride not equal to -1,
fill in the lowest possible end.

2010-08-09  Thomas Koenig  

PR fortran/44235
* gfortran.dg/dependency_32.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/dependency_32.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/45212] [4.6 Regression] FAIL: gcc.target/alpha/pr24178.c scan-assembler ldl.*,18\\\\(

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2010-08-09 18:24 ---
(In reply to comment #4)
> Fixed.

Confirmed fixed on alpha [1].

[1] http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg00932.html


-- 


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

[Bug middle-end/45242] New: [4.6 Regression] ICE in trunc_int_for_mode, at explow.c:57

[jv244 at cam dot ac dot uk]

Recent regression with trunk revision 163037

> cat bug.f90
  SUBROUTINE dbcsr_sort_indices(n,row_i, col_i)
INTEGER, DIMENSION(1:n), INTENT(INOUT)   :: row_i, col_i
row_i(:) = ISHFT(row_i(:), 16) + col_i
  END SUBROUTINE dbcsr_sort_indices

> gfortran -c  -O3   bug.f90
bug.f90: In function ‘dbcsr_sort_indices’:
bug.f90:4:0: internal compiler error: in trunc_int_for_mode, at explow.c:57
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.6 Regression] ICE in trunc_int_for_mode, at
explow.c:57
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk


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

[Bug tree-optimization/45241] CPU2006 465.tonto ICE in the vectorizer with -fno-tree-pre

[changpeng dot fang at amd dot com]

--- Comment #1 from changpeng dot fang at amd dot com  2010-08-09 17:52 
---
This patch should be a valid fix, because the recognition of the dot_prod
pattern is known to be fail at this point if the stmt is outside the loop.
(I am not sure whether we should not see this case in the vectorizer at this
point -- should previous analysis already filter out?):

diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
index 19f0ae6..5f81a73 100644
--- a/gcc/tree-vect-patterns.c
+++ b/gcc/tree-vect-patterns.c
@@ -259,6 +259,10 @@ vect_recog_dot_prod_pattern (gimple last_stmt, tree
*type_in, tree *type_out)
  inside the loop (in case we are analyzing an outer-loop).  */
   if (!is_gimple_assign (stmt))
 return NULL;
+
+  if (!flow_bb_inside_loop_p (loop, gimple_bb (stmt)))
+return NULL;
+
   stmt_vinfo = vinfo_for_stmt (stmt);
   gcc_assert (stmt_vinfo);
   if (STMT_VINFO_DEF_TYPE (stmt_vinfo) != vect_internal_def)


-- 


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

[Bug tree-optimization/45241] New: CPU2006 465.tonto ICE in the vectorizer with -fno-tree-pre

[changpeng dot fang at amd dot com]

With gcc 4.6:
gfortran  -c -o diis.fppized.o -O3 -fno-tree-pre -march=amdfam10 -m64
diis.fppized.f90

diis.fppized.f90: In function 'extrapolate':
diis.fppized.f90:882:0: internal compiler error: vector VEC(vec_void_p,base)
index domain error, in vinfo_for_stmt at tree-vectorizer.h:595
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions

This is invoked in "vect_recog_dot_prod_pattern":
stmt_vinfo = vinfo_for_stmt (stmt);

Where "stmt" is not inside the loop, and thus stmt_vinfo was not set up.


-- 
   Summary: CPU2006 465.tonto ICE in the vectorizer with -fno-tree-
pre
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: changpeng dot fang at amd dot com


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

[Bug target/45234] [4.4 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca

[truedfx at gentoo dot org]

--- Comment #13 from truedfx at gentoo dot org  2010-08-09 17:44 ---
Thanks, that seems to work for me too for the reduced code. I'll test the
original larger code that was failing too, but that'll take a little longer for
me to report back anything.


-- 


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

[Bug c++/45236] [C++0x] Can't access nested type of a partial class specialization involving variadic parameters

[paolo dot carlini at oracle dot com]

--- Comment #9 from paolo dot carlini at oracle dot com  2010-08-09 17:44 
---
Ah, DR 691!


-- 


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

[Bug c++/45236] [C++0x] Can't access nested type of a partial class specialization involving variadic parameters

[jason at gcc dot gnu dot org]

--- Comment #8 from jason at gcc dot gnu dot org  2010-08-09 17:42 ---
Wait, no, I was misreading your testcase; it doesn't have a pack expansion as a
template argument, so it ought to work.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords|diagnostic  |rejects-valid
Summary|[C++0x] unhelpful diagnostic|[C++0x] Can't access nested
   |for parameter pack that is  |type of a partial class
   |not last|specialization involving
   ||variadic parameters


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

[Bug fortran/44595] INTENT of argeuments to intrinsics procedure not check

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2010-08-09 17:41 ---
(In reply to comment #0)
> The problem is in check_variable() in check.c.  The first if-statement
> prevents the second one from being reached.

Right. However, exchanging them produces lots of regressions, since the intent
of the formal argument is not checked.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug libgomp/45240] New: parallel.c: GOMP_parallel_end locks a mutex but fails to unlock it after atomic operation complete

[shreyasp at ti dot com]

In parallel.c, if HAVE_SYNC_BUILTINS is #undef'ed, then GOMP_parallel_end uses
a mutex to atomically modify the team->nthreads field.  The mutex that is used
to atomically write to nthreads is locked but never unlocked.

parallel.c, GOMP_parallel_end:

#ifdef HAVE_SYNC_BUILTINS
  __sync_fetch_and_add (&gomp_remaining_threads_count,
1UL - team->nthreads);
#else
  gomp_mutex_lock (&gomp_remaining_threads_lock);
  gomp_remaining_threads_count -= team->nthreads - 1;
#endif


-- 
   Summary: parallel.c: GOMP_parallel_end locks a mutex but fails to
unlock it after atomic operation complete
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: shreyasp at ti dot com


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

[Bug tree-optimization/45239] New: CPU2006 465.tonto ICE in the vectorizer with -fno-tree-pre

[changpeng dot fang at amd dot com]

With gcc 4.6:
gfortran  -c -o diis.fppized.o -O3 -fno-tree-pre -march=amdfam10 -m64
diis.fppized.f90

diis.fppized.f90: In function 'extrapolate':
diis.fppized.f90:882:0: internal compiler error: vector VEC(vec_void_p,base)
index domain error, in vinfo_for_stmt at tree-vectorizer.h:595
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions

This is invoked in "vect_recog_dot_prod_pattern":
stmt_vinfo = vinfo_for_stmt (stmt);

Where "stmt" is not inside the loop, and thus stmt_vinfo was not set up.


-- 
   Summary: CPU2006 465.tonto ICE in the vectorizer with -fno-tree-
pre
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: changpeng dot fang at amd dot com


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

[Bug c++/45236] [C++0x] unhelpful diagnostic for parameter pack that is not last

[jason at gcc dot gnu dot org]

--- Comment #7 from jason at gcc dot gnu dot org  2010-08-09 17:36 ---
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#691


-- 


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

[Bug c++/45236] [C++0x] unhelpful diagnostic for parameter pack that is not last

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2010-08-09 17:34 ---
14.1 paragraph 11 says,

If a template-parameter of a class template is a template parameter pack, it
shall be the last template-parameter.

This isn't quite right: what we really want to require is that if a
partial-specialization argument (or the equivalent transformed parameter for a
primary template) is a pack expansion, it is the last one.  But that also
applies to your testcase #5, which is ill-formed.  Your testcase in comment #4
is OK because none of the partial specialization arguments are pack expansions.

As Paolo says, we ought to give a better error.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2010-08-09 17:34:37
   date||
Summary|[C++0x] Can't access nested |[C++0x] unhelpful diagnostic
   |type of a partial class |for parameter pack that is
   |specialization involving|not last
   |variadic parameters |


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

[Bug target/45234] [4.4 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca

[hjl dot tools at gmail dot com]

--- Comment #12 from hjl dot tools at gmail dot com  2010-08-09 17:24 
---
Created an attachment (id=21442)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21442&action=view)
A patch

This patch seems to work for me.


-- 


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

[Bug fortran/45128] Segmentation fault with -fwhole-file for subref_array_pointer

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2010-08-09 17:18 
---
Paul, can you send me a preview of the new descriptor structure so I can be
planning the internal unit I/O impacts if any.


-- 


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

[Bug middle-end/41551] [4.4 Regression] ia64: ICE: in instantiate_virtual_regs_in_insn, at function.c:1630

[steven at gcc dot gnu dot org]

--- Comment #6 from steven at gcc dot gnu dot org  2010-08-09 17:11 ---
Needs fixing in 4.4 still.


-- 

steven 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-09 17:11:51
   date||


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

[Bug middle-end/41551] [4.4 Regression] ia64: ICE: in instantiate_virtual_regs_in_insn, at function.c:1630

[steven at gcc dot gnu dot org]

--- Comment #5 from steven at gcc dot gnu dot org  2010-08-09 17:11 ---
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg01067.html


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
  Known to fail||4.4.4
  Known to work||4.2.0 4.5.0 4.6.0
 Resolution|FIXED   |
Summary|ia64: ICE: in   |[4.4 Regression] ia64: ICE:
   |instantiate_virtual_regs_in_|in
   |insn, at function.c:1630|instantiate_virtual_regs_in_
   ||insn, at function.c:1630
   Target Milestone|--- |4.4.5


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

[Bug target/45234] [4.4 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca

[hjl dot tools at gmail dot com]

--- Comment #11 from hjl dot tools at gmail dot com  2010-08-09 17:01 
---
(In reply to comment #9)
> Does this patch:
> 
> --
> diff --git a/gcc/calls.c b/gcc/calls.c
> index cd0d9c5..cbb0944 100644
> --- a/gcc/calls.c
> +++ b/gcc/calls.c
> @@ -2846,7 +2846,8 @@ expand_call (tree exp, rtx target, int ignore)
> 
>/* Stack must be properly aligned now.  */
>gcc_assert (!pass
> -   || !(stack_pointer_delta % preferred_unit_stack_boundary));
> +   || !(stack_pointer_delta
> +% (PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT)));
> 
>/* Generate the actual call instruction.  */
>emit_call_1 (funexp, exp, fndecl, funtype, unadjusted_args_size,
> --
> 
> make any senses?
> 

This is incorrect. If SUPPORTS_STACK_ALIGNMENT is true, expand_call needs
to check stack_pointer_delta and preferred_unit_stack_boundary, and adjust
stack is needed before expanding call if needed.


-- 


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

[Bug target/45234] [4.4 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca

[truedfx at gentoo dot org]

--- Comment #10 from truedfx at gentoo dot org  2010-08-09 16:58 ---
I had already tried simply commenting out the assert, and that caused wrong
code, so changing the assert without anything else won't help :)

FWIW, I now also checked the code difference between alloca(2) and alloca(6)
with 4.3.5, and it looks like that gets it wrong:

@@ -5,7 +5,7 @@
 g:
pushl   %ebp
movl%esp, %ebp
-   subl$36, %esp
+   subl$40, %esp
movdqa  .LC0, %xmm0
movaps  %xmm0, (%esp)
callf

so this isn't really a regression, it just changed from wrong code to an ICE,
which is an improvement IMO.


-- 


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

[Bug target/45234] [4.4 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2010-08-09 16:38 ---
Does this patch:

--
diff --git a/gcc/calls.c b/gcc/calls.c
index cd0d9c5..cbb0944 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -2846,7 +2846,8 @@ expand_call (tree exp, rtx target, int ignore)

   /* Stack must be properly aligned now.  */
   gcc_assert (!pass
-   || !(stack_pointer_delta % preferred_unit_stack_boundary));
+   || !(stack_pointer_delta
+% (PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT)));

   /* Generate the actual call instruction.  */
   emit_call_1 (funexp, exp, fndecl, funtype, unadjusted_args_size,
--

make any senses?


-- 


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

[Bug target/45234] [4.4 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2010-08-09 16:28 ---
/* Adjust the stack pointer by minus ADJUST (an rtx for a number of bytes).
   This pushes when ADJUST is positive.  ADJUST need not be constant.  */

void
anti_adjust_stack (rtx adjust)
{
  rtx temp;

  if (adjust == const0_rtx)
return;

  /* We expect all variable sized adjustments to be multiple of
 PREFERRED_STACK_BOUNDARY.  */
  if (CONST_INT_P (adjust))
stack_pointer_delta += INTVAL (adjust);

However, PREFERRED_STACK_BOUNDARY isn't fixed at this time.


-- 


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

[Bug middle-end/41551] ia64: ICE: in instantiate_virtual_regs_in_insn, at function.c:1630

[armin76 at gentoo dot org]

--- Comment #4 from armin76 at gentoo dot org  2010-08-09 16:28 ---
Could this be backported to gcc-4.4 branch, please?


-- 


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

[Bug target/45234] [4.4 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2010-08-09 16:19 ---
__builtin_alloca (var) is handled properly. __builtin_alloca (const int)
is a special case. I am looking into it now.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|4.4.5   |---


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

[Bug target/45234] [4.4 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca

[truedfx at gentoo dot org]

--- Comment #6 from truedfx at gentoo dot org  2010-08-09 16:15 ---
With those two lines removed from 4.5.0, it looks like the stack will be
aligned properly by accident. When changing __builtin_alloca (2) to
__builtin_alloca (6), the only thing that changes in the generated code is

@@ -10,7 +10,7 @@
movl%esp, %ebp
pushl   %ecx
subl$20, %esp
-   subl$20, %esp
+   subl$24, %esp
movdqa  .LC0, %xmm0
movdqa  %xmm0, (%esp)
callf


-- 


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

[Bug other/45238] New: gccgo failure to build

[gcc-bugzilla at gcc dot gnu dot org]

libgo fails to build. Here's the error output:


gmake[4]: Entering directory
`/usr/home/chris/gnuobj/gccgo/i386-unknown-freebsd8.1/libgo'
rm -f syscall.gox syscalls/libsyscall.a
test -d syscalls || mkdir -p syscalls
files=`echo ../../../../gnusrc/gccgo/libgo/syscalls/errstr.go
../../../../gnusrc/gccgo/libgo/syscalls/exec_helpers.go
../../../../gnusrc/gccgo/libgo/syscalls/exec.go
../../../../gnusrc/gccgo/libgo/syscalls/socket.go
../../../../gnusrc/gccgo/libgo/syscalls/socket_linux.go
../../../../gnusrc/gccgo/libgo/syscalls/socket_epoll.go
../../../../gnusrc/gccgo/libgo/syscalls/syscall.go
../../../../gnusrc/gccgo/libgo/syscalls/syscall_unix.go
../../../../gnusrc/gccgo/libgo/syscalls/stringbyte.go
../../../../gnusrc/gccgo/libgo/syscalls/sysfile_posix.go
../../../../gnusrc/gccgo/libgo/syscalls/sysfile_linux.go sysinfo.go
../../../../gnusrc/gccgo/libgo/syscalls/errno.c sync.gox | sed -e 's/[^
]*\.gox//g' -e's/[^ ]*\.c//g'`; \
/bin/sh ./libtool --tag GO --mode=compile
/usr/home/chris/gnuobj/gccgo/./gcc/gccgo -B/usr/home/chris/gnuobj/gccgo/./gcc/ 
-minline-all-stringops -O2 -g -c -fgo-prefix="libgo__" -o syscalls/syscall.o
$files
libtool: compile:  /usr/home/chris/gnuobj/gccgo/./gcc/gccgo
-B/usr/home/chris/gnuobj/gccgo/./gcc/ -minline-all-stringops -O2 -g -c
-fgo-prefix=libgo__ ../../../../gnusrc/gccgo/libgo/syscalls/errstr.go
../../../../gnusrc/gccgo/libgo/syscalls/exec_helpers.go
../../../../gnusrc/gccgo/libgo/syscalls/exec.go
../../../../gnusrc/gccgo/libgo/syscalls/socket.go
../../../../gnusrc/gccgo/libgo/syscalls/socket_linux.go
../../../../gnusrc/gccgo/libgo/syscalls/socket_epoll.go
../../../../gnusrc/gccgo/libgo/syscalls/syscall.go
../../../../gnusrc/gccgo/libgo/syscalls/syscall_unix.go
../../../../gnusrc/gccgo/libgo/syscalls/stringbyte.go
../../../../gnusrc/gccgo/libgo/syscalls/sysfile_posix.go
../../../../gnusrc/gccgo/libgo/syscalls/sysfile_linux.go sysinfo.go  -fPIC -o
syscalls/.libs/syscall.o
sysinfo.go:2904:32: error: expected ')'
sysinfo.go:2904:32: error: expected ';' or newline after top level declaration
sysinfo.go:2904:32: error: expected declaration
sysinfo.go:2905:1: error: expected ';' or newline after top level declaration
sysinfo.go:3067:6: error: recursive type definition
sysinfo.go:3074:6: error: recursive type definition
sysinfo.go:3075:6: error: recursive type definition
sysinfo.go:3254:7: error: redefinition of '_FD_SETSIZE'
sysinfo.go:196:7: note: previous definition of '_FD_SETSIZE' was here
sysinfo.go:3255:7: error: redefinition of '_O_RDONLY'
sysinfo.go:308:7: note: previous definition of '_O_RDONLY' was here
sysinfo.go:3256:7: error: redefinition of '_O_WRONLY'
sysinfo.go:309:7: note: previous definition of '_O_WRONLY' was here
sysinfo.go:3257:7: error: redefinition of '_O_RDWR'
sysinfo.go:310:7: note: previous definition of '_O_RDWR' was here
sysinfo.go:3258:7: error: redefinition of '_O_ACCMODE'
sysinfo.go:311:7: note: previous definition of '_O_ACCMODE' was here
sysinfo.go:3259:7: error: redefinition of '_O_NONBLOCK'
sysinfo.go:314:7: note: previous definition of '_O_NONBLOCK' was here
sysinfo.go:3260:7: error: redefinition of '_O_APPEND'
sysinfo.go:315:7: note: previous definition of '_O_APPEND' was here
sysinfo.go:3261:7: error: redefinition of '_O_SHLOCK'
sysinfo.go:316:7: note: previous definition of '_O_SHLOCK' was here
sysinfo.go:3262:7: error: redefinition of '_O_EXLOCK'
sysinfo.go:317:7: note: previous definition of '_O_EXLOCK' was here
sysinfo.go:3263:7: error: redefinition of '_O_ASYNC'
sysinfo.go:318:7: note: previous definition of '_O_ASYNC' was here
sysinfo.go:3264:7: error: redefinition of '_O_FSYNC'
sysinfo.go:319:7: note: previous definition of '_O_FSYNC' was here
sysinfo.go:3265:7: error: redefinition of '_O_SYNC'
sysinfo.go:320:7: note: previous definition of '_O_SYNC' was here
sysinfo.go:3266:7: error: redefinition of '_O_NOFOLLOW'
sysinfo.go:321:7: note: previous definition of '_O_NOFOLLOW' was here
sysinfo.go:3267:7: error: redefinition of '_O_CREAT'
sysinfo.go:322:7: note: previous definition of '_O_CREAT' was here
sysinfo.go:3268:7: error: redefinition of '_O_TRUNC'
sysinfo.go:323:7: note: previous definition of '_O_TRUNC' was here
sysinfo.go:3269:7: error: redefinition of '_O_EXCL'
sysinfo.go:324:7: note: previous definition of '_O_EXCL' was here
sysinfo.go:3270:7: error: redefinition of '_O_NOCTTY'
sysinfo.go:325:7: note: previous definition of '_O_NOCTTY' was here
sysinfo.go:3271:7: error: redefinition of '_O_DIRECT'
sysinfo.go:326:7: note: previous definition of '_O_DIRECT' was here
sysinfo.go:3272:7: error: redefinition of '_O_DIRECTORY'
sysinfo.go:327:7: note: previous definition of '_O_DIRECTORY' was here
sysinfo.go:3273:7: error: redefinition of '_O_EXEC'
sysinfo.go:328:7: note: previous definition of '_O_EXEC' was here
sysinfo.go:3274:7: error: redefinition of '_O_TTY_INIT'
sysinfo.go:329:7: note: previous definition of '_O_TTY_INIT' was here
sysinfo.go:3275:7: error: redefinition of '_O_NDELAY'
sysinfo.go:335:7: note: previous definitio

[Bug target/45234] [4.4 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|ICE in expand_call, at  |[4.4 Regression] ICE in
   |calls.c:2845 when passing   |expand_call, at calls.c:2845
   |aligned function argument   |when passing aligned
   |from unaligned stack after  |function argument from
   |alloca  |unaligned stack after alloca
   Target Milestone|--- |4.4.5


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

[Bug other/43977] Patches from oldlto branch to be salvaged

[froydnj at gcc dot gnu dot org]

--- Comment #9 from froydnj at gcc dot gnu dot org  2010-08-09 15:58 ---
r114528 and r114655 have been committed as r163033.

r114348, r114396, and r116014 have been committed (no revisions, but I have
them crossed off on my local list).

FWIW, everything after r116179 is irrelevant for backporting.


-- 


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

[Bug target/45234] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2010-08-09 15:51 ---
(In reply to comment #4)
> H.J, this was introduced by your commit:
> 
...
> 
> By backing out lines marked as ***, compilation succeeds.
> 

Can you take a look at the assembly output to see if
the stack is realigned properly?


-- 


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

[Bug target/45234] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2010-08-09 15:24 ---
H.J, this was introduced by your commit:

138808hjl   /* Ensure current function's preferred stack boundary is at
least
138808hjl  what we need.  Stack alignment may also increase
preferred stack
138808hjl  boundary.  */
137045   uros   if (crtl->preferred_stack_boundary <
preferred_stack_boundary)
134425hubicka crtl->preferred_stack_boundary =
preferred_stack_boundary;
138808  ***   hjl   else
138808  ***   hjl preferred_stack_boundary =
crtl->preferred_stack_boundary;
 31831hubicka 
 33913hubicka   preferred_unit_stack_boundary = preferred_stack_boundary /
BITS_PER_UNIT;
   201rms 

By backing out lines marked as ***, compilation succeeds.


-- 


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

[Bug tree-optimization/42172] inefficient bit fields assignments

[bernds at gcc dot gnu dot org]

--- Comment #4 from bernds at gcc dot gnu dot org  2010-08-09 15:04 ---
I'm reopening this as it's not fixed, and even if we fix it in the RTL
optimizers, it should stay open as a reminder that we produce poor initial RTL.


-- 

bernds at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
  Component|target  |tree-optimization
 Resolution|DUPLICATE   |


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

[Bug fortran/45211] C interoperable error when compiling BIND(C) function in a module.

[brtnfld at hdfgroup dot org]

--- Comment #2 from brtnfld at hdfgroup dot org  2010-08-09 15:02 ---
If the type declaration is moved to the module scope the code compiles.

MODULE liter_cb_mod

USE ISO_C_BINDING

TYPE, BIND(C) :: MYFTYPE
  INTEGER(C_INT) :: I, J
  REAL(C_FLOAT) :: S
END TYPE MYFTYPE

CONTAINS

  FUNCTION liter_cb() bind(C)

USE ISO_C_BINDING
IMPLICIT NONE

INTEGER(c_int) liter_cb

TYPE(MYFTYPE) :: link_info

liter_cb = 0

  END FUNCTION liter_cb

END MODULE liter_cb_mod

There was a discussion about the matter in comp.lang.fortran under the topic
"BIND(C) functions in a module error" as to the source of the problem. Since
there seems to be a work around I downgraded the severity.


-- 

brtnfld at hdfgroup dot org changed:

   What|Removed |Added

   Severity|critical|normal


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

[Bug c++/45236] [C++0x] Can't access nested type of a partial class specialization involving variadic parameters

[rodolfo at rodsoft dot org]

--- Comment #5 from rodolfo at rodsoft dot org  2010-08-09 14:38 ---
And I think that the original intent of the attached code (as I wrote in the
summary) was lost when I tried to reduce it. Here's the original version:

//
template  class foo;

template class C, int... II, class S>
struct foo,S>
{
template 
struct bar { typedef int type; };
};

template 
struct A {};

foo, float>::bar x;
//---

g++ output:
g++ -std=c++0xteste.cpp   -o teste
teste.cpp: In instantiation of ‘foo, float>’:
teste.cpp:13:17:   instantiated from here
teste.cpp:7:9: error: type/value mismatch at argument 2 in template parameter
list for ‘template > class C, int ...II, class S>
template struct foo, S>::bar’
teste.cpp:7:9: error:   expected a constant of type ‘int’, got ‘float’
teste.cpp:7:9: error: type/value mismatch at argument 2 in template parameter
list for ‘template > class C, int ...II, class S>
template struct foo, S>::bar’
teste.cpp:7:9: error:   expected a constant of type ‘int’, got ‘float’
teste.cpp:13:1: error: ‘bar’ in class ‘foo, float>’ does not name a type
make: ** [teste] Erro 1

That is, it is selecting the correct partial specialization. But if make
int...II the last template parameter, it'll compile.


-- 


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

[Bug c++/45236] [C++0x] Can't access nested type of a partial class specialization involving variadic parameters

[rodolfo at rodsoft dot org]

--- Comment #4 from rodolfo at rodsoft dot org  2010-08-09 14:24 ---
Well, this compiles:

template  struct A {};
template  struct B {};
template  struct C {};

template  struct foo;

template class A,
 template class B,
 template class C,
 int...II, int J, int...KK>
struct foo, B, C>
{
};

int main()
{
foo,B<5>,C<7>> bar;
}


-- 


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

[Bug c++/45236] [C++0x] Can't access nested type of a partial class specialization involving variadic parameters

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2010-08-09 14:20 
---
This is certainly correct, and works as expected:

template  struct foo;

template class C, int... II>
struct foo>
{
  struct bar {};
};

template 
struct A {};

foo<4, A<3>>::bar x;


-- 


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

[Bug c++/45236] [C++0x] Can't access nested type of a partial class specialization involving variadic parameters

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2010-08-09 14:18 
---
To me:

  template class C, int... II, int S>

with the variadic II in the middle and S without a default, seems badly
illegal. Jason, should we immediately produce a meaningful error when we see
it?


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug c++/45236] [C++0x] Can't access nested type of a partial class specialization involving variadic parameters

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-08-09 14:11 
---
I would say the problem isn't about "access" (even in non-technical sense),
instead that the specialization itself isn't considered: indeed, if you comment
it out, the error is exactly the same.


-- 


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

[Bug c/45237] New: /usr/include/string.h:546:5: error: unknown type name �__locale_t�

[michael dot a dot richmond at nasa dot gov]

When I attempt to build gcc 4.5.1 or a recent 4.5 snapshot on an x86_64
workstation running SuSE Linux 11.3 I get the following messages:

gcc -c -DHAVE_CONFIG_H -g -fkeep-inline-functions  -I.
-I/home/mrichmon/gcc-4.5.1/libiberty/../include  -W -Wall -Wwrite-strings
-Wc++-compat -Wstrict-prototypes -pedantic 
/home/mrichmon/gcc-4.5.1/libiberty/floatformat.c -o floatformat.o
In file included from /home/mrichmon/gcc-4.5.1/libiberty/floatformat.c:31:0:
/usr/include/string.h:546:5: error: unknown type name ‘__locale_t’
/usr/include/string.h:550:18: error: unknown type name ‘__locale_t’
make[3]: *** [floatformat.o] Error 1
make[3]: Leaving directory `/home/mrichmon/gcc-4.5.1/g95/libiberty'
make[2]: *** [all-stage1-libiberty] Error 2
make[2]: Leaving directory `/home/mrichmon/gcc-4.5.1/g95'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/mrichmon/gcc-4.5.1/g95'
make: *** [all] Error 2
Error running make


-- 
   Summary: /usr/include/string.h:546:5: error: unknown type name
‘__locale_t’
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov
 GCC build triplet: x86_64-unknown-linux-gnu
  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=45237

[Bug c++/45236] New: Can't access nested type of a partial class specialization involving variadic parameters

[rodolfo at rodsoft dot org]

The following code doesn't compile on gcc-4.4.1, gcc-4.5.0 and gcc-trunk (as of
2010/08/09):

//---
template  class foo;

template class C, int... II, int S>
struct foo,S>
{
struct bar {};
};

template 
struct A {};

foo, 4>::bar x;
//---

g++ output:
g++ -std=c++0xteste.cpp   -o teste
teste.cpp:12:1: error: ‘bar’ in class ‘foo, 4>’ does not name a type


-- 
   Summary: Can't access nested type of a partial class
specialization involving variadic parameters
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rodolfo at rodsoft dot org
 GCC build triplet: x86_64-pc-linux-gnu
  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=45236

[Bug rtl-optimization/45235] const volatile read moved out of order

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-08-09 13:56 ---
Probably easier to not set TREE_READONLY or MEM_READONY_P here.

Index: gcc/emit-rtl.c
===
--- gcc/emit-rtl.c  (revision 163030)
+++ gcc/emit-rtl.c  (working copy)
@@ -1669,7 +1670,8 @@ set_mem_attributes_minus_bitpos (rtx ref
   base = get_base_address (base);
   if (base && DECL_P (base)
  && TREE_READONLY (base)
- && (TREE_STATIC (base) || DECL_EXTERNAL (base)))
+ && (TREE_STATIC (base) || DECL_EXTERNAL (base))
+ && !TREE_THIS_VOLATILE (base))
MEM_READONLY_P (ref) = 1;

   /* If this expression uses it's parent's alias set, mark it such


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2010-08-09 13:56:06
   date||


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

[Bug libstdc++/45228] [C++0x] Can't copy-construct "tuple" from "const tuple" rvalue

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2010-08-09 13:44 
---
Note the specific constructor I mentioned:

  // XXX http://gcc.gnu.org/ml/libstdc++/2008-02/msg00047.html
  template
tuple(tuple<_UElements...>& __in)

we are *not* talking there about any of the constructors part of the user
interface, we are talking about a constructor added only for the purpose of
getting right special cases (having to do with cc qualifiers, conversions)
without resorting to SFINAE. I think we should be able to uniformly use *only*
constraining on the user visible constructors, for this issue too. Agreed?


-- 


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

[Bug libstdc++/45228] [C++0x] Can't copy-construct "tuple" from "const tuple" rvalue

[jason at redhat dot com]

--- Comment #5 from jason at redhat dot com  2010-08-09 13:38 ---
Subject: Re:  [C++0x] Can't copy-construct "tuple"
 from "const tuple" rvalue

On 08/09/2010 09:31 AM, paolo dot carlini at oracle dot com wrote:
> I'm also thinking that the weird constructor tuple(tuple<_UElements...>&  
> __in),
> which has been suggested at the time by Peter Dimov, falls under the same
> reasoning and should be removed, the actual issue sorted out elsewhere again
> through SFINAE.

Removed?  To be clear, I was suggesting that you keep the constructor, 
just prevent it from being selected when the deduced parameter type is 
reference-related to the enclosing class.

Jason


-- 


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

[Bug libstdc++/45228] [C++0x] Can't copy-construct "tuple" from "const tuple" rvalue

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2010-08-09 13:31 
---
Thanks for the clarification Jason. Indeed, I think the most robust fix is
using SFINAE, and actually we have already quite a bit of language in the FCD
about tuple constuctors vs constraining, I think it's time to look into that in
detail.

I'm also thinking that the weird constructor tuple(tuple<_UElements...>& __in),
which has been suggested at the time by Peter Dimov, falls under the same
reasoning and should be removed, the actual issue sorted out elsewhere again
through SFINAE. If you think differently, just let me know here... Thanks
again.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-09 13:31:39
   date||


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

[Bug tree-optimization/44632] [4.4/4.5 regression] wrong code for complex division

[rguenth at gcc dot gnu dot org]

--- Comment #19 from rguenth at gcc dot gnu dot org  2010-08-09 13:31 
---
Backports are pre-approved if they pass bootstrap & testing.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.4.4 4.5.0 4.6.0   |4.4.4 4.5.0
  Known to work|4.3.5   |4.3.5 4.6.0
Summary|[4.4/4.5/4.6 regression]|[4.4/4.5 regression] wrong
   |wrong code for complex  |code for complex division
   |division|


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

[Bug libstdc++/45228] [C++0x] Can't copy-construct "tuple" from "const tuple" rvalue

[jason at redhat dot com]

--- Comment #3 from jason at redhat dot com  2010-08-09 13:22 ---
Subject: Re:  [C++0x] Can't copy-construct "tuple"
 from "const tuple" rvalue

For tuple_m, you have a variadic template constructor that can take 
*any* arguments whatsoever, and will therefore be a better match than 
anything that doesn't have a specific constructor.  In this case, you're 
trying to create a tuple_m from a const tuple_m rvalue, and therefore 
the variadic template is instantiated to form tuple_m(const tuple_m&&), 
which is a better match than either tuple_m(const tuple_m&) or 
tuple_m(tuple_m&&).

For tuple_2, the T&& constructor requires two arguments, so this isn't 
an issue.

This is the same issue that we had with thread; I worked around that for 
the non-const lvalue case by adding thread(thread&) = delete, and you 
could do the same here by adding a const tuple_m&& overload.

But in general, I think any time you have a variadic constructor that 
can take a single T&&, you probably want to use SFINAE to make sure that 
it isn't chosen for a single argument of the enclosing class type.


-- 


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

[Bug tree-optimization/44632] [4.4/4.5/4.6 regression] wrong code for complex division

[rguenth at gcc dot gnu dot org]

--- Comment #18 from rguenth at gcc dot gnu dot org  2010-08-09 13:18 
---
Subject: Bug 44632

Author: rguenth
Date: Mon Aug  9 13:18:08 2010
New Revision: 163031

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163031
Log:
2010-08-09  Richard Guenther  

PR middle-end/44632
* function.c (gimplify_parameters): Do not clear addressable
bit of the original parameter.

* g++.dg/opt/nrv17.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/opt/nrv17.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/45235] const volatile read moved out of order

[bigotp at acm dot org]

--- Comment #1 from bigotp at acm dot org  2010-08-09 11:57 ---
Created an attachment (id=21441)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21441&action=view)
fixes for assumption that readonly means constant

The problem is caused by the same sort of test as was fixed in a different
situation in #35729.  In the attached patch, it is the change to
rtanal.c:rtx_varies_p that fixes the problem.  The remaining changes are
plausible, but I don't know whether they're necessary.  There are additional
uses of MEM_READONLY_P that are also questionable, that I didn't get around
to trying.  I suggest a thorough review by somebody who, unlike me, knows GCC
internals.


-- 


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

[Bug rtl-optimization/45235] New: const volatile read moved out of order

[bigotp at acm dot org]

This example is reduced from hardware-specific code that uses memory-mapped
registers to control and sample a logical signal.  The read of the input signal
is moved to follow the clear of the output signal, in violation of the
requirements for volatile memory access.

Reproduce with:  gcc -S -O2 ira-bug.c

Examine the generated assembly code to verify the read of in has moved to
follow the second write of out within the loop body.

The presence of the const qualifier on the in variable enables the bug; if the
qualifier is removed the original order is retained.


volatile const short int in;
volatile short int out;

void func () {
  short int value;
  do {
out |= 2;
value = in;
out &= ~2;
  } while (value & 1);
}


-- 
   Summary: const volatile read moved out of order
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bigotp at acm dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  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=45235

[Bug target/45212] [4.6 Regression] FAIL: gcc.target/alpha/pr24178.c scan-assembler ldl.*,18\\\\(

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-08-09 11:53 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/44632] [4.4/4.5/4.6 regression] wrong code for complex division

[rguenther at suse dot de]

--- Comment #17 from rguenther at suse dot de  2010-08-09 11:51 ---
Subject: Re:  [4.4/4.5/4.6 regression] wrong
 code for complex division

On Mon, 9 Aug 2010, dave at hiauly1 dot hia dot nrc dot ca wrote:

> --- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca  2010-08-09 
> 11:44 ---
> Subject: Re:  [4.4/4.5/4.6 regression] wrong
> 
> > t]':/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include/tr1/poly_lagu=
> > erre.tcc:106:5: internal compiler error: in simplify_subreg, at simplify-rt=
> > x.c:5129
> 
> No, it is present without change.
> 
> Should the fix be backported?

Probably yes.  I'm testing the fix on x86_64-linux now together with
a testcase and will apply it to trunk.  If you can do a bootstrap
and regtest on the 4.4 branch as well that would be nice.

Thx.


-- 


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

[Bug tree-optimization/44632] [4.4/4.5/4.6 regression] wrong code for complex division

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca  2010-08-09 
11:44 ---
Subject: Re:  [4.4/4.5/4.6 regression] wrong

> The following might be a regression:
> Executing on host: /home/dave/gnu/gcc/objdir/./gcc/g++ -shared-libgcc -B/ho=
> me/dave/gnu/gcc/objdir/./gcc -nostdinc++ -L/home/dave/gnu/gcc/objdir/hppa-l=
> inux/libstdc++-v3/src -L/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/s=
> rc/.libs -B/home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/bin/ -B/home/dave/op=
> t/gnu/gcc/gcc-4.6.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.6=
> =2E0/hppa-linux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linu=
> x/sys-include -B/home/dave/gnu/gcc/objdir/hppa-linux/./libstdc++-v3/src/.li=
> bs -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=3D0 -ffunction-sections -fdata=
> -sections -g -O2 -D_GNU_SOURCE -g -O2 -D_GNU_SOURCE -DLOCALEDIR=3D"." -nost=
> dinc++ -I/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include/hppa-lin=
> ux -I/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include -I/home/dave=
> /gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/i=
> nclude/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util /home/=
> dave/gnu/gcc/gcc/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_=
> functions/01_assoc_laguerre/check_nan.cc-include bits/stdc++.h ./libtes=
> tc++.a -Wl,--gc-sections  -lm   -o ./check_nan.exe(timeout =3D 600)
> In file included from /home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/inc=
> lude/tr1/cmath:95:0, from /home/dave/gnu/gcc/gcc/libstdc++-=
> v3/testsuite/tr1/5_numerical_facilities/special_functions/01_assoc_laguerre=
> /check_nan.cc:25:/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include/=
> tr1/poly_laguerre.tcc: In function '_Tp std::tr1::__detail::__poly_laguerre=
> _large_n(unsigned int, _Tpa, _Tp) [with _Tpa =3D unsigned int, _Tp =3D floa=
> t]':/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include/tr1/poly_lagu=
> erre.tcc:106:5: internal compiler error: in simplify_subreg, at simplify-rt=
> x.c:5129

No, it is present without change.

Should the fix be backported?


-- 


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

[Bug target/45212] [4.6 Regression] FAIL: gcc.target/alpha/pr24178.c scan-assembler ldl.*,18\\\\(

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-08-09 11:43 ---
Subject: Bug 45212

Author: rguenth
Date: Mon Aug  9 11:43:23 2010
New Revision: 163029

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163029
Log:
2010-08-09  Richard Guenther  

PR middle-end/45212
* emit-rtl.c (set_mem_attributes_minus_bitpos): Adjust
alignment from MEM_REF offset only if we took it from the
base object.

* gcc.target/i386/pr24178.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr24178.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/emit-rtl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/44632] [4.4/4.5/4.6 regression] wrong code for complex division

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca  2010-08-09 
11:37 ---
Subject: Re:  [4.4/4.5/4.6 regression] wrong

> 
> On Sat, 07 Aug 2010, rguenth at gcc dot gnu dot org wrote:
> 
> > So the following should fix this.  Can you bootstrap/test this?

Oh, I forgot to say test.cxx testcase is fixed.


-- 


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

[Bug tree-optimization/44632] [4.4/4.5/4.6 regression] wrong code for complex division

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca  2010-08-09 
11:35 ---
Subject: Re:  [4.4/4.5/4.6 regression] wrong
code for complex division

On Sat, 07 Aug 2010, rguenth at gcc dot gnu dot org wrote:

> So the following should fix this.  Can you bootstrap/test this?

Test results are here:
http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg00900.html

The following might be a regression:
Executing on host: /home/dave/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/home/dave/gnu/gcc/objdir/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/src/.libs
-B/home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/include -isystem
/home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/sys-include
-B/home/dave/gnu/gcc/objdir/hppa-linux/./libstdc++-v3/src/.libs -g -O2
-D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include/hppa-linux
-I/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/01_assoc_laguerre/check_nan.cc
   -include bits/stdc++.h ./libtestc++.a -Wl,--gc-sections  -lm   -o
./check_nan.exe(timeout = 600)
In file included from
/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include/tr1/cmath:95:0,  
  from
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/01_assoc_laguerre/check_nan.cc:25:/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include/tr1/poly_laguerre.tcc:
In function '_Tp std::tr1::__detail::__poly_laguerre_large_n(unsigned int,
_Tpa, _Tp) [with _Tpa = unsigned int, _Tp =
float]':/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include/tr1/poly_laguerre.tcc:106:5:
internal compiler error: in simplify_subreg, at simplify-rtx.c:5129


-- 


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

[Bug fortran/45128] Segmentation fault with -fwhole-file for subref_array_pointer

[paul dot richard dot thomas at gmail dot com]

--- Comment #2 from paul dot richard dot thomas at gmail dot com  
2010-08-09 10:50 ---
Subject: Re:  Segmentation fault with -fwhole-file for 
subref_array_pointer

Dear Tobias,

> If one now recycles the definition for the array descriptor "desc" this
> information is not present. I think the real solution is the new array
> descriptor. I do not know how to fix this otherwise - except by always
> generating a span variable.

This has occurred to me more than once!

>
> Paul - any progress from the array-descriptor front?

Yes, I made a small start whilst on vacation.  I have embarked on the
first step of the project, which is to add to the existing dimension
triplet the stride measure (sm) and extent fields.  On top of that, I
added an extra field to the descriptor itself, which does nothing but
uncover all the accesses to the descriptor fields that do not use the
ABI in trans-array.c.  I just reached the stage of plugging all the
segfaults arising from the latter.  The next step is to evaluate the
sm and extent fields, in parallel to the stride and upper fields, just
to check all is well.  Then will come the crucial step of using the
new fields for evaluation of array references.  I suspect that there
will be a substantial performance hit in the scalarizer and problems
with the library, both of which will require time to fix.  Then, the
stride and upper fields can be taken away.  Finally, all the extra
fields can be added to the descriptor.

I will have some time to work on this next week.

Cheers

Paul


-- 


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

[Bug target/15087] IA64: Wrong alignment for structure > 8 byte

[michael dot haubenwallner at salomon dot at]

--- Comment #5 from michael dot haubenwallner at salomon dot at  2010-08-09 
08:49 ---
Well, I'm waiting for this to become fixed, even if it isn't a real blocker
here.
There is a workaround (=ugly hack) using alignment attributes within #ifdef's
for the rare cases where this really is a problem - mallinfo() only for now
here.
But IIRC somewhere there was a note from an Oracle developer having to avoid
gcc on ia64-hpux because of this bug...
Found it: in PR30826, maybe a dup?


-- 


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

[Bug c/45207] The -Os flag generates wrong code for ARM966e-s

[fredrik dot hederstierna at securitas-direct dot com]

--- Comment #8 from fredrik dot hederstierna at securitas-direct dot com  
2010-08-09 07:55 ---
I think I found what was the problem, the flags

-mthumb -mcpu=arm966e-s -Os -falign-functions=4

Did not 32-bit-align my thumb->arm trampoline function.
I dont know if -Os win over -falign-functions flag in this case.
Anyway, my function ended up on a 16-bit aligned address and that caused an
abort.

/Fredrik


-- 


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

[Bug libstdc++/44963] [DR 1334] Ambiguous function overload using __gnu_cxx::crope with std::back_inserter in c++0x mode

[paolo dot carlini at oracle dot com]

--- Comment #13 from paolo dot carlini at oracle dot com  2010-08-09 07:31 
---
Any help with it would be appreciated, thanks. In general, if you mean to
contribute it's a good idea to sort out first the Copyright Assignment
paperwork, which is actually very simple but takes time:
http://gcc.gnu.org/contribute.html Thus get the forms from assignme...@. Then,
it would be nice if before larger rewrites we could figure out more localized
improvements to rope.


-- 


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