--- Comment #10 from bonzini at gnu dot org 2008-04-01 07:08 ---
Subject: Re: [4.3/4.4 Regression]: Combined gcc + binutils
source tree doesn't bootstrap
hjl dot tools at gmail dot com wrote:
> --- Comment #5 from hjl dot tools at gmail dot com 2008-03-31 18:16
> ---
> (In r
--- Comment #20 from pinskia at gcc dot gnu dot org 2008-04-01 07:11
---
I am just going to test this patch and relook at it when the test is finished
but I can see what the issue is. at -O0 we have unit-at-a-time on. Though
there is still an issue if we don't have any clones, I think
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org
--- Comment #2 from pault at gcc dot gnu dot org 2008-04-01 07:29 ---
(In reply to comment #1)
> Confirm. This is a 4.3.x/4.4.0 regression
>
> Fails: 2007-05-09-r124566
> Works: 2007-05-08-r124539
>
> There are three checkins in that period, I think the following is most likely.
> I re
--- Comment #7 from herwig at gdsys dot de 2008-04-01 07:58 ---
(In reply to comment #5)
> (In reply to comment #0)
> > The following stripped down code shows pure virtual method definitions for
> > both
> > a normal base class and a templated base class. To my surprise, the
> > templa
Using the parameter ONE in the PRIVATE stanza of the parallel do in the below
code produces the shown error. This error only occurs if the subroutine is in a
module file.
[EMAIL PROTECTED] $ gfortran-4.3 -fopenmp -c test.f90
test.f90: In function test:
test.f90:8: internal compiler error: in gfc
--- Comment #15 from d at domob dot eu 2008-04-01 08:12 ---
The bootstrap problem is fixed, but with dynamic lengths I'm still struggling
;)
However, the following program without typespec in the array constructor also
fails (according to my judging what it should do) both with 4.3 and m
--- Comment #7 from george at gcc dot gnu dot org 2008-04-01 08:24 ---
Can't verify that the patch provided works. After three attempts at a build
(one just by patching libgfortran.h followed by a "make", one by "make
clean-target-libgfortran" followed by "make" and one built from scrat
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||bernds at gcc dot gnu dot
|
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-04-01 11:11
---
i686-pc-linux-gnu or x86_64-unknown-linux-gnu (with -m32)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35739
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2008-04-01 10:43
---
(In reply to comment #7)
> .libs/in_unpack_generic.o: In function `putc_unlocked':
> .libs/in_unpack_generic.o(.text+0x2220): multiple definition of
> `putc_unlocked'
> .libs/backtrace.o(.text+0x27c0): first defi
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-01 11:05 ---
4.3 produces
.L5:
callf
subl$1, %ebx
jne .L5
thus fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from hubicka at gcc dot gnu dot org 2008-04-01 08:41 ---
Subject: Bug 35781
Author: hubicka
Date: Tue Apr 1 08:41:14 2008
New Revision: 133786
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133786
Log:
PR middle-end/35781
* m32c/m32.c (m32c_leaf_
--- Comment #16 from burnus at gcc dot gnu dot org 2008-04-01 10:17 ---
(In reply to comment #15)
> However, the following program without typespec in the array constructor also
> fails (according to my judging what it should do)
Different compilers give different output for this one, b
--- Comment #4 from dominiq at lps dot ens dot fr 2008-04-01 10:28 ---
On i686-apple-darwin9, the failure occurs only in 32 bit mode (default). I also
occurs on powerpc-apple-darwin8.5.0:
http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00013.html
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #6 from rsandifo at nildram dot co dot uk 2008-04-01 08:52
---
Subject: Re: gcc.c-torture/compile/20010226-1.c:22: ICE: in do_output_reload,
at reload1.c:7331
"dave at hiauly1 dot hia dot nrc dot ca" <[EMAIL PROTECTED]> writes:
>> I suppose the assumption in pa.md is that
--- Comment #2 from jakub at gcc dot gnu dot org 2008-04-01 09:18 ---
Can't reproduce. What target?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35739
--- Comment #17 from jakub at gcc dot gnu dot org 2008-04-01 10:58 ---
Subject: Bug 13675
Author: jakub
Date: Tue Apr 1 10:58:02 2008
New Revision: 133790
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133790
Log:
PR pch/13675
* files.c (struct _cpp_file): Remov
--- Comment #11 from oblivian at users dot sourceforge dot net 2008-04-01
10:24 ---
(In reply to comment #10)
> Subject: Re: [4.3/4.4 Regression]: Combined gcc + binutils
> source tree doesn't bootstrap
> # When ld-new is first executed from the build tree, libtool
> # will relink it
--- Comment #3 from dominiq at lps dot ens dot fr 2008-04-01 09:39 ---
The test fails on i686-apple-darwin9 at revision 133785:
FAIL: gcc.dg/pr35729.c scan-rtl-dump-times loop2_invariant "Decided to move
invariant" 0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35729
--- Comment #12 from bonzini at gnu dot org 2008-04-01 11:21 ---
I think there are two bugs. One is the infinite loop, and H.J.'s patch is
"masking" it by patching gcc/exec-tool.in (which is why I'd prefer to have the
"masking" in ld/Makefile.am). The other is yours, which does not hav
--- Comment #14 from bonzini at gnu dot org 2008-04-01 11:54 ---
hm, I see now. H.J. hold on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
--- Comment #13 from oblivian at users dot sourceforge dot net 2008-04-01
11:51 ---
(In reply to comment #12)
> I think there are two bugs. One is the infinite loop, and H.J.'s patch is
> "masking" it by patching gcc/exec-tool.in (which is why I'd prefer to have the
> "masking" in ld/M
--- Comment #15 from oblivian at users dot sourceforge dot net 2008-04-01
11:57 ---
In fact the more I think about it, the search path clean up is what has
definitely got to be killing this build. The binutils configure scripts rely
on the retargeted search paths to come from the previ
--- Comment #16 from bonzini at gnu dot org 2008-04-01 12:08 ---
> The stage 1 ld works as far as linking the stage 1 gcc which is directly after
> it. It's only when we get to stage 2 that things break.
This is a red herring. stage 1 ld goes through the same relink process, but it
u
--- Comment #17 from oblivian at users dot sourceforge dot net 2008-04-01
12:14 ---
I understand the difference now, and thanks.
Still not sure why I can make it through the whole host bootstrap phase without
his patch though. Maybe a 4.4 specific change issue?
Let me know if you ope
--- Comment #8 from bangerth at math dot tamu dot edu 2008-04-01 12:52
---
Subject: Re: Pure virtual method body omitted from template
> thanks for the clarification. I should have realized it myself, though. I
> solved the problem in another way, but out of pure curiosity: How can I
--- Comment #19 from oblivian at users dot sourceforge dot net 2008-04-01
12:40 ---
(In reply to comment #18)
> Created an attachment (id=15402)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15402&action=view) [edit]
> my version of H.J.'s patch
>
> I think this is the right way
--- Comment #17 from d at domob dot eu 2008-04-01 12:53 ---
I see, thanks! I thought it would be the longest length (i.e., clipped by the
array definition assigned to).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997
--- Comment #18 from bonzini at gnu dot org 2008-04-01 12:33 ---
Created an attachment (id=15402)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15402&action=view)
my version of H.J.'s patch
I think this is the right way to do it, more or less.
Can anyone test it? (I don't have b
--- Comment #1 from burnus at gcc dot gnu dot org 2008-04-01 13:22 ---
Thanks for the report; the internal compiler error is definitely a compiler
bug. However, I believe the program is invalid.
If I read "2.8.3.3 private clause" in the OpenMP 2.5 specification correctly,
the items in t
--- Comment #9 from schwab at suse dot de 2008-04-01 13:29 ---
Fixed in 4.3, wontfix for the older versions.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #3 from schwab at suse dot de 2008-04-01 13:24 ---
This is no longer reproducible, closing as fixed.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #9 from jakub at gcc dot gnu dot org 2008-04-01 13:31 ---
Testing a patch with a langhook.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from schwab at suse dot de 2008-04-01 13:32 ---
No longer reproducible with 4.3.
--
schwab at suse dot de changed:
What|Removed |Added
Known to work|
--- Comment #6 from schwab at suse dot de 2008-04-01 13:34 ---
WONTFIX for the pch issue.
--
schwab at suse dot de changed:
What|Removed |Added
Status|NEW
Hello
I am using the latest version of cygwin to compile c++ programs into to
mips-elfs, and I have several serious problems. One in particular is that fact
that the allocation and deallocation of memory on the stack for function and
procedure calls is not done correctly. For some reason the
--- Comment #2 from derrick_chi at msn dot com 2008-04-01 14:27 ---
Created an attachment (id=15404)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15404&action=view)
C++ function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35788
--- Comment #3 from derrick_chi at msn dot com 2008-04-01 14:27 ---
Created an attachment (id=15405)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15405&action=view)
global variables .h file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35788
--- Comment #4 from derrick_chi at msn dot com 2008-04-01 14:28 ---
Created an attachment (id=15406)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15406&action=view)
delay function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35788
--- Comment #21 from oblivian at users dot sourceforge dot net 2008-04-01
13:53 ---
(In reply to comment #20)
> if it reaches the end of ld compilation in stage2, that's already enough.
> (and
> less than 4 hours).
>
Sorry, but for me to test it I have to wait until the pass 2 compi
--- Comment #2 from J dot Hogg at rl dot ac dot uk 2008-04-01 14:13 ---
(In reply to comment #1)
> Thanks for the report; the internal compiler error is definitely a compiler
> bug. However, I believe the program is invalid.
I know the program is invalid (thought that went without sayin
--- Comment #1 from derrick_chi at msn dot com 2008-04-01 14:26 ---
Created an attachment (id=15403)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15403&action=view)
C++ code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35788
--- Comment #5 from derrick_chi at msn dot com 2008-04-01 14:28 ---
Created an attachment (id=15407)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15407&action=view)
i2c function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35788
--- Comment #18 from burnus at gcc dot gnu dot org 2008-04-01 14:18 ---
> I see, thanks! I thought it would be the longest length (i.e., clipped by the
> array definition assigned to).
For completeness: See "4.7 Construction of array values" in the Fortran 2003
standard (http://gcc.gnu
--- Comment #20 from bonzini at gnu dot org 2008-04-01 13:49 ---
if it reaches the end of ld compilation in stage2, that's already enough. (and
less than 4 hours).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-01 14:11 ---
I probably already have a fix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Revision 133680 breaks 447.dealII in SPEC CPU 2006:
error_estimator.cc: In static member function 'static void
KellyErrorEstimator::integrate_over_irregular_face(const DoFHandler&,
const Quadrature<(dim - 1)>&, const std::vector >&, const std::vector >&, const Function*, std::map::face_iterator, s
--- Comment #9 from herwig at gdsys dot de 2008-04-01 14:38 ---
(In reply to comment #8)
> Subject: Re: Pure virtual method body omitted from template
>
>
> > thanks for the clarification. I should have realized it myself, though. I
> > solved the problem in another way, but out of pu
--- Comment #10 from bangerth at math dot tamu dot edu 2008-04-01 14:44
---
Subject: Re: Pure virtual method body omitted from template
> Or did you mean that the function definition is in the TBase header file? If
> so: It is.
Yes. Since the class declaration must be visible from t
--- Comment #3 from rguenther at suse dot de 2008-04-01 14:57 ---
Subject: Re: [4.4 Regression]: Revision 133680
breaks 447.dealII
On Tue, 1 Apr 2008, bangerth at dealii dot org wrote:
> --- Comment #2 from bangerth at dealii dot org 2008-04-01 14:54 ---
> (In reply to comme
--- Comment #2 from bangerth at dealii dot org 2008-04-01 14:54 ---
(In reply to comment #0)
> error_estimator.cc: In static member function 'static void
> KellyErrorEstimator::integrate_over_irregular_face(const
> DoFHandler&,
> const Quadrature<(dim - 1)>&, const std::vector std::allo
--- Comment #18 from jamborm at gcc dot gnu dot org 2008-04-01 14:50
---
I'm now working on a proper fix.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-01 15:14 ---
Btw, I don't see this error in our runs - what flags do you use for
compilation?
Which target is affected and can you attach preprocessed source?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35787
--- Comment #22 from oblivian at users dot sourceforge dot net 2008-04-01
15:30 ---
Doesn't work. In my setup enable-fast-install is not getting set, but the
prev-ld is generating an lt-ld-new, so it assumes it should use the current ld
instead of the prev-ld binary.
--
http://gcc
--- Comment #23 from bonzini at gnu dot org 2008-04-01 15:36 ---
and if you modify collect-ld manually to set it to yes?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
--- Comment #24 from oblivian at users dot sourceforge dot net 2008-04-01
15:39 ---
(In reply to comment #23)
> and if you modify collect-ld manually to set it to yes?
>
Sure that works, but doesn't that defeat the purpose? :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
--- Comment #25 from oblivian at users dot sourceforge dot net 2008-04-01
15:41 ---
(In reply to comment #24)
> (In reply to comment #23)
> > and if you modify collect-ld manually to set it to yes?
> >
> Sure that works, but doesn't that defeat the purpose? :)
>
How about changing it
--- Comment #26 from Ralf dot Wildenhues at gmx dot de 2008-04-01 15:42
---
Subject: Re: [4.3/4.4 Regression]: Combined gcc +
binutils source tree doesn't bootstrap
* bonzini at gnu dot org wrote on Tue, Apr 01, 2008 at 05:36:52PM CEST:
> --- Comment #23 from bonzini at gn
--- Comment #27 from bonzini at gnu dot org 2008-04-01 15:42 ---
Subject: Re: [4.3/4.4 Regression]: Combined gcc + binutils
source tree doesn't bootstrap
oblivian at users dot sourceforge dot net wrote:
> --- Comment #24 from oblivian at users dot sourceforge dot net
> 2008-04-0
--- Comment #28 from hjl dot tools at gmail dot com 2008-04-01 15:49
---
Created an attachment (id=15408)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15408&action=view)
A setup for combined gcc/binutils source tree
This is the setup to create a combined gcc/binutils source tree
--- Comment #29 from hjl dot tools at gmail dot com 2008-04-01 15:50
---
(In reply to comment #27)
>
> Gives me enough context to commit a patch that actually works.
>
> Paolo
>
Please get
http://gcc.gnu.org/bugzilla/attachment.cgi?id=15408
and create a combined gcc/binutils sourc
--- Comment #30 from bonzini at gnu dot org 2008-04-01 16:11 ---
Created an attachment (id=15409)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15409&action=view)
new patch
@Ralf: yes, I understood that (I just wanted to understand if the failure was
just that my way of setting en
--- Comment #4 from felix-gcc at fefe dot de 2008-04-01 16:09 ---
I'm not familiar enough with how gcc works to say whether warning about
precision loss that turns out important later on can be done at all.
But I think we should not reject an idea because it only handles 60% of the
case
--- Comment #31 from oblivian at users dot sourceforge dot net 2008-04-01
16:44 ---
(In reply to comment #30)
> Created an attachment (id=15409)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15409&action=view) [edit]
> new patch
>
> @Ralf: yes, I understood that (I just wanted to
--- Comment #6 from hjl dot tools at gmail dot com 2008-04-01 16:51 ---
Revision 133786 doesn't work for C++:
libtool: compile: /export/build/gnu/gcc/build-ia64-linux/./gcc/xgcc
-shared-libgcc -B/export/build/gnu/gcc/build-ia64-linux/./gcc -nostdinc++
-L/export/build/gnu/gcc/build-ia64
--- Comment #7 from hjl dot tools at gmail dot com 2008-04-01 16:52 ---
(In reply to comment #4)
> Created an attachment (id=15400)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15400&action=view) [edit]
> patch for cfun->emit rtl.emit changes
>
> I tested this patch with a C only
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||gcc-bugs at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-01 17:21 ---
Can you read http://gcc.gnu.org/bugs.html and provide the rest of the
information?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-04-01 17:36 ---
Can you provide the preprocessed source and also the exact version of GCC you
are using?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janis at gcc dot gnu dot org 2008-04-01 17:58 ---
For powerpc-linux this affects _Decimal128, 128-bit long double, and _Complex
double. I'm testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35713
--- Comment #7 from zippel at gcc dot gnu dot org 2008-04-01 17:53 ---
Actually for the PCH issue there is a fix:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01607.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25343
--- Comment #24 from joel at gcc dot gnu dot org 2008-04-01 18:02 ---
With Laurent's test program, I have traces of good (powerpc/psim) and bad
(qemu) runs. The traced include only entry and exit status info for the
following calls are:
_CPU_Context_switch
pthread_cond_broadcast
pthre
--- Comment #32 from oblivian at users dot sourceforge dot net 2008-04-01
18:55 ---
(In reply to comment #30)
> This patch should work. It creates a good collect-ld for me.
>
How about a simple change without the whole fast-install patch.
if test -x $scriptdir/../prev-$dir/$prog
--- Comment #8 from schwab at suse dot de 2008-04-01 18:57 ---
Ok, lets fix it for real.
--
schwab at suse dot de changed:
What|Removed |Added
Status|RESOLVED
--- Comment #33 from oblivian at users dot sourceforge dot net 2008-04-01
19:04 ---
(In reply to comment #32)
> (In reply to comment #30)
> > This patch should work. It creates a good collect-ld for me.
> >
>
> How about a simple change without the whole fast-install patch.
>
How abo
--- Comment #34 from oblivian at users dot sourceforge dot net 2008-04-01
19:04 ---
Sorry make that stage 3 intl gives me the above
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-04-01 19:18 ---
Can you cook up some code examples where you'd like to see a warning?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35592
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-01 19:20 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #7 from bkoz at gcc dot gnu dot org 2008-04-01 19:34 ---
Hey Jason, can we get this fixed on 4_3-branch? (Could probably get away with
just
gcc/cp/name-lookup.c fix, no?)
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33486
--- Comment #6 from felix-gcc at fefe dot de 2008-04-01 19:34 ---
Sure. For example:
char* c=malloc(lseek(somefd,0,SEEK_END);
on a platform where off_t is 64-bit, but where size_t is 32-bit. For example:
i686-linux with #define _FILE_OFFSET_BITS 64.
Now that I'm thinking about it,
--- Comment #25 from laurent at guerby dot net 2008-04-01 19:40 ---
The binder will generate a call to Set_Globals
pragma Import (C, Set_Globals, "__gnat_set_globals");
Set_Globals
(Main_Priority=> -1,
Time_Slice_Value => -1,
WC_
operator new has an implicit *sizeof(type), and during that operation there can
occur an integer overflow. Example:
int* foo() {
return new int[0x4000];
}
Compiled for a 32-bit target, this allocates 0 bytes. Most compilers do not
detect this either, but the Microsoft compiler instead gen
--- Comment #7 from derrick_chi at msn dot com 2008-04-01 20:32 ---
Hello
I've already attached the source code I'm using, and I'm not sure of the
version of GCC but I just recently downloaded cygwin so its got to be a fairly
up to date version. If there is a command I can enter to
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-04-01 20:34
---
Subject: Bug 35436
Author: reichelt
Date: Tue Apr 1 20:33:37 2008
New Revision: 133800
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133800
Log:
PR c/35436
* c-format.c (init_dynamic_gfc_
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-04-01 20:37
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Su
with Ada.Text_IO;
procedure A is
package Stuff is
type Base_1 is interface;
procedure P_1 (X : in Base_1) is abstract;
type Base_2 is interface;
procedure P_2 (X : in Base_2) is abstract;
type Middle is interface and Base_1 and Base_2;
type Concrete is n
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35791
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-01 20:46 ---
There is no overflow here really as sizeof is unsigned and unsigned types don't
overflow, they wrap.
*** This bug has been marked as a duplicate of 19351 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #13 from pinskia at gcc dot gnu dot org 2008-04-01 20:46
---
*** Bug 35790 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pault at gcc dot gnu dot org 2008-04-01 20:47 ---
I do not agree that this is a regression. Try
MODULE MODS
INTEGER, PARAMETER, DIMENSION(10) :: A = [(i, i = 1,10)]
INTEGER, PARAMETER, DIMENSION(10) :: B = ISHFTC(3, A, 5) !ICE
END MODUL
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-04-01 20:47
---
Also note unsigned types don't overflow, they wrap. So as far as I can tell,
C++ defines this as being returning too small of a size.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351
--- Comment #1 from laurent at guerby dot net 2008-04-01 20:49 ---
confirmed on trunk 133715
--
laurent at guerby dot net changed:
What|Removed |Added
Status|
If an incomplete_type_declaration includes the reserved word tagged,
then a full_type_declaration that completes it shall declare a tagged
type.
The error for T3 is detected, but not T1 or T2.
package pak1 is
type T1 is tagged;
type T2 is tagged;
type T3 is tagged;
protected type T1 i
RM 3.8(12):
If the discriminant is used to define the constraint of a component, ...
then its name shall appear alone as a direct_name (not as part of ...
an expanded name).
The error for x3 is detected, but not x1.
package pak1 is
type T1(n: natural) is null record;
type T2(n: natural) is
--- Comment #15 from felix-gcc at fefe dot de 2008-04-01 21:24 ---
I think we can all agree it does not matter what we call this problem.
Real world programs have security problems because of this.
-fstack-protector carries a much larger run-time cost and gcc still offers it,
and there i
-- RM 4.1.3(9.2/2):
-- The selector_name shall resolve to denote a view of a subprogram
-- declared immediately within the declarative region in which an
-- ancestor of the type T is declared.
package pak1 is
package pak2 is
type T1 is tagged private;
private
type T1 is tagged n
--- Comment #1 from ludovic at ludovic-brenta dot org 2008-04-01 21:26
---
gcc-4.3 -c -gnat05 pak1.ads
pak1.ads:11:21: no selector "f1" for private type "T1" defined at line 4
--
ludovic at ludovic-brenta dot org changed:
What|Removed |Added
-
--- Comment #16 from rguenth at gcc dot gnu dot org 2008-04-01 21:51
---
I agree. Patches welcome.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351
1 - 100 of 115 matches
Mail list logo