-fdefault-integer-8 has some "interesting" interactions with
the library, especially on big-endian systems.
Look at the following program:
$ cat maxloc-mask.f90
program main
real, dimension(2) :: a
call random_number(a)
print *,maxloc(a,mask=.true.)
end program main
$ gfortran -fdump-tree-
--- Comment #1 from rask at sygehus dot dk 2007-07-15 14:29 ---
I get something similiar with my 16-bit x86 port compiling libgcc:
/home/rask/cvsbuild/gcc/./gcc/xgcc -B/home/rask/cvsbuild/gcc/./gcc/ -nostdinc
-B/home/rask/cvsbuild/gcc/ia16-elf/newlib/ -isystem
/home/rask/cvsbuild/gcc/ia
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-07-15 15:43
---
> I get something similiar with my 16-bit x86 port compiling libgcc:
Same on SPARC/Solaris:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg02135.html
> This patch seems to fix it:
>
> Index: gcc/df-problems.c
>
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-07-15 16:26
---
Subject: Bug 32611
Author: jvdelisle
Date: Sun Jul 15 16:26:22 2007
New Revision: 126654
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126654
Log:
2007-07-15 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-07-15 16:29
---
Subject: Bug 32611
Author: jvdelisle
Date: Sun Jul 15 16:29:19 2007
New Revision: 126655
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126655
Log:
2007-07-15 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-07-15 16:35
---
Subject: Bug 32611
Author: jvdelisle
Date: Sun Jul 15 16:35:07 2007
New Revision: 126656
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126656
Log:
2007-07-15 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-07-15 16:36
---
Fixed on trunk, closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-07-15 16:50
---
Fixed on trunk, no backport.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from danglin at gcc dot gnu dot org 2007-07-15 17:08 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #5 from danglin at gcc dot gnu dot org 2007-07-15 17:19 ---
Subject: Bug 32769
Author: danglin
Date: Sun Jul 15 17:19:13 2007
New Revision: 126657
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126657
Log:
PR middle-end/32398
PR middle-end/32769
--- Comment #20 from danglin at gcc dot gnu dot org 2007-07-15 17:19
---
Subject: Bug 32398
Author: danglin
Date: Sun Jul 15 17:19:13 2007
New Revision: 126657
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126657
Log:
PR middle-end/32398
PR middle-end/32769
--- Comment #6 from danglin at gcc dot gnu dot org 2007-07-15 17:21 ---
Fixed by change.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #21 from danglin at gcc dot gnu dot org 2007-07-15 17:23
---
Fixed by change.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #3 from dorit at gcc dot gnu dot org 2007-07-15 18:31 ---
> With loop distribution we could vectorize these loops using peeling to handle
> misaligned stores (multiple stores make peeling for alignment insufficient
> here).
wonder what the loop-distribution pass in the graph
--- Comment #4 from tprince at computer dot org 2007-07-15 18:43 ---
The arrays in this example all have compatible alignment. This is one of the
advantages many compilers see in the use of the "old-fashioned" block COMMON.
In the usual case lft==1 all arrays in COMMON are aligned, with
--- Comment #5 from dorit at gcc dot gnu dot org 2007-07-15 19:02 ---
(In reply to comment #4)
> The arrays in this example all have compatible alignment. This is one of the
> advantages many compilers see in the use of the "old-fashioned" block COMMON.
> In the usual case lft==1 all ar
--- Comment #12 from mark at codesourcery dot com 2007-07-15 19:27 ---
Subject: Re: "-Xcompiler" is inserted after "-Xlinker"
when building libstdc++
pcarlini at suse dot de wrote:
> --- Comment #11 from pcarlini at suse dot de 2007-07-14 23:51 ---
> I advice against committi
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|--- |4.2.2
http://gc
make[2]: Entering directory
`/home/calves/mydownloads/mjpegtools-1.9.0rc2/y4mdenoise'
if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/usr/include -I../utils
-DNDEBUG -finline-functions -fno-PIC -march=k8 -mcpu=k8 -g -O2 -pthread -MT
newdenoise.o -MD -MP -MF ".deps/newdenoise.Tpo" -c -o newdenoise
Hi guys,
I was trying to compile mjpegtools-1.9.0rc2
(http://sourceforge.net/projects/mjpeg/), then when making the usual:
./configure
make
I got the error below, I don't know if it's a real gcc bug or just
a code bug! Anyway, someone could help me pointing me out what's
could be wrong?
C
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-15 20:43 ---
Can you attach the preprocessed source which can be found via using the
-save-temps flag?
You can find more information about the process at http://gcc.gnu.org/bugs.html
which mentions what exact information we need
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-15 20:46 ---
Can you stop reporting bugs against RedHat's 4.1.1 to this bug database?
If you are going to report them, please report them against 4.3.0 after trying
that version.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.0 |4.2.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-15 20:50 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32723
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32713
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-15 20:52 ---
Can you attach the preprocessed source as requested by
http://gcc.gnu.org/bugs.html ?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-07-15 20:53 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||mmitchel at gcc dot gnu dot
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-15 21:01 ---
This seems related to:
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01379.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-15 21:03 ---
If ecj is hanging this might not be a GCJ bug but an ecj one.
Can you attach picture.java?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32758
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-15 21:05 ---
What is happening is that for the switch statement, we don't know that the
value can't be just 0 or 1 at the point where we warn. We should be able to
lower this switch statement into an if statement and get better
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|target |middle-end
Target Milestone|--- |4.3.0
ht
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-15 21:08 ---
PS Where is the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-15 21:09 ---
This is more likely a target issue of not including these functions in the
shared version of libgcc.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-15 21:10 ---
Can you attach the preprocessed source as requested by
http://gcc.gnu.org/bugs.html ?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-15 21:14 ---
Fixed in 4.2.0 and above.
*** This bug has been marked as a duplicate of 27115 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-07-15 21:14 ---
*** Bug 32767 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32731
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32752
--- Comment #4 from bisqwit at iki dot fi 2007-07-15 21:17 ---
Also is reported that on some 32-bit platforms, instead of causing an ICE, it
causes a rampant memory eating phenomenon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32767
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-07-15 21:24
---
Paul, can you confirm that it is impossible to build an arm-elf cross-compiler
with GCC 4.2.1? AFAICT, nothing has changed in cirrus.md in a long time, and
cirrus.md is included in all ARM configurations, so I wou
--- Comment #9 from jb at gcc dot gnu dot org 2007-07-15 21:33 ---
Subject: Bug 32748
Author: jb
Date: Sun Jul 15 21:33:32 2007
New Revision: 126662
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126662
Log:
2007-07-16 Janne Blomqvist <[EMAIL PROTECTED]>
PR fortran/32
--- Comment #10 from jb at gcc dot gnu dot org 2007-07-15 21:35 ---
With the 126662 commit, this should now be fixed, closing.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
---
In from glibc, there are
/* Re-allocate the previously allocated block
in PTR, making the new block SIZE bytes long. */
extern void *realloc (void *__ptr, size_t __size)
__THROW __attribute_malloc__ __attribute_warn_unused_result__;
However, when a function is marked as mallloc-like, gc
--- Comment #5 from hjl at lucon dot org 2007-07-15 22:49 ---
Created an attachment (id=13916)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13916&action=view)
_moddi3 source
# ./xgcc -B./ -O -g _moddi3.i -S
/net/gnu-13/export/gnu/src/gcc/gcc/libgcc/../gcc/libgcc2.c: In function
--- Comment #1 from bkorb at gnu dot org 2007-07-15 22:53 ---
I'd take ownership, but I cannot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32771
--- Comment #3 from rask at sygehus dot dk 2007-07-15 23:39 ---
There are test results for GCC 4.2.1 20070706 on arm-elf here:
http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00334.html>.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32753
I got the following compile error when trying to compile Linux kernel
2.6.22-rc6-mm1 with a recent gcc SVN snapshot:
$ /usr/local/DIR/gcc-svn20070715/bin/gcc -Wp,-MD,mm/.page_alloc.o.d -nostdinc
-isystem /usr/local/DIR/gcc-svn20070715/lib/gcc/i686-pc-linux-gnu/4.3.0/include
-D__KERNEL__ -Iinclude
--- Comment #1 from bunk at stusta dot de 2007-07-15 23:56 ---
Created an attachment (id=13917)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13917&action=view)
complete error messages
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32772
--- Comment #2 from bunk at stusta dot de 2007-07-15 23:59 ---
Created an attachment (id=13918)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13918&action=view)
preprocessed code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32772
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |tree-optimization
Keywords||ice
--- Comment #4 from pbrook at gcc dot gnu dot org 2007-07-16 01:04 ---
Builds fine for me.
The bogus constraint is in a pattern that is never used - the predicate is
"TARGET_ARM && TARGET_HARD_FLOAT && TARGET_MAVERICK && 0 [...]"
gen* are clever enough to eliminate it before it causes
--- Comment #5 from pbrook at gcc dot gnu dot org 2007-07-16 01:28 ---
In further investigation building with a prehistoric (<3.0.1) host compiler may
also cause the same failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32753
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-07-16 02:08
---
Paul --
Thanks for investigating.
Since this should occur only for a minority of people, this is not a
showstopper. However, would you please remove the disabled pattern? It's not
doing anything useful, and we
--- Comment #7 from mmitchel at gcc dot gnu dot org 2007-07-16 02:25
---
Because this is a Java issue, I'm not too concerned about this -- but because
it breaks the build, I'm more concerned than I would be if it was "just" a bug
in using Java. So, I've marked this P2.
--
mmitchel
With -m4 -O -fprofile-use, sh-elf compiler fails for
void foo (int *p)
{
if (p)
*p = 0;
}
with
internal compiler error: in create_pre_exit, at mode-switching.c:223
It starts to fail after the patch
r126576 | rakdver | 2007-07-12 19:24:19 +0900 (Thu, 12 Jul 2007) | 5 lines
PR r
60 matches
Mail list logo
