Mike Stump | 1 Feb 2006 01:25
Picon
Favicon

possible Altivec inconsistency

I was looking through the altivec.md file and found the below.  Seems  
like either they should all be "", or "i"; my guess, they should all  
be "i".

(define_insn "altivec_vspltb"
   [(set (match_operand:V16QI 0 "register_operand" "=v")
         (vec_duplicate:V16QI
          (vec_select:QI (match_operand:V16QI 1 "register_operand" "v")
                         (parallel
                          [(match_operand:QI 2 "u5bit_cint_operand"  
"")]))))]
   "TARGET_ALTIVEC"
   "vspltb %0,%1,%2"
   [(set_attr "type" "vecperm")])

(define_insn "altivec_vsplth"
   [(set (match_operand:V8HI 0 "register_operand" "=v")
         (vec_duplicate:V8HI
          (vec_select:HI (match_operand:V8HI 1 "register_operand" "v")
                         (parallel
                          [(match_operand:QI 2 "u5bit_cint_operand"  
"")]))))]
   "TARGET_ALTIVEC"
   "vsplth %0,%1,%2"
   [(set_attr "type" "vecperm")])

(define_insn "altivec_vspltw"
   [(set (match_operand:V4SI 0 "register_operand" "=v")
         (vec_duplicate:V4SI
          (vec_select:SI (match_operand:V4SI 1 "register_operand" "v")
(Continue reading)

David Edelsohn | 1 Feb 2006 02:55
Picon
Favicon

Re: possible Altivec inconsistency

>>>>> Mike Stump writes:

> I was looking through the altivec.md file and found the below.  Seems  
> like either they should all be "", or "i"; my guess, they should all  
> be "i".

	I agree that they all should be "i".

David

H. J. Lu | 1 Feb 2006 02:57

Bad indentation and strange code in fortran/trans-array.c

Around line 3923 in fortran/trans-array.c, there are

      if (expr->ts.type == BT_CHARACTER)
        {
          gcc_assert (expr->ts.cl && expr->ts.cl->length
                      && expr->ts.cl->length->expr_type == EXPR_CONSTANT);
          loop.temp_ss->string_length = gfc_conv_mpz_to_tree
                        (expr->ts.cl->length->value.integer,
                         expr->ts.cl->length->ts.kind);
          expr->ts.cl->backend_decl = loop.temp_ss->string_length;
        }
        loop.temp_ss->data.temp.type = gfc_typenode_for_spec (&expr->ts);
	^^^^^^^^^^^^^^^
		Bad indentation.

      /* ... which can hold our string, if present.  */
      if (expr->ts.type == BT_CHARACTER)
        {
          loop.temp_ss->string_length = TYPE_SIZE_UNIT (loop.temp_ss->data.temp.type);
          se->string_length = loop.temp_ss->string_length;
        }
      else
        loop.temp_ss->string_length = NULL;

Also why are there duplicated

      if (expr->ts.type == BT_CHARACTER)

H.J.

(Continue reading)

Steve Kargl | 1 Feb 2006 03:03
Picon

Re: Bad indentation and strange code in fortran/trans-array.c

On Tue, Jan 31, 2006 at 05:57:04PM -0800, H. J. Lu wrote:
> Around line 3923 in fortran/trans-array.c, there are
> 
>       if (expr->ts.type == BT_CHARACTER)
>         {
>           gcc_assert (expr->ts.cl && expr->ts.cl->length
>                       && expr->ts.cl->length->expr_type == EXPR_CONSTANT);
>           loop.temp_ss->string_length = gfc_conv_mpz_to_tree
>                         (expr->ts.cl->length->value.integer,
>                          expr->ts.cl->length->ts.kind);
>           expr->ts.cl->backend_decl = loop.temp_ss->string_length;
>         }
>         loop.temp_ss->data.temp.type = gfc_typenode_for_spec (&expr->ts);
> 	^^^^^^^^^^^^^^^
> 		Bad indentation.
> 

If you go looking through the gfortran sources, you'll find 
all sorts of GNU style violations.  Many are historical from
when g95 was first integrated into GCC as gfortran.

> Also why are there duplicated

I can't answer that question.

--

-- 
Steve

Bobby McNulty | 1 Feb 2006 04:46

error in libmath on i686-pc-cygwin

An error occurred on trunk, the new libcpp-math.
Stops here, when its linking.
I don't know that much about C programming to fix it.
Its output is printing out something about a missing file in e_expf.c,
at fenv.h.
Bobby

"1.0\" -DHAVE_HIDDEN_VISIBILITY=1 -I. -I../../../../gcc/libgcc-math/i386 
-I../..
/../../gcc/libgcc-math/i386/../include -include 
../../../../gcc/libgcc-math/i386
/sse2.h -Wall -O2 -g -msse2 -msseregparm -mfpmath=sse -march=pentium3 
-fno-math-
errno -fno-trapping-math -ffinite-math-only -fno-rounding-math 
-fno-signaling-na
ns -D__NO_MATH_INLINES -O2 -g -O2 -MT libsse2_la-e_expf.lo -MD -MP -MF 
.deps/lib
sse2_la-e_expf.Tpo -c 
../../../../gcc/libgcc-math/i386/../flt-32/e_expf.c -o lib
sse2_la-e_expf.o
../../../../gcc/libgcc-math/i386/../flt-32/e_expf.c:56:18: error: 
fenv.h: No suc
h file or directory
../../../../gcc/libgcc-math/i386/../flt-32/e_expf.c: In function 
'__libm_sse2_ex
pf':
../../../../gcc/libgcc-math/i386/../flt-32/e_expf.c:87: error: 'fenv_t' 
undeclar
ed (first use in this function)
../../../../gcc/libgcc-math/i386/../flt-32/e_expf.c:87: error: (Each 
(Continue reading)

Andrew Pinski | 1 Feb 2006 05:16
Picon

Re: error in libmath on i686-pc-cygwin


On Jan 31, 2006, at 10:46 PM, Bobby McNulty wrote:

> An error occurred on trunk, the new libcpp-math.
> Stops here, when its linking.
> I don't know that much about C programming to fix it.
> Its output is printing out something about a missing file in e_expf.c,
> at fenv.h.

I created GCC PR 26059 <http://gcc.gnu.org/PR26059> for this
issue as it was already reported as failing on i386-netbsd also.

-- Pinski

Bobby McNulty | 1 Feb 2006 05:36

Re: error in libmath on i686-pc-cygwin

Andrew Pinski wrote:
>
> On Jan 31, 2006, at 10:46 PM, Bobby McNulty wrote:
>
>> An error occurred on trunk, the new libcpp-math.
>> Stops here, when its linking.
>> I don't know that much about C programming to fix it.
>> Its output is printing out something about a missing file in e_expf.c,
>> at fenv.h.
>
> I created GCC PR 26059 <http://gcc.gnu.org/PR26059> for this
> issue as it was already reported as failing on i386-netbsd also.
>
> -- Pinski
>
>
Thanks, Andrew.
Bobby

H. J. Lu | 1 Feb 2006 06:33

Re: Bad indentation and strange code in fortran/trans-array.c

On Tue, Jan 31, 2006 at 06:03:12PM -0800, Steve Kargl wrote:
> On Tue, Jan 31, 2006 at 05:57:04PM -0800, H. J. Lu wrote:
> > Around line 3923 in fortran/trans-array.c, there are
> > 
> >       if (expr->ts.type == BT_CHARACTER)
> >         {
> >           gcc_assert (expr->ts.cl && expr->ts.cl->length
> >                       && expr->ts.cl->length->expr_type == EXPR_CONSTANT);
> >           loop.temp_ss->string_length = gfc_conv_mpz_to_tree
> >                         (expr->ts.cl->length->value.integer,
> >                          expr->ts.cl->length->ts.kind);
> >           expr->ts.cl->backend_decl = loop.temp_ss->string_length;
> >         }
> >         loop.temp_ss->data.temp.type = gfc_typenode_for_spec (&expr->ts);
> > 	^^^^^^^^^^^^^^^
> > 		Bad indentation.
> > 
> 
> If you go looking through the gfortran sources, you'll find 
> all sorts of GNU style violations.  Many are historical from
> when g95 was first integrated into GCC as gfortran.
> 
> 
> > Also why are there duplicated
> 
> I can't answer that question.
> 

I don't know much about FORTRAN front end. Is this patch the same
as the original code?
(Continue reading)

Daniel Berlin | 1 Feb 2006 06:42

Thoughts on imposing a 100k per-comment limit

I was staring at the comment database, and noticed

mysql> select COUNT(*) from longdescs where length(thetext) > 100000;
+----------+
| COUNT(*) |
+----------+
|      271 |
+----------+
1 row in set (0.48 sec)

mysql> select COUNT(*) from longdescs where length(thetext) > 500000;
+----------+
| COUNT(*) |
+----------+
|       35 |
+----------+
1 row in set (0.51 sec)

mysql> select COUNT(*) from longdescs where length(thetext) > 750000;
+----------+
| COUNT(*) |
+----------+
|       12 |
+----------+
1 row in set (0.49 sec)

I can't imagine *any* of these comments are useful to human beings to read.

If you dump the comment text from the >100k comments into a file, it's
actually 71 meg of comments.
(Continue reading)

Paul Thomas | 1 Feb 2006 06:52
Picon

Re: Bad indentation and strange code in fortran/trans-array.c

H. J,

>> <>Also why are there duplicated
>
On the face of , that is very odd. It looks as if the charlen_ is 
obtained, the type obtained and the charlen done over again. I will have 
a look today.

Thanks

Paul


Gmane