[Bug middle-end/37805] [4.3/4.4 Regression] gcc --help=separate

[cnstar9988 at gmail dot com]

--- Comment #5 from cnstar9988 at gmail dot com  2008-10-17 07:30 ---
4.3 branch has the same bug...


-- 


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

[Bug c++/37860] New: default and delete used w/ member functions vs. initialization

[bkoz at gcc dot gnu dot org]

Valid C++0x code is failing to compile. Support for default and delete appears
to be incomplete, as certain valid initialization fails. An example:

struct b
{
  bool t;

  b() = default;
  ~b() = default;
  b& operator=(const b&) = delete;
  b(const b&) = delete;
};

int main()
{
  // copy initialization
  b tst1 = { false }; // valid but error

  // copy initialization. 
  b tst2 = false;

  // direct initialization, copy list initialization syntax
  b tst3 { false }; // valid but error

  // default initialization
  b tst4;
}


See tst1, tst3.

This is related to the GCC bug report about standard layout types but I'm going
to go and file individual bug reports about known issues.


-- 
   Summary: default and delete used w/ member functions vs.
initialization
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
  GCC host triplet: all


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

[Bug c++/37860] default and delete used w/ member functions vs. initialization

[bkoz at gcc dot gnu dot org]

--- Comment #1 from bkoz at gcc dot gnu dot org  2008-10-17 08:19 ---

Sorry, that should have a single argument ctor.

Like:

struct b
{
  bool t;

  b() = default;
  ~b() = default;
  b& operator=(const b&) = delete;
  b(const b&) = delete;

  b(bool) { }
};


Gives:

%g++ -std=c++0x -c atomic_init_forms.cc
atomic_init_forms.cc: In function 'int main()':
atomic_init_forms.cc:8: error: deleted function 'b::b(const b&)'
atomic_init_forms.cc:16: error: used here
atomic_init_forms.cc:8: error: deleted function 'b::b(const b&)'
atomic_init_forms.cc:19: error: used here


-- 


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

[Bug middle-end/37861] New: Bogus array bounds warning

[rguenth at gcc dot gnu dot org]

extern int printf (__const char *__restrict __format, ...);

  static int f2(char formatstr[10][100]) {
int anz;
for( anz = 0; anz < 10; ++anz ) {
  printf( "%d %s\n", anz, formatstr[anz] );
} 
return anz;
  }


  static   char formatstr[10][100];
  int main( void ) {
int anz;
anz = f2(formatstr);
printf( "   %d\n",anz);
return 0;
  }


with -O3 -Wall this reports

t.c: In function ‘main’:
t.c:6: warning: array subscript is above array bounds
t.c:6: warning: array subscript is above array bounds
t.c:6: warning: array subscript is above array bounds
t.c:6: warning: array subscript is above array bounds
t.c:6: warning: array subscript is above array bounds
t.c:6: warning: array subscript is above array bounds
t.c:6: warning: array subscript is above array bounds
t.c:6: warning: array subscript is above array bounds

because we end up with

:
  # anz_23 = PHI 
  D.1572_5 = (long unsigned int) anz_23;
  D.1573_7 = D.1572_5 * 100;
  D.1574_8 = &formatstr[0][D.1573_7];
  printf (&"%d %s\n"[0], anz_23, D.1574_8);
  anz_9 = anz_23 + 1;

:
  # anz_6 = PHI 
  if (anz_6 <= 9)
goto ;
  else
goto ;


-- 
   Summary: Bogus array bounds warning
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: middle-end
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=37861

[Bug c++/37862] New: Parenthesised indirection alters class member access

[nickc at redhat dot com]

Hi Guys,

Compiling and then executing this program:
#include 

class A {
public:
 virtual void get() { printf ("A\n"); }
};
class B:public A {
public:
 virtual void get() { printf ("B\n"); }
};
class C:public B {
};
int main (void)
{
 C c;
 C* p = &c;

 p->A::get();
 (p->A::get)();

 return 0;
}

Results in:

  A
  B

Being displayed, rather than:

  A
  A

As far as I can tell the parentheses around the class member access should not
change anything.

Cheers
  Nick


-- 
   Summary: Parenthesised indirection alters class member access
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nickc at redhat dot com
 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=37862

[Bug tree-optimization/37853] [4.4 Regression] gcc.dg/vect/vect-67.c failing since PRE rewrite

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dberlin at gcc dot gnu dot
   ||org, rguenth at gcc dot gnu
   ||dot org
 Status|UNCONFIRMED |NEW
  Component|middle-end  |tree-optimization
 Ever Confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2008-10-17 08:45:43
   date||
Summary|gcc.dg/vect/vect-67.c   |[4.4 Regression]
   |failing since PRE rewrite   |gcc.dg/vect/vect-67.c
   ||failing since PRE rewrite
   Target Milestone|--- |4.4.0


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

[Bug c/35579] [4.1/4.2/4.3/4.4 Regression] casts to void do not silence -Wunused warnings for the case of __attribute__(( warn_unused_result ))

[bonzini at gnu dot org]

--- Comment #6 from bonzini at gnu dot org  2008-10-17 09:14 ---
It seems bad that *explicit* casts to void cannot silence the warning.  This is
a problem for projects using -Werror and using (void) with due diligence
(including GNU coreutils).


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

  Known to fail||4.1.2 4.2.4 4.3.2 4.4.0
  Known to work||4.0.3
Summary|__attribute__(( |[4.1/4.2/4.3/4.4 Regression]
   |warn_unused_result )) warns |casts to void do not silence
   |when it shouldn't, doesn't  |-Wunused warnings for the
   |warn when it should |case of __attribute__((
   ||warn_unused_result ))


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

[Bug c/35579] [4.1/4.2/4.3/4.4 Regression] casts to void do not silence -Wunused warnings for the case of __attribute__(( warn_unused_result ))

[bonzini at gnu dot org]

--- Comment #7 from bonzini at gnu dot org  2008-10-17 11:12 ---
Totally untested patch.

Index: c-common.c
===
--- c-common.c  (revisione 134435)
+++ c-common.c  (copia locale)
@@ -6762,7 +6762,8 @@ c_warn_unused_result (tree *top_p)
  ftype = TREE_TYPE (ftype);
}

-  if (lookup_attribute ("warn_unused_result", TYPE_ATTRIBUTES (ftype)))
+  if (lookup_attribute ("warn_unused_result", TYPE_ATTRIBUTES (ftype))
+ && !TREE_NO_WARNING (t))
{
  if (fdecl)
warning (0, "%Hignoring return value of %qD, "
Index: c-convert.c
===
--- c-convert.c (revisione 134435)
+++ c-convert.c (copia locale)
@@ -96,7 +96,11 @@ convert (tree type, tree expr)
   return error_mark_node;
 }
   if (code == VOID_TYPE)
-return fold_convert (type, e);
+{
+  if (TREE_CODE (e) == CALL_EXPR)
+   TREE_NO_WARNING (e) == 1;
+  return fold_convert (type, e);
+}
   if (code == INTEGER_TYPE || code == ENUMERAL_TYPE)
 return fold (convert_to_integer (type, e));
   if (code == BOOLEAN_TYPE)
Index: cp/cvt.c
===
--- cp/cvt.c(revisione 134435)
+++ cp/cvt.c(copia locale)
@@ -825,6 +825,7 @@ convert_to_void (tree expr, const char *
   break;

 case CALL_EXPR:   /* We have a special meaning for volatile void fn().  */
+  TREE_NO_WARNING (expr) = 1;
   break;

 case INDIRECT_REF:


-- 


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

[Bug c/35579] [4.1/4.2/4.3/4.4 Regression] casts to void do not silence -Wunused warnings for the case of __attribute__(( warn_unused_result ))

[joseph at codesourcery dot com]

--- Comment #8 from joseph at codesourcery dot com  2008-10-17 11:22 ---
Subject: Re:  [4.1/4.2/4.3/4.4 Regression] casts to void do not
 silence -Wunused warnings for the case of __attribute__(( warn_unused_result
 ))

On Fri, 17 Oct 2008, bonzini at gnu dot org wrote:

> It seems bad that *explicit* casts to void cannot silence the warning.  This 
> is
> a problem for projects using -Werror and using (void) with due diligence
> (including GNU coreutils).

The maintainers of a library using this attribute in its headers have 
decided that casting the return value of the relevant functions to (void) 
is an incorrect use of those functions.  The testsuite duly checks for 
these semantics.  If you disagree with a library maintainer's decision, 
you should bring that up with the library maintainers.  This was discussed 
at length in bug 25509.


-- 


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

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[bonzini at gnu dot org]

--- Comment #16 from bonzini at gnu dot org  2008-10-17 11:40 ---
It does not matter if it is a "security" issue; if void-ifying is not an
acceptable workaround, there must be at the very least a Wno-* option to
disable it.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org
 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |
Summary|can't voidify   |can't disable
   |__attribute__((warn_unused_r|__attribute__((warn_unused_r
   |esult)) |esult))


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

[Bug middle-end/37815] [4.4 Regression] ICE in vt_add_function_parameters (bootstrap error)

[ktietz at gcc dot gnu dot org]

--- Comment #6 from ktietz at gcc dot gnu dot org  2008-10-17 12:25 ---
For target x86_64-pc-mingw32 it is the same

In file included from
/vol/d/sources/gcc_new/gcc_1017/build3/x86_64-pc-mingw32/libstdc++-v3/include/ostream:572,
 from ../../../../libstdc++-v3/src/ostream-inst.cc:35:
/vol/d/sources/gcc_new/gcc_1017/build3/x86_64-pc-mingw32/libstdc++-v3/include/bits/ostream.tcc:
In member function 'std:
:basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
_Traits>::_M_insert(_ValueT) [with _ValueT = long double, _C
harT = char, _Traits = std::char_traits]':
/vol/d/sources/gcc_new/gcc_1017/build3/x86_64-pc-mingw32/libstdc++-v3/include/bits/ostream.tcc:92:
internal compiler err
or: in vt_add_function_parameters, at var-tracking.c:3176
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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

Worth a bug report?

[Pranith Kumar]

Hello,

I ran into the following using gcc 4.2.3 on ubuntu 8.04. I ran it with
-Werror so it died on receiving this warning:

cc1: warnings being treated as errors
tux3fuse.c: In function 'tux3_lookup':
tux3fuse.c:78: warning: initialized field overwritten
tux3fuse.c:78: warning: (near initialization for 'ep.attr')
tux3fuse.c:79: warning: initialized field overwritten
tux3fuse.c:79: warning: (near initialization for 'ep.attr')
tux3fuse.c:80: warning: initialized field overwritten
tux3fuse.c:80: warning: (near initialization for 'ep.attr')
tux3fuse.c:81: warning: initialized field overwritten
tux3fuse.c:81: warning: (near initialization for 'ep.attr')
tux3fuse.c:82: warning: initialized field overwritten
tux3fuse.c:82: warning: (near initialization for 'ep.attr')
tux3fuse.c:83: warning: initialized field overwritten
tux3fuse.c:83: warning: (near initialization for 'ep.attr')
tux3fuse.c:85: warning: initialized field overwritten
tux3fuse.c:85: warning: (near initialization for 'ep.attr')


the code:
struct fuse_entry_param ep = {
.attr.st_mode  = inode->i_mode,
.attr.st_atime = inode->i_atime,
.attr.st_mtime = inode->i_mtime,
.attr.st_ctime = inode->i_ctime,
.attr.st_size  = inode->i_size,
.attr.st_uid   = inode->i_uid,
.attr.st_gid   = inode->i_gid,
.attr.st_nlink = inode->i_links,

.ino = (fuse_ino_t)inode,
.generation = 1,
.attr_timeout = 1.0,
.entry_timeout = 1.0,
};

It worked fine when i changed the code as .attr = { .st_mode = ...}

Thanks,
-- 
Pranith.

[Bug c/35579] false negatives in warn_unused_result

[bonzini at gnu dot org]

--- Comment #9 from bonzini at gnu dot org  2008-10-17 11:37 ---
So I should reopen bug 25509 and leave this one for the false negatives.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

Summary|[4.1/4.2/4.3/4.4 Regression]|false negatives in
   |casts to void do not silence|warn_unused_result
   |-Wunused warnings for the   |
   |case of __attribute__(( |
   |warn_unused_result ))   |


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

[Bug fortran/37850] FAIL: gfortran.dg/c_by_val_1.f & gfortran.dg/value_4.f90 execution test

[mikael dot morin at tele2 dot fr]

--- Comment #3 from mikael dot morin at tele2 dot fr  2008-10-17 12:39 
---
I'm at r141174. 
But I don't think it is one particular revision. 
I have seen this for a couple of weeks now. 
I thought it would be reverted soon. 
Now, I'm not sure it is a gcc bug. 
I have the feeling that my system is somehow broken, but I can't figure out
where. 

Here are the details:
$ /usr/local/bin/gfortran -v
Utilisation des specs internes.
Target: x86_64-unknown-linux-gnu
Configuré avec: ../src/configure --enable-languages=fortran --disable-multilib
Modèle de thread: posix
gcc version 4.4.0 20081016 (experimental) (GCC) 

$ /usr/local/bin/gcc -O0 -g -c value_4.c
$ /usr/local/bin/gfortran -ff2c -w -O0 -g value_4.o value_4.f90 -o value_4
$ ./value_4 
zsh: segmentation fault  ./value_4

(gdb) bt
#0  __muldc3 (a=8, b=0, c=0, d=1) at ../../../src/libgcc/../gcc/libgcc2.c:1834
#1  0x7fb8c55fb351 in __muldc3 (a=8, b=0, c=0, d=1)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#2  0x7fb8c55fb351 in __muldc3 (a=8, b=0, c=0, d=1)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#3  0x7fb8c55fb351 in __muldc3 (a=8, b=0, c=0, d=1)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#4  0x7fb8c55fb351 in __muldc3 (a=-1, b=2, c=4, d=0)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#5  0x004007f7 in c_to_c__ (retval=0x7fffce012220, c1=0 + 0 * I, 
c2=0x7fffce012228) at value_4.c:48
#6  0x0040092d in value_4 () at value_4.f90:39
#7  0x004009e0 in main (argc=1, argv=0x7fffce012338)
at ../../../src/libgfortran/fmain.c:21
#8  0x7fb8c52a6146 in __libc_start_main () from /lib/libc.so.6
#9  0x00400659 in _start ()


this is not fortran-related, reduced-testcase:

#include 
int main ()
{
complex float u = __muldc3 (1, 2, 3, 4); 
return 0;
}


(gdb) bt
#0  __muldc3 (a=10, b=0, c=0, d=1) at ../../../src/libgcc/../gcc/libgcc2.c:1834
#1  0x00400cc1 in __muldc3 (a=10, b=0, c=0, d=1)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#2  0x00400cc1 in __muldc3 (a=10, b=0, c=0, d=1)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#3  0x00400cc1 in __muldc3 (a=10, b=0, c=0, d=1)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#4  0x00400cc1 in __muldc3 (a=10, b=0, c=0, d=1)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#5  0x00400cc1 in __muldc3 (a=10, b=0, c=0, d=1)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#6  0x00400cc1 in __muldc3 (a=1, b=2, c=3, d=4)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#7  0x004004a1 in main () at value_4_f90.c:4


I looked at the offending line, but seen nothing wrong though I have never 
been playing with C complex. 
In fact the code looks like directly taken from the C99 standard, so I bet it's
correct. 

I will see if I can find a working revision. 


-- 


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

[Bug fortran/37850] FAIL: gfortran.dg/c_by_val_1.f & gfortran.dg/value_4.f90 execution test

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2008-10-17 12:54 ---
Looks like pr37808, supposed to be fixed at r 14178.


-- 


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

[Bug target/37396] bootstrap broken on hppa-linux-gnu trunk with ada (20080906)

[ludovic at ludovic-brenta dot org]

--- Comment #3 from ludovic at ludovic-brenta dot org  2008-10-17 13:06 
---
This is a duplicate of PR ada/37034.


-- 


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

[Bug middle-end/37815] [4.4 Regression] ICE in vt_add_function_parameters (bootstrap error)

[krebbel at gcc dot gnu dot org]

--- Comment #7 from krebbel at gcc dot gnu dot org  2008-10-17 13:16 ---
Same on s390x:
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00740.html

Please note that the patch attached to the email most likely isn't a correct
solution.


-- 

krebbel at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu dot
   ||org
   Last reconfirmed|2008-10-13 19:48:06 |2008-10-17 13:16:23
   date||


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

[Bug fortran/37863] New: Display of a value close to 1 shows 2

[sylvestre dot ledru at inria dot fr]

With the code here:

  program pb
  character*10 form
  character*4093 str
  str=' '
  write(form,120) 3,0
  write(str(1:3),form) 1.0d0 - 1.110223024625157D-16
  print *,str(1:10)
 120  format('(f',i2,'.',i2,')')
  end


Compiled with gfortran 4.3.2:
the output is 2

With the gfortran 4.2.4
the result is 1 (which is the right one)

$ gfortran-4.3 -o pb pb.f && ./pb 
  2.   
$ gfortran-4.2 -o pb pb.f && ./pb 
  1.


-- 
   Summary: Display of a value close to 1 shows 2
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvestre dot ledru at inria dot fr


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

[Bug debug/37801] DWARF output for inlined functions doesn't always use DW_TAG_inlined_subroutine

[jason at redhat dot com]

--- Comment #4 from jason at redhat dot com  2008-10-17 15:18 ---
Subject: Re:  DWARF output for inlined functions doesn't
 always use DW_TAG_inlined_subroutine

These bits should not be generated:

  <2><8c>: Abbrev Number: 8 (DW_TAG_lexical_block)
  <3><8d>: Abbrev Number: 8 (DW_TAG_lexical_block)
  <4><8e>: Abbrev Number: 9 (DW_TAG_variable)
 <8f>   DW_AT_abstract_origin: <0x46>
  <4><93>: Abbrev Number: 9 (DW_TAG_variable)
 <94>   DW_AT_abstract_origin: <0x51>

  <2>: Abbrev Number: 8 (DW_TAG_lexical_block)
  <3>: Abbrev Number: 8 (DW_TAG_lexical_block)
  <4>: Abbrev Number: 9 (DW_TAG_variable)
DW_AT_abstract_origin: <0x81>
  <4>: Abbrev Number: 8 (DW_TAG_lexical_block)
  <5>: Abbrev Number: 8 (DW_TAG_lexical_block)
  <6>: Abbrev Number: 9 (DW_TAG_variable)
DW_AT_abstract_origin: <0x46>
  <6>: Abbrev Number: 9 (DW_TAG_variable)
DW_AT_abstract_origin: <0x51>

Basically, when we're generating the debug info for the abstract 
instance of an inline function we shouldn't emit any information about 
other inline functions, as it would be redundant.  We shouldn't see any 
DW_AT_abstract_origin attributes inside a DW_TAG_subprogram with 
DW_AT_inline set.

Incidentally, it seems that we're also emitting these unnecessary 
DW_TAG_lexical_block inside the concrete instances 
(DW_TAG_inlined_subroutine): For instance,

  <3><1a5>: Abbrev Number: 14 (DW_TAG_lexical_block)
 <1a6>   DW_AT_low_pc  : 0x40046f
 <1ae>   DW_AT_high_pc : 0x400479

should be dropped, and

  <4><1b6>: Abbrev Number: 9 (DW_TAG_variable)
 <1b7>   DW_AT_abstract_origin: <0x81>

should be at level 3, directly under the DW_TAG_inlined_subroutine.


-- 


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

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[joseph at codesourcery dot com]

--- Comment #17 from joseph at codesourcery dot com  2008-10-17 15:31 
---
Subject: Re:  can't disable __attribute__((warn_unused_result))

On Fri, 17 Oct 2008, bonzini at gnu dot org wrote:

> It does not matter if it is a "security" issue; if void-ifying is not an
> acceptable workaround, there must be at the very least a Wno-* option to
> disable it.

The workaround is to change the header declaring the function with the 
attribute.  There isn't an option to disable the error for calling a 
prototyped function with the wrong number of arguments either; if you feel 
you know better than the library author how many arguments the function 
should take for a particular use case in the program, you'll need to 
change the library or conform to the API it specifies.  This attribute is 
giving further information about the API for a function.

In the case of fwrite, for example, the only obvious case where checking 
would be useless is if you already are writing an error message before 
exiting with error status and so an error writing the error message could 
not usefully be reported anywhere and wouldn't lead to a change of exit 
status.  This suggests you might have an xfwrite function that looks at 
the return value and acts on it unless a static flag is set to say the 
program is in the process of exiting with an error.  Coding in the style 
suggested by the library API should be easier than trying to work around 
the API to code in another style.


-- 


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

[Bug fortran/37863] Display of a value close to 1 shows 2

[domob at gcc dot gnu dot org]

--- Comment #1 from domob at gcc dot gnu dot org  2008-10-17 15:42 ---
Confirmed on trunk, with this test:

program pb
  write(*,'(F3.0)') 1.0d0 - 1.110223024625157D-16
end

Changing decimals display to a value larger than 0 outputs 1 correctly.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||domob at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-17 15:42:22
   date||


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

[Bug middle-end/37815] [4.4 Regression] ICE in vt_add_function_parameters (bootstrap error)

[joel at gcc dot gnu dot org]

--- Comment #8 from joel at gcc dot gnu dot org  2008-10-17 15:44 ---
Also happens on powerpc-rtems4.10

+===GNAT BUG DETECTED==+
| 4.4.0 20081014 (experimental) [trunk revision 141108]
(powerpc-unknown-rtems4.10) GCC error:|
| in vt_add_function_parameters, at var-tracking.c:3176|
| Error detected around a-clrefi.adb:526   |


-- 


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

[Bug middle-end/37815] [4.4 Regression] ICE in vt_add_function_parameters (bootstrap error)

[joel at gcc dot gnu dot org]

--- Comment #9 from joel at gcc dot gnu dot org  2008-10-17 15:45 ---
*** Bug 37840 has been marked as a duplicate of this bug. ***


-- 

joel at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||joel at gcc dot gnu dot org


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

[Bug ada/37840] ICE compiling Ada [regression]

[joel at gcc dot gnu dot org]

--- Comment #2 from joel at gcc dot gnu dot org  2008-10-17 15:45 ---


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


-- 

joel at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[bonzini at gnu dot org]

--- Comment #18 from bonzini at gnu dot org  2008-10-17 15:48 ---
> In the case of fwrite, for example, the only obvious case where checking 
> would be useless is if you already are writing an error message before 
> exiting with error status and so an error writing the error message could 
> not usefully be reported anywhere and wouldn't lead to a change of exit 
> status.

Not really.  The return code of fwrite is not only useless: worse, it gives a
*false* sense of security.  Stuff can stay in the buffers, only to give errors
when you do an fflush or an fclose, which do not have the attribute in glibc
(as of July 2007).

It is much better to do

  fwrite (buf, m, n, f);
  if (fflush (f) != EOF)
perror ("write");
  if (fclose (f) != EOF)
perror ("close");

than checking the return code of fwrite, and that's more or less what coreutils
does.  Anyway this is OT, because this would be a glibc bug.

Back to the GCC point-of-view, the situation is similar to setting a
format(printf) attribute on a printf-like function that also has some
extension.  It would work for some calls, maybe most, but not for all of them. 
So the solution would be to use -Wno-format, either directly or via #pragma GCC
diagnostic.  This warning is not mandated by any standard, after all.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot org


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

[Bug fortran/37863] [4.3/4.4 Regression] Display of a value close but less to 1 shows 2 with '(F3.0)'

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-10-17 15:50 ---
Jerry, do you have an idea?


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu dot
   ||org
   Severity|critical|normal
   Keywords||wrong-code
   Priority|P3  |P4
Summary|Display of a value close to |[4.3/4.4 Regression] Display
   |1 shows 2   |of a value close but less to
   ||1 shows 2 with '(F3.0)'
   Target Milestone|--- |4.3.3


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

[Bug middle-end/37815] [4.4 Regression] ICE in vt_add_function_parameters (bootstrap error)

[rth at gcc dot gnu dot org]

-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-10-17 13:16:23 |2008-10-17 15:56:19
   date||


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

[Bug c/37850] FAIL: gfortran.dg/c_by_val_1.f & gfortran.dg/value_4.f90 execution test

[mikael dot morin at tele2 dot fr]

--- Comment #5 from mikael dot morin at tele2 dot fr  2008-10-17 16:38 
---
I'v just tried r140349 and r141192. 
It's not better.


-- 

mikael dot morin at tele2 dot fr changed:

   What|Removed |Added

  Component|fortran |c


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

[Bug middle-end/37815] [4.4 Regression] ICE in vt_add_function_parameters (bootstrap error)

[rth at gcc dot gnu dot org]

--- Comment #10 from rth at gcc dot gnu dot org  2008-10-17 16:40 ---
Created an attachment (id=16513)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16513&action=view)
proposed patch

I'm pretty sure this patch is sufficient to return this function to working
order.
I'll have a look at the rest of var-tracking and see where else ought to be 
modified to ignore spill_slot_decl.


-- 


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

[Bug c/25509] can't disable __attribute__((warn_unused_result))

[joseph at codesourcery dot com]

--- Comment #19 from joseph at codesourcery dot com  2008-10-17 16:55 
---
Subject: Re:  can't disable __attribute__((warn_unused_result))

On Fri, 17 Oct 2008, bonzini at gnu dot org wrote:

> > In the case of fwrite, for example, the only obvious case where checking 
> > would be useless is if you already are writing an error message before 
> > exiting with error status and so an error writing the error message could 
> > not usefully be reported anywhere and wouldn't lead to a change of exit 
> > status.
> 
> Not really.  The return code of fwrite is not only useless: worse, it gives a
> *false* sense of security.  Stuff can stay in the buffers, only to give errors
> when you do an fflush or an fclose, which do not have the attribute in glibc
> (as of July 2007).
> 
> It is much better to do
> 
>   fwrite (buf, m, n, f);
>   if (fflush (f) != EOF)
> perror ("write");
>   if (fclose (f) != EOF)
> perror ("close");
> 
> than checking the return code of fwrite, and that's more or less what 
> coreutils
> does.  Anyway this is OT, because this would be a glibc bug.

Yes, I previously noted this as an alternative valid style in comment#6. 
glibc has chosen to make one style much easier than the other and that's a 
matter for the glibc maintainers, not for GCC to work around glibc.

> Back to the GCC point-of-view, the situation is similar to setting a
> format(printf) attribute on a printf-like function that also has some
> extension.  It would work for some calls, maybe most, but not for all of 
> them. 
> So the solution would be to use -Wno-format, either directly or via #pragma 
> GCC
> diagnostic.  This warning is not mandated by any standard, after all.

Yes, all warnings in GCC should have options to control them as a general 
principle of warning control, but some (such as in this case) would be 
there more for a general principle than because they should actually be 
used.  GNU software should not be working around other GNU software; if 
some GNU software has a problem with attributes used in glibc then in the 
first instance the maintainers of both packages should try to ensure that 
glibc's headers and the other software's coding style work well together.


-- 


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

[Bug tree-optimization/37102] [4.3 Regression] out-of-SSA is broken

[amacleod at gcc dot gnu dot org]

--- Comment #23 from amacleod at redhat dot com  2008-10-17 17:37 ---
Subject: Bug 37102

Author: amacleod
Date: Fri Oct 17 17:35:58 2008
New Revision: 141195

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141195
Log:
fix PR tree-optimization/37102

2008-10-17  Andrew MacLeod  <[EMAIL PROTECTED]>

PR tree-optimization/37102
* tree-outof-ssa.c (remove_gimple_phi_args): Remove all the PHI args  
from a node. Check to see if another PHI is dead.
(eliminate_useless_phis): Rename from eliminate_virtual_phis and remove
real PHIs which have no uses.
(rewrite_out_of_ssa): Call eliminate_useless_phis.

2008-10-17  Andrew MacLeod  <[EMAIL PROTECTED]>

PR tree-optimization/37102
* gcc.c-torture/execute/pr37102.c: New Test.


Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr37102.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-outof-ssa.c


-- 


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

[Bug other/26633] [4.1/4.2 Regression] Minimal c++ program using threads and exceptions crashes when compiled statically

[fago at earthlink dot net]

--- Comment #5 from fago at earthlink dot net  2008-10-17 18:06 ---
Just to document: I came across this bug with OpenMP using gcc 4.3.2 on RHEL4,
with static libraries, and found the threads mentioned in #1 and #2.

Linking dynamically fixed the segfaults on RHEL4. It does seem to be a bug in
RHEL4 (glibc per #4?), as it works fine on Fedora 9.


-- 


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

[Bug fortran/37863] [4.3/4.4 Regression] Display of a value close but less to 1 shows 2 with '(F3.0)'

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2008-10-17 19:32 
---
I will try to look at this tonight.


-- 


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

[Bug middle-end/37864] New: incorrect warning from fold

[mrs at apple dot com]

We found an interesting bootstrap failure in gcc after changing a machine
definition some, the important bits are below.  Something is wrong, but it is
hard to say exactly what.  The warning would be fine, if there were no
preprocessor involved.  But, it is.  The warning doesn't make any sense for the
source in stmt.c, and the definitions in insn-*.h are also valid.  When the
preprocessor combines them, then the result is worthy of warning about, but,
that's hardly the fault of stmt.c, or the machine definition.  Logically, we
want to only issue the warning if the code in question came from the user, not
as a combination of macro preprocessing.  I can't recall any other place in the
compiler when we take into consideration the preprocessor like this, so that
makes this case weird in my book.

So, some solutions:

  Don't use -Werror, because stmt.c can warn on some .md files.
  Remove the warning, the benefit isn't work the risk of false positives.
  Keep the warning, but somehow take into consideration the preprocessor (ick).
  Recode how the insn-*.h files are generated to avoid the warning.
  Redo stmt.c to use a local variable and then use that in the conditional.

Thoughts?  Currently we're taking the last approach, but it just feels icky. 
Longer term, would be nice if gcc were architected so that this can't crop up.

$ cat /tmp/t.c
extern int target_flags;
#define ARM ((target_flags & (1 << 16)) != 0)
#define THUMB (!ARM)
#define LONGCALL ((target_flags & (1 << 11)) != 0)

#define ARMLONGCALL ((target_flags & ((1<<16) | (1<<11))) != 0)

// 4.2 version:
//#define HAVE_tablejump (ARM || LONGCALL)
// shows same problem in 4.4
#define HAVE_tablejump (ARMLONGCALL)
#define HAVE_casesi (THUMB)

void foo();

void expand_case()
{
  if (0
  /* If neither casesi or tablejump is available, we can
 only go this way.  */
  || (!HAVE_casesi && !HAVE_tablejump))
foo();
}
$ ./xgcc -B./ -c /tmp/t.c -O
/tmp/t.c: In function 'expand_case':
/tmp/t.c:21: warning: 'and' of mutually exclusive equal-tests is always 0

gcc version 4.4.0 20081003 (experimental) [trunk revision 140855] (GCC)


-- 
   Summary: incorrect warning from fold
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com


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

[Bug pch/13675] #including a precompiled header more than once in the same unit fails

[jakub at gcc dot gnu dot org]

--- Comment #18 from jakub at gcc dot gnu dot org  2008-10-17 20:19 ---
Fixed in 4.4.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/37815] [4.4 Regression] ICE in vt_add_function_parameters (bootstrap error)

[andreast at gcc dot gnu dot org]

--- Comment #11 from andreast at gcc dot gnu dot org  2008-10-17 20:59 
---
Entered in testing part on sparc-solaris2.10

Bootstrap ok. with patch in comment #10


-- 


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

[Bug target/34422] Bootstrap error with --enable-fixed-point

[bernard at brenda-arkle dot me dot uk]

--- Comment #3 from bernard at brenda-arkle dot me dot uk  2008-10-17 21:08 
---
I've seen this with 4.3.1 and 4.3.2 official releases with (as it happens)
athlon-64 again (but 32-bit Linux).  But then I also saw it with 4.3.1
on a pure Pentium4 system, so I don't think it's really 64-bit specific.
I've *never* built successfully with --enable-fixed-point .


-- 

bernard at brenda-arkle dot me dot uk changed:

   What|Removed |Added

 CC||bernard at brenda-arkle dot
   ||me dot uk


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

[Bug fortran/37865] New: gfortran build fails in stage 3 bootstrap with --enable-intermodule

[bernard at brenda-arkle dot me dot uk]

make[3]: Entering directory
`/mnt/devel/lfs/lfs-build/gcc-4.3.2/build-gcc-4.3.2/i686-pc-linux-gnu/libgfortran'
if /bin/sh ./libtool --tag=CC --mode=compile
/mnt/devel/lfs/lfs-build/gcc-4.3.2/build-gcc-4.3.2/./gcc/xgcc
-B/mnt/devel/lfs/lfs-build/gcc-4.3.2/build-gcc-4.3.2/./gcc/
-B/mnt/devel/lfs/lfs-build/gcc-4.3.2/dummy/i686-pc-linux-gnu/bin/
-B/mnt/devel/lfs/lfs-build/gcc-4.3.2/dummy/i686-pc-linux-gnu/lib/ -isystem
/mnt/devel/lfs/lfs-build/gcc-4.3.2/dummy/i686-pc-linux-gnu/include -isystem
/mnt/devel/lfs/lfs-build/gcc-4.3.2/dummy/i686-pc-linux-gnu/sys-include
-DHAVE_CONFIG_H -I. -I../../../gcc-4.3.2/libgfortran -I. 
-iquote../../../gcc-4.3.2/libgfortran/io
-I../../../gcc-4.3.2/libgfortran/../gcc
-I../../../gcc-4.3.2/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE 
-std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings -O2 -g -Wall
-march=athlon64-sse3   -MT fmain.lo -MD -MP -MF ".deps/fmain.Tpo" -c -o
fmain.lo ../../../gcc-4.3.2/libgfortran/fmain.c; \
then mv -f ".deps/fmain.Tpo" ".deps/fmain.Plo"; else rm -f
".deps/fmain.Tpo"; exit 1; fi

... eventually is rendered as

/mnt/devel/lfs/lfs-build/gcc-4.3.2/build-gcc-4.3.2/./gcc/xgcc
-B/mnt/devel/lfs/lfs-build/gcc-4.3.2/build-gcc-4.3.2/./gcc/
-B/mnt/devel/lfs/lfs-build/gcc-4.3.2/dummy/i686-pc-linux-gnu/bin/
-B/mnt/devel/lfs/lfs-build/gcc-4.3.2/dummy/i686-pc-linux-gnu/lib/ -isystem
/mnt/devel/lfs/lfs-build/gcc-4.3.2/dummy/i686-pc-linux-gnu/include -isystem
/mnt/devel/lfs/lfs-build/gcc-4.3.2/dummy/i686-pc-linux-gnu/sys-include
-DHAVE_CONFIG_H -I. -I../../../gcc-4.3.2/libgfortran -I.
-iquote../../../gcc-4.3.2/libgfortran/io
-I../../../gcc-4.3.2/libgfortran/../gcc
-I../../../gcc-4.3.2/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE
-std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings -O2 -g -Wall
-march=athlon64-sse3 -c ../../../gcc-4.3.2/libgfortran/runtime/backtrace.c
../../../gcc-4.3.2/libgfortran/runtime/compile_options.c
../../../gcc-4.3.2/libgfortran/runtime/environ.c
../../../gcc-4.3.2/libgfortran/runtime/error.c
../../../gcc-4.3.2/libgfortran/runtime/fpu.c
../../../gcc-4.3.2/libgfortran/runtime/main.c
../../../gcc-4.3.2/libgfortran/runtime/memory.c
../../../gcc-4.3.2/libgfortran/runtime/pause.c
../../../gcc-4.3.2/libgfortran/runtime/stop.c
../../../gcc-4.3.2/libgfortran/runtime/string.c
../../../gcc-4.3.2/libgfortran/runtime/select.c
../../../gcc-4.3.2/libgfortran/generated/all_l1.c
../../../gcc-4.3.2/libgfortran/generated/all_l2.c
../../../gcc-4.3.2/libgfortran/generated/all_l4.c
../../../gcc-4.3.2/libgfortran/generated/all_l8.c
../../../gcc-4.3.2/libgfortran/generated/all_l16.c
../../../gcc-4.3.2/libgfortran/generated/any_l1.c
../../../gcc-4.3.2/libgfortran/generated/any_l2.c
../../../gcc-4.3.2/libgfortran/generated/any_l4.c
../../../gcc-4.3.2/libgfortran/generated/any_l8.c
../../../gcc-4.3.2/libgfortran/generated/any_l16.c
../../../gcc-4.3.2/libgfortran/generated/count_1_l.c
../../../gcc-4.3.2/libgfortran/generated/count_2_l.c
../../../gcc-4.3.2/libgfortran/generated/count_4_l.c
../../../gcc-4.3.2/libgfortran/generated/count_8_l.c
../../../gcc-4.3.2/libgfortran/generated/count_16_l.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_4_i1.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_8_i1.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_16_i1.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_4_i2.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_8_i2.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_16_i2.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_4_i4.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_8_i4.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_16_i4.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_4_i8.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_8_i8.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_16_i8.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_4_i16.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_8_i16.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_16_i16.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_4_r4.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_8_r4.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_16_r4.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_4_r8.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_8_r8.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_16_r8.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_4_r10.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_8_r10.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_16_r10.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_4_r16.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_8_r16.c
../../../gcc-4.3.2/libgfortran/generated/maxloc0_16_r16.c
../../../gcc-4.3.2/libgfortran/generated/maxloc1_4_i1.c
../../../gcc-4.3.2/libgfortran/generated/maxloc1_8_i1.c
../../../gcc-4.3.2/libgfortran/generated/maxloc1_16_i1.c
../../../gcc-4.3.2/libgfortran/generated/maxloc1_4_i2.c
../../../gcc-4.3.2/libgfortr

[Bug middle-end/37809] [4.2/4.3/4.4 Regression] Incorrect code with MMX right shift __builtin_ia32_psradi

[suckfish at ihug dot co dot nz]

--- Comment #6 from suckfish at ihug dot co dot nz  2008-10-17 22:18 ---
Pleasantly, my fears that this was just the tip of the iceburg seems to be
wrong.  Writing some test cases, found another bug involving a shift, and also
the ICE below [fixed by some combination of change above and 38707 fix.]

Will fix the remaining case & post patches to gcc-patches list.

#include 
typedef int v2si __attribute__ ((vector_size (8)));
v2si shiftU (v2si y)
{
return _m_psrldi (_m_psrldi (y, 0), 0);
}

$ gcc -O shift2.c
shift2.c: In function ‘shiftU’:
shift2.c:6: internal compiler error: in trunc_int_for_mode, at explow.c:55
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/cckqI2oC.out file, please attach this to
your bugreport.


-- 


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

[Bug c/37866] New: "passing argument from incompatible pointer type" warning cannot be passed to -Werror=

[flameeyes at gentoo dot org]

The new -Werror= option for GCC 4.3 is very useful to make GCC error out for
specific warnings, but it currently lacks a way to make that warning an error
(which is very useful to avoid skipping parameters in fprintf()-like functions.

Even -fdiagnostics-show-option suggested by the manual doesn't show an option
name near those warnings, which seems to be available only with -Wall.


-- 
   Summary: "passing argument from incompatible pointer type"
warning cannot be passed to -Werror=
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: flameeyes at gentoo dot org
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug c/37866] "passing argument from incompatible pointer type" warning cannot be passed to -Werror=

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-10-17 22:34 ---
That is because this is a pedantic warning which is enabled by default.


-- 


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

[Bug c/37866] "passing argument from incompatible pointer type" warning cannot be passed to -Werror=

[flameeyes at gentoo dot org]

--- Comment #2 from flameeyes at gentoo dot org  2008-10-17 22:36 ---
Which gives it even more usefulness to be optionally treated as an error, since
it really helps to avoid shooting oneself in the foot...

I guess it would be bad to have a way to -Wno- it, but it would be nice to at
least being able to -Werror= it...


-- 


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

[Bug libfortran/37707] Namelist read of array of derived type incorrect

[jvdelisle at gcc dot gnu dot org]

--- Comment #11 from jvdelisle at gcc dot gnu dot org  2008-10-18 05:25 
---
Subject: Bug 37707

Author: jvdelisle
Date: Sat Oct 18 05:23:47 2008
New Revision: 141207

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141207
Log:
2008-10-17  Jerry DeLisle  <[EMAIL PROTECTED]

PR libfortran/37707
* io/write_float.def (WRITE_FLOAT): Round to 1.0 correctly.
* io/io.h (st_parameter_44): Fix id type declaration.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/io.h
trunk/libgfortran/io/write_float.def


-- 


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

[Bug fortran/37863] [4.3/4.4 Regression] Display of a value close but less to 1 shows 2 with '(F3.0)'

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2008-10-18 05:28 
---
Subject: Bug 37863

Author: jvdelisle
Date: Sat Oct 18 05:27:23 2008
New Revision: 141208

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141208
Log:
Fix ChangeLog
2008-10-17  Jerry DeLisle  <[EMAIL PROTECTED]

PR libfortran/37863
* io/write_float.def (WRITE_FLOAT): Round to 1.0 correctly.
* io/io.h (st_parameter_44): Fix id type declaration.

Modified:
trunk/libgfortran/ChangeLog


-- 


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

[Bug fortran/37863] [4.3/4.4 Regression] Display of a value close but less to 1 shows 2 with '(F3.0)'

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2008-10-18 05:32 
---
Fixed on trunk. I accidentally committed the patch with the wrong PR number in
the Changelog (37707)

This I will backport to 4.3 in a day.


-- 


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

[Bug libfortran/37707] Namelist read of array of derived type incorrect

[jvdelisle at gcc dot gnu dot org]

--- Comment #12 from jvdelisle at gcc dot gnu dot org  2008-10-18 05:36 
---
Ignore comment #11.  I got wrong PR number in Changelog.  Should have been
37863.


-- 


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