--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-27 07:18 ---
Confirmed, simple testcase for this really:
int f(int a)
{
int b = a % 3;
return b > 4 || b < -4;
}
This should always return false as b can be proved to be in between -2 and 2.
for unsigned mod, the range is [
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-27 07:04 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-12-27 06:53 ---
(In reply to comment #1)
> > #define BUF ((uip_tcpip_hdr *)&uip_buf[UIP_LLH_LEN])
> Right there is an alias violation.
More than that this is an alignment violation.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #22 from pinskia at gcc dot gnu dot org 2008-12-27 06:51
---
Can you still provide the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-27 06:43 ---
Confirmed from Janis's testresults:
http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg02361.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-27 06:41 ---
THis works for me on different targets.
Can you try building GCC yourself without using the port system on freebsd?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-12-27 06:34
---
*** Bug 37596 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-27 06:34 ---
*** This bug has been marked as a duplicate of 11814 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-12-27 06:35
---
Does this happen still?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-12-27 06:22 ---
How about -fno-delete-null-pointer-checks -O2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37107
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-27 06:19 ---
*** Bug 38620 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-27 06:19 ---
*** This bug has been marked as a duplicate of 37177 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-27 06:15 ---
Can you reproduce this now?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-27 06:11 ---
I don't think the different pointer matters.
There is an extra temporary that shows up on the stack.
When doing the expanding of:
;; b.D.21263 = f (); [return slot optimization]
We get that extra temp. RSO is not w
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-27 05:54 ---
I found this also too and saw it was a regression because -O3 changes.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-27 05:53 ---
Blah, someone else find this bug too.
*** This bug has been marked as a duplicate of 37194 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-27 05:53 ---
*** Bug 37579 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37194
--- Comment #15 from pinskia at gcc dot gnu dot org 2008-12-27 05:46
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|4.3.3 |4.2.0 4.3.3
Target Milestone|4.4.0 |4.3.3
h
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-27 05:25 ---
Was this ever fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37264
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-27 01:38 ---
This is a regression as we went from rejecting this code to ICEing on it.
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-27 01:35 ---
How can this be a regression when auto never worked in a released compiler?
Anyways confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-27 01:29 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-27 01:28 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-12-27 00:38 ---
*** This bug has been marked as a duplicate of 23169 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from dfranke at gcc dot gnu dot org 2008-12-27 00:38 ---
*** Bug 36076 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from paolo dot carlini at oracle dot com 2008-12-27 00:33
---
... by the way, before anything else, I think you should confirm that the
software works fine if built with current mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38631
--- Comment #3 from paolo dot carlini at oracle dot com 2008-12-26 23:05
---
Bah, for sure we need a reduced testcase anyway, I have no idea what to do with
this report, otherwise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38631
--- Comment #2 from mikael at gcc dot gnu dot org 2008-12-26 23:04 ---
Created an attachment (id=16989)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16989&action=view)
patch, not regression-tested
This patch fixes the ICE and accepts the following (valid, I think) program
(reject
--- Comment #1 from mikael at gcc dot gnu dot org 2008-12-26 22:54 ---
About the second error:
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33497#c3
in resolve.c:
2095 else if (parent_ref != NULL && parent_ref->type != REF_COMPONENT)
2096 gfc_internal_error ("Unexpected exp
The following valid code snippet triggers an ICE since GCC 4.3.0
(when __decltype was introduced):
template void foo(__decltype(N));
bug.cc:1: internal compiler error: in finish_decltype_type, at
cp/
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38639
--- Comment #10 from tkoenig at gcc dot gnu dot org 2008-12-26 22:48
---
(In reply to comment #8)
> Plus this is documented this way:
> http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Target-Options.html#index-V-901
I see this works for gcc. I also see (in the 4.4.0 docs)
# The C++ compi
The following invalid code snippet triggers an ICE on mainline when compiled
with "-fopenmp":
template void foo()
{
#pragma omp parallel for
for (auto i = i = 0; i<4; ++i) ;
}
void bar()
{
foo<0>();
}
bug.cc: I
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38638
The following invalid code snippet triggers an ICE since GCC 4.2.0:
struct A
{
template void foo(int i)
{
typename A::foo<0>(i);
}
};
bug.cc: In member function 'void A::foo(int)':
bug.cc:5: internal compi
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38637
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-26 22:30 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
The following invalid code snippet triggers an ICE on mainline:
template enum E : int { e };
bug.cc:1: error: template declaration of 'enum E'
bug.cc:1: internal compiler error: tree check: expected integer_type or
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-26 22:29 ---
Happens with both the C and C++ front-ends.
Backtrace:
#2 0x00566f2e in replace_by_duplicate_decl (tp=0xb43c,
vars_map=0x43902ae0, to_context=0x42f76100) at
/Users/apinski/src/local/gcc/gcc/tree-cfg.c:5412
#3 0
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-26 22:26 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-26 22:25 ---
This only ICEs with checking turned on now.
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-12-26 22:24
---
Fixed.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGN
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-26 22:23 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-26 22:22 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38636
The following invalid code snippet triggers an ICE since GCC 4.0.0:
struct A;
A::A(
struct B;
bug.cc:5: internal compiler error: in push_class_level_binding, at
cp/name-lookup.c:2756
Please submit a full bug repor
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38635
The following invalid code snippet triggers an ICE on mainline:
void foo()
{
if (struct A{}
bug.cc: In function 'void foo()':
bug.cc:3: error: types may not be defined in conditions
bug.cc:3: error: expected unqua
The following invalid code snippet triggers an ICE since at least GCC 2.95.3:
template struct A
{
A();
};
template A::A()
{
struct B {};
}
A<0> a;
bug.cc:6: error: got 2 template parameters for 'A< >::A()'
bug
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38633
The following valid code snippet triggers an ICE on mainline when compiled
with "-fopenmp":
void foo()
{
#pragma omp parallel
{
struct A;
}
}
bug.c: In function 'foo':
bug.c:3: internal compiler error: in re
--- Comment #1 from mikael at gcc dot gnu dot org 2008-12-26 21:46 ---
it works for me at revision 142908
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38568
The following valid code snippet triggers an ICE when compiled with
"-O -ftree-parallelize-loops=2":
void foo();
void bar(int n, char *p)
{
try
{
foo();
++n;
foo();
for (int i = 0; i < n-1; ++i)
p[i] = 0;
}
catch (...)
{
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-26 21:35 ---
>set_param_value ("inline-call-cost", 5);
This might be too high, the default for -O2/-O3 is 12. That might be the real
issue.
Also -O2/-Os for 3.4 and above did the same inlining of static functions that
4.3
--- Comment #2 from forwards dot from dot bugzilla at d81 dot de
2008-12-26 21:29 ---
Steven, thanks for your explanation. My point of view was that gcc-4.3.3 did do
inlining code for "-Os", "-O1", "-O2" although the manual clearly states that
it would not do inlining for these optimiza
--- Comment #2 from bero at arklinux dot org 2008-12-26 21:09 ---
If I install libstdc++ from gcc 4.4.0 and libgcc_s from gcc 4.3.2 (yes, I know
that's a weird thing to do, and it's definitely not my normal setup), it works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38631
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-26 18:43 ---
(In reply to comment #2)
> Thanks for your reply.
> Can you please let me know the complete steps needed to build the 4.3.2 source
> code on solaris 5.7 ? I tried doing ./configure and it says that some
> components
--- Comment #2 from soumendus at rediffmail dot com 2008-12-26 18:38
---
(In reply to comment #1)
> 2.95.3 is about 8 years old now and not supported. Without a full testcase it
> is hard to figure out what is going on. Also you might want to try 4.3.2
> which
> is the latest release
--- Comment #4 from dodji at gcc dot gnu dot org 2008-12-26 18:32 ---
More work-in-progress patches for this PR can be checked out at
http://www.seketeli.org/dodji/patches/gcc/PR30161 .
Please note that each patch there is self contained and passes regtests on
x86_64. The tests accompany
--- Comment #18 from tim dot vanholder at anubex dot com 2008-12-26 18:06
---
I see that my gcc build tree (last used to build 4.3.2 on Sep 26) does not have
any local changes to the libstdc++-v3 directory, according to 'svn diff'. This
at least suggests it is resolved.
A quick check sh
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-26 17:54 ---
2.95.3 is about 8 years old now and not supported. Without a full testcase it
is hard to figure out what is going on. Also you might want to try 4.3.2 which
is the latest release and is still supported.
--
pins
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-12-26 17:50 ---
Plus this is documented this way:
http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Target-Options.html#index-V-901
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-12-26 17:50 ---
The -V and -b options work by running the -gcc- executable,
so there's no real reason to use them if you can just run that directly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38628
--- Comment #2 from jakub at gcc dot gnu dot org 2008-12-26 17:48 ---
Caused by PR21366, IMHO for -b alone (where the option comes in the second arg)
we shouldn't check for the hyphen at all.
--
jakub at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-12-26 17:49 ---
That is because when you use -V, it calls ${target}-gcc-4.3 rather than
${target}-gfortran-4.3 or ${target}-4.3-g++.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38628
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-26 17:40
---
In any case, why you are so sure the problem is due to libstdc++ and not
libgcc_s?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38631
--- Comment #6 from dfranke at gcc dot gnu dot org 2008-12-26 17:31 ---
Just to make sure, you cleaned out the prefix before?
I use a similar setup at work, 4.2, 4.3 and trunk, all in the same prefix.
Besides "--enable-version-specific-runtime-libs", I also have
"--program-suffix=-${bra
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.4.0
Known to work||4.3.2
Target
igured with: ../gcc-4_3/configure --prefix=/home/tkoenig
--enable-languages=c,fortran,c++ --with-gmp=/opt/cfarm/mpfr-2.3.2/
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.3.3 20081226 (prerelease) (GCC)
tkoe...@gcc16:/tmp$ g++ -V4.3.3 hello.cc
/tmp/cc40A3Ee.o:(.eh_frame+0x12)
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-12-26 16:11 ---
Works with current trunk, 4.1 is no longer maintained.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-12-26 16:08 ---
Is this still an issue with current trunk?
gcc 3.4 has been out of maintenance for some time.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-12-26 16:07 ---
Failing with 183 failures with
gcc -std=c99 foo.c -lm
on current trunk with x86_64-unknown-linux-gnu
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-26 16:02 ---
Is there a test case which shows the wrong-code
behavior, and which can be checked against the
new register allocator?
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-12-26 15:44 ---
(In reply to comment #3)
> IIRC this is by design.
What on earth for?
Especially, what could be the reason for having -V, while making sure
it doesn't work?
I'll try the switch suggested by Daniel.
--
http://
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-26 15:38 ---
GCC inline heuristics are just that: heuristics. They are not optimal for all
targets but only for those targets that they have been tuned for.
For AVR, nobody ever tuned the heuristics, despite several suggestions (
Compile OpenOffice.org 3.0 with gcc 4.3.2, then update to a recent gcc 4.4
snapshot (I tried rev. 142890).
OpenOffice.org now crashes on startup. There is no need to recompile anything
with gcc 4.4.
Backtrace:
#0 0xb7c2f0fd in gcc3::deleteException () from
/usr/lib/ooo-3.0/ure/lib/libgcc3_uno.so
Hi,
This seems to be a bug in the default O0 optimization level. With O1 , -O2
and O3 it works fine.
I have seen it many times that it generates perfect code with O1 , -O2 and O3
but if I change to O0
things dont work.
The following is the issue.
The following function func( )
Hello GCC bug hunters,
I'm using GCC C compiler, compiled as a cross compiler for AVR (ATmel
microcontrollers) on Cygwin (Windows). With earlier GCC version 4.1.2 always
smaller code was generated for one of the projects I'm working on than with
more recent versions of GCC. I tested with GCC 4.2.x
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-26 13:34 ---
IIRC this is by design.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38628
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-12-26 12:53 ---
--enable-version-specific-runtime-libs, maybe?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-26 11:49 ---
This bug hasn't been active for a long time.
Is this still an issue?
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-12-26 11:46 ---
Closing, then.
Once again, the number of gcc bugs goes down by approximately 0.02% :-)
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-26 10:54 ---
Same problem with g++:
tkoe...@gcc16:/tmp$ g++ hello.cc
tkoe...@gcc16:/tmp$ g++ -V4.3.3 hello.cc
/tmp/ccQtuMbq.o:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status
tk
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38342
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38594
++ --with-gmp=/opt/cfarm/mpfr-2.3.1/
Thread model: posix
gcc version 4.4.0 20081226 (experimental) (GCC)
tkoe...@gcc16:~$ gfortran -V4.3.3 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4_3/configure --prefix=/home/tkoenig
--enable-languages=c,fortran,c++ --with-gmp=/opt
--- Comment #4 from dcb314 at hotmail dot com 2008-12-26 09:55 ---
(In reply to comment #3)
> I think this is fixed on the trunk now.
I agree. I just re-checked it and it seems
fixed to me.
--
dcb314 at hotmail dot com changed:
What|Removed |Adde
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-12-26 09:10 ---
(In reply to comment #3)
> > Works with 4.3:
>
> Well, not really. gfortran 4.1/4.2/4.3 only call the module procedure, but for
> "call f()" the contained procedure should be called, which does not work with
> 4.[1-
--- Comment #11 from tammer at tammer dot net 2008-12-26 09:10 ---
Created an attachment (id=16988)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16988&action=view)
libstdc++.sum
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38607
--- Comment #10 from tammer at tammer dot net 2008-12-26 09:07 ---
Created an attachment (id=16987)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16987&action=view)
gcc.sum
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38607
--- Comment #9 from tammer at tammer dot net 2008-12-26 09:06 ---
Created an attachment (id=16986)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16986&action=view)
g++.sum
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38607
--- Comment #8 from tammer at tammer dot net 2008-12-26 08:52 ---
Hello,
one small addition. I have tried to add -Wl,-brtl to the xgcc calls (which
produces the libstdc++.so.6) and as a result the ld errors are gone.
/powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/Makefile
OPT_LDFLAGS = -Wl,-
--- Comment #7 from tammer at tammer dot net 2008-12-26 08:37 ---
Hello,
this problem is present for every call to xgcc with the output of "-o
.libs/libstdc++.so.6".
The resulting library is not correct for AIX.
The error message (example):
ld: 0711-768 WARNING: Object ../libsupc++/.l
95 matches
Mail list logo
