date:20071113

[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin

2007-11-13 Thread dominiq at lps dot ens dot fr



--- Comment #7 from dominiq at lps dot ens dot fr  2007-11-13 08:01 ---
Created an attachment (id=14539)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14539&action=view)
"Good" assembly code.


-- 


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

[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin

2007-11-13 Thread dominiq at lps dot ens dot fr



--- Comment #9 from dominiq at lps dot ens dot fr  2007-11-13 08:10 ---
> and the from the debugger which field of the array caused the abort and maybe 
> even good 
> and bad char_cshift_2.*.fwprop* dumps?  Can you hit breakpoint on 
> _gfortran_cshift1_4_char 
> and _gfortran_cshift1_8_char and compare the incoming and outgoing arrays 
> between a good 
> and bad version?

This will take a little more time (I have to restore the revision and rebuild
gcc). I have printed the
arrays a and b, and with shift4 the first 4 lines, i.e., b(:,1:2,1) is
different from the corresponding a's.

Do you know the important differences in the config files for Darwin8 and
Linux?


-- 


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

[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin

2007-11-13 Thread dominiq at lps dot ens dot fr



--- Comment #8 from dominiq at lps dot ens dot fr  2007-11-13 08:02 ---
Created an attachment (id=14540)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14540&action=view)
"Bad" assembly code.


-- 


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

[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin

2007-11-13 Thread bonzini at gnu dot org



--- Comment #10 from bonzini at gnu dot org  2007-11-13 08:16 ---
Anyway, it looks like a latent bug somewhere else.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


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

[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin

2007-11-13 Thread bonzini at gnu dot org



--- Comment #11 from bonzini at gnu dot org  2007-11-13 08:21 ---
Since you are at it, could you test on *exactly* the involved revisions, i.e.
130042 and 130043?


-- 


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

[Bug tree-optimization/33860] [4.3 Regression] ICE in vectorizable_load, at tree-vect-transform.c:5503

2007-11-13 Thread tbm at cyrius dot com



--- Comment #6 from tbm at cyrius dot com  2007-11-13 08:27 ---
So I guess this can be closed?


-- 

tbm at cyrius dot com changed:

   What|Removed |Added

 CC||dorit at gcc dot gnu dot org


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

[Bug target/33923] [4.3 Regression] ICE in reload_cse_simplify_operands (insn does not satisfy its constraints)

2007-11-13 Thread tbm at cyrius dot com



--- Comment #8 from tbm at cyrius dot com  2007-11-13 08:29 ---
Would be great if some IA64 people could comment on the patch.


-- 

tbm at cyrius dot com changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu dot
   ||org


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

[Bug fortran/34079] New: Bind(C): Don't pass the string length as argument (for STDCALL)

2007-11-13 Thread burnus at gcc dot gnu dot org

Using STDCALL, not the callee but the called procedure pops the arguments from
the stack. The problem is that gfortran currently also for BIND(C) passes the
string lengths as arguments.

See also:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/19d77dfc75f8be58


-- 
   Summary: Bind(C): Don't pass the string length as argument (for
STDCALL)
   Product: gcc
   Version: 4.3.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=34079

[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin

2007-11-13 Thread dominiq at lps dot ens dot fr



--- Comment #12 from dominiq at lps dot ens dot fr  2007-11-13 08:42 ---
Subject: Re:  [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3
-funroll-loops fails on Intel Darwin

> Since you are at it, could you test on *exactly* the involved revisions, i.e.
> 130042 and 130043?

Yes, but allow for more time!-)

Meanwhile, I have restored the changes of revision 130043 and the bug did not
reappeared, wierd!-(


-- 


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

[Bug fortran/34008] ICE in gfc_trans_call, at fortran/trans-stmt.c:389 on elemental assignment

2007-11-13 Thread dominiq at lps dot ens dot fr



--- Comment #3 from dominiq at lps dot ens dot fr  2007-11-13 08:52 ---
The patch works as advertised without regression on both PPC and Intel Darwin8.


-- 


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

[Bug fortran/34080] New: Transfer was working, now broken

2007-11-13 Thread drewmccormack at mac dot com

I have code that was previously working with gfortran and now is broken. The
problem has to do with the 'transfer' intrinsic. If I transfer a character
string into an array of a different type, and then transfer the array back to a
string, the result is not the original string, but apparently random bytes.

I have prepared sample code to demonstrate:


module TransferBug

   type ByteType
  private
  character(len=1)  :: singleByte
   end type

   type (ByteType), save:: BytesPrototype(1)

contains

   function StringToBytes(v) result (bytes)
  character(len=*), intent(in)  :: v
  type (ByteType)   ::
bytes(size(transfer(v, BytesPrototype)))
  bytes = transfer(v, BytesPrototype)
   end function

   subroutine BytesToString(bytes, string)
  type (ByteType), intent(in)   :: bytes(:)
  character(len=*), intent(out) :: string
  character(len=1)  :: singleChar(1)
  integer   :: numChars
  numChars = size(transfer(bytes,singleChar))
  string = ''
  string = transfer(bytes, string)
  string(numChars+1:) = ''
   end subroutine

end module


program main
   use TransferBug
   character(len=100) :: str
   call BytesToString( StringToBytes('Hi'), str )
   print *, trim(str)   ! This should print 'Hi'
end program


-- 
   Summary: Transfer was working, now broken
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drewmccormack at mac dot com
 GCC build triplet: 4.3.0 20071026 (experimental)
GCC target triplet: powerpc-apple-darwin9.0.0


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

[Bug target/34081] New: [4.3 Regression] ICE in s390_function_value, at config/s390/s390.c:7880

2007-11-13 Thread rguenth at gcc dot gnu dot org

gcc -v
Using built-in specs.
Target: s390x-suse-linux
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local
--infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64
--libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3.0
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --program-suffix=-4.3
--enable-version-specific-runtime-libs --without-system-libunwind
--with-tune=z9-109 --with-arch=z900 --with-long-double-128
--build=s390x-suse-linux
Thread model: posix
gcc version 4.3.0 20071109 (experimental) [trunk revision 130038] (SUSE Linux) 

/usr/lib64/gcc/s390x-suse-linux/4.3.0/cc1plus -w -Wfatal-errors -fpreprocessed
fam.min.ii -quiet -dumpbase fam.c++ -version -o /dev/null
GNU C++ (SUSE Linux) version 4.3.0 20071109 (experimental) [trunk revision
130038] (s390x-suse-linux)
compiled by GNU C version 4.3.0 20071109 (experimental) [trunk revision
130038], GMP version 4.2.1, MPFR version 2.3.0.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: fa0dba4316cd7f190032018dbf935c39
fam.min.ii: In member function 'BTree::Closure::operator BTree::Status()':
fam.min.ii:148: internal compiler error: in s390_function_value, at
config/s390/s390.c:7880
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.3 Regression] ICE in s390_function_value, at
config/s390/s390.c:7880
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: s390-*-*, s390x-*-*


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

[Bug target/34081] [4.3 Regression] ICE in s390_function_value, at config/s390/s390.c:7880

2007-11-13 Thread rguenth at gcc dot gnu dot org



--- Comment #1 from rguenth at gcc dot gnu dot org  2007-11-13 10:00 ---
Created an attachment (id=14541)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14541&action=view)
reduced testcase


-- 


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

[Bug target/34077] GCC -O1 -minline-all-stringops -minline-stringops-dynamically fails for spec 2006 bzip2, gobmk, and h264ref benchmarks

2007-11-13 Thread rguenth at gcc dot gnu dot org



--- Comment #2 from rguenth at gcc dot gnu dot org  2007-11-13 10:19 ---
I think ix86_expand_movemem should not call emit_cmp_and_jump_insns with
constant
tests.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org, hubicka at gcc dot gnu
   ||dot org


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

[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin

2007-11-13 Thread dominiq at lps dot ens dot fr



--- Comment #13 from dominiq at lps dot ens dot fr  2007-11-13 10:40 ---
Created an attachment (id=14542)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14542&action=view)
Comparison between revisions 130042 and 130043 with -O2 -funroll-loops and with
-O1+all the others

bzip2 tar archive with four directories r42_O1, r42_O2, r43_O1, and r43_O2
containing the result of -fdump-tree-all and the assembly codes for the
different revisions and options (see comment #2).


-- 


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

[Bug tree-optimization/34063] [4.3 Regression] ICE: build2_stat, at tree.c:3115

2007-11-13 Thread jakub at gcc dot gnu dot org



--- Comment #3 from jakub at gcc dot gnu dot org  2007-11-13 10:26 ---
Either we should use correct order of arguments in chrec_evaluate (that
function
is swapping CHREC_LEFT based expression with CHREC_RIGHT based expression
for pointer_plus addition) - testing patch for that - or chrec_fold_plus_1
should swap op0 with op1 if code is POINTER_PLUS_EXPR and the first argument
has integer type, but second POINTER_TYPE_P.


-- 


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

[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin

2007-11-13 Thread dominiq at lps dot ens dot fr



--- Comment #14 from dominiq at lps dot ens dot fr  2007-11-13 10:41 ---
Could you try to "compile" the assembly code in r43_O2 and see if you get the
abort?


-- 


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

[Bug c++/34054] [4.3 regression] ICE with parameter pack in return type

2007-11-13 Thread jakub at gcc dot gnu dot org



--- Comment #1 from jakub at gcc dot gnu dot org  2007-11-13 11:38 ---
Mine.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-13 11:38:42
   date||


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

[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin

2007-11-13 Thread paolo dot bonzini at lu dot unisi dot ch



--- Comment #15 from paolo dot bonzini at lu dot unisi dot ch  2007-11-13 
11:43 ---
Subject: Re:  [4.3 regression] gfortran.dg/char_cshift_2.f90
 fails with -O3 -funroll-loops fails on Intel Darwin


> bzip2 tar archive with four directories r42_O1, r42_O2, r43_O1, and r43_O2
> containing the result of -fdump-tree-all and the assembly codes for the
> different revisions and options (see comment #2).

Please use -fdump-rtl-all since fwprop is not a tree pass. :-)

Also, please check if the bug appears disappears with

-O2 -fno-forward-propagate -funroll-loops

versus

-O2 -funroll-loops

in both 130042 and 130043.  If the -fno-forward-propagate would make a 
difference, this would be a great way to narrow the bug.

Paolo


-- 


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

[Bug c++/34056] [4.3 regression] ICE with parameter pack and pointer

2007-11-13 Thread jakub at gcc dot gnu dot org



--- Comment #1 from jakub at gcc dot gnu dot org  2007-11-13 12:12 ---
The set_packs_to_error stuff is very problematic in this case, because
trees are shared and the C++ FE certainly doesn't expect error_mark_nodes
to appear at random places.
In this case T* type is shared (as the pointer to T has been cached).
check_for_bare_parameter_packs should have errored about this twice, but will
do only once because of the sharing and in the second case just won't fail,
so doesn't let the caller to deal with the errorneous type.


-- 


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

[Bug tree-optimization/33319] [4.2 regression] g++.dg/tree-ssa/pr27549.C ICE with vectorization

2007-11-13 Thread victork at gcc dot gnu dot org



--- Comment #12 from victork at gcc dot gnu dot org  2007-11-13 12:26 
---
> Still fails on 4.2 branch.

I've just tried with 4.2 on PPC from svn and it did not ICE:
./gcc/cc1plus -O3 -ftree-vectorize -maltivec ~/42/build/pr27549.C
Can we close this PR?


-- 


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

[Bug fortran/34040] [4.3 Regression] ICE: in simplify_subreg, at simplify-rtx.c:4921 building libgfortran

2007-11-13 Thread fxcoudert at gcc dot gnu dot org



--- Comment #5 from fxcoudert at gcc dot gnu dot org  2007-11-13 12:28 
---
(In reply to comment #4)
> __builtin_copysign has got SFmode(*)(SFmode, SFmode) prototype and is invoked
> on DFmode arguments.

copysign takes doubles and returns a double. Does the SH double have SF mode in
the conditions of this PR? It is assumed, throughout the Fortran front-end,
that SF mode corresponds to float, and DF corresponds to double. (This will be
changed for 4.4, but not before... it's a most significant reworking.)


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org


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

[Bug fortran/33759] Unequal character lengths in MERGE intrinsic not detected at run time

2007-11-13 Thread pault at gcc dot gnu dot org



--- Comment #10 from pault at gcc dot gnu dot org  2007-11-13 12:46 ---
(In reply to comment #9)

> > This patch is OK.
> Yes indeed, I have applied it a long time ago.

As I found out minutes after I posted this note - thanks!

> I have only pointed to the last bug on transfer I know of.
> > It is only at the default logical length that it fails!

The optimizer is doing something horrible to the code in
transfer_simplify_4.f90; I have CC'd Andrew in the hope that he can shed some
light on it:

As an experiment, I tried the following patch to circumvent the mashing up of
the logical by BUILT_IN_MEMCPY when transferring between LOGICAL and INTEGER:

Index: gcc/fortran/trans-intrinsic.c
===
*** gcc/fortran/trans-intrinsic.c   (révision 130095)
--- gcc/fortran/trans-intrinsic.c   (copie de travail)
*** gfc_conv_intrinsic_transfer (gfc_se * se
*** 3277,3282 
--- 3277,3291 
se->expr = ptr;
se->string_length = argse.string_length;
  }
+   else if (expr->value.function.actual->expr->ts.kind == expr->ts.kind
+&& ((expr->value.function.actual->expr->ts.type == BT_LOGICAL
+   && expr->ts.type == BT_INTEGER)
+||  (expr->value.function.actual->expr->ts.type == BT_INTEGER
+   && expr->ts.type == BT_LOGICAL)))
+ {
+   ptr = convert (build_pointer_type (type), ptr);
+   se->expr = build_fold_indirect_ref (ptr);
+ }
else
  {
tree moldsize;

The example in comment #6 now works at any level of optimization, even without
the PRINT statement (the reason why I mention this will be apparent in a
moment).

transfer_simplify_4.f90 itself fails in the third block, at -O2 and higher,
whereas it failed at all levels of optimization withhout the patch.

  a = transfer(ip1, .true.)
  i = transfer(a, 0)
  if (i .ne. ip1) call abort ()

Adding a PRINT *, a; or a PRINT *, i; anywhere in the program allows it to work
at any level of optimization.  This is true, even if the PRINT replaces one of
the call abort's.

I have looked to see what the i/o might be doing but cannot understand it at
all.

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin

2007-11-13 Thread dominiq at lps dot ens dot fr



--- Comment #16 from dominiq at lps dot ens dot fr  2007-11-13 13:18 ---
> Also, please check if the bug appears disappears with

> -O2 -fno-forward-propagate -funroll-loops

It disappears with -fno-forward-propagate (rev 130043).


-- 


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

[Bug tree-optimization/33319] [4.2 regression] g++.dg/tree-ssa/pr27549.C ICE with vectorization

2007-11-13 Thread victork at gcc dot gnu dot org



--- Comment #13 from victork at gcc dot gnu dot org  2007-11-13 13:26 
---
I've just tested it with 4.2 on x86 on it worked OK as well.


-- 


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

[Bug tree-optimization/33860] [4.3 Regression] ICE in vectorizable_load, at tree-vect-transform.c:5503

2007-11-13 Thread dorit at gcc dot gnu dot org



--- Comment #7 from dorit at gcc dot gnu dot org  2007-11-13 13:29 ---
fixed


-- 

dorit at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class

2007-11-13 Thread p dot vestjens at gmail dot com



--- Comment #5 from p dot vestjens at gmail dot com  2007-11-13 13:38 
---
Okay. First of all the code causing the problems isn't actually my own code. It
is used in the Connexis middleware layer of IBM's Rational Rose Real-Time
application. The reproduce.cpp file was created by IBM's support department to
reproduce the problem. They claim that the file compiles with the GNU 3.2
compiler but not with the GNU 3.4.4 and 4.1.0 compilers. I'm using GNU 4.1.1
which also doesn't compile the code, but WindRiver's Tornado 2 GNU 2.7.2 and
the MS Visual Studio 6 compiler do.

The problem seems to lie in the abundant use of parentheses:
- "list = new (pure(*[3]));" => does not compile
- "list = new (pure*[3]);" => compiles
- "list = new pure(*[3]);" => does not compile
- "list = new pure*[3];" => compiles

So, the only question still relevant to me is whether the original construction
is valid C++ code according to the ISO C++ standard. I tried verifying this
using the grammar printed in Stroustrup's "C++ Programming language (third
edition" but did not quite succeed. I guess grammatically it is ok, but
semantically the GCC compiler interprets the construction differently from its
previous version(s).

How do we determine if the original construction is correct, both grammatically
and semantically? If it isn't valid, IBM should fix their code. If it is, there
might be a bug in GCC.


-- 


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

[Bug c++/34056] [4.3 regression] ICE with parameter pack and pointer

2007-11-13 Thread jakub at gcc dot gnu dot org



--- Comment #2 from jakub at gcc dot gnu dot org  2007-11-13 13:43 ---
Testing a fix.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-13 13:43:49
   date||


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

[Bug c++/34057] [4.3 regression] ICE with variadic template and vector attribute

2007-11-13 Thread jakub at gcc dot gnu dot org



--- Comment #1 from jakub at gcc dot gnu dot org  2007-11-13 13:44 ---
Testing a fix.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-13 13:44:05
   date||


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

[Bug c++/34058] [4.3 regression] ICE with variadic template and typedef

2007-11-13 Thread jakub at gcc dot gnu dot org



--- Comment #1 from jakub at gcc dot gnu dot org  2007-11-13 13:44 ---
Testing a fix.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-13 13:44:22
   date||


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

[Bug c++/34060] [4.3 regression] ICE with invalid specialization of variadic template

2007-11-13 Thread jakub at gcc dot gnu dot org



--- Comment #1 from jakub at gcc dot gnu dot org  2007-11-13 13:44 ---
Testing a fix.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-11-13 13:44:56
   date||


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

[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin

2007-11-13 Thread dominiq at lps dot ens dot fr



--- Comment #17 from dominiq at lps dot ens dot fr  2007-11-13 13:46 ---
Created an attachment (id=14543)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14543&action=view)
outputs with -fdump-rtl-all

outputs with -fdump-rtl-all with -O2 -funroll-loops for revisions 130042 and
130043.


-- 


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

[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC

2007-11-13 Thread victork at gcc dot gnu dot org



--- Comment #36 from victork at gcc dot gnu dot org  2007-11-13 13:53 
---
Subject: Bug 32582

Author: victork
Date: Tue Nov 13 13:53:33 2007
New Revision: 130138

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130138
Log:
2007-11-13  Victor Kaplansky  <[EMAIL PROTECTED]>

PR tree-optimization/32582
* Makefile.in (CRTSTUFF_CFLAGS): Add -fno-tree-vectorize



Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in


-- 


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

[Bug fortran/34080] [regression] Transfer was working, now broken

2007-11-13 Thread fxcoudert at gcc dot gnu dot org



--- Comment #1 from fxcoudert at gcc dot gnu dot org  2007-11-13 13:55 
---
Confirmed on x86_64-linux.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|4.3.0 20071026  |
   |(experimental)  |
 GCC target triplet|powerpc-apple-darwin9.0.0   |
   Keywords||wrong-code
  Known to fail||4.3.0
   Last reconfirmed|-00-00 00:00:00 |2007-11-13 13:55:55
   date||
Summary|Transfer was working, now   |[regression] Transfer was
   |broken  |working, now broken


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

[Bug libf2c/34082] New: someinfo

2007-11-13 Thread jim3 at iq17 dot com

someinfo


-- 
   Summary: someinfo
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: libf2c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jim3 at iq17 dot com


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

[Bug libf2c/34082] someinfo

2007-11-13 Thread jim3 at iq17 dot com



--- Comment #1 from jim3 at iq17 dot com  2007-11-13 14:32 ---
aa


-- 

jim3 at iq17 dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/34079] Bind(C): Don't pass the string length as argument (for STDCALL)

2007-11-13 Thread burnus at gcc dot gnu dot org



--- Comment #1 from burnus at gcc dot gnu dot org  2007-11-13 14:39 ---
Example:

interface
  subroutine subiso(x) bind(c)
use iso_c_binding
character(kind=c_char,len=1), dimension(*) :: x
  end subroutine subiso
  subroutine subiso2(x) bind(c) ! { dg-warning "may not be C interoperable" }
character(len=1), dimension(*) :: x
  end subroutine subiso2
  subroutine sub(x)
use iso_c_binding
character(kind=c_char,len=1), dimension(*) :: x
  end subroutine sub
end interface
call sub("abcdef")
call subiso ("ABCDEF")
call subiso2("AbCdEf")
end

Dumped tree should look like:
  sub (&"abcdef"[1]{lb: 1 sz: 1}, 6);
  subiso (&"ABCDEF"[1]{lb: 1 sz: 1});
  subiso2 (&"ABCDEF"[1]{lb: 1 sz: 1});


Draft of a patch:

Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(Revision 130131)
+++ gcc/fortran/trans-expr.c(Arbeitskopie)
@@ -2390,8 +2390,8 @@ gfc_conv_function_call (gfc_se * se, gfc
 }

   /* Character strings are passed as two parameters, a length and a
- pointer.  */
-  if (parmse.string_length != NULL_TREE)
+ pointer - except for Bind(c) which only passes the pointer.  */
+  if (parmse.string_length != NULL_TREE && !sym->attr.is_bind_c)
 stringargs = gfc_chainon_list (stringargs, parmse.string_length);

   arglist = gfc_chainon_list (arglist, parmse.expr);


-- 


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

[Bug fortran/34080] [regression] Transfer was working, now broken

2007-11-13 Thread dominiq at lps dot ens dot fr



--- Comment #2 from dominiq at lps dot ens dot fr  2007-11-13 15:08 ---
Reduced test case:

module TransferBug

   type ByteType
  character(len=1)  :: singleByte
   end type

contains

   subroutine BytesToString(bytes, string)
  type (ByteType), intent(in)   :: bytes(:)
  character(len=*), intent(out) :: string
  string = 'Hi! '
!  print *, len(trim(string))  !  <-- works
  print *, len(transfer(bytes, string)) ! <-- gives garbage (crash with
g95)
   end subroutine

end module

program main
   use TransferBug
   character(len=100) :: str
   type (ByteType)   :: bytes(4)
   bytes = (/ByteType('t'), ByteType('e'), ByteType('s'), ByteType('t')/)
   call BytesToString( bytes, str )
   print *, trim(str)   ! This should print 'Hi!'
end program

[karma] f90/bug% gfc -fbounds-check pr34080_red.f90
[karma] f90/bug% a.out 
   0
 0låÅ¨0l0 ]Q(Ô¿ÿà`á
d
[karma] f90/bug% pgfc -fbounds-check pr34080_red.f90
[karma] f90/bug% a.out
 100
 Hi!

If I exchange the commented print lines, the code works. So the bug is related
to transfer, but apparently through some memory leak and not due to its result.


-- 


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

[Bug fortran/34083] New: internal compiler error: in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:2819

2007-11-13 Thread dominiq at lps dot ens dot fr

While looking at pr34080, I produced the following invalid code

module TransferBug

   type ByteType
  character(len=1)  :: singleByte
   end type

end module

program main
   use TransferBug
   type (ByteType)   :: bytes(4)
   print *, size(bytes)
   bytes = ByteType((/'H', 'i', '!', ' '/))  ! <-- ICE
!   bytes = (/ByteType('H'), ByteType('i'), ByteType('!'), ByteType(' ')/) !
<-- works
end program

which gives an ICE:

pr34080_ice.f90: In function 'MAIN__':
pr34080_ice.f90:12: internal compiler error: in
gfc_conv_array_constructor_expr, at fortran/trans-expr.c:2819


-- 
   Summary: internal compiler error: in
gfc_conv_array_constructor_expr, at fortran/trans-
expr.c:2819
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: powerpc-apple-darwin8
  GCC host triplet: powerpc-apple-darwin8
GCC target triplet: powerpc-apple-darwin8


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

[Bug tree-optimization/33870] [4.3 Regression] miscompiles sqlite

2007-11-13 Thread dnovillo at gcc dot gnu dot org

--- Comment #23 from dnovillo at gcc dot gnu dot org  2007-11-13 15:20 
---
Subject: Bug 33870

Author: dnovillo
Date: Tue Nov 13 15:20:40 2007
New Revision: 130141

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130141
Log:

pr 33870
* tree.h (strcut tree_memory_tag): add field unpartitionable.
remove field in_nested_struct.
(struct tree_struct_field_tag): add field nesting_level.
(sft_in_nested_struct): remove.
(sft_nesting_level): define.
(sft_unpartitionable_p): define.
* tree-ssa-alias.c (mem_sym_score): if mp->var is not
partitionable, return long_max.
(compute_memory_partitions): do not partition sfts marked
unpartitionable.
(create_sft): add argument nesting_level.  set
sft_nesting_level with it.  update all users.
(create_overlap_variables_for): show nesting level.
* tree-dfa.c (dump_subvars_for): likewise.
(dump_variable): likewise.
show whether the sft is partitionable or not.
* tree-flow.h (struct fieldoff): remove field
in_nested_struct.
add field nesting_level.
* tree-ssa-structalias.c (struct variable_info): remove
field in_nested_struct.
(push_fields_onto_fieldstack): add argument
nesting_level.  update all users.
update documentation.
update pair->nesting_level with nesting_level.
make recursive calls with nesting_level + 1.
(set_uids_in_ptset): if an sft is added to the points-to
set, mark it as unpartitionable.
* tree-ssa-operands.c (ref_nesting_level): new.
(add_vars_for_offset): call it.
add argument full_ref.  update
callers.
if var is inside a nested structure and the nesting level
of full_ref is lower than the nesting level of var,
adjust offset by the offset of var.

testsuite/ChangeLog

PR 33870
* gcc.c-torture/execute/pr33870-1.c: New test.
* gcc.dg/tree-ssa/alias-16.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr33870-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/alias-16.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-dfa.c
trunk/gcc/tree-flow.h
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-operands.c
trunk/gcc/tree-ssa-structalias.c
trunk/gcc/tree.h

-- 

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

[Bug fortran/34083] internal compiler error: in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:2819

2007-11-13 Thread burnus at gcc dot gnu dot org



--- Comment #1 from burnus at gcc dot gnu dot org  2007-11-13 15:44 ---
Confirmed.  NAG f95 reports:

Error: aa.f90, line 13: Array value for scalar component SINGLEBYTE of type
BYTETYPE


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|powerpc-apple-darwin8   |
   GCC host triplet|powerpc-apple-darwin8   |
 GCC target triplet|powerpc-apple-darwin8   |
   Keywords||ice-on-invalid-code
  Known to fail||4.1.3 4.2.2 4.3.0
   Last reconfirmed|-00-00 00:00:00 |2007-11-13 15:44:50
   date||


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

[Bug tree-optimization/33870] [4.3 Regression] miscompiles sqlite

2007-11-13 Thread dnovillo at gcc dot gnu dot org



--- Comment #24 from dnovillo at gcc dot gnu dot org  2007-11-13 15:47 
---

Fixed.  http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00719.html


-- 

dnovillo at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/34080] [4.3 regression] Transfer was working, now broken

2007-11-13 Thread burnus at gcc dot gnu dot org



--- Comment #3 from burnus at gcc dot gnu dot org  2007-11-13 15:51 ---
I did not do proper regression tests, but it works using
  4.3.0 20071016 (experimental) [trunk revision 129378] (SUSE Linux)
which has presumably no Fortran patches applied.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org
  Known to work||4.2.1 4.1.3
Summary|[regression] Transfer was   |[4.3 regression] Transfer
   |working, now broken |was working, now broken


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

[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

2007-11-13 Thread jakub at gcc dot gnu dot org



--- Comment #18 from jakub at gcc dot gnu dot org  2007-11-13 15:57 ---
Is this still reproduceable with current trunk?


-- 


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

[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin

2007-11-13 Thread dominiq at lps dot ens dot fr



--- Comment #18 from dominiq at lps dot ens dot fr  2007-11-13 15:58 ---
At revision 130137 the minimal flags are:

[ibook-dhum] f90/bug% gfc -O1 -funroll-loops -fschedule-insns -fregmove
-fexpensive-optimizations -fforward-propagate
char_cshift_2_red_1.f90[ibook-dhum] f90/bug% a.out
 test 2
 'adf'  'acf'  'adf'   1   1   2   1
 'bdf'  'bcf'  'bdf'   2   1   2   1
 'aef'  'adf'  'aef'   1   2   3   1
 'bef'  'bdf'  'bef'   2   2   3   1
 'acf'  'aef'  'acf'   1   3   1   1
 'bcf'  'bef'  'bcf'   2   3   1   1
Abort
[ibook-dhum] f90/bug% gfc -O1 -funroll-loops -fregmove
-fexpensive-optimizations -fforward-propagate char_cshift_2_red_1.f90
[ibook-dhum] f90/bug% a.out
 test 2
 'bdf'  'bcf'  'bdf'   2   1   2   1
 'bef'  'bdf'  'bef'   2   2   3   1
 'bcf'  'bef'  'bcf'   2   3   1   1
Abort

where the printed lines come from

 print *, "'", a (i1, i2p, i3), "'  '", b (i1, i2, i3), "'  '", b
(i1, i2p, i3), "'", i1, i2, i2p, i3


-- 


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

Patch: bootstrap broken when building boehm-gc

2007-11-13 Thread Manfred Hollstein

Hi there,

I'm not sure if there's something broken on my system(s), but here we
go. Building current gcc from HEAD "Tue Nov 13 11:39:03 UTC 2007
(revision 130136)" fails for me on i686-suse10-linux-gnu and
x86_64-suse10-linux-gnu; I'm using gcc-4.2.2 and binutils-2.18 for
bootstrapping and configured the stuff as follows:

  env CC=gcc CFLAGS=-O2 CXXFLAGS='-O2 -g' GCJFLAGS='-O2 -g' LDFLAGS=-s
  /bin/sh ../gcc-20071113/configure --host=$config --target=$config 
--build=$config
--srcdir=../gcc-20071113 --prefix=/opt/gnu --with-gnu-as --with-gnu-ld
--enable-multilib=yes --enable-__cxa_atexit --enable-checking=release
--enable-clocale=gnu --enable-interpreter --enable-shared
--enable-threads=posix --with-system-zlib --with-local-prefix=/opt/gnu
--enable-languages=c,c++,ada,java,fortran,objc --disable-nls --verbose

(No multilibs for i686-suse10-linux-gnu, of course). Up until boehm-gc,
the build runs without issues, but here it bails out:

  gmake[3]: Entering directory
  
`/home/gnu/work/GNU/gcc-20071113-x86_64-suse10-linux-gnu/x86_64-suse10-linux-gnu/boehm-gc'
  /bin/sh ./libtool --mode=compile 
/home/gnu/work/GNU/gcc-20071113-x86_64-suse10-linux-gnu/./gcc/xgcc 
-B/home/gnu/work/GNU/gcc-20071113-x86_64-suse10-linux-gnu/./gcc/ 
-B/opt/gnu/x86_64-suse10-linux-gnu/bin/ -B/opt/gnu/x86_64-suse10-linux-gnu/lib/ 
-isystem /opt/gnu/x86_64-suse10-linux-gnu/include -isystem 
/opt/gnu/x86_64-suse10-linux-gnu/sys-include -DHAVE_CONFIG_H 
-I/home/gnu/work/GNU/gcc-20071113/boehm-gc/include  -fexceptions -Iinclude 
-I././targ-include -I.//libc/include -O2 -O2   -fexceptions -Iinclude 
-I././targ-include -I.//libc/include  -c -o allchblk.lo 
../../../gcc-20071113/boehm-gc/allchblk.c
  libtool: compile: unable to infer tagged configuration
  libtool: compile: specify a tag with `--tag'
  gmake[3]: *** [allchblk.lo] Error 1
  gmake[3]: Leaving directory
  
`/home/gnu/work/GNU/gcc-20071113-x86_64-suse10-linux-gnu/x86_64-suse10-linux-gnu/boehm-gc'

The generated libtool script contains a line

  available_tags="CXX "

but no "--tag=whatsover" is passed when invoking libtool.  Looking at other
.../Makefile.in files, it appears that one has to pass e.g. "--tag=CC"
(like most files do), or "--tag=CXX" (as in libstdc++-v3/src/Makefile.in);
this option is missing in the definition of LTCOMPILE and LINK in both
boehm-gc/Makefile.am and boehm-gc/Makefile.in .

I have absolutely no idea why apparently nobody else is seeing this,
though.

The patch below fixes it for me. OK to check in?

Cheers.

l8er
manfred


boehm-gc/ChangeLog:
2007-11-13  Manfred Hollstein  <[EMAIL PROTECTED]>

* Makefile.ac (LTCOMPILE): Add missing "--tag=CC" argument;
wrap line to fit with 80 column rule.
(LINK): Likewise.
* Makefile.in: Regenerate.

diff -rup -x .svn -x CVS -x RCS -x '*.o' -x '*.info*' -x '*.elc' -x '*.dvi' -x 
'*.orig' -x '*~' -x version.el gcc-20071113.orig/boehm-gc/Makefile.am 
gcc-20071113/boehm-gc/Makefile.am
--- gcc-20071113.orig/boehm-gc/Makefile.am  2007-07-23 12:24:57.648580681 
+0200
+++ gcc-20071113/boehm-gc/Makefile.am   2007-11-13 16:45:34.792758499 +0100
@@ -64,9 +64,10 @@ TESTS = gctest
 
 ## We have our own definition of LTCOMPILE because we want to use our
 ## CFLAGS, not those passed in from the top level make.
-LTCOMPILE = $(LIBTOOL) --mode=compile $(CC) $(DEFS) $(AM_CPPFLAGS) $(CPPFLAGS) 
\
-   $(AM_CFLAGS) $(MY_CFLAGS) $(GC_CFLAGS) 
-LINK = $(LIBTOOL) --mode=link $(CC) $(AM_CFLAGS) $(MY_CFLAGS) $(LDFLAGS) -o $@
+LTCOMPILE = $(LIBTOOL) --tag=CC --mode=compile $(CC) $(DEFS) $(AM_CPPFLAGS) \
+   $(CPPFLAGS) $(AM_CFLAGS) $(MY_CFLAGS) $(GC_CFLAGS) 
+LINK = $(LIBTOOL) --tag=CC --mode=link $(CC) $(AM_CFLAGS) $(MY_CFLAGS) \
+   $(LDFLAGS) -o $@
 
 # Work around what appears to be a GNU make bug handling MAKEFLAGS
 # values defined in terms of make variables, as is the case for CC and
diff -rup -x .svn -x CVS -x RCS -x '*.o' -x '*.info*' -x '*.elc' -x '*.dvi' -x 
'*.orig' -x '*~' -x version.el gcc-20071113.orig/boehm-gc/Makefile.in 
gcc-20071113/boehm-gc/Makefile.in
--- gcc-20071113.orig/boehm-gc/Makefile.in  2007-07-23 12:33:53.628861021 
+0200
+++ gcc-20071113/boehm-gc/Makefile.in   2007-11-13 16:46:33.28565 +0100
@@ -300,10 +300,11 @@ gctest_LDADD = ./libgcjgc.la $(THREADLIB
 gctest_LDFLAGS = -shared-libgcc
 TESTS_ENVIRONMENT = LD_LIBRARY_PATH=../../$(MULTIBUILDTOP)gcc
 TESTS = gctest
-LTCOMPILE = $(LIBTOOL) --mode=compile $(CC) $(DEFS) $(AM_CPPFLAGS) $(CPPFLAGS) 
\
-   $(AM_CFLAGS) $(MY_CFLAGS) $(GC_CFLAGS) 
+LTCOMPILE = $(LIBTOOL) --tag=CC --mode=compile $(CC) $(DEFS) $(AM_CPPFLAGS) \
+   $(CPPFLAGS) $(AM_CFLAGS) $(MY_CFLAGS) $(GC_CFLAGS) 
 
-LINK = $(LIBTOOL) --mode=link $(CC) $(AM_CFLAGS) $(MY_CFLAGS) $(LDFLAGS)

[Bug fortran/34084] New: Error in November 9 version of gfortran when the first line in a source file is an INCLUDE statement

2007-11-13 Thread michael dot a dot richmond at nasa dot gov

The following error occurs in the November 9 snapshot version of gfortran. It
applies to all platforms. I compile the following program:

INCLUDE 'anything'
PROGRAM test_cg
END PROGRAM test_cg

The INCLUDE file can contain anything. I get the message:

f951: internal compiler error: in end_source_file, at fortran/scanner.c:327
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The error does not occur if I change the program to:

INCLUDE 'anything'
INCLUDE 'anything_2'
PROGRAM test_cg
END PROGRAM test_cg


-- 
   Summary: Error in November 9 version of gfortran when the first
line in a source file is an INCLUDE statement
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov


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

[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin

2007-11-13 Thread paolo dot bonzini at lu dot unisi dot ch



--- Comment #19 from paolo dot bonzini at lu dot unisi dot ch  2007-11-13 
16:46 ---
Subject: Re:  [4.3 regression] gfortran.dg/char_cshift_2.f90
 fails with -O3 -funroll-loops fails on Intel Darwin


> [ibook-dhum] f90/bug% gfc -O1 -funroll-loops -fschedule-insns -fregmove
> -fexpensive-optimizations -fforward-propagate
> char_cshift_2_red_1.f90[ibook-dhum] f90/bug% a.out
>  test 2
>  'adf'  'acf'  'adf'   1   1   2   1
>  'bdf'  'bcf'  'bdf'   2   1   2   1
>  'aef'  'adf'  'aef'   1   2   3   1
>  'bef'  'bdf'  'bef'   2   2   3   1
>  'acf'  'aef'  'acf'   1   3   1   1
>  'bcf'  'bef'  'bcf'   2   3   1   1
> Abort
> [ibook-dhum] f90/bug% gfc -O1 -funroll-loops -fregmove
> -fexpensive-optimizations -fforward-propagate char_cshift_2_red_1.f90
> [ibook-dhum] f90/bug% a.out
>  test 2
>  'bdf'  'bcf'  'bdf'   2   1   2   1
>  'bef'  'bdf'  'bef'   2   2   3   1
>  'bcf'  'bef'  'bcf'   2   3   1   1
> Abort

Can you attach a -fdump-rtl-all tarball for these two sets of options 
for revision 130137?  Thanks!

Paolo


-- 


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

[Bug tree-optimization/34063] [4.3 Regression] ICE: build2_stat, at tree.c:3115

2007-11-13 Thread jakub at gcc dot gnu dot org



-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-11-11 12:26:15 |2007-11-13 16:57:09
   date||


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

[Bug target/34067] [4.3 regression] gfortran.dg/char_cshift_2.f90 fails with -O3 -funroll-loops fails on Intel Darwin

2007-11-13 Thread dominiq at lps dot ens dot fr



--- Comment #20 from dominiq at lps dot ens dot fr  2007-11-13 16:59 ---
Created an attachment (id=14544)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14544&action=view)
outputs of -fdump-rtl-all for two set of options at -O1

The folder r137_O1_insns corresponds to -fschedule-insns. I have also added the
modified test whith printing.


-- 


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

[Bug tree-optimization/34043] Missed optimization causing extra loads and stores when using x86_64 builtin function together with aggregate types.

2007-11-13 Thread jsjodin at gcc dot gnu dot org



--- Comment #5 from jsjodin at gcc dot gnu dot org  2007-11-13 17:07 ---
(In reply to comment #4)
> Related to PR 33790 (and most likely fixed by it).  There is another issue 
> with
> that bug relating to not deleting the extra store.
> 

Indeed the extra load disappeared when with the patch. The store did not get
deleted as expected. I looked at the differences between the good and bad case. 
Compiling the good case has the following sequence before the fre pass:
Note: src and dst are unions

src.f = D.9650_45;
D.9630_31 = src.f;
D.9655_46 = __builtin_ia32_addps (D.9630_31, D.9630_31);
dst.f = D.9655_46;
D.9632_33 = dst.f;

After fre the temps have been propagated and replaced the uses of dst.f:

src.f = D.9650_45;  
D.9630_31 = D.9650_45;  
D.9655_46 = __builtin_ia32_addps (D.9630_31, D.9630_31);
dst.f = D.9655_46;  
D.9632_33 = D.9655_46;

The extra stores to src.f are eliminated in dce. 

The bad case has the following code before and after fre:
src.i = D.9651_44;  
D.9630_31 = src.f;  
D.9655_45 = __builtin_ia32_addps (D.9630_31, D.9630_31);
dst.f = D.9655_45;  
D.9632_33 = dst.i;   

Since the src.i and src.f are probably not considered to be the same the
propagation does not work. It might be possible to handle this case if one
consideres the size of data being written and read from unions.


-- 


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

[Bug c++/34059] [4.1/4.2/4.3 regression] ICE with invalid base type for class member

2007-11-13 Thread janis at gcc dot gnu dot org



--- Comment #1 from janis at gcc dot gnu dot org  2007-11-13 17:23 ---
The change on mainline from silently accepting the code to an ICE is due to
this patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=117360

r117360 | mmitchel | 2006-10-02 04:12:30 + (Mon, 02 Oct 2006)


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mmitchel at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/34063] [4.3 Regression] ICE: build2_stat, at tree.c:3115

2007-11-13 Thread rakdver at gcc dot gnu dot org



--- Comment #4 from rakdver at gcc dot gnu dot org  2007-11-13 17:34 ---
(In reply to comment #3)
> Either we should use correct order of arguments in chrec_evaluate (that
> function
> is swapping CHREC_LEFT based expression with CHREC_RIGHT based expression
> for pointer_plus addition) - testing patch for that

This is the correct fix.

>  - or chrec_fold_plus_1
> should swap op0 with op1 if code is POINTER_PLUS_EXPR and the first argument
> has integer type, but second POINTER_TYPE_P.
> 


-- 


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

[Bug middle-end/29478] [4.2 Regression] optimization generates warning for casts

2007-11-13 Thread alexandre dot nunes at gmail dot com



--- Comment #29 from alexandre dot nunes at gmail dot com  2007-11-13 17:35 
---
(In reply to comment #28)
> (In reply to comment #26)
> > (In reply to comment #25)
> [cut]
> 
> Mark does not actually read the full list of messages when changing the target
> milestone. I think this should be closed as WONTFIX since there is no easy way
> to fix this for 4.2 but it is fixed in 4.3. As a workaround, you should be 
> able
> to use -Wno-cast-qual to avoid the warning. 
> 
> I don't remember if 4.2 supports -Wno-error=cast-qual. If it does, you can
> still get the warning as a warning even when using -Werror.
> 

It does, thanks for the tip. I added this to my makefile:

check_gcc = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null > /dev/null
2>&1; then echo "$(1)"; else echo "$(2)"; fi ;)
# Work-around for stupid gcc 4.2 bug
ifneq ($(findstring Werror,$(WARN)),)
WARN += $(call check_gcc,-Wno-error=cast-qual,)
endif

... now it compiles fine with -Werror both on gcc 4.1 and 4.2.

It would be nice if this bug would get somehow documented on gcc manual or the
main site before gcc 4.2.3 release.


-- 


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

[Bug middle-end/29478] [4.2 Regression] optimization generates warning for casts

2007-11-13 Thread manu at gcc dot gnu dot org



--- Comment #30 from manu at gcc dot gnu dot org  2007-11-13 17:55 ---
(In reply to comment #29)
> 
> It would be nice if this bug would get somehow documented on gcc manual or the
> main site before gcc 4.2.3 release.

I agree. But I am not sure how this is typically done (I am too newbie). I
think if you write a patch [*] for http://gcc.gnu.org/gcc-4.2/changes.html (a
new item under Caveats) pointing to http://gcc.gnu.org/PR29478 with you would
like (as an user) to know, that may do. Send it to [EMAIL PROTECTED]

If you have any doubts, ask me. Thanks.

[*] Getting the webpages: http://gcc.gnu.org/cvs.html#wwwdocs
And a bit more of info: http://gcc.gnu.org/contribute.html#webchanges


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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

[Bug rtl-optimization/34085] New: ICE with -freorder-blocks-and-partition

2007-11-13 Thread eres at il dot ibm dot com

When compiling the testacse attached with -O3 -fprofile-use
-freorder-blocks-and-partition flags, I get the following error: (I use the
profiling information given by first compiling with -fprofile-generate and than
running the executable)

tmp.c: In function âmainâ:
tmp.c:36: error: insn 186 outside of basic blocks has non-NULL bb field
tmp.c:36: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

This ICE seems to happen when not all of the bbs are in the same partition
(hot/cold).


-- 
   Summary: ICE with -freorder-blocks-and-partition
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com


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

[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition

2007-11-13 Thread eres at il dot ibm dot com



--- Comment #1 from eres at il dot ibm dot com  2007-11-13 18:21 ---
Created an attachment (id=14545)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14545&action=view)
The testcase


-- 


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

[Bug tree-optimization/34063] [4.3 Regression] ICE: build2_stat, at tree.c:3115

2007-11-13 Thread jakub at gcc dot gnu dot org

--- Comment #5 from jakub at gcc dot gnu dot org  2007-11-13 18:23 ---
Subject: Bug 34063

Author: jakub
Date: Tue Nov 13 18:23:03 2007
New Revision: 130151

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130151
Log:
PR tree-optimization/34063
* tree-chrec.c (chrec_evaluate): Put CHREC_LEFT based argument
as first chrec_fold_plus operand rather than second.

* g++.dg/tree-ssa/pr34063.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr34063.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-chrec.c

-- 

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

[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition

2007-11-13 Thread steven at gcc dot gnu dot org



--- Comment #2 from steven at gcc dot gnu dot org  2007-11-13 18:24 ---
Can you please also attach your profile information and give the exact compiler
revision ID that you used to create that information?  That way, people without
access to POWER can still help debug this problem.


-- 


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

[Bug c++/34057] [4.3 regression] ICE with variadic template and vector attribute

2007-11-13 Thread jakub at gcc dot gnu dot org

--- Comment #2 from jakub at gcc dot gnu dot org  2007-11-13 18:27 ---
Subject: Bug 34057

Author: jakub
Date: Tue Nov 13 18:27:09 2007
New Revision: 130152

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130152
Log:
PR c++/34054
PR c++/34056
PR c++/34057
PR c++/34058
PR c++/34060
* pt.c (find_parameter_packs_r): If ppd->set_packs_to_error,
set to error_mark_node the outermost POINTER_TYPE to the pack if
it is seen in a POINTER_TYPE.
(push_template_decl_real): If check_for_bare_parameter_packs
fails for function return type, set the return type to
integer_type_node.  If check_for_bare_parameter_packs failed
for non-function, return error_mark_node.

* g++.dg/parse/crash36.C: Add another dg-error.
* g++.dg/cpp0x/pr34054.C: New test.
* g++.dg/cpp0x/pr34056.C: New test.
* g++.dg/cpp0x/pr34057.C: New test.
* g++.dg/cpp0x/pr34058.C: New test.
* g++.dg/cpp0x/pr34060.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr34054.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34056.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34057.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34058.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34060.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/parse/crash36.C

-- 

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

[Bug c++/34054] [4.3 regression] ICE with parameter pack in return type

2007-11-13 Thread jakub at gcc dot gnu dot org

--- Comment #2 from jakub at gcc dot gnu dot org  2007-11-13 18:27 ---
Subject: Bug 34054

Author: jakub
Date: Tue Nov 13 18:27:09 2007
New Revision: 130152

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130152
Log:
PR c++/34054
PR c++/34056
PR c++/34057
PR c++/34058
PR c++/34060
* pt.c (find_parameter_packs_r): If ppd->set_packs_to_error,
set to error_mark_node the outermost POINTER_TYPE to the pack if
it is seen in a POINTER_TYPE.
(push_template_decl_real): If check_for_bare_parameter_packs
fails for function return type, set the return type to
integer_type_node.  If check_for_bare_parameter_packs failed
for non-function, return error_mark_node.

* g++.dg/parse/crash36.C: Add another dg-error.
* g++.dg/cpp0x/pr34054.C: New test.
* g++.dg/cpp0x/pr34056.C: New test.
* g++.dg/cpp0x/pr34057.C: New test.
* g++.dg/cpp0x/pr34058.C: New test.
* g++.dg/cpp0x/pr34060.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr34054.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34056.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34057.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34058.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34060.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/parse/crash36.C

-- 

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

[Bug c++/34058] [4.3 regression] ICE with variadic template and typedef

2007-11-13 Thread jakub at gcc dot gnu dot org

--- Comment #2 from jakub at gcc dot gnu dot org  2007-11-13 18:27 ---
Subject: Bug 34058

Author: jakub
Date: Tue Nov 13 18:27:09 2007
New Revision: 130152

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130152
Log:
PR c++/34054
PR c++/34056
PR c++/34057
PR c++/34058
PR c++/34060
* pt.c (find_parameter_packs_r): If ppd->set_packs_to_error,
set to error_mark_node the outermost POINTER_TYPE to the pack if
it is seen in a POINTER_TYPE.
(push_template_decl_real): If check_for_bare_parameter_packs
fails for function return type, set the return type to
integer_type_node.  If check_for_bare_parameter_packs failed
for non-function, return error_mark_node.

* g++.dg/parse/crash36.C: Add another dg-error.
* g++.dg/cpp0x/pr34054.C: New test.
* g++.dg/cpp0x/pr34056.C: New test.
* g++.dg/cpp0x/pr34057.C: New test.
* g++.dg/cpp0x/pr34058.C: New test.
* g++.dg/cpp0x/pr34060.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr34054.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34056.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34057.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34058.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34060.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/parse/crash36.C

-- 

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

[Bug c++/34060] [4.3 regression] ICE with invalid specialization of variadic template

2007-11-13 Thread jakub at gcc dot gnu dot org

--- Comment #2 from jakub at gcc dot gnu dot org  2007-11-13 18:27 ---
Subject: Bug 34060

Author: jakub
Date: Tue Nov 13 18:27:09 2007
New Revision: 130152

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130152
Log:
PR c++/34054
PR c++/34056
PR c++/34057
PR c++/34058
PR c++/34060
* pt.c (find_parameter_packs_r): If ppd->set_packs_to_error,
set to error_mark_node the outermost POINTER_TYPE to the pack if
it is seen in a POINTER_TYPE.
(push_template_decl_real): If check_for_bare_parameter_packs
fails for function return type, set the return type to
integer_type_node.  If check_for_bare_parameter_packs failed
for non-function, return error_mark_node.

* g++.dg/parse/crash36.C: Add another dg-error.
* g++.dg/cpp0x/pr34054.C: New test.
* g++.dg/cpp0x/pr34056.C: New test.
* g++.dg/cpp0x/pr34057.C: New test.
* g++.dg/cpp0x/pr34058.C: New test.
* g++.dg/cpp0x/pr34060.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr34054.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34056.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34057.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34058.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34060.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/parse/crash36.C

-- 

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

[Bug c++/34056] [4.3 regression] ICE with parameter pack and pointer

2007-11-13 Thread jakub at gcc dot gnu dot org

--- Comment #3 from jakub at gcc dot gnu dot org  2007-11-13 18:27 ---
Subject: Bug 34056

Author: jakub
Date: Tue Nov 13 18:27:09 2007
New Revision: 130152

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130152
Log:
PR c++/34054
PR c++/34056
PR c++/34057
PR c++/34058
PR c++/34060
* pt.c (find_parameter_packs_r): If ppd->set_packs_to_error,
set to error_mark_node the outermost POINTER_TYPE to the pack if
it is seen in a POINTER_TYPE.
(push_template_decl_real): If check_for_bare_parameter_packs
fails for function return type, set the return type to
integer_type_node.  If check_for_bare_parameter_packs failed
for non-function, return error_mark_node.

* g++.dg/parse/crash36.C: Add another dg-error.
* g++.dg/cpp0x/pr34054.C: New test.
* g++.dg/cpp0x/pr34056.C: New test.
* g++.dg/cpp0x/pr34057.C: New test.
* g++.dg/cpp0x/pr34058.C: New test.
* g++.dg/cpp0x/pr34060.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr34054.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34056.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34057.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34058.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr34060.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/parse/crash36.C

-- 

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

[Bug c++/34054] [4.3 regression] ICE with parameter pack in return type

2007-11-13 Thread jakub at gcc dot gnu dot org



--- Comment #3 from jakub at gcc dot gnu dot org  2007-11-13 18:28 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/34056] [4.3 regression] ICE with parameter pack and pointer

2007-11-13 Thread jakub at gcc dot gnu dot org



--- Comment #4 from jakub at gcc dot gnu dot org  2007-11-13 18:28 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/34057] [4.3 regression] ICE with variadic template and vector attribute

2007-11-13 Thread jakub at gcc dot gnu dot org



--- Comment #3 from jakub at gcc dot gnu dot org  2007-11-13 18:30 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/34058] [4.3 regression] ICE with variadic template and typedef

2007-11-13 Thread jakub at gcc dot gnu dot org



--- Comment #3 from jakub at gcc dot gnu dot org  2007-11-13 18:30 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition

2007-11-13 Thread eres at il dot ibm dot com



--- Comment #3 from eres at il dot ibm dot com  2007-11-13 18:30 ---
Created an attachment (id=14546)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14546&action=view)
the testcase (please ignore the previous testcase it has been uploaded by
mistake)


-- 


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

[Bug c++/34060] [4.3 regression] ICE with invalid specialization of variadic template

2007-11-13 Thread jakub at gcc dot gnu dot org



--- Comment #3 from jakub at gcc dot gnu dot org  2007-11-13 18:30 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/34063] [4.3 Regression] ICE: build2_stat, at tree.c:3115

2007-11-13 Thread jakub at gcc dot gnu dot org



--- Comment #6 from jakub at gcc dot gnu dot org  2007-11-13 18:31 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition

2007-11-13 Thread eres at il dot ibm dot com



--- Comment #4 from eres at il dot ibm dot com  2007-11-13 18:34 ---
(In reply to comment #2)
> Can you please also attach your profile information and give the exact 
> compiler
> revision ID that you used to create that information?  That way, people 
> without
> access to POWER can still help debug this problem.

Sure - 
gcc version 4.3.0 20071028 (experimental) (GCC)


-- 


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

[Bug libstdc++/11196] parse error before numeric constant

2007-11-13 Thread gcc-bugzilla at contacts dot eelis dot net



--- Comment #7 from gcc-bugzilla at contacts dot eelis dot net  2007-11-13 
18:42 ---
(In reply to comment #6)
> The bug is that the C++ front end implicitly #defines _GNU_SOURCE. 
> [..]
> Could some libstdc++ guru explain why this define is actually needed? 

I am no libstdc++ guru, but this:

  echo "#include " | g++ -x c++ -U _GNU_SOURCE -c -

produces:

  /usr/include/c++/4.1.2/cstdlib:162: error: â::lldiv_tâ has not been
declared
  /usr/include/c++/4.1.2/cstdlib:168: error: â::_Exitâ has not been
declared
  /usr/include/c++/4.1.2/cstdlib:175: error: â::llabsâ has not been
declared
  /usr/include/c++/4.1.2/cstdlib:177: error: âlldiv_tâ does not name a type
  /usr/include/c++/4.1.2/cstdlib:181: error: â::lldivâ has not been
declared
  /usr/include/c++/4.1.2/cstdlib:196: error: â::strtofâ has not been
declared
  /usr/include/c++/4.1.2/cstdlib:197: error: â::strtoldâ has not been
declared
  /usr/include/c++/4.1.2/cstdlib:203: error: â__gnu_cxx::lldiv_tâ has not
been declared
  /usr/include/c++/4.1.2/cstdlib:205: error: â__gnu_cxx::_Exitâ has not
been declared
  /usr/include/c++/4.1.2/cstdlib:208: error: â__gnu_cxx::llabsâ has not
been declared
  /usr/include/c++/4.1.2/cstdlib:209: error: â__gnu_cxx::divâ has not been
declared
  /usr/include/c++/4.1.2/cstdlib:210: error: â__gnu_cxx::lldivâ has not
been declared
  /usr/include/c++/4.1.2/cstdlib:213: error: â__gnu_cxx::strtofâ has not
been declared
  /usr/include/c++/4.1.2/cstdlib:216: error: â__gnu_cxx::strtoldâ has not
been declared


-- 


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

[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure

2007-11-13 Thread dave at hiauly1 dot hia dot nrc dot ca



--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca  2007-11-13 
19:27 ---
Subject: Re:  [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related
verify_ssa failure

> Is this still reproduceable with current trunk?

As of last night, this still occurs on hppa2.0w-hp-hpux11.11.  It's
the only remaining failure in the libstdc++ testsuite.

Dave


-- 


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

[Bug fortran/34084] [4.3 regression] Error in November 9 version of gfortran when the first line in a source file is an INCLUDE statement

2007-11-13 Thread burnus at gcc dot gnu dot org



--- Comment #1 from burnus at gcc dot gnu dot org  2007-11-13 19:51 ---
I can reproduce this (if the included file is not empty).

FX, can you have a look? I would not be surprised if one of your debug patches
caused the regression:

anything:1: internal compiler error: in end_source_file, at
fortran/scanner.c:327


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org, burnus at gcc dot gnu
   ||dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2007-11-13 19:51:09
   date||
Summary|Error in November 9 version |[4.3 regression] Error in
   |of gfortran when the first  |November 9 version of
   |line in a source file is an |gfortran when the first line
   |INCLUDE statement   |in a source file is an
   ||INCLUDE statement


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

[Bug fortran/34079] Bind(C): Don't pass the string length as argument (for STDCALL)

2007-11-13 Thread burnus at gcc dot gnu dot org



--- Comment #2 from burnus at gcc dot gnu dot org  2007-11-13 20:02 ---
Note: The patch above works, one only needs to check whether there is a memory
leak or something else which affects the generated tree.

Index: gcc/testsuite/gfortran.dg/bind_c_vars_2.f03
===
--- gcc/testsuite/gfortran.dg/bind_c_vars_2.f03 (revision 0)
+++ gcc/testsuite/gfortran.dg/bind_c_vars_2.f03 (revision 0)
@@ -0,0 +1,29 @@
+! { dg-do compile }
+! { dg-options "-fdump-tree-original" }
+!
+! PR fortran/34079
+! Character bind(c) arguments shall not pass the length as additional argument
+!
+implicit none
+interface
+  subroutine subiso(x) bind(c)
+use iso_c_binding
+character(kind=c_char,len=1), dimension(*) :: x
+  end subroutine subiso
+  subroutine subiso2(x) bind(c) ! { dg-warning "may not be C interoperable" }
+character(len=1), dimension(*) :: x
+  end subroutine subiso2
+  subroutine sub(x)
+use iso_c_binding
+character(kind=c_char,len=1), dimension(*) :: x
+  end subroutine sub
+end interface
+call sub("abc")
+call subiso ("ABCDEF")
+call subiso2("AbCdEfGhIj")
+end
+
+! { dg-final { scan-tree-dump-times "{lb: 1 sz: 1}, 3" 1 "original" } }
+! { dg-final { scan-tree-dump-times "{lb: 1 sz: 1}, 6" 0 "original" } }
+! { dg-final { scan-tree-dump-times "{lb: 1 sz: 1}, 10" 0 "original" } }
+! { dg-final { cleanup-tree-dump "original" } }


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||patch, wrong-code


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

[Bug fortran/34080] [4.3 regression] Transfer was working, now broken

2007-11-13 Thread pault at gcc dot gnu dot org



--- Comment #4 from pault at gcc dot gnu dot org  2007-11-13 20:07 ---
The regression occurred at r129505.  Allowance was not made in the correction
to gfc_resolve_transfer for assumed size dummy arguments.  This fixes it:

Index: /svn/trunk/gcc/fortran/iresolve.c
===
*** /svn/trunk/gcc/fortran/iresolve.c   (revision 130152)
--- /svn/trunk/gcc/fortran/iresolve.c   (working copy)
*** gfc_resolve_transfer (gfc_expr *f, gfc_e
*** 2283,2289 
/* TODO: Make this do something meaningful.  */
static char transfer0[] = "__transfer0", transfer1[] = "__transfer1";

!   if (mold->ts.type == BT_CHARACTER && !mold->ts.cl->length)
  mold->ts.cl->length = gfc_int_expr (mold->value.character.length);

f->ts = mold->ts;
--- 2283,2290 
/* TODO: Make this do something meaningful.  */
static char transfer0[] = "__transfer0", transfer1[] = "__transfer1";

!   if (mold->ts.type == BT_CHARACTER && !mold->ts.cl->length
!   && !(mold->expr_type == EXPR_VARIABLE &&
mold->symtree->n.sym->attr.dummy))
  mold->ts.cl->length = gfc_int_expr (mold->value.character.length);

f->ts = mold->ts;

It's just now regtesting with a couple of other fixes.  I'll clean this patch
up and commit it as obvious (the others I will submit).

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-11-13 13:55:55 |2007-11-13 20:07:30
   date||


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

[Bug c++/34086] New: g++ crashes on simple 20-line source file

2007-11-13 Thread nmaquet at gmail dot com

The following code crashes g++ 4.1.3 :


*START OF FILE**

#include 
using namespace std;

double arctan(double x)
{
   int i=1,n=20;
   double c=1.0,arct=0.0,paf=1.0,eps=0.1,hab;
   hab=(x/(1+x*x));
   do
   {
   arct+=paf;
   c+=2i/(2i+1);
   paf=(c*hab);
   i++;
   }
   while((ieps));
   arct*=hab;
   return arct;
}

int main()
{
   double Pi;
   Pi=4*(4*arctan(1/5)-arctan(1/239));
   cout< search starts here:
 /usr/include/c++/4.1.3
 /usr/include/c++/4.1.3/i486-linux-gnu
 /usr/include/c++/4.1.3/backward
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.1.3/include
 /usr/include
End of search list.
GNU C++ version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
(i486-linux-gnu)
compiled by GNU C version 4.1.3 20070929 (prerelease) (Ubuntu
4.1.2-16ubuntu2).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3cc47be363985179cfafdceddd0e8f5d
test.cpp: In function double arctan(double):
test.cpp:12: internal compiler error: in const_binop, at fold-const.c:1641
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
Preprocessed source stored into /tmp/cczf63dY.out file, please attach this to
your bugreport.


-- 
   Summary: g++ crashes on simple 20-line source file
   Product: gcc
   Version: 4.1.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nmaquet at gmail dot com


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

[Bug c++/34086] g++ crashes on simple 20-line source file

2007-11-13 Thread nmaquet at gmail dot com



--- Comment #1 from nmaquet at gmail dot com  2007-11-13 20:13 ---
Created an attachment (id=14547)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14547&action=view)
preprocessed source


-- 


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

[Bug c++/34086] g++ crashes on simple 20-line source file

2007-11-13 Thread nmaquet at gmail dot com



--- Comment #2 from nmaquet at gmail dot com  2007-11-13 20:16 ---
I reported this on Launchpad a few weeks ago but it doesn't get much attention
:

https://bugs.launchpad.net/ubuntu/+source/gcc-4.1/+bug/155259


-- 


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

[Bug fortran/34080] [4.3 regression] Transfer was working, now broken

2007-11-13 Thread pault at gcc dot gnu dot org



--- Comment #5 from pault at gcc dot gnu dot org  2007-11-13 20:19 ---
Drew,

By the way - thanks!

The regression test is just coming to an end, so it'll be fixed very soon.

Paul


-- 


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

[Bug fortran/34080] [4.3 regression] Transfer was working, now broken

2007-11-13 Thread drewmccormack at mac dot com



--- Comment #6 from drewmccormack at mac dot com  2007-11-13 20:27 ---
Subject: Re:  [4.3 regression] Transfer was working, now broken

Thanks for fixing it so quick, Paul.

Drew


On 13/11/2007, at 9:19 PM, pault at gcc dot gnu dot org wrote:

>
>
> --- Comment #5 from pault at gcc dot gnu dot org  2007-11-13  
> 20:19 ---
> Drew,
>
> By the way - thanks!
>
> The regression test is just coming to an end, so it'll be fixed very  
> soon.
>
> Paul
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34080
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.


-- 


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

[Bug fortran/34080] [4.3 regression] Transfer was working, now broken

2007-11-13 Thread pault at gcc dot gnu dot org



--- Comment #7 from pault at gcc dot gnu dot org  2007-11-13 20:33 ---
Subject: Bug 34080

Author: pault
Date: Tue Nov 13 20:33:21 2007
New Revision: 130158

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130158
Log:
2007-11-13  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/34080
* iresolve.c (gfc_resolve_transfer): Do not try to convert
to a constant MOLD expression, if it is an assumed size
dummy.

2007-11-13  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/34080
* gfortran.dg/transfer_assumed_size_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/transfer_assumed_size_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/iresolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/34077] GCC -O1 -minline-all-stringops -minline-stringops-dynamically fails for spec 2006 bzip2, gobmk, and h264ref benchmarks

2007-11-13 Thread michael dot meissner at amd dot com



--- Comment #3 from michael dot meissner at amd dot com  2007-11-13 20:48 
---
Created an attachment (id=14548)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14548&action=view)
Patch to fix PR34077


-- 


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

[Bug target/34087] New: ICE in regrename.c for movdf_hardfloat64_mfpgpr

2007-11-13 Thread pthaugen at gcc dot gnu dot org

The following attatchment from the cpu20006 benchmark leslie3d ICEs in the
following manner. The problem appears to be a latent bug that has come and gone
a couple times (I saw it earlier on the gamess benchmark too).  Recent
mainlines compile it fine, but revision 128829 exhibits the problem.  Opening a
bugzilla since I haven't been able to spend as much time digging into it as I'd
thought/hoped, and don't want to lose track of it.

> gfortran -c -m64 -O2 -mcpu=power6x -fpeel-loops -ffast-math junk.f
junk.f: In function 'setiv':
junk.f:913: error: insn does not satisfy its constraints:
(insn 5218 2288 4792 191 (set (reg:DF 46 14 [2631])
(reg:DF 65 lr [1528])) 335 {*movdf_hardfloat64_mfpgpr}
(expr_list:REG_DEAD (reg:DF 65 lr [1528])
(nil)))
junk.f:913: internal compiler error: in build_def_use, at regrename.c:766
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE in regrename.c for movdf_hardfloat64_mfpgpr
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pthaugen at gcc dot gnu dot org
 GCC build triplet: powerpc64-linux
  GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux


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

[Bug target/34087] ICE in regrename.c for movdf_hardfloat64_mfpgpr

2007-11-13 Thread pthaugen at gcc dot gnu dot org



--- Comment #1 from pthaugen at gcc dot gnu dot org  2007-11-13 21:08 
---
Created an attachment (id=14549)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14549&action=view)
Testcase


-- 


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

[Bug c++/34086] g++ crashes on simple 20-line source file

2007-11-13 Thread fang at csl dot cornell dot edu



--- Comment #3 from fang at csl dot cornell dot edu  2007-11-13 21:12 
---
4.0.1 (apple) ICEs:
pr34086.cc: In function 'double arctan(double)':
pr34086.cc:12: internal compiler error: in const_binop, at fold-const.c:1610

4.2.2 gives me:
pr34086.cc: In function 'double arctan(double)':
pr34086.cc:12: error: cannot convert 'double __complex__' to 'double' in
assignment


-- 


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

[Bug fortran/34084] [4.3 regression] Error in November 9 version of gfortran when the first line in a source file is an INCLUDE statement

2007-11-13 Thread fxcoudert at gcc dot gnu dot org



--- Comment #2 from fxcoudert at gcc dot gnu dot org  2007-11-13 21:18 
---
(In reply to comment #1)
> FX, can you have a look? I would not be surprised if one of your debug patches
> caused the regression

Me neither. A simple workaround is to simply add a blank line before the
INCLUDE statement. This problem is the exact inverse of the one I solved
previously (which was about include statements on the last line), but it can't
be fixed with the same hack. I'll revert my previous patch, and we'll need to
fix this one straight in the scanner, when we read the file for the first time.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-11-13 19:51:09 |2007-11-13 21:18:22
   date||


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

[Bug target/34087] ICE in regrename.c for movdf_hardfloat64_mfpgpr

2007-11-13 Thread pinskia at gcc dot gnu dot org



--- Comment #2 from pinskia at gcc dot gnu dot org  2007-11-13 21:57 ---
This is not the first time something like this has shown up before.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Keywords||ice-on-valid-code, ra


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

[Bug middle-end/34088] New: [4.3 regression] ICE with uninitialized variable and -Werror

2007-11-13 Thread reichelt at gcc dot gnu dot org

The following valid code snippet triggers an ICE on mainline
when compiled with "gcc -O -Wall -Werror" on i686-pc-linux-gnu.

=
int F0 (int);
int F1 (int t) { return F0(t); }
int F2 (int t) { return F0(t); }

extern int X[];
static inline int foo(int i)
{
  return X[i];
}

int bar(int* p)
{
  int i;

  while ( ({ if (foo(*p) && foo(*p)); p; }) );

  return i;
}
=

cc1: warnings being treated as errors
bug.c: In function 'bar':
bug.c:17: error: 'i' is used uninitialized in this function
bug.c:12: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]

Although the first functions aren't used in bar where the ICE happens,
they're needed to reproduce the ICE.

I can trace the bug back to at least 2007-05-13.

Janis, a regression hunt might be useful here.
Would you mind running one?


-- 
   Summary: [4.3 regression] ICE with uninitialized variable and -
Werror
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug middle-end/34088] [4.3 regression] ICE with uninitialized variable and -Werror

2007-11-13 Thread reichelt at gcc dot gnu dot org



-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet||i686-pc-linux-gnu
   GCC host triplet||i686-pc-linux-gnu
 GCC target triplet||i686-pc-linux-gnu
   Target Milestone|--- |4.3.0
Version|unknown |4.3.0


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

[Bug c++/34086] [4.1 Regression] g++ crashes on simple 20-line source file

2007-11-13 Thread rguenth at gcc dot gnu dot org



--- Comment #4 from rguenth at gcc dot gnu dot org  2007-11-13 22:38 ---
Confirmed.

#1  0x084a545e in const_binop (code=TRUNC_DIV_EXPR, arg1=0xb7cec528, 
arg2=0xb7cec720, notrunc=0)
at /home/richard/src/gcc-4_1-branch/gcc/fold-const.c:1640
1640default:
(gdb) l
1635real = const_binop (code, t1, magsquared, notrunc);
1636imag = const_binop (code, t2, magsquared, notrunc);
1637  }
1638  break;
1639
1640default:
1641  gcc_unreachable ();
1642}
1643
1644  if (real && imag)

both args are COMPLEX_CST which are not valid for TRUNC_DIV_EXPR.

#1  0x084a545e in const_binop (code=TRUNC_DIV_EXPR, arg1=0xb7cec528, 
arg2=0xb7cec720, notrunc=0)
at /home/richard/src/gcc-4_1-branch/gcc/fold-const.c:1640
#2  0x084d63be in fold_binary (code=TRUNC_DIV_EXPR, type=0xb7cea844, 
op0=0xb7cec528, op1=0xb7cec720)
at /home/richard/src/gcc-4_1-branch/gcc/fold-const.c:7626
#3  0x084f4704 in fold (expr=0xb7c4d2ac)
at /home/richard/src/gcc-4_1-branch/gcc/fold-const.c:10303
#4  0x081e0b06 in fold_if_not_in_template (expr=0xb7c4d2ac)
at /home/richard/src/gcc-4_1-branch/gcc/cp/tree.c:2334
#5  0x0818c0cb in build_binary_op (code=TRUNC_DIV_EXPR, orig_op0=0xb7cec528, 
orig_op1=0xb7cec720, convert_p=1)
at /home/richard/src/gcc-4_1-branch/gcc/cp/typeck.c:3594
#6  0x080576d7 in build_new_op (code=TRUNC_DIV_EXPR, flags=3, arg1=0xb7cec528, 
arg2=0xb7cec720, arg3=0x0, overloaded_p=0xbfc21583 "")
at /home/richard/src/gcc-4_1-branch/gcc/cp/call.c:3914
#7  0x08188321 in build_x_binary_op (code=TRUNC_DIV_EXPR, arg1=0xb7cec528, 
arg2=0xb7cec720, overloaded_p=0xbfc21583 "")
at /home/richard/src/gcc-4_1-branch/gcc/cp/typeck.c:2778

Indeed a C++ frontend issue and a regression from 3.4.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-invalid-code
  Known to fail||4.0.4 4.1.3
  Known to work||4.2.2 3.4.6
   Last reconfirmed|-00-00 00:00:00 |2007-11-13 22:38:08
   date||
Summary|g++ crashes on simple 20-   |[4.1 Regression] g++ crashes
   |line source file|on simple 20-line source
   ||file


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

[Bug middle-end/34088] [4.3 regression] ICE with uninitialized variable and -Werror

2007-11-13 Thread pinskia at gcc dot gnu dot org



--- Comment #1 from pinskia at gcc dot gnu dot org  2007-11-13 22:41 ---
I think this showed up when may_alias became a TODO.

Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|i686-pc-linux-gnu   |
   GCC host triplet|i686-pc-linux-gnu   |
 GCC target triplet|i686-pc-linux-gnu   |
   Last reconfirmed|-00-00 00:00:00 |2007-11-13 22:41:26
   date||


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

[Bug c++/33588] gcc warns of (char*) conversion on client-side varargs funcs

2007-11-13 Thread pinskia at gcc dot gnu dot org



--- Comment #4 from pinskia at gcc dot gnu dot org  2007-11-13 22:54 ---
(In reply to comment #3)
> So? Is the warning warranted?
Yes because va_list is not a first class type and never was and is very ABI
dependent.

> Can be worked-around? 
Well no, because va_list's type is ABI dependent.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug c++/33588] gcc warns of (char*) conversion on client-side varargs funcs

2007-11-13 Thread manu at gcc dot gnu dot org



--- Comment #5 from manu at gcc dot gnu dot org  2007-11-13 23:20 ---
Stephan, please, try with 

my_func( "format string: %s", (char *)__FILE__ )

Otherwise, you can use -Wno-write-strings to avoid the warning or
-Wno-error=write-strings to get the warning as a warning even when using
-Werror.


-- 


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

[Bug c++/34089] New: Segfault on specialization using struct instead of template function.

2007-11-13 Thread drahflow at gmx dot de

Attempting to compile the following file

template void foo() { };
template struct foo { };

results in

bug.c++:2: 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.
For Debian GNU/Linux specific bug reporting instructions,
see .

which is obviously undesirable.

g++ --version
g++ (GCC) 4.2.3 20071014 (prerelease) (Debian 4.2.2-3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


-- 
   Summary: Segfault on specialization using struct instead of
template function.
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drahflow at gmx dot de


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

[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-11-13 Thread jvdelisle at gcc dot gnu dot org

--- Comment #22 from jvdelisle at gcc dot gnu dot org  2007-11-14 00:59 
---
Subject: Bug 33162

Author: jvdelisle
Date: Wed Nov 14 00:59:09 2007
New Revision: 130168

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130168
Log:
2007-11-11  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/33162
* decl.c (match_procedure_decl): Remove TODO and allow intrinsics in
PROCEDURE declarations.  Set attr.untyped to allow the interface to be
resolved later where the symbol type will be set.
* interface.c (compare_intr_interfaces): Remove static from pointer
declarations.  Add type and kind checks for dummy function arguments.
(compare_actual_formal_intr): New function to compare an actual
argument with an intrinsic function. (gfc_procedures_use): Add check
for
interface that points to an intrinsic function, use the new function.
* resolve.c (resolve_specific_f0): Resolve the intrinsic interface.
(resolve_specific_s0): Ditto.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c

-- 

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

[Bug middle-end/34088] [4.3 regression] ICE with uninitialized variable and -Werror

2007-11-13 Thread janis at gcc dot gnu dot org



--- Comment #2 from janis at gcc dot gnu dot org  2007-11-14 01:02 ---
The ICE also occurs on powerpc-linux, where a regression hunt identified this
patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=120373

r120373 | hubicka | 2007-01-03 01:12:56 + (Wed, 03 Jan 2007)


-- 


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

[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-11-13 Thread jvdelisle at gcc dot gnu dot org



--- Comment #23 from jvdelisle at gcc dot gnu dot org  2007-11-14 01:06 
---
Subject: Bug 33162

Author: jvdelisle
Date: Wed Nov 14 01:06:13 2007
New Revision: 130169

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130169
Log:
2007-11-13  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/33162
*gfortran.dg/proc_decl_1.f90: Update.
*gfortran.dg/proc_decl_7.f90: New test.
*gfortran.dg/proc_decl_8.f90: New test.
*gfortran.dg/proc_decl_9.f90: New test.
*gfortran.dg/proc_decl_10.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/proc_decl_10.f90
trunk/gcc/testsuite/gfortran.dg/proc_decl_7.f90
trunk/gcc/testsuite/gfortran.dg/proc_decl_8.f90
trunk/gcc/testsuite/gfortran.dg/proc_decl_9.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/proc_decl_1.f90


-- 


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

[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-11-13 Thread jvdelisle at gcc dot gnu dot org



--- Comment #24 from jvdelisle at gcc dot gnu dot org  2007-11-14 01:17 
---
Fixed on trunk.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

1 2 >

1 - 100 of 120 matches

Mail list logo