[Bug c++/41874] Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning
--- Comment #5 from fw at deneb dot enyo dot de 2010-01-31 09:38 --- Isn't this a wrong-code bug? Or is the information used for the diagnostic not used by the optimizers? -- fw at deneb dot enyo dot de changed: What|Removed |Added CC| |fw at deneb dot enyo dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874
[Bug c++/19351] operator new[] can return heap blocks which are too small
--- Comment #12 from fw at deneb dot enyo dot de 2007-03-23 15:23 --- Subject: Re: operator new[] can return heap blocks which are too small * mmitchel at gcc dot gnu dot org: > What does the C standard say about calloc? That's a similar case; the > multiplication is in calloc. Does it have to report an error? My interpretation is that it must return NULL. (This was fixed in GNU libc years ago.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351
[Bug libstdc++/24712] [4.0 Regression] Accidental ABI change between 4.0.1 and 4.0.2?
--- Comment #3 from fw at deneb dot enyo dot de 2005-11-08 21:12 --- (In reply to comment #2) > I gather therefore that Debian > is building GCC passing --enable-libstdcxx-allocator=mt, something absolutely > not obvious and not trivial in its consequences. Seems to be the case: Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu Does your comment mean that this configuration is strongly discouraged, or that the bug report lacked relevant information? -- fw at deneb dot enyo dot de changed: What|Removed |Added CC| |fw at deneb dot enyo dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24712
[Bug ada/21573] 'Valid attribute on enumeration types with holes
--- Additional Comments From fw at deneb dot enyo dot de 2005-08-12 15:23
---
Another test case, this time without Unchecked_Conversion. See the discussion
at <http://gcc.gnu.org/ml/gcc/2005-08/msg00344.html>.
-- Another test case for PR21573. Note that if PR23354 is fixed and
-- X is initialized to a different value, this test case might no
-- longer check the same bug (but it should still print SUCCESS).
-- (The Bug3_P package is necessary to prevent compile-time
-- evaluation.)
pragma Normalize_Scalars;
with Bug3_P; use Bug3_P;
procedure Bug3 is
X : U;
-- The subtype causes X to be initialized with 0, according to the
-- current Normalize_Scalars rules.
begin
Test (X);
end Bug3;
with Ada.Text_IO; use Ada.Text_IO;
package Bug3_P is
type T is (A, B, C, D);
for T'Size use 8;
for T use (A => 2, B => 3, C => 5, D => 7);
subtype U is T range B .. D;
procedure Test (X : T);
end Bug3_P;
package body Bug3_P is
procedure Test (X : T) is
begin
-- Check with a debugger that X is zero at this point.
if X'Valid then
Put_Line ("FAIL");
else
Put_Line ("SUCCESS");
end if;
end Test;
end Bug3_P;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21573
[Bug ada/23354] New: Normalize_Scalars and enumeration types with holes
Objects are unnecessarily initialized to valid values. The initialization
algorithm is described here:
`Enumeration types'
Objects of an enumeration type are initialized to all one-bits,
i.e. to the value `2 ** typ'Size - 1' unless the subtype excludes
the literal whose Pos value is zero, in which case a code of zero
is used. This choice will always generate an invalid value if one
exists.
But the conclusion is wrong because it does not consider enumeration types with
holes.
-- Run through gnatchop. Compile with -O2.
pragma Normalize_Scalars;
with Ada.Text_IO; use Ada.Text_IO;
procedure Bug4 is
type T is (A, B);
for T use (A => 1, B => 255);
for T'Size use 8;
X : T;
begin
if X'Valid then
Put_Line ("FAIL");
else
Put_Line ("PASS");
end if;
end Bug4;
--
Summary: Normalize_Scalars and enumeration types with holes
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fw at deneb dot enyo dot de
CC: gcc-bugs at gcc dot gnu dot org
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=23354
[Bug c++/23147] Missing declaration of static const members
--- Additional Comments From fw at deneb dot enyo dot de 2005-08-05 21:43 --- (In reply to comment #5) > (In reply to comment #4) > > > What about permitting this as a GNU extension? It seems quite useful for > > template code. > > With "this" you mean omitting the definition? Well, it saves one line of > typing, but I'm not really convinced that justifies an extension. I (incorrectly) feared that GCC would emit the constant for each template instantiation. Therefore, I agree with you that no extension is necessary, and the bug report was completely invalid. Sorry about that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23147
[Bug c++/23147] Missing declaration of static const members
--- Additional Comments From fw at deneb dot enyo dot de 2005-07-31 09:25 --- What about permitting this as a GNU extension? It seems quite useful for template code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23147
[Bug c++/23147] Missing declaration of static const members
--- Additional Comments From fw at deneb dot enyo dot de 2005-07-30 13:45 --- What about a GNU extension which would make this program well-formed? I think it's quite a common pattern, and a requirement to provide a definition would just increase object code size meaninglessly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23147
[Bug c++/23147] New: Missing declaration of static const members
The program below compiles cleanly with GCC 4.0.1, although the definition of
Foo::foo required by the standard (9.4.2/4) is missing.
It probably makes sense to accept such programs as a GNU extension (as long as
the address of the member is not taken).
#include
struct Foo
{
static const int foo = 42;
};
int
main ()
{
std::printf ("%d\n", Foo::foo);
return 0;
}
--
Summary: Missing declaration of static const members
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fw at deneb dot enyo dot de
CC: gcc-bugs at gcc dot gnu dot org
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=23147
[Bug c++/22435] New: Incorrect "may reach end of non-void function" warning
The code below results in an incorrect warning. If the "break" statement is
removed, the warning disappears. The C compiler does not issue the warning for
both programs.
#include
// Imports: extern void abort (void) throw () __attribute__ ((__noreturn__));
inline unsigned
convert_watch(int w)
{
switch (w) {
case 0:
return 0;
// Deleting the following line suppresses the warning.
break;
default:
abort();
}
}
extern void foo(unsigned);
void
add_fd(int w, int* fdh)
{
unsigned u = convert_watch(w); // warning: "may reach end..."
foo(u); // silence unused warning
}
--
Summary: Incorrect "may reach end of non-void function" warning
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fw at deneb dot enyo dot de
CC: gcc-bugs at gcc dot gnu dot org
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=22435
[Bug ada/21573] 'Valid attribute on enumeration types with holes
--- Additional Comments From fw at deneb dot enyo dot de 2005-05-30 17:50 --- In expand_case, we have: unit size user align 32 symtab 0 alias set -1 precision 32 min max RM size > side-effects asm_written arg 0 unit size user align 8 symtab 0 alias set -1 precision 8 min max RM size > readonly unsigned QI file /tmp/bug2_p.ads line 4 size unit size align 8 context result unit size align 32 symtab 0 alias set -1 precision 32 min max pointer_to_this > initial (reg/v:QI 60 [ A ]) arg-type arg-type-as-written incoming-rtl (mem/i:SI (reg/f:SI 53 virtual-incoming-args) [7 A+0 S1 A32]) chain readonly unsigned QI file /tmp/bug2_p.ads line 4 size unit size align 8 context result initial (reg/v:QI 62 [ F ]) arg-type arg-type-as-written incoming-rtl (mem/i:SI (plus:SI (reg/f:SI 53 virtual-incoming-args) (const_int 4 [0x4])) [2 F+0 S1 A32])>> arg 2 elt 1 elt 2 elt 3 elt 4 > /tmp/bug2_p.ads:4> Please note the min and max values of the enumeral_type. The cause seems to be that exp_ch3.adb emits the rep-to-pos function as follows: --function _Rep_To_Pos (A : etype; F : Boolean) return Integer is --begin -- case ityp!(A) is -- when enum-lit'Enum_Rep => return posval; -- when enum-lit'Enum_Rep => return posval; -- ... -- when others => -- [raise Constraint_Error when F "invalid data"] -- return -1; -- end case; --end; I think the argument A should be of a suitable integer type, not the enumeration type, but this might only hide the bug. Maybe Ada should even refrain from setting TYPE_MIN_VALUE and TYPE_MAX_VALUE on its enumeration types. -- What|Removed |Added Component|rtl-optimization|ada http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21573
[Bug ada/21573] 'Valid attribute on enumeration types with holes
--- Additional Comments From fw at deneb dot enyo dot de 2005-05-14 19:35
---
Subject: Re: 'Valid attribute on enumeration types with holes
* pinskia at gcc dot gnu dot org:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
> 19:09 ---
> It works for me on powerpc-darwin with "4.0.0 20050222".
I've looked at the trees generated by the following three-file test
case (in particular the tree dumps for bug2_p.adb), and they look
fine. Maybe it's an i386 back end issue.
-- Run through gnatchop
with Ada.Unchecked_Conversion;
with Ada.Text_IO; use Ada.Text_IO;
with Bug2_P; use Bug2_P;
procedure Bug2 is
function Convert is new Ada.Unchecked_Conversion (N, T);
begin
if V (Convert (0)) then
Put_Line ("FAIL");
else
Put_Line ("SUCCESS");
end if;
end Bug2;
package Bug2_P is
type T is (A, B, C, D);
for T'Size use 8;
for T use (A => 2, B => 3, C => 5, D => 7);
type N is mod 2**8;
function V (X : T) return Boolean;
end Bug2_P;
package body Bug2_P is
function V (X : T) return Boolean is
begin
return X'Valid;
end V;
end Bug2_P;
-- End
The i386 assembly code looks like this:
.type bug2_p__tRP, @function
bug2_p__tRP:
.LFB4:
pushl %ebp
.LCFI0:
movl%esp, %ebp
.LCFI1:
subl$8, %esp
.LCFI2:
movb8(%ebp), %al
movb12(%ebp), %dl
cmpb$3, %al
je .L4
jb .L3
cmpb$5, %al
je .L5
cmpb$7, %al
je .L13
testb %dl, %dl
jne .L8
movl$-1, %eax
leave
ret
.p2align 4,,15
.L3:
xorl%eax, %eax
leave
ret
[...]
I'm not very good at reading AT&T syntax, but it appears that for a
first argument of 0, the branch to .L3 is taken, which returns 0
(instead of the expected -1).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21573
[Bug ada/21573] 'Valid attribute on enumeration types with holes
--- Additional Comments From fw at deneb dot enyo dot de 2005-05-14 19:09 --- I should have mentioned that the N'Value business is solely designed to force a call to the Rep_To_Pos function for T (instead of evaluation of 'Valid at compile time). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21573
[Bug ada/21573] New: 'Valid attribute on enumeration types with holes
The program below is expected to print "SUCCESS" (because 0 is not a valid value
of type T). However, at optimization level -O2 (on i686-pc-linux-gnu), it
prints "FAIL".
with Ada.Unchecked_Conversion;
with Ada.Text_IO; use Ada.Text_IO;
procedure Valid_Enumeration_Holes is
type T is (A, B, C, D);
for T'Size use 8;
for T use (A => 2, B => 3, C => 5, D => 7);
type N is mod 2**8;
function Convert is new Ada.Unchecked_Conversion (N, T);
begin
if Convert (N'Value ("0"))'Valid then
Put_Line ("FAIL");
else
Put_Line ("SUCCESS");
end if;
end Valid_Enumeration_Holes;
--
Summary: 'Valid attribute on enumeration types with holes
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fw at deneb dot enyo dot de
CC: gcc-bugs at gcc dot gnu dot org
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=21573
[Bug ada/20300] New: ICE on undefined value of type derived from Character
The following program results in an ICE: procedure Undefined_Derived_Char is type Char is new Character; C : Char; begin case C is when XXX => null; when others => null; end case; end Undefined_Derived_Char; It seems that the checks in Sem_Ch8.Find_Direct_Name.Undefined should take into account that Case_Typ can be a type derived from one of the character types: if Is_Enumeration_Type (Case_Typ) and then Case_Typ /= Standard_Character and then Case_Typ /= Standard_Wide_Character and then Case_Typ /= Standard_Wide_Wide_Character then Maybe Is_Enumeration_Type (Case_Typ) and not Is_Character_Type (Case_Typ) is the correct test? -- Summary: ICE on undefined value of type derived from Character Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fw at deneb dot enyo dot de CC: gcc-bugs at gcc dot gnu dot org 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=20300
[Bug ada/19587] Unnecessary warning for class-wide out parameters
--- Additional Comments From fw at deneb dot enyo dot de 2005-02-24 22:45 --- But the type conversion is a view conversion, so the operand is not actually evaluated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19587
[Bug ada/19587] New: Unnecessary warning for class-wide out parameters
The follow program results in a warning at the indicated position. As far as I
can tell, the warning is a false positive.
Code like this one immediately suggests itself if you've got two parallel type
hierarchies (and Bar is actually a dispatching operation on the second type
which is not shown here). IMHO, it makes sense to suppress the warning in this
case.
procedure Classwide_Out is
type Foo is abstract tagged null record;
type Foo_Real is new Foo with record
X : Integer;
end record;
procedure Bar (F : out Foo'Class) is
F2 : Foo_Real renames Foo_Real (F);
-- warning: "F" may be referenced before it has a value
begin
F2.X := 0;
end Bar;
F : Foo_Real;
begin
Bar (F);
end Classwide_Out;
--
Summary: Unnecessary warning for class-wide out parameters
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fw at deneb dot enyo dot de
CC: gcc-bugs at gcc dot gnu dot org
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=19587
[Bug c++/19351] operator new[] can return heap blocks which are too small
--- Additional Comments From fw at deneb dot enyo dot de 2005-01-09 23:07 --- There's no multiplication in the source code. The multiplication is an implementation detail. You can hardly use it to justify the semantics of the operation. I would expect that std::bad_alloc is thrown. But I agree that the C++ standard isn't very clear in this area. The implementation must ensure that the postcondition in 5.3.4(10) holds, but the standard doesn't provide a means to signal failure. I'm going to post a note to comp.std.c++ on this matter, but hopefully this will be fixed in GCC as a quality of implementation issue. The necessary overflow check is should be very cheap because the multiplication is always by a constant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351
[Bug c++/19351] operator new[] can return heap blocks which are too small
--- Additional Comments From fw at deneb dot enyo dot de 2005-01-09 22:35 --- Why is this undefined behavior? Would you quote chapter and verse, please? GCC's behavior violates 5.3.4(10): "A new-expression passes the amount of space requested to the allocation function as the first argument of type std::size_t. That argument shall be no less than the size of the object being created; [...]" In this case, the passed value is 16, which is much smaller than the size of the array. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351
[Bug c++/19351] New: operator new[] can return heap blocks which are too small
operator new[] sometimes returns pointers to heap blocks which are too small.
When a new array is allocated, the C++ run-time has to calculate its size. The
product may exceed the maximum value which can be stored in a machine register.
This error is ignored, and the truncated value is used for the heap allocation.
This may lead to heap overflows and therefore security bugs. (See
http://cert.uni-stuttgart.de/advisories/calloc.php for further references.)
The test case below uses a user-defined operator new[] to test for the presence
of this problem. However, the problem itself occurs also with the default
operator new[], but it is probably harder to write a portable test case.
#include
struct foo
{
char data[16];
void* operator new[] (size_t size)
{
VERIFY(size != sizeof(foo));
VERIFY (false);
return malloc(size);
}
};
int
main()
{
size_t size = size_t (-1) / sizeof(foo) + 2;
try
{
foo* f = new foo[size];
VERIFY (f == 0);
VERIFY (false);
}
catch(std::bad_alloc&)
{
return 0;
}
}
--
Summary: operator new[] can return heap blocks which are too
small
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fw at deneb dot enyo dot de
CC: gcc-bugs at gcc dot gnu dot org
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=19351
