--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-03-04 05:37
---
Patch in the works. Stay tuned.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43228
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2010-03-04 05:32
---
Try compiling the test program with -std=f95 and then run it. ;)
Oh Bother.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43228
--- Comment #6 from kargl at gcc dot gnu dot org 2010-03-04 03:15 ---
(In reply to comment #5)
> Tobias,
>
> If you have a fix in mind, you are welcome to take this. I am going to work
> the namelist bug first.
>
Just close the report. Using Hollerith in 2010 is a less than
smart i
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-03-04 03:08
---
Tobias,
If you have a fix in mind, you are welcome to take this. I am going to work
the namelist bug first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43217
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-03-04 02:34
---
Without looking at the code yet, the matcher must see a space or double colon
after the word FINAL before matching it. If it sees anything else, its a
MATCH_NO not a MATCH_ERROR. If this is being done then the s
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2010-03-04
02:32 ---
Created an attachment (id=20017)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20017&action=view)
g++.dg/abi/mangle41.C assembly file from x86_64-apple-darwin10
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2010-03-04
02:30 ---
/sw/src/fink.build/gcc45-4.4.999-20100303/darwin_objdir/gcc/testsuite/g++/../../g++
-B/sw/src/fink.build/gcc45-4.4.999-20100303/darwin_objdir/gcc/testsuite/g++/../../
/sw/src/fink.build/gcc45-4.4.999
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2010-03-04
02:28 ---
FAIL: g++.dg/abi/mangle40.C scan-assembler weak[^\n]*_Z1fIDv4_fEvT_
FAIL: g++.dg/abi/mangle40.C scan-assembler weak[^\n]*_ZN1AIDv4_fE1tE
FAIL: g++.dg/abi/mangle41.C (test for errors, line 6)
FAIL: g++.dg/
--- Comment #11 from zsojka at seznam dot cz 2010-03-04 01:28 ---
Created an attachment (id=20016)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20016&action=view)
different reduced testcase
Testcases from comment #0 and comment #10 don't fail for me (x86_64, r157161).
However, a
--- Comment #11 from kargl at gcc dot gnu dot org 2010-03-04 00:18 ---
(In reply to comment #9)
> (In reply to comment #8)
> > It is a dup of PR 24581. Backporting the gcc/tree-complex.c change
> > in revision 147281:
> >
> > http://gcc.gnu.org/viewcvs?view=revision&revision=147281
> >
--- Comment #6 from zsojka at seznam dot cz 2010-03-03 23:45 ---
It could be regression from 3.3.6.
3.4.6, 4.1.2, 4.2.4, 4.3.4, 4.4.3 built without checking all bail out, while
3.3.6 ends with:
$ g++-3.3.6 xxx.cc
xxx.cc:6: error: ISO C++ forbids declaration of `f' with no type
xxx.cc:6:
--- Comment #12 from meissner at gcc dot gnu dot org 2010-03-03 23:01
---
As I said in the last bug entry, I have convinced myself that the compiler is
correct, and that the bug is caused by using -ffast-math when compiling, but
the atan2 library function supporting full IEEE semantics,
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-03-03 22:57
---
Or rather vectorizers differently.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43251
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-03-03 22:53 ---
(In reply to comment #8)
> It is a dup of PR 24581. Backporting the gcc/tree-complex.c change
> in revision 147281:
>
> http://gcc.gnu.org/viewcvs?view=revision&revision=147281
>
> to 4.4 fixes this.
If that is t
--- Comment #9 from hjl dot tools at gmail dot com 2010-03-03 22:49 ---
*** Bug 43251 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581
--- Comment #8 from hjl dot tools at gmail dot com 2010-03-03 22:49 ---
It is a dup of PR 24581. Backporting the gcc/tree-complex.c change
in revision 147281:
http://gcc.gnu.org/viewcvs?view=revision&revision=147281
to 4.4 fixes this.
*** This bug has been marked as a duplicate of 245
The Fortran testcase gfortran.dg/logical_dot_product.f90 fails with the
following middle-end message on SPU. As far as I can see, the generated tree by
the front end is OK and I also do not see any bit field which presumably comes
about due to the optimization. The code is:
logical :: l1(4) = (
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-03-03 22:33 ---
(In reply to comment #6)
> -ftree-vectorize never worked correctly on this testcase
> until PR 24581 is fixed.
Oh no. This is not related to that bug at all since the vectorized code is in
Fortran. And the differe
--- Comment #8 from hjl dot tools at gmail dot com 2010-03-03 22:30 ---
*** Bug 43251 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #6 from hjl dot tools at gmail dot com 2010-03-03 22:30 ---
-ftree-vectorize never worked correctly on this testcase
until PR 24581 is fixed.
*** This bug has been marked as a duplicate of 24581 ***
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #10 from manu at gcc dot gnu dot org 2010-03-03 22:11 ---
Created an attachment (id=20015)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20015&action=view)
further reduced testcase
This testcase is somehow smaller. I won't try to reduce it further.
--
manu at gcc d
--- Comment #6 from law at gcc dot gnu dot org 2010-03-03 22:10 ---
Subject: Bug 32693
Author: law
Date: Wed Mar 3 22:10:17 2010
New Revision: 157207
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157207
Log:
* PR middle-end/32693
* expmed.c (store_bit_field_1):
--- Comment #5 from law at redhat dot com 2010-03-03 22:10 ---
Fixed for gcc-4.5
--
law at redhat dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from manu at gcc dot gnu dot org 2010-03-03 21:43 ---
(In reply to comment #2)
> 4.4.2 also warns, 4.5.0 doesn't
Jonathan, could you add a testcase for GCC 4.5 so we avoid regressing?
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from a dot kumar at alumni dot iitm dot ac dot in
2010-03-03 20:49 ---
My gfortran details:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.3-3'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--en
--- Comment #4 from a dot kumar at alumni dot iitm dot ac dot in
2010-03-03 20:42 ---
Created an attachment (id=20014)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20014&action=view)
C program which uses zdrot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43251
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Known to fail||4.4.3
--- Comment #3 from a dot kumar at alumni dot iitm dot ac dot in
2010-03-03 20:41 ---
Created an attachment (id=20013)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20013&action=view)
The zdrot function from Blas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43251
--- Comment #2 from a dot kumar at alumni dot iitm dot ac dot in
2010-03-03 20:41 ---
Created an attachment (id=20012)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20012&action=view)
The Makefile used for this build.
The Makefile used for this build.
--
http://gcc.gnu.org/b
--- Comment #1 from a dot kumar at alumni dot iitm dot ac dot in
2010-03-03 20:40 ---
Created an attachment (id=20011)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20011&action=view)
Preprocessed file, built with -O2 -ftree-vectorize
This is the preprocessed file, built as:
gfo
Hi!
While compiling zdrot.f from Blas with -ftree-vectorize (which seems to be on
with -O3), I get incorrect results. I have attached a .s file, but I also
attach the original (self-contained) source files with an explanation available
here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571572
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-03-03 20:21
---
I have noticed this with some code with graphite enabled too, graphite uses
arrays for some reason.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-03-03 20:13 ---
I should mention why I filed this bug, someone asked (on IRC) how to fix up a
link error when using std::tr1::regex. Of course I looked inside bugzilla
first and did not see any so I did not look into further than t
--- Comment #6 from paolo dot carlini at oracle dot com 2010-03-03 20:10
---
Bah, frankly WONTFIX doesn't seem correct either: we are not taking about a
*bug* which we are not going to fix. We are talking about a largely
*unimplemented* part of the future C++1x standard. Now, in my opin
--- Comment #8 from bangerth at gmail dot com 2010-03-03 19:40 ---
(In reply to comment #7)
> The use of a base class ( class B : A ) is not a declaration of A.
> Thus the base class ( class A ) is visible and not private.
>
> Reopen the bug and fix it.
Andrew was right: the name 'A' i
--- Comment #5 from bangerth at gmail dot com 2010-03-03 19:31 ---
...is WONTFIX.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC|
--- Comment #4 from bangerth at gmail dot com 2010-03-03 19:30 ---
I think INVALID is the wrong resolution of this PR. This clearly is a bug
(if we offer a class we should make sure it can be used), but we may
choose to say that we won't work on this bug. The right resolution therefore..
--- Comment #7 from s dot franke at bebbosoft dot de 2010-03-03 19:26
---
The C++ Standard says:
3.4 Name lookup
The name lookup rules apply uniformly to all names (including typedef-names
(7.1.3), namespace-names (7.3) and class-names (9.1)) wherever the grammar
allows such names in t
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-03-03 19:21 ---
I have a patch to c_common_truthvalue_conversion which fixes this issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43082
I think will be good idea to have warning (and command line option to turn it
on/off) to report missing break in switch statement.
Sure syntax is valid, but I think missed breaks are occurring more often then
intentionally skipped ones.
Same goes for C++ and other languages where similar problem
For a function with no prototype that defines an argument as unsigned
int, GCC for powerpc64-linux with -m64 and optimization uses the
entire 64-bit argument register rather than masking off the lower
32 bits. This problem was discoverd with 176.gcc using options
"-m64 -O2 -ftree-vectorize -maltiv
--- Comment #11 from jason at gcc dot gnu dot org 2010-03-03 19:05 ---
As fixed as it reasonably can be until we switch to -fabi-version=4. We now
have a new mangling enabled with that flag, an error in the compiler for this
situation, a warning with -Wabi about the old mangling, and
fo
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-03-03 19:02 ---
I get:
t1.c:4:7: internal compiler error: tree check: expected class type, have
exceptional (error_mark) in get_narrower, at tree.c:7654
Now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43082
--- Comment #10 from jason at gcc dot gnu dot org 2010-03-03 19:02 ---
Subject: Bug 12909
Author: jason
Date: Wed Mar 3 19:02:08 2010
New Revision: 157204
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157204
Log:
PR c++/12909
* lto-streamer.h (LTO_tags): Add LT
--- Comment #9 from jason at gcc dot gnu dot org 2010-03-03 19:02 ---
Subject: Bug 12909
Author: jason
Date: Wed Mar 3 19:01:58 2010
New Revision: 157203
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157203
Log:
PR c++/12909
* cgraph.h (varpool_node): Add extra
--- Comment #8 from jason at gcc dot gnu dot org 2010-03-03 19:02 ---
Subject: Bug 12909
Author: jason
Date: Wed Mar 3 19:01:46 2010
New Revision: 157202
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157202
Log:
PR c++/12909
* method.c (make_alias_for): Handle
--- Comment #7 from jason at gcc dot gnu dot org 2010-03-03 19:02 ---
Subject: Bug 12909
Author: jason
Date: Wed Mar 3 19:01:36 2010
New Revision: 157201
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157201
Log:
PR c++/12909
* mangle.c: Include cgraph.h.
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-03 19:00 ---
Reduced testcase:
int main(void)
{
int gpf;
if(gpf ? (void) (0) : f ()) ;
}
--- CUT ---
Looking into it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-03 18:09 ---
I have a simple patch to build_compound_literal which fixes this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pault at gcc dot gnu dot org 2010-03-03 17:53 ---
Fixed on trunk and yes, thanks for the report!
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2010-03-03 17:50 ---
Subject: Bug 43243
Author: pault
Date: Wed Mar 3 17:49:53 2010
New Revision: 157199
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157199
Log:
2010-03-03 Paul Thomas
PR fortran/43243
* tra
--- Comment #1 from hjl dot tools at gmail dot com 2010-03-03 17:06 ---
It is caused by tuples merge. We must have missed something.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43248
--- Comment #5 from burnus at net-b dot de 2010-03-03 16:59 ---
Subject: Re: [4.5 Regression] Missing array temp for DT
with pointer component
On 03/03/2010 04:53 PM, Paul Richard Thomas wrote:
> Yet another in the series :-) I hope that it is the last...
>
So do I - espe
--- Comment #7 from mikestump at comcast dot net 2010-03-03 16:56 ---
I fixed the test case to not expect the unimplemented optimization in r157197,
however, it would be nice to ensure the async signal handlers can handle
unaligned stacks and to perform this optimization. I'm fairly cer
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
Command line:
gcc testcase.c
- testcase.c -
int foo(int i)
{
i ? : (void *){};
}
--
Output - 4.5 r157122, checking:
$ /mnt/svn/gcc-trunk/binary-157122/bin/gcc testcase.c
testcase.c: In function 'foo':
testcase.c:3:3: error: empty scalar initializer
te
--- Comment #4 from paul dot richard dot thomas at gmail dot com
2010-03-03 16:15 ---
Subject: Re: [4.5 Regression] Wrong-code due to missing
array temp for DT with pointer component
Tobias,
Don't worry, I got it:-)
The patch fixes both problems.
Cheers
Paul
On Wed, Mar
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-03 16:08 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-03-03 15:59 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #3 from burnus at gcc dot gnu dot org 2010-03-03 15:53 ---
As it might have not been completely clear from comment 0:
type t
[...]
integer, pointer :: b(:)
end type
type(t) :: y
y%b => z(::2)
call bar(y%b) ! <<< WRONG-CODE: Here a temporary is missing
With
--- Comment #1 from paul dot richard dot thomas at gmail dot com
2010-03-03 15:53 ---
Subject: Re: [4.5 Regression] Missing array temp for DT
with pointer component
Yet another in the series :-) I hope that it is the last...
This bootstraps and regtests on RHEL5.2/x86_64 -
--
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 #5 from rguenth at gcc dot gnu dot org 2010-03-03 15:42 ---
We shouldn't have deferred BB31 in the first iteration (with just TEN):
:
goto ;
...
:
:
D.2759_1 = b ();
if (D.2759_1 != 0)
goto ;
else
goto ;
:
goto ;
:
return;
Starting iteration 0
...
Bl
--- Comment #5 from janus at gcc dot gnu dot org 2010-03-03 15:40 ---
Quick fix for free form:
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 157195)
+++ gcc/fortran/decl.c (working copy)
@@ -7810,6 +7810,
--- Comment #3 from manu at gcc dot gnu dot org 2010-03-03 15:36 ---
Use -fdiagnostics-show-option to see which option controls a warning. In this
case, it will show nothing (this is another bug that will be fixed in GCC 4.6)
because, unfortunately, this is a default pedantic warning, so
--- Comment #4 from burnus at gcc dot gnu dot org 2010-03-03 15:32 ---
Regarding the error message: The problem is the lazy evaluation of error
messages. If one sets a breakpoint at "gfc_error" one finds:
gfc_error (gmsgid=0xd25bd0 "Syntax error in %s statement at %C")
gfc_error (gmsgid
--- Comment #2 from manu at gcc dot gnu dot org 2010-03-03 15:29 ---
Moreover, see http://gcc.gnu.org/wiki/NewWconversion and the -Wconversion
option has been improved notably in GCC 4.5, so you should test with that
version when available.
--
manu at gcc dot gnu dot org changed:
--- Comment #11 from janus at gcc dot gnu dot org 2010-03-03 15:17 ---
Fixed with r157196. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from janus at gcc dot gnu dot org 2010-03-03 15:13 ---
Subject: Bug 43169
Author: janus
Date: Wed Mar 3 15:12:40 2010
New Revision: 157196
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157196
Log:
2010-03-03 Janus Weil
PR fortran/43169
* res
--- Comment #2 from redi at gcc dot gnu dot org 2010-03-03 15:03 ---
4.4.2 also warns, 4.5.0 doesn't
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40145
--- Comment #1 from thiago at kde dot org 2010-03-03 14:46 ---
Anyone?
This is not a showstopper, but produces unnecessary (and incorrect) warnings.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40145
--- Comment #2 from thiago at kde dot org 2010-03-03 14:44 ---
Also:
-O1 -ftree-vrp -fno-cprop-registers -fno-defer-pop
-fno-guess-branch-probability -fno-if-conversion -fno-if-conversion2
-fno-ipa-pure-const -fno-ipa-reference -fno-merge-constants
-fno-omit-frame-pointer -fno-split-wide
--- Comment #1 from thiago at kde dot org 2010-03-03 14:41 ---
Problem also happens on:
gcc 4.4.3 on linux 32-bit
gcc 4.4.1 on linux ARM (armel gnueabi)
Also reproducible with -O1 -ftree-vrp.
--
thiago at kde dot org changed:
What|Removed |Added
--- Comment #17 from manu at gcc dot gnu dot org 2010-03-03 14:40 ---
(In reply to comment #13)
> It may be a different issue since the original testcase
> compiles with older gcc.
It is much tougher to get a testcase that compiled before but I managed to get
344K. Delta is still runnin
--- Comment #9 from manu at gcc dot gnu dot org 2010-03-03 14:38 ---
(In reply to comment #8)
> Created an attachment (id=19938)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19938&action=view) [edit]
> smaller testcase
>
> Here is the smallest testcase I could get out of delta.
This code should print "WORKS" a couple of time. But with -O2, g++ optimize
the condition away.
It works with -O1
Tested with gcc 4.4.3 on linux x86_64 (Archlinux)
#include
#include
#include
struct QVectorTypedData
{
int array[1];
};
int main(int , char **)
{
QVectorTypedData *d
--- Comment #1 from manu at gcc dot gnu dot org 2010-03-03 14:33 ---
All 4.5 pending patches block 4.6 pending patches.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from manu at gcc dot gnu dot org 2010-03-03 14:32 ---
(In reply to comment #10)
> Patch for SH to prevent the generation of the pop instruction in the
> delay slot after 'rte' for sh and sh2 targets.
Rather than attach patches here, it would be better to link to the mai
--- Comment #6 from steven at gcc dot gnu dot org 2010-03-03 14:26 ---
Well, it is not hoisting, either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38497
--- Comment #7 from amonakov at gcc dot gnu dot org 2010-03-03 13:38
---
(In reply to comment #6)
> This fixes the -O[123] miscompilations. -Os is slightly harder to fix, since
> we
> use wrong number of iterations (cond bb is executed 11 times, latch bb with
> assignment 10 times).
I
--- Comment #6 from amonakov at gcc dot gnu dot org 2010-03-03 13:06
---
Not a regression, off-by-one error in reverse iteration case is since day one.
Patch:
diff --git a/gcc/tree-loop-distribution.c b/gcc/tree-loop-distribution.c
index 13ac7ea..110abdc 100644
--- a/gcc/tree-loop-distr
--- Comment #3 from burnus at gcc dot gnu dot org 2010-03-03 12:59 ---
(In reply to comment #0)
> We should at least make sure the FINAL keyword is separated by spaces
> when parsing stuff like this.
Be careful with this! In free format that's OK but fixed format has some
strange way of
--- Comment #10 from kaushik dot phatak at kpitcummins dot com 2010-03-03
12:53 ---
Created an attachment (id=20009)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20009&action=view)
Patch for SH to prevent the generation of the pop instruction in the delay
slot after 'rte'
Patch
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-03 11:03 ---
I'm not so sure. We start with
:
plaintextlen_3 = *a_2(D);
:
# i_13 = PHI
D.2725_5 = *a_2(D);
DoHuffIteration (D.2725_5);
i_6 = i_13 + 1;
if (i_6 <= )
goto ;
else
goto ;
:
goto ;
:
--- Comment #4 from steven at gcc dot gnu dot org 2010-03-03 10:57 ---
I think pinskia means we could transform the test case of comment #0 to:
void DoHuffIteration(int);
int f(int *a)
{
int i;
int plaintextlen=*a;
pretmp = plaintextlen;
for(i = 0; i< 1; i++)
{
D
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-03 10:43 ---
This isn't PRE but code hoisting which we have a dup for.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-03 10:38 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-03 10:34 ---
Works with 4.4.2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--
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=43243
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-03 10:31 ---
Because the warning is not controlled by -Wignored-qualifiers (or -Wcast-qual).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from redi at gcc dot gnu dot org 2010-03-03 10:30 ---
-Wignored-qualifiers is for warning about qualifiers on return types, which are
ignored. I don't think it has anything to do with discarded qualifiers on
function arguments.
-pedantic-errors will give an error on your
When compiling a piece of C-source code, like:
#include
void doit(char *p)
{
p[0] = 'y';
printf("doit: %s\n", p);
}
int main(void)
{
const char *str = "hello there";
/* check whether gcc complains about const qualifier. The
-Werror=ignored-qualifiers did not wor
--- Comment #5 from jakub at gcc dot gnu dot org 2010-03-03 10:02 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from jakub at gcc dot gnu dot org 2010-03-03 09:58 ---
Subject: Bug 43229
Author: jakub
Date: Wed Mar 3 09:58:11 2010
New Revision: 157191
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157191
Log:
PR debug/43229
* cfgexpand.c (expand_debug_expr):
--- Comment #2 from janus at gcc dot gnu dot org 2010-03-03 09:54 ---
(In reply to comment #0)
> With so many compilers rejecting it, I wonder: Is it actually legal?
I guess not. Changing the line in question to
finalstate(1,1:2)%ID = (/1,103/)
makes all compilers accept it (including
--- Comment #1 from janus at gcc dot gnu dot org 2010-03-03 09:49 ---
IIRC the parsing of FINAL declarations was implemented by Daniel Kraft. It was
committed as r136293. Daniel, could you have a look at this bug?
--
janus at gcc dot gnu dot org changed:
What|Removed
I just encountered a rather strange bug in gfortran. Consider the following
code:
implicit none
type particle
integer :: ID
end type
type(particle), dimension(1,1:3) :: finalState
finalstate(1,(/1:2/))%ID = (/1,103/)
end
This is compiled fine with ifort and pgf95, but gfortran 4.5 tr
--- Comment #2 from rakdver at kam dot mff dot cuni dot cz 2010-03-03
09:21 ---
Subject: Re: Teaching SCEV about ADDR_EXPR
causes regression
> This together with the patch mentioned in the previous comment allows to
> generate:
> ivtmp.0 = &a[0][0]
>
> L1:
> s.0 = PHI(0, s.2)
, one needs to pack as the test
case also shows.
Correctness test fails with
4.5.0 20100218 (experimental) [trunk revision 156860]
4.5.0 20100303 (experimental)
but works with
4.4.2 [gcc-4_4-branch revision 155966]
4.3.4 [gcc-4_3-branch revision 152973]
module m
type t
integer
99 matches
Mail list logo
