--- Comment #6 from bonzini at gnu dot org 2010-02-16 08:15 ---
Subject: Bug 41917
Author: bonzini
Date: Tue Feb 16 08:15:37 2010
New Revision: 156795
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156795
Log:
PR rtl-optimization/41917
* rtlanal.c (num_sign_bit_copies1) : If si
--- Comment #7 from bonzini at gnu dot org 2010-02-16 08:16 ---
Committed the patch to 4.3 too
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|N
--- Comment #4 from burnus at gcc dot gnu dot org 2010-02-16 08:35 ---
Subject: Bug 43040
Author: burnus
Date: Tue Feb 16 08:35:05 2010
New Revision: 156796
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156796
Log:
2010-02-16 Tobias Burnus
PR fortran/43040
*
--- Comment #3 from patrick dot wallace at stfc dot ac dot uk 2010-02-16
08:49 ---
Subject: RE: gfortran: spurious warning of line truncation at col 72
> Works for me with both 4.4.2 and trunk.
Mystery solved. It is to do with line endings. When gfortran sees
a file with DOS line e
--- Comment #9 from paul dot richard dot thomas at gmail dot com
2010-02-16 08:59 ---
Subject: Re: ICE segfault when reading module file
> Ditto. (Don't forget "gfc_symbol *sym;" as I did in my posted patch as I
> failed
> to split three patches correctly.)
***grin***
OK - Paul
-
--- Comment #10 from pault at gcc dot gnu dot org 2010-02-16 09:04 ---
(In reply to comment #6)
Joost,
I held back from committing the patch this morning because I noticed that your
testcase below is also calling pack/unpack like it is going out of business.
I have to confess that I
--- Comment #11 from jv244 at cam dot ac dot uk 2010-02-16 09:22 ---
(In reply to comment #10)
> (In reply to comment #6)
>
> Joost,
>
> I held back from committing the patch this morning because I noticed that your
> testcase below is also calling pack/unpack like it is going out of b
--- Comment #30 from developer at sandoe-acoustics dot co dot uk
2010-02-16 09:23 ---
apropos
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00587.html
do you think that _OBJC_CLASS_REFERENCES_* and _OBJC_SELECTOR_REFERENCES_*
should be marked as TREE_ADDRESSABLE and DECL_PRESERVE_P in
#include
#include
struct AB {
unsigned a:1;
unsigned b:31;
};
int main(int argc, char **argv) {
unsigned in;
struct AB ab;
unsigned b2;
sscanf(argv[1], "%x", &in);
ab = (struct AB){0,in};
b2 = ab.b + ab.b;
assert(!(b2 <=
--- Comment #31 from jakub at gcc dot gnu dot org 2010-02-16 10:06 ---
Not sure about TREE_ADDRESSABLE, but certainly DECL_PRESERVED_P should be set
as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
This thing quite annoys me and it's present in all cross gcc/binutils
environments. If you install cross binutils+gcc, it looks like this (example
with --prefix=/usr --target=m68k-atari-mint):
/usr/bin/m68k-atari-mint-as
/usr/bin/m68k-atari-mint-gcc
:
:
/usr/m68k-atari-mint/bin/as (but not gcc, on
--- Comment #32 from rguenth at gcc dot gnu dot org 2010-02-16 10:14
---
(In reply to comment #24)
> Yes, I think IainS is on the right track, all things in objc_cls_refs escape
> and can be read and written to in unexpected ways by the runtime. Setting
> TREE_ADDRESSABLE sounds like a
--- Comment #33 from rguenth at gcc dot gnu dot org 2010-02-16 10:14
---
(In reply to comment #32)
> (In reply to comment #24)
> > Yes, I think IainS is on the right track, all things in objc_cls_refs escape
> > and can be read and written to in unexpected ways by the runtime. Setting
MODULE test
USE iso_c_binding
TYPE, BIND(c) :: odig
INTEGER(c_int) :: value
END TYPE
TYPE, BIND(c) :: odig_type
INTEGER(c_int64_t) :: name
INTEGER(c_int) :: value
END TYPE
INTEGER(c_int),PARAMETER :: od_ig=11
INTERFACE
SUBROUTINE odessa_segment_all(iseg,ityp,itype,
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-16 10:16 ---
0x7fff + 1 overflows. Signed overflow invokes undefined behavior.
Use -fwrapv if you want wrapping signed overflow.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43084
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43083
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-16 10:21 ---
We get
6493 STRIP_USELESS_TYPE_CONVERSION (*expr_p);
(gdb) call debug_tree (*expr_p)
unit size
align 8 symtab 0 alias set -1 canonical type 0x77ee4888 precision 1
min max >
arg
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-02-16 10:22 ---
FE issue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|libstd
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.3.4
Target Milestone|--- |4.4.4
http://
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27016
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-16 10:30 ---
rguent...@murzim:/tmp> gcc-3.3 -Os -c t.i -m32
rguent...@murzim:/tmp> size t.o
textdata bss dec hex filename
222 0 0 222 de t.o
rguent...@murzim:/tmp> gcc-4.1 -Os -c t.i -m
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-16 10:34 ---
It works for me with FSF 4.3.4. You might want to report this to Debian.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.4 / 4.5 regression] loop |[4.4/4.5 Regression] loop
|canonicalization causes
--- Comment #20 from Roger dot Jeurninck at home dot nl 2010-02-16 10:36
---
great job, couldn't even hope that I got a solution that fast!!
The patch did the trick for 4.4.2 on Solaris and the 'hanging' file builds
without any issues.
pls let me know if I can be of any help in further
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42648
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-16 10:37 ---
So, was this fixed on trunk?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42851
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42886
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-02-16 10:39 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|c++ |middle-end
Keywords||missed-opt
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42073
--- Comment #1 from david at westcontrol dot com 2010-02-16 10:46 ---
There are many other cases where 8-bit optimisation is missing - C's integer
promotion gets in the way. This is particularly common when dealing with a
compile-time constant - there is no way in C to say that "0x3f" i
--- Comment #10 from burnus at gcc dot gnu dot org 2010-02-16 10:51 ---
Subject: Bug 41869
Author: burnus
Date: Tue Feb 16 10:50:56 2010
New Revision: 156799
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156799
Log:
2010-02-16 Paul Thomas
PR fortran/41869
*
--- Comment #11 from burnus at gcc dot gnu dot org 2010-02-16 10:53 ---
... and FIXED it myself.
Thanks again for the fix, Paul. (I refrain from thanking myself for reporting
the bug ;-)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #2 from 0xe2 dot 0x9a dot 0x9b at gmail dot com 2010-02-16
10:59 ---
(In reply to comment #1)
> 0x7fff + 1 overflows. Signed overflow invokes undefined behavior.
Like so what? Is this your way of saying "I am not going to fix it"? Do you
find it convenient to hide your
--- Comment #10 from pault at gcc dot gnu dot org 2010-02-16 10:59 ---
(In reply to comment #9)
> Fixed.
>
Richard,
With one thing and another this slipped my mind.
Sorry
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42997
--- Comment #12 from paul dot richard dot thomas at gmail dot com
2010-02-16 11:01 ---
Subject: Re: ICE segfault when reading module file
Aahhh... thanks, I was going to attend to it myself.
Well thank you for the report :-)
Paul
On Tue, Feb 16, 2010 at 11:53 AM, burnus at gcc dot
--- Comment #1 from burnus at gcc dot gnu dot org 2010-02-16 11:14 ---
Confirm. (Compiles with NAG, ifort, g95; fails with gfortran 4.3/4.4/4.5.)
Though, I think this is a duplicate of PR 42851, based on the location.
Valgrind shows:
Invalid read of size 8
at 0x55FAF5: gfc_trans_
--- Comment #1 from ramana at gcc dot gnu dot org 2010-02-16 11:20 ---
What happens if you use make all-gcc all-target-libgcc on the top level of your
object tree rather than using make all.
Also, it's not necessary that all options supported by the Codesourcery
toolchain should work
--- Comment #3 from 0xe2 dot 0x9a dot 0x9b at gmail dot com 2010-02-16
11:23 ---
(In reply to comment #2)
>
> If I were to modify the test case like this:
>
> int i = ab.b;
> b2 = i + i;
>
> I would be ALSO triggering undefined behavior. But the modified test-case
> would
> succeed
--- Comment #1 from irar at gcc dot gnu dot org 2010-02-16 11:35 ---
Subject: Bug 43074
Author: irar
Date: Tue Feb 16 11:35:03 2010
New Revision: 156800
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156800
Log:
PR tree-optimization/43074
* tree-vectorizer.h (VE
--- Comment #3 from jakub at gcc dot gnu dot org 2010-02-16 11:35 ---
Yes.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from irar at gcc dot gnu dot org 2010-02-16 11:42 ---
Subject: Bug 43074
Author: irar
Date: Tue Feb 16 11:41:55 2010
New Revision: 156802
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156802
Log:
PR tree-optimization/43074
* tree-vect-analyze.c (
--- Comment #4 from jakub at gcc dot gnu dot org 2010-02-16 11:56 ---
There is nothing to fix. Your program triggers undefined behavior. It can do
anything, which can include something you'd expect, or something completely
different and it can depend on compiler options, position of st
--- Comment #4 from joseph at codesourcery dot com 2010-02-16 12:09 ---
Subject: Re: gfortran: spurious warning of line truncation
at col 72
On Tue, 16 Feb 2010, patrick dot wallace at stfc dot ac dot uk wrote:
> Mystery solved. It is to do with line endings. When gfortran sees
> a
--- Comment #1 from joseph at codesourcery dot com 2010-02-16 12:14 ---
Subject: Re: New: Why gcc can't invoke -as
and uses 'as' instead?
The key thing to remember about $prefix/$target/bin
(/usr/m68k-atari-mint/bin in this case) is that it is an *internal*
directory of the toolcha
--- Comment #16 from l dot lunak at suse dot cz 2010-02-16 12:47 ---
Created an attachment (id=19887)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19887&action=view)
testcase from kdesdk/umbrello
If it helps, here's another testcase where 2G RAM is not enough. This is "g++
(SUSE
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-16 12:59 ---
Mine.
C testcase showing exponential behavior:
> ~/bin/maxmem.sh /usr/bin/time ./cc1 -quiet -O2 t.i
6.20user 0.09system 0:06.32elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+8outputs (0major+30333minor)pa
--- Comment #17 from jakub at gcc dot gnu dot org 2010-02-16 13:06 ---
You should retry with r156794 or newer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-16 13:17 ---
#define FOO ((long)i * (long)i)
#define FOO2 (FOO * FOO)
#define FOO3 (FOO2 * FOO2)
#define FOO4 (FOO3 * FOO3)
#define FOO5 (FOO4 * FOO4)
#define FOO6 (FOO5 * FOO5)
#define FOO7 (FOO6 * FOO6)
#define FOO8 (FOO7 * FOO
--- Comment #5 from dominiq at lps dot ens dot fr 2010-02-16 13:22 ---
I think http://gcc.gnu.org/ml/gcc/2010-02/msg00156.html is the same problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41043
/* { dg-do run } */
/* { dg-options "-O2 -march=i586 -dA -g -fomit-frame-pointer" { target { {
i?86-*-* x86_64-*-* } && ilp32 } } } */
void __attribute__((noinline))
bar (int *p)
{
(*p)++;
asm volatile ("" : "=r" (*p) : "0" (*p) : "memory");
}
void __attribute__((noinline))
baz (int a, int b,
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2010-02-16
13:25 ---
> Except from the fact this 'as' is not symlinked but copied
It must be hardlinked, not copied, on the systems which support hard links.
> The fact that the toolchain has various such internal directories
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.5.0
http://gcc.g
--- Comment #7 from jacek at codeweavers dot com 2010-02-16 13:35 ---
I've confirmed that it's fixed for Mozilla code. Thank you!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43031
686-mingw32
Configured with: ../gcc/configure --prefix=/home/jacek/gcc/mingw
--target=i686-mingw32 --with-gnu-ld --with-gnu-as --enable-__cxa_atexit
target_alias=i686-mingw32 --enable-languages=c,c++
Thread model: win32
gcc version 4.5.0 20100216 (experimental) (GCC)
--
--- Comment #1 from jacek at codeweavers dot com 2010-02-16 13:45 ---
Created an attachment (id=19888)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19888&action=view)
Preprocessed nsSVGOuterSVGFrame.cpp
Result of command
$ i686-mingw32-g++ -mno-cygwin -o nsSVGOuterSVGFrame.o -c
--- Comment #3 from miro dot kropacek at gmail dot com 2010-02-16 13:47
---
>It must be hardlinked, not copied, on the systems which support hard links.
I don't know, Linux copies it, too.
>it is an *internal* directory of the toolchain for *internal* use by one
>toolchain binary call
--- Comment #5 from burnus at gcc dot gnu dot org 2010-02-16 13:51 ---
I think the comment applies only to FLOOR and ROUND - at least when it was
first written those were the only ones present. If I read the source code
correctly, the ME floor(l,f) is not directly called but instead the
--- Comment #2 from francois dot jacq at irsn dot fr 2010-02-16 14:07
---
Sorry,
this is a duplication of 34640 I found 2 years ago ... It has nothing to do
with BIND(C) but only with "value => d(:)%..." when value is a dummy !
I thought that this bug was already corrected and I did n
--- Comment #2 from jacek at codeweavers dot com 2010-02-16 14:38 ---
Here is simplified test:
struct S {
int x;
S(const S &s) {}
};
S __attribute__((__stdcall__)) getS();
void test()
{
S s = getS();
}
It seems like calling stdcall function that returns a struct (or class) with
--- Comment #34 from developer at sandoe-acoustics dot co dot uk
2010-02-16 14:58 ---
Created an attachment (id=19889)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19889&action=view)
patch with CLASS and SELECTOR refs. marked as TREE_ADDRESSABLE &
DECL_PRESERVE_P (for NeXT runtim
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-02-16 15:06 ---
I can mitigate the effect of VRP calling SCEV somewhat, but still we'll
the following trigger the issue.
int foo (int i)
{
long j = i;
int k = 0;
while (j < 1)
{
j *= i;
j *= j;
j *=
--- Comment #1 from jakub at gcc dot gnu dot org 2010-02-16 15:17 ---
For sp based addresses in the -fno-var-tracking-assignments case we have
vt_stack_adjustments that replaces the sp based MEMs with CFA based ones
(frame_pointer_rtx resp. arg_pointer_rtx based ones).
Unfortunately, add
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43093
--- Comment #6 from abel at gcc dot gnu dot org 2010-02-16 15:43 ---
How about the below patch? It fixes all testcases for me. I'm not sure
whether it makes sense to filter duplicate labels this late, but I don't know
how to do this earlier, as catches seem to be lowering independently
--- Comment #3 from pault at gcc dot gnu dot org 2010-02-16 15:46 ---
(In reply to comment #2)
I have just patched a tree with the fix for PR36932 on an i686 at work. None
of these temporaries appear!
Something is different between 32 and 64 bits..
Paul
--
http://gcc.gnu.org/bug
--- Comment #5 from kargl at gcc dot gnu dot org 2010-02-16 16:01 ---
(In reply to comment #4)
> Subject: Re: gfortran: spurious warning of line truncation
> at col 72
>
> On Tue, 16 Feb 2010, patrick dot wallace at stfc dot ac dot uk wrote:
>
> > Mystery solved. It is to do with li
--- Comment #3 from jorrit at jorrit dot de 2010-02-16 16:03 ---
This still fails with "gcc version 4.3.4 (Debian 4.3.4-6)" and "gcc version
4.4.3 20100108 (prerelease) (Debian 4.4.2-9)"
In addition the workaround suggested in the last comment stopped working for
gcc 4.4
--
jorrit at
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-16 16:08
---
Jason, can we still do something about this? See Comment #3, in particular...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from patrick dot wallace at stfc dot ac dot uk 2010-02-16
16:10 ---
Subject: RE: gfortran: spurious warning of line truncation at col 72
> Well, it's a counting issue. Fixed-form Fortran is required to
> have exactly 72 characters in a line of code. Does CRLF count as
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-02-16 16:11 ---
Subject: Bug 41043
Author: rguenth
Date: Tue Feb 16 16:11:28 2010
New Revision: 156808
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156808
Log:
2010-02-16 Richard Guenther
PR tree-optimization/
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-02-16 16:12 ---
"Fixed" on trunk. Let's see if it causes any performance fallout.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #35 from mikestump at comcast dot net 2010-02-16 16:25 ---
Ok to the last patch for now. Feel free to file a bug about checking
DECL_PRESERVE_P and add a pointer to remove the setting of DECL_ATTRIBUTES from
the frontend, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #7 from burnus at gcc dot gnu dot org 2010-02-16 16:25 ---
(In reply to comment #3)
> Mystery solved. It is to do with line endings. When gfortran sees
> a file with DOS line endings it interprets the CR and LF as separate
> characters. This is why demonstrating the effect
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-16 16:27 ---
Created an attachment (id=19890)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19890&action=view)
patch
Incomplete patch I've tried, didn't make any difference unfortunately.
--
http://gcc.gnu.org/bugzilla/
--- Comment #8 from kargl at gcc dot gnu dot org 2010-02-16 16:29 ---
(In reply to comment #6)
> Subject: RE: gfortran: spurious warning of line truncation at col 72
>
> > Well, it's a counting issue. Fixed-form Fortran is required to
> > have exactly 72 characters in a line of code.
--- Comment #5 from jorrit at jorrit dot de 2010-02-16 16:30 ---
Here is a workaround that works with gcc "gcc version 4.1.3 20080704
(prerelease) (Debian 4.1.2-27)" as well as the gcc 3.4 and 4.4 mentioned in
Comment #3.
=
--- Comment #9 from doko at ubuntu dot com 2010-02-16 16:34 ---
confirmed with binutils trunk 20100216, checking with gold from the trunk.
--
doko at ubuntu dot com changed:
What|Removed |Added
Linking CXX executable semnotes
cd /home/pielud/creator/semnotes/build/src && /usr/bin/cmake -E
cmake_link_script CMakeFiles/semnotes.dir/link.txt --verbose=1
/usr/bin/c++ -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align
-Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-
--- Comment #6 from jason at gcc dot gnu dot org 2010-02-16 16:46 ---
Clarified summary. Since this isn't a regression and there is a workaround, it
doesn't seem like a high priority for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |
usr/local/avr --target=avr
--enable-languages=c --disable-nls --disable-libssp --with-dwarf2 :
(reconfigured) ../configure --prefix=/usr/local/avr --target=avr
--enable-languages=c --disable-nls --disable-libssp --with-dwarf2
Thread model: single
gcc version 4.5.0 20100216 (experimental) (GCC)
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-16 17:05 ---
>/usr/lib/gcc/i586-suse-linux/4.4/../../../../i586-suse-linux/bin/ld: BFD (GNU
Binutils; openSUSE 11.2) 2.19.51.20090527-10.26.4 internal error, aborting at
../../bfd/merge.c line 869 in _bfd_merged_section_offset
--- Comment #9 from dominiq at lps dot ens dot fr 2010-02-16 17:06 ---
Apparently gfortran.dg/pr41043.f90 has not been committed.
Thanks for the fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41043
--- Comment #20 from jason at gcc dot gnu dot org 2010-02-16 17:10 ---
I would approve a patch to enable the warnings in conversion_null_warnings, and
the similar warning in build_expr_type_conversion, by default. That is,
reverting revision 109847. I don't know what Eric's rationale w
The following ACATS started failing:
,.,. C37105A ACATS 2.5 10-02-16 15:35:22^M
C37105A RECORDS WITH ONLY DISCRIMINANTS.^M
* C37105A DISCRIMINANT-ONLY RECORDS DON'T WORK.^M
C37105A FAILED .^M
between:
PASS: LAST_UPDATED: Fri Jan 29 14:43:55 UTC 2010 (revi
--- Comment #5 from 0xe2 dot 0x9a dot 0x9b at gmail dot com 2010-02-16
17:37 ---
(In reply to comment #4)
> There is nothing to fix. Your program triggers undefined behavior. It can do
> anything, which can include something you'd expect, or something completely
> different and it can
GCC trunk gets an internal compiler error when building SPEC CPU2000 test
173.applu on powerpc64-linux with options "-O2 -fgraphite-identity
-ftree-vectorize" for either -m32 or -m64. Here's a minimized testcase:
subroutine foo (ldmx,ldmy,nx,ny,v)
implicit real*8 (a-h, o-z)
dime
--- Comment #20 from bernds_cb1 at t-online dot de 2010-02-16 17:40 ---
Sorry I've seen this so late; the mails I got have been hidden in my unread
fortran folder so far. Need to change the filters.
Comment #9 suggests you can reproduce this without -frename-registers. Is this
correct
--- Comment #1 from laurent at guerby dot net 2010-02-16 17:43 ---
Might be related to the same patch on powerpc-linux two different ACATS started
FAILing around the same time:
LAST_UPDATED: Fri Jan 29 08:20:22 UTC 2010 (revision 156342)
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg
--- Comment #7 from amonakov at gcc dot gnu dot org 2010-02-16 17:43
---
(In reply to comment #6)
Looks like this has been fixed. We do generate good code:
fred:
li 0,100
mtctr 0
.L2:
sthu 3,2(4)
bdnz .L2
blr
.size fred, .-fred
Sent from my iPhone
On Feb 16, 2010, at 9:37 AM, "0xe2 dot 0x9a dot 0x9b at gmail dot com"
wrote:
--- Comment #5 from 0xe2 dot 0x9a dot 0x9b at gmail dot com
2010-02-16 17:37 ---
(In reply to comment #4)
There is nothing to fix. Your program triggers undefined
behavior.
--- Comment #6 from pinskia at gmail dot com 2010-02-16 17:51 ---
Subject: Re: Optimizer ignores type in a conversion
Sent from my iPhone
On Feb 16, 2010, at 9:37 AM, "0xe2 dot 0x9a dot 0x9b at gmail dot com"
wrote:
>
>
> --- Comment #5 from 0xe2 dot 0x9a dot 0x9b at gmail d
GCC (156804, x86_64-unknown-linux-gnu) generates an ICE in compiling the
following code.
typedef __builtin_va_list va_list;
struct __attribute__((aligned (4))) S238 { struct{}a[24]; short b; } ;
struct __attribute__((aligned (4))) S238 a238[5];
extern int fails;
void foo (int z, ...) {
s
--- Comment #21 from echristo at apple dot com 2010-02-16 18:01 ---
I remember that we originally ran into this warning in a huge number of places
building OSX. Now I'd agree that null checking would be something good to
have, but there should be some way to turn it off if it's on by de
--- Comment #22 from manu at gcc dot gnu dot org 2010-02-16 18:05 ---
Testing this:
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 156812)
+++ gcc/doc/invoke.texi (working copy)
@@ -3835,18 +3835,23 @@ lik
--- Comment #23 from echristo at apple dot com 2010-02-16 18:09 ---
That looks fine to me, though you'll probably want to use "null" instead of
null in the command line option. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35669
--- Comment #21 from dominiq at lps dot ens dot fr 2010-02-16 18:13 ---
> Comment #9 suggests you can reproduce this without -frename-registers. Is
> this
> correct?
>From comment #12:
> -funroll-loops triggers -frename-registers which again would hint at
> Bernds change.
I think th
1 - 100 of 153 matches
Mail list logo
