On RISC cpus with many registers, it is often helpful to keep constants (such
as addresses) in registers for later use, since loading a register with a
constant takes longer than moving data between registers, and since
register-constant operations are seldom available. On the AVR, however,
regist
As the avr is an 8-bit processor, it is important to handle data as 8-bit when
possible, even though the C standards force 8-bit data to be promoted to 16-bit
ints in many situations. Common cases are when doing logic operations on chars
- when legally valid (i.e., the results are the same as for
--
Summary: Missed optimisation on avr - no sibling call
optimisation
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at g
--- Comment #1 from david at westcontrol dot com 2008-01-15 08:34 ---
(Sorry - I committed the bug before entering the description!)
Sibling calls are not optimised on avrgcc, even with -foptimize-sibling-calls
enabled (such as for -Os):
extern void foo(void);
void bar(void) {
As noted in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34791 , it is important
on the avr to use 8-bit logic whenever possible. In some cases, the c++
compiler will produce worse code than the c compiler for exactly the same
source:
extern uint8_t data[64];
uint8_t bar2(uint8_t x, uint8_t y) {
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-01-15 09:47
---
Thanks.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITIN
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27177
--- Comment #23 from rguenth at gcc dot gnu dot org 2008-01-15 09:45
---
I don't see where there is a problem with widening conversions. The problem is
we re-use the (unsigned : 24) i; value for the comparison, which looks
reasonable, but this _narrowing_ conversion is not reflected b
After reading all other PRs about uninitialized variable warnings, I
believe this one is a different situtation.
PR 20968 -- is about inlining, which is not involved here
PR 21733 -- is about two concatenated blocks rather than nested ones
PR 31707 -- is about setjmp
PR 20644 -- is also about unre
--- Comment #8 from aldot at gcc dot gnu dot org 2008-01-15 10:10 ---
This was recently changed on trunk:
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01574.html
via
r127745 | drow | 2007-08-23 19:42:08 +0200 (Thu, 23 Aug 2007) | 4 lines
* configure.ac (leb128): Modify sed state
--- Comment #1 from j at uriah dot heep dot sax dot de 2008-01-15 10:10
---
Created an attachment (id=14942)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14942&action=view)
Testcase showing the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34793
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||diagnosti
Hello,
the build of gcc 4.2.2 fails on AIX 6.1 during stage3 / libstdc++.
environment:
IBM AIX 6.1 TL0 SP2
XC C/C++ 9.0
gcc 4.2.2 compiled on AIX 5.3
=> stage_current: stage3
gmake[4]: Entering directory
`/opt/freeware/src/packages/BUILD/gcc-build/powerpc-ibm-aix6.1.0.0/libstdc++-v3/libmath
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-15 10:49 ---
This problem is introduced by the default case that gets added to the switch
stmt in the IL. Coming from this case, areg is uninitialized.
The fix for PR14495 will likely fix this (by removing the default case agai
--- Comment #1 from pcarlini at suse dot de 2008-01-15 10:45 ---
Hi David, can you have a look at this issue? Thanks.
--
pcarlini at suse dot de changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-15 10:37 ---
Patches should be sent to [EMAIL PROTECTED]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34787
The inquire direct= specifier always returns YES regardless how the file is
created or actually opened.
The bug has been seen on gfortran versions
gcc version 4.1.0 20060304 (Red Hat 4.1.0-3) Target: x86_64-redhat-linux
gcc version 4.1.1 20061011 (Red Hat 4.1.1-30) Target: i386-redhat-linux
--- Comment #2 from tammer at tammer dot net 2008-01-15 11:28 ---
Hello,
currently I am working with Ralf Wildenhues (libtool, autconf, automake,
config) to get AIX 6.1 in. The libtool (branch-1.5 / HEAD) and config.guess now
recognizes AIX 6.1 as -> powerpc-ibm-aix6.1.0.0.
I have not y
--- Comment #3 from j at uriah dot heep dot sax dot de 2008-01-15 12:54
---
(In reply to comment #2)
> The fix for PR14495 will likely fix this (by removing the default case again).
Alas, no, it doesn't. I applied that patch (and the one it depends one
mentioned in the article), rebu
Compiling gives twice the error message:
Error: Element of assumed-shaped array passed to dummy argument 'y'
Other compilers give it only for "rdiff2"; thinking over it, there is no reason
to reject it for "rdiff" as the memory is contiguous which might not be the
case for dummy arguments (strip
In settings.h, the Settings class (containing only static variables) is
encapsulated in an anonymous namespace. This makes the linker think of a
distinct class for each compilation unit. As as result, settings changed in one
.cpp file won't affect code from another .cpp file, although they should h
--- Comment #1 from singler at gcc dot gnu dot org 2008-01-15 13:15 ---
First of all, we should get rid of these many static variables in the Settings
class, and replace them by usual member variables. Then, there should be one
static/global instance of this Settings class.
The question
--- Comment #24 from rguenth at gcc dot gnu dot org 2008-01-15 13:23
---
So the issue is that for
void foo(unsigned int) (i)
{
i.0;
:
i.0 = () i;
sv.f2 = i.0;
if ((unsigned int) i.0 != 0)
we neither emit code for the narrowing nor for the widening, but only
for the bitfield
--- Comment #4 from rguenther at suse dot de 2008-01-15 13:27 ---
Subject: Re: warning: 'areg' may be used uninitialized
in this function
On Tue, 15 Jan 2008, j at uriah dot heep dot sax dot de wrote:
> --- Comment #3 from j at uriah dot heep dot sax dot de 2008-01-15 12:54
> -
--- Comment #2 from singler at gcc dot gnu dot org 2008-01-15 13:20 ---
There are two general options to fix this bug:
1. Introduce a global variable, to be compiled into libstdc++.a and
libstdc++.so.
2. Do the "template trick", i. e. pseudo-parametrize Settings as
template class, to lea
--- Comment #6 from singler at gcc dot gnu dot org 2008-01-15 13:05 ---
No further objections.
--
singler at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-15 14:04 ---
>From the Fortran 2003 standard ("12.4.1.2 Actual arguments associated with
dummy data objects")
"If the actual argument is scalar, the corresponding dummy argument shall be
scalar unless the actual argument is of ty
--- Comment #25 from rguenth at gcc dot gnu dot org 2008-01-15 14:05
---
Unassigning. I like to have help from somebody knowing how to debug the
libjava failures. The only bitfields are defined in jvmti.h.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #31 from olga at gcc dot gnu dot org 2008-01-15 14:11 ---
I gave it another push. The following is a patch solving inconsistency of the
data structures in struct reorg, and releasing comparison with 0. Please try it
together with the Richard's patch. It should give extra XPAS
--- Comment #2 from debian-gcc at lists dot debian dot org 2008-01-15
14:54 ---
confirmed.
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32484
--- Comment #6 from rguenther at suse dot de 2008-01-15 14:54 ---
Subject: Re: warning: 'areg' may be used uninitialized
in this function
On Tue, 15 Jan 2008, j at uriah dot heep dot sax dot de wrote:
> --- Comment #5 from j at uriah dot heep dot sax dot de 2008-01-15 14:38
> -
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-15 14:44 ---
Reduced testcase:
int f(char *device)
{
return device == ((char *)0 + ~0UL);
}
for building the POINTER_PLUS_EXPR we convert the unsigned offset to
sizetype which causes the double-int (-1, 0) to sign-extend to (
--- Comment #5 from j at uriah dot heep dot sax dot de 2008-01-15 14:38
---
(In reply to comment #4)
> Oh, indeed - it also needs PR30317 fixed. (the attached patches therein
> probably no longer apply)
I applied the second of the attached patches there. It applies cleanly,
but stil
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-15 15:01 ---
I think the frontend should reject identifiers in declarations that touch
the __builtin_ namespace.
The regression status is dubious (it probably 'regressed' at the point
the builtin was introduced).
--
rguenth
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|enhancement |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33699
--- Comment #3 from aph at gcc dot gnu dot org 2008-01-15 15:13 ---
Fixed in trunk.
Tested:
zorro:~ $ ~/gcc/trunk/install/bin/gcj -shared -Wl,-Bsymbolic -fPIC
-findirect-dispatch -fjni -g0 -O0 -mtune=nocona -march=nocona -pipe -w
-save-temps -o libjunit.jar.so junit.jar
gcj: warning: -
--- Comment #31 from rguenth at gcc dot gnu dot org 2008-01-15 15:22
---
Created an attachment (id=14943)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14943&action=view)
other approach to supress the warnings
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
--- Comment #14 from burnus at gcc dot gnu dot org 2008-01-15 15:21 ---
Check that the renamed imported operator is not imported again, see PR 33541.
If I recall correctly, this part is missing for the patch in PR 33541
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298
In the example below gcc reports an assertion failure, when warnings are
switched on.
> gcc -c -gnatwa status.ads
fails, while
> gcc -c status.ads
is working.
The snapshot 4.3.0 20070921 is correctly warning 'no component clause given for
"C" declared at line 12' while later snapshots (e.g. 4.
--- Comment #30 from rguenth at gcc dot gnu dot org 2008-01-15 15:21
---
I suggest to tag the DECL with TREE_NO_WARNING if -fno-default-inline is set
and
check this.
On the trunk the functions are inlined anyway, because we inline small
functions by default (and the functions are pure
--- Comment #4 from aph at gcc dot gnu dot org 2008-01-15 15:32 ---
.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #5 from aph at gcc dot gnu dot org 2008-01-15 15:32 ---
*** This bug has been marked as a duplicate of 33639 ***
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from aph at gcc dot gnu dot org 2008-01-15 15:32 ---
*** Bug 32484 has been marked as a duplicate of this bug. ***
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #33 from rguenther at suse dot de 2008-01-15 15:54 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] -Winline
does not respect -fno-default-inline
On Tue, 15 Jan 2008, hubicka at gcc dot gnu dot org wrote:
> --- Comment #32 from hubicka at gcc dot gnu dot org 2008-01-15
--- Comment #32 from hubicka at gcc dot gnu dot org 2008-01-15 15:47
---
I am bit confused by logic of code here. Middle end now ingore DECL_INLINE
consistently, it is still arround since it affect some instantiation decisions
in C++ FE. Does fno-default-inline work? I think only way
--- Comment #9 from dgregor at gcc dot gnu dot org 2008-01-15 16:07 ---
Fixed in mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #6 from dgregor at gcc dot gnu dot org 2008-01-15 16:09 ---
Fixed on mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #8 from dgregor at gcc dot gnu dot org 2008-01-15 16:07 ---
Subject: Bug 34052
Author: dgregor
Date: Tue Jan 15 16:06:48 2008
New Revision: 131543
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131543
Log:
2008-01-15 Douglas Gregor <[EMAIL PROTECTED]>
PR c+
--- Comment #34 from hubicka at ucw dot cz 2008-01-15 15:59 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] -Winline does not respect
-fno-default-inline
> Yes, this is what I understand. I think we need a new flag specifying
> if in the source the 'inline' keyword was used and solely u
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--- Comment #7 from dgregor at gcc dot gnu dot org 2008-01-15 16:10 ---
Subject: Bug 33964
Author: dgregor
Date: Tue Jan 15 16:09:28 2008
New Revision: 131544
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131544
Log:
2008-01-15 Douglas Gregor <[EMAIL PROTECTED]>
PR c+
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-15 16:40 ---
This is an ice-on-valid, so it should probably be a P2.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #35 from manu at gcc dot gnu dot org 2008-01-15 16:44 ---
(In reply to comment #33)
> Yes, this is what I understand. I think we need a new flag specifying
> if in the source the 'inline' keyword was used and solely use that for
> inline warning purposes. (That is, I would
--- Comment #3 from dgregor at gcc dot gnu dot org 2008-01-15 16:59 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00650.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34055
--- Comment #3 from dgregor at gcc dot gnu dot org 2008-01-15 16:59 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00650.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34102
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-15 16:59 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00650.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
--- Comment #16 from gustavodn at gmail dot com 2008-01-15 17:20 ---
"Glibc being Linux being the world" is not really relevant, IMHO. What is
relevant is printf() (or any function) is, fundamentally, implemented by
library, not by compiler, so compiler should not prevent library from de
--- Comment #6 from alexandre dot nunes at gmail dot com 2008-01-15 17:40
---
This seems to work as of gcc 4.2.2 (vanilla), using the original commands to
reproduce. Anyone denies/confirms this?
--
alexandre dot nunes at gmail dot com changed:
What|Removed
$ cat pqp.c
typedef union {
struct
{
unsigned char d;
};
unsigned char a, b;
} test_type;
extern test_type whatever;
$ gcc -c pqp.c
$ gcc --combine -c pqp.c pqp.c
pqp.c:9: error: conflicting types for whatever
pqp.c:9: error: previous declaration of whatever was here
T
--- Comment #7 from alexandre dot nunes at gmail dot com 2008-01-15 17:55
---
(In reply to comment #6)
> This seems to work as of gcc 4.2.2 (vanilla), using the original commands to
> reproduce. Anyone denies/confirms this?
>
... and please see bug 34800 .
--
http://gcc.gnu.org/b
--- Comment #5 from alexandre dot nunes at gmail dot com 2008-01-15 17:58
---
(In reply to comment #4)
> won't fix in GCC-4.0.x. Adjusting milestone.
>
For anyone interested, I think this is fixed for at least gcc 4.2.2; I couldn't
reproduce it.
--
alexandre dot nunes at gmail do
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-15 18:00 ---
Subject: Bug 34314
Author: dgregor
Date: Tue Jan 15 17:59:44 2008
New Revision: 131546
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131546
Log:
2008-01-15 Douglas Gregor <[EMAIL PROTECTED]>
PR c+
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-15 18:00 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00656.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34796
--- Comment #16 from alexandre dot nunes at gmail dot com 2008-01-15 18:03
---
vanilla gcc 4.2.2 seems to compile this testcase ok (all five symbols are
emmited and externally visible, no warnings)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28744
--- Comment #6 from dgregor at gcc dot gnu dot org 2008-01-15 18:05 ---
Fixed on mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #8 from dgregor at gcc dot gnu dot org 2008-01-15 18:08 ---
Fixed in mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-15 18:08 ---
Subject: Bug 34055
Author: dgregor
Date: Tue Jan 15 18:08:00 2008
New Revision: 131547
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131547
Log:
2008-01-15 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #9 from dgregor at gcc dot gnu dot org 2008-01-15 18:08 ---
Subject: Bug 34051
Author: dgregor
Date: Tue Jan 15 18:08:00 2008
New Revision: 131547
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131547
Log:
2008-01-15 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-15 18:08 ---
Subject: Bug 34103
Author: dgregor
Date: Tue Jan 15 18:08:00 2008
New Revision: 131547
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131547
Log:
2008-01-15 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-15 18:08 ---
Subject: Bug 34102
Author: dgregor
Date: Tue Jan 15 18:08:00 2008
New Revision: 131547
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131547
Log:
2008-01-15 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-15 18:09 ---
Fixed in mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-15 18:09 ---
Fixed in mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #6 from dgregor at gcc dot gnu dot org 2008-01-15 18:09 ---
Fixed in mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #9 from alexandre dot nunes at gmail dot com 2008-01-15 18:12
---
(In reply to comment #8)
> Fixed on the trunk.
>
For anyone else wondering, this is still reproductible on vanilla gcc 4.2.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28755
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-15 18:50 ---
Fixed in mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-15 18:50 ---
Subject: Bug 34751
Author: dgregor
Date: Tue Jan 15 18:49:47 2008
New Revision: 131548
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131548
Log:
2008-01-15 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #17 from manu at gcc dot gnu dot org 2008-01-15 18:51 ---
This will be fixed yesterday if printf("%s\n", s) were equivalent to puts(s) in
glibc.
Also there is a way to disable the optimization: "-fno-builtin-printf".
People that don't rely on undefined behaviour don't deser
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-15 19:12 ---
| correct output (produced by g77)
| default open drct=NO opened= T access=SEQUENTIAL
| Sequent open drct=NO opened= T access=SEQUENTIAL
| direct open drct=YES opened= T access=DIRECT
How do you know which
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-01-15 19:19 ---
(In reply to comment #5)
> This is an ice-on-valid, so it should probably be a P2.
Well it is both depending on -std= settings.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-15 19:30 ---
Confirmed. Your bugreport was there even before mine, but since my contains a
link to the patch I mark yours as duplicate.
Thanks for finding the bug.
> This diagnostic is (a) misleading - b is NOT an assumed-shape
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-15 19:30 ---
*** Bug 34788 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #32 from dominiq at lps dot ens dot fr 2008-01-15 20:03 ---
With the patches in comments #11 and 31, the error disappears in 32 bit mode on
Intel Darwin9 (as with #11 alone), now appears in 64 bit mode with the other
errors already reported:
FAIL: gcc.dg/struct/wo_prof_globa
--- Comment #14 from tbptbp at gmail dot com 2008-01-15 20:07 ---
I keep bumping into this issue and i'd really appreciate a clue about how to
workaround for the time being.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34774
This should have already been reported, but I cannot find any trace of it.
gcc.dg/Warray-bounds.c fails on all the platforms I have looked at:
FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 59)
FAIL: gcc.dg/Warray-bounds.c (test for warnings, line 65)
FAIL: gcc.dg/Warray-bounds.c (test
--- Comment #18 from manu at gcc dot gnu dot org 2008-01-15 20:48 ---
There is an explanation for the optimisation, a potential fix [*] and there is
a workaround.
[*] http://sourceware.org/bugzilla/show_bug.cgi?id=5618
--
manu at gcc dot gnu dot org changed:
What|Rem
--- Comment #1 from dick dot hendrickson at gmail dot com 2008-01-15 20:49
---
Another example in executable code
MODULE s_TESTS
IMPLICIT CHARACTER (P)
CONTAINS
subroutine simple (u,j1)
optional :: j1
if (present (j1)) stop
end subroutine
--- Comment #6 from dgregor at gcc dot gnu dot org 2008-01-15 20:57 ---
Subject: Bug 34399
Author: dgregor
Date: Tue Jan 15 20:56:55 2008
New Revision: 131552
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131552
Log:
2008-01-15 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #7 from dgregor at gcc dot gnu dot org 2008-01-15 20:59 ---
Fixed in mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #19 from gustavodn at gmail dot com 2008-01-15 21:08 ---
(In reply to comment #17)
> This will be fixed yesterday if printf("%s\n", s) were equivalent to puts(s)
> in
> glibc.
[+] The standard requires them to be equivalent? Per standard, they can't be
equivalent if both ar
gcc-3.x gives this information but gcc-4.2 does not.
In the shell snippit below, the unknown symbol name should be
embedded in the gcc-4.2 error lines as it is done in gcc-3.4.
$ gcc-3.4 foo.f
undeclared_variable(index)=0.0
^
Invalid declaration of ... 'undeclare
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-01-15 21:22 ---
Subject: Bug 34671
Author: tkoenig
Date: Tue Jan 15 21:22:07 2008
New Revision: 131553
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131553
Log:
2008-01-15 Thomas Koenig <[EMAIL PROTECTED]>
PR li
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-01-15 21:24 ---
Fixed on trunk.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
No simpler C code is (yet) known to hit this. On request will
describe actual package where similar code occurs.
In the attached preprocessed code, incorrect arg 3, `%rdx', is passed
to `handle_out_external'. Code expects this value, `extlen', to be
the same as value that is returned from `__bui
--- Comment #1 from gin at mo dot msk dot ru 2008-01-15 21:41 ---
Created an attachment (id=14944)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14944&action=view)
preprocessed code in question
Instead of `extptr', uninitialized value is passed to
`handle_out_external'.
--
ht
I am currently having fun porting code to the NEC SX-6 vector processor.
The native compiler on that platform (as well as NEC's cross compiler)
does not support INTEGER*1.
It would be useful to have a flag to mimic this behavior by disabling
the above mentioned types for declarations, along with t
1 - 100 of 119 matches
Mail list logo
