[Bug libfortran/43551] [4.4/4.5 Regression] I/O regression (wrong values with Quantum Espresso)

[burnus at gcc dot gnu dot org]

--- Comment #8 from burnus at gcc dot gnu dot org  2010-03-28 08:19 ---
(In reply to comment #7)
> Turning off format caching is very easy for debugging purposes.
I tried this (see comment 4), but it did not seem to help.

I now added a printf for "*(GFC_REAL_8 *)dest, buffer" in read_f, but "dest" is
the same with libgfortran 4.3.x and 4.5.


-- 


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

[Bug libfortran/43551] [4.4/4.5 Regression] I/O regression (wrong values with Quantum Espresso)

[burnus at gcc dot gnu dot org]

--- Comment #9 from burnus at gcc dot gnu dot org  2010-03-28 08:52 ---
The issue seems to be the buffering. If one uses GFORTRAN_UNBUFFERED_ALL=1 the
result is correct, without it is not.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jb at gcc dot gnu dot org


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

[Bug tree-optimization/43425] enhance scalar expansion to vectorize this loop

[irar at il dot ibm dot com]

--- Comment #2 from irar at il dot ibm dot com  2010-03-28 08:59 ---
I think PR 35229 covers this issue.


-- 


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

[Bug tree-optimization/43431] Diagnostic message is not clear for vectorization profitability analysis

[irar at il dot ibm dot com]

--- Comment #1 from irar at il dot ibm dot com  2010-03-28 09:41 ---
(In reply to comment #0)

> What does this message mean?
> "vector iteration cost = 2056 is divisible by scalar iteration cost = 4 by a
> factor greater than or equal to the vectorization factor = 4 ."
> Is the vectorization not profitable?
> Why?

The cost of one vector iteration is 2056.
The cost of one scalar iteration is 4.
2056/4 = 514 
514 > 4 (= vectorization factor)
The vectorization is not profitable.

We want to vectorize only if one vector iteration cost is lower than one scalar
iteration cost multiplied by vectorization factor.

(Vector cost is so high here, because of the j,i access. We should vectorize
the outer loop, but we fail because of some unsupported features: unknown inner
loop bound, need for versioning (for alias) in outer loop.)


-- 


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

[Bug target/40722] [4.5 Regression] ia32intrin.h defines of _rotl, _rotr conflict with target stdlib.h decls

[jon_y at users dot sourceforge dot net]

--- Comment #10 from jon_y at users dot sourceforge dot net  2010-03-28 
10:14 ---
Created an attachment (id=20228)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20228&action=view)
Broken stdlib.h

Hi,

This patched caused problems for mingw-w64 stdlib.h, see attachment.


-- 


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

[Bug target/40722] [4.5 Regression] ia32intrin.h defines of _rotl, _rotr conflict with target stdlib.h decls

[jon_y at users dot sourceforge dot net]

--- Comment #11 from jon_y at users dot sourceforge dot net  2010-03-28 
10:17 ---
Created an attachment (id=20229)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20229&action=view)
log from buildbot

Here is the error output from one of the buildbot slaves.


-- 


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

[Bug libstdc++/43554] New: profile-mode version of forward_list missing

[paolo dot carlini at oracle dot com]

I'm looking for help for the profile-mode version (I'm going to take care of
the debug-mode one)


-- 
   Summary: profile-mode version of forward_list missing
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paolo dot carlini at oracle dot com


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

[Bug libstdc++/43554] profile-mode version of forward_list missing

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-28 10:36:29
   date||


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

[Bug tree-optimization/43436] Missed vectorization: "unhandled data-ref"

[irar at il dot ibm dot com]

--- Comment #2 from irar at il dot ibm dot com  2010-03-28 10:58 ---
(In reply to comment #0)

> sub_hfyu_median_prediction.c:18: note: not vectorized: unhandled data-ref 
> 
> Looking with GDB at it, I get:
> (gdb) p debug_data_references (datarefs)
> (Data Ref: 
>   stmt: D.2736_16 = *D.2735_15;
>   ref: *D.2735_15;
>   base_object: *src1_14(D);
>   Access function 0: {0B, +, 1}_1
> )
> (Data Ref: 
>   stmt: 
>   ref: 
>   base_object: 
> )
> 
> I think it is the dst data ref that is NULL.  Might be an aliasing
> problem for the data dep analysis, but still, the data ref should be
> analyzed correctly first.

Data refs analysis fails because of the function call in the loop.

The vectorizer should check the return value of
compute_data_dependences_for_loop() and print some better error message though.


-- 


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

[Bug tree-optimization/43436] Missed vectorization: "unhandled data-ref"

[irar at il dot ibm dot com]

--- Comment #3 from irar at il dot ibm dot com  2010-03-28 11:07 ---
(In reply to comment #1)

> hadamard8_diff.c:44: note: not vectorized: unhandled data-ref 

There is a function call in this loop as well.

> hadamard8_diff.c:26: note: not vectorized: data ref analysis failed D.2771_12 
> =
> *D.2770_11;

Scalar evolution analysis fails here with:
failed: evolution of base is not affine.

  D.2768_8 = i_361 * stride_7(D);
  D.2769_9 = (long unsigned int) D.2768_8;
  D.2770_11 = src_10(D) + D.2769_9;
  D.2771_12 = *D.2770_11;

stride is function parameter.


-- 


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

[Bug tree-optimization/43543] Reorder the statements in the loop can vectorize it

[irar at il dot ibm dot com]

--- Comment #1 from irar at il dot ibm dot com  2010-03-28 11:16 ---
Looks similar to PR 32806.


-- 


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

[Bug libfortran/43551] [4.4/4.5 Regression] Buffered direct I/O reads wrong record

[burnus at gcc dot gnu dot org]

--- Comment #10 from burnus at gcc dot gnu dot org  2010-03-28 11:56 ---
And the culprit is unit 30 ("$HOME/tmp/_phsi.ebar" alias unit=iuebar), which is
a binary file (672000 bytes), which is automatically deleted
(PH/close_phq.f90).

The file is opened with: form='unformatted', access='direct', recl=22400
(= 2800 * DIRECT_IO_FACTOR w/ DIRECT_IO_FACTOR = 8 for real(8).)

 * * *

! Test case:

implicit none
integer, parameter :: size = 2800 ! << needs to be large enough
real(8) :: vec1(size,30), dummy(size)
integer i

CALL RANDOM_NUMBER(vec1)

open(99, file='test.dat', form='unformatted', access='direct', recl=size*8)
do i = 1, 10
  write(99,rec=i) vec1(:,i)
  write(99,rec=i+10) vec1(:,i+10)
  write(99,rec=i+20) vec1(:,i+20)
end do

do i = 1, 10
  read(99,rec=i) dummy
  if (any (dummy /= vec1(:,i))) call abort()
  read(99,rec=i+10) dummy
  if (any (dummy /= vec1(:,i+10))) call abort()
  read(99,rec=i+20) dummy
  if (any (dummy /= vec1(:,i+20))) call abort() ! << aborts here for rec = 21
end do

close(99, status='delete')
end

 * * *

Closer examination shows that reading rec = 1, rec = 11, rec = 21 returns the
record 1, 11, 30. That is: The third read returns the *last* record instead of
the 21th!


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.4/4.5 Regression] I/O|[4.4/4.5 Regression]
   |regression (wrong values|Buffered direct I/O reads
   |with Quantum Espresso)  |wrong record


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

[Bug debug/43552] FAIL: gcc.dg/guality/pr41353-1.c with -flto and -fwhopr

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-03-28 12:41 ---
There is no line 28 to break on, instead it breaks at f3().


-- 

rguenth 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-03-28 12:41:05
   date||


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

[Bug fortran/42958] Weird temporary array allocation

[burnus at gcc dot gnu dot org]

--- Comment #12 from burnus at gcc dot gnu dot org  2010-03-28 12:57 ---
(In reply to comment #8)
> atmp.5.dim[0].lbound = 0;
> atmp.5.dim[0].ubound = D.1612;
> D.1616 = D.1612 < 0;
> D.1617 = D.1612 + 1;
> D.1618 = D.1616 ? 0 : D.1617 * 8;
>
> but there's still the conditional on negative D.1612.

I think that check is needed: If one has:
   array(1:0) or array(1:-200) or array(1:100:-1)
that means that one has a zero-sized array. If one had no such check one would
allocate "negative memory" which matches - as the malloc argument is unsigned -
a large positive number. Maybe there are cases where one knows before hand that
the array cannot be zero-sized, but in the general case one cannot.

(I am thinking of
   call f(array(...))
where one knows that "f" does not allow for a zero-sized array argument. In the
other known cases, the upper bound should be already known at compile time and
the check should be folded away. Maybe there are more such cases.)


> Also deallocation is
>   D.1621 = (void *) atmp.5.data;
>   if (D.1621 != 0B)
>  __builtin_free (D.1621);
> 
> where the check for NULL is not necessary (though the middle end might
> be able to remove that condition).

I think one can remove the check as __builtin_free also can deal with NULL
arguments, but it is not known before hand whether the argument is NULL as - in
the general case - one can manually deallocate arrays.

Well, for generated temporary arrays (which the user cannot directly access),
one can know whether the pointer is NULL and thus one could remove the check.
Such a patch should be rather simple.

> another missed middle-end optimization,
> p = malloc(1); free (p); isn't optimized away

I think it would be useful, if the middle end were able to do so.


-- 


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

[Bug debug/43552] FAIL: gcc.dg/guality/pr41353-1.c with -flto and -fwhopr

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-03-28 12:58 ---
The return statement does not have line information, even without LTO:

f2 (int i, int j)
{
:
  [/home/richard/src/trunk/gcc/testsuite/gcc.dg/guality/pr41353-1.c : 23:5] j_3
= j_1(D) + i_2(D);
  [/home/richard/src/trunk/gcc/testsuite/gcc.dg/guality/pr41353-1.c : 23:5] #
DEBUG j => j_3
  [/home/richard/src/trunk/gcc/testsuite/gcc.dg/guality/pr41353-1.c : 26:7] #
DEBUG i1 => [/home/richard/src/trunk/gcc/testsuite/gcc.dg/guality/pr41353-1.c :
26] i_2(D) * 2
  [/home/richard/src/trunk/gcc/testsuite/gcc.dg/guality/pr41353-1.c : 27:7] #
DEBUG i2 => [/home/richard/src/trunk/gcc/testsuite/gcc.dg/guality/pr41353-1.c :
27] i_2(D) * 3
  return j_3;

}

(same dump with -flto).  There's no line 28 in the debug information of
either variant - still gdb breaks on the closing } for -O2 but on the
start of f3 () for -O2 -flto.  But the non-LTO variant has a line advance
entry to line 29.

What is missing is visible in the .expand dump - the non-LTO variant
does have line number information on the function return (line 29), but
the LTO variant does not.


-- 


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

[Bug fortran/42958] Weird temporary array allocation

[burnus at gcc dot gnu dot org]

--- Comment #13 from burnus at gcc dot gnu dot org  2010-03-28 13:05 ---
(In reply to comment #12)
> (I am thinking of
>call f(array(...))
> where one knows that "f" does not allow for a zero-sized array argument.

s/where/if/ - in the general case one does not know. Especially for
  dummyArg(n) and dummyArg(*) [and if no interface it known]
one does not know it, while for
  dummyArg(4)
one does. I fear, that this is a rare case.

For "call foo(Ix)" in the Tonto example of comment 9, one does not know as the
explicit interface interface of "foo" is not known.


-- 


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

[Bug fortran/42958] Weird temporary array allocation

[burnus at gcc dot gnu dot org]

--- Comment #14 from burnus at gcc dot gnu dot org  2010-03-28 13:56 ---
Created an attachment (id=20230)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20230&action=view)
Draft patch for NULL check for deallocation

Draft patch for removing the NULL check before __builtin_free. According to
POSIX, passing NULL to free is allowed. The patch removes all the NULL checks
where it is likely that the temporary is not-NULL. For procedure arguments
(_gfortran_pack/_gfortran_unpack) the chance is high that it is NULL - which is
the case if the variable was already contiguous. Thus, I left the check in.

The patch removes 5 of the 15 "!= 0" checks for the test case (attachment
20225).


-- 


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

[Bug fortran/42958] Weird temporary array allocation

[burnus at gcc dot gnu dot org]

--- Comment #15 from burnus at gcc dot gnu dot org  2010-03-28 14:10 ---
Actually, I am wondering whether one needs to do
  D.1620_135 = __builtin_malloc (1);
for temporary arrays. For user-accessible ALLOCATABLE arrays one does - because
ALLOCATED(array) needs also to be .TRUE. for zero-sized arrays, but for
temporary arrays one does not. For those one could just do
  D.1620_135 = 0B
Will the middle-end optimize __builtin_free(NULL) away?


-- 


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

[Bug debug/41893] ICE with -combine and debug

[kevin at koconnor dot net]

--- Comment #4 from kevin at koconnor dot net  2010-03-28 14:43 ---
This problem has returned.  The test case above no longer causes the problem -
but simply changing the test case to also assign a value to the variable shows
the problem.  This is with gcc from svn (r157452).

New test case:


cat > file1.c << EOF
struct s1_s {
int v;
};
struct s1_s g1;
void __attribute__((externally_visible)) func1() {
struct s1_s *l1 = &g1;
l1->v = 0;
}
EOF

cat > file2.c << EOF
extern struct s1_s g1;
void func2() {
&g1;
}
EOF

cc -O -g -fwhole-program -combine -c file1.c file2.c



-- 


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

[Bug target/40722] [4.5 Regression] ia32intrin.h defines of _rotl, _rotr conflict with target stdlib.h decls

[hjl dot tools at gmail dot com]

--- Comment #12 from hjl dot tools at gmail dot com  2010-03-28 14:44 
---
(In reply to comment #10)
> Created an attachment (id=20228)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20228&action=view) [edit]
> Broken stdlib.h
> 
> Hi,
> 
> This patched caused problems for mingw-w64 stdlib.h, see attachment.
> 

Someone from mingw64 should adjust fixincludes/mkfixinc.sh for mingw64.


-- 


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

[Bug fortran/42958] Weird temporary array allocation

[rguenther at suse dot de]

--- Comment #16 from rguenther at suse dot de  2010-03-28 14:45 ---
Subject: Re:  Weird temporary array allocation

On Sun, 28 Mar 2010, burnus at gcc dot gnu dot org wrote:

> --- Comment #15 from burnus at gcc dot gnu dot org  2010-03-28 14:10 
> ---
> Actually, I am wondering whether one needs to do
>   D.1620_135 = __builtin_malloc (1);
> for temporary arrays. For user-accessible ALLOCATABLE arrays one does - 
> because
> ALLOCATED(array) needs also to be .TRUE. for zero-sized arrays, but for
> temporary arrays one does not. For those one could just do
>   D.1620_135 = 0B
> Will the middle-end optimize __builtin_free(NULL) away?

Not yet, but that's easy to implement.  Note that I will be looking
in detail into malloc/free optimizations, including moving allocation
out of loops.  So there's no need to rush anything and it can wait
for 4.6.

Richard.


-- 


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

[Bug fortran/43266] ICE on invalid: in ensure_not_abstract_walker, at fortran/resolve.c:10290

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2010-03-28 15:05 ---
Created an attachment (id=20231)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20231&action=view)
Fix for the PR

Bootstraps and regtests on FC9/x86_64

Paul


-- 


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

[Bug fortran/43266] ICE on invalid: in ensure_not_abstract_walker, at fortran/resolve.c:10290

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2010-03-28 15:11 ---
For completeness: The test case was based on a post at
http://groups.google.ca/group/comp.lang.fortran/browse_thread/thread/f5ec99089ea72b79


-- 


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

[Bug target/40722] [4.5 Regression] ia32intrin.h defines of _rotl, _rotr conflict with target stdlib.h decls

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2010-03-28 15:34 
---
(In reply to comment #12)
> (In reply to comment #10)
> > Created an attachment (id=20228)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20228&action=view) [edit]
> > Broken stdlib.h
> > 
> > Hi,
> > 
> > This patched caused problems for mingw-w64 stdlib.h, see attachment.
> > 
> 
> Someone from mingw64 should adjust fixincludes/mkfixinc.sh for mingw64.

HJ, please consider reverting your patch.


-- 


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

[Bug c++/43555] New: wrong address calculation of multidimensional variable-length array element

[skir50 at gmail dot com]

In some cases addressing elements of multidimensioanl variable-length array
goes wrong. Consider the program:


#include
#include

int nx,ny;

void f(double *x1d,int choice)
{
  double (*x2d)[nx][ny]=(double(*)[nx][ny])x1d;
  unsigned long delta;
//  (*x2d)[0][0]=123; // <- this line affects the result
  if (choice!=0)
  {
delta=&(*x2d)[1][0]-x1d;
  }
  else
  { 
delta=&(*x2d)[1][0]-x1d;
  }
  printf("Choice: %d, Delta: %ld\n",choice,delta);
}

int main()
{ double *data;
  nx=100;
  ny=100;
  data=(double*)malloc(nx*ny*sizeof(double));
  f(data,0);
  f(data,1);
  free(data);
  return 0;
}


The idea is to get a difference betweet the address of element [1][0] of
100*100 array and beginning of the array. If it is compiled as *.c by gcc,
everiyhing is right, and the output is:

$./a.exe
Choice: 0, Delta: 100
Choice: 1, Delta: 100

But if is compiled as *.cpp by g++, the output is:

$./a.exe
Choice: 0, Delta: 18517576
Choice: 1, Delta: 100

So, the error is in obtaining the address of element [1][0] in "else" section
in function "f". Analysis of assembler listing showed, that compiler makes a
copy of global variable "ny" on a stack and uses that copy to calculate an
address of any array element. But for the presented code it makes
initialisation of the copy only in the "if" section, when "choice!=0". And if
execution flow goes to "else" section, the copy of "ny" remains uninitialized
but still used. So, the calculated address of [1][0] is wrong.

If we add some array usage before "if" (for example, uncomment the commented
line), initialization of the copy of "ny" would be in right place and the
result would be correct.


-- 
   Summary: wrong address calculation of multidimensional variable-
length array element
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skir50 at gmail dot com
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug rtl-optimization/42461] Missed optimisation for pure functions with __builtin_unreachable

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-03-28 15:39 ---
How is this a regression anyway?  __builtin_unreachable () is new with 4.5.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Priority|P2  |P3
Summary|[4.5 Regression] Missed |Missed optimisation for pure
   |optimisation for pure   |functions with
   |functions with  |__builtin_unreachable
   |__builtin_unreachable   |
   Target Milestone|4.5.0   |---


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

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2010-03-28 15:46 
---
(In reply to comment #15)
> I've been discussing this on IRC a while ago with Richard Guenther, but forgot
> to add a record.
> 
> It seems that for 4.5, it is best to leave inlining heruistics as it is.  THe
> code size regression come mainly from bzip that is excercising kind of typical
> "bad luck" scenario.  Other known problem in 4.5 inlining is tramp3d where we
> now deliver worse than best known performance, but still not worse than one of
> 4.4.
> 
> I spent some time playing with this and only way to get 4.5 inliner to solve
> these faults is to add new parameter that allows early inlining to inline
> forwarder functions that do increase code size estimates by small amount.  
> This
> helps to solve both tramp3d and bzip problems but also cause code size issues
> in some benchmarks (mostly not regressions over 4.4) and is quite ugly.
> 
> Since re-tunning heuristics needs significant amount of effort and it was done
> earlier in stage1 of 4.5 after merging changes from pretty-ipa, it seems 
> better
> to leave as it is now. Also after LTO merge it seems, according to results
> posted by Vladimir Marakov, that the inliner is actually perfomring very well
> compared to other compilers.
> 
> For 4.6 I do have number of plans. With FRE in early optimization queue we
> invalidate need for some of early inlining and also IPA stuff should be making
> us less dependent on inling overall.
> 
> But I would propose this PR to be wontfix for 4.5.

Indeed.

There is also some miscounting of overall unit size, Micha has a patch for
that (but it completely chokes tramp3d results).  There is also the
early inliner cleanups I have done at some point.  Thus, I suppose we can
look at this early during 4.6 development again.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/43555] wrong address calculation of multidimensional variable-length array element

[sezeroz at gmail dot com]

--- Comment #1 from sezeroz at gmail dot com  2010-03-28 15:49 ---
Happens with 4.3.0 and 4.4.4 on i686-pc-linux, too. Reproduced the problem with
g++ only at -O0. -O1 and higher output the wanted result.


-- 

sezeroz at gmail dot com changed:

   What|Removed |Added

 CC||sezeroz at gmail dot com


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

[Bug tree-optimization/43431] Diagnostic message is not clear for vectorization profitability analysis

[spop at gcc dot gnu dot org]

--- Comment #2 from spop at gcc dot gnu dot org  2010-03-28 15:56 ---
(In reply to comment #1)
> > What does this message mean?
> > "vector iteration cost = 2056 is divisible by scalar iteration cost = 4 by a
> > factor greater than or equal to the vectorization factor = 4 ."
> > Is the vectorization not profitable?
> > Why?
>
> The cost of one vector iteration is 2056.
> The cost of one scalar iteration is 4.
> 2056/4 = 514
> 514 > 4 (= vectorization factor)
> The vectorization is not profitable.
>
> We want to vectorize only if one vector iteration cost is lower than one 
> scalar
> iteration cost multiplied by vectorization factor.
>

Ok.  Thanks for the explanation.  Could we change the diagnostic
message to read this instead: "the vector iteration cost = 2056
divided by the scalar iteration cost = 4 is greater or equal to
the vectorization factor = 4."

> (Vector cost is so high here, because of the j,i access. We should vectorize
> the outer loop, but we fail because of some unsupported features: unknown 
> inner
> loop bound, need for versioning (for alias) in outer loop.)

I looked at whether loop interchange could help, but interchanging the
two loops seems non trivial to me.


-- 


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

[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817

[rguenth at gcc dot gnu dot org]

--- Comment #26 from rguenth at gcc dot gnu dot org  2010-03-28 15:50 
---
ppc folks, can you re-confirm this bug again?  There have been some register
allocation changes meanwhile.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |WAITING


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

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

--- Comment #5 from howarth at nitro dot med dot uc dot edu  2010-03-28 
16:11 ---
Created an attachment (id=20232)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20232&action=view)
proposed patch to pass -DUSE_EMUTLS via libgcc/config/t-emutls on darwin

Corrected ChangeLog and comment.


-- 

howarth at nitro dot med dot uc dot edu changed:

   What|Removed |Added

  Attachment #20227|0   |1
is obsolete||


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

[Bug tree-optimization/43436] Missed vectorization: "unhandled data-ref"

[spop at gcc dot gnu dot org]

--- Comment #4 from spop at gcc dot gnu dot org  2010-03-28 16:28 ---
What about fixing the diagnostic message like this:

diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index 37ae9b5..44248b3 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -1866,10 +1866,21 @@ vect_analyze_data_refs (loop_vec_info loop_vinfo,
bb_vec_info bb_vinfo)

   if (loop_vinfo)
 {
+  bool res;
+
   loop = LOOP_VINFO_LOOP (loop_vinfo);
-  compute_data_dependences_for_loop (loop, true,
- &LOOP_VINFO_DATAREFS (loop_vinfo),
- &LOOP_VINFO_DDRS (loop_vinfo));
+  res = compute_data_dependences_for_loop
+   (loop, true, &LOOP_VINFO_DATAREFS (loop_vinfo),
+&LOOP_VINFO_DDRS (loop_vinfo));
+
+  if (!res)
+{
+  if (vect_print_dump_info (REPORT_UNVECTORIZED_LOCATIONS))
+   fprintf (vect_dump, "not vectorized: loop contains function calls"
+" or data references that cannot be analyzed");
+  return false;
+}
+
   datarefs = LOOP_VINFO_DATAREFS (loop_vinfo);
 }
   else


-- 


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

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

--- Comment #6 from howarth at nitro dot med dot uc dot edu  2010-03-28 
16:29 ---
Testsuite results for revised patch at
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg02449.html.


-- 


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

[Bug c++/43555] wrong address calculation of multidimensional variable-length array element

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-03-28 16:33 ---
Confirmed.  The problem seems to be gimplification of type sizes where
we end up putting the size calculation stmts into the conditional block,
a place not dominating the 2nd stmt where we re-use it:

  x2d = (double[0:(unsigned int) (SAVE_EXPR <() nx +
-1>)][0:(unsigned int) SAVE_EXPR ] *) x1d;
  if (choice != 0) goto ; else goto ;
  :
  ny.2 = ny;
  D.2820 = ny.2 + -1;
  D.2821 = (unsigned int) D.2820;
  D.2822 = D.2821 + 1;
  D.2823 = &(*x2d)[1]{lb: 0 sz: D.2822 * 8}[0];
  D.2824 = (int) D.2823;
  x1d.3 = (int) x1d;
  D.2826 = D.2824 - x1d.3;
  D.2827 = D.2826 /[ex] 8;
  delta = (long unsigned int) D.2827;
  goto ;
  :
  D.2829 = (unsigned int) D.2820;
  D.2830 = D.2829 + 1;
  D.2831 = &(*x2d)[1]{lb: 0 sz: D.2830 * 8}[0];
  D.2832 = (int) D.2831;
  x1d.4 = (int) x1d;
  D.2834 = D.2832 - x1d.4;
  D.2835 = D.2834 /[ex] 8;
  delta = (long unsigned int) D.2835;
  :
  printf (&"Choice: %d, Delta: %ld\n"[0], choice, delta);

also see how the type-sizes in the cast are not gimplified.  Thus, if
we'd have gimplified type-sizes when gimplifying

  <) nx +
-1>)][0:(unsigned int) (SAVE_EXPR <() ny + -1>)] *) x1d) >>>
>>;

it all would have worked out.  The C frontend seems to be lucky because
it decomposes the address difference internally:

  if (choice != 0)
{
  delta = (long unsigned int) (((int) ((double *) x2d + (unsigned int)
SAVE_EXPR  * 8) - (int) x1d) /[ex] 8);
}
  else
{
  delta = (long unsigned int) (((int) ((double *) x2d + (unsigned int)
SAVE_EXPR  * 8) - (int) x1d) /[ex] 8);
}

but even changing the testcase to sth different shows that for C we
properly gimplify type-sizes of casts.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
  Known to fail||4.3.4 4.4.2 4.5.0
   Last reconfirmed|-00-00 00:00:00 |2010-03-28 16:33:10
   date||


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

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[hubicka at ucw dot cz]

--- Comment #17 from hubicka at ucw dot cz  2010-03-28 16:33 ---
Subject: Re:  [4.5 regression] 0.5% code size
regression caused by r147852

> Indeed.
> 
> There is also some miscounting of overall unit size, Micha has a patch for
> that (but it completely chokes tramp3d results).  There is also the

Where is the patch?

> early inliner cleanups I have done at some point.  Thus, I suppose we can
> look at this early during 4.6 development again.

Well, those should not affect the resulting inlining, right?

Honza


-- 


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

[Bug tree-optimization/43436] Missed vectorization: "unhandled data-ref"

[spop at gcc dot gnu dot org]

--- Comment #5 from spop at gcc dot gnu dot org  2010-03-28 16:35 ---
When defining the missing function like this:

static inline int mid_pred(int a, int b, int c)
{
int t= (a-b)&((a-b)>>31);
a-=t;
b+=t;
b-= (b-c)&((b-c)>>31);
b+= (a-b)&((a-b)>>31);

return b;
}

The vectorization reports: "not vectorized: unsupported use in stmt."

When this function is defined like this:
static inline int mid_pred(int a, int b, int c)
{
  if(a>b){
if(c>b){
  if(c>a) b=a;
  elseb=c;
}
  }else{
if(b>c){
  if(c>a) b=c;
  elseb=a;
}
  }
  return b;
}

the vectorizer stops with: "not vectorized: control flow in loop."


-- 


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

[Bug target/40722] [4.5 Regression] ia32intrin.h defines of _rotl, _rotr conflict with target stdlib.h decls

[hjl at gcc dot gnu dot org]

--- Comment #14 from hjl at gcc dot gnu dot org  2010-03-28 16:41 ---
Subject: Bug 40722

Author: hjl
Date: Sun Mar 28 16:40:50 2010
New Revision: 157784

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157784
Log:
2010-03-28  H.J. Lu  

PR target/40722
* mkfixinc.sh: Revert the last change for mingw.

Modified:
trunk/fixincludes/ChangeLog
trunk/fixincludes/mkfixinc.sh


-- 


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

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[rguenther at suse dot de]

--- Comment #18 from rguenther at suse dot de  2010-03-28 16:43 ---
Subject: Re:  [4.5 regression] 0.5% code size
 regression caused by r147852

On Sun, 28 Mar 2010, hubicka at ucw dot cz wrote:

> --- Comment #17 from hubicka at ucw dot cz  2010-03-28 16:33 ---
> Subject: Re:  [4.5 regression] 0.5% code size
> regression caused by r147852
> 
> > Indeed.
> > 
> > There is also some miscounting of overall unit size, Micha has a patch for
> > that (but it completely chokes tramp3d results).  There is also the
> 
> Where is the patch?

Somewhere - you have to as Micha.

> > early inliner cleanups I have done at some point.  Thus, I suppose we can
> > look at this early during 4.6 development again.
> 
> Well, those should not affect the resulting inlining, right?

In theory not.  In practice it removes the iteration if I remember
correctly.

Richard.


-- 


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

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[hubicka at ucw dot cz]

--- Comment #19 from hubicka at ucw dot cz  2010-03-28 16:56 ---
Subject: Re:  [4.5 regression] 0.5% code size
regression caused by r147852

> > > There is also some miscounting of overall unit size, Micha has a patch for
> > > that (but it completely chokes tramp3d results).  There is also the
> > 
> > Where is the patch?
> 
> Somewhere - you have to as Micha.

I think I saw one but it was wrong.  I would be interested to at least know
what this patch is about :)
> 
> 
> In theory not.  In practice it removes the iteration if I remember
> correctly.

Yes, but that should not affect the metrics (hopefully)
Anyway the 4.6 inliner will probably again behave quite differently - I want to
get FRE
early, possibly get partial inlining done and we will have IPA AA that all
affects effectivity
of inlining.

Honza


-- 


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

[Bug tree-optimization/43431] Diagnostic message is not clear for vectorization profitability analysis

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2010-03-28 16:57 ---
What about fixing this bug with 

diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index afbd342..2601b58 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -2173,9 +2173,9 @@ vect_estimate_min_profitable_iters (loop_vec_info
loop_vinfo)
   else
 {
   if (vect_print_dump_info (REPORT_COST))
-fprintf (vect_dump, "cost model: vector iteration cost = %d "
- "is divisible by scalar iteration cost = %d by a factor "
- "greater than or equal to the vectorization factor = %d .",
+fprintf (vect_dump, "cost model: the vector iteration cost = %d "
+"divided by the scalar iteration cost = %d "
+"is greater or equal to the vectorization factor = %d.",
  vec_inside_cost, scalar_single_iter_cost, vf);
   return -1;
 }


-- 


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

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[rguenther at suse dot de]

--- Comment #20 from rguenther at suse dot de  2010-03-28 17:00 ---
Subject: Re:  [4.5 regression] 0.5% code size
 regression caused by r147852

On Sun, 28 Mar 2010, hubicka at ucw dot cz wrote:

> --- Comment #19 from hubicka at ucw dot cz  2010-03-28 16:56 ---
> Subject: Re:  [4.5 regression] 0.5% code size
> regression caused by r147852
> 
> > > > There is also some miscounting of overall unit size, Micha has a patch 
> > > > for
> > > > that (but it completely chokes tramp3d results).  There is also the
> > > 
> > > Where is the patch?
> > 
> > Somewhere - you have to as Micha.
> 
> I think I saw one but it was wrong.  I would be interested to at least know
> what this patch is about :)

It's about not accounting static called once functions twice when
decreasing overall unit size.

> > In theory not.  In practice it removes the iteration if I remember
> > correctly.
> 
> Yes, but that should not affect the metrics (hopefully)
> Anyway the 4.6 inliner will probably again behave quite differently - I want 
> to
> get FRE
> early, possibly get partial inlining done and we will have IPA AA that all
> affects effectivity
> of inlining.

Of course.

Richard.


-- 


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

[Bug tree-optimization/43431] Diagnostic message is not clear for vectorization profitability analysis

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-03-28 17:01 ---
(In reply to comment #3)
> What about fixing this bug with 
> 
> diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
> index afbd342..2601b58 100644
> --- a/gcc/tree-vect-loop.c
> +++ b/gcc/tree-vect-loop.c
> @@ -2173,9 +2173,9 @@ vect_estimate_min_profitable_iters (loop_vec_info
> loop_vinfo)
>else
>  {
>if (vect_print_dump_info (REPORT_COST))
> -fprintf (vect_dump, "cost model: vector iteration cost = %d "
> - "is divisible by scalar iteration cost = %d by a factor "
> - "greater than or equal to the vectorization factor = %d .",
> +fprintf (vect_dump, "cost model: the vector iteration cost = %d "
> +"divided by the scalar iteration cost = %d "
> +"is greater or equal to the vectorization factor = %d.",
>   vec_inside_cost, scalar_single_iter_cost, vf);
>return -1;
>  }
> 

Looks good to me.


-- 


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

[Bug c/43556] New: Ubuntu : segmentation fault in strchr() obtained with gcc4.4.3 and not with gcc4.4.1

[eric dot cabret at gmail dot com]

My system is Ubuntu 64 bits Lucid Lynx.
with this following small program, I obtain a crazy segmentation fault in
strchr() with gcc4.4.3-4ubuntu5 AND NOT with gcc4.4.1-4ubuntu9 (with same glibc
in both case) :

// gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 -> execution gives a "segmentation fault"
// gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1 -> execution is fully OK
#include 
#include 

char t[]="It: is a gcc4.4.3 bug";

main() {
char *p;

puts(t);
p = strchr(t, ':');
printf("p='%s'\n", p);

return 0;
}

Many best regards.
Eric.


-- 
   Summary: Ubuntu : segmentation fault in strchr() obtained with
gcc4.4.3 and not with gcc4.4.1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot cabret at gmail dot com


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

[Bug libfortran/43551] [4.4/4.5 Regression] Buffered direct I/O reads wrong record

[burnus at gcc dot gnu dot org]

--- Comment #11 from burnus at gcc dot gnu dot org  2010-03-28 17:12 ---
Mine. I have a patch: http://gcc.gnu.org/ml/fortran/2010-03/msg00190.html


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-28 17:12:33
   date||


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

[Bug c/43556] Ubuntu : segmentation fault in strchr() obtained with gcc4.4.3 and not with gcc4.4.1

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-03-28 17:20 ---
Works for me (thus I suggest to file a bug with Ubuntu).

Which optimization options?  Please attach preprocessed source.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c/43557] New: ICE with -combine and -g

[kevin at koconnor dot net]

The following causes an ICE with latest gcc 4.5.0 (svn r157452):


cat > file1.c << EOF
struct s1_s {
int v;
};
struct s1_s g1;
void __attribute__((externally_visible)) func1() {
struct s1_s *l1 = &g1;
l1->v = 0;
}
EOF

cat > file2.c << EOF
extern struct s1_s g1;
void func2() {
&g1;
}
EOF

cc -O -g -fwhole-program -combine -c file1.c file2.c


This appears similar to pr41893.


$ ~/src/gcc/install/bin/gcc -O -g -fwhole-program -combine -c file1.c file2.c
file1.c: In function ‘func1’:
file1.c:5:42: internal compiler error: in simplify_subreg, at
simplify-rtx.c:5139
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ ~/src/gcc/install/bin/gcc --version
gcc (GCC) 4.5.0 20100315 (experimental)
Copyright (C) 2010 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: ICE with -combine and -g
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kevin at koconnor dot net


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

[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

[hubicka at ucw dot cz]

--- Comment #21 from hubicka at ucw dot cz  2010-03-28 17:30 ---
Subject: Re:  [4.5 regression] 0.5% code size
regression caused by r147852

> > I think I saw one but it was wrong.  I would be interested to at least know
> > what this patch is about :)
> 
> It's about not accounting static called once functions twice when
> decreasing overall unit size.
Ah, I saw that one and I think it was wrong (and that is also why it regressed
on tramp3d).  I will dig it out.

Honza


-- 


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

[Bug c++/43558] New: [4.5 Regression] Rejects specialization

[rguenth at gcc dot gnu dot org]

Very recently we started to reject

class Compressible;
template  class Engine;
template 
class Engine
{
public:
  typedef T Element_t;
  Element_t read(int);
};

template 
T Engine::read(int)
{
}

Engine x;

with

t2.ii:12:3: error: prototype for 'T Engine::read(int)' does
not match any in class 'Engine'
t2.ii:8:13: error: candidate is: Element_t Engine::read(int)

(testcase reduced from tramp3d).

But the following is accepted:

template 
class Engine
{
public:
  typedef T Element_t;
  Element_t read(int);
};

template 
T Engine::read(int)
{
}

Engine x;


-- 
   Summary: [4.5 Regression] Rejects specialization
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug c++/43558] [4.5 Regression] Rejects specialization

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-03-28 17:46 ---
EDG accepts both.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P1
   Last reconfirmed|-00-00 00:00:00 |2010-03-28 17:46:42
   date||
   Target Milestone|--- |4.5.0


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

[Bug tree-optimization/43436] Missed vectorization: "unhandled data-ref"

[irar at il dot ibm dot com]

--- Comment #6 from irar at il dot ibm dot com  2010-03-28 18:05 ---
(In reply to comment #4)
> What about fixing the diagnostic message like this:
> 

It would be nice to do the same for SLP (compute_data_dependences_for_bb) for
completeness.

Thanks,
Ira

> diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
> index 37ae9b5..44248b3 100644
> --- a/gcc/tree-vect-data-refs.c
> +++ b/gcc/tree-vect-data-refs.c
> @@ -1866,10 +1866,21 @@ vect_analyze_data_refs (loop_vec_info loop_vinfo,
> bb_vec_info bb_vinfo)
> 
>if (loop_vinfo)
>  {
> +  bool res;
> +
>loop = LOOP_VINFO_LOOP (loop_vinfo);
> -  compute_data_dependences_for_loop (loop, true,
> - &LOOP_VINFO_DATAREFS (loop_vinfo),
> - &LOOP_VINFO_DDRS (loop_vinfo));
> +  res = compute_data_dependences_for_loop
> +   (loop, true, &LOOP_VINFO_DATAREFS (loop_vinfo),
> +&LOOP_VINFO_DDRS (loop_vinfo));
> +
> +  if (!res)
> +{
> +  if (vect_print_dump_info (REPORT_UNVECTORIZED_LOCATIONS))
> +   fprintf (vect_dump, "not vectorized: loop contains function calls"
> +" or data references that cannot be analyzed");
> +  return false;
> +}
> +
>datarefs = LOOP_VINFO_DATAREFS (loop_vinfo);
>  }
>else
> 


-- 


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

[Bug tree-optimization/43436] Missed vectorization: "unhandled data-ref"

[irar at il dot ibm dot com]

--- Comment #7 from irar at il dot ibm dot com  2010-03-28 18:22 ---
(In reply to comment #5)
> When defining the missing function like this:
> 
> static inline int mid_pred(int a, int b, int c)
> {
> int t= (a-b)&((a-b)>>31);
> a-=t;
> b+=t;
> b-= (b-c)&((b-c)>>31);
> b+= (a-b)&((a-b)>>31);
> 
> return b;
> }
> 
> The vectorization reports: "not vectorized: unsupported use in stmt."

Yes, we have an unsupported cycles for l and lt, since they don't match regular
reduction pattern.

> 
> When this function is defined like this:
> static inline int mid_pred(int a, int b, int c)
> {
>   if(a>b){
> if(c>b){
>   if(c>a) b=a;
>   elseb=c;
> }
>   }else{
> if(b>c){
>   if(c>a) b=c;
>   elseb=a;
> }
>   }
>   return b;
> }
> 
> the vectorizer stops with: "not vectorized: control flow in loop."
> 

if-conversion fails with 
l_34 = *D.2750_33;
tree could trap...


-- 


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

[Bug c++/43559] New: Overloaded template functions became ambiguous

[sefi at s-e-f-i dot de]

The following code used to work with gcc-4.4.3.
The Comeau online compiler also accepts it.
But with the gcc-4.5 trunk, it is rejected as ambiguous.


template void f(U&) { }
template void f(T const&) { }

int main()
{
int a;
f(a);
}

This is a reduced test case from boost.phoenix.
I'm not completely sure if gcc-4.5 is now right or wrong. Please investigate.


-- 
   Summary: Overloaded template functions became ambiguous
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sefi at s-e-f-i dot de


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

[Bug c/43560] New: possible wrong code bug

[regehr at cs dot utah dot edu]

I don't believe the program below should crash when run.

Valgrind says the store at line 20 is at fault, which is strange since it looks
like the "if" branch should execute twice and the "else" branch 0 times.

reg...@john-home:~$ current-gcc -O small.c -o small
reg...@john-home:~$ ./small
Segmentation fault
reg...@john-home:~$ cat small.c
#include 

int g_6[1][2] = {{1,1}};
int g_34 = 0;
int *const g_82 = &g_6[0][1];
int *g_85[2][1] = {{&g_34}, {&g_34}};

void func_4 (void)
{
  int i;
  for (i = 0; i <= 1; i++) {
if (g_6[0][1]) {
  *g_82 = 1;
} else {
  int **l_109 = &g_85[1][0];
  if (&g_82 != l_109) {
  } else {
*l_109 = &g_6[0][1];
  }
  *g_82 = 1;
}
  }
}

int main (void)
{
  func_4();
  return 0;
} 

reg...@john-home:~$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/compiler-install/gcc-r157783-install/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r157783-install
--program-prefix=r157783- --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20100328 (experimental) (GCC)


-- 
   Summary: possible wrong code bug
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

--- Comment #7 from howarth at nitro dot med dot uc dot edu  2010-03-28 
19:21 ---
Untested alternative approach to fix this...

Index: libgcc/Makefile.in
===
--- libgcc/Makefile.in  (revision 157785)
+++ libgcc/Makefile.in  (working copy)
@@ -226,7 +226,7 @@
 # will usually contain -g, so for the moment CFLAGS goes first.  We must
 # include CFLAGS - that's where multilib options live.
 INTERNAL_CFLAGS = $(CFLAGS) $(LIBGCC2_CFLAGS) $(HOST_LIBGCC2_CFLAGS) \
- $(INCLUDES) @set_have_cc_tls@
+ $(INCLUDES) @set_have_cc_tls@ @set_use_emutls@

 MULTIDIR := $(shell $(CC) $(CFLAGS) -print-multi-directory)
 MULTIOSDIR := $(shell $(CC) $(CFLAGS) -print-multi-os-directory)
Index: libgcc/configure.ac
===
--- libgcc/configure.ac (revision 157785)
+++ libgcc/configure.ac (working copy)
@@ -238,6 +238,14 @@
 fi
 AC_SUBST(set_have_cc_tls)

+# See if we have emulated thread-local storage.
+GCC_CHECK_EMUTLS
+set_use_emutls=
+if test "$enable_tls $gcc_cv_use_emutls" = "yes yes"; then
+  set_use_emutls="-DUSE_EMUTLS"
+fi
+AC_SUBST(set_use_emutls)
+
 # Conditionalize the makefile for this target machine.
 tmake_file_=
 for f in ${tmake_file}


-- 


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

[Bug c++/43559] Overloaded template functions became ambiguous

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-03-28 19:27 
---
Jason, what do you think?


-- 

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=43559

[Bug c++/43559] Overloaded template functions became ambiguous

[schaub-johannes at web dot de]

--- Comment #2 from schaub-johannes at web dot de  2010-03-28 19:33 ---
I've done some analysis for this using the argument-deduction during partial
ordering rules as clarified by
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#214:

template
void f(U&) { } // #1

template
void f(T const&) { } // #2


4 Each type from the parameter template and the corresponding type from the
argument template are used as the types of P and A.

Round 1, #1 -> #2:

  As: (X&)// #1
  Ps: (T const&)  // #2

Round 2, #2 -> #1:

  As: (X const&)  // #2
  Ps: (T&)// #1

— If P is a reference type, P is replaced by the type referred to.
— If A is a reference type, A is replaced by the type referred to.

=> 

Round 1, #1 -> #2:

  As: (X)  // #1
  Ps: (T const)// #2

Round 2, #2 -> #1:

  As: (X const)   // #2
  Ps: (T) // #1

If both P and A were reference types (before being replaced with the type
referred to above), determine which of the two types (if any) is more
cv-qualified than the other; otherwise the types are considered to be
equally cv-qualified for partial ordering purposes. The result of this
determination will be used below.

=> * #2 more cv-qualified than #1

— If P is a cv-qualified type, P is replaced by the cv-unqualified
version of P.
— If A is a cv-qualified type, A is replaced by the cv-unqualified
version of A.

Round 1, #1 -> #2:

  As: (X) // #1
  Ps: (T) // #2

Round 2, #2 -> #1:

  As: (X) // #2
  Ps: (T) // #1

Using the resulting types P and A the deduction is then done as described in
14.9.2.5. If deduction succeeds for a given type, the type from the argument
template is considered to be at least as specialized as the type from the
parameter template.

Round 1, T <- X   
Round 2, T <- X

#1.param1 at least as specialized as #2.param1 and vice-versa. 

If, for a given type, deduction succeeds in both directions (i.e., the types
are identical after the transformations above) and if the type from the
argument template is more cv-qualified than the type from the parameter
template (as described above) that type is considered to be more specialized
than the other.

  Deduction succeeded in both rounds ("types" as in P/A pairs), but #2.param1
was more cv-qualified 
=> #2.param1 more specialized than #1.param1

If for each type being considered a given template is at least as specialized
for all types and more specialized for some set of types and the other template
is not more specialized for any types or is not at least as specialized for any
types, then the given template is more specialized than the other template.

#2 is at least as specialized for all types and more specialized for #1.param1
and #1 is not more specialized for any types, so #2 is more specialized than
#1. 

So, i think GCC should choose the one with the f(T const&) because that
template is more specialized. Notice that the rules also say

In most cases, all template parameters must have values in order for deduction
to succeed, but for partial ordering purposes a template parameter may remain
without a value provided it is not used in the types being used for partial
ordering. 


-- 


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

[Bug middle-end/40003] apparent spurious uninitialized read from r147052 on integer code

[regehr at cs dot utah dot edu]

--- Comment #2 from regehr at cs dot utah dot edu  2010-03-28 19:34 ---
I no longer see this behavior.


-- 

regehr at cs dot utah dot edu changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug c++/43561] New: Default argument of nested template function causes a compile-time error

[lorcaminiti at gmail dot com]

The code below fails to compile and giving the indicated error message.

Based on the C++ standard, is this a compiler bug or my code is invalid?
Is this related to C++ bug #21903?

$ gcc -v -save-temps -Wall -Werror test/noinherit/09.cpp 
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
 /usr/lib/gcc/i486-linux-gnu/4.2.4/cc1plus -E -quiet -v -D_GNU_SOURCE
test/noinherit/09.cpp -mtune=generic -Wall -Werror -fpch-preprocess -o 09.ii
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.2.4/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.2
 /usr/include/c++/4.2/i486-linux-gnu
 /usr/include/c++/4.2/backward
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.2.4/include
 /usr/include
End of search list.
 /usr/lib/gcc/i486-linux-gnu/4.2.4/cc1plus -fpreprocessed 09.ii -quiet
-dumpbase 09.cpp -mtune=generic -auxbase 09 -Wall -Werror -version
-fstack-protector -fstack-protector -o 09.s
GNU C++ version 4.2.4 (Ubuntu 4.2.4-1ubuntu4) (i486-linux-gnu)
compiled by GNU C version 4.2.4 (Ubuntu 4.2.4-1ubuntu4).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129366
Compiler executable checksum: a9a6f696028630a438a334c3f20809c8
test/noinherit/09.cpp: In instantiation of ‘const bool O::B::sized’:
test/noinherit/09.cpp:9:   instantiated from here
test/noinherit/09.cpp:5: error: the default argument for parameter 1 of ‘static
bool O::B::set(T, bool) [with T = int]’ has not yet been parsed


struct O {
template struct B {
static bool set(T x, bool b = true) { return b; }
static const bool sized = sizeof(set(T())) == 0; // line 5
};

struct D: public B {}; 
static const bool int_sized = B::sized; // line 9
};

void x () {
O::D d;
d.set(1);
} 

int main() {
x();
return 0;
}


-- 
   Summary: Default argument of nested template function causes a
compile-time error
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lorcaminiti at gmail dot com


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

[Bug c/43560] possible wrong code bug

[sezeroz at gmail dot com]

--- Comment #1 from sezeroz at gmail dot com  2010-03-28 20:12 ---
Happens on x86_64-pc-linux-gnu, too. Segfaults with gcc-4.3.0 and 4.3.2 (as
shipped by fedora), but runs fine with 3.3.6, 3.4.6 and my custom 4.4.4.


-- 

sezeroz at gmail dot com changed:

   What|Removed |Added

 CC||sezeroz at gmail dot com


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

[Bug c/43557] ICE with -combine and -g

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2010-03-28 20:22 ---
Confirmed with "cc1 -O -g -fwhole-program file1.c file2.c"

#0  fancy_abort (file=0xd4a558 "../../gcc-svn/trunk/gcc/simplify-rtx.c", 
line=5135, function=0xd4b590 "simplify_subreg")
at ../../gcc-svn/trunk/gcc/diagnostic.c:762
#1  0x0079ec50 in simplify_subreg (outermode=VOIDmode, 
op=0x71f59918, innermode=SImode, byte=0)
at ../../gcc-svn/trunk/gcc/simplify-rtx.c:5135
#2  0x0079ee9e in simplify_gen_subreg (outermode=VOIDmode, 
op=0x71f59918, innermode=SImode, byte=0)
at ../../gcc-svn/trunk/gcc/simplify-rtx.c:5449
#3  0x0055ca74 in expand_debug_expr (exp=0x71f1)
at ../../gcc-svn/trunk/gcc/cfgexpand.c:2416
#4  0x0055b503 in expand_debug_expr (exp=0x71f57510)
at ../../gcc-svn/trunk/gcc/cfgexpand.c:2882
#5  0x0055b02c in expand_debug_expr (exp=0x71f575a0)
at ../../gcc-svn/trunk/gcc/cfgexpand.c:2273
#6  0x0055b37f in expand_debug_expr (exp=0x71ef6318)
at ../../gcc-svn/trunk/gcc/cfgexpand.c:2938
#7  0x0055ebd5 in expand_debug_locations ()
at ../../gcc-svn/trunk/gcc/cfgexpand.c:3072
#8  gimple_expand_cfg () at ../../gcc-svn/trunk/gcc/cfgexpand.c:3834
#9  0x0071273b in execute_one_pass (pass=0x1154a20)
at ../../gcc-svn/trunk/gcc/passes.c:1567


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-28 20:22:55
   date||


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

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

--- Comment #8 from howarth at nitro dot med dot uc dot edu  2010-03-28 
20:31 ---
Created an attachment (id=20233)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20233&action=view)
alternative patch that uses GCC_CHECK_EMUTLS and set_use_emutls


-- 


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

[Bug c/43556] Ubuntu : segmentation fault in strchr() obtained with gcc4.4.3 and not with gcc4.4.1

[eric dot cabret at gmail dot com]

--- Comment #2 from eric dot cabret at gmail dot com  2010-03-28 20:34 
---
Created an attachment (id=20234)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20234&action=view)
Preprocessed source not OK with "gcc -E main.c"


-- 


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

[Bug c/43556] Ubuntu : segmentation fault in strchr() obtained with gcc4.4.3 and not with gcc4.4.1

[eric dot cabret at gmail dot com]

--- Comment #3 from eric dot cabret at gmail dot com  2010-03-28 20:34 
---
Created an attachment (id=20235)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20235&action=view)
Preprocessed source OK with "gcc -E main.c"


-- 


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

[Bug c/43556] Ubuntu : segmentation fault in strchr() obtained with gcc4.4.3 and not with gcc4.4.1

[eric dot cabret at gmail dot com]

--- Comment #4 from eric dot cabret at gmail dot com  2010-03-28 20:35 
---
Created an attachment (id=20236)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20236&action=view)
a.out OK obtained by command "gcc main.c"


-- 


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

[Bug c/43557] ICE with -combine and -g

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2010-03-28 20:35 ---
simplify_gen_subreg is called with VOIDmode outermode.

(gdb) f 3
#3  0x0055ca74 in expand_debug_expr (exp=0x71f1)
at ../../gcc-svn/trunk/gcc/cfgexpand.c:2416
2416  op0 = simplify_gen_subreg (mode, op0, inner_mode,
(gdb) p mode
$8 = VOIDmode

Adding CC.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot org


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

[Bug c/43556] Ubuntu : segmentation fault in strchr() obtained with gcc4.4.3 and not with gcc4.4.1

[eric dot cabret at gmail dot com]

--- Comment #5 from eric dot cabret at gmail dot com  2010-03-28 20:36 
---
Created an attachment (id=20237)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20237&action=view)
a.out not OK obtained by command "gcc main.c"


-- 


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

[Bug c/43556] Ubuntu : segmentation fault in strchr() obtained with gcc4.4.3 and not with gcc4.4.1

[eric dot cabret at gmail dot com]

--- Comment #6 from eric dot cabret at gmail dot com  2010-03-28 20:37 
---
Here are new files (preprocessed sources OK and not OK) and binaries obtained
only with command "gcc main.c"


-- 


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

[Bug fortran/43289] Missed constraint C1271a: Referrencing VOLATILE variable in PURE subprogram

[pault at gcc dot gnu dot org]

--- Comment #1 from pault at gcc dot gnu dot org  2010-03-28 20:39 ---
(In reply to comment #0)

> My understanding is that thus the following program is invalid:
> 
> pure subroutine foo(a, c, d)
>   integer, volatile, intent(inout) :: a, c ! OK
>   integer, volatile :: b ! OK
>   integer :: d
>   b = 4 ! Invalid LHS as "b" is volatile
>   d = b ! Invalid RHS
> end subroutine
> 

I can see why the LHS should be invalid but why the RHS?

I have confirmed it since it is manifestly 50% a bug!  Note that ifort 11.1
does not detect it.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-28 20:39:01
   date||


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

[Bug c/43556] Ubuntu : segmentation fault in strchr() obtained with gcc4.4.3 and not with gcc4.4.1

[eric dot cabret at gmail dot com]

--- Comment #7 from eric dot cabret at gmail dot com  2010-03-28 20:45 
---
Created an attachment (id=20238)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20238&action=view)
a.out OK obtained by command "gcc -g main.c" (with debug infos on 64bit ubuntu)


-- 


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

[Bug c/43556] Ubuntu : segmentation fault in strchr() obtained with gcc4.4.3 and not with gcc4.4.1

[eric dot cabret at gmail dot com]

--- Comment #8 from eric dot cabret at gmail dot com  2010-03-28 20:45 
---
Created an attachment (id=20239)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20239&action=view)
a.out not OK obtained by command "gcc -g main.c" (with debug infos on 64bit
ubuntu)


-- 


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

[Bug fortran/41059] -fwhole-file and error messages

[pault at gcc dot gnu dot org]

--- Comment #1 from pault at gcc dot gnu dot org  2010-03-28 20:50 ---
Dear Dominiq,

Unfortunately, what you report here is a consequence of the way in which
-fwhole-file has to be implemented.  The order changes because of the need to
resolve called procedures and I can well believe that the number of error
messages might change, even though namespaces are tagged when they have been
resolved. I guess that we could tag every line for errors but this would need a
bigger change to error.c than I am prepared to embark on.

My inclination is WONTFIX but I would be happy to discuss.

Paul 


-- 


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

[Bug c/43556] Ubuntu : segmentation fault in strchr() obtained with gcc4.4.3 and not with gcc4.4.1

[eric dot cabret at gmail dot com]

--- Comment #9 from eric dot cabret at gmail dot com  2010-03-28 20:52 
---
Created an attachment (id=20240)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20240&action=view)
File obtained with command "strace -s 1024 ./a_ok_withdebug.out >
strace_s1024_a_ok.txt 2>&1"


-- 


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

[Bug c/43556] Ubuntu : segmentation fault in strchr() obtained with gcc4.4.3 and not with gcc4.4.1

[eric dot cabret at gmail dot com]

--- Comment #10 from eric dot cabret at gmail dot com  2010-03-28 20:52 
---
Created an attachment (id=20241)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20241&action=view)
File obtained with command "strace -s 1024 ./a_nok_withdebug.out >
strace_s1024_a_nok.txt 2>&1"


-- 


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

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

[howarth at nitro dot med dot uc dot edu]

--- Comment #9 from howarth at nitro dot med dot uc dot edu  2010-03-28 
20:59 ---
Confirmed with current gcc trunk on x86_64 Fedora 10 that the alternative patch
which uses GCC_CHECK_EMUTLS still leaves the build properly passing
-DHAVE_CC_TLS  -DUSE_TLS for native TLS targets. 


-- 


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

[Bug c/43556] Ubuntu : segmentation fault in strchr() obtained with gcc4.4.3 and not with gcc4.4.1

[eric dot cabret at gmail dot com]

--- Comment #11 from eric dot cabret at gmail dot com  2010-03-28 21:01 
---
Created an attachment (id=20242)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20242&action=view)
File obtained with command "strace -s 1024 ./a_nok_withdebug.out >
strace_s1024_a_nok.txt 2>&1" (executed on the SAME SYSTEM than file attachment
#20240 that was OK)


-- 


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

[Bug fortran/43532] Segfault using shape intrinsic function with deferred-shape array

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2010-03-28 21:19 ---
Valgrind shows:

==4509== Conditional jump or move depends on uninitialised value(s)
==4509==at 0x4EB51A3: _gfortran_shape_4 (shape_i4.c:47)
==4509==by 0x40091E: myfunc.1553 (hjfdf.f90:19)
==4509==by 0x400A87: MAIN__ (hjfdf.f90:10)
==4509==by 0x400AC2: main (hjfdf.f90:10)
==4509== 
==4509== Use of uninitialised value of size 8
==4509==at 0x4EB51E2: _gfortran_shape_4 (shape_i4.c:53)
==4509==by 0x40091E: myfunc.1553 (hjfdf.f90:19)
==4509==by 0x400A87: MAIN__ (hjfdf.f90:10)
==4509==by 0x400AC2: main (hjfdf.f90:10)
==4509== 
==4509== Invalid write of size 4
==4509==at 0x4EB51E2: _gfortran_shape_4 (shape_i4.c:53)
==4509==by 0x40091E: myfunc.1553 (hjfdf.f90:19)
==4509==by 0x400A87: MAIN__ (hjfdf.f90:10)
==4509==by 0x400AC2: main (hjfdf.f90:10)
==4509==  Address 0x0 is not stack'd, malloc'd or (recently) free'd


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||32834
  nThis||
  Component|libfortran  |fortran
   Keywords||wrong-code
  Known to fail||4.1.2 4.2.1 4.3.4 4.4.4
   ||4.5.0


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

[Bug tree-optimization/43505] [4.5 Regression] type mismatch between an SSA_NAME and its symbol with -O3

[hubicka at gcc dot gnu dot org]

--- Comment #10 from hubicka at gcc dot gnu dot org  2010-03-28 21:47 
---
Subject: Bug 43505

Author: hubicka
Date: Sun Mar 28 21:46:50 2010
New Revision: 157786

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

PR tree-optimization/43505
* cgraph.c (cgraph_clone_node): When clonning a clone, replacement
map should not be copied.
* gfortran.dg/pr43505.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr43505.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libstdc++/43554] profile-mode version of forward_list missing

[rus at google dot com]

--- Comment #1 from rus at google dot com  2010-03-28 22:58 ---
Subject: Re:  profile-mode version of forward_list 
missing

On Sun, Mar 28, 2010 at 3:36 AM, paolo dot carlini at oracle dot com
 wrote:
>
>
> --
>
> paolo dot carlini at oracle dot com changed:
>
>           What    |Removed                     |Added
> 
>             Status|UNCONFIRMED                 |NEW
>     Ever Confirmed|0                           |1
>   Last reconfirmed|-00-00 00:00:00         |2010-03-28 10:36:29
>               date|                            |
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43554
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.


Hello Paolo,

Could you please assign it to me.  (Also feel free to assign any other
unclaimed profile mode bugs to me, current or future.)

Thank you,
Silvius


-- 


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

[Bug fortran/43146] Character constant declared in a module does not transfer correctly

[wirawan0 at gmail dot com]

--- Comment #15 from wirawan0 at gmail dot com  2010-03-28 23:01 ---
Yes, just close it. I'm waiting the gentoo folks to find out which patch was
causing this error. It was so slow there...


-- 


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

[Bug libstdc++/43554] profile-mode version of forward_list missing

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC|rus at google dot com   |
 AssignedTo|unassigned at gcc dot gnu   |rus at google dot com
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug middle-end/43556] Ubuntu : segmentation fault in strchr() obtained with gcc4.4.3 and not with gcc4.4.1

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal
  Component|c   |middle-end


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

[Bug c++/43506] name lookup fails in function template

[yao_yin at 163 dot com]

--- Comment #7 from yao_yin at 163 dot com  2010-03-29 01:56 ---
Sorry, I gave a wrong example..

In fact, the code in PR 29131:
template
int t(T i)
{
  return f (i);  // OK, with g++ 4.4.3
}

int
f (int i)
{
  return i;
}

int
main()
{
  return t(1);
}

can be compiled with g++ 4.4.3

but the following code cannot:

template
int f(int k, T i)
{
  return f(i);  // error: f not visible here
}

int
f (int i) // overload
{
  return i;
}

int
main()
{
  return f(1, 2);
}


-- 

yao_yin at 163 dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |


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

[Bug c/43560] possible wrong code bug

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2010-03-29 02:49 ---
It is caused by revision 147083:

http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00057.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-29 02:49:04
   date||


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

[Bug fortran/43265] [4.3/4.4/4.5 Regression] No EOF condition if reading with '(x)' from an empty file

[jvdelisle at gcc dot gnu dot org]

--- Comment #26 from jvdelisle at gcc dot gnu dot org  2010-03-29 02:50 
---
Reopening.  I have one more regression here related to the patch sequence here.

It has to do with reading a file with no EOR marker at the end of a file.

program test
 character (len=80) :: line
 character (len=20) :: filename
 integer :: n, k=0
 n = command_argument_count()
 if (n > 0) then
call get_command_argument(1,filename)
else
   stop 'argument missing'
endif
 open(unit=25,file=filename,status='old')
 do
read(25,'(a80)',end=100,err=101) line
k = k+1
print*,k,' : ',line(1:len_trim(line))
 enddo
stop "ok"
100 stop 100
101 stop 101
end program test

I know the exact location of the problem in transfer.c (next_record_r) and am
working on a patch.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug c/43560] [4.5 Regession] possible wrong code bug

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Known to fail||4.5.0
  Known to work||4.4.3
Summary|possible wrong code bug |[4.5 Regession] possible
   ||wrong code bug
   Target Milestone|--- |4.5.0
Version|unknown |4.5.0


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

[Bug testsuite/43441] pr42427.c:5:21: fatal error: complex.h: No such file or directory

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2010-03-29 02:52 ---
This is also now present on 4.4 branch.


-- 


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

[Bug middle-end/43562] New: GCC ICE on optimize attribute

[jiez at gcc dot gnu dot org]

GCC ICE on the attached test case.

$ ./cc1 /tmp/t.c
 bak
Analyzing compilation unit
Performing interprocedural optimizations
  <*free_lang_data>  
Assembling functions:
 bak
/tmp/t.c: In function ‘bak’:
/tmp/t.c:17:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: GCC ICE on optimize attribute
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jiez at gcc dot gnu dot org


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

[Bug middle-end/43562] GCC ICE on optimize attribute

[jiez at gcc dot gnu dot org]

--- Comment #1 from jiez at gcc dot gnu dot org  2010-03-29 03:39 ---
Created an attachment (id=20243)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20243&action=view)
The test case


-- 


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