http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53069
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
--- Comment #5 from Andrew Pinski 2012-04-22
07:19:29 UTC ---
Really you should not be dependent on the order since that has even been
defined. Yes you would think it would be defined but it was never a guarantee.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
--- Comment #6 from Ivan Godard 2012-04-22
07:46:20 UTC ---
Yes, but. Order is not defined, but order dependencies are inescapable in C++
which has a tendency to invoke constructors where you least expect them - when
you #include a file for examp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
Pawel Sikora changed:
What|Removed |Added
CC||pluto at agmk dot net
--- Comment #7 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
Ivan Godard changed:
What|Removed |Added
CC||igodard at pacbell dot net
--- Comment #96
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52562
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52702
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52942
--- Comment #16 from Paolo Carlini 2012-04-22
08:08:05 UTC ---
*** Bug 53067 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059
--- Comment #6 from Evgeny Ratnikov 2012-04-22
08:47:07 UTC ---
(In reply to comment #2)
> Why do you think this is a bug?
>
> The C++ 2011 standard requires that std::list::size() is O(1) so a new member
> variable is needed to store the contai
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53070
Bug #: 53070
Summary: ICE: in execute_cse_reciprocals, at
tree-ssa-math-opts.c:513 with -O -ffast-math
-ftree-loop-if-convert -fno-tree-loop-im
Classification: Unclassified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53071
Bug #: 53071
Summary: Wrong instruction replacement when compiling for xop
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53071
Andrew Pinski changed:
What|Removed |Added
Component|c |target
Severity|critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #19 from Marc Glisse 2012-04-22
10:31:33 UTC ---
Created attachment 27217
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27217
shuffle
With this patch, g++ passes the few __builtin_shuffle tests I tried, and
generates generic co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46886
--- Comment #14 from razya at gcc dot gnu.org 2012-04-22 10:36:18 UTC ---
Author: razya
Date: Sun Apr 22 10:36:13 2012
New Revision: 186667
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186667
Log:
2012-04-20 Razya Ladelsky
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059
--- Comment #7 from Jonathan Wakely 2012-04-22
11:38:36 UTC ---
(In reply to comment #6)
> problem is that after such change my application (-std=98) linked with
> libraries (-std=0x) causes corrupted stack.
You can't do that. It won't work.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685
--- Comment #20 from Uros Bizjak 2012-04-22 12:42:07
UTC ---
(In reply to comment #19)
> int test (int a, int b)
> {
> int lt = a + b < 0;
> int eq = a + b == 0;
> if (lt)
> return 1;
> return eq;
> }
Actually, here ce1 pass steps o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685
--- Comment #21 from Uros Bizjak 2012-04-22 12:45:17
UTC ---
(In reply to comment #17)
> The only one which is not fixed is comment #4
This testcase is fixed with patch at [1].
[1] http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00295.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685
Uros Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53058
Markus Trippelsdorf changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #20 from Marc Glisse 2012-04-22
13:21:14 UTC ---
(In reply to comment #19)
> Created attachment 27217 [details]
> shuffle
Doesn't work with -std=c++11, which requires:
--- semantics.c(revision 186667)
+++ semantics.c(working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53027
--- Comment #2 from Jonathan Wakely 2012-04-22
14:14:21 UTC ---
Author: redi
Date: Sun Apr 22 14:14:15 2012
New Revision: 186671
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186671
Log:
PR libstdc++/53027
* include/bits/ptr_trai
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53027
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52910
Agner Fog changed:
What|Removed |Added
CC||agner at agner dot org
--- Comment #1 from Ag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #21 from Manuel López-Ibáñez 2012-04-22
14:56:28 UTC ---
(In reply to comment #19)
> With this patch, g++ passes the few __builtin_shuffle tests I tried, and
> generates generic code for non-constant indexes and special code for const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #22 from Marc Glisse 2012-04-22
15:09:23 UTC ---
(In reply to comment #20)
> And then I still need to write a cxx_eval_vec_perm function so the result of
> __builtin_shuffle can be constexpr. I haven't seen how the C front-end handles
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52383
Thorsten Glaser changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067
--- Comment #3 from Paolo Carlini 2012-04-22
16:10:38 UTC ---
I'm right now rebuilding both mainline and branch, because yesterday both
worked and I don't think we changed anything in this area. What the heck it is?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
Manuel López-Ibáñez changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53072
Bug #: 53072
Summary: automatically set Init() only if option was not set in
some other way
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067
Paolo Carlini changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #97 from Ian Lance Taylor 2012-04-22 17:03:24
UTC ---
One option you have is to configure gcc with --disable-initfini-array.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53073
Bug #: 53073
Summary: [4.8 Regression] 464.h264ref in SPEC CPU 2006
miscompiled
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53051
--- Comment #2 from Tobias Burnus 2012-04-22
17:28:39 UTC ---
Author: burnus
Date: Sun Apr 22 17:28:34 2012
New Revision: 186675
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186675
Log:
2012-04-22 Tobias Burnus
PR fortran/53
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53051
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067
--- Comment #5 from paolo at gcc dot gnu.org
2012-04-22 17:38:07 UTC ---
Author: paolo
Date: Sun Apr 22 17:37:57 2012
New Revision: 186676
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186676
Log:
2012-04-22 Paolo Carlini
PR libs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067
--- Comment #6 from paolo at gcc dot gnu.org
2012-04-22 17:38:18 UTC ---
Author: paolo
Date: Sun Apr 22 17:38:11 2012
New Revision: 186677
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186677
Log:
2012-04-22 Paolo Carlini
PR libs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53067
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #98 from Ivan Godard 2012-04-22
17:44:24 UTC ---
It's OK if you reverse the default order - make it sideways if it gets a faster
Firefox. We can cope.
It's OK is you dump ctors for init_array if it simplifies your maintenance. We
do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #99 from Jan Hubicka 2012-04-22 18:33:44
UTC ---
> OK to re-open this ticket?
If ctor order was/is controllable via linker script, it seems that you need
similar feature for init arrays. In that case it is binutils feature, not GCC,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53074
Bug #: 53074
Summary: insn-recog.c:recog calls predicates known to be false
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: missed-optimi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #100 from Paolo Carlini
2012-04-22 18:43:18 UTC ---
As as side, Sunday-type, observation, we don't normally use the work 'ticket'
here (if only because no money is involved, at least, not in the open ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059
--- Comment #8 from Evgeny Ratnikov 2012-04-22
19:11:22 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > problem is that after such change my application (-std=98) linked with
> > libraries (-std=0x) causes corrupted stack.
>
> Yo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44774
--- Comment #16 from Manuel López-Ibáñez 2012-04-22
19:17:51 UTC ---
Author: manu
Date: Sun Apr 22 19:17:47 2012
New Revision: 186681
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186681
Log:
2012-04-22 Manuel López-Ibáñez
PR c/4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059
--- Comment #9 from Paolo Carlini 2012-04-22
19:18:13 UTC ---
That last situation is really totally unsupported and never was. By the way, I
don't know if you noticed already, but it doesn't work for many, many, reasons
outside sizes of container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #101 from Ivan Godard 2012-04-22
19:35:08 UTC ---
Well, it's easy to say that it's the other guy's problem, but it isn't. You are
assuming that the linker is always gnu ld; for big shops with multi-platform
targets that's not necessar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53075
Bug #: 53075
Summary: -Werror=pedantic should be equivalent to
-pedantic-errors
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44774
Manuel López-Ibáñez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37187
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
Target|x86_6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53076
Bug #: 53076
Summary: [4.8 Regression]: gcc.dg/torture/builtin-explog-1.c,
gcc.dg/torture/builtin-power-1.c at -O0 soft-float
newlib
Classification: Unclassified
Product
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077
Bug #: 53077
Summary: suggestion to add the .f extension to the list of file
extensions that trigger enabling of the preprocessor
Classification: Unclassified
Product: gcc
Versio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077
--- Comment #1 from Sylwester Arabas 2012-04-22
20:35:49 UTC ---
The gfortran-mp-4.6 vs. gfortran difference in the code above is not relevant
to the issue.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #102 from Ian Lance Taylor 2012-04-22
21:16:14 UTC ---
To be clear, nothing has changed in collect2. The only thing that has changed
is that data that was being emitted in the .ctors section is now being emitted
in the .init_array se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077
--- Comment #2 from Sylwester Arabas 2012-04-22
21:36:33 UTC ---
Hmm... apparently the PGI compiler uses the same rule for enabling preprocessor
with .f and .F extensions. Then, if there's some important reason behind it (?)
perhaps at least the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #103 from Ivan Godard 2012-04-22
21:52:40 UTC ---
I may be just displaying my ignorance, but my understanding is that order under
init_array is governed by order of pointers within the array itself, and where
the pointed-to sections a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #104 from Ian Lance Taylor 2012-04-22
22:26:50 UTC ---
I'm not sure what you mean. Each object file will have a .init_array section.
The linker will assemble those sections in the usual manner.
The order of global constructors in a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53078
Bug #: 53078
Summary: [C++11] Wrong diagnostic "no return statement in
function returning non-void" on
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53065
Georg-Johann Lay changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53079
Bug #: 53079
Summary: Unwanted optimization occurs on function with the same
name as a math.h function without including math.h nor
linking with libm
Classification: Unclassified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53078
--- Comment #1 from Paolo Carlini 2012-04-23
00:21:43 UTC ---
Are you *really* sure you are using current 4.8? I get:
paolo@poldo4:~/Work> g++ -std=c++11 -Wall -Wextra -Werror -pedantic 53078.C
53078.C: In function ‘int main()’:
53078.C:1:19: e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53077
--- Comment #3 from Andrew Pinski 2012-04-23
01:17:16 UTC ---
Why can't you just pass the -cpp option to gfortran if you want to enable the
preprocessor?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53079
--- Comment #1 from Andrew Pinski 2012-04-23
01:19:48 UTC ---
This is expected. If you don't want floor to be considered a builtin, then use
-fno-builtin-floor . The C standard even says the name is in the reversed
namespace really.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53076
--- Comment #1 from Andrew Pinski 2012-04-23
01:26:41 UTC ---
I saw this failure on non soft-float x86 too.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53080
Bug #: 53080
Summary: std::array - std::get() and std::tuple_element is
nothing bounds check
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53076
Hans-Peter Nilsson changed:
What|Removed |Added
Summary|[4.8 Regression]: |[4.8 Regression]:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53059
--- Comment #10 from Evgeny Ratnikov 2012-04-23
02:47:37 UTC ---
Now it's clear. Thanks for replies.
.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53078
--- Comment #2 from M8R-gt1qwe at mailinator dot com 2012-04-23 03:58:52 UTC ---
Ooops. That will teach me to make sure I update before filing a bug :S I was
running 20120401. You can close this. It doesn't manifest on 20120422.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081
Bug #: 53081
Summary: memcpy/memset loop recognition
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081
--- Comment #1 from Andrew Pinski 2012-04-23
05:03:28 UTC ---
I thought there is already one part of graphite.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081
--- Comment #2 from Andrew Pinski 2012-04-23
05:07:30 UTC ---
I should mention I made one patch before based on the vectorizer code which did
detection of at least memset; it was while I was an intern at Apple. I posted
it and there was some rev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081
--- Comment #3 from davidxl 2012-04-23 05:34:24
UTC ---
(In reply to comment #2)
> I should mention I made one patch before based on the vectorizer code which
> did
> detection of at least memset; it was while I was an intern at Apple. I posted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081
--- Comment #4 from davidxl 2012-04-23 05:34:55
UTC ---
(In reply to comment #2)
> I should mention I made one patch before based on the vectorizer code which
> did
> detection of at least memset; it was while I was an intern at Apple. I posted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53082
Bug #: 53082
Summary: local malloc/free optimization
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53082
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19831
Andrew Pinski changed:
What|Removed |Added
CC||xinliangli at gmail dot com
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081
--- Comment #6 from Andrew Pinski 2012-04-23
06:54:43 UTC ---
(In reply to comment #4)
> LLVM's version also tries to merge smaller memsets into a larger one.
That is filed as PR 49872.
And the original issue is related to PR 30442.
79 matches
Mail list logo
