--- Comment #1 from uros at gcc dot gnu dot org 2009-10-03 08:16 ---
Subject: Bug 41542
Author: uros
Date: Sat Oct 3 08:15:55 2009
New Revision: 152432
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152432
Log:
PR testsuite/41542
* gcc.dg/tree-ssa/ipa-cp-1.c:
--- Comment #2 from ubizjak at gmail dot com 2009-10-03 08:16 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
20091003 (experimental) [trunk revision
152431].
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0
--- Comment #7 from sam at gcc dot gnu dot org 2009-10-03 09:53 ---
(In reply to comment #6)
committed to trunk, 4.4 will follow.
Any news about the 4.4 commit?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41122
--- Comment #1 from sam at gcc dot gnu dot org 2009-10-03 10:11 ---
It has been fixed on trunk by commit 134020. The fix will be in GCC 4.5.0.
2008-04-08 Javier Miranda mira...@adacore.com
Robert Dewar de...@adacore.com
Ed Schonberg schonb...@adacore.com
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-10-03 10:31
---
It has been fixed on trunk by commit 134020. The fix will be in GCC 4.5.0.
2008-04-08 Javier Miranda mira...@adacore.com
Robert Dewar de...@adacore.com
Ed Schonberg
--- Comment #1 from sam at gcc dot gnu dot org 2009-10-03 10:41 ---
This has been fixed in GCC 4.4 already.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from sam at gcc dot gnu dot org 2009-10-03 10:42 ---
This has been fixed in SVN, the fix will be in GCC 4.5.0.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
./g++ -B. -fPIC -O -flto -c dvector.3.ii slufactor.3.ii
./g++ -nostdlib -B. -fPIC -O -shared -o t slufactor.3.o dvector.3.o
nm t | grep _ZN6soplex7DVectoraSERKNS_6VectorE
./g++ -nostdlib -B. -fPIC -O -shared -o t dvector.3.o slufactor.3.o
nm t | grep _ZN6soplex7DVectoraSERKNS_6VectorE
./g++
--- Comment #1 from sam at gcc dot gnu dot org 2009-10-03 10:57 ---
This has been fixed in commit 149326 and will be in GCC 4.5.0.
2009-07-07 Pascal Obry o...@adacore.com
* s-osprim-mingw.adb (Get_Base_Time): Avoid infinite loop.
--
sam at gcc dot gnu dot org
--- Comment #3 from sam at gcc dot gnu dot org 2009-10-03 11:01 ---
No reproducer, no answer for 4+ months, closing.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Recently, gcc started to timeout when compiling
g++.old-deja/g++.other/crash28.C:
Executing on host: /home/uros/gcc-build/gcc/testsuite/g++1/../../g++
-B/home/uros/gcc-build/gcc/testsuite/g++1/../../ -nostdinc++
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-10-03 11:21
---
I ran into it on i586 as well.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from sam at gcc dot gnu dot org 2009-10-03 11:23 ---
It is triggered if you instantiate pak1 as a pure unit:
% cat p.ads
with Pak1;
package P is new Pak1;
pragma Pure (P);
% gcc -c p.ads
p.ads:2:01: instantiation error at pak1.ads:4
p.ads:2:01: named access type not
--- Comment #2 from sam at gcc dot gnu dot org 2009-10-03 11:24 ---
Confirmed on trunk
+===GNAT BUG DETECTED==+
| 4.5.0 20091003 (experimental) (x86_64-unknown-linux-gnu) GCC error: |
| in bitmap_first_set_bit, at bitmap.c:770
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-03 11:26 ---
I obviously reduced into sth with ODR violations. Fixing them makes the
testcase work ok apart from producing weak symbols for
_ZN6soplex7DVectoraSERKNS_6VectorE where the non-LTO case had no such things.
Note the
--- Comment #2 from sam at gcc dot gnu dot org 2009-10-03 11:27 ---
Confirmed on SVN trunk.
+===GNAT BUG DETECTED==+
| 4.5.0 20091003 (experimental) (x86_64-unknown-linux-gnu) Assert_Failure
atree.adb:765|
| Error detected
--- Comment #1 from sam at gcc dot gnu dot org 2009-10-03 11:32 ---
Wouldn't it be enough to replace ; by between the various steps?
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-03 11:41 ---
Ok, I have some new reduced testcases:
dvector.3.ii
typedef double Real;
class Vector {
int dimen;
Real* val;
public:
Vector operator=(const Vector vec);
Vector(int p_dimen, Real
--- Comment #1 from sam at gcc dot gnu dot org 2009-10-03 11:43 ---
It would help if you provided the RM reference that you think is violated here.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-03 11:58 ---
cgraph after input_cgraph () in the broken case:
operator=/8(-1) @0xb7d34500
called by: __base_ctor /2 (1.00 per call) (can throw external) __comp_ctor /3
(1.00 per call) (can throw external)
calls:
--- Comment #2 from davek at gcc dot gnu dot org 2009-10-03 12:23 ---
(In reply to comment #1)
Wouldn't it be enough to replace ; by between the various steps?
Hello Sam, the problem with just doing that is that xoscons can fail but still
leave fragmentary output, and then next
Both options are now recognized by individual front ends. They should be moved
to common.opt. Individual front end validation could be done via a langhook.
--
Summary: -flto and -fwhopr should be moved to common.opt
Product: gcc
Version: lto
--- Comment #7 from ubizjak at gmail dot com 2009-10-03 12:48 ---
We regressed on the example from comment #1.
gcc-4.3 with -O2 generates:
foo:
movzbl (%rdi), %edx
movq%rdx, %rax
shrq$4, %rdx
andl$15, %eax
movqtable(,%rax,8),
--- Comment #5 from sam at gcc dot gnu dot org 2009-10-03 12:55 ---
This has been fixed alreayd in SVN.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-03 13:19 ---
We only have one cgraph node for _ZN7DVectoraSERK6Vector in both files,
but its decl isn't the prevailing one!? The one for the cgraph node
is LDPR_PREEMPTED_IR while the prevailing one is LDPR_PREVAILING_DEF.
--- Comment #4 from davek at gcc dot gnu dot org 2009-10-03 13:41 ---
(In reply to comment #0)
They seem to represent serious breakage of dllexport with cygwin as the latest
testrun with my libstdc-as-dll patch is showing even more fails on top of
these, but didn't fail before they
--- Comment #14 from domob at gcc dot gnu dot org 2009-10-03 14:13 ---
Here's a patch and some comments for this:
http://gcc.gnu.org/ml/fortran/2009-10/msg00017.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41403
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-10-03 15:10
---
There are two unrelated bugs in output rounding. The following patch fixes
both. The smaller hunks were obvious. The larger gets rid of a hack I did to
handle the special case with d=0. The rounding logic
The test input below is really gross but I couldn't easily reduce it more.
The behavior leading to the apparent bad execution is actually pretty simple:
the if test in func_19() is true and so the store to g_133 must execute.
reg...@john-home:~/volatile/tmp201$ current-gcc -O3 small.c -o small
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2009-10-03 16:17
---
Correction to comment #13, Shifting bytes right not left. Also, I have
completed testing using memmove instead of the explicit for loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35862
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-03 16:33 ---
Where do you get all this testcases from ... ;)
Btw, making more functions static probably results in the same failure
without -fwhole-program (well, reproducing the same inline decision, that is).
--
rguenth
--- Comment #2 from regehr at cs dot utah dot edu 2009-10-03 16:42 ---
Created an attachment (id=18696)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18696action=view)
failure-inducing input
There is no problem here at -O3. However if you make g_101 static then the
wrong answer
--- Comment #3 from regehr at cs dot utah dot edu 2009-10-03 16:44 ---
Making the variables static in addition to the functions causes the problem to
happen at -O3.
The bad behavior happens at -O3 only if g_101 is static.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41555
When defining an abstract type with generic operators that map to deferred
bindings and using these operators in an expression, the development branch of
gfortran 4.5.0 (20090925) gives the errors shown below the program below. In
case it helps to know, IBM XL Fortran 12.1 compiles the program
Using built-in specs.
Target: djgpp
Configured with: /203/gcc-4.41/configure djgpp --prefix=/dev/env/DJDIR
--disable
-nls --disable-werror --enable-languages=c,c++,fortran,objc,obj-c++,ada
Thread model: single
gcc version 4.4.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'Teste.exe'
--- Comment #2 from jason at gcc dot gnu dot org 2009-10-03 18:48 ---
Subject: Bug 41553
Author: jason
Date: Sat Oct 3 18:48:44 2009
New Revision: 152433
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152433
Log:
PR c++/41553
* parser.c
--- Comment #3 from jason at gcc dot gnu dot org 2009-10-03 19:05 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
GNU Fortran (GCC) 4.5.0 20091003 (experimental)
subroutine f(s)
character*3 s
s = s
end
call f ('foo')
end
gdb -nx -ex 'b 3' -ex r -ex 'p s' ./file
-
Cannot access memory at address 0x6f6f66
24a: Abbrev Number: 3 (DW_TAG_formal_parameter)
4b DW_AT_name: s
The following simple cat clone fails with mudflap:
$ cat mudflap_unlocked.c
#include stdio.h
int main(int argc, char** argv) {
int chr;
while ((chr = fgetc_unlocked(stdin)) != EOF)
fputc_unlocked(chr, stdout);
return 0;
}
$ i686-pc-linux-gnu-gcc-4.4.1 -Wall -O1 -fmudflap \
--- Comment #5 from dannysmith at users dot sourceforge dot net 2009-10-03
21:47 ---
(In reply to comment #0)
These new FAILs have been appearing on trunk since some time between 20090820
and 20090903:
FAIL: g++.dg/ext/dllexport-MI1.C scan-assembler -export:_ZNK2D12vfEv
FAIL:
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
CC||dannysmith at users dot
|
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-10-03 21:54 ---
Yes, it's intended. The fix is as you suggest.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41512
--- Comment #7 from davek at gcc dot gnu dot org 2009-10-03 21:55 ---
(In reply to comment #5)
The breakage can be fixed in target backend i386/winnt-cxx.c
i386_pe_adjust_class_at_definition, by propagating the dllexport attribute
there, rather than relying on DECL_CONTEXT later.
I'm getting a bus error on the following override of operator[]. (Not sure if
it's valid.)
#include vector
templatetypename T
class MyVector : public std::vectorT
{
const T operator[](size_t n) const
{
return typename std::vectorToperator[](n);
}
};
test.cpp: In member
--- Comment #1 from markleone at gmail dot com 2009-10-03 22:01 ---
The bus error disappears when it's fixed with '::' between vectorT and
operator[] in the return statement.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41560
--- Comment #7 from Martin dot vGagern at gmx dot net 2009-10-03 22:03
---
Seems gcc 4.1.1 no longer has this kind of problems: all cases except for the
one with the expected failure do compile, and generated assembler looks sane at
first glance.
--
Martin dot vGagern at gmx dot
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-03 22:06 ---
This is fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-03 22:06 ---
This is fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-03 22:07 ---
Still true.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-03 22:08 ---
I'm not 100% sure (I don't really understand this bug), but it should be fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-10-03 22:11 ---
One testcase is enough for each ICE, please use different bugs for different
ICEs. Closing this one to start with clean bugs.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-03 22:12 ---
Waiting for someone with access to that host to investigate.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-03 22:14 ---
Needs re-confirming, I think this has been fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41159
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-03 22:16 ---
See also PR39023.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-03 22:16 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-03 22:19 ---
Not valid. At least 4.0.4 and later say
t.C: In member function const T MyVectorT::operator[](size_t) const:
t.C:7: error: expected `(' before operator
t.C:7: error: expected ; before operator
--
According to [lex.icon], Table 5 of the C++ 0x spec (e.g., N21914), the type
of the integer literal in the snippet below in ILP32 is long long. gcc does
the right thing (i.e., interprets the literal correctly) but the warning it
issues (with -m32 only) is unwarranted.
$ cat t.cpp g++
one of our more ambitious users discovered an ICE while building libmsn with
-O1 -ftree-loop-distribution -floop-block. dropping any one of these flags
makes it go away. i'll attach a reduced testcase which i believe is invalid
code but still ICEs, and the original preprocessed sources. i also
Ada.Tags cannot be compiled with -O3. GCC and Ada.Tags from SVN revision
152434.
% gcc -c -gnatg -gnatp -O3 a-tags.adb
+===GNAT BUG DETECTED==+
| 4.5.0 20091003 (experimental) (x86_64-unknown-linux-gnu) GCC error: |
| in vectorizable_store
--- Comment #1 from dirtyepic at gentoo dot org 2009-10-03 22:29 ---
Created an attachment (id=18697)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18697action=view)
minimal testcase
$ x86_64-unknown-linux-gnu-gcc-4.4.1 -O1 -Wall -ftree-loop-distribution
-floop-block
--- Comment #2 from dirtyepic at gentoo dot org 2009-10-03 22:31 ---
Created an attachment (id=18698)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18698action=view)
original preprocessed source
requires -O2 to ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41562
--- Comment #3 from matz at gcc dot gnu dot org 2009-10-03 22:49 ---
Found a nice testcase for exponential explosion. It's reduced from tree.c
(make_vector_type) when building with -fprofile-generate. The testcase needs
simply -O2 -g and takes a ridiculous amount of 4GB RAM.
It's the
--- Comment #4 from matz at gcc dot gnu dot org 2009-10-03 22:50 ---
Created an attachment (id=18699)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18699action=view)
pr41264-test.c
Compile this with
% ./cc1 -O2 -g pr41264-test.c
and cry.
--
--- Comment #16 from matz at gcc dot gnu dot org 2009-10-03 23:18 ---
Created an attachment (id=18700)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18700action=view)
pr41264-test.c
Hmm, seems I used the wrong bug report to assign a nicer testcase. Here
the comment and testcase I
--- Comment #5 from matz at gcc dot gnu dot org 2009-10-03 23:22 ---
Hmpf, sorry, I think this bug report might be about something else. The
exponential explosion is actually tracked in PR41343. I've attached the
testcase there.
--
--- Comment #4 from zadeck at naturalbridge dot com 2009-10-03 23:57
---
Richard,
the problem is that at least for the linux world there are two elf
implementations that while they claim to be compatible are distinctly different
on the inside. LTO, for better or worse, needs to use
68 matches
Mail list logo
