Somewhere in the libgcc build machinery, there is mechanism to override
the default LIBGCC2_UNITS_PER_WORD setting when compilng a function, so you
could in principle provide e.g. _divsi3 as well as _divdi3. It there a way
of making use of this facility in a more elegant way than putting the
On Wed, Jan 03, 2007 at 11:28:29PM -0500, Daniel Jacobowitz wrote:
I've just committed the approved top level libgcc patches, which
create a top level libgcc directory.
I updated to revision 120997 for my Intel x86 16-bit port, to find:
Checking multilib configuration for libgcc...
Rask Ingemann Lambertsen [EMAIL PROTECTED] writes:
Checking multilib configuration for libgcc...
Configuring in ia16-elf/libgcc
[snip]
checking whether decimal floating point is supported... no
*** Configuration ia16-unknown-elf not supported
make[1]: *** [configure-target-libgcc] Fejl 1
Nevertheless, I (and others seem to agree) would like to name that
particular warning, so it can be enabled/disabled. Also, there is a
similar warning for unsigned = 0 and unsigned 0 in -Wextra. There
are bug reports about the inconsistency (http://gcc.gnu.org/PR23587).
So,
On Sun, 2007-01-21 at 01:49 -0500, Richard Stallman wrote:
It would be nice to have such a construct in GNU C, something that
could be used in a macro expansion, and would turn off _all_ warnings
for the code within the construct.
http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
But
integer(1) :: i(1:-1)
i = 5
end
gives:
hh1.f90: In function 'MAIN__':
hh1.f90:1: error: size of variable 'i' is too large
Expected:
No error as i is an array with no elements
--
Summary: zero-sized array wrongly rejected: integer :: i(1:-1)
Product: gcc
--- Comment #7 from patchapp at dberlin dot org 2007-01-20 09:25 ---
Subject: Bug number PR c++/24745
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01657.html
--
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-20 09:37 ---
Vaguely related is:
trans-intrinsic.c's gfc_conv_intrinsic_minmaxval, which contains currently:
/* Most negative(-HUGE) for maxval, most positive (-HUGE) for minval. */
if (op == GT_EXPR)
tmp = fold_build1
--- Comment #4 from mtrudel at gmx dot ch 2007-01-20 10:13 ---
Fixed in 4.3 mainline. The gcj specific serialization was replaced with the
classpath serialization (StackWalker or something). Thanks guys... minGW gets
better and better :-)
--
mtrudel at gmx dot ch changed:
--- Comment #11 from manu at gcc dot gnu dot org 2007-01-20 10:15 ---
Paolo or Gerald, could you try to collect a list of the warnings produced by
-Wconversion? I am only interested in the warning message, not where it was
instantiated, so please, filter it through fgrep warning: .
You
--- Comment #4 from mtrudel at gmx dot ch 2007-01-20 10:16 ---
I thought this was already closed?
Well, Mohan fixed it. It is in the 4.2 branch and in the 4.3 mainline
(trunk)...
Thank you Mohan!
--
mtrudel at gmx dot ch changed:
What|Removed
gcj -s -O2 --main=HelloWorld HelloWorld.java World.class -o foobar.exe
Works with gcj 4.2 but fails with gcj 4.3:
C:\DOKUME~1\Marco\LOKALE~1\Temp/ccSkeaaa.o:ccoFcaaa.jar:(.text+0x66):
undefined reference to `java::lang::String* World::getWorld()'
collect2: ld returned 1 exit status
also:
gcj -s
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-01-20 10:37 ---
How did you configure the hpux compiler? I was told Linux/x86 works for you.
Can you verify that gthr-aix.h selected gthr-posix.h for compiling libgcc2 and
libstdc++-v3?
--
rguenth at gcc dot gnu dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-01-20 11:12 ---
Subject: Bug 30223
Author: rguenth
Date: Sat Jan 20 11:12:35 2007
New Revision: 120998
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120998
Log:
2007-01-20 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-01-20 11:19 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal
--- Comment #12 from pcarlini at suse dot de 2007-01-20 11:58 ---
(In reply to comment #11)
Paolo or Gerald, could you try to collect a list of the warnings produced by
-Wconversion?
Hi. I will double check ASAP, but definitely most of them are about signed -
unsigned, exactly like
--- Comment #13 from manu at gcc dot gnu dot org 2007-01-20 12:32 ---
I am also interested in seeing if there are any (large signed) - (small
unsigned) and bring them to the discussion, where all positive values fit in
the unsigned (so no warning) or there is a sign conversion.
About
--- Comment #1 from manu at gcc dot gnu dot org 2007-01-20 12:43 ---
Note: we emit a duplicated warning because this patch is not committed yet:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00799.html
(Not a single comment yet).
With the patch the output is just:
int g() T h() int
--- Comment #2 from burnus at gcc dot gnu dot org 2007-01-20 12:46 ---
Non-library part of this fix.
This fixes the reported bug, but libgfortran/m4/* should be fixed as well.
m4/iparm.m4 contains:
define(atype_max, atype_name`_HUGE')dnl
define(atype_min, `-'atype_max)dnl
One would
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-01-20 13:01
---
Subject: Bug 30446
Author: fxcoudert
Date: Sat Jan 20 13:01:08 2007
New Revision: 121000
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121000
Log:
PR fortran/30446
* options.c
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||patch
Known to fail||4.2.0 4.1.2
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-01-20 13:14
---
Aldy, can you comment on this bug? It's still present as of today, and it
prevents mainline from building a fair number of real-life Fortran codes.
--
fxcoudert at gcc dot gnu dot org changed:
--- Comment #6 from dominiq at lps dot ens dot fr 2007-01-20 13:27 ---
On Mac OSX 10.3.9, after the same failure I have applied the patch of comment
#1. Now the build fails
with:
/sw/src/fink.build/gcc4-4.3.0-20070120/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc4-4.3.0-20070120
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-20 13:45 ---
I teached VRP to look for this idiom and during a C only bootstrap on i686 this
triggers 28921 times.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Tried a simple program that left shifts the long long 33 times, the result
displayed is wrong and not what is expected of shifting 1 33
Sample code follows,
int main()
{
unsigned long long var=1;
long long m =1;
printf( %lu , (var 33));
printf(\n %lu , (m 33));
return 0;
}
Using
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-01-20 15:55
---
Subject: Bug 30446
Author: fxcoudert
Date: Sat Jan 20 15:55:41 2007
New Revision: 121001
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121001
Log:
PR fortran/30446
* options.c
--- Comment #33 from fxcoudert at gcc dot gnu dot org 2007-01-20 15:55
---
Subject: Bug 26893
Author: fxcoudert
Date: Sat Jan 20 15:55:41 2007
New Revision: 121001
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121001
Log:
PR fortran/30446
* options.c
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-01-20 15:57
---
Fixed on mainline and 4.2.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #34 from fxcoudert at gcc dot gnu dot org 2007-01-20 15:57
---
Fixed on mainline and 4.2.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from schwab at suse dot de 2007-01-20 16:07 ---
macro.c: In function #8216;main#8217;:
macro.c:18: warning: format #8216;%lu#8217; expects type #8216;long
unsigned int#8217;, but
argument 2 has type #8216;long long unsigned int#8217;
macro.c:19: warning: format
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-20 16:30 ---
This is a duplicate of PR 23587.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29694
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-20 16:52 ---
Not sure if the summary is 100% correct but it is far better than the previous
one.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-01-20 17:19
---
Looks fun! The following code even gets gfortran into an infinite loop:
integer :: i(2:0), j(1:0)
integer, parameter :: k(2:0) = 0, l(1:0) = 0
i = k
j = l
end
--
fxcoudert at gcc dot gnu dot org changed:
--- Comment #11 from manu at gcc dot gnu dot org 2007-01-20 18:06 ---
Any news on this? Is this an important warning?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from pcarlini at suse dot de 2007-01-20 19:13 ---
(In reply to comment #13)
I am also interested in seeing if there are any (large signed) - (small
unsigned) and bring them to the discussion, where all positive values fit in
the unsigned (so no warning) or there is a
gcc version 4.3.0 20070120 (experimental)
This is svn r120997.
The attached file has three differently-coded but equivalent sets of array
accesses, none of which are compiled to the smallest possible form at -Os.
case '':
htmled[i2
After using the patch of PR30511, gcc-4.3-20070119 failed to build
on OSX 10.3.9 with:
...
/sw/src/fink.build/gcc4-4.3.0-20070120/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc4-4.3.0-20070120/darwin_objdir/./gcc/
-B/sw/lib/gcc4/powerpc-apple-darwin7/bin/
-B/sw/lib/gcc4/powerpc-apple-darwin7
--- Comment #1 from dominiq at lps dot ens dot fr 2007-01-20 20:42 ---
Created an attachment (id=12924)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12924action=view)
preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30518
gcc/../libdecnumber -I../../libdecnumber -o crtendS.o -MT crtendS.o -MD -MP -MF
crtendS.dep -fPIC \
-c ../../../gcc/libgcc/../gcc/crtstuff.c -DCRT_END -DCRTSTUFFS_O
# If the gcc directory specifies which extra parts to
# build for this target, and the libgcc configuration also
#
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootstrap |target
Keywords||build
--- Comment #2 from fang at csl dot cornell dot edu 2007-01-20 22:00
---
In sys/resource.h (Darwin), near the beginning, you'll see some ifndef
business for struct timeval (the type of ru_utime and ru_stime). It looks to
be protected by the _TIMEVAL macro. Somehow that is evaluating
--- Comment #3 from fang at csl dot cornell dot edu 2007-01-20 22:05
---
Subject: Re: failed to build libgfortran in gcc-4.3-20070119
on OSX 10.3.9
--- Comment #2 from fang at csl dot cornell dot edu 2007-01-20 22:00
---
In sys/resource.h (Darwin), near the beginning,
From
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/6ec0a526ea59aa94/
gfortran accepts in the three test cases in 1., which violate C1232 (R1221)
and C1233 (R1221).
Fourth test case (should pass as dummy is pointer array, passes with gfortran)
subroutine s10()
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
--- Comment #4 from dominiq at lps dot ens dot fr 2007-01-20 22:52 ---
Subject: Re: failed to build libgfortran in gcc-4.3-20070119 on OSX 10.3.9
Thanks for the answers. I am not sure to fully understand them.
Am I correct if I summarize them by saying that I should
add a line
--- Comment #5 from fang at csl dot cornell dot edu 2007-01-20 23:11
---
Subject: Re: failed to build libgfortran in gcc-4.3-20070119
on OSX 10.3.9
--- Comment #4 from dominiq at lps dot ens dot fr 2007-01-20 22:52
---
Subject: Re: failed to build libgfortran in
--- Comment #1 from brooks at gcc dot gnu dot org 2007-01-21 00:23 ---
I would suggest that your comment about No check_used needed should reference
11.2.1 of the F2003 standard. The relevant language is towards the end (p252,
lines 30-34 of the page): The local identifier of an entity
Suppose that we have a function f that can be written in 2 ways with identical
result:
unsigned int f(unsigned int i, unsigned int n) {++i; if (i == n) ++i; return
i;}
unsigned int f(unsigned int i, unsigned int n) {++i; i += i == n; return i;}
g++ -O3 produces different code for the 2 versions:
(This bug description assumes that the patch to PR30520 is already applied.)
gfortran currently permits the following redundant VOLATILE attributes:
module A
real :: vol
end module A
module B
use A
volatile :: vol
volatile :: vol ! WRONG, but accepted
end module B
gfortran wrongly
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28531
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29151
--- Comment #2 from patchapp at dberlin dot org 2007-01-21 01:55 ---
Subject: Bug number PR30520
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01703.html
--
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-21 03:08 ---
I have a patch to document '#' and '@'.
I'll submit it shortly.
Currently gcc.c and invoke.texi are mostly kept in sync.
However I haven't audited to make sure they are fully in sync.
Adding support for \f is
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-21 03:09 ---
I am testing a patch for this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from levon at movementarian dot org 2007-01-21 03:15
---
It's been a cause of bugs time and time again, so yes, it's useful and
important.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7543
--- Comment #12 from tromey at gcc dot gnu dot org 2007-01-21 03:23 ---
One odd thing here is that if -Werror is given, then an inaccessible
directory will cause a compilation failure.
I would prefer we not check this patch in. I don't think there is
any obviously correct behavior on
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-01-21 04:35 ---
Tom, I tried your patch and now I get the following error. On line 14 in
AnnotationInvocationHandler.h, there is namespace sun and sun is defined to
1 on solaris. When I recompile with -ansi (which eliminates sun
--- Comment #1 from bangerth at dealii dot org 2007-01-21 05:16 ---
I only have the C99 standard, and there I read in 6.3.1.1 p2 that only
those variables are promoted to int that are of smaller size.
Similarly, in 6.3.1.8, integer promotion rules are specified, and they
specify that
--- Comment #3 from bangerth at dealii dot org 2007-01-21 05:23 ---
Here's an even simpler testcase that shows the same problem (even if the
error message is different):
-
struct a
{
int g(void);
};
struct b : a { };
void test()
{
static_castint (b::*)() const (b::g);
--- Comment #3 from bangerth at dealii dot org 2007-01-21 05:23 ---
*** Bug 30281 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2007-01-21 05:29 ---
No, that's not the case. We can print the types:
-
#include stdio.h
#include iostream
#include typeinfo
struct S
{
unsigned int long long a:33;
};
int main ()
{
struct S x = { -1 };
typeof(+x.a) z =
--- Comment #3 from bangerth at dealii dot org 2007-01-21 05:32 ---
In any case, I consider this a bug in gcc. The problem doesn't happen with
gcc 3.3 or 3.4 or 4.0, so it's a regression.
That said, there's a second problem: before 4.1.x, we warned:
g/x
--- Comment #2 from bangerth at dealii dot org 2007-01-21 05:33 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- Comment #1 from bangerth at dealii dot org 2007-01-21 05:34 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
This is the command-line:
gcc -c -O2 -Wall -I../modes aesxam.c
This is the offending assembly:
read_tsc:
...
#APP
cpuid; read_tsc
#NO_APP
...
The error is:
Error: invalid character '_' in mnemonic
GCC:
Configured with: /var/tmp/portage/gcc-4.1.1-r1/work/gcc-4.1.1/configure
--- Comment #1 from akihana at gmail dot com 2007-01-21 06:41 ---
Created an attachment (id=12925)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12925action=view)
Preprocessor output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30523
--- Comment #2 from akihana at gmail dot com 2007-01-21 06:48 ---
This is not a gcc bug.
--
akihana at gmail dot com changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-01-21 06:51 ---
Subject: Bug 30479
Author: pinskia
Date: Sun Jan 21 06:51:07 2007
New Revision: 121024
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121024
Log:
2007-01-20 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #32 from pinskia at gcc dot gnu dot org 2007-01-21 07:00
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
69 matches
Mail list logo
